under another kind of attack

Olaf Hopp

25 Jul 2017 25 Jul '17

5:37 p.m.

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik

Dipl.-Geophys. Olaf Hopp

Leitung IT-Dienste -

Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu

www.kit.edu

KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft

Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.

Attachments:

smime.p7s (application/pkcs7-signature — 5.2 KB)

Show replies by date

mj

25 Jul 25 Jul

5:54 p.m.

Hi Olaf,

Since we implemented country blocking, everything seems nicely under control, with only 'normal levels' of knocking.

We first have impemented: http://blog.jeshurun.ca/technology/block-countries-ubuntu-iptables-xtables-g...

Then we did: https://github.com/firehol/blocklist-ipsets

And finale iptables rules like these:

...

iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc CR,MZ -j DROP

iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc CR,MZ -j DROP

iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc CR,MZ -j DROP

I tried to combine the various dports in one single rule, but that didn't seem to work. Perhaps someone here knows how to combine --match "geoip" and "multiport" in one single rule?

Anyway: for us these combined measures did the tric.

Users in one of the imap-blocked countries will have to use ActiveSync (works over https), the webmail-interface, or launch the VPN first.

This works for us.

Only one thing on my wishlist: application specific passwords. I would very much appreciate a respond on that thread... (posted yesterday evening, with a pseudo-dovecot-config file...)

Hope the above helps you a bit, Olaf.

On 07/25/2017 04:37 PM, Olaf Hopp wrote:

...

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

Robert Schetterer

10 p.m.

Am 25.07.2017 um 16:54 schrieb mj:

...

Hi Olaf,

Since we implemented country blocking, everything seems nicely under control, with only 'normal levels' of knocking.

We first have impemented: http://blog.jeshurun.ca/technology/block-countries-ubuntu-iptables-xtables-g...

Then we did: https://github.com/firehol/blocklist-ipsets

simply geoip blocking may work at your site but it does not work for many other cases

...

And finale iptables rules like these:

...
iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 143 -m geoip --src-cc CR,MZ -j DROP

iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 993 -m geoip --src-cc CR,MZ -j DROP

iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc CN,AG,MX,NI,MF,VE,CO,AR,RU,UA -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc MD,SD,SS,GA,CN,AZ,IN,ID,KZ,LA -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc MY,MN,SG,VN,TH,TW,HK,KR,KP,HT -j DROP iptables -A INPUT -p tcp --dport 465 -m geoip --src-cc CR,MZ -j DROP

I tried to combine the various dports in one single rule, but that didn't seem to work. Perhaps someone here knows how to combine --match "geoip" and "multiport" in one single rule?

Anyway: for us these combined measures did the tric.

Users in one of the imap-blocked countries will have to use ActiveSync (works over https), the webmail-interface, or launch the VPN first.

This works for us.

Only one thing on my wishlist: application specific passwords. I would very much appreciate a respond on that thread... (posted yesterday evening, with a pseudo-dovecot-config file...)

Hope the above helps you a bit, Olaf.

MJ

On 07/25/2017 04:37 PM, Olaf Hopp wrote:

...
Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

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

Doug Barton

29 Jul 29 Jul

8:44 p.m.

On 07/25/2017 07:54 AM, mj wrote:

...

Since we implemented country blocking,

Please don't do that. Balkanizing the Internet doesn't really benefit anyone, and makes innovation a lot more difficult.

Instead, take a look at the fail2ban scenarios in this thread, which solve the actual problem with a precision tool, instead of a hammer.

Doug

mj

9:29 p.m.

Hi Doug,

On 07/29/2017 07:44 PM, Doug Barton wrote:

...

Instead, take a look at the fail2ban scenarios in this thread, which solve the actual problem with a precision tool, instead of a hammer.

I have implemented (most of) those as well, and additionally choose to also block certain countries. It helps tremendously.

Robert Schetterer

30 Jul 30 Jul

8:59 a.m.

Am 29.07.2017 um 20:29 schrieb mj:

...

Hi Doug,

On 07/29/2017 07:44 PM, Doug Barton wrote:

...
Instead, take a look at the fail2ban scenarios in this thread, which solve the actual problem with a precision tool, instead of a hammer.

I have implemented (most of) those as well, and additionally choose to also block certain countries. It helps tremendously.

MJ

