Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A story on home server security

raniseth.com

Post reply on HN
Print view View original

211–220 of 287 posts

Re: A story on home server security

#211

Post by bakugo »

aaomidi wrote: post #207
bakugo wrote: post #183

Earlier quoted context omitted.

Important to note that, even if you use Tailscale, the firewall punching happens regardless, so you still have to make sure you either: 1. Have some external firewall outside of the Docker host blocking the port 2. Explicitly tell Docker to bind to the Tailscale IP only

> the firewall punching happens regardless Does it? I think it only happens if you specifically enumerate the ports. You do not need to enumerate the ports at all if you're using Tailscale as a container.

Oh, I didn't realize you meant running Tailscale in docker, my bad. Then yeah, that's safe.

Re: A story on home server security

#212

Post by spr-alex »

smarx007 wrote: post #16

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737 I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set t…

-p 127.0.0.1: might not offer all of the protections the way you would expect, and is arguably a bug in dockers firewall rules they're failing to address. they choose to instead say hey we dont protect against L2, and have an open issue here: https://github.com/moby/moby/issues/45610.

this secondary issue with docker is a bit more subtle, it's that they don't respect the bind address when they do forwarding into the container. the end result is that machines one hop away can forward packets into the docker container.

for a home user the impact could be that the ISP can reach into the container. depending on risk appetite this can be a concern (salt typhoon going after ISPs).

more commonly it might end up exposing more isolated work related systems to related networks one hop away

Re: A story on home server security

#213

Post by bt1a »

bluedino wrote: post #178
dijit wrote: post #54

Earlier quoted context omitted.

This is pretty common, developers are focused on making things that work. Sysadmins were always the ones who focused on making things secure, and for a bunch of reasons they basically don’t exist anymore. EDIT: what guidelines did I break?

> This is pretty common, developers are focused on making things that work. True, but over the last twenty years, simple mistakes by developers have caused so many giant security issues. Part of being a developer now is knowing at least the basics on standard security practices. But you still see people ignoring things as simple as SQL injection, mainly because it's easy and they might not even have been taught other…

and many of these people havent debugged messages more complex than a Python error message. tastelessly jabbing at needing to earn your marks by slamming into segfaults and pushing gdb

Re: A story on home server security

#214

Post by eadmund »

veyh wrote: post #125
smarx007 wrote: post #16

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737 I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set t…

I wonder how many people realize you can use the whole 127.0.0.0/8 address space, not just 127.0.0.1. I usually use a random address in that space for all of a specific project's services that need to be exposed, like 127.1.2.3:3000 for web and 127.1.2.3:5432 for postgres.

Be aware that there is an effort to repurpose most of 127.0.0.0/8: https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...

It’s well-intentioned, but I honestly believe that it would lead to a plethora of security problems. Maybe I am missing something, but it strikes me as on the level of irresponsibility of handing out guardless chainsaws to kindergartners.

Re: A story on home server security

#215

Post by eadmund »

MortyWaves wrote: post #76
anthropodie wrote: post #40

Earlier quoted context omitted.

And this was one of the reason why I switched to Podman. I haven't looked back since.

I want to use Podman but I keep reading the team feels podman-compose to be some crappy workaround they don’t really want to keep. This is daunting because: Take 50 random popular open source self-hostable solutions and the instructions are invariably: normal bare installation or docker compose. So what’s the ideal setup when using podman? Use compose anyway and hope it won’t be deprecated, or use SystemD as Podman s…

Honestly, I just use a small k8s cluster, and convert the docker compose config to k8s config.

Re: A story on home server security

#216

Post by smarx007 »

spr-alex wrote: post #212
smarx007 wrote: post #16

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737 I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set t…

-p 127.0.0.1: might not offer all of the protections the way you would expect, and is arguably a bug in dockers firewall rules they're failing to address. they choose to instead say hey we dont protect against L2, and have an open issue here: https://github.com/moby/moby/issues/45610 . this secondary issue with docker is a bit more subtle, it's that they don't respect the bind address when they do forwarding into the…

What about cloud VMs? I would love to read more about "they don't respect the bind address when they do forwarding into the container" and "machines one hop away can forward packets into the docker container" if you could be so kind!

