[Dovecot] Auth failure delays
Currently Dovecot works like this when authentication fails:
- the delay is always at least auth_failure_delay seconds (default: 2s)
- each failed attempt doubles the delay for that specific imap/pop3 connection (no such delays for e.g. smtp)
- the delay's upper limit is 3 minutes
For v2.0 I was planning on making dovecot-auth process do these checks and keeping the state in anvil process:
- the delay is always at least auth_failure_delay seconds (default: 2s)
- for each remote IP address the delay is doubled, regardless of how the request comes (imap, pop3, smtp, etc).
- the delay's upper limit is .. hardcoded to 15 secs? i kind of hate the thought of making this configurable.
- each successful authentication from the IP resets the IP's delay
- the delay happens before authentication is even attempted, so even successful auth attempts will have the delay (unless of course there haven't been auth failures from that IP)
If the upper limit is 15 secs, that means max. 240 auth attempts per hour per IP. The reason I was thinking 15 secs is because I have some vague memories about Thunderbird dropping connection after 15 or maybe 30 seconds of idling.
If user has one successful login, it's of course possible to get around the delay doubling by just doing failed attempt -> successful attempt -> failed -> success -> etc. But probably no one is really going to try to do that, and even if they did it's still not that bad. The second successful login will still have that 2 second delay before it resets the delay. So that's still max one auth/2 seconds or max. 1800 auth attempts/hour.
Any thoughts?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 6 Nov 2009, Timo Sirainen wrote:
Any thoughts?
The only two remarks I have are that some well-known IPs should be able to bypass this check, e.g. NATed gateways of the organisation and that external IDSs (e.g. fail2ban) should be able to pick up the possible breakin, maybe you can configure Dovecot to send failed logins to syslog, too, even though it logs to file normally.
My subjective feeling is that such "hammering" attacks from a single host origin from a misconfigured auto-POPer than an attack nowadays.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSvfMdXWSIuGy1ktrAQLKTAf/e7cQ6ONK0HuqkBeg3NBotXsRf0qeeOmZ w857YOQJqqGVrnCBQVaA7OWVBlAMhfpM3Nc/WMth4/vooXz8wWp3Y+Bqpw1Iex1M qOI2nIX+Jep4a8/3XExmWlh5gsQRWQRhkWNY12nu2jqEe0QT4VgqrMIs7YPgXTel fmWSWHA3HySKiRbP+pwzPZH1B6aEAysK3W/BHycS5/HWab4E60LiyncBtMm24eKZ dRZ1NqOhknNX8E6lbnNagQL/J1Cnge1drT0/FvYNunuMPpgWVopBw73sifC/Xh9A RhOIjcw56MN0CNvJBBW692FGNMjiSanHJztLb/1iop8LT4+bmvrWvA== =W9T5 -----END PGP SIGNATURE-----
On Mon, 2009-11-09 at 09:01 +0100, Steffen Kaiser wrote:
Any thoughts?
The only two remarks I have are that some well-known IPs should be able to bypass this check, e.g. NATed gateways of the organisation
Hmm. That seems like way too much trouble. Even just on/off setting annoys me.
and that external IDSs (e.g. fail2ban) should be able to pick up the possible breakin, maybe you can configure Dovecot to send failed logins to syslog, too, even though it logs to file normally.
This also seems kind of weird.. Why couldn't fail2ban or whatever just parse the normal log files? Or maybe you should just configure syslog to log to those two different locations?
On Mon, 2009-11-09 at 16:41 -0500, Timo Sirainen wrote:
On Mon, 2009-11-09 at 09:01 +0100, Steffen Kaiser wrote:
Any thoughts?
The only two remarks I have are that some well-known IPs should be able to bypass this check, e.g. NATed gateways of the organisation
Hmm. That seems like way too much trouble. Even just on/off setting annoys me.
Maybe:
- If hash(user+password) has already been tried from the IP within n minutes, trying it again wouldn't increase the delay.
But that might increase the memory usage too much.. But maybe it could be limited to just n hashes and it wouldn't be too bad.
participants (2)
-
Steffen Kaiser
-
Timo Sirainen