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

61–70 of 287 posts

Re: A story on home server security

#61

Post by akerl_ »

Fnoord wrote: post #50
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…

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.

Re: A story on home server security

#62

Post by malfist »

johnchristopher wrote: post #36
rpadovani wrote: post #8

> "None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet." This prompts a reflection about, as an industry, we should make a better job in providing solid foundations. 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 aroun…

> 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 poorly written tutorial.

Re: A story on home server security

#63

Post by akerl_ »

lopkeny12ko wrote: post #55
mattrighetti wrote: post #29

Earlier quoted context omitted.

> They are not memory safe by design I'm aware of that, but the C/C++ thing seemed more like a rant, hence my question. I've searched up the malware and it doesn't seem to use memory exploitation. Rust is not going to magically protect you against any security issue caused by cloud misconfiguration.

What is the point you're trying to make here? Are you waiting for some malware that exploits a buffer overrun to infect you before conceding that C/C++ is a terrible choice for memory-safe code?

It just seems totally unrelated to this post.

Re: A story on home server security

#64

Post by daneel_w »

"None of the database guides I followed had warned me about the dangers of exposing a docker containerized database to the internet."

Really? Nor any Docker guides warning in general about exposing a container to the Internet?

Re: A story on home server security

#65

Post by smarx007 »

Fnoord wrote: post #50
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…

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 open on your machine.

@globular-toast was not suggesting an iptables setup on a VM, instead they are suggesting to have a firewall on a totally different device/VM than the one running docker. Sure, you can do that with iptables and /proc/sys/net/ipv4/ip_forward (see https://serverfault.com/questions/564866/how-to-set-up-linux...) but that's a whole new level of complexity for someone who is not an experienced network admin (plus you now need to pay for 2 VMs and keep them both patched).

Re: A story on home server security

#66

Post by malfist »

paulnpace wrote: post #35

I had ~500 kbps sustained attacks against my residential ISP for years. I learned how to do everything through SSH - it is really an incredible Swiss Army knife of a tool.

I remember working at a non-tech company and their firewall blocked anything not on port 22, 80 and 443. I got real good at port forwarding with ssh.

Re: A story on home server security

#67

Post by smarx007 »

aaomidi wrote: post #49
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…

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.

I would love to read a write-up on that! Are you doing something like https://tailscale.com/blog/docker-tailscale-guide ?

Re: A story on home server security

#68

Post by coder543 »

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…

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 unless you intentionally set up a port binding for those services in the compose file.

Re: A story on home server security

#69

Post by dfsegoat »

malfist wrote: post #59
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…

Checklist security at it's finest. My team where I work is responsible for sending frivolous newsletters via email and sms to over a million employees. We use an OTP for employees to verify they gave us the right email/phone number to send them to. Security sees "email/sms" and "OTP" and therefor, tickets us at the highest "must respond in 15 minutes" priority ticket every time an employee complains about having lost…

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.

Re: A story on home server security

#70

Post by jpc0 »

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…

It's also common practice to do what everyone here recommends and out things behind a firewall.

The seperation of control and function has been a security practice for a long time.

Port 80 and 443 can be open to the internet, and in 2024 whatever port wireguard uses. All other ports should only be accessible from the local network.

With VPS providers this isn't always easy to do. My preferred VPS provider. However provides a separate firewall which makes that easier.

Post reply on HN