News for hackers. Stuff that matters.
Re:I looked through attacks in my access logs by SamuelAdams on Sunday January 28, 2024 @10:40AM (#39166737)
What are some realistic, self hosted mitigation strategies for defending against these attacks?
Re:I looked through attacks in my access logs by wetbaby on Sunday January 28, 2024 @12:08PM (#39167636)
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.

Re:I looked through attacks in my access logs by tamimio on Sunday January 28, 2024 @05:44PM (#39170614)
Yeah you can self host zerotier, there’s even quick docker for it.
Re:I looked through attacks in my access logs by mfashby on Sunday January 28, 2024 @10:59AM (#39166911)
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.
Re:I looked through attacks in my access logs by ggpsv on Sunday January 28, 2024 @11:14AM (#39167039)
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.

Re:I looked through attacks in my access logs by elashri on Sunday January 28, 2024 @11:28AM (#39167195)
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.
Re:I looked through attacks in my access logs by ggpsv on Sunday January 28, 2024 @11:55AM (#39167492)
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.
Re:I looked through attacks in my access logs by mfashby on Sunday January 28, 2024 @04:28PM (#39169981)
Yes I've made this mistake with docker and UFW before :( Such a footgun.
Re:I looked through attacks in my access logs by ggpsv on Sunday January 28, 2024 @11:03AM (#39166946)
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.
Re:I looked through attacks in my access logs by yjftsjthsd-h on Sunday January 28, 2024 @11:07AM (#39166973)
Or, depending on practical constraints, even http simple auth via nginx/apache reverse proxy.
Re:I looked through attacks in my access logs by ggpsv on Sunday January 28, 2024 @11:17AM (#39167062)
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.
Re:I looked through attacks in my access logs by Aachen on Sunday January 28, 2024 @12:14PM (#39167696)
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

Re:I looked through attacks in my access logs by ggpsv on Sunday January 28, 2024 @12:50PM (#39168015)
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.
Re:I looked through attacks in my access logs by yjftsjthsd-h on Sunday January 28, 2024 @11:22AM (#39167115)
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.
Re:I looked through attacks in my access logs by achairapart on Sunday January 28, 2024 @11:18AM (#39167075)
Also, be sure your web server is not serving dotfiles/dotfolders (apart for a few legitimate reasons, ie .well-known).
Re:I looked through attacks in my access logs by Aachen on Sunday January 28, 2024 @12:18PM (#39167733)
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)?
Re:I looked through attacks in my access logs by azeemba on Sunday January 28, 2024 @10:45AM (#39166787)
Update your software frequently.
Re:I looked through attacks in my access logs by klysm on Sunday January 28, 2024 @10:53AM (#39166858)
But not too frequently
Re:I looked through attacks in my access logs by Tijdreiziger on Sunday January 28, 2024 @04:50PM (#39170161)
I’d rather update it too frequently and potentially bork something, than not update it frequently enough and potentially get pwned.
Re:I looked through attacks in my access logs by lazyeye on Sunday January 28, 2024 @12:31PM (#39167834)
Tailscale is ridiculously easy to install and get running.
Re:I looked through attacks in my access logs by ufmace on Sunday January 28, 2024 @02:56PM (#39169228)
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.
Re:I looked through attacks in my access logs by layer8 on Sunday January 28, 2024 @05:23PM (#39170423)
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.