Published 2026-04-25 · 8 min read

A 30-minute homelab security baseline (no enterprise tools required)

You don't need a dedicated security team or a five-figure tooling budget to make your homelab meaningfully harder to compromise. You need 30 focused minutes and the willingness to actually do the checklist below. Time to get from "nothing in particular" to a defensible baseline.

Minute 0–5: Inventory what you actually have

You can't secure a fleet you can't list. Open a terminal and write down (or paste into a note):

Most homelab compromises start with a service the operator forgot they exposed. The list itself is half the value.

Minute 5–10: Patch everything, right now

Run the package manager's update on every host: 

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade -y

# Rocky / Alma / RHEL
sudo dnf upgrade -y

# Alpine
sudo apk update && sudo apk upgrade

# Arch
sudo pacman -Syu --noconfirm

For homelabs, also enable unattended security updates so this doesn't depend on you remembering: 

# Debian / Ubuntu
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Rocky / Alma / RHEL
sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Reboot when the update lands a new kernel. Check uptime on each host afterwards — anything older than ~6 months is likely overdue for a kernel restart.

Minute 10–15: SSH hardening

Open /etc/ssh/sshd_config on every host and confirm:

Reload sshd: sudo systemctl reload sshd.

On the Mac you SSH from, make sure ~/.ssh/authorized_keys on every host contains only the keys you currently use. Old laptop keys, retired keys, anything from a former sysadmin or a "test" account — purge them now. (SSH key hygiene detail here.)

Minute 15–20: Close anything you don't actively serve

List listening services on each host: 

ss -tulpn          # show every TCP/UDP listener with the owning process
sudo ss -tulpn     # add process names if not running as root

Look for surprises. Is there a Redis on 0.0.0.0:6379? An old phpMyAdmin on port 80? A lingering test web server? Either bind it to localhost, firewall it off the public LAN, or stop the service.

Set the firewall default to deny-incoming, allow-only-what-you-need: 

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'ssh'
sudo ufw allow 443/tcp comment 'https reverse proxy'   # if applicable
sudo ufw enable

Minute 20–25: TLS and admin surfaces

For every web service you expose (even just to LAN):

Minute 25–30: Pick a CVE-awareness tool

You've now patched, hardened SSH, closed open ports, and authenticated admin surfaces. The remaining question is: how do you know the next CVE that drops affects you?

Three options at the homelab scale:

  1. Subscribe to security mailing lists for the distros you run (debian-security-announce, ubuntu-security-announce). Free, manual, requires you to read and act.
  2. Run Lynis weekly on each host and scan the report for hardening regressions. Free, host-installed, per-host operation.
  3. Run a fleet-wide CVE scanner that polls a signed feed daily and reports diffs. Noxen sits here — Mac-native, agentless over SSH, $79 one-time at launch. See also agent vs agentless trade-offs.

Whichever you pick, put a recurring calendar reminder for the first weekly review. Tools that run but never get looked at provide false comfort, which is worse than running nothing.

Optional: 5 more minutes for the paranoid

Why this works

The 30-minute checklist isn't comprehensive. It won't pass an auditor's checklist for SOC 2. It won't catch every config bug or every CVE. What it does is move you from "soft target" to "not worth the attacker's time" — which for a homelab on the public internet is the goalpost that matters. The CVE scanner you set up in minute 25 keeps the baseline maintained as time passes.

Try Noxen when it ships — $79 one-time at launch.

Related reading