Hacker News Reader

Comment by pandog | Hacker News Reader

To put it another way - there is no security risk that fail2ban helps with that can't be resolved in another, better, more robust and less risky way.

View on HN

But it also helps in reducing the load on your servers when, e.g., instead of 300+ login attempts per minute on your mail ports, you get 20 because the IP gets banned for a day after 2 failures. Or, instead of nginx spending 90% of its time sending out 404s for the various PHP and MySQL holes I do not have installed, it can spend 10% of its time instead.

Particularly on my small server, fail2ban is the difference between "usable" and "on the edge of falling over".

Parent says there are more robust solutions to these and there are. Rate limiting is one that has been in use forever for example.

Yes, I'm rate-limiting by using fail2ban to drop traffic that I don't want.

If you’re a hobbyist sysadmin setting up a personal VPS then the security risk is your own competence in correctly configuring things the better more robust less risky way, but you can’t replace yourself with a more competent sysadmin in this scenario, so fail2ban helps to Swiss cheese model this edge case.

Saying anyone who makes mistakes is just incompetent is really just a “no true Scotsman” argument.

Everyone makes mistakes. That’s the whole point of the Swiss cheese model and of layers of security in general.

Excuse me, if fail2ban is frowned upon, what is the alternative to block crawlers that try to find wordpress or php endpoints on my website, two software that I don't have installed?

The idea is you don't have to block those since there is no attack surface.

I look at the imap login attempts on my server sometimes. The passwords they try are usually pathetic. Nothing close to the 15+ character actual passwords we have in use.

So the idea is I shouldn't need an alarm system in my house because all my valuables are kept at a safe that can't be opened by anyone but me?

I disagree with this, 404 queries still use resources and someone trying URLs in a matter of seconds should be blocked nonetheless.

> […] that can't be resolved in another, better, more robust and less risky way.

Only if you can get business/users/management buy-in or approval for implementing those ways and changing workflows.

Reply on news.ycombinator.com