Disconnecting unauthenticated IMAP entities faster?
Hello, given the 2015 revision date, I was curious if anyone can confirm https://wiki2.dovecot.org/Timeouts is still accurate where the 'before login' IMAP timeout remains hard coded?
We're having an issue where blocks of IP's from China and similar locations are crawling IP ranges trying common login credentials, and hanging the connections open in the process. We have clients who have large numbers of employees at single locations, so it isn't possible to reduce the mail_max_userip_connections (assuming it even applies to pre-auth sessions) to a low value. The end result is these connections chew up all the imap-login processes because they sit there until the three-minute timeout is hit, blocking legit users. The only workaround is to raise both the imap and imap-login processes to a massive amount to support all the pre-auth hung open connections.
It would be a lot easier to find a reasonable process limit if we could boot these unauthenticated connections off in a more reasonable amount of time, like 5-10 seconds, but I'm not seeing a way to accomplish that?
Thanks
On 18 May 2018, at 20.19, David Hubbard dhubbard@dino.hostasaurus.com wrote:
Hello, given the 2015 revision date, I was curious if anyone can confirm https://wiki2.dovecot.org/Timeouts is still accurate where the 'before login' IMAP timeout remains hard coded?
We're having an issue where blocks of IP's from China and similar locations are crawling IP ranges trying common login credentials, and hanging the connections open in the process. We have clients who have large numbers of employees at single locations, so it isn't possible to reduce the mail_max_userip_connections (assuming it even applies to pre-auth sessions) to a low value. The end result is these connections chew up all the imap-login processes because they sit there until the three-minute timeout is hit, blocking legit users. The only workaround is to raise both the imap and imap-login processes to a massive amount to support all the pre-auth hung open connections.
It would be a lot easier to find a reasonable process limit if we could boot these unauthenticated connections off in a more reasonable amount of time, like 5-10 seconds, but I'm not seeing a way to accomplish that?
https://github.com/PowerDNS/weakforced https://github.com/PowerDNS/weakforced is just for situations like this.
Sami
On Fri, 18 May 2018, Sami Ketola wrote:
It would be a lot easier to find a reasonable process limit if we could boot these unauthenticated connections off in a more reasonable amount of time, like 5-10 seconds, but I'm not seeing a way to accomplish that?
https://github.com/PowerDNS/weakforced https://github.com/PowerDNS/weakforced is just for situations like this.
It may be, but it's good to dial back the timeouts to something
reasonable, even for legitimate hosts. Maybe it's stipulated by RFC,
but 3 minutes is a lot of time to wait for a password.
I did have a patch I applied to an old version of Dovecot to 30s, so
I don't know if it will works without modification the version the OP
has (the seocnd define looks like it has to be tweaked for 5-10s), or
whether it has been superceded by some other config setting, but this
was the patch
--------------------------------------------------------------------------------
diff -r -U0 a/src/lib-master/master-interface.h b/src/lib-master/master-interface.h
--- a/src/lib-master/master-interface.h Mon Jun 2 04:50:10 2014
+++ b/src/lib-master/master-interface.h Sat Feb 14 18:41:39 2015
@@ -99,1 +99,1 @@
-#define MASTER_LOGIN_TIMEOUT_SECS (30)
+#define MASTER_LOGIN_TIMEOUT_SECS (3*60)
@@ -101,1 +101,1 @@
-#define MASTER_AUTH_SERVER_TIMEOUT_SECS (MASTER_LOGIN_TIMEOUT_SECS<<1)
+#define MASTER_AUTH_SERVER_TIMEOUT_SECS (MASTER_LOGIN_TIMEOUT_SECS - 30)
Joseph Tam
participants (3)
-
David Hubbard
-
Joseph Tam
-
Sami Ketola