Hi selfhosters,
I’m considering improving the security of my homelab/server setup and I’d love to hear some more experienced opinions on my plans.
Like most self-hosters, I started out with a single-server setup: I cobbled together some old hardware, slapped on a NAS-style OS, bolted on Docker and started experimenting. As things go, my setup has grown a lot over the years. I’m running a lot on that machine - NAS capability, local DNS via pihole, a Wireguard VPN endpoint (so I can tunnel into the LAN from outside), many private services (accessible only from inside the LAN), but also some public ones accessible from the open web.
Although I’ve tried to do my homework in terms of security (various hardening measures for SSH and Docker, reverse proxy, proper SSL termination for everything), I realise I’ve put a lot of eggs in that one basket and I might want to introduce some network segmentation.
I don’t think I’m ready for getting a hardware firewall or a router/switch capable of VLANs just yet. What I’m considering, though, is putting my services available from the open internet on a separate server inside my network - a little Pi 5 I’ve still got lying around. My idea is that if a container on that is breached and if an attacker manages to escape the container to gain root access, compromise would be limited to the few of publicly available services I have on the Pi, thus limiting blast radius. If combined with (software) firewall rules that make the Pi a ‘pariah node’ (dropping all incoming connection efforts), lateral movement to other devices on the network could be contained.
An alternative would be to finally make the move to Proxmox. Everything would still be running on one physical machine, but I’d create several VMs: there would be one for private, one for publicly available services, and I’d firewall the latter off rigorously so it cannot connect to anything else.
I’d like your opinion on these plans. Which one would you recommend? Are they both sound, or is there anything I haven’t considered? Are there other (easy, non-hardware intense) things I could do to improve security even more?
You must log in or register to comment.
Security architect at a large enterprise here, so grain of salt with what I say as it may be overkill for your use case. First question you have to ask yourself is so what? If they completely compromise your devices, what impact will that have? Establish what your hard and soft limits are. Are you ok with your device becoming a crypto miner? If not, what controls can you put in place? e.g. CPU/GPU monitoring and alerting. Are you worried about threat actors stealing your personal data? Consider encrypting your drives and applying least privilege (don’t have a single user account). Worried they will do the favour of encrypting your drives for you? Look into off site storage.
If you are only using docker, the switch to Proxmox may give you trouble as docker isn’t supported. That said, I run Proxmox and have everything as an LXC and I think it is an excellent technology. If you stay on Docker, look up the OWASP Docker cheat sheet. It will help you to lock everything down tightly. You could also migrate to podman. Still not comfortable with the risks and controls at that point? Look at creating docker networks or a SDN. Also, log into your router. You may find that you can create a DMZ to limit an adversaries ability to pivot.
Feel free to reach out and ask more.
Thanks for your detailed reply and expertise! I really appreciate it!
First question you have to ask yourself is so what?
You’re right to call out my lack of threat modeling. I am aware that the “cost” of what I’m planning here likely outweighs the actual risks. That’s a deliberate choice though: one of my objectives in homelabbing is to “learn how the big guys do it”, i.e. learning and implementing, bit by bit, networking and security best practices.
That said,
- all of my drives are (LUKS) encrypted (although this will only help against evil maid attacks physically stealing my disks, since data is only encrypted at rest, not while the server is in operation)
- I do have some CPU monitoring in place
- I have applied the principle of least privilege (as far as I can see at least)
- I have set up an off-site backup server running (although I need to improve automation and deduplication; I’ll probably go with Borg here)
Thank you also for pointing me towards OWASP Docker cheat sheet! I didn’t know this resource yet, although I seem to have found others that said the same thing. I already have in place:
- no docker socket exposed to services
- user set for every service that didn’t give me a headache doing that (some assume root and won’t accept setting a user)
- username remapping is active
- all containers have their caps dropped and selectively only put those back in which they need
- I expose almost no container ports, and only those necessary; instead, communication with the containers is handled on my reverse proxy’s network (i.e. via the internal docker network)
- privilege escalation is disabled
I have played around with rootless docker (again, stubborn containers assuming root prevented me from going all-in) and considered Podman, although just putting containers in a VM looks like a more frictionless route to me.
All things considered, your advice seems to be:
- to first consider whether I actually need all this security. I really don’t, yet I want to learn how to set it up anyway.
- to first explore and all other hardening avenues. I have, to a certain degree, and beyond that run into brick walls.
If I might exhaust a little more of your time, I’d be curious how you judge the next step I’ve suggested: splitting duties between separate servers, thus segmenting public from private physically, or going the virtual route (again, by splitting into a public and a private VM and separate them through strict software firewalling).
+1 for owasp resources.
My primary purpose for separating services is stability.
My file server is just for file services - so if my media server needs a reboot it doesn’t affect anything else, like my media conversion server, etc.
Preventing lateral movement is really a secondary benefit. If someone gets in, my ability to prevent lateral movement as a non-enterprise is pretty limited.
I still use separate user accounts for different purposes with heavily restrictive permissions.
I still use separate user accounts for different purposes with heavily restrictive permissions.
Good call, that’s an even more effective first line of defense! (I have, however, already implemented it. ;)
Is lateral movement really a risk for you? Most internet malware is fully automated drive-by stuff. They hit you, gain execution and your part of their botnet. They don’t need to move laterally, because they have all the execution they need.
Moving laterally requires a human (or agent these days), which has a non-zero time and resource cost, so the only reason anyone is going to do that to you is if you are a very valuable target.
Do whatever you like for learning/fun, but I wouldn’t stress to much. Your risk level is probably very low.
I wouldn’t stress to much. Your risk level is probably very low.
I’m not, no worries! :) You are correct to say that what I’m trying to do is likely above my threat model. Yet, I’m also in this for the learning experience, which includes picking up best practices and networking/security concepts that go a little bit above what I actually need.
Also…
Moving laterally requires a human (or agent these days)
you’re bringing up the emerging threat of agentic attacks that allows for automating lateral movement. While infiltrating some rando’s network probably doesn’t warrant burning through several thousands of expensive tokens now, odds are this cost will decrease over time, thus increasing the likelihood of opportunistic automated attacks. If and when that happens, I’d like to be prepared.
I respect what you said about your own firewall, however I disagree with it! ISP modem/firewall’s are rarely if ever updated/upgraded. I thought I was fine without a hardware firewall until I started getting into some of my more darring adventures into home labbing. I was using DuckDNS for things, but decided I wanted to be able to do more so I needed a static IP. Luckily my ISP offers two static IPs for free so I got those.
I hope part of your hardening SSH is changing the port number! If you want to keep your LAN safer with a firewall, and something small like a pi zero (I use a pi zero 2), you can setup a honey pot vLAN. Again I realize you said not interested in a firewall, but I am saying a honepot helps.
Thanks for your input. It is correct that a lot of ISPs/consumer grade hardware is poorly maintained. Mine is a rare exception, however: I’m running an AVM FritzBox, which are somewhat famous for still receiving updates even after 10+ years on the market. They have only recently pushed a security update my way, so I’m good enough on that front - for now.
I shall consider a firewall in the future though.
I hope part of your hardening SSH is changing the port number!
I used to do that, but then realised that doing so will do very little. Scanning all possible ports is a matter of seconds, and SSH (unlike Wireguard) will signal to a potential attacker that it’s listening on port X instead of just remaining silent. In other words: in my eyes, it’s security by obscurity and will have very little effect.
What I have done to harden SSH is:
- set up pubkey authentication and disable password authentication
- disable root login
- not expose my SSH port publicly; it is accessible only from my LAN and through Wireguard
I have also tried out IP whitelisting (which may harden my setup against attacks from the LAN), but found it may be overkill for now. I might turn it back on just for shits and giggles.
Containing lateral movement of a compromised machine is hard
Before doing anything else , consider if you actually need to expose anything to the internet at all. Running a VPN would let you reduce your exposed service to 1 port ( wireguard is UDP based so it’s harder to test if the port is open too ). A VPN like NetBird / tailscale / Cloudflare warp don’t need you to open any ports at all
Except for services that absolutely must be open to the internet ( like my Tor Relay ) I access everything via NetBird
Before doing anything else , consider if you actually need to expose anything to the internet at all. Running a VPN would let you reduce your exposed service to 1 port ( wireguard is UDP based so it’s harder to test if the port is open too ). A VPN like NetBird / tailscale / Cloudflare warp don’t need you to open any ports at all
Good advice! Here’s my setup in more detail:
- a good 90% of my services are “private”, i.e. they’re only accessible through Wireguard or from the LAN. I use local DNS + a reverse proxy to get “virtual” URLs + proper SSL termination within the LAN. Also, all administrative tools (e.g. SSH) are private (Wireguard or LAN only); none of them are publicly available.
- some of my services (e.g. Nextcloud, Wireguard, RustDesk) are public so as to allow me to use collaboration and file sharing tools with others. For this I do expose some ports publicly.
As you can see, I have mostly realised what you said. However, I don’t see myself setting up VPN connections for each and every user of my services and train them how to use them; link shares via Nextcloud or tech support via RustDesk need to be frictionless, so taking these services private isn’t an option.
Yet if one of these public services were to be compromised and root access gained, I do see the risk of a (motivated) attacker to attempt lateral movement to get at the more sensitive services that I’m keeping local for a reason.
I personally go with VMs. Except of some services that I run on Hetzner.
I got one Debian server that runs multiple VMs with tailscale. Then one Hetzner VPS with Caddy. This one acts as a public gateway.
Some things are still running bare metal, like Immich or Jellyfin because of apple hardware. However the level of entropy I have now is th opposite of all eggs in on basket. I sometimes forget what do I have where and have to look it up in my docs.
This sounds a lot like my second option, except yours is a little more custom-made. What do you use to set up and run your VMs?
combine your VMs with a little layered LXC garnish for that special touch :-)
I was in your position a few years ago. Went the Proxmox route. For many services, don’t make separate VMs, but instead separate LXC containers. Saves time and space.
I’ve done my research on that, and apparently LXCs share the host kernel, meaning: if the LXC is compromised, so is the host system. So if I go with Proxmox, I’ll probably swallow the (somewhat) larger overhead of running a full VM.
