[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