How to Secure a Homelab Network in 2026: 7 Steps Before You Expose Anything

How to Secure a Homelab Network (Short Answer)

Secure a home lab in seven steps, in this order: close every inbound port on the router, reach the lab over an overlay VPN instead of a forwarded port, turn off SSH password login and use keys, run a default-deny firewall on every host, put IoT and anything exposed on their own VLAN, treat containers as untrusted, then back up and monitor so you find out first. The order matters more than the tooling. Nothing on this list costs money.

Tested on: Ubuntu Server 24.04 LTS and 26.04, Debian 13, Proxmox VE 9, Docker Engine 27. Last reviewed 8 September 2026.

What actually attacks a home lab: 11 days on one fresh server

Most homelab security advice starts with a threat you cannot see. This one starts with a number.

In August 2026 I put a brand new cloud VM online and left it there with monitoring on, to see how long a fresh server lasts before the bots find it. Nothing ran on it that anyone could use. No DNS pointed at it. Nobody knew it existed. I watched it for 11 days and counted what hit the SSH port, with my own vulnerability scanner excluded from the totals so the numbers are only other people’s traffic.

• 1,001 failed SSH logins on the first day.
• 28,578 failed SSH logins over 11 days, roughly 2,600 a day.
• 658 distinct source addresses across 68 countries.

The shape of it is more useful than the total. By number of addresses the spread was United States 114, China 106, Netherlands 55, Vietnam 40, Germany 31. By number of attempts it was Netherlands 6,658, United Kingdom 3,267, United States 2,781, Andorra 2,770. Country here comes from IP geolocation, which tells you where the machine sat, not who was at the keyboard.

Around half the addresses belonged to cloud and hosting ranges rather than home broadband. Two hosting networks alone accounted for 41% of everything. Fifty-five addresses were Google Cloud, 35 were Azure, 22 were DigitalOcean. These are rented machines running scanners, paid for by someone.

What they guessed says something too. root was tried 11,791 times, admin 2,051, ubuntu 974. Then solana and sol, over 500 times between them: bots looking for crypto wallets on any box that answers.

None of it worked, because root was key-only from the first minute. That is the whole point. The exposure window is not “once I get round to it”. It opens the second the machine has a public IP, and it is measured in minutes.

So the threat model for a home lab is not a targeted attacker. It is industrial-scale automation:

• Automated scanning. Every public address is swept continuously for open ports, default credentials, known CVEs and unauthenticated admin panels.
• Credential stuffing. Leaked username and password pairs get replayed against any login page an attacker can reach, including your Nextcloud, your Grafana and your router.
• Accidentally exposed dashboards. Portainer, Proxmox and router admin pages get found within hours of being reachable.
• Untrusted container images. Pulling an unmaintained image from a stranger is the container equivalent of running an attachment from an unknown sender.

All four are cheap to defend against. None of them need expensive tooling. They need the seven steps below, applied in order.

Step 1: Close every inbound port on the router

Port forwarding is the single most common way a homelab ends up in someone else’s scan results. Forwarding 22 or 80 to a box inside your network puts that box in the same population as the server above: about 2,600 login attempts a day, starting immediately.

Log into your router and check the port forwarding, virtual server and DMZ pages. Remove anything you did not deliberately add. Turn off UPnP while you are there, because it lets any device on your network open a port without asking you.

Verify from outside your network, not from inside it. From a phone on mobile data, or any host that is not on your LAN:

nmap -Pn -p 22,80,443,8006,9000 your.public.ip

Every port should come back filtered or closed. If one is open, you have found your first job.

Step 2: Reach the lab over an overlay VPN, not a forwarded port

Once the ports are shut you still need a way in. The answer is an overlay network that authenticates you before any service is reachable, rather than a hole in the firewall that anyone can knock on.

• Tailscale, a mesh VPN built on WireGuard. Quickest to stand up, works through NAT with no router changes.
• WireGuard directly, if you would rather not depend on a coordination service. More setup, no third party in the path.
• Cloudflare Tunnel, for publishing a specific web service without exposing the host at all.
• Twingate, if you want per-resource access control that looks like what you would deploy at work.

