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 slowI 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. MJ
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
Hi everybody, Thanks very much for the kind advises given yesterday and today. I have now implemented the blocklist on * http://list.blocklist.de/lists/all.txt using the scripts here: * https://forum.blocklist.de/viewtopic.php?f=11&t=84# (a combi of bash and php) For now, my server appears to handle that approach (with the seperate iptables rules) quite nicely. But I will keep the ipset solution in mind. Anyone aware of other blocklists that are worth bocking? Because the list.blocklist.de/lists/all.txt blocks some, but not anywhere near all. I now know how to block large lists of ips, so if anyone has additional lists to block? MJ On 07/19/2017 12:42 PM, Dave wrote:> 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. >
Hi all, If I may, one more question on this subject: I would like to create a fail2ban filer, that scans for these lines:> Jul 20 11:10:09 auth: Info: ldap(user1,60.166.35.162,<cDFXHbxUQgA8piOi>): invalid credentials (given password: password) > Jul 20 11:10:19 auth: Info: ldap(user2,61.53.66.4,<V+nyHbxU+wA9NUIE>): invalid credentials (given password: password)(as you can see, I have enabled auth_verbose_passwords to do this, making me very uncomfortable...) Anyway: since there are only a few password variations, I would like to block anyone using those passwords. (since the connections are over TLS/SSL, I cannot use iptables, as suggested earlier) So I need a specific fail2ban rule that extracts the <IP> from that line, and matches on "(given password: password)" Can anyone here help out with a failregex line that would match..?