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

171–180 of 287 posts

Re: A story on home server security

#171

Post by Mister_Snuggles »

rsolva wrote: post #135
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.

> - Missing feature; do not connect when on certain SSIDs.

I'm very surprised by this omission as this feature exists on the official iOS client.

Re: A story on home server security

#172

Post by jerf »

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.

Also a great way around code that tries to block you from hitting resources local to the box. Lots of code out there in the world blocking the specific address "127.0.0.1" and maybe if you were lucky "localhost" but will happily connect to 127.6.243.88 since it isn't either of those things. Or the various IPv6 localhosts.

Relatedly, a lot of systems in the world either don't block local network addresses, or block an incomplete list, with 172.16.0.0/12 being particularly poorly known.

Re: A story on home server security

#173

Post by libeclipse »

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.

You don't need NixOS to use Nix as a package manager/build system

Re: A story on home server security

#174

Post by queuebert »

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…

> Ironically enough even cybersecurity doesn't catch them for it, they are too busy harassing other teams about out of date versions of services that are either not vulnerable, or already patched but their scanning tools don't understand that.

Wow, this really hits home. I spend an inordinate amount of time dealing with false positives from cybersecurity.

Re: A story on home server security

#175

Post by smarx007 »

Cyph0n wrote: post #148
mschuster91 wrote: post #145

Earlier quoted context omitted.

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.

I think you are both correct, see https://news.ycombinator.com/item?id=42602429 - the socket would still listen on 0.0.0.0 but podman would not punch holes.

Re: A story on home server security

#177

Post by adriancr »

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…

securing is straightforward, too bad it's not by default: https://docs.docker.com/engine/network/packet-filtering-fire...

Re: A story on home server security

#178

Post by bluedino »

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?

> This is pretty common, developers are focused on making things that work.

True, but over the last twenty years, simple mistakes by developers have caused so many giant security issues.

Part of being a developer now is knowing at least the basics on standard security practices. But you still see people ignoring things as simple as SQL injection, mainly because it's easy and they might not even have been taught otherwise. Many of these people can't even read a Python error message so I'm not surprised.

And your cybersecurity department likely isn't auditing source code. They are just making sure your software versions are up to date.

Re: A story on home server security

#179

Post by bennythomsson »

depaulagu wrote: post #169
j_bum wrote: post #164

Ok - curious if anyone can provide some feedback for me on this. I am running Immich on my home server and want to be able to access it remotely. I’ve seen the options of using wireguard or using a reverse proxy (nginx) with Cloudflare CDN, on top of properly configured router firewalls, while also blocking most other countries. Lots of this understanding comes from a YouTube guide I watched [0]. From what I understa…

Piggybacking on your request, I would also like feedback. I also run some services on my home computer. The setup I'm currently using is a VPN (Wireguard) redirecting a UDP port from my router to my PC. Although I am a Software Engineer, I don't know much about networks/infra, so I chose what seemed to me the most conservative approach.

To both of you, wireguard is the way to go.

So, parent poster: yes, you are doing it right.

Grandparent: Use a VPN, close everything else.

Re: A story on home server security

#180

Post by j_bum »

bennythomsson wrote: post #179
depaulagu wrote: post #169

Earlier quoted context omitted.

Piggybacking on your request, I would also like feedback. I also run some services on my home computer. The setup I'm currently using is a VPN (Wireguard) redirecting a UDP port from my router to my PC. Although I am a Software Engineer, I don't know much about networks/infra, so I chose what seemed to me the most conservative approach.

To both of you, wireguard is the way to go. So, parent poster: yes, you are doing it right. Grandparent: Use a VPN, close everything else.

Thanks, Benny!
Post reply on HN