Hacker News Reader

Comment by tptacek | Hacker News Reader

Yes. At this point, fail2ban has become almost a shibboleth for people following security checklists as opposed to reasoning about a coherent threat model. This is a perennial topic on HN, and almost always devolves to some appeal to grooming logs, because of all the authentication errors fail2ban is presumably preventing.

Don't use fail2ban. (Don't use passwords, either!)

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

View on HN

I am one of the people to whom you refer. I read about fail2ban in a "Linux Server Bible" e-book around 2010 and have used it on all of my servers since, even though I am careful with my keys and use password-less login.

Does fail2ban have authorization to write firewall rules? That's a high-impact vector of attack, should fail2ban have a vulnerability. Also, does fail2ban store credentials that provide that authorization?

Yes, no.

It runs as root.

While I agree fail2ban is a wrong tool to prevent password brute force - better authentication mechanisms should be used instead - it has its uses. For example, it can be used to automatically ban (or alert about) dumb http scanners like gobuster. I am not saying, a determined attacker cannot bypass it, but if it saves me some hassle and raises the bar for them, why should not I do it?

More general, some attacker actions, especially during recon, rely on making many attempts to connect, fetch an URL, resolve FQDN, etc., these could be detected and automatically responded to, making attacker’s job harder and providing extra visibility to defenders.

You shouldn’t use it because fail2ban itself can (and has been) attacked. It doesn’t make the attackers job meaningfully harder but does add complexity to your systems, that complexity is weakness.

I looked at fail2ban exploits and they are either LPE due to file permissions or command injection in other tools like mailutils.

Citation needed for the claim “has been attacked” if you refer to real attacks in the wild.

One noted upthread https://news.ycombinator.com/item?id=37796588

Yeah, that’s command injection in mailutils I mentioned, not in fail2ban itself. Did you see how it’s supposed to be exploited? Did you see a real-life exploitation?

While it’s a nice trick, it’s simply not relevant. And the vulnerability before that seems to be 10 years old. I’d say it’s a decent track record.

I use fail2ban because I take break in attempts personally, especially when it's some script trying default logins one after another. It's insulting.

> It's insulting

Brute force / credential stuffing attacks against ssh are the mosquitos of the Internet.

Ubiquitous, annoying, and persistent. But nothing personal.

I also take mosquitoes personally, so maybe it's a larger character flaw on my part.

You have that exactly backwards: if someone is hitting you with a password bruteforce from a single IP address (which is the only threat that fail2ban mitigates) then it is assuredly nothing personal at all.

A personal insult, if you are ever unfortunate enough to receive one, will be much more stealthy and neither fail2ban nor any other magical rock will protect you against it.

You don't see any tigers around, do you?

Usually they use a big pool of IP addresses, but that doesn't make fail2ban completely useless since they do reuse IPs.

If anything, you're doing them a (miniscule) favor by keeping them from wasting more resources on failed login attempts. If you really hated them, you'd set up a honeypot.

More fun: setup a fail2ban actionban script that instead of banning the IP, shapes the traffic coming from it to have abysmal bandwidth so requests/responses takes really long time, so they'll have to timeout instead of getting failures.

This is known as tarpitting, and apparently iptables can do it: https://en.wikipedia.org/wiki/Tarpit_%28networking%29

This is hilarious

Neat, didn't know that! Think before I've used Traffic Control (tc) for it, but iptables would be simpler.

Available in `xtables-addons` it seems. After install:

    iptables -A INPUT -p tcp -s $SOURCE_IP -j TARPIT # add IP to tarpit
    iptables -D INPUT -p tcp -s $SOURCE_IP -j TARPIT # remove IP from tarpit

Restrict your SSH login to a single user, then su to your admin

I know how to lock machines down. That's not why I bugs me.

Apologies, I guess I just wanted my two cents in and didn't see anyone writing it

No, it's solid advice. Thanks for looking out for others.

Grooming logs from attempts seems like shibboleth on its own that is indicating junior level or “security enthusiast”.

Anyone who manages servers professionally does not read logs anymore and does not care about obvious things like people brute-forcing.

Reading ssh logs on your single VPS is security LARPING. Discussing faill2ban as well :)

As that gaps of inequality of our winner takes all societies ever widen, anyone just trying to do something for themselves and not for global scale SV company is just meaninglessly role playing.

Not really. Only that reading logs by human or even grepping "manually" is super inefficient where you can make a script that will for instance send you a notification when someone actually logs into your VPS.

In world where "login attempts" are basically all day reality reading logs is meaningless. In 2023 no one should be reading logs you should have alerts on events. In 1995 or something if someone was trying to brute-force your user password that was security event to look at and block IP. In 2023 someone brute-forcing is not an event, it is either wrong configuration like not using ssh authentication or not using tools that filter logs automatically and make alerts when something is actually going on.

Reply on news.ycombinator.com