You can only use strict geoip blocking as long as your users do not travel so this is not a solution in most cases.

But you can use geoip in an "anomal filter" which compares more informations i.e a user is recent logged in germany so normally he dont want to be logged in from china at the same time, additional count bad logins using some magic formula and he will blocked auto etc, this will prevent hacking and abuse accounts too.

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

mj

29 Jul 29 Jul

9:39 p.m.

On 07/29/2017 07:44 PM, Doug Barton wrote:

...

On 07/25/2017 07:54 AM, mj wrote:

...
Since we implemented country blocking,

Please don't do that. Balkanizing the Internet doesn't really benefit anyone, and makes innovation a lot more difficult.

Perhaps I need to be more specific:

I block certain countries from accessing imap/smtp directly, as that is where all the botnets seem to be trying their passwords.

I do not block entire countries from accessing us completely (the hammer) but rather block their access of imap and smtp for my mailserver. (this is what I like to see as a precision tool)

For the record I improved my iptables rules a lot compared to the mail you replied to. I am now using a chain, like this:

...

$IPTABLES -N filter_countries $IPTABLES -A filter_countries -m geoip --src-cc CN,AG,MX,etc -j DROP $IPTABLES -A filter_countries -m geoip --src-cc MD,SD,SS,etc -j DROP

and then:

...

$IPTABLES -I INPUT 1 -p tcp --dport 143 -j filter_countries $IPTABLES -I INPUT 1 -p tcp --dport 993 -j filter_countries $IPTABLES -I INPUT 1 -p tcp --dport 465 -j filter_countries

This makes it a lot more efficient, compared to the (many) rules I was using earlier.

Gary Sellani

30 Jul 30 Jul

6:25 a.m.

At a bare minimum, do the same blocking for AWS. The jq program mentioned on the page works great.

http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html

I block the cloud services as they hack me. There aren't many left that I haven't seen. Sadly my VPS, Digital Ocean, has an email hacker that I just can't get DO to shut down. I assure you I'm costing them plenty in tech support. You can do a search on stretchoid.com if you want to learn more about the offender.

I have an additional list of EDU ip addresses that probably are doing research, but won't let me opt out.

bgp.he.net is one way to get IP space listings.

Original Message From: lists@merit.unu.edu Sent: July 29, 2017 11:39 AM To: dovecot@dovecot.org Subject: Re: under another kind of attack

On 07/29/2017 07:44 PM, Doug Barton wrote:

...

On 07/25/2017 07:54 AM, mj wrote:

...
Since we implemented country blocking,

Please don't do that. Balkanizing the Internet doesn't really benefit anyone, and makes innovation a lot more difficult.

Perhaps I need to be more specific:

I block certain countries from accessing imap/smtp directly, as that is where all the botnets seem to be trying their passwords.

I do not block entire countries from accessing us completely (the hammer) but rather block their access of imap and smtp for my mailserver. (this is what I like to see as a precision tool)

For the record I improved my iptables rules a lot compared to the mail you replied to. I am now using a chain, like this:

...

$IPTABLES -N filter_countries $IPTABLES -A filter_countries -m geoip --src-cc CN,AG,MX,etc -j DROP $IPTABLES -A filter_countries -m geoip --src-cc MD,SD,SS,etc -j DROP

and then:

...

$IPTABLES -I INPUT 1 -p tcp --dport 143 -j filter_countries $IPTABLES -I INPUT 1 -p tcp --dport 993 -j filter_countries $IPTABLES -I INPUT 1 -p tcp --dport 465 -j filter_countries

This makes it a lot more efficient, compared to the (many) rules I was using earlier.

Tanstaafl

31 Jul 31 Jul

7:03 p.m.

On Sat Jul 29 2017 13:44:53 GMT-0400 (Eastern Standard Time), Doug Barton dougb@dougbarton.us wrote:

...

On 07/25/2017 07:54 AM, mj wrote:

...
Since we implemented country blocking,

Please don't do that. Balkanizing the Internet doesn't really benefit anyone, and makes innovation a lot more difficult.

Your use of the term 'balkanizing' is in reality an attempt to balkanize this list/thread.

In reality, when you (the sysadmin) know with absolutely certainty that no one from certain countries should ever be logging into one or more servers/services you provide, outright blocking based on those country's is not only a good idea, it is common sense.

