[Dovecot] Dovecot under brute force attack - nice attacker
Hi List,
optimizing the configuration on one of our servers (which was hit by a brute force attack on dovecot) showed an odd behavior.
Dovecot Version 1.0.7 (CentOS 5.2)
The short story: On one of our servers an attacker did a brute force attack on dovecot (pop3). Since the attacker closed and reopened the connection after every user/password combination the logs showed many lines like this: dovecot: pop3-login: Aborted login: user=<test>,......
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
If I enable auth_verbose every attempt gets logged, but if I read the docs correctly this option should only be used for figuring out why authentication isn't working.
Question: Is there any way to close the connection after the first wrong user/pass combination. So an attacker would be forced to reopen it? This would be perfect since an easy iptables/hashlimit would avoid such a brute force attack.
Any other Ideas? Henry
On Thu, 2009-06-04 at 12:16 +0200, henry ritzlmayr wrote:
Hi List,
optimizing the configuration on one of our servers (which was hit by a brute force attack on dovecot) showed an odd behavior.
Dovecot Version 1.0.7 (CentOS 5.2)
The short story: On one of our servers an attacker did a brute force attack on dovecot (pop3). Since the attacker closed and reopened the connection after every user/password combination the logs showed many lines like this: dovecot: pop3-login: Aborted login: user=<test>,......
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
Verified with 1.1.6 as well, nice catch Henry.
Reproduced on 1.1.14 too and really problematic for me
-----Message d'origine----- De : dovecot-bounces+laruellec=aiderdonner.com@dovecot.org [mailto:dovecot-bounces+laruellec=aiderdonner.com@dovecot.org] De la part de Noel Butler Envoyé : jeudi 4 juin 2009 12:48 À : henry ritzlmayr Cc : dovecot@dovecot.org Objet : Re: [Dovecot] Dovecot under brute force attack - nice attacker
On Thu, 2009-06-04 at 12:16 +0200, henry ritzlmayr wrote:
Hi List,
optimizing the configuration on one of our servers (which was hit by a brute force attack on dovecot) showed an odd behavior.
Dovecot Version 1.0.7 (CentOS 5.2)
The short story: On one of our servers an attacker did a brute force attack on dovecot (pop3). Since the attacker closed and reopened the connection after every user/password combination the logs showed many lines like this: dovecot: pop3-login: Aborted login: user=<test>,......
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
Verified with 1.1.6 as well, nice catch Henry.
Cédric Laruelle pisze:
Reproduced on 1.1.14 too and really problematic for me
Can't reproduce in 1.2rc4 :)
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys +OK User name accepted, password please pass wew -ERR Bad login / Bledne haslo lub login. Connection closed by foreign host.
On Jun 4, 2009, at 10:01 AM, Lenthir wrote:
Cédric Laruelle pisze:
Reproduced on 1.1.14 too and really problematic for me
Can't reproduce in 1.2rc4 :)
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys +OK User name accepted, password please pass wew -ERR Bad login / Bledne haslo lub login. Connection closed by foreign host.
That's not Dovecot.
Timo Sirainen pisze:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys +OK User name accepted, password please pass wew -ERR Bad login / Bledne haslo lub login. Connection closed by foreign host.
That's not Dovecot.
Hm... ups... maybe... Tommorow I'll check it.
Timo Sirainen pisze:
On Jun 4, 2009, at 10:01 AM, Lenthir wrote:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys +OK User name accepted, password please pass wew -ERR Bad login / Bledne haslo lub login. Connection closed by foreign host.
That's not Dovecot.
I'm sorry to said that, but this is Dovecot... Maybe with little modifications, but this is Dovecot :)
POP3: telnet localhost 10101 Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys7373@op.pl +OK User name accepted, password please pass ******** +OK Mailbox open, 5 messages, new: 0, your primary account: krzys7373@op.pl, message quota: 30 kB capa +OK CAPA TOP UIDL RESP-CODES PIPELINING . quit +OK Sayonara
IMAP: telnet localhost 10102 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot ready. o logout Connection closed by foreign host.
Am Freitag, den 05.06.2009, 09:24 +0200 schrieb Lenthir:
Timo Sirainen pisze:
On Jun 4, 2009, at 10:01 AM, Lenthir wrote:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 [127.0.0.1] server ready user krzys +OK User name accepted, password please pass wew -ERR Bad login / Bledne haslo lub login. Connection closed by foreign host.
That's not Dovecot.
I'm sorry to said that, but this is Dovecot... Maybe with little modifications, but this is Dovecot :)
Could you elaborate what kind of modifications you made? Especially the connection closing is of real interest for me.
thanks Henry
Am Donnerstag, den 04.06.2009, 14:53 +0200 schrieb Cédric Laruelle:
Reproduced on 1.1.14 too and really problematic for me
Curious question:
Why is it so problematic for you?
As stated in my original post you only have to set auth_verbose to yes to get it logged. With that you can always block the attacker with a little script (fail2ban,..).
Henry
-----Message d'origine----- De : dovecot-bounces+laruellec=aiderdonner.com@dovecot.org [mailto:dovecot-bounces+laruellec=aiderdonner.com@dovecot.org] De la part de Noel Butler Envoyé : jeudi 4 juin 2009 12:48 À : henry ritzlmayr Cc : dovecot@dovecot.org Objet : Re: [Dovecot] Dovecot under brute force attack - nice attacker
On Thu, 2009-06-04 at 12:16 +0200, henry ritzlmayr wrote:
Hi List,
optimizing the configuration on one of our servers (which was hit by a brute force attack on dovecot) showed an odd behavior.
Dovecot Version 1.0.7 (CentOS 5.2)
The short story: On one of our servers an attacker did a brute force attack on dovecot (pop3). Since the attacker closed and reopened the connection after every user/password combination the logs showed many lines like this: dovecot: pop3-login: Aborted login: user=<test>,......
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
Verified with 1.1.6 as well, nice catch Henry.
on 6-4-2009 3:48 AM Noel Butler spake the following:
On Thu, 2009-06-04 at 12:16 +0200, henry ritzlmayr wrote:
Hi List,
optimizing the configuration on one of our servers (which was hit by a brute force attack on dovecot) showed an odd behavior.
Dovecot Version 1.0.7 (CentOS 5.2)
The short story: On one of our servers an attacker did a brute force attack on dovecot (pop3). Since the attacker closed and reopened the connection after every user/password combination the logs showed many lines like this: dovecot: pop3-login: Aborted login: user=<test>,......
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
Verified with 1.1.6 as well, nice catch Henry.
1.1.15 gives me one log entry, but lists the number of failed login attemps;
Jun 4 10:16:56 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<username>, method=PLAIN, rip=192.168.1.19, lip=192.168.0.1 Jun 4 10:18:10 mail dovecot: pop3-login: Aborted login (auth failed, 2 attempts): user=<username>, method=PLAIN, rip=192.168.1.19, lip=192.168.0.1
On Jun 4, 2009, at 6:16 AM, henry ritzlmayr wrote:
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries.
With v1.2+ the login failure delay grows after each failed login.
If I enable auth_verbose every attempt gets logged, but if I read the docs correctly this option should only be used for figuring out why authentication isn't working.
auth_debug is for figuring out why it's not working. auth_verbose is
useful if you actually care about logging that information. I guess in
your case you would care.
Question: Is there any way to close the connection after the first wrong user/pass combination. So an attacker would be forced to reopen it?
I think the growing delay is a better idea.
Question: Is there any way to close the connection after the first wrong user/pass combination. So an attacker would be forced to reopen it?
I think the growing delay is a better idea.
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file? This would be much easier to detect/monitor on an upfront firewall/IDS. I agree that each service should care about its own security but some of us have certain sw/hw in front which also should be able to detect such an attempt. By just delaying the next try I guess it will be tough to detect this upfront.
Henry
On Thu, 2009-06-04 at 18:13 +0200, henry ritzlmayr wrote:
Question: Is there any way to close the connection after the first wrong user/pass combination. So an attacker would be forced to reopen it?
I think the growing delay is a better idea.
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Yes, more settings in config file does hurt. There are way too many of them already. But passdb could perhaps return "disconnect" field if authentication failed..
Am Donnerstag, den 04.06.2009, 12:23 -0400 schrieb Timo Sirainen:
On Thu, 2009-06-04 at 18:13 +0200, henry ritzlmayr wrote:
Question: Is there any way to close the connection after the first wrong user/pass combination. So an attacker would be forced to reopen it?
I think the growing delay is a better idea.
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Yes, more settings in config file does hurt. There are way too many of them already. But passdb could perhaps return "disconnect" field if authentication failed..
I am not that familiar with returning extra fields using passdb, but wouldn't this be even more complicated. Since pam for example doesn't even support this and it also depends on the password database ( as read on http://wiki.dovecot.org/PasswordDatabase/ExtraFields )?
Henry
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Is that not the wrong approach? I mean: all you wanted is to have a log entry showing when there was a username/password mismatch when logging in. And you found out that with normal logging options that log entry only shows up if the connection get's disconnected. Right? So would it not be better to have an option to log ANY username/password login mismatch even if the user/attacker does not disconnect?
This would be much easier to detect/monitor on an upfront firewall/IDS.
A disconnect on TCP/IP level is easier to detect/monitor? How? Without logging or without inspecting the communication channel you are pretty much lost. Correct me if I am wrong.
I agree that each service should care about its own security but some of us have certain sw/hw in front which also should be able to detect such an attempt. By just delaying the next try I guess it will be tough to detect this upfront.
Henry
Steve
GMX FreeDSL mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.! http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a
Am Donnerstag, den 04.06.2009, 18:27 +0200 schrieb Steve:
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Is that not the wrong approach? I mean: all you wanted is to have a log entry showing when there was a username/password mismatch when logging in. And you found out that with normal logging options that log entry only shows up if the connection get's disconnected. Right? So would it not be better to have an option to log ANY username/password login mismatch even if the user/attacker does not disconnect?
Right, logging a wrong username/password should always be done. That's one reason why I favor a disconnect. Almost any service logs a disconnect - so does dovecot.
This would be much easier to detect/monitor on an upfront firewall/IDS.
A disconnect on TCP/IP level is easier to detect/monitor? How? Without logging or without inspecting the communication channel you are pretty much lost. Correct me if I am wrong.
Any serious firewall those days has the capability to track the amount of connection attempts on any port without knowing whats in the packet. By just delaying the next try within the service the firewall would have to inspect the packets to know whats going on. So by disconnecting an intruder (and forcing him to reconnect) its easy to detect such an attack on the firewall/IDS by just counting the amount of connects in a given timeframe. Within iptables for example this can accomplished with "--hashlimit 5/Minute".
Henry
On Thu, 2009-06-04 at 18:58 +0200, henry ritzlmayr wrote:
Am Donnerstag, den 04.06.2009, 18:27 +0200 schrieb Steve:
The Idea is good but I guess an option to just disconnect the attacker wouldn't hurt in the config file?
Is that not the wrong approach? I mean: all you wanted is to have a log entry showing when there was a username/password mismatch when logging in. And you found out that with normal logging options that log entry only shows up if the connection get's disconnected. Right? So would it not be better to have an option to log ANY username/password login mismatch even if the user/attacker does not disconnect?
Right, logging a wrong username/password should always be done. That's one reason why I favor a disconnect. Almost any service logs a disconnect - so does dovecot.
Also, I think not disconnecting is only supportive to those who want to run scripts as such and perform brute force attacks or hacks, I can see no reason why, if you fail as user unknown, you should not be dropped.
On Thu, Jun 04, 2009 at 12:16:00PM +0200, henry ritzlmayr wrote:
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
I see the same thing with Dovecot 1.2.rc4 on CentOS 5, but pam logs every failed attempt:
Jun 4 09:37:40 sbh16 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Jun 4 09:37:40 sbh16 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=zzz rhost=127.0.0.1 Jun 4 09:38:05 sbh16 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Jun 4 09:38:05 sbh16 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=mmm rhost=127.0.0.1
So, fail2ban will block based on the pam log.
-- Mark Sapiro mark at msapiro net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am Donnerstag, den 04.06.2009, 09:51 -0700 schrieb Mark Sapiro:
On Thu, Jun 04, 2009 at 12:16:00PM +0200, henry ritzlmayr wrote:
The problem: If the attacker wouldn't have closed and reopened the connection no log would have been generated and he/she would have endless tries. Not even an iptables/hashlimit or fail2ban would have kicked in.
How to reproduce: telnet dovecot-server pop3 user test pass test1 user test pass test2 ... QUIT ->Only the last try gets logged.
I see the same thing with Dovecot 1.2.rc4 on CentOS 5, but pam logs every failed attempt:
Jun 4 09:37:40 sbh16 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Jun 4 09:37:40 sbh16 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=zzz rhost=127.0.0.1 Jun 4 09:38:05 sbh16 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown Jun 4 09:38:05 sbh16 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=mmm rhost=127.0.0.1
So, fail2ban will block based on the pam log.
Good to know. We have ldap here, but it certainly would be possible to do the authentication through pam->ldap.
thanks Henry
I'm not sure I got everything here... Actually, I said it was a problem for me, but it's not really. Indeed, by just changing the setting auth_verbose to yes (but leaving auth-debug to no), I get a line like auth-worker(default): pam(USER,HOST): pam_authenticate() failed: Authentication failure (password mismatch?) without any extra log information I don't need (only auth_debug would produce such info). This log is perfectly catchable by fail2ban or any other system.
So to me, the only "problem" is the documentation as mentioned initially by Henri which says : # More verbose logging. Useful for figuring out why authentication isn't # working. auth_verbose = yes
Am I missing something ?
Cédric
On Jun 5, 2009, at 4:58 AM, Cédric Laruelle wrote:
So to me, the only "problem" is the documentation as mentioned
initially by Henri which says :More verbose logging. Useful for figuring out why authentication
isn't
working.
auth_verbose = yes
OK, how about: http://hg.dovecot.org/dovecot-1.2/rev/a9d3108d0cec
That would be just crystal clear and perfect for me :)
Cédric
-----Message d'origine----- De : Timo Sirainen [mailto:tss@iki.fi] Envoyé : vendredi 5 juin 2009 16:07 À : Cédric Laruelle Cc : dovecot@dovecot.org Objet : Re: [Dovecot] Dovecot under brute force attack - nice attacker
On Jun 5, 2009, at 4:58 AM, Cédric Laruelle wrote:
So to me, the only "problem" is the documentation as mentioned
initially by Henri which says :More verbose logging. Useful for figuring out why authentication
isn't
working.
auth_verbose = yes
OK, how about: http://hg.dovecot.org/dovecot-1.2/rev/a9d3108d0cec
participants (8)
-
Cédric Laruelle
-
henry ritzlmayr
-
Lenthir
-
Mark Sapiro
-
Noel Butler
-
Scott Silva
-
Steve
-
Timo Sirainen