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

81–90 of 287 posts

Re: A story on home server security

#81

Post by somebehemoth »

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…

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

Re: A story on home server security

#82

Post by Cyph0n »

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…

There is a third option: enable the Docker socket and use Docker Compose as usual.

https://github.com/containers/podman/blob/main/docs/tutorial...

Re: A story on home server security

#83

Post by coder543 »

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.

What does swarm actually do better for a single-node, single-instance deployment? (I have no experience with swarm, but on googling it, it looks like it is targeted at cluster deployments. Compose seems like the simpler choice here.)

Re: A story on home server security

#84

Post by geye1234 »

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

Re: A story on home server security

#85

Post by Raqbit »

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…

You can install docker's compose plugin, and podman is able to use it via "podman compose": https://docs.podman.io/en/stable/markdown/podman-compose.1.h...

Re: A story on home server security

#87

Post by gobblegobble2 »

> 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 lesson was learned here.

Re: A story on home server security

#88

Post by evantbyrne »

coder543 wrote: post #83
evantbyrne wrote: post #78

Earlier quoted context omitted.

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.

What does swarm actually do better for a single-node, single-instance deployment? (I have no experience with swarm, but on googling it, it looks like it is targeted at cluster deployments. Compose seems like the simpler choice here.)

Swarm works just as well in a single host environment. It is very similar to compose in semantics, but also does basic orchestration that you would have to hack into compose, like multiple instances of a service and blue/green deployments. And then if you need to grow later, it can of course run services on multiple hosts. The main footgun is that the Swarm management port does not have any security on it, so that needs to be locked down either with rove or manual ufw config.

Re: A story on home server security

#89

Post by pahae »

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.

Quadlets are pretty nice but require podman > 4.4 to function properly. Debian 12, for example, still only has podman ~4.3 in its repos.

Re: A story on home server security

#90

Post by znpy »

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 avoid most docker problems by running unprivileged containers via rootless podman, on a rocky-linux based host with selinux enabled.

At this point docker should be considered legacy technology, podman is the way to go.

Post reply on HN