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

91–100 of 287 posts

Re: A story on home server security

#91

Post by smarx007 »

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…

Your understanding is correct, unfortunately. Not only that, the developers are also reluctant to make 127.0.0.1:####:#### the default in their READMEs and docker-compose.yml files because UsEr cOnVeNiEnCe, e.g. https://github.com/louislam/uptime-kuma/pull/3002 closed WONTFIX

Re: A story on home server security

#92

Post by phoronixrly »

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…

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...

Re: A story on home server security

#93

Post by yx827ha »

aaomidi wrote: post #49
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…

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.

I agree, Tailscale FTW! You didn't even need to integrate it with docker. Just add a subnet route and evening just works. It's a great product.

Re: A story on home server security

#94

Post by diggan »

gobblegobble2 wrote: post #87

> Fortunately, despite the scary log entries showing attempts to change privileges and delete critical folders, it seemed that all the malicious activity was contained within the container. OP can't prove that. The only way is to scrap the server completely and start with a fresh OS image. If OP has no backup and ansible repo (or anything similar) to configure a new home server quickly, then I guess another valuable…

Not 100% what you mean with "scrapping" the server, you suggest just a re-install OS? I'd default to assuming the hardware itself is compromised somehow, if I'm assuming someone had root access. If you were doing automated backups from something you assume was compromised, I'm not sure restoring from backups is a great idea either.

Re: A story on home server security

#95

Post by smarx007 »

evantbyrne wrote: post #78
coder543 wrote: post #68

Earlier quoted context omitted.

Your original solution of binding to 127.0.0.1 generally seems fine. Also, if you're spinning up a web app and its supporting services all in Docker, and you're really just running this on a single $3/mo instance... my unpopular opinion is that docker compose might actually be a fine choice here. Docker compose makes it easy for these services to talk to each other without exposing any of them to the outside network…

You should try swarm. It solves a lot of challenges that you would otherwise have while running production services with compose. I built rove.dev to trivialize setup and deployments over SSH.

Interesting, in my mind Swarm was more or less dead and the next step after docker+compose or podman+quadlet was k3s. I will check out Rove, thanks!

Re: A story on home server security

#96

Post by pahae »

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…

Correct. This can be disabled [0] but you need to work around this then. Usually you can "just" use host-networking and manage iptable rules manually. Not pretty but in that case you at least know what's done to the system and iptables.

[0] https://docs.docker.com/engine/network/packet-filtering-fire...

Re: A story on home server security

#98

Post by diggan »

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…

> So what’s the ideal setup when using podman? Use compose anyway and hope it won’t be deprecated, or use SystemD as Podman suggests as a replacement for Compose?

After moving from bare to compose to docker-compose to podman-compose and bunch of things in-between (homegrown Clojure config-evaluators, ansible, terraform, make/just, a bunch more), I finally settled on using Nix for managing containers.

It's basically the same as docker-compose except you get to do it with proper code (although Nix :/ ) and as a extra benefit, get to avoid YAML.

You can switch the backend/use multiple ones as well, and relatively easy to configure as long as you can survive learning the basics of the language: https://wiki.nixos.org/wiki/Docker

Re: A story on home server security

#99

Post by Gud »

darkwater wrote: post #33
kibwen wrote: 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. 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.

We do, it's called FreeBSD. In my experience, many Linux distributions also qualify. To keep a modern *nix secure and up to date is simple.

Re: A story on home server security

#100

Post by smarx007 »

somebehemoth wrote: post #81
MortyWaves wrote: post #76

Earlier quoted context omitted.

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…

podman rootless running services with quadlet is not a bad start.

Is there a tool/tutorial that assumes that I already have a running docker compose setup instead of starting with some toy examples? Basically, I am totally excited about using systemd that I already have on my system instead of adding a new daemon/orchestrator but I feel that the gap between quadlet 101 and migrating quite a complex docker compose YAML to podman/quadlet is quite large.
Post reply on HN