Hacker News Reader

Comment by SamuelAdams | Hacker News Reader

What are some realistic, self hosted mitigation strategies for defending against these attacks?

IMO, you shouldn't do anything special. They're all very low-skill automated attacks. Just design and deploy stuff well, do the basic stuff correctly before you make anything publicly accessible, and don't worry about the noise. If you're doing things properly, none of it will work. Whatever fancy thing anyone suggests to try to reduce the noise likely won't slow down any actual determined human attacker much, and will just cause you more hassle to deploy and maintain.

Updates as the other commenter says. Also isolation technology like docker containers, chroots, bsd jails, protections that systemd offers, or virtual machines. While not perfect, it means that the attackers must have the ability to chain exploits in order to break out of the compromised application to the rest of the host system.

Docker is great but it is easy to shoot yourself on the foot if you use it conveniently but don't actually understand it.

A common mistake is to publish the Docker ports unknowingly to all interfaces (e.g `5432:5432`), which makes your Docker container available to everyone. It is common to see this in Docker tutorials or pre-made Docker Compose files. Coupled with UFW, it may give you a false sense of security because Docker manages its own iptables rules.

I do make the habit of not expose ports and just use reverse proxy for the container. Of course, you will need a bridged network between the reverse proxy container and the target container, but that's fine. I'm sure there is more clever ways around that.

I prefer to run the webserver using systemd on the host so publishing the container port to 127.0.0.1 is enough for me.

Yes I've made this mistake with docker and UFW before :( Such a footgun.

Nord Meshnet, ZeroTier, Cloudflare Tunnels.

Instead of exposing your applications externally, you create a private network that uses UDP hole punching.

This isn't completely self-hosted, as you need some server to auth / broadcast connection details with. Self-hosting might be possible on ZeroTier, but I'm not familiar enough to say for sure.

Yeah you can self host zerotier, there’s even quick docker for it.

Don't expose your services publicly unless it is necessary. If you're self-hosting services that are meant to be accessed only by you then consider accessing them exclusively over a VPN like Wireguard (Tailscale is nice) and firewall everything else.

Or, depending on practical constraints, even http simple auth via nginx/apache reverse proxy.

Yes, though I'd say _and_ not _or_. Just because you're using a VPN it doesn't mean you should drop all forms of authentication.

Well, I did mean or; sometimes just sticking httpd in front of the application with a user:pass over https is fine, and also much easier if the client can't run a VPN client or doesn't want to.

I am not aware of a vulnerability in popular web server software that affected a basic auth login screen for over a decade. Assuming you use a proper password and don't typo the domain and end up on someone who wants to specifically phish you through typo squatting, it's about as solid as SSH or Wireguard

They serve different use-cases but I wouldn't say that VPN is strictly better than HTTP auth or vice versa. Recommending to double up for a self-hosted little something, not a big target like 4chan or Gmail, is overkill

What I'm saying is that security is about layers. I agree with you, a VPN and HTTP auth is not apples to apples where one is better than the other.

Also, be sure your web server is not serving dotfiles/dotfolders (apart for a few legitimate reasons, ie .well-known).

Why? Code is open source and I don't check config changes into .git. Do you mean like .htpasswd which is already default disallowed (on web servers that make use of it in the first place; I think Nginx doesn't block it by default but also doesn't use it so it wouldn't grant any access)?

Update your software frequently.

But not too frequently

I’d rather update it too frequently and potentially bork something, than not update it frequently enough and potentially get pwned.

Use packages from a distribution like Debian and run unattended-upgrades or equivalent for the security-updates repository. They usually fix newly reported vulnerabilities in less than a day.

Tailscale is ridiculously easy to install and get running.

Reply on news.ycombinator.com