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

131–140 of 287 posts

Re: A story on home server security

#131

Post by sgarland »

diggan wrote: post #113
sgarland wrote: post #104

Earlier quoted context omitted.

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

For crypto miners, it’s pretty easy to tell if your servers are in your house. Even if they aren’t, if you have any kind of metrics collection, you’ll notice the CPU spike.

My general feeling is that if someone wants to install a hardware rootkit on my extremely boring home servers, it’s highly unlikely that I’ll be able to stop them. I can do best practices (like not exposing things publicly), but ultimately I can’t stop Mossad; on the other hand, I am an unlikely target for anything other than script kiddies and crypto miners.

Re: A story on home server security

#132

Post by number6 »

veyh wrote: post #125
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 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.

TIL I always thought it was /32

Re: A story on home server security

#133

Post by 0xCMP »

diggan wrote: post #98
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…

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

Of course, that means you need to run NixOS for that to work (which I also do everywhere) and there are networking problems with Docker/Podman in NixOS you need to address yourself. Whereas Docker "runs anywhere" these days.

Worth noting the tradeoffs, but I agree using Nix for this makes life more pleasant and easy to maintain.

Re: A story on home server security

#135

Post by rsolva »

acidburnNSA wrote: post #11

I really like the "VPN into home first" philosophy of remote access to my home IT. I was doing openvpn into my ddwrt router fortunately years, and now it's wireguard into openwrt. It's quite easy for me to vpn in first and then do whatever: check security cams, control house via home assistant, print stuff, access my zfs shared drive, run big scientific simulations or whatever on big computer, etc. The router VPN end…

I use WireGuard to access all in-home stuff as well, but there is one missing feature and one bug with the official WireGuard app for android that is inconvenient:

- Missing feature; do not connect when on certain SSIDs. - Bug: When the WG connection is active and I put my phone in Flightmode (which I do every night), it drains the battery from full to almost empty during the night.

Re: A story on home server security

#136

Post by 01HNNWZ0MV43FF »

Fnoord wrote: post #72
akerl_ wrote: post #61

Earlier quoted context omitted.

Docker by default modifies iptables rules to allow traffic when you use the options to launch a container with port options. If you have your own firewall rules, docker just writes its own around them.

I always have to define 'external: true' at the network. Which I don't do with databases. I link it to an internal network, shared with application. You can do the same with your web application, thereby only needing auth on reverse proxy. Then you use whitelisting on that port, or you use a VPN. But I also always use a firewall where OCI daemon does not have root access on.

I thought "external" referred to whether the network was managed by compose or not

Re: A story on home server security

#137

Post by thedanbob »

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…

I use docker compose for development because it's easy to spin up an entire project at once. Tried switching to podman compose but it didn't work out of the box and I wasn't motivated to fix it.

For "production" (my homelab server), I switched from docker compose to podman quadlets (systemd) and it was pretty straightforward. I actually like it better than compose because, for example, I can ensure a containers dependencies (e.g. database, filesystem mounts) are started first. You can kind of do that with compose but it's very limited. Also, systemd is much more configurable when it comes to dealing service failures.

Re: A story on home server security

#138

Post by sigseg1v »

smarx007 wrote: post #42
globular-toast wrote: post #32

Earlier quoted context omitted.

This is only an issue if you run Docker on your firewall, which you absolutely should not.

Ideally, yes. But in reality, this means that if you just want to have 1 little EC2 VM on AWS running Docker, you now need to create a VM, a VPC, an NLB/ALB in front of the VPC ($20/mo+, right?) and assign a public IP address to that LB instead. For a VM like t4g.nano, it could mean going from a $3/mo bill to $23/mo ($35 in case of a NAT gateway instead of an LB?) bill, not to mention the hassle of all that setup. He…

In AWS why would you need a NLB/ALB for this? You could expose all ports you want all day from inside the EC2 instance, but nobody is going to be able to access it unless you specifically allow those ports as inbound in the security group attached to the instance. In this case you'd only need a load balancer if you want to use it as a reverse proxy to terminate HTTPS or something.

Re: A story on home server security

#139

Post by calvinmorrison »

bluedino wrote: post #30
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…

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…

Turns out devsecops was just a layoff scheme for sysadmins

Re: A story on home server security

#140

Post by darkwater »

Gud wrote: post #99
darkwater wrote: post #33

Earlier quoted context omitted.

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.

Which would help exactly 0 in this scenario, where someone is exposing a port directly on the Internet. Also, FreeBSD is even more niche than Linux, I doubt it would stand the average user stress test.
Post reply on HN