A story on home server security • Hacker News Board

Re: A story on home server security

#231

Post by timcambrant » Sun, Jan 05, 2025, 9:24 PM UTC

mattrighetti wrote: post #29

timcambrant wrote: post #19

Earlier quoted context omitted.

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.

I think it was a rant, but still related to the post. Its point is that we need to minimize the attack surface of our infrastructure, even at home. People tend to expose services unintentionally, but what's so bad about that? After all, they are password protected.

Well, even when these exposed services are not built to cause harm or provide admin privileges, like all software they tend to not be memory secure. This gives a lucky attacker a way in from just exposing a single port on the network. I can see where comments on memory unsafe languages fit in here, although vulnerabilities such as XSS also apply no matter what language we build software with.

Re: A story on home server security

#232

Post by wutwutwat » Sun, Jan 05, 2025, 9:32 PM UTC

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…

From the linked issue

> by running docker images that map the ports to my host machine

If you start a docker container and map port 8080 of the container to port 8080 on the host machine, why would you expect port 8080 on the host machine to not be exposed?

I don't think you understand what mapping and opening a port does if you think that when you tell docker to expose a port on the host machine that it's a bug or security issue when docker then exposes a port on the host machine...

docker supports many network types, vlans, host attached, bridged, private, etc. There are many options available to run your containers on if you don't want to expose ports on the host machine. A good place to start: If you don't want ports exposed on the host machine then probably should not start your docker container up with host networking and a port exposed on that network...

Regardless of that, your container host machines should be behind a load balancer w/ firewall and/or a dedicated firewall, so containers poking holes (because you told them to and then got mad at it) shouldn't be an issue

Re: A story on home server security

#233

Post by jeroenhd » Sun, Jan 05, 2025, 9:35 PM UTC

rpadovani wrote: post #8

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

Between MongoDB running without a password by default and quick start guides brushing over anything security related, the industry can use a more security-conscious mindset.

However, security is hard and people will drop interest in your project if it doesn't work automatically within five minutes.

The hard part is at what experience level the warnings can stop. Surely developer documentation doesn't need the "docker exposes ports by default" lesson repeated every single time, but there are a _lot_ of "beginner" tutorials on how to set up software through containers that ignore any security stuff.

For instance, when I Google "how to set up postgres on docker", this article was returned, clearly aimed at beginners: https://medium.com/@jewelski/quickly-set-up-a-local-postgres... This will setup a simply-guessable password on both postgres and pgadmin, open from the wider network without warning. Not so bad when run on a VM or Linux computer, quite terrible when used for a small project on a public cloud host.

The problems caused by these missing warnings are almost always the result of lacking knowledge about how Docker configures it networks, or how (Linux) firewalls in general work. However, most developers I've met don't know or care about these details. Networking is complicated beyond the bare basics and security gets in the way.

With absolutely minimal impact on usability, all those guides that open ports to the entire internet can just prepend 127.0.0.1 to their port definitions. Everyone who knows what they're doing will remove them when necessary, and the beginners need to read and figure out how to open ports if they do want them exposed to the internet.

Re: A story on home server security

#234

Post by packtreefly » Sun, Jan 05, 2025, 9:39 PM UTC

gus_ wrote: post #202

The article misses one critical point in these attacks: practically all these attacks require downloading remote files to the server once they gain access, using curl, wget or bash. Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless. Also these cryptominers are usually dropped to /tmp, /var/tmp or /dev/shm. They need internet access to work, so agai…

> Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.

Any advice what that looks like for a docker container? My border firewall isn't going to know what binary made the request, and I'm not aware of per-process restrictions of that kind

Re: A story on home server security

#235

Post by rane » Sun, Jan 05, 2025, 9:43 PM UTC

_heimdall wrote: post #205

bennythomsson wrote: post #168

Earlier quoted context omitted.

What kind of "hosting service" are you referring to? Just run wireguard on the home server, or your router, and that's it. No more infra required.

I meant to say hosted service there, I.e. running a wireguard server to negotiate the VPN connections. The main reason I haven't jumped into hosting wireguard rather than using Tailscale is mainly because I reach for Tailscale to avoid exposing my home server to the public internet.

What could be the issue with exposing WireGuard at a random port to the public internet?

It works over UDP so it doesn't even send any acknowledgement or error response to unauthenticated or non-handshake packets.

Re: A story on home server security

#236

Post by 63stack » Sun, Jan 05, 2025, 9:46 PM UTC

globular-toast wrote: post #34

phoronixrly wrote: post #25

Earlier quoted context omitted.

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

I feel like you and grandparent are the only people who read the article, because I'm wondering the same thing.

The article never properly explains how the attack happened. Having a port exposed to the internet on any container is a remote execution vulnerability? What? How? Nobody would be using docker in that case.

The article links to a blog post as a source on the vulnerability, but the article is a general "how to secure" article, there is nothing about remote code execution.

Re: A story on home server security

#237

Post by 63stack » Sun, Jan 05, 2025, 9:47 PM UTC

echelon_musk wrote: post #51

globular-toast wrote: post #34

Earlier quoted context omitted.

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

Also from TFA: > it was exposed to the internet, with open ports in the router firewall Upvoted because you're right that the comments in this thread have nothing to do with what happened here. The story would have been no different if OP had created an Alpine Linux container and exposed SSH to the internet with SSH password authentication enabled and a weak password. It's nothing to do with Docker's firewalling.

>The story would have been no different if OP had created an Alpine Linux container and exposed SSH to the internet with SSH password authentication enabled and a weak password.

What? The story would have been VERY different, obviously that's asking for trouble. Opening a port to your database running in a docker container is not a remote execution vulnerability, or if it is, the article is failing to explain how.

Re: A story on home server security

#238

Post by 63stack » Sun, Jan 05, 2025, 9:50 PM UTC

phoronixrly wrote: post #92

globular-toast wrote: post #34

Earlier quoted context omitted.

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

Are you sure about that? Last I checked pg admins had command execution on the DB host, as well as FS r/w and traversal. See https://www.postgresql.org/docs/current/sql-copy.html#id-1.9... Specifically the `filename` and `PROGRAM` parameters. And that is documented expected out of the box behaviour without even looking for an exploit...

It's funny that you said TFA a few comments earlier, because you seem to have not read the article either, or are making some great leaps here.

If the break in happened as you would explain the article would also mention that:

* the attacker gained access to the postgres user or equally privileged user

* they used specific SQL commands to execute code

* would have not claimed the vulnerability was about docker containers and exposed ports

And the take away would not be "be careful with exposing your home server to the internet", but would be "anyone with admin privileges to postgres is able to execute arbitrary code".

Re: A story on home server security

#239

Post by sieabahlpark » Sun, Jan 05, 2025, 9:56 PM UTC

Manouchehri wrote: post #105

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.

Another option is using Cloudflare Tunnels (`cloudflared`), and stacking Cloudflare Access on top (for non-public services) to enforce authentication.

[dead]

Re: A story on home server security

#240

Post by sieabahlpark » Sun, Jan 05, 2025, 9:57 PM UTC

9dev wrote: post #210

veyh wrote: post #125

Earlier quoted context omitted.

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.

Also, many people don’t remember that those zeros in between numbers in IPs can be slashed, so pinging 127.1 works fine. This is also the reason why my home network is a 10.0.0.0/24—don’t need the bigger address space, but reaching devices at 10.1 sure is convenient!

[dead]