Topics → Homelab security

Homelab security

Q: What's the most important homelab security task?

Patch what's actually exposed first. In rough order of impact for a 5–50 host fleet: patch internet-facing services, harden SSH, close admin surfaces you forgot were reachable, and watch for TLS certificates about to expire. A 30-minute baseline pass covers all four without any new tooling.

Q: How do I secure SSH on a homelab?

Use key-only authentication, disable password and root login in sshd_config, and audit authorized_keys across every host so you can find and remove keys you no longer recognise. The hard part on a fleet is doing it everywhere consistently without locking yourself out mid-rotation.

Q: What are exposed admin surfaces?

Web admin panels — Grafana, Pi-hole, phpMyAdmin, the *arr suite, Portainer — reachable from a network they shouldn't be, often bound to 0.0.0.0 and forgotten. Most homelab compromises that aren't drive-by RCE start with one of these. Auditing for them across ~70 known services is a core part of a homelab security pass.

Q: Do I need enterprise tools like Nessus for a homelab?

No — Nessus, Qualys, and Tenable are capable but the wrong shape and price for a homelab. A right-sized approach is agentless scanning over SSH from a Mac you already own: same classes of finding, no enterprise console, no per-host bill.

A pragmatic guide for people who run their own boxes. SSH hygiene, TLS expiry, exposed admin surfaces, CVE triage, Linux hardening — without the enterprise overhead. Every post here has been tested on a real homelab fleet.

Where to start

Homelab security has a different shape than enterprise security. There's no SOC team to triage alerts, no compliance auditor to satisfy, no patch-management vendor to write the cheque to. What you have is some Saturday afternoons, a Mac or two, a handful of Linux boxes, and a list of "I'll get to it eventually" tasks that quietly grew into the thing that gets you owned.

The right answer isn't to ape an enterprise security programme at one-tenth scale. It's to identify the small number of things that actually move the needle for a fleet of 5-50 hosts, do them well, and ignore the rest.

In rough order of impact, those things are: patching what's actually exposed, hardening SSH, closing exposed admin surfaces you forgot existed, and watching for TLS certs about to expire. Together they cover the realistic threat model: drive-by internet scanners harvesting unpatched RCEs, weak SSH config, forgotten Grafana / Pi-hole / *arr panels, and 3 AM cert-expiry pages from your spouse.

If you only have 30 minutes

Start with the 30-minute homelab security baseline. It's a four-step procedure that takes you from "I haven't really thought about it" to a defensible position: patch every host, harden SSH, close ports you don't need, and authenticate every admin surface. No new tools required.

Pair that with a recurring monthly homelab security checklist — ninety minutes a month, with coffee, that keeps the fleet from drifting back into entropy. Most homelab compromises happen because someone did a great one-time hardening pass and then never revisited it. The monthly checklist is the antidote.

Hardening individual surfaces

Once the baseline is in place, the depth comes from hardening specific surfaces. Each of the posts below goes deep on a single attack vector with the exact commands to audit and fix.

SSH key hygiene for homelabs
Audit authorized_keys across your fleet, rotate without locking yourself out, and find the keys you forgot you trusted.
TLS certificate expiry on self-hosted services
Stop your services going down at 3 AM because a cert quietly expired. Per-host, per-service, with the renewal commands that actually work.
Exposed admin surfaces
Why most homelab compromises start with a forgotten Grafana / phpMyAdmin / Pi-hole panel — and the 70+ services to check.
Ubuntu 22.04 LTS hardening checklist
Twelve audit-ready SSH, TLS, and package-policy checks every Jammy box should run before April 2027 EOL.
Why your Raspberry Pi's OpenSSL is out of date
Find unpatched CVEs on your Pi and fix them in one command — including the package-cache trap that keeps reintroducing the same CVEs.
10 homelab security quick wins
Ten practical hardening steps you can apply across your homelab in a single Saturday — no new software required.

Per-service hardening checklists

The most-attacked surfaces in a homelab are usually a handful of popular self-hosted apps. These go service-by-service with the exact settings to check before — and after — you expose them.

Before you expose a service to the web
The pre-flight checklist to run before opening any panel to the internet — auth, TLS, rate limits, and the questions to answer first.
Home Assistant security checklist
Lock down the most-exposed smart-home hub: trusted networks, auth, API tokens, and reverse-proxy hygiene.
Pi-hole security checklist
Keep the admin panel and DNS resolver from becoming an open relay or an exposed control surface on your LAN.
Proxmox security checklist
Harden the hypervisor that runs everything else — web UI exposure, API tokens, and the container-escape blast radius.

Where homelab security goes wrong

Two failure modes account for most homelab compromises that aren't drive-by RCE: the patching gap (apt upgrade doesn't touch Plex, Grafana, Pi-hole, or your *arr suite — those need their own update path) and forgotten admin surfaces (a Pi-hole admin panel exposed to 0.0.0.0 on a public-facing VPS is far more common than people think). Both are dealt with above.

The third failure mode is alert fatigue. If your tooling pages you about every theoretical CVE on every host, you'll learn to ignore the page — including the one that actually matters. The post on how often to scan covers cadence; the post on triaging CVE findings covers what to actually act on.

Tooling for the homelab shape

Nessus, Qualys, Tenable — fine tools, wrong shape for a homelab. Nessus alternative for Mac homelabs covers the right-sized options. Agent vs agentless covers the architectural choice behind every scanner — and why agentless wins for a fleet you don't fully control. Pareto Security for your fleet compares the per-host audit model to the fleet-level audit model.

The Mac-native, agentless, one-time-purchase shape is what Noxen exists to fill. It runs nightly audits against your remote Linux fleet over SSH, flags the same classes of finding the posts above describe, and surfaces them in a single Mac-native view.

Frequently asked

What's the most important homelab security task?

Patch what's actually exposed first, then harden SSH, close forgotten admin surfaces, and watch TLS expiry. The 30-minute baseline covers all four with no new tooling.

How do I secure SSH on a homelab?

Key-only auth, no password or root login, and a regular audit of authorized_keys across every host — see SSH key hygiene for homelabs.

What are exposed admin surfaces?

Forgotten web panels (Grafana, Pi-hole, the *arr suite) reachable from a network they shouldn't be. Most non-RCE homelab compromises start here — the full write-up is here.

Do I need enterprise tools like Nessus for a homelab?

No — wrong shape and price. Agentless scanning over SSH from your Mac fits better; see the Nessus alternative and Noxen vs Pareto Security.