Live data from Hacker News

A story on home server security

raniseth.com

31–40 of 287 posts

Re: A story on home server security

#31

> "None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet." This prompts a reflection about, as an industry, we should make a better job in providing solid foundations. When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful aroun…

Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here. As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server. I myself even wouldn't venture into exposing a server to the internet to…

> Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here.

I find this to be extremely sad.

Unlike welding or diving, there is no inherent physical risk to life and limb to running a server. I should be able to stand up a server and leaving it running, unattended and unadministered, and then come back to it 20 years later to find it happily humming along unpwned. The fact that this isn't true isn't due to any sort of physical inevitability, it's just because we, the collective technologists, are shit at what we do.

Re: A story on home server security

#32

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…

This is only an issue if you run Docker on your firewall, which you absolutely should not.

Re: A story on home server security

#33
post #31

Earlier quoted context omitted.

Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here. As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server. I myself even wouldn't venture into exposing a server to the internet to…

> Just like people shouldn't just buy industrial welding machines, SCUBA equipment or a parachute and "wing it" I think the same can be said here. I find this to be extremely sad. Unlike welding or diving, there is no inherent physical risk to life and limb to running a server. I should be able to stand up a server and leaving it running, unattended and unadministered, and then come back to it 20 years later to find…

No. It's not so easy because in most cases you have to choose between security, flexibility and usability. Obviously it's not a 100% accurate example but generally speaking, it tends to be true. Sum it up over several decades of development and you get why we cannot have something that it's really really easy to use, flexible and secure by default.

Re: A story on home server security

#34

I think I'm missing something here - what is specific about Docker in the exploit? Nowhere is it mentioned what the actual exploit was, and whether for example a non-containerized postgres would have avoided it. Should the recommendation rather be "don't expose anything from your home network publically unless it's properly secured"?

From TFA: > This was somewhat releiving, as the latest change I made was spinning up a postgres_alpine container in Docker right before the holidays. Spinning it up was done in a hurry, as I wanted to have it available remotely for a personal project while I was away from home. This also meant that it was exposed to the internet, with open ports in the router firewall and everything. Considering the process had been…

> Seems like they opened up a postgres container to the Internet

Yes, but so what? Getting access to a postgres instance shouldn't allow arbitrary execution on the host.

> IIRC docker does this whether you want to or not, it punches holes in iptables without asking you

Which is only relevant if you run your computer directly connected to the internet. That's a dumb thing to do regardless. The author probably also opened their firewall or forwarded a port to the host, which Docker cannot do.

Re: A story on home server security

#36

> "None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet." This prompts a reflection about, as an industry, we should make a better job in providing solid foundations. When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful aroun…

> When I check tutorials on how to drill in the wall, there is (almost) no warning about how I could lose a finger doing so. It is expected that I know I should be careful around power tools.

I think the analogy and the example work better when the warning is that you should be careful when drilling in walls because there may be an electrical wire that will be damaged.

Re: A story on home server security

#37
Im curious about what the password for postgres looked like.

This exact thing happened to a friend, but there was no need to exploit obscure memory safety vulnerabilities, the password was “password”.

My friend learnt that day that you can start processes in the machine from Postgres.

Re: A story on home server security

#38

Tailscale is a great solution for this problem. I too run homeserver with Nextcloud and other stuff, but protected behind Tailscale (Wireguard) VPN. I can't even imagine exposing something like my family's personal data over internet, no matter how convenient it is. But I sympathize with OP. He is not a developer and it is sad that whatever software engineers produce is vulnerable to script kiddies. Exposing database…

C and C++ is not accountable for all evil of the world. Yes I know, some Rust evangelists want to tell us that, but most servers get owned through configuration mistakes.

Re: A story on home server security

#39

Despite people slating the author, I think this is a reasonable oversight. On the surface, spinning up a Postgres instance in Docker seems secure because it’s contained. I know many articles claim “Docker= Secure”. Whilst easy to point to common sense needed, perhaps we need to have better defaults. In this case, the Postgres images should only permit the cli, and nothing else.

Every guide out there says to link Postgres to the application (the one using Postgres). So the Postgres network is not reachable. Then, even if it were exposed, a firewall would need to be configured to allow access. Then, another thing every guide does is suggesting a reverse proxy, decreasing attack service. Then, such reverse proxy would need some kind of authentication. Instead, I simply run it behind Wireguard. There's still plenty to go wrong, such as backdoor in Postgres database image (you used docker pull), not upgrading it while it contains serious vulnerabilities, or a backdoor in some other image.

Re: A story on home server security

#40

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…

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