4 ms·

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

by SamuelAdams 3y ago

azeemba 3y ago
Update your software frequently.
- klysm 3y ago
  But not too frequently
  - Tijdreiziger 3y ago
    I’d rather update it too frequently and potentially bork something, than not update it frequently enough and potentially get pwned.
mfashby 3y ago
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.
- ggpsv 3y ago
  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.
  - elashri 3y ago
    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.
    - ggpsv 3y ago
      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.
  - mfashby 3y ago
    Yes I've made this mistake with docker and UFW before :( Such a footgun.
ggpsv 3y ago
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.
- yjftsjthsd-h 3y ago
  Or, depending on practical constraints, even http simple auth via nginx/apache reverse proxy.
  - ggpsv 3y ago
    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.
    - yjftsjthsd-h 3y ago
      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.
    - Aachen 3y ago
      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
      - ggpsv 3y ago
        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.
achairapart 3y ago
Also, be sure your web server is not serving dotfiles/dotfolders (apart for a few legitimate reasons, ie .well-known).
- Aachen 3y ago
  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)?
wetbaby 3y ago
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.
- tamimio 3y ago
  Yeah you can self host zerotier, there’s even quick docker for it.
lazyeye 3y ago
Tailscale is ridiculously easy to install and get running.
ufmace 3y ago
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.
layer8 3y ago
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.

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

azeemba 3y ago

Update your software frequently.

klysm 3y ago
But not too frequently
- Tijdreiziger 3y ago
  I’d rather update it too frequently and potentially bork something, than not update it frequently enough and potentially get pwned.

mfashby 3y ago

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.

ggpsv 3y ago
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.
- elashri 3y ago
  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.
  - ggpsv 3y ago
    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.
- mfashby 3y ago
  Yes I've made this mistake with docker and UFW before :( Such a footgun.

ggpsv 3y ago

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.

yjftsjthsd-h 3y ago
Or, depending on practical constraints, even http simple auth via nginx/apache reverse proxy.
- ggpsv 3y ago
  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.
  - yjftsjthsd-h 3y ago
    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.
  - Aachen 3y ago
    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
    - ggpsv 3y ago
      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.

achairapart 3y ago

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

Aachen 3y ago
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)?

wetbaby 3y ago

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.

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

lazyeye 3y ago

Tailscale is ridiculously easy to install and get running.

ufmace 3y ago

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.

layer8 3y ago

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.