I built my home lab solely to embark on distro-hopping (mis)adventures. But over time, I began using my server nodes for other purposes, including building wacky computing projects and sharpening my DevOps skills. Running FOSS apps is also one of them, and since I often encounter new self-hosted services while researching for new articles, my application stack tends to grow with each passing week.

Besides the extra power consumption of my nodes, a major drawback of hosting every cool-looking service I come across is that a malicious app can sneak its way into my arsenal and wreak havoc. As such, my paranoid self relies on several preventive measures to save my precious servers from potentially harmful services.

Configure VLANs for insecure services

Especially all apps involving IoT devices

Between their weak security provisions and inherent vulnerabilities, smart home gadgets and IoT gizmos often pose huge security risks in a home lab. Since I’ve combined my smart peripherals with a bunch of automation services, my servers and app stack can get compromised by these insecure devices.

Or so I’d say if I weren’t relying on VLANs. A managed switch was the first investment I made after buying a handful of smart home gadgets, and I did it just so I could reduce the security risks using VLANs. I’ll admit that I had a bit of trouble setting them up on my switch and router (or rather firewall), and configuring the Proxmox bridges to operate on VLANs. But being able to restrict vulnerable devices and services to virtual networks was well worth the effort, as all my essential tools run on a different VLAN, and hackers would have a harder time breaking into them from my smart devices.

Self-host a firewall OS

And harden its security rules

Leaving barebones ISP routers aside, their third-party counterparts often feature solid firewall rules. However, even the most expensive routers tend to lack on the customizability front, especially when it comes to advanced firewall facilities. The solution? Deploying a custom firewall and configuring its traffic rules to minimize the chances of intruders breaking into my systems.

I’ve stuck with OPNsense ever since I migrated from a Raspberry Pi-powered OpenWRT firewall, though pfSense is also a solid option. Besides tweaking the default firewall rules (which are actually quite good) and enabling VLANs, I’ve armed my OPNsense instance with Suricata and CrowdSec for extra IDS/IPS provisions.

Use an SSO server for logins

It’s quite secure when configured correctly

Truth be told, I didn’t look into Single Sign-On servers until earlier this year – and I really wish I’d given them a shot sooner. True to the name, an SSO server lets me log into all my self-hosted services (and even virtualization platforms) using a single set of credentials. I’m a part of the Authentik faction, as it’s fairly easy to set up and includes tons of features. And if you’re wondering, there are some security benefits to using an SSO instance to log into my home lab.

For starters, many of my home lab services – including Vert and BentoPDF – don’t have password-based logins built into them. By combining Authetik with a reverse proxy manager, I can force login screens to appear for these applications. Authentik also keeps track of login attempts, including failed ones, and lets me create blocking policies to ensure I don’t have unauthorized users trying to gain access to my devices. Throw in MFA support, and SSO servers like Authentik can protect my services while sparing my brain cells the hassle of remembering different passwords for everything in my self-hosted empire.

Deploy unprivileged containers

To reduce the attack surface for containerized apps

While their lightweight nature is a huge perk, containers don’t provide the same level of isolation as their VM counterparts. This is especially true for privileged containers, which not only offer root-level access to the host machine’s resources, but also remove certain security rules. Sure, you get better compatibility with network mounts and can map devices easily with privileged containers, but they are quite a nightmare for security-conscious folks such as myself.

As such, I prefer running my LXCs as well as Docker and Podman containers in unprivileged/rootless modes. That way, the underlying server will have fewer chances of getting compromised if I end up running suspicious services inside containers.

Run frequent vulnerability scans

Yes, I use Kali Linux to break into my own hardware

Finally, I regularly use pen-testing tools to ensure my home lab’s security is in tip-top shape. Since Kali Linux offers a plethora of vulnerability detection and network scanning tools, it’s my preferred companion for this task. Wireshark, for example, lets me quickly scan all network protocols operating on my LAN, and it’s my go-to utility for checking suspicious activity in my virtual guests.

There’s also Zenmap, which is great for scanning open ports, and I used Evil-Winrm to scan my remote Windows 11 dev VM for vulnerabilities when I first deployed it. I also relied on Aircrack-ng for pen-testing my own Wi-Fi connection ages ago, and it’s precisely why I use dozens of characters in my WLAN passwords.

Some more tips on securing your home lab

Besides the tricks I’ve mentioned so far, I also have a couple of other security measures I want to go over before concluding this article. I use Kopia to schedule regular backups of all my devices and virtual guests, as its encryption facility lowers the chances of my data becoming irretrievable from ransomware attacks. While it’s technically not a self-hosted service, I use Tailscale to safely access my home lab and application stack from external networks. That way, I don’t have to expose my precious services to the massive botnet armies marching around on the Internet.