this post was submitted on 16 Oct 2026
33 points (100.0% liked)

Selfhosted

63012 readers
1720 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

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 are viewing a single comment's thread
view the rest of the comments
[–] miaowoo_lw@lemmy.world 1 points 1 hour ago

Your instinct is right but I'd push back gently on one assumption: the Pi 5 only buys you real containment if you also assume the attacker will escape the container — and container escapes from properly configured containers (no privileged, no docker socket mounted, seccomp default) are rare in practice. What's not rare is an attacker getting app-level access to one public service and then abusing that service's credentials: your Nextcloud app password, its SMTP credentials, its access to the reverse proxy config.

So the segmentation that pays off most for minimal effort:

  1. Move public services off the NAS box — yes, exactly as you planned. The Pi 5 handles a handful of public services fine. Even without container-escape paranoia, you've separated the machine that has your entire NAS/backup dataset mounted.
  2. Credentials are the actual lateral path. Whatever the Pi can reach, the Pi's compromise can reach: make its firewall allow only the specific ports it needs back into the LAN (DNS out, maybe the backup target port), and ideally have it push backups out rather than pull data in.
  3. Reverse proxy on the Pi too — your public-facing reverse proxy config is itself a target (acme account, upstream definitions). Keep it with the services it fronts, not with your private infrastructure.

One extra benefit you didn't mention: rebuilding is now cheap. If the public machine gets trashed — by an attacker, or more likely by you breaking it during an update — your NAS/VPN/DNS stack is untouched and you can redeploy the public box from a compose file in an hour. That separation-for-blast-radius argument sells itself in the first real incident.