In our case - all of our email users are in the USA, and virtually never travel outside the USA. Why then should I leave our mail servers open to people in Russia, China, Saudi Arabia, etc, when we have no users there?

This does not create a contentious situation for anyone other than hackers from foreign countries trying to access our systems - unless you think that hackers attempting to hack into systems they have no right to access have some kind of 'right' nevertheless to be able to try, thus have a legitimate 'compliant' about me blocking their entire country.

This is not a 'security through obscurity' argument. Geo-blocking can dramatically reduce the risk to systems that, again, have no legitimate users in said countries, and improve the signal-to-noise ratio of logs as well.

...

Instead, take a look at the fail2ban scenarios in this thread, which solve the actual problem with a precision tool, instead of a hammer.

Fail2ban doesn't work against distributed attacks that use a different IP address each time.

While I agree that the combination of methods being discussed in this thread are valuable, their use, in combination with outright blocking entire swaths of sources of attacks, is an an even better way to protect ones systems.

Of course, the above doesn't and cannot apply to servers/services that *do* deal with users from all over the world.

As well, if you don't have users who need to be able to log in from many foreign countries, you are free to disagree and leave your systems unnecessarily open to such attacks if you like, but that doesn't mean you get to attack others with impunity who recognize the sanity of such measures under appropriate circumstances.

Darac Marjal

25 Jul 25 Jul

6:25 p.m.

On Tue, Jul 25, 2017 at 04:37:23PM +0200, Olaf Hopp wrote:

...

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

Of course it will. You just need to set the "findtime" high enough. Personally, on my very quiet home server, I have findtime set to 7200 (2 hours) and maxretry set to 5, meaning that if a host fails to authenticate 5 times in two hours, they're banned (I have a fairly harsh ban time of a week, so that stops them coming back too soon).

...

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik

Dipl.-Geophys. Olaf Hopp

Leitung IT-Dienste -

Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu

www.kit.edu

KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft

Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.

-- For more information, please reread.

Tamsy

6:32 p.m.

Olaf Hopp wrote on 25.07.2017 16:37:

...

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

For those "unknown user" attacks on Dovecot we use a rule we named "dovecot-unknownusers.conf" with Fail2Ban:

<SNIP> failregex = ^%(__prefix_line)sauth-worker$\d+$: (pam|sql)$\S+,<HOST>$: unknown user\s*$ <SNIP>

"findtime" we set to 5400 (90 minutes) with "maxretry" set to 2.

Works pretty well to block those pesty slow pace attacks.

Robert Schetterer

9:58 p.m.

Am 25.07.2017 um 16:37 schrieb Olaf Hopp:

...

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ?

all the time ,since years, in my case its always schema user xyz.abc in my case all username without @ could be dropped at once a regex deny should be fine, but i havent implemented/thinked of it cause it comming in small waves and mostly fail2ban stops it soon

...

Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

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

Michael Starks

26 Jul 26 Jul

12:36 a.m.

On 2017-07-25 09:37, Olaf Hopp wrote: But the rate at which they

...

are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

OSSEC has at least two ways of stopping these:

Repeat offenders option: this keeps track of the IP and increases the block time if they come back (within a defined timeframe).
You can simply overwrite the rule looking for repeated attempts from the same IP and increase the timeframe option to hours instead of minutes.

...

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

In this case, it looks like it's coming from several different IPs. If the IPs are in geographic regions which should never have a need to log in, you can deny them preemptively in rules.

You can also simply look for any attempt to authenticate to an unknown user and block that. It would be interesting to try to figure out a way to look for deviations from the normal naming convention, or perhaps try to identify something that looks random.

There are other options, as well. You can set up a CDB list with known bad IPs and populate them from threat lists of your choice.

All around, I think you'll find it much more capable and robust than fail2ban.

Disclaimer: I wrote the OSSEC Dovecot ruleset several years ago. I don't know if it is current (but I think it is being maintained).

Olaf Hopp

12:57 p.m.

Dear collegues,

many thanks for your valuable input.

Since we are an university GEO-IP blocking is not an option for us. Somestimes I think it should ;-)

My "mistake" was that I had just *one* fail2ban filter for both cases: "wrong password" and "unknown user".

Now I have two distinct jails: The first one just for "wrong password" and here the findtime, bantime, retries are tolerant to typos.

