Mailinabox: fail2ban 'failtime' limits seem too low; some rules can never trigger

[hachre]

Hi,

I've gotten into Mail-In-A-Box a few days ago and am in the process of going through everything that was done to set it up. Great job by the way! It's a really great project :)

When I arrived at the fail2ban configurations I first assumed that the findtime variable was in minutes but later found out it was in seconds. The current values appear so low to me that they would never trigger.

I have some experience with servers in the wild and most of the times you'll see attacks of the kind where several IPs make several requests and try out usernames and passwords. Modern bots even simulate different amounts of waiting times between the individual retries to fool rate limiting systems. However with the current way fail2ban is set up, some rules would never trigger.

The current RoundCube configuration, for example, wants to see 20 failed logins by the same IP within 30 seconds. The way RoundCube is set up, however, it will rate limit the user and enforce a 1 minute waiting period after 3 failed logins already. As far as I know RoundCube looks at the IP as well to determine this. This means this particular rule can never be triggered. (This behavior can be disabled but is on by default. $config['login_rate_limit'] = 0; would disable it.)

When it comes to the configuration of Dovecot for example, the limits are the same. You'd need 20 failed logins from the same IP within 30 seconds to trigger a ban. I think Dovecot even waits 2-3 seconds on login failures but I'm not sure about this. Again, unless you're hit by someone who quickly wrote up a brute force script with no rate limiting at all (and Dovecot doesn't do any waiting), this just won't happen. Most serious attacks are conducted by distributed botnets and as such the IPs vary for many of the requests.

In essence this means you need to increase the time window you're looking at significantly to have a chance of catching these requests. I have set findtime to 30 minutes (1800 seconds) now. Within a botnet, the same host will typically only try a request every around 10 seconds or so. Some of them now vary between 5 and 35 seconds to appear more human. They rarely do it faster than this and rather use different IPs in the meantime. This means under the old rule a potential attacker bot would have never been banned, but under the new rule it would be banned after roughly 200 seconds on average.

Am I missing something? Otherwise I'd suggest keeping the maxretry at the current 20 but increasing the findtime to at least 900 or more.

Thanks!

[yodax]

Some previous discussion were had here: https://github.com/mail-in-a-box/mailinabox/pull/478 and https://github.com/mail-in-a-box/mailinabox/pull/551

The current setting still bans on my machine. But I think there shouldn't be much of a risk to increase the time.

[JoshData]

If they don't trigger because there is redundant protection at the application level, that's _fine_. (We could consider removing fail2ban for those applications!)

It would be nice to see some data on how brute force attacks are happening these days, rather than just going from the text of this issue. That said, I'm fine with tweaking the settings to make them better!

[hachre]

@JoshData I fully agree, it would be nice to see data on this - I spoke merely from my personal experience.

I just want to point out that there's one big difference about letting Roundcube handle it compared to having fail2ban handle it: Roundcube only blocks login attempts to itself by refusing to authenticate anyone coming from that IP for a minute. The affected IP can still access and load any Roundcube URLs and any other services fine - they just can't login. On the other hand fail2ban blocks access to all services on the server once triggered. I'm personally more comfortable with that.

[JoshData]

Closing because of inactivity. Feel free to re-open.

[JoshData]

Closing because of inactivity. Feel free to re-open.