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

241–250 of 287 posts

Re: A story on home server security

#241

Post by 63stack »

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…

You don't need any of this, and the article is completely bogus, having a port forwarded to a database in a container is not a security vulnerability, unless the database has a vulnerability. The article fails to explain how they actually got remote code execution, and blames it on some docker container vulnerability, and links to a random article as a source that has nothing to do with what he is claiming in the article.

What you have to understand is that having an immich instance on the internet is only a security vulnerability if immich itself has a vulnerability in it. Obviously, this is a big if, so if you want to protect against this scenario, you need to make sure only you can access this instance, and you have a few options here that don't involve 3rd parties like cloudflare. You can make it listen only on the local network, and then use ssh port tunneling, or you can set up a vpn.

Cloudflare has been spamming the internet with "burglars are burgling in the neighbourhood, do you have burglar alarms" articles, youtube is also full of this.

Re: A story on home server security

#242

Post by smarx007 »

jeroenhd wrote: post #229
smarx007 wrote: post #184

Earlier quoted context omitted.

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…

UFW and Docker don't work well together. Both of them call iptables (or nftables) in a way that assumes they're in control of most of the firewall, which means they can conflict or simply not notice each other's rules. For instance, UFW's rules to block all traffic get overriden by Docker's rules, because there is no active block rule (that's just the default, normally) and Docker just added a rule. UFW doesn't know…

> you can prevent container from being publicly reachable by just not binding them to any public ports

well, that's what I opened with: https://news.ycombinator.com/item?id=42601673

problem is, I was told in https://news.ycombinator.com/item?id=42604472 that this protection is easier to work around than I imagined...

Re: A story on home server security

#243

Post by jcgl »

Fnoord wrote: post #146
wl wrote: post #75

Earlier quoted context omitted.

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

I hope you'll reconsider your stance on Tor exit nodes; many people use the Tor network to avoid censorship or even just bolster their own privacy. Blacklisting users on the basis of their Tor usage is hostile to their goals of privacy and anti-censorship.

Re: A story on home server security

#244

Post by notatoad »

kibwen wrote: post #31
tossandthrow wrote: post #13

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…

>Unlike welding or diving, there is no inherent physical risk to life and limb to running a server.

good news! there is no inherent risk to life or limb because you left your server exposed. As OP discovered, you might come back to find it running a crypto miner. and that's just really not that big of a deal. maybe we're not all shit at what we do, but rather we have appropriately valued the seriousness of the risks involved, and made the decision that locking everything down to be impossible to hack isn't actually worth the trade-offs to usability, convenience, and freedom.

you can leave your iPad running, unattended, and unadministered for 20 years if that's what you wanted, and come back to find it un-pwned.

Re: A story on home server security

#245

Post by rpcope1 »

wutwutwat wrote: post #232
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…

From the linked issue > by running docker images that map the ports to my host machine If you start a docker container and map port 8080 of the container to port 8080 on the host machine, why would you expect port 8080 on the host machine to not be exposed? I don't think you understand what mapping and opening a port does if you think that when you tell docker to expose a port on the host machine that it's a bug or s…

I think the unintuitive thing is that by "port mapping", Docker is doing DNAT which doesn't trigger the input firewall rules. Unless you're relatively well versed in the behavior of iptables or notables, you probably expect the "port mapping" to work like a regular old application proxy (which would obey a firewall rules blocking all inputs) and not use NAT and firewall rules (and all of the attendant complexity that brings).

Re: A story on home server security

#246

Post by _heimdall »

rane wrote: post #235
_heimdall wrote: post #205

Earlier quoted context omitted.

I meant to say hosted service there, I.e. running a wireguard server to negotiate the VPN connections. The main reason I haven't jumped into hosting wireguard rather than using Tailscale is mainly because I reach for Tailscale to avoid exposing my home server to the public internet.

What could be the issue with exposing WireGuard at a random port to the public internet? It works over UDP so it doesn't even send any acknowledgement or error response to unauthenticated or non-handshake packets.

There may not be an issue at all, I'm just gun shy about opening any ports publicly. I don't do networking often and have never focused on it enough to feel confident in my setup and maintenance.

Re: A story on home server security

#247

Post by lmaoguy »

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

Unless you want it publicly available and expect people to try and illegitimately access it, never expose it to the internet.

Re: A story on home server security

#248

Post by spr-alex »

smarx007 wrote: post #216
spr-alex wrote: post #212

Earlier quoted context omitted.

-p 127.0.0.1: might not offer all of the protections the way you would expect, and is arguably a bug in dockers firewall rules they're failing to address. they choose to instead say hey we dont protect against L2, and have an open issue here: https://github.com/moby/moby/issues/45610 . this secondary issue with docker is a bit more subtle, it's that they don't respect the bind address when they do forwarding into the…

What about cloud VMs? I would love to read more about "they don't respect the bind address when they do forwarding into the container" and "machines one hop away can forward packets into the docker container" if you could be so kind! Upd: thanks for a link, looks quite bad. I am now thinking that an adjacent VM in a provider like Hetzner or Contabo could be able to pull it off. I guess I will have to finally switch r…

i cant speak to hetzner, contabo. i have tested this attack on aws, gcp a while back and their L2 segmentation was solid. VMs/containers should be VLANd across customers/projects on most mature providers. On some it may not be though.

if theres defense in depth it may be worth checking out L2 forwarding within a project for unexpected pivots an attacker could use. we've seen this come up in pentests

I work on SPR, we take special care in our VPN to avoid these problems as well, by not letting docker do the firewalling for us. (one blog post on the issue: https://www.supernetworks.org/pages/blog/docker-networking-c...).

as an aside there's a closely related issue with one-hop attacks with conntrack as well, that we locked down in October.

Re: A story on home server security

#249

Post by tommy_axle »

matharmin wrote: post #10

I think I'm missing something here - what is specific about Docker in the exploit? Nowhere is it mentioned what the actual exploit was, and whether for example a non-containerized postgres would have avoided it. Should the recommendation rather be "don't expose anything from your home network publically unless it's properly secured"?

This is one that can sneak up on you even when you're not intentionally exposing a port to the internet. Docker manages iptables directly by default (you can disable it but the networking between compose services will be messed up). Another common case this can bite you is if using an iptables front-end like ufw and thinking you're exposing just the application. Then unless you bind to localhost then Posgres in this case will be exposed. My recommendation is to review iptables -L directly and where possible use firewalls closer to the perimeter (e.g. the one from your vps provider) instead of solely relying on iptables on the same node

Re: A story on home server security

#250

Post by downrightmike »

Shank wrote: post #79

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

Good time to make sure UPnP is not enabled. Its an authenticationless protocol. Yeah, you read that right, no auth needed.
Post reply on HN