Live data from Hacker News

A story on home server security

raniseth.com

21–30 of 287 posts

Re: A story on home server security

#21
post #3

Earlier quoted context omitted.

> Always block China and Russia from any of your services. But does this add much security if bad actors are using VPNs ?

They'd need to run a VPN with end point in a less hostile country and so there's an element of enforcement on those endpoints. At any rate, blocking China and Russia isn't ever presented as a foolproof defence, it just raises the barrier to attack.

They extensively use these VPNs, in NL. They can also use Tor exit node.

Either way, nothing is full proof. It is part of a solid defense in depth [1].

[1] https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing)

Re: A story on home server security

#22

> "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…

You can't just click a few buttons and have industrial machinery - and when you DO get it there's a ton of safety warnings on and around it. And I don't agree with your fundamental premise; self owned computing should be for everyone. It shouldn't be - at least for some subset of basics - arcane or onerous.

Re: A story on home server security

#23

> "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…

I don't think it's that unreasonable for a database guide not to mention it. This is more of a general server/docker security thing. Just as I wouldn't expect an application guide to tell me not to use windows xp because it's insecure.

Most general guides on the other hand regarding docker mention not to expose containers directly to the internet and if a container has to be exposed to do so behind a reverse proxy.

Re: A story on home server security

#24
There usual route that people would take is either use VPN/tailscale/Clouflare Tunnels ..etc and only expose things locally and you will need to be on VPN network to access services. The other route is not to expose any ports and rely on reverse proxy. Actually you can combine the two approaches and it is relativity easy for non SWE homelab hobbyists.

Re: A story on home server security

#25

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 running for 8 days, this means that the infection occured just a day after creating the database. None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet. Ofcourse I password protected it, but seeing as it was meant to be temporary, I didn't dive into securing it properly.

Seems like they opened up a postgres container to the Internet (IIRC docker does this whether you want to or not, it punches holes in iptables without asking you). Possibly misconfigured authentication or left a default postgres password?

Re: A story on home server security

#26

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…

We’ve found this out a few times when someone inexperienced with docker would expose a redis port and run docker compose up on a public accessible machine. Would only be minutes until that redis would be infected. Also blame redis for having the ability to run arbitrary code without auth by default.

Re: A story on home server security

#27

> "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…

And yet, OP here seems very comfortable with computer stuff. Can’t imagine about the regular joe buying a nas from synology and all the promesses made by the company.

Re: A story on home server security

#28
post #24

There usual route that people would take is either use VPN/tailscale/Clouflare Tunnels ..etc and only expose things locally and you will need to be on VPN network to access services. The other route is not to expose any ports and rely on reverse proxy. Actually you can combine the two approaches and it is relativity easy for non SWE homelab hobbyists.

If anyone is looking for one, https://nginxproxymanager.com/

Been using it for years and it’s been solid.

Re: A story on home server security

#29

Earlier quoted context omitted.

> C and C++ has been failing us for decades yet we continue to use such unsafe stacks. I'm not sure — what do C and C++ have to do with this?

They are not memory safe by design. See: https://xeiaso.net/blog/series/no-way-to-prevent-this/ Of course all languages can produce insecure binaries, but C/C++ buffer overflows and similar vulnerabilities are likely what AlgebraFox refers to.

> They are not memory safe by design

I'm aware of that, but the C/C++ thing seemed more like a rant, hence my question.

I've searched up the malware and it doesn't seem to use memory exploitation. Rust is not going to magically protect you against any security issue caused by cloud misconfiguration.

Re: A story on home server security

#30

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…

Containers are widely used at our company, by developers who don't understand underlying concepts, and they often expose services on all interfaces, or to all hosts.

You can explain this to them, they don't care, you can even demonstrate how you can access their data without permission, and they don't get it.

Their app "works" and that's the end of it.

Ironically enough even cybersecurity doesn't catch them for it, they are too busy harassing other teams about out of date versions of services that are either not vulnerable, or already patched but their scanning tools don't understand that.

Post reply on HN