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

101–110 of 287 posts

Re: A story on home server security

#101

Post by anthropodie »

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 supports kubernetes YAML or the quadlets option. It's fairly easy to convert docker-compose to one of these.

Nowaday I just ask genAI to convert docker-compose to one of the above options and it almost always works.

Re: A story on home server security

#102

Post by azthecx »

_heimdall wrote: post #58
rane wrote: post #47

Earlier quoted context omitted.

What do you need Tailscale for? Why isn't Wireguard enough?

There's nothing wrong with wireguard at all if you already have the hosting service available. The core value add for Tailscale is that they provide/host the service coordinating your wireguard network. If I'm not mistaken, there's a self-hosted alternative that let's you run the core of Tailscale's service yourself if you're interested in managing wireguard.

I believe you are referring to Headscale https://github.com/juanfont/headscale

Re: A story on home server security

#103

Post by Quizzical4230 »

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.

I'm still using systemd. Podman keeps telling to use quadlets :)

Re: A story on home server security

#104

Post by sgarland »

diggan wrote: post #94
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.

I think it’s reasonable to take a measured view of attacks. I doubt someone installing crypto miners has a hardware rootkit.

Re: A story on home server security

#105

Post by Manouchehri »

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.

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

Re: A story on home server security

#106

Post by diggan »

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.

FOSS alternative is to throw up a $5 VPS on some trusted host, then use Wireguard (FOSS FTW) to do basically exactly the same, but cheaper, without giving away control and with better privacy.

There is bunch of software that makes this easier than trivial too, one example: https://github.com/g1ibby/auto-vpn/

Re: A story on home server security

#107

Post by kQq9oHeAz6wLLS »

malfist wrote: post #62
johnchristopher wrote: post #36

Earlier quoted context omitted.

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

To your point, guides don't warn too much about electrical wires because code and practices makes it really hard to do. Code requires metal plates where electrical wires go through studs so you can't drill into them, and every stud finder in existence these days also detects AC behind them. We didn't make the guides better, we made the tradespeople make it so any novice can't burn down the house by not following a po…

> every stud finder in existence these days

Slightly pedantic point of order: you mean to say every stud finder for sale these days, not in existence, for the old stud finders still exist.

Okay, that's all. Carry on.

Re: A story on home server security

#108

Post by kibwen »

lopkeny12ko wrote: post #48
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…

What motivates this attitude? Software, like anything else, needs to be actively maintained. This is a positive sign of technology evolution and improvement over time. To expect to run some software for 20 years without needing to apply a single security patch is ridiculous, and probably exactly the attitude that caused the author to get himself in this situation.

> To expect to run some software for 20 years without needing to apply a single security patch is ridiculous

The whole point of my comment is that it's only "ridiculous" because of path dependency and the choices that we have made. There's no inherent need for this to be true, and to think otherwise is just learned helplessness.

Re: A story on home server security

#110

Post by diggan »

znpy wrote: post #90
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.

Would that actually save you in this case? OP had their container exposed to the internet, listening for incoming remote connections. Wouldn't matter in that case if you're running a unprivileged container, podman, rocky-linux or with selinux, since everything is just wide open at that point.
Post reply on HN