Re: Disconnecting unauthenticated IMAP entities faster?

[Joseph Tam]

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  
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 

Re: Disconnecting unauthenticated IMAP entities faster?

[Sami Ketola]

> On 18 May 2018, at 20.19, David Hubbard  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  
is just for situations like this.

Sami

Disconnecting unauthenticated IMAP entities faster?

[David Hubbard]

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