Whichever you pick, the rule is the same: management interfaces are never published. Proxmox on 8006, Portainer on 9000, your router’s admin page and any database tool stay reachable only over the overlay.

Our walkthroughs: Tailscale on Linux, WireGuard on Ubuntu, and Cloudflare Tunnels on Debian.

Step 3: Turn off SSH password login and use keys

This is the change that made 28,578 attempts irrelevant. With password authentication disabled there is nothing to guess, so the entire brute-force category stops mattering.

Generate a key on the machine you connect from, then copy it up:

ssh-keygen -t ed25519 -C "you@yourmachine"
ssh-copy-id you@your-server

Confirm the key works before you lock anything down. Then put the settings in a drop-in file, /etc/ssh/sshd_config.d/00-hardening.conf, rather than editing /etc/ssh/sshd_config itself. sshd uses the first value it reads for each setting, the drop-in directory is read first, and many cloud images ship 50-cloud-init.conf with PasswordAuthentication yes, which silently overrides an edit to the main file:

PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

Test the config before restarting, so a typo cannot lock you out:

sudo sshd -t && sudo systemctl restart ssh
# confirm the setting sshd is actually using
sudo sshd -T | grep -i passwordauthentication

Keep your existing session open and prove a new one works from a second terminal before you close it. Every directive above is documented in the sshd_config manual page, and Ubuntu’s own OpenSSH server guide covers the same ground.

Add fail2ban afterwards if you like the log noise reduction, but understand what it is for. Once passwords are off, fail2ban is tidying your logs, not holding the door. The door is already shut.

Deeper: SSH key authentication on Ubuntu, 8 SSH settings that stop brute-force logins, and fail2ban on Ubuntu, including the 24.04 journal trap.

Step 4: Run a default-deny firewall on every host

The router firewall protects the boundary. A host firewall protects each machine from everything already inside your network, which is where a compromised smart plug or a guest laptop lives.

On Ubuntu and Debian, ufw does this in four commands:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw enable

Note the third line. Allowing SSH from your LAN subnet only is meaningfully different from ufw allow OpenSSH, which allows it from everywhere. Check the result:

sudo ufw status verbose

One caveat that catches people out: Docker writes its own iptables rules and can publish a container port past ufw. If you map a port with -p 8080:80, bind it explicitly to localhost (-p 127.0.0.1:8080:80) unless you actually want it on the network.

Longer version: UFW for homelabs, restricting services to your LAN subnet.

Step 5: Put IoT and exposed services on their own VLAN

Segmentation is about blast radius, not perfection. If a smart bulb gets compromised, it should not be able to reach your file server.

If your switch supports VLANs: lab devices on one VLAN, household devices on another, IoT on a third with no route to either. Management interfaces go on a management VLAN that only your admin workstation can reach. IoT firmware is the least maintained code on your network and deserves the strictest isolation.

If it does not: use the router’s guest network for IoT, which most consumer routers isolate by default, and lean harder on host firewalls to restrict which addresses can reach management ports. At minimum, keep your lab servers off the same subnet as devices whose firmware you do not control.

If you want a firewall OS rather than a consumer router, OPNsense and pfSense both run happily on a small box and give you real inter-VLAN rules. The UK NCSC’s home working guidance makes the same separation argument for work devices at home, which is the same problem with a different label.

Step 6: Treat containers as untrusted

Containers are isolated, not sandboxed. A container running as root with the Docker socket mounted is root on the host, and plenty of copy-paste compose files do exactly that.

• Prefer official or well-maintained images, and check when the image was last built rather than how many stars it has.
• Never use --privileged unless you can say precisely why. Drop capabilities instead: --cap-drop ALL and add back only what breaks.
• Do not mount /var/run/docker.sock into a container you did not write.
• Run read-only where the app allows it: --read-only with a tmpfs for scratch space.
• Bind published ports to an interface, not to every interface.
• Consider rootless mode for anything internet-facing.

Keep images current. Watchtower automates it, or schedule a pull yourself:

docker compose pull && docker compose up -d

Docker’s own security documentation and the run reference spell out what each flag actually gives away.

