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

111–120 of 287 posts

Re: A story on home server security

#111

Post by smarx007 »

diggan wrote: post #110
znpy wrote: post #90

Earlier quoted context omitted.

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.

I think podman does not punch holes in the firewall as opposed to docker. I.e., to expose a container on port 8080 on the WAN in podman, you need to both expose 8080:8080 and use, for example, firewalld to open port 8080. Which I consider a correct behaviour.

Re: A story on home server security

#112

Post by ocdtrekkie »

cynicalsecurity wrote: post #2

> None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet. This is like IT security 101. > A quick IP search revealed that it was registed with a Chinese ISP and located in the Russian Federation. Welcome to the Internet. Follow me. Always block China and Russia from any of your services. You are never going to need them and the only thing tha…

Yes, but go further: Are you ever using your home server outside your own country? If the answer is no, block everything but your country. You can remove the vast majority of your attack surface by just understanding where you need to be exposed.

Re: A story on home server security

#113

Post by diggan »

sgarland wrote: post #104
diggan wrote: post #94

Earlier quoted context omitted.

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.

I'm guessing it's an automated attack, where it found running services and then threw payloads at it until it got something. Once they're there, since docker isn't a real security barrier, I'd consider it all bets off.

Especially when it comes to my home network, I would rather be safe than sorry. How would you even begin to investigate a rootkit since it can clean up after itself and basically make itself invisible?

Particularly when it comes to Kinsing attacks, as there seem to been rootkits detected in tandem with it, which is exactly what OP got hit by it seems (although they could only see the coinminer).

Re: A story on home server security

#114

Post by dboreham »

diggan wrote: post #110
znpy wrote: post #90

Earlier quoted context omitted.

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.

I think it's more about whether traffic is bound to localhost or a routable interface. Podman has different behavior vs Docker.

Re: A story on home server security

#115

Post by heresie-dabord »

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…

> as an industry, we should make a better job in providing solid foundations.

Here is the fundamental confusion: programming is not an industry, it is a (ubiquitous) type of tooling used by industries.

Software itself is insecure in its tooling and in its deployment. So we now have a security industry struggling to improve software.

Some software companies are trying to improve but software in the $cloud is just as big a mess as software on work devices and personal devices.

Re: A story on home server security

#116

Post by diggan »

smarx007 wrote: post #111
diggan wrote: post #110

Earlier quoted context omitted.

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.

I think podman does not punch holes in the firewall as opposed to docker. I.e., to expose a container on port 8080 on the WAN in podman, you need to both expose 8080:8080 and use, for example, firewalld to open port 8080. Which I consider a correct behaviour.

Sure, but the issue here wasn't because the default behavior surprised OP. OP needed a service that was accessible from a remote endpoint, so they needed to have some connection open. They just (for some reason) chose to do it over public internet instead of a private network.

But regardless of software used, it would have led to the same conclusion, a vulnerable service running on the open internet.

Re: A story on home server security

#117

Post by ocdtrekkie »

Docker is a terrible self-hosting tool reason #4056. Let's give everyone a footgun and recommend they use it at work and their house.

Especially with a tool you don't have an enterprise class firewall in front of, security needs to be automatic, not afterthought.

Re: A story on home server security

#118

Post by zenoprax »

elashri wrote: 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.

I use HAProxy on PFSense to expose a home media server (among other services) for friends to access. It runs on a privileged LXC (because NFS) but as an unprivileged user.

Is this reckless? Reading through all this makes me wonder if SSHFS (instead of NFS) with limited scope might be necessary.

Re: A story on home server security

#119

Post by diggan »

V__ wrote: post #23
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…

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.

> if a container has to be exposed to do so behind a reverse proxy.

I see this mentioned everywhere in the comments here but they seem to miss that the author explicitly wanted it to be exposed, and the compromise would have happened regardless if the traffic went directly to the container or via a reverse proxy.

The proper fix for OP is to learn about private networks, not put a reverse proxy in front and still leave it running on the public internet...

Re: A story on home server security

#120

Post by ocdtrekkie »

dijit wrote: post #54
bluedino wrote: post #30

Earlier quoted context omitted.

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, t…

This is pretty common, developers are focused on making things that work. Sysadmins were always the ones who focused on making things secure, and for a bunch of reasons they basically don’t exist anymore. EDIT: what guidelines did I break?

I suspect you'll find a lot of intersection between the move to "devops" outfits who "don't need IT anymore" and "there's a lot more security breaches now", but hey, everyone's making money so who cares?
Post reply on HN