Upd: thanks for a link, looks quite bad. I am now thinking that an adjacent VM in a provider like Hetzner or Contabo could be able to pull it off. I guess I will have to finally switch remaining Docker installations to Podman and/or resort to https://firewalld.org/2024/11/strict-forward-ports

Re: A story on home server security

#217

Post by eadmund »

diggan wrote: post #106
aaomidi wrote: post #49

Earlier quoted context omitted.

Tbh I prefer not exposing any ports directly, and then throwing Tailscale on the network used by docker. This automatically protects everything behind a private network too.

FOSS alternative is to throw up a $5 VPS on some trusted host, then use Wireguard (FOSS FTW) to do basically exactly the same, but cheaper, without giving away control and with better privacy. There is bunch of software that makes this easier than trivial too, one example: https://github.com/g1ibby/auto-vpn/

Or you can use headscale (BSD) with the Tailscale client (BSD), which is still FOSS but also very very easy to use.

Re: A story on home server security

#218

Post by adriancr »

smarx007 wrote: post #184
adriancr wrote: post #177

Earlier quoted context omitted.

securing is straightforward, too bad it's not by default: https://docs.docker.com/engine/network/packet-filtering-fire...

Do I understand the bottom two sections correctly? If I am using ufw as a frontend, I need to switch to firewalld instead and modify the 'docker-forwarding' policy to only forward to the 'docker' zone from loopback interfaces? Would be good if the page described how to do it, esp. for users who are migrating from ufw. More confusingly, firewalld has a different feature to address the core problem [1] but the page you…

I'm not sure about ufw/firewalld. Maybe docs aren't clear there either

I configured iptables and had no trouble blocking WAN access to docker...

In addition to that there's the default host in daemon.json plus specifying bindings to local host directly in compose / manually.

Re: A story on home server security

#219

Post by sgarland »

diggan wrote: post #152
sgarland wrote: post #131

Earlier quoted context omitted.

For crypto miners, it’s pretty easy to tell if your servers are in your house. Even if they aren’t, if you have any kind of metrics collection, you’ll notice the CPU spike. My general feeling is that if someone wants to install a hardware rootkit on my extremely boring home servers, it’s highly unlikely that I’ll be able to stop them. I can do best practices (like not exposing things publicly), but ultimately I can’t…

> For crypto miners, it’s pretty easy to tell if your servers are in your house. Even if they aren’t, if you have any kind of metrics collection, you’ll notice the CPU spike. Sure, but if you already know since before that this specific cryptominer has been found together with rootkits, and you know rootkits aren't as easy to detect, what's your approach to validate if you're infected or not? Maybe I'm lucky that I c…

NixOS isn't going to do anything against a hardware rootkit, which is what I originally mentioned. My home infra's base layer is Proxmox, with VMs built with Packer + Ansible, but that still has the same problem.

That's my point – you can do best practices all day long, but short of observing sudden shifts (or long-term trends) in collected metrics, you're not going to be able to notice, let alone defend, against sophisticated attacks. There has been malware that embeds itself into HDD firmware. Good luck.

Re: A story on home server security

#220

Post by tomjen3 »

geye1234 wrote: post #84
smarx007 wrote: post #16

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737 I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set t…

I am not a security person at all. Are you really saying that it could potentially cause Iptables to open ports without an admin's knowing? Is that shockingly, mind-bogglingly bad design on Docker's part, or is it just me? Worse, the linked bug report is from a DECADE ago, and the comments underneath don't seem to show any sense of urgency or concern about how bad this is. Have I missed something? This seems appallin…

To run Docker, you need to be an admin or in the Docker group, which warns you that it is equivalent to having sudo rights, AKA be an admin.

As for it not being explicitly permitted, no ports are exposed by default. You must provide the docker run command with -p, for each port you want exposed. From their perspective, they're just doing exactly what you told them to do.

Personally, I think it should default to giving you an error unless you specified what IPs to listen to, but this is far from a big of an issue as people make it out to be.

The biggest issue is that it is a ginormous foot gun for people who don't know Docker.

Post reply on HN