Live data from Hacker News

A story on home server security

raniseth.com

181–190 of 287 posts

Re: A story on home server security

#181
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…

Reverse proxy is pretty good - you've isolated the machine from direct access so that is something.

I'm in the same boat. I've got a few services exposed from a home service via NGINX with a LetsEncrypt cert. That removes direct network access to your machine.

Ways I would improve my security:

- Adding a WAF (ModSecurity) to NGINX - big time investment!

- Switching from public facing access to Tailscale only (Overlay network, not VPN, so ostensibly faster). Lots of guys on here do this - AFAIK, this is pretty secure.

Reverse proxy vs. Overlay network - the proxy itself can have exploitable vulnerabilities. You should invest some time in seeing how nmap can identify NGINX services, and see if those methods can be locked down. Good debate on it here:

https://security.stackexchange.com/questions/252480/blocking...

Re: A story on home server security

#182
post #133

Earlier quoted context omitted.

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

If you configure your server(s) through nix and nix containers, then even without another host OS you are basically running nix.

Re: A story on home server security

#183
post #49

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.

Important to note that, even if you use Tailscale, the firewall punching happens regardless, so you still have to make sure you either:

1. Have some external firewall outside of the Docker host blocking the port

2. Explicitly tell Docker to bind to the Tailscale IP only

Re: A story on home server security

#184

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

Do I understand the bottom two sections correctly? If I am using ufw as a frontend, I need to switch to firewalld instead and modify the 'docker-forwarding' policy to only forward to the 'docker' zone from loopback interfaces? Would be good if the page described how to do it, esp. for users who are migrating from ufw.

More confusingly, firewalld has a different feature to address the core problem [1] but the page you linked does not mention 'StrictForwardPorts' and the page I linked does not mention the 'docker-forwarding' policy.

[1]: https://firewalld.org/2024/11/strict-forward-ports

Re: A story on home server security

#185
post #72
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 always have to define 'external: true' at the network

That option has nothing to do with the problem at hand.

https://docs.docker.com/reference/compose-file/networks/#ext...

Re: A story on home server security

#186

Earlier quoted context omitted.

I feel this. Recently implemented a very trivial “otp to sign an electronic document” function in our app. Security heard “otp” and forced us through a 2 month security/architecture review process for this sign-off feature that we built with COTs libraries in a single sprint.

To be fair, I would also be alarmed, albeit not by OTP. "sign an electronic document" and "built with COTs libraries in a single sprint" is essentially begging for a security review. Signatures and their verification are non-trivial, case in point: https://news.ycombinator.com/item?id=42590307

Nobody said you shouldn’t do any due diligence. But 1 sprint vs 2 months of review really smells like ‘processes over people’. ;)

Re: A story on home server security

#187
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. As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server. I myself even wouldn't venture into exposing a server to the internet to…

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

There is quite a distance from

> stand up a server and leaving it running, unattended and unadministered

to, what was my proposition, maintain a server with active access from the internet.

Just what you describe I do myself: I have several home server running, but none accept incoming connections from the internet and the sec surface is much smaller.

Re: A story on home server security

#188
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…

Well, you are better off using Google Photos for securely accessing your photos over Internet. It is not a matter of securing it once, but one of keeping it secure all the time.

Re: A story on home server security

#189

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. As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server. I myself even wouldn't venture into exposing a server to the internet to…

You can't just click a few buttons and have industrial machinery - and when you DO get it there's a ton of safety warnings on and around it. And I don't agree with your fundamental premise; self owned computing should be for everyone. It shouldn't be - at least for some subset of basics - arcane or onerous.

Like you sibling I think you also misunderstand my statement: I do run local servers, but none a connected to the internet.

I definitely believe it is for all to have a NAS server, a home assistant, or a NUC setup to run some docker containers.

Just don't let them accept connections from the internet.

For most normal home setups it is actually super hard to make them accept incoming requests as you need to setup port forwarding or put the server in front of your router.

The default is that the server is not reachable from the internet.

Re: A story on home server security

#190

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. As a society we already have the structures setup: The author had been more than welcome to attend a course or a study programme in server administration that would prepare them to run their own server. I myself even wouldn't venture into exposing a server to the internet to…

And yet, OP here seems very comfortable with computer stuff. Can’t imagine about the regular joe buying a nas from synology and all the promesses made by the company.

These are not, per default, exposed to the internet.
Post reply on HN