I propose that the default 600s/10minute find time is a better test duration for this ban. The altered 120s findtime sounds reasonable until you consider that attackers can simply throttle to 3 attempts per minute and never be banned.
The remaining non default jail settings of maxretry = 7 and bantime = 3600 I believe are good.
Recidive can be thought of as FAIL2BAN checking itself. This setup will monitor the FAIL2BAN log and if 10 bans are seen within one day activate a week long ban and email the mail in a box admin that it has been applied . These bans survive FAIL2BAN service restarts so are much stronger which obviously means we need to be careful with them.
Our current settings are relatively safe and definitely not easy to trigger by mistake e.g to activate a recidive IP jail by failed SSH logins a user would have to fail logging into SSH 6 times in 10 minutes, get banned, wait for the ban to expire and then repeat this process 9 further times within a 24 hour period.
The default maxretry of 5 is much saner but that can be applied once users are happy with this jail. I have been running a stronger version of this for months and it does a very good job of ejecting persistent abusers.
Explicitly set the timings and counts for the dovecot jail rather than change the global [DEFAULT] and inherit it for this one jail. These settings are far too safe so a future PR should increase security here.
Reverts the remaining FAIL2BAN settings to default: findtime 600 and maxretry 3. As jail settings override default settings this was hardly being used anyway so it is better to explicitly set it per jail as and when required.
Ban time was too low for preventing ssh brute force attacks, this change also allows to keep the auth.log more clean and avoid wasting cpu and i/o on this.
Bots eventually will flag your IP as secure and move along.
No legitimate admin will require 20 login attempts. The default 6 is a sane middle ground especially since in 10 minutes they can try again or immediately from another IP anyway.
A 60 second/1 minute ban time is not long enough to counter brute force attacks which is the main purpose of fail2ban for mail in a box. The default bantime of 10 minutes is still sane and I think we have proven fail2ban is reliable enough not to cause problems in general. It is not worth sacrificing security for the rare case where an admin locks themselves out for 10 minutes.
Jan Schulz-Hofen
NatCC
Michael Kroes
Chris Blankenship
Joshua Tauberer
anoma
kri3v
H8H