Re: [Dovecot] Logging passwords on auth failure/dealing with botnets
"Michael Smith (DF)" writes:
Or another option, is there any good DNS based RBLs for botnet IPs, and is there any way to tie that in to the dovecot auth system? I've been looking for botnet rbls, but what I've found so far doesn't seem to work very well. Most of the IPs that I've had to firewall don't exist in them.
/dev/rob0 writes:
The problem with using XBL, anyway, is that you might have legitimate logins from listed hosts. Example: a traveler using hotel wifi. We (TINW) really would need a new DNSBL type (or a special result) for this sort of abuse.
It's a nice idea, worth building upon, if someone can fund it (or find the time to develop it, which really amounts to the same thing.) Imagine also a Dovecot network of reporters, where brute force attempts worldwide are reported from Dovecots to the DNSBL, not merely a one-way tie in.
I'd also suggest listing SSH brute force attacks in the same DNSBL, possibly with a different result (127.0.0.$port, so IMAP attackers list as 127.0.0.143, SSH attackers as 127.0.0.22. Yes, we'd have to incorporate the third quad for ports > 255, but the general idea is for result codes to be both machine and human readable as much as possible.)
I use bl.blocklist.de as a DNSRBL for ssh BFD, but I think it also detects BFD for other protocols:
http://www.blocklist.de/en/index.htmlThe nice thing about this RBL is that you can also contribute by configuring your Fail2Ban/DenyHost to forward logs to the maintainers, to widen the detection network. I get about a 60% hit on ssh BFD attacks.
I also found
http://openbl.orgbut they distribute it as a downloadable file rather than as a DNSRBL. Maybe I can introduce the latter to the former.
Joseph Tam <jtam.home@gmail.com>
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP. Add that on top of load balancing between many servers... We've setup some rules to help, but still not that great.
I've checked out several DNS BLs (those listed here, and some not), and at the most they have about 15-20 IPs out of the 8000+ that we've manually identified, and blocked, as botnet behavior. So, none of them seem effective/beneficial to us right now.
That leaves us back to getting dovecot to log the tried password for unknown users. I'll admit that C is not my strong suit, but after poking around I've come up with a patch that appears to work. It hasn't been stress tested yet, so I don't know it's long term stability. Maybe someone more intimately familiar with the Dovecot code can review it, and maybe this could make it into the code base. This patch is against Dovecot 2.2.4, as that is what we have deployed at the moment. It would be weeks before we could begin to deploy to Dovecot 2.2.5.
Also, is there a way to make the auth system report successful auths, with no option to report the password (or maybe ONLY report the hash if password debugging is enabled)? It's currently impossible to identify when a bot makes a successful auth. Dovecot doesn't report it, and postfix doesn't report it. Postfix only reports the authentication IF a message is actually sent through. These bots are only connecting, sending the auth command, and quitting. My best guess, based on the bulk of auth failures for a user, and when that user is used by a botnet is 1-8 weeks. So, if we could identify the bot's successful auth, we could warn the customer and/or force a password change before the account is used to send hundreds of thousands of spam.
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Joseph Tam Sent: Thursday, August 22, 2013 11:30 PM To: dovecot@dovecot.org Subject: Re: [Dovecot] Logging passwords on auth failure/dealing with botnets
"Michael Smith (DF)" writes:
Or another option, is there any good DNS based RBLs for botnet IPs, and is there any way to tie that in to the dovecot auth system? I've been looking for botnet rbls, but what I've found so far doesn't seem to work very well. Most of the IPs that I've had to firewall don't exist in them.
/dev/rob0 writes:
The problem with using XBL, anyway, is that you might have legitimate logins from listed hosts. Example: a traveler using hotel wifi. We (TINW) really would need a new DNSBL type (or a special result) for this sort of abuse.
It's a nice idea, worth building upon, if someone can fund it (or find the time to develop it, which really amounts to the same thing.) Imagine also a Dovecot network of reporters, where brute force attempts worldwide are reported from Dovecots to the DNSBL, not merely a one-way tie in.
I'd also suggest listing SSH brute force attacks in the same DNSBL, possibly with a different result (127.0.0.$port, so IMAP attackers list as 127.0.0.143, SSH attackers as 127.0.0.22. Yes, we'd have to incorporate the third quad for ports > 255, but the general idea is for result codes to be both machine and human readable as much as possible.)
I use bl.blocklist.de as a DNSRBL for ssh BFD, but I think it also detects BFD for other protocols:
http://www.blocklist.de/en/index.htmlThe nice thing about this RBL is that you can also contribute by configuring your Fail2Ban/DenyHost to forward logs to the maintainers, to widen the detection network. I get about a 60% hit on ssh BFD attacks.
I also found
http://openbl.orgbut they distribute it as a downloadable file rather than as a DNSRBL. Maybe I can introduce the latter to the former.
Joseph Tam <jtam.home@gmail.com>
On 30.8.2013, at 20.54, Michael Smith (DF) <msmith@datafoundry.com> wrote:
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP. Add that on top of load balancing between many servers... We've setup some rules to help, but still not that great.
I've checked out several DNS BLs (those listed here, and some not), and at the most they have about 15-20 IPs out of the 8000+ that we've manually identified, and blocked, as botnet behavior. So, none of them seem effective/beneficial to us right now.
That leaves us back to getting dovecot to log the tried password for unknown users. I'll admit that C is not my strong suit, but after poking around I've come up with a patch that appears to work. It hasn't been stress tested yet, so I don't know it's long term stability. Maybe someone more intimately familiar with the Dovecot code can review it, and maybe this could make it into the code base. This patch is against Dovecot 2.2.4, as that is what we have deployed at the moment. It would be weeks before we could begin to deploy to Dovecot 2.2.5.
I guess it doesn't hurt to add this feature for everyone: http://hg.dovecot.org/dovecot-2.2/rev/4ce8f47d20af http://hg.dovecot.org/dovecot-2.2/rev/1f9294fbb118
Also, is there a way to make the auth system report successful auths, with no option to report the password (or maybe ONLY report the hash if password debugging is enabled)? It's currently impossible to identify when a bot makes a successful auth. Dovecot doesn't report it, and postfix doesn't report it. Postfix only reports the authentication IF a message is actually sent through. These bots are only connecting, sending the auth command, and quitting. My best guess, based on the bulk of auth failures for a user, and when that user is used by a botnet is 1-8 weeks. So, if we could identify the bot's successful auth, we could warn the customer and/or force a password change before the account is used to send hundreds of thousands of spam.
I'm not sure what you mean by this. Log the password also for successful connections? How would that help?
participants (3)
-
Joseph Tam
-
Michael Smith (DF)
-
Timo Sirainen