Step 7: Back up, monitor and alert so you find out first

The first six steps reduce the chance of a bad day. This one decides how bad the day is.

Backups. Three copies, two media, one offsite. Restic, Borg or Duplicati all encrypt client-side, so an offsite target you do not control is fine. The rule that matters is the one people skip: restore something, on purpose, before you need to. An untested backup is a hypothesis.

Monitoring. Uptime Kuma runs in one container and will tell you a service died within a minute instead of three days later. Netdata or Grafana give you the resource picture underneath it.

Alerting. Monitoring without alerting is just logging. Wire up notifications for service down, disk nearly full and repeated failed logins, then deliberately break something to prove the alert arrives.

Logs. You do not need a SIEM at home, though you can run one. Check /var/log/auth.log for failed SSH attempts, your reverse proxy logs for odd requests, and container logs for restarts you did not cause.

Setup guides: Uptime Kuma with Docker and Grafana and Prometheus for homelab monitoring.

The 7-step checklist

Step	Do this	Verify it worked
1	Remove all router port forwards and disable UPnP	nmap -Pn from outside shows no open ports
2	Install an overlay VPN and reach the lab through it	Admin panels unreachable with the VPN off
3	SSH keys only, PasswordAuthentication no	A password login attempt is refused
4	Host firewall default-deny, SSH from your subnet only	sudo ufw status verbose shows deny incoming
5	IoT and exposed services on a separate VLAN or guest network	IoT device cannot ping a lab host
6	No --privileged, no docker socket mounts, images current	docker inspect shows no privileged containers
7	Backups running, monitoring alerting to your phone	A test restore completes and a test alert arrives

Which VPN is best for a home lab?

Tailscale for most people, because it works through NAT with no router configuration and takes about ten minutes. Plain WireGuard if you would rather not depend on a coordination server and are comfortable managing keys and endpoints yourself. Cloudflare Tunnel is not really a VPN, it is a way to publish one web service without exposing the host, so it complements the other two rather than replacing them. Avoid the VPN server built into a consumer router unless you have checked when its firmware was last updated.

Which DNS is best for a home lab?

Run your own resolver on the lab so you can see what your network is asking for, and so that name resolution does not depend on a service outside your control. Pi-hole and AdGuard Home both do this and both block at the DNS layer. Point them at an upstream you trust over DNS-over-HTTPS or DNS-over-TLS. The trap is making it a single point of failure: if the box running your DNS goes down, everything in the house looks broken. Run a second resolver, or set a working secondary on the DHCP scope.

Comparison: Pi-hole vs AdGuard Home.

What router is best for a home lab?

Any router will do if it lets you turn off UPnP, remove port forwards and run a guest network. The upgrade that actually changes what you can build is VLAN support, which usually means a managed switch plus a firewall OS such as OPNsense or pfSense rather than a better consumer router. Buy the switch before the router. If you are staying with the ISP box, the honest position is that segmentation will be coarse and you should lean on host firewalls instead.

Plan for the bad day before you have one

Homelab security work is usually framed as prevention, and the seven steps above are prevention. The part people skip is deciding, in advance, what happens when prevention fails. Answer these three questions in writing, today, while nothing is on fire:

• If the main storage died right now, what would I actually lose? Not what is backed up in principle. What is in the gap between your last verified restore and now.
• How long would a rebuild take? If the answer is “I would have to remember how I set it up”, that is the finding. Configuration belongs in a git repository, not in your head or in a container you can no longer start.
• Would I know? A compromised home lab rarely announces itself. It gets quieter, or it gets busier at three in the morning. Without the monitoring from step 7 the honest answer is usually no.

If you do suspect a host is compromised, the order is: isolate it from the network first, take a copy of the disk or a snapshot before you touch anything, and only then start looking. Investigating a live box overwrites the evidence you would want. Rotate every credential that host could reach, including keys and API tokens, and assume anything it could read was read. Rebuild rather than clean: a rebuilt host from known-good configuration is trustworthy, a cleaned one is a guess.

Write it down as a plain markdown file in the same repository as your compose files. A page of notes you wrote calmly is worth more than any security tool you install in a panic.

