under some kind of attack

[Dave]

On 19/07/2017 11:23, mj wrote:
> Hi Robert,
> 
> On 07/18/2017 11:43 PM, Robert Schetterer wrote:
>> i guess not, but typical bots arent using ssl, check it
>>
>> however fail2ban sometimes is to slow
> 
> I have configured dovecot with
> auth_failure_delay = 10 secs
> 
> I hope that before the 10 sec are over, dovecot will have logged about the
> failed login attempt, and fail2ban will have blocked the ip by then.

I realise this is orthogonal to dovecot, but if you are attempting to block a
very large number of IPs, it is more efficient to use a single ipset than
thousands of iptables rules:

For example, given a single firewall rule:

iptables -A INPUT -p tcp --dport 143 -m set --match-set imap-bl src -j DROP

/etc/fail2ban/jail.conf:

[imap]

...
action = ipset[name=imap-bl]

/etc/fail2ban/action.d/ipset.conf:

[Definition]

# fail2ban tracks, so we dont use ipset timeout
actionstart = /usr/sbin/ipset -exist create <name> hash:ip maxelem 131072
actionstop  = /usr/sbin/ipset -exist flush  <name>

actioncheck =

actionban   = /usr/sbin/ipset -exist add <name> <ip>
actionunban = /usr/sbin/ipset -exist del <name> <ip>

You may have to ensure the ipset is present before referencing it in iptables,
for example, Redhat-alikes will have an ipset init script that operates in
exactly the same way as iptables (start/stop/save), with the configuration
stored under /etc/sysconfig/ipset:

create imap-bl hash:ip family inet hashsize 1024 maxelem 131072

chkconfig ipset on
service ipset start

(create iptables rules, ipset created on boot prior to iptables, other distros
likely have similar configuration)

I've found that the slowest component tends to be fail2ban itself, which has
difficulty tracking a large number of IPs or even tailing sufficiently busy
logfiles.

-- 
Dave