[BeefWellington]

> That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.

Shifting services to alternate port numbers will stop very stupid scanners but it does not stop the worst offenders IME. Basically it just means you'll only get the really obnoxious sources that try everything ignoring responses.

> I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.

Given the age of the project and that there's been a whopping NINE vulnerabilities found in its lifetime, this is a great take. By this same logic you better disable OpenSSH everywhere. In the same timeframe as Fail2Ban has has reported vulnerabilities, OpenSSH has had at least 60: https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...

"Worse than security theatre" is quite the statement given they reported and fixed those issues in timely fashions.

If you apply the principles of defense in depth, using the network layer to deny access to misbehaving remote hosts is an obvious win on a lot of fronts and hardly qualifies as security theatre anymore than using a network firewall is security theatre.

[rendaw]

It's not 9 vs 60, it's 9 vs 0 if you don't use it, with no loss in functionality. And GPs point is that it's not defense in depth, the vulnerabilities in Fail2Ban can compromise the security of other layers.

[dizhn]

If we limit the use case to a single service, fail2ban is just a log cleaner. What it's detecting is merely the service that you're protecting doing its job properly. Now if you analyze the collected data and do something smarter with it, that's another story.