Lock down a homelab without locking yourself out. Your real threat model, secrets out of plaintext files, key-only SSH, remote access with zero open ports, and a written plan for the day something leaks — from a real hardening sweep, not enterprise theater.
If you do nothing else from this guide today, do these four things. They won’t make you bulletproof, but they close the four doors that account for nearly every home-network compromise: an exposed service, a reused password, password-based SSH, and secrets sitting in plaintext.
Setups: any home network with one or more self-hosted services — Home Assistant, a NAS, cameras, a media server, anything you’ve thought about reaching from outside the house. Examples use Linux/Docker conventions; the principles are platform-agnostic.
Assumes: you have administrative access to your services and your router, and a way to reach a machine locally (console or LAN) if you misconfigure remote access. That local fallback is non-negotiable for Chapters 04 and 06.
Before you change SSH, firewall, tunnel, or router settings, confirm you have local console access, a current backup, and a recovery path that doesn’t depend on the thing you’re changing. Every step below that can lock you out repeats this where it bites.
Log into your router and find the port-forwarding table. For most homes the correct number of entries is zero. Every forwarded port is a service answering the entire internet, and automated scanners find them within minutes of being opened. If you currently reach something from outside via a forwarded port, leave it for now — Chapter 05 replaces it with a safer path — but delete anything you don’t recognize or no longer use today.
Port forwards aren’t the only door. Also check UPnP/NAT-PMP auto-mappings (apps can open ports for themselves), your IPv6 firewall (it’s separate from IPv4 and often more permissive), any router remote-admin toggle, and cloud “remote access” switches inside apps. Each can expose a service with no manual port forward at all.
Password reuse is the single highest-leverage risk at home. One leaked service becomes every service. You don’t have to fix it all today — start with the crown jewels: email, your router, your password manager itself, and anything holding financial or personal data. Give each a unique, generated password stored in a manager. Chapter 03 covers the full dig-out when one password has quietly spread across dozens of logins.
If you SSH into anything, switch to key-based authentication and turn password login off. Password-based SSH on an exposed host is the classic break-in, and bots hammer it constantly.
# on your laptop: make a key if you don't have one ssh-keygen -t ed25519 -C "you@laptop" # copy it to the server (keeps password login working until you confirm) ssh-copy-id user@server # confirm key login works in a NEW terminal BEFORE disabling passwords
Before you disable password SSH or enable a firewall, make sure you have a way back in that doesn’t depend on the thing you’re changing — a physical console, a KVM, or a hypervisor shell. Confirm key login works in a second terminal while your first session is still open. Every section that can lock you out says so explicitly.
Search your configs, .env files, and docker-compose.yml files for anything that looks like a password, API key, or token. Anything you find is a secret living in plaintext, often in a file that’s also in a git repo or a backup. Move them into a password manager or secrets vault and reference them from there. Chapter 02 is the full version of this — it’s the most important chapter in the guide.
If something specific brought you here, jump straight to it. Otherwise read start to finish — the chapters build on each other.
| If you… | Go to |
|---|---|
| opened ports / exposed a service | Chapter 05 · Appendix A |
| reused one password everywhere | Chapter 03 · Appendix C |
| found a secret in a config or in git | Chapter 02 · Chapter 09 |
| want to safely expose a service | Appendix A · Appendix B |
| just want copy-paste commands | Appendix D |
| think something already leaked | Chapter 09 (the playbook) |
Most home-security advice fails in one of two directions: vague platitudes, or enterprise machinery nobody runs at home. The fix is to be honest about who you’re actually defending against — because it isn’t who you think, and the real list is short.
Almost nobody is hand-picking your Raspberry Pi for a targeted attack. The threats that actually reach a home network are overwhelmingly automated and opportunistic. Get these four right and you’ve handled the realistic majority:
You are not too small to target, because nobody is targeting you specifically — they’re targeting everyone, cheaply, at scale. To an automated scanner you are an IP address with open ports and a login form, indistinguishable from a million others. “Too small” assumes a human is deciding you’re not worth the effort. No human is in that loop.
Honesty cuts both ways. At home, treat SIEMs, threat-intelligence feeds, intrusion-detection appliances, and quarterly pentests as optional later layers, not the starting point. They’re real tools for real budgets and staff you don’t have, and chasing them steals attention from the five things that actually move the needle: no open ports, no reused passwords, no plaintext secrets, key-only SSH, and a way to recover when something slips. Everything in this guide ladders up to those.
For every control in this guide, ask: which of the four threats does this address, and at what cost to me? If a measure defends against an attacker you don’t realistically face, and it makes your life harder, it’s theater. Skip it and spend the effort on the doors that are actually open.
You’ve seen your real threat model. The full guide covers getting secrets out of plaintext files, credential rotation that actually sticks, key-only SSH without locking yourself out, zero-trust remote access with zero open ports, network segmentation, host firewalling, a repeatable self-audit, and a written incident playbook — plus four printable appendices including a full service-exposure matrix. About 30 pages.