[Dovecot] Delay on failed pw attempts
Hi,
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
-- Dean Brooks dean@iglou.com
On Tue, 2008-01-01 at 15:59 -0500, Dean Brooks wrote:
Hi,
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
Failed auth requests are put to a queue that's flushed every 2 seconds. So there is already a delay. I don't think it's a good idea to increase it up from 2 seconds, it just gets annoying when you type the wrong password accidentally.
Although I suppose I could change the code so that it always waits 2 seconds instead of flushing all of them.
On Tue, 1 Jan 2008, Timo Sirainen wrote:
On Tue, 2008-01-01 at 15:59 -0500, Dean Brooks wrote:
Hi,
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
Failed auth requests are put to a queue that's flushed every 2 seconds. So there is already a delay. I don't think it's a good idea to increase it up from 2 seconds, it just gets annoying when you type the wrong password accidentally.
I'd think the increase in effort required for a dictionary attack would outweigh the infrequent inconvenience to valid users.
Although I suppose I could change the code so that it always waits 2 seconds instead of flushing all of them.
Any reason that '2 seconds' couldn't be configurable (with a default of 2)? In my situation, I'm the only user of my system, and I use reasonably secure passwords, so brute-force doesn't really scare me. As a sysadmin at an ISP or company with (too-)lenient password requirements, on the other hand, it'd be nice to slow an attack by a larger factor.
Best, Ben
On 1/1/2008, Benjamin R. Haskell (dovecot@benizi.com) wrote:
Any reason that '2 seconds' couldn't be configurable (with a default of 2)?
What I'd like to see is something incremental, like:
n=2 Password fails - wait n secs, n=n+1 2nd failure: wait n secs, n=n+1 etc...
This way the delay gets longer and longer with every failure.
--
Best regards,
Charles
On Tue, Jan 01, 2008 at 11:22:31PM +0200, Timo Sirainen wrote:
On Tue, 2008-01-01 at 15:59 -0500, Dean Brooks wrote:
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
Failed auth requests are put to a queue that's flushed every 2 seconds. So there is already a delay. I don't think it's a good idea to increase it up from 2 seconds, it just gets annoying when you type the wrong password accidentally.
I think the majority of Dovecot users would propose that 2 seconds is much too short, and that the annoyance of an occasional rare wrong password is of little concern given the high number of dictionary attacks occuring nowadays.
This *really* needs to be configurable. For our site, I would probably set the delay to 15 seconds. Others might want it at the very low 2 seconds like you suggest.
I suppose I could spend the development time to do this and then post my patch on the Wiki for everyone who needs it, but it seems like this would be better done in the official sources instead of requiring everyone to download a one-off patch.
-- Dean Brooks dean@iglou.com
On Tue, 2008-01-01 at 16:47 -0500, Dean Brooks wrote:
Failed auth requests are put to a queue that's flushed every 2 seconds. So there is already a delay. I don't think it's a good idea to increase it up from 2 seconds, it just gets annoying when you type the wrong password accidentally.
I think the majority of Dovecot users would propose that 2 seconds is much too short, and that the annoyance of an occasional rare wrong password is of little concern given the high number of dictionary attacks occuring nowadays.
This *really* needs to be configurable. For our site, I would probably set the delay to 15 seconds. Others might want it at the very low 2 seconds like you suggest.
I don't really like adding settings that just tweak a small detail, but I guess there's no good default value to this then. v1.1 has now auth_failure_delay setting.
For v1.0 you can change src/auth/auth-request-handler.c line:
to_auth_failures = timeout_add(2000, auth_failure_timeout, NULL);
On 1 Jan 2008, at 21:22, Timo Sirainen wrote:
On Tue, 2008-01-01 at 15:59 -0500, Dean Brooks wrote:
Hi,
Is there a way, or can a way be added, to add an
"auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
Failed auth requests are put to a queue that's flushed every 2
seconds. So there is already a delay. I don't think it's a good idea to
increase it up from 2 seconds, it just gets annoying when you type the wrong password accidentally.Although I suppose I could change the code so that it always waits 2 seconds instead of flushing all of them.
Actually, a better method which would not inconvenience real users is
to have an accumalative delay, i.e. the first error has a 1 second
delay, the second 2 seconds, the third 4 seconds and so on. This
should tar-pit any brute force attack, at least until the script
kiddies just blast the server with a huge number of new connections to
do the job.
Steve
Computer Systems Administrator, E-Mail:-steve@earth.ox.ac.uk
Department of Earth Sciences, Tel:- +44 (0)1865
282110
University of Oxford, Parks Road, Oxford, UK. Fax:- +44 (0)1865
272072
On Tue, Jan 01, 2008 at 11:21:50PM +0000, Stephen Usher wrote:
Actually, a better method which would not inconvenience real users is
to have an accumalative delay, i.e. the first error has a 1 second
delay, the second 2 seconds, the third 4 seconds and so on. This
should tar-pit any brute force attack, at least until the script
kiddies just blast the server with a huge number of new connections to
do the job.
Unfortunately, most of the dictionary attacks that we've been seeing will open and attack multiple simultaneous connections. After a single attempt, they'll drop the connection and reconnect.
The only way to mitigate the attacks is a long delay even on a single authentication failure.
We can handle most of the load issue through our hardware load-balancers, but ultimately it's the delay after auth failure that is the only real limiting factor.
Ideally, Dovecot would allow finer control over its process forking (specifically maximum simultaneous connections from a single IP, maximum total connections and maximum authentication attempts before disconnect), but I figured I'd probably be pushing my luck asking for all of it at once. :)
Until those features are in place, larger sites have to just cross their fingers and hope that the current rash of attacks will slow over time.
-- Dean Brooks dean@iglou.com
On Tue, 2008-01-01 at 18:38 -0500, Dean Brooks wrote:
On Tue, Jan 01, 2008 at 11:21:50PM +0000, Stephen Usher wrote:
Actually, a better method which would not inconvenience real users is
to have an accumalative delay, i.e. the first error has a 1 second
delay, the second 2 seconds, the third 4 seconds and so on. This
should tar-pit any brute force attack, at least until the script
kiddies just blast the server with a huge number of new connections to
do the job.Unfortunately, most of the dictionary attacks that we've been seeing will open and attack multiple simultaneous connections. After a single attempt, they'll drop the connection and reconnect.
The only way to mitigate the attacks is a long delay even on a single authentication failure.
I'd think that if longer delays become more common, the attackers will just disconnect before the auth reply is received. So maybe I should remove the auth_failure_delay setting after all. A growing delay based on remote IP address would be nice, but it would require keeping track of that information, which pretty much means that there would have to be a new separate process doing that. All of this would be so much easier to implement for v2.0 framework..
Timo Sirainen said the following on 01/02/2008 11:39 AM:
A growing delay based on remote IP address would be nice, but it would require keeping track of that information, which pretty much means that there would have to be a new separate process doing that. All of this would be so much easier to implement for v2.0 framework..
IMHO this stuff is to be handled by IDS and firewall.
Ciao, luigi
-- / +--[Luigi Rosa]-- \
I Veri End-User non sanno mai quello che vogliono, ma sanno sempre quello che il tuo programma non e` in grado di fare.
On 2 Jan 2008, at 10:43, Luigi Rosa wrote:
Timo Sirainen said the following on 01/02/2008 11:39 AM:
A growing delay based on remote IP address would be nice, but it would require keeping
track of that information, which pretty much means that there would have
to be a new separate process doing that. All of this would be so much
easier to implement for v2.0 framework..IMHO this stuff is to be handled by IDS and firewall.
Unfortunately many (most) of the IDS appliances aren't tunable in this
way, they merely use content signatures. Firewalls are not designed to
do this at all. My experience with Cisco kit shows this to be true.
You also have to remember that the people managing the firewall/IDS
aren't necessarily the same people as those who run the mail services
and the latter may not have a direct influence upon the former.
As for if/when Dovecot should get this, well it's not imperative. It's
a feature which would be very nice to have but it's not a deal
breaker. Let's face it, I know of no other IMAP server systems which
currently have it. In this case, if it fits better into the v2.0
framework then it's probably best to wait until then but factor such
sorts of controls into the design at this early stage of development.
Steve
Computer Systems Administrator, E-Mail:-steve@earth.ox.ac.uk
Department of Earth Sciences, Tel:- +44 (0)1865
282110
University of Oxford, Parks Road, Oxford, UK. Fax:- +44 (0)1865
272072
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
-- Dean Brooks dean@iglou.com
I recently installed an application called Fail2Ban (http://www.fail2ban.org), which scans log files and filters out failed login attempts. If a configurable number of failed attempts from the same IP is found, the IP is blocked out via iptables or hosts.deny for some time (default 10 minutes). Works pretty well for SSH, though I'm still waiting for the first attempt on my IMAP or SMTP ports ;-)
So instead of letting a brute force attack continue at a slower pace, Fail2Ban locks out the attacking system for some time, while a legitimate user can mistype his password at least once or twice without penalty. If he continues to mistype his password, he probably deserves to wait ;-)
If anyone want's to try it, a working fail2ban-regex for dovecot 1.05 and mysql is:
failregex = Info: auth-worker\(default\): sql\(.*,<HOST>\): Password mismatch Info: auth-worker\(default\): sql\(.*,<HOST>\): unknown user
Frank
On Tue, 1 Jan 2008, Frank Kintrup wrote:
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
Even if it's not configurable, can a delay be hardcoded to something like, say, 10 or 15 seconds?
-- Dean Brooks dean@iglou.com
I recently installed an application called Fail2Ban (http://www.fail2ban.org), which scans log files and filters out failed login attempts. If a configurable number of failed attempts from the same IP is found, the IP is blocked out via iptables or hosts.deny for some time (default 10 minutes). Works pretty well for SSH, though I'm still waiting for the first attempt on my IMAP or SMTP ports ;-)
Oops, you beat me to it! (-:
Cheers....
Maybe you should write this up on the Dovecot wiki!
-- Asheesh.
-- Most people have a mind that's open by appointment only.
On Tue, 1 Jan 2008, Dean Brooks wrote:
Hi,
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool?
-- Asheesh.
-- Kites rise highest against the wind -- not with it. -- Winston Churchill
On Tue, Jan 01, 2008 at 03:46:23PM -0800, Asheesh Laroia wrote:
On Tue, 1 Jan 2008, Dean Brooks wrote:
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool?
Not everyone runs Linux (i.e. iptables) and Dovecot doesn't appear to have imbedded tcpwrappers support (i.e. forces you to run it under inetd which is not always desirable). One or the other is a prerequisite for fail2ban.
Plus, I don't consider adding these features "added complexity". On the contrary, I feel like ANY software that accepts incoming public TCP connections has an obligation to implement some basic controls to limit the resources it consumes. The lack of these kinds of controls are what result in most application-level DDOS attacks.
In the case of IMAP or POP, a minimum of controls would be max connections, max connections per IP and max auth failures.
Using a program to effectively "tail -f" a logfile in realtime is a hack. Logfile formats change, logfile locations change, not everyone uses syslog, etc. It also assumes that logfiles are stored in a centralized location which is often not the case in a large distributed network. Throw in network load-balancers in a server farm and something like fail2ban becomes a real headache.
Hey, it's just my opinion, but keep in mind some people are running Dovecot in very large environments, and Linux isn't even anywhere in our equation.
-- Dean Brooks dean@iglou.com
On tis, 2008-01-01 at 19:15 -0500, Dean Brooks wrote:
On Tue, Jan 01, 2008 at 03:46:23PM -0800, Asheesh Laroia wrote:
On Tue, 1 Jan 2008, Dean Brooks wrote:
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool?
Not everyone runs Linux (i.e. iptables) and Dovecot doesn't appear to have imbedded tcpwrappers support (i.e. forces you to run it under inetd which is not always desirable). One or the other is a prerequisite for fail2ban.
Plus, I don't consider adding these features "added complexity". On the contrary, I feel like ANY software that accepts incoming public TCP connections has an obligation to implement some basic controls to limit the resources it consumes. The lack of these kinds of controls are what result in most application-level DDOS attacks.
In the case of IMAP or POP, a minimum of controls would be max connections, max connections per IP and max auth failures.
Using a program to effectively "tail -f" a logfile in realtime is a hack. Logfile formats change, logfile locations change, not everyone uses syslog, etc. It also assumes that logfiles are stored in a centralized location which is often not the case in a large distributed network. Throw in network load-balancers in a server farm and something like fail2ban becomes a real headache.
uhm, i'd rather say that it assumed you don't save log files in a centralized location. It assumes you run the log file tail on the same machine as the application itself, but you might have a environment where all log files end up on one centralized machine instead.
Hey, it's just my opinion, but keep in mind some people are running Dovecot in very large environments, and Linux isn't even anywhere in our equation.
-- Dean Brooks dean@iglou.com
Ian Kumlien
-- http://pomac.netswarm.net
On Tue, 1 Jan 2008, Asheesh Laroia wrote:
On Tue, 1 Jan 2008, Dean Brooks wrote:
Hi,
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool?
I fell in the 'use another tool' (fail2ban or similar) camp the last time, but this thread made me wonder:
Does fail2ban allow you to tarpit, rather than outright-ban, IP's? I've always thought tarpitting the better option of the two. Seems sneakier (Fight back without the attacker necessarily knowing you're fighting).
Best, Ben
On Jan 2, 2008 2:33 AM, Benjamin R. Haskell dovecot@benizi.com wrote:
I fell in the 'use another tool' (fail2ban or similar) camp the last time, but this thread made me wonder:
Does fail2ban allow you to tarpit, rather than outright-ban, IP's? I've always thought tarpitting the better option of the two. Seems sneakier (Fight back without the attacker necessarily knowing you're fighting).
fail2ban is just a log processor that is keyed to a netfilter-like method, but modifying it to
"touch /var/tmp/.dovecotFailedAuth/$REMOTE_IP"
and then wrap the pop3/imap login_executable process with a lookup to do this sort of tar pitting with
test -f /var/tmp/.dovecotFailedAuth/$REMOTE_IP && sleep 10
the variable names escape me and the wiki wasn't immediately helpful to my tired eyes, I just couldn't find the wrapper example. if the need is great i could write working perl script to do both ends and work with memcache or something if you have multiple servers.
-- Gabriel Millerd
On Jan 2, 2008 2:33 AM, Benjamin R. Haskell dovecot@benizi.com wrote:
Does fail2ban allow you to tarpit, rather than outright-ban, IP's? I've always thought tarpitting the better option of the two. Seems sneakier (Fight back without the attacker necessarily knowing you're fighting).
Actually I was wrong, if you have netfilter tarpit support compiled in you could do this, though though that aspect isn't fail2ban specific.
-- Gabriel Millerd
participants (10)
-
Asheesh Laroia
-
Benjamin R. Haskell
-
Charles Marcus
-
Dean Brooks
-
Frank Kintrup
-
Gabriel Millerd
-
Ian Kumlien
-
Luigi Rosa
-
Stephen Usher
-
Timo Sirainen