And I have a new one just for "unknown user" and here my bantime and findtime are much bigger and the retries are just '2'. So here I'm much harsher. I'll keep an eye on my logs and maybe some more twaeking is necessary.

Another interesting observation: I activated auth_verbose_passwords = plain to log the plain password when (and only when) there is "unknown user". It reveals that all different IPs trying one unknown account always try with the same stupid password scheme <ACCOUNT>1234. So this doesn't look very well coordinated between the bots ;-)

Regards, Olaf

On 07/25/2017 04:37 PM, Olaf Hopp wrote:

...

Hi folks,

"somehow" similar to the thread "under some kind oof attack" started by "MJ":

I have dovecot shielded by fail2ban which works fine. But since a few days I see many many IPs per day knocking on my doors with wron password and/or users. But the rate at which they are knocking is very very low. So fail2ban will never catch them.

For example one IP:

Jul 25 14:03:17 irams1 dovecot: auth-worker(2212): pam(eurodisc,101.231.247.210,): unknown user Jul 25 15:16:36 irams1 dovecot: auth-worker(11047): pam(gergei,101.231.247.210,): pam_authenticate() failed: Authentication failure (password mismatch?) Jul 25 16:08:51 irams1 dovecot: auth-worker(3379): pam(icpe,101.231.247.210,): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user

Note the timestamps. If I look the other way round (tries to one account) I'll get

Jul 25 01:30:48 irams1 dovecot: auth-worker(11276): pam(endsulei,60.166.12.117,<slp6mhhViI48pgx1>): unknown user Jul 25 01:31:26 irams1 dovecot: auth-worker(11276): pam(endsulei,222.243.211.200,): unknown user Jul 25 13:29:22 irams1 dovecot: auth-worker(4745): pam(endsulei,60.2.50.114,<4elhpCJVtcw8AjJy>): unknown user Jul 25 13:30:27 irams1 dovecot: auth-worker(4747): pam(endsulei,222.84.118.83,<kaE1qCJVn7neVHZT>): unknown user Jul 25 16:10:47 irams1 dovecot: auth-worker(4250): pam(endsulei,101.231.247.210,): unknown user Jul 25 16:11:45 irams1 dovecot: auth-worker(5933): pam(endsulei,206.214.0.120,<R5H56CRVdJfO1gB4>): unknown user

Also note the timestamps!

And I see many many distinct IPs per day (a few hundred) trying many many existing and non-existings accounts. As you see in the timestamps in my examples, this can not be handled by fail2ban without affecting regular users with typos. Is anybody observing something similar ? Anybody an idea against this ? Many of these observed IPs are chinese mobile IPs, if this matters. But we have also chinese students and researchers all abroad.

Regards, Olaf

-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik

Dipl.-Geophys. Olaf Hopp

Leitung IT-Dienste -

Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu

www.kit.edu

KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft

Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.

jack

9:44 p.m.

On 26/07/2017 10:57, Olaf Hopp wrote:

...

I'll keep an eye on my logs and maybe some more twaeking is necessary.

Twerking?

...

So this doesn't look very well coordinated between the bots ;-)

Bots are cheap - free, basically, because they are stolen. Most bruteforce attacks are crap; they try the same username/password pair on the same host over and over again.

I would like to be able to signal to the bot "Dude, I do not accept username/password pairs - you need a keypair, so give it a rest". But the bots are dumb, because the economic advantage of building a smart one is zero.

BTW: I don't think this is on-topic for Dovecot - we seem to be discussing mail-abuse abatement measures, which is a much more general topic.

-- Jack.

James Brown

27 Jul 27 Jul

6:19 a.m.

...

On 26 Jul 2017, at 7:57 pm, Olaf Hopp Olaf.Hopp@kit.edu wrote:

Dear collegues,

many thanks for your valuable input.

Since we are an university GEO-IP blocking is not an option for us. Somestimes I think it should ;-)

My "mistake" was that I had just *one* fail2ban filter for both cases: "wrong password" and "unknown user".

Now I have two distinct jails: The first one just for "wrong password" and here the findtime, bantime, retries are tolerant to typos.

And I have a new one just for "unknown user" and here my bantime and findtime are much bigger and the retries are just '2'. So here I'm much harsher. I'll keep an eye on my logs and maybe some more twaeking is necessary.

