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

71–80 of 287 posts

Re: A story on home server security

#71

Post by HomeDeLaPot »

rane wrote: post #47
AlgebraFox wrote: post #9

Tailscale is a great solution for this problem. I too run homeserver with Nextcloud and other stuff, but protected behind Tailscale (Wireguard) VPN. I can't even imagine exposing something like my family's personal data over internet, no matter how convenient it is. But I sympathize with OP. He is not a developer and it is sad that whatever software engineers produce is vulnerable to script kiddies. Exposing database…

What do you need Tailscale for? Why isn't Wireguard enough?

The author mentioned closing their VPN port so people would stop trying to break in, but this also cut off the author's access.

Tailscale allows you to connect to your home network without opening a port to allow incoming connections.

Re: A story on home server security

#72

Post by Fnoord »

akerl_ wrote: post #61
Fnoord wrote: post #50

Earlier quoted context omitted.

There's no good reason a VM or container on Hetzner cannot use a firewall like IPTables. If that makes the service too expensive you increase cost or otherwise lower resources. A firewall is a very simple, essential part of network security. Every simple IoT device running Linux can run IPTables, too.

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.

Re: A story on home server security

#73

Post by fullspectrumdev »

WaxProlix wrote: post #60
fullspectrumdev wrote: post #53

Earlier quoted context omitted.

You absolutely can. Have you a credit card and a web browser? You can buy all sorts of heavy machinery and have it shipped to your door!

You've introduced a new element here - the credit card. And if you did have the money and whimsy it'd still show up with (regulated, mandatory, industry-standardized) safety documentation.

I guess that depends where you order from. You can get some crazy machines from Alibaba/Aliexpress and the “documentation” they come with is usually… well it leaves a lot to be desired.

Re: A story on home server security

#74

Post by Fnoord »

smarx007 wrote: post #65
Fnoord wrote: post #50

Earlier quoted context omitted.

There's no good reason a VM or container on Hetzner cannot use a firewall like IPTables. If that makes the service too expensive you increase cost or otherwise lower resources. A firewall is a very simple, essential part of network security. Every simple IoT device running Linux can run IPTables, too.

I guess you did not read the link I posted initially. When you set up a firewall on a machine to block all incoming traffic on all ports except 443 and then run docker compose exposing port 8000:8000 and put a reverse proxy like caddy/nginx in front (e.g. if you want to host multiple services on one IP over HTTPS), Docker punches holes in the iptables config without your permission, making both ports 443 and 8000 ope…

Either you run a VM inside the VM or indeed two VMs. Jumphost does not require a lot of resources.

The problem here is the user does not understand that exposing 8080 on external network means it is reachable by everyone. If you use an internal network between database and application, cache and application, application and reverse proxy, and put proper auth on reverse proxy, you're good to go. Guides do suggest this. They even explain LE for reverse proxy.

Re: A story on home server security

#75

Post by wl »

Fnoord wrote: post #43
immibis wrote: post #17

Every server gets constantly probed for SSH. Since half the servers on the Internet haven't been taken over yet, it doesn't seem like SSH has significant exploits (well, there was that one signal handler race condition). Unless you're trying to do one of those designs that cloud vendors push to fully protect every single traffic flow, most people have some kind of very secure entry point into their private network an…

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.

Re: A story on home server security

#76

Post by MortyWaves »

anthropodie wrote: post #40
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…

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 suggests as a replacement for Compose?

Re: A story on home server security

#77

Post by phartenfeller »

A lot of people comment about Docker firewall issues. But it still doesn't answer how an exposed postgres instance leads to arbitrary code execution.

My guess is that the attacker figured out or used the default password for the superuser. A quick lookup reveals that a pg superuser can create extension and run some system commands.

I think the takeaway here is that the pg image should autogenerate a strong password or not start unless the user defines a strong one. Currently it just runs with "postgres" as the default username and password.

Re: A story on home server security

#78

Post by evantbyrne »

coder543 wrote: post #68
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…

Your original solution of binding to 127.0.0.1 generally seems fine. Also, if you're spinning up a web app and its supporting services all in Docker, and you're really just running this on a single $3/mo instance... my unpopular opinion is that docker compose might actually be a fine choice here. Docker compose makes it easy for these services to talk to each other without exposing any of them to the outside network…

You should try swarm. It solves a lot of challenges that you would otherwise have while running production services with compose. I built rove.dev to trivialize setup and deployments over SSH.

Re: A story on home server security

#79

Post by Shank »

For all intents and purposes, the only ports you should ever forward are ones that are explicitly designed for being public facing, like TLS, HTTP, and SSH. All other ports should be closed. If you’re ever reaching for DMZ, port forwarding, etc., think long and hard about what you’re doing. This is a perfect problem for Tailscale or WireGuard. You want a remote database? Tailscale.

I even get a weird feeling these days with SSH listening on a public interface. A database server, even with a good password/ACLs, just isn’t a great safe idea unless you can truly keep on top of all security patches.

Re: A story on home server security

#80

Post by luismedel »

AlgebraFox wrote: post #9

Tailscale is a great solution for this problem. I too run homeserver with Nextcloud and other stuff, but protected behind Tailscale (Wireguard) VPN. I can't even imagine exposing something like my family's personal data over internet, no matter how convenient it is. But I sympathize with OP. He is not a developer and it is sad that whatever software engineers produce is vulnerable to script kiddies. Exposing database…

There are a lot of vulnerability categories. Memory unsafety is the origin of some of them, but not all.

You could write a similar rant about any development stack and all your rants would be 100% unrelated with your point: never expose a home-hosted service to the internet unless you seriously know your shit.

Post reply on HN