Re: [Dovecot] Logging passwords on auth failure/dealing with botnets
Michael Smith writes:
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP.
Yeah, distributed BFDs are tough to block unless you can characterize the clients well.
That leaves us back to getting dovecot to log the tried password for unknown users.
Another tactic might be to hook in a authentication script:
http://wiki2.dovecot.org/AuthDatabase/CheckPasswordYou can run this as an external plugin and won't have to muck into the dovecot innards. From here, you can log attempts, keep track of bad IPs, or take action if you spot a username/password combination that merits instant blacklisting.
Joseph Tam jtam.home@gmail.com
On 2013-08-30 7:55 PM, Joseph Tam jtam.home@gmail.com wrote:
Michael Smith writes:
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP.
Yeah, distributed BFDs are tough to block unless you can characterize the clients well.
Wonder if there's a way to leverage Stan Hoeppner's most excellent botnet killer to reject AUTHs from the same types of clients before they even try?
Stan?
--
Best regards,
*/Charles/*
On 01 Sep 2013, at 09:00 , Charles Marcus CMarcus@Media-Brokers.com wrote:
On 2013-08-30 7:55 PM, Joseph Tam jtam.home@gmail.com wrote:
Michael Smith writes:
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP.
Yeah, distributed BFDs are tough to block unless you can characterize the clients well.
Wonder if there's a way to leverage Stan Hoeppner's most excellent botnet killer to reject AUTHs from the same types of clients before they even try?
Looking at Stan's pcre file, it seems like it's a brilliant tool for anyone who is using an older version of postfix that does not support postscreen and cannot upgrade. Anyone using a postscreen-capable postfix should use postscreen with zen and would gain very little (if anything) from adding this.
Really, postscreen is the best thing to come along for postfix since... I dunno, auth?
As far as the botnets go, at a certain point it is essentially worrying about "too many notes". Yes, there's a lot of failed attempts in the logs, but that't the thing, they are FAILED attempts. postfix already does a good job of dealing with those (for example, anvil).
If there are so many bonnet connections that they are overwhelming your server and legitimate users can't login and legitimate email is being constantly and repeatedly temp-failed, then you start having to look into something else. But even if you are seeing thousands of connections a day, that is unlikely to affect your server.
Denyssh might be worth looking into, as I recall it has a feature to distribute a ban list which can be somewhat effective against botnets, if you are willing to trust the essentially crowd-sourced list of hosts to block. If your server is small and non-commercial, this might be acceptable. I'd be hesitant to do it otherwise. I'd probably end up doing it anyway, but I'd at least hesitate.
(I may be remembering something other than DenySsh)
-- "640K ought to be enough RAM for anybody." - Bill Gates, 1981
On 9/1/2013 10:00 AM, Charles Marcus wrote:
On 2013-08-30 7:55 PM, Joseph Tam jtam.home@gmail.com wrote:
Michael Smith writes:
We're already running fail2ban, but it doesn't seem that effective against botnets, when they only do one attempt per IP.
Yeah, distributed BFDs are tough to block unless you can characterize the clients well.
Wonder if there's a way to leverage Stan Hoeppner's most excellent botnet killer to reject AUTHs from the same types of clients before they even try?
Stan?
The objective of Stan's list is to reject dynamic hosts, because the overwhelming majority of dynamic hosts trying to send via SMTP are zombies.
For dovecot, the situation is quite different. Blocking all dynamic IPs would be an obvious mistake.
-- Noel Jones
On 9/1/2013 2:59 PM, Noel wrote:
On 9/1/2013 10:00 AM, Charles Marcus wrote: ...
Wonder if there's a way to leverage Stan Hoeppner's most excellent botnet killer to reject AUTHs from the same types of clients before they even try?
The objective of Stan's list is to reject dynamic hosts, because the overwhelming majority of dynamic hosts trying to send via SMTP are zombies.
Yep.
For dovecot, the situation is quite different. Blocking all dynamic IPs would be an obvious mistake.
Yep.
Unfortunately the hosts we want to block at the public SMTP port are the same hosts that are your typical legitimate IMAP clients.
To do something similar to Postscreen with Dovecot would require Timo writing code similar to Postscreen that would look for IMAP protocol violations or similar signs that the client is a bot and not a legit MUA.
But given that Dovecot is designed for inherently greater client parallelism (thousands) than Postfix smtpd (100), I don't think anyone is rejecting clients due to running out of auth process slots taken by bots.
As others have suggested this seems a log clutter issue, nothing more.
-- Stan
On 2013-09-02 4:12 AM, Stan Hoeppner stan@hardwarefreak.com wrote:
As others have suggested this seems a log clutter issue, nothing more.
Well, it would be nice to have some way to stop brute force attacks (rather than just letting one run rampant until the attacker gives up) - ie, attempted FAILED logins to the same user account.
Maybe a two pronged approach...
A whitelist that whitelists IP+username for *successful* logins (maybe with a configurable age-out option) to prevent the real user from being locked out if accessing from an IP on the whitelist, and
A blacklist that when triggered (x failed login attempts in x seconds), doesn't try to block the IP, but rather prevents login attempts for that user account from even reaching the AUTH stage - *unless* the IP in question is in the whitelist.
The question is, where is this best dealt with - firewall (can fail2ban do anything like this?), or would it have to be done in dovecot?
--
Best regards,
*/Charles/*
On 2013-09-02 9:35 AM, Charles Marcus CMarcus@Media-Brokers.com wrote:
Well, it would be nice to have some way to stop brute force attacks (rather than just letting one run rampant until the attacker gives up)
And I left out the obvious "... or worst case, is successful ..." - which obviously is why we are having this conversation in the first place...
Maybe a two pronged approach...
- A whitelist that whitelists IP+username for *successful* logins (maybe with a configurable age-out option)
Of course there should be a default age-out option (24 hours? 48 hours? longer? shorter?), but should it be configurable?
- A blacklist that when triggered (x failed login attempts in x seconds)
Configurable?
Maybe to make it simplest, some sane defaults could be decided on, and hard code them, with a single config option to enable or disable botnet brute-force protection?
--
Best regards,
*/Charles/*
On 9/2/2013 8:35 AM, Charles Marcus wrote:
- A blacklist that when triggered (x failed login attempts in x seconds), doesn't try to block the IP, but rather prevents login attempts for that user account from even reaching the AUTH stage - *unless* the IP in question is in the whitelist.
The question is, where is this best dealt with - firewall (can fail2ban do anything like this?), or would it have to be done in dovecot?
I'm already using fail2ban to block IPs that have too many AUTH failures.
Fail2ban is pretty flexible -- it watches the log and counts strings you specify, then runs a command or script you specify. If the username is logged, I suppose it's possible to run something to temporarily disable that user.
It would be a lot easier to deploy if some sort of blocker were built into dovecot -- after X number of failures during Y seconds, fail all future attempts for the account for T seconds. Maybe reset the timer on each attempt during the blackout period so the timer never expires on the persistent distributed brute force attacks. I suppose there would also need to be a way to whitelist IPs so the account owner can get in.
-- Noel Jones
On 2013-09-02 5:11 PM, Noel noeldude@gmail.com wrote:
It would be a lot easier to deploy if some sort of blocker were built into dovecot -- after X number of failures during Y seconds, fail all future attempts for the account for T seconds.
But again, totally blocking all AUTH attempts like that even blocks valid attempts by the real user.
Having a whitelist that tracks valid user+IP logins would prevent that.
Maybe reset the timer on each attempt during the blackout period so the timer never expires on the persistent distributed brute force attacks. I suppose there would also need to be a way to whitelist IPs so the account owner can get in.
Ummm... maybe you didn't read what I wrote? That is what I meant by 'whitelist' in item 1... ;)
On 2013-09-02 9:59 PM, other@ahhyes.net other@ahhyes.net wrote:
Is there anyway to limit the number of auth attempts allowed in a single session? The reason for this is because I have "fail2ban" setup to firewall out any IP addresses that repeatedly auth fails.
Is there a way to tell fail2ban to block connection attempts NOT based on IP, but based on other values or value combinations (like user+IP)?
On 9/3/2013 5:12 AM, Charles Marcus wrote:
Ummm... maybe you didn't read what I wrote? That is what I meant by 'whitelist' in item 1... ;)
Yes, I think we're on the same page.
On 2013-09-02 9:59 PM, other@ahhyes.net other@ahhyes.net wrote:
Is there anyway to limit the number of auth attempts allowed in a single session? The reason for this is because I have "fail2ban" setup to firewall out any IP addresses that repeatedly auth fails.
Is there a way to tell fail2ban to block connection attempts NOT based on IP, but based on other values or value combinations (like user+IP)?
I'm not sure if fail2ban can trigger on a value combination, but it should be able to pull a username out of a log line and run some command on the username.
Basically whatever you can do with a regexp and a single log line. Pull any value out of the log line and run a command or script with the value (usually an IP, but can be anything in that line).
On 2013-09-01 3:59 PM, Noel noeldude@gmail.com wrote:
The objective of Stan's list is to reject dynamic hosts, because the overwhelming majority of dynamic hosts trying to send via SMTP are zombies.
For dovecot, the situation is quite different. Blocking all dynamic IPs would be an obvious mistake.
Oops... you're right of course, sorry for the noise...
--
Best regards,
*/Charles/*
participants (5)
-
Charles Marcus
-
Joseph Tam
-
LuKreme
-
Noel
-
Stan Hoeppner