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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20180518/cc343af3/attachment.html>
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 <jtam.home at gmail.com>