The mistakes that undo the other six steps

Four patterns account for most of the home lab security problems worth having an opinion about, and none of them are exotic:

• Doing step 7 first. Standing up the service, then promising to sort the firewall out later. The measurement at the top of this page is what “later” costs: the scanning starts the same day, not when you are ready for it.
• Trusting the LAN. Treating everything inside the house as safe means one compromised device reaches everything. Host firewalls and segmentation exist because the boundary is not the only place attacks come from.
• Security theatre on the wrong layer. Moving SSH to port 2222 while leaving password authentication on. Scanners find the port in seconds; the password is the thing that mattered.
• Backups nobody has restored. The most common serious loss in a home lab is not an intrusion at all. It is a disk failure meeting a backup job that had been silently failing for months.

Why this matters beyond the lab

Every step above is the home version of something with a budget line attached at work. Default-deny, key-based authentication, network segmentation, least privilege on containers, tested restores, detection and alerting. The tooling differs, the reasoning does not.

That is the practical case for doing it properly at home: it is the cheapest place to build the habits, and being able to explain why you put the firewall before the service is the thing that reads as experience in an interview. A home lab you can describe defending is worth more on a CV than a list of things you installed.

Want the interactive version of this checklist plus the rest of our free tools? They all live in the RTM Toolbox, and the homelab quiz will tell you what to secure next.

Frequently Asked Questions

How do I secure my homelab network?

Work in this order: remove every router port forward and disable UPnP, reach the lab over an overlay VPN such as Tailscale or WireGuard instead of an open port, disable SSH password authentication and use keys, set a default-deny host firewall on each machine, separate IoT and exposed services onto their own VLAN or guest network, run containers without privileged mode or a mounted Docker socket, and finish with tested backups plus monitoring that alerts you. The sequence matters more than the specific tools, and none of it costs money.

How quickly do bots find a new server?

Immediately. A brand new cloud VM with no DNS record and nothing running on it took 1,001 failed SSH login attempts on its first day online, and 28,578 over 11 days from 658 addresses in 68 countries. Roughly half the sources were cloud and hosting ranges rather than home connections. There is no quiet period during which it is safe to postpone the firewall.

Is it safe to port forward to my homelab?

Forwarding a port puts that service into continuous automated scanning within minutes, so it is only reasonable when the service is designed to be exposed, is kept patched, and sits behind strong authentication. For anything administrative, including Proxmox, Portainer, router pages and database tools, the answer is no. Use an overlay VPN, or publish a single web service through a tunnel so the host itself is never reachable.

Does changing the SSH port make my homelab safer?

Barely. A full port scan finds a moved SSH service in seconds, so it reduces log noise rather than risk. It is not harmful, but it is not a control either. Disabling password authentication is the change that actually removes the threat, because it leaves nothing for a brute-force attempt to guess.

Do I need a firewall for my homelab?

Yes, and preferably two layers. The router firewall handles the boundary, and a host firewall such as ufw on each server protects it from everything already inside your network, which is where a compromised IoT device would be. Set the default to deny incoming, then allow only what you need, and restrict SSH to your own subnet rather than to everywhere. Be aware that Docker writes its own iptables rules and can publish a container port past ufw unless you bind it to localhost.

Should I use a VPN or zero trust for homelab remote access?

Either is far better than a forwarded port, and the practical difference is granularity. A VPN such as WireGuard or Tailscale puts you on the network and then relies on host firewalls to limit what you can reach. Zero trust access such as Twingate or Cloudflare Tunnel authenticates per resource, so a compromised client reaches one service rather than the whole subnet. For most home labs Tailscale is the fastest route to a safe setup; add per-resource control when you have services other people use.

What are Docker security best practices for a homelab?

Avoid privileged mode, drop capabilities with –cap-drop ALL and add back only what breaks, and never mount /var/run/docker.sock into a container you did not write, because that is equivalent to giving it root on the host. Prefer images that are actively maintained and check when they were last built rather than counting stars. Bind published ports to a specific interface instead of every interface, run read-only where the application allows it, consider rootless mode for anything internet-facing, and keep images current with a scheduled pull.