Another interesting observation: I activated auth_verbose_passwords = plain to log the plain password when (and only when) there is "unknown user". It reveals that all different IPs trying one unknown account always try with the same stupid password scheme <ACCOUNT>1234. So this doesn't look very well coordinated between the bots ;-)

Olaf, how do you do this only for the unknown user?

Can you share the Dovecot settings?

I’m under the same sort of slow distributed attack.

Also the two fail2ban jails would be helpful.

Thanks,

James.

Olaf Hopp

10:40 a.m.

On 07/27/2017 05:19 AM, James Brown wrote:

...

...
On 26 Jul 2017, at 7:57 pm, Olaf Hopp Olaf.Hopp@kit.edu wrote:

Dear collegues,

many thanks for your valuable input.

Since we are an university GEO-IP blocking is not an option for us. Somestimes I think it should ;-)

My "mistake" was that I had just *one* fail2ban filter for both cases: "wrong password" and "unknown user".

Now I have two distinct jails: The first one just for "wrong password" and here the findtime, bantime, retries are tolerant to typos.

And I have a new one just for "unknown user" and here my bantime and findtime are much bigger and the retries are just '2'. So here I'm much harsher. I'll keep an eye on my logs and maybe some more twaeking is necessary.

Another interesting observation: I activated auth_verbose_passwords = plain to log the plain password when (and only when) there is "unknown user". It reveals that all different IPs trying one unknown account always try with the same stupid password scheme <ACCOUNT>1234. So this doesn't look very well coordinated between the bots ;-)

Olaf, how do you do this only for the unknown user?

Can you share the Dovecot settings?

I’m under the same sort of slow distributed attack.

Also the two fail2ban jails would be helpful.

Nothing special in the dovecot config

/etc/fail2ban/jail.local

[dovecot]

enabled = true filter = dovecot action = iptables-multiport[name=dovecot, port="pop3,pop3s,imap,imaps,submission,465,sieve", protocol=tcp] logpath = /var/log/dovecot bantime = 600 findtime= 600 maxretry= 5 backend = auto

[dovecot_unknown]

ignoreip = X.X.X.0/24 enabled = true filter = dovecot_unknown action = iptables-multiport[name=dovecot_unknown, port="pop3,pop3s,imap,imaps,submission,465,sieve", protocol=tcp] logpath = /var/log/dovecot bantime = 14400 findtime= 14400 maxretry= 2 backend = auto

/etc/fail2ban/filter.d/dovecot.local

[INCLUDES] before = common.conf

[Definition] failregex = dovecot: auth-worker$\d+$: pam$.*,<HOST>,\<.*\>$: pam_authenticate failed: Authentication failure $password mismatch\?$ ignoreregex =

/etc/fail2ban/filter.d/dovecot_unknown.local

[INCLUDES] before = common.conf

[Definition] failregex = dovecot: auth-worker$\d+$: pam$.*,<HOST>,\<.*\>$: unknown user.* ignoreregex =

The failregex lines may need adaption to your log format. "fail2ban-regex" is your friend.

On my Dovecot 2.2.31 unknows user log lines are Jul 26 14:58:56 irams1 dovecot: auth-worker(2822): pam(inikul,112.54.93.34,<TcVzAjhVMINwNl0i>): unknown user (given password: inikul2017)

and "wrong password" lines look like this Jul 26 15:01:41 irams1 dovecot: auth-worker(3530): pam(johndoe,120.209.164.118,): pam_authenticate() failed: Authentication failure (password mismatch?)

Regards, Olaf

Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik

Dipl.-Geophys. Olaf Hopp

Leitung IT-Dienste -

Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu

www.kit.edu

KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft

Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.

2670

Age (days ago)

2676

Last active (days ago)

List overview

16 comments

11 participants

participants (11)

Darac Marjal
Doug Barton
Gary Sellani
jack
James Brown
Michael Starks
mj
Olaf Hopp
Robert Schetterer
Tamsy
Tanstaafl

under another kind of attack

Olaf Hopp

Michael Starks

Olaf Hopp

jack

Olaf Hopp

/etc/fail2ban/jail.local

/etc/fail2ban/filter.d/dovecot.local

/etc/fail2ban/filter.d/dovecot_unknown.local

Regards, Olaf

tags

participants (11)