2026-10-16 21:48 UTC
Replies (8)
-
@sznowicki@lemmy.world 2026-10-16 22:02
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.
-
@werebearstare@lemmy.ca 2026-10-16 22:44
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.
-
@trojanbark@lemmy.world 2026-10-16 22:53
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.
-
@CameronDev@programming.dev 2026-10-16 22:57
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.
-
@irq0@infosec.pub 2026-10-16 22:23
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
-
@Reannlegge@lemmy.ca 2026-10-16 22:48
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.
-
@Onomatopoeia@lemmy.cafe 2026-10-17 01:41
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.
-
@miaowoo_lw@lemmy.world 2026-10-18 04:55
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: 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. 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. 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.