And TBH while it is definitely a cool thing; I think that documenting how to install and configure this sort of thing is probably better than just including it.

My understanding is that it leverages IPTables to enforce it's bans. Assuming that my understanding is right (please correct me if I'm wrong); considering that IPTables is disabled by default it adds very little OOTB (IMO).

The only way to make it generically useful is to also pre-enable IPTables. But that is where it starts getting tricky. Some of our build formats do not include a kernel (e.g. OpenVZ). So IPTables won't work. Although TBH I'm not sure whether it would just fail gracefully or throw a big fat error. Also AWS instances use Amazon's security profile (and not IPTables). So if fail2ban were used AWS users would need to configure both AWS security profile AND IPTables. I can guarantee that would lead to many frustrated users and a rise in support requests...

So I'm certainly not saying don't use it. I'm just saying that I'm not sure that including it by default is a good idea. Instead let's document it's setup config and usage. Despite IPTables not being enabled by default it is configured so enabling it (on systems that support it) is super easy. And apparently fail2ban defaults are pretty sensible and install is fairly straight forward (even more so in the upcoming v14.0 - it's in the Jessie repos).

FWIW the docs are a wiki and you should be able to add a new child page to the tutorial/how to section.

Thoughts?

With the current state of play I doubt that fail2ban alone would make a significant improvement if someone were specifically targeting you and/or your server. It would just slow them down by increasing the time that it takes them to hack you. Also an attacker with a botnet could easily side step fail2ban with a distributed attack (i.e. the same attacker coming at you from multiple IPs).

However I suspect that it would make your server less of a "low hanging fruit" for unsophisticated attacks by less organised hackers looking for opportunities.

IMO the best defence against attackers though is configuration...

Disabling services that you don't use is a great start (reduces attack vectors). Not allowing SSH login using a password (i.e. only allowing keys) is a really easy way to massively reduce the chance of someone hacking into the root (or any other) account of your server.

Also where possible only allow connection to limited IPs (i.e. limit connections to the IPs you and people you permit). Obviously that won't be a valid option for a webserver, but it might be for other services...

But probably one of the biggest ones is making sure that where and when you do use passwords, make them REALLY good ones! 8 chars bare minimum (the more the better) and include at least 3 of the 4: lower-case, upper-case, numbers, special characters. From what I have read, actually using a sentence (or phrase) as your password is not a bad way to go (it's long and by nature includes a mix of character types and is often easier to remember).