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