On Tuesday 18 July 2017 22:15:24 mj wrote:

Hi,

Thanks for the quick follow-ups! Much appreciated. After posting this, I immediately started working on fail2ban. And between my initial posting and now, fail2ban already blocked 114 IPs.

I have fail2ban with maxretry=1 and bantime=1800

However, it seems almost all IPs are different, and I don't think I can keep the above settings permanently.

Robert, your iptables suggestions are _very_ interesting! However, will they also work on imaps/993, because of the ssl?

Thanks for the quick replies!

MJ

Why not? You can however let them retry 2-3 times , we all made mistakes :) If there is a real user in that ban list you will help him to found and remove the malware in his network.

On 07/18/2017 09:52 PM, Robert Schetterer wrote:

...

Am 18.07.2017 um 21:44 schrieb mj:

...

Hi all,

It seems we are under some kind of password guessing attack:

...

Jul 18 21:33:33 auth: Info: ldap(username1,103.6.223.61,<W7wLl5xUfABnBt89>): invalid credentials (given password: 1q2w3e4r5t) Jul 18 21:34:16 auth: Info: ldap(username1,221.4.61.180,<89WnmZxUrADdBD20>): invalid credentials (given password: 1q2w3e4r5t) Jul 18 21:36:13 auth: Info: ldap(username2,117.243.180.225,<ESWBoJxUdQB187Th>): invalid credentials (given password: 1q2w3e4r) Jul 18 21:36:50 auth: Info: ldap(username2,58.59.103.230,<j7fQopxUNgA6O2fm>): invalid credentials (given password: 1q2w3e4r) Jul 18 21:36:56 auth: Info: ldap(username4,58.215.13.154,<gtY5o5xUlQA61w2a>): invalid credentials (given password: 1q2w3e4r5t) Jul 18 21:37:18 auth: Info: ldap(username3,220.175.154.205,<lFxppJxUFADcr5rN>): invalid credentials (given password: 1q2w3e4r) Jul 18 21:37:25 auth: Info: ldap(username5,14.142.29.142,<40zopJxUSgAOjh2O>): invalid credentials (given password: 1q2w3e4r) Jul 18 21:37:27 auth: Info: ldap(username4,119.1.98.121,<JDQOpZxUCwB3AWJ5>): invalid credentials (given password: 1q2w3e4r5t) Jul 18 21:37:54 auth: Info: ldap(username3,218.76.156.11,<OMqtppxUMADaTJwL>): invalid credentials (given password: 1q2w3e4r)

Different IPs, different usernames, but all (almost) the same password.

Any idea what we can do about this??

Any advice you could give us would be very much appreciated.

MJ

perhaps this

https://wiki.dovecot.org/HowTo/Fail2Ban

or you may adapt this

https://sys4.de/de/blog/2015/11/07/abwehr-des-botnets-pushdo-cutwail-ehlo-> > ylmf-pc-mit-iptables-string-recent-smtp/

https://sys4.de/de/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/

to pop3(s)/imap(s) and your needs

Best Regards MfG Robert Schetterer

Am 18.07.2017 um 22:53 schrieb mj:

Hi Robert,

On 07/18/2017 10:15 PM, mj wrote:

...

Robert, your iptables suggestions are _very_ interesting! However, will they also work on imaps/993, because of the ssl?

I have adjusted and put into place your iptables suggestion like this:

...

iptables -I INPUT -p tcp --dport 143 -m string --algo bm --string '1q2w3e4r' -j DROP iptables -I INPUT -p tcp --dport 993 -m string --algo bm --string '1q2w3e4r' -j DROP

dont speculate verify if your bots are using ssl , and what flows over the wire if plain is used, you dont need to use 1q2w3e4r, i think you can use any dovecot answer that "means rejected", sorry no time to test myself

However, I don't think it's working, as the login attempts just keep coming. Probably the reason is: smtp is plain text, and imap TLS/SSL is not, so the rules never get triggered.

MJ

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

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.

MJ

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.

On 20.07.2017 12:16, mj wrote:

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,): 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..?

You could use https://github.com/PowerDNS/weakforced here. It lets you execute arbitrary actions in addition to just outright blocking the users.

Aki

Am 20.07.2017 um 12:28 schrieb mj:

I have concoted something that seems to work. And for the archives, this is it:

...

failregex = auth: Info: ldap\(.+,<HOST>,.+\): invalid credentials \(given password: .+ssword\) auth: Info: ldap\(.+,<HOST>,.+\): invalid credentials \(given password: 1qaz2wsx\) auth: Info: ldap\(.+,<HOST>,.+\): invalid credentials \(given password: 123321\) auth: Info: ldap\(.+,<HOST>,.+\): invalid credentials \(given password: 1234567890\) auth: Info: ldap\(.+,<HOST>,.+\): invalid credentials \(given password: 1q2w3e4r.+\)

It's still reactive, and not pro-active.

All the other suggestions are very much appreciated, including weakforced, however implementing that is a much larger project.

i dont understand why you focused on that ldap strings fail2ban should trigger on some "Authentication failure" regex in the related syslog

perhaps this will help to make it more clear

http://www.stefan-seelmann.de/wiki/fail2ban#postfix-and-dovecot

Next I have to find out how to feed my fail2ban logs back to blocklist.de, to improve their mail.txt hit rate.

Thanks again for all kind assistance.

MJ

On 07/20/2017 11:16 AM, mj wrote:

...

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,): 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..?

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

Am 20.07.2017 um 20:03 schrieb mj:

Hi Robert,

...

i dont understand why you focused on that ldap strings fail2ban should trigger on some "Authentication failure" regex in the related syslog

perhaps this will help to make it more clear

http://www.stefan-seelmann.de/wiki/fail2ban#postfix-and-dovecot

Yes, but I have that as well. :-)

I wanted two kinds of blockings:

#1: Everybody trying the well-known passwords (password, 123321, 1q2w3e, etc, etc) to become blocked *immediately* and for *always*.

#2: I wanted all others have to have the 'regular' settings, with three shots at typing a password, etc.

#2 being the 'regular fail2ban' settings, but during this attack, I wanted special settings, #1, for anyone trying one of the malicious passwords.

I did NOT want to have them the usual three opportunities to try.

In fact: this is a bit similar to your iptables solution, but that only works for non-ssl/non-tls connections.

Your iptables solution makes sure that thy cannot authenticate *at all*, while the above solution makes sure they can only authnticate *once*.

MJ

Ok I understand, not a bad idea, report how it works for you

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

On 21/07/2017 04:03, mj wrote:

Hi Robert,

...

i dont understand why you focused on that ldap strings fail2ban should trigger on some "Authentication failure" regex in the related syslog

perhaps this will help to make it more clear

http://www.stefan-seelmann.de/wiki/fail2ban#postfix-and-dovecot

Yes, but I have that as well. :-)

I wanted two kinds of blockings:

#1: Everybody trying the well-known passwords (password, 123321, 1q2w3e, etc, etc) to become blocked *immediately* and for *always*.

This can be very tricky at times and you may actually hit quite a few legit users who are using weak passwords and have forgotten / mistyped them by accident. Seen this enough times and the amount of support required to make a sloppy & lazy customer happy again isn't always trivial. If they're few and far apart you can live with it, otherwise you'll have to reevaluate it :)

Adi Pircalabu