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

141–150 of 287 posts

Re: A story on home server security

#141

Post by Timber-6539 »

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…

Not a security issue. Docker explain it very clearly on their documentation. https://docs.docker.com/engine/network/packet-filtering-fire...

If you have opened up a port in your network to the public, the correct assumption is to direct outside connections to your application as per your explicit request.

Re: A story on home server security

#142

Post by 6ak74rfy »

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 think it's a relatively small attack surface.

Plus, you can obfuscate that too by using a random port for Wireguard (instead of the default 51820): if Wireguard isn't able to authenticate (or pre-authenticate?) a client, it'll act as if the port is closed. So, a malicious actor/bot wouldn't even know you have a port open that it can exploit.

Re: A story on home server security

#143

Post by Volundr »

globular-toast wrote: post #32
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…

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

Do you not run firewalls on your internal facing machines to make sure they only have the correct ports exposed?

Security isn't just an at the edge thing.

Re: A story on home server security

#144

Post by smarx007 »

sigseg1v wrote: post #138
smarx007 wrote: post #42

Earlier quoted context omitted.

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.

TIL, thank you! I used such security groups with OpenStack and OCI but somehow didn't think about them in connection with EC2.

Re: A story on home server security

#145

Post by mschuster91 »

Cyph0n wrote: post #82
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…

There is a third option: enable the Docker socket and use Docker Compose as usual. https://github.com/containers/podman/blob/main/docs/tutorial...

Docker Compose would not prevent you from doing a "publish port to 0.0.0.0/0", it's not much more than a (very convenient) wrapper around "docker build" and "docker run".

And many if not as good as all examples of docker-compose descriptor files don't care about that. Images that use different networks for exposed services and backend services (db, redis, ...) are the rare exception.

Re: A story on home server security

#146

Post by Fnoord »

wl wrote: post #75
Fnoord wrote: post #43

Earlier quoted context omitted.

OpenSSH has no currently known flaws but in past it contained a couple. For example, the xz backdoor utilized OpenSSH and it has contained a remote vulnerability in past (around 2003). Furthermore, some people use password auth as well as weak (low entropy or reused, breached) passwords. Instead, only use public key authentication. And tarpit the mofos brute forcing SSH (e.g. with fail2ban). They always do it on IPv4…

Also, if you’re running SSH on a non-standard port, block Censys’ IP ranges. They port scan the entire internet constantly and bad actors use their scans to target their attacks. Once I did that, the number of attempted SSH logins went to zero pretty quickly.

Solid advice! I've had certain countries in my blocklist thus far, and now I have added Censys (I did not know that was the company behind Shodan). Now, I've also added the Tor exit node list as my blocklist. Since nothing good comes from any of these. I used this blocklist for the latter [1] (the Censys ranges I just did manually, as it is only 12 entries in total).

[1] https://github.com/7c/torfilter

Re: A story on home server security

#147

Post by diggan »

0xCMP wrote: post #133
diggan wrote: post #98

Earlier quoted context omitted.

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

> that means you need to run NixOS for that to work

Does it? I'm pretty sure you're able to run Nix (the package manager) on Arch Linux for example, I'm also pretty sure you can do that on things like macOS too but that I haven't tested myself.

Or maybe something regarding this has changed recently?

Re: A story on home server security

#148

Post by Cyph0n »

mschuster91 wrote: post #145
Cyph0n wrote: post #82

Earlier quoted context omitted.

There is a third option: enable the Docker socket and use Docker Compose as usual. https://github.com/containers/podman/blob/main/docs/tutorial...

Docker Compose would not prevent you from doing a "publish port to 0.0.0.0/0", it's not much more than a (very convenient) wrapper around "docker build" and "docker run". And many if not as good as all examples of docker-compose descriptor files don't care about that. Images that use different networks for exposed services and backend services (db, redis, ...) are the rare exception.

Are you sure about that? Because I was under the impression that these firewall rules are configured by Docker. So if you use Docker Compose with Podman emulating the Docker socket, this shouldn’t happen.

Maybe someone more knowledgeable can comment.

Re: A story on home server security

#149

Post by diggan »

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…

> We didn't make the guides better

That sucks, because that means anything built not to that standard (which I guess is a US one?) could lead the person to hurt themselves/the house.

One doesn't exclude the other, and most likely both are needed if you're aiming to actually eliminate the problem as well as you can.

Re: A story on home server security

#150

Post by diggan »

kQq9oHeAz6wLLS wrote: post #107
malfist wrote: post #62

Earlier quoted context omitted.

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.

If we're being pedantic, then I'd say "old stud finders" are still being sold (second hand for example), so "every stud finder for sale these days" isn't correct either.

Best to just say "most" or "some" to cover all corner cases :)

Post reply on HN