On: Fail2Ban

[callalex]

Doesn’t it help to mitigate DoS type attacks by reducing the amount of CPU that a bad actor can burn?

[pandog → callalex]

If someone is performing a denial of service attack from one I.P. address then this will help.

To tptacek's point, you've got to ask yourself is a denial of service attack in your threat model?

The reality is most folk set up fail2ban after seeing auth failures in their logs, not service degradation.

If you're considering a denial of service attack in your threat model, then I'd probably also consider a DDoS attack and there are likely more effective solutions here (a firewall or CDN).

And don't forget you're using some of those precious CPU cycles to parse the auth logs, with python no less :-)

[_vOv_ → pandog]

>And don't forget you're using some of those precious CPU cycles to parse the auth logs, with python no less :-)

You can ship the log somewhere else, do the fail2ban there and perform the block action in another place up the stack.

[inferiorhuman → pandog]

f2b can also do an (r)whois lookup and ban netblocks.

[discreditable → callalex]

You can do it with ufw limit too

[pluc → discreditable]

You can also literally have anything pipe rules into it. Want WordPress auth to result in fail2ban-enforced bans? You can do that. Want cheap rate limiting? You can do that too

[BeefWellington → pluc]

This thread seems pretty full of people dismissing the project based on the idea that it only protects against ssh credential stuffing, and ignoring the other 99.5% of what F2B does.