[Dovecot] Lots of pop3-logins

Rodman Frowert rodman at thefrowerts.com
Fri Jun 26 16:55:07 EEST 2009


Well concerning my problem, I adjusted fail2ban so that it can parse the 
maillog and ban IP's that have 6 incorrect pop3 logins.  I had another 
"attack" last night, but fail2ban got him only have 6 attempts and banned 
his sorry ass.

If anyone wants to see the fail2ban config file I am using for Dovecot, let 
me know...

Rodman

----- Original Message ----- 
From: "V S Rao" <viriyala at yahoo.com>
To: <japc at co.sapo.pt>
Cc: <dovecot at dovecot.org>
Sent: Friday, June 26, 2009 4:01 AM
Subject: Re: [Dovecot] Lots of pop3-logins


>
>> > > Doing a "ps aux" on my Slackware box, I have approx 100  PID's of 
>> > > "pop3-login's going on.  This is a production mail server, but it is 
>> > > getting VERY low traffic.  In fact, only 3 people can "pop3" into it. 
>> > > I've check their e-mail clients, and they are not checking mail any 
>> > > more often than every 5 minutes.
>> > >
>> > > This is a new installation and I've had the server up and running 
>> > > since Sunday.  If it matters, I'm using Postfix for the MTA and using 
>> > > the Dovecot SASL library to AUTH SMTP.
>> > >
>> > > Is this a cause for concern?  Why does Dovecot need this many 
>> > > processes?
>> > >
>> >
>> > >> Because dovecot preforks the *-login processes to speed-up the 
>> > >> login.
>> >
>> > >> No need to worry.
>> >
>> > 100 login sessions for just 3 connections? That is not right, no matter 
>> > what.
>>
>> >> No, login_processes_count matters.
>>
>> How? If my understanding is correct, you have extra 3 login processes 
>> created to cater to new connections. So with only 3 POP3 users, why 
>> should so many login processes be spawned? I can understand 10-15. But 
>> 100 definitely indicates either the processes are not dying or something 
>> else happening on the system which is causing such high number of login 
>> processes. The system definitely needs to be checked for some kind of 
>> attack, a rogue process running on the system or something else.
>>
>
>>> My idle box has 64 imap-login processes and no, I'm not under a
>>> dictionary attack :)
>
> I am not sure what your load is (user base, system config etc), but I will 
> give you my typical load here. I run mail server for about 6000 users with 
> a mix of 70% POP3 and 30% IMAP (thro webmail). And here are the typical 
> stats (I run a script in the background collecting this data every 5 
> secs):
>
> pop3-logins:12
> pop3-connections:8
> IMAP-logins:7
> IMAP-connections:11
>
> I have read other opinions in this thread by Timo & others. And I am 
> interested in a few things. So if you will indulge me, maybe it will be 
> useful for others who face these kind of issues
>
> Timo Wrote: You can also just decrease login_process_max_count
>
> Wouldn't decreasing the login_process_max_count simply create more 
> problems. Now users will start experiencing timeouts sooner than before, 
> because whatever is causing the login processes to increase (attack, rogue 
> process or whatever) will *always* be trying to login and genuine users 
> will be denied login. So without knowing the root cause of the issue 
> simply decreasing or increasing the login_process_max_count will lead to 
> other problems. Correct me if I am wrong.
>
> Rodman Wrote: I'll go ahead and lower that limit to something that fits my 
> usage better.
>
> No, I think leave that value to default and try and identify the root 
> cause and prevent it.
>
> Noel Wrote: What would be nice is, an anti brute force option
>
> Yes, that would be nice. But consider a situation where the system is not 
> under brute force attack, but for some reason the number of login 
> processes keep on increasing by the hour. This would ultimately lead the 
> system to deny connections to the users. Is there a way to track what is 
> happening? strace would be too complicated for us field guys to work with. 
> Any suggestions?
>
> Regards
> --Rao
>
> 



More information about the dovecot mailing list