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.
Regards --Rao
Well, after going through my log files, I was hit with a dictionary based attack. My maillog is full of about 20,000 lines of crap like this:
Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<warren>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<williams>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<www>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<wilson>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<willy>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<valerie>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2
Starts with "A" and runs all the way to "Z". The IP traces back to cable modem subscriber on Cox Communications out of Arizona. I'll shoot them off my "standard" attack e-mail.
In the meantime, I need to modify fail2ban so that it checks the maillog for failed pop3 auth logins and bans IP's so this won't happen again.
Rodman
----- Original Message ----- From: "V S Rao" viriyala@yahoo.com To: dovecot@dovecot.org Sent: Thursday, June 25, 2009 1:15 PM 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.
Regards --Rao
You can also just decrease login_process_max_count. If Dovecot reaches the limit, it'll just start killing off old connections that haven't logged in.
And yeah, some day I should also make Dovecot kill some of the login processes after many of them have been idling for a while.
On Thu, 2009-06-25 at 14:33 -0500, Rodman Frowert wrote:
Well, after going through my log files, I was hit with a dictionary based attack. My maillog is full of about 20,000 lines of crap like this:
Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<warren>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<williams>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<www>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<wilson>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<willy>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:05 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<valerie>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2
Starts with "A" and runs all the way to "Z". The IP traces back to cable modem subscriber on Cox Communications out of Arizona. I'll shoot them off my "standard" attack e-mail.
In the meantime, I need to modify fail2ban so that it checks the maillog for failed pop3 auth logins and bans IP's so this won't happen again.
Rodman
----- Original Message ----- From: "V S Rao" viriyala@yahoo.com To: dovecot@dovecot.org Sent: Thursday, June 25, 2009 1:15 PM 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.
Regards --Rao
I'll go ahead and lower that limit to something that fits my usage better.
Thanks Timo! You built a hell of a mail server.
Rodman ----- Original Message ----- From: "Timo Sirainen" tss@iki.fi To: "Rodman Frowert" rodman@thefrowerts.com Cc: dovecot@dovecot.org Sent: Thursday, June 25, 2009 2:46 PM Subject: Re: [Dovecot] Lots of pop3-logins
On Jun 25, 2009, at 3:46 PM, Timo Sirainen wrote:
You can also just decrease login_process_max_count. If Dovecot reaches the limit, it'll just start killing off old connections that haven't logged in.
I don't see this option in my dovecot.conf. Was it added after
1.1.6?
-Dave-- Dave McGuire Port Charlotte, FL
On Thu, 2009-06-25 at 15:46 -0400, Timo Sirainen wrote:
You can also just decrease login_process_max_count. If Dovecot reaches the limit, it'll just start killing off old connections that haven't logged in.
What would be nice is, an anti brute force option, like xinetd, X-number of connections from Y i.p. in Z seconds (optional setting of course) or maybe a way to extend that to detect if the same i.p is retrying constantly using different usernames on every new connection within X seconds, come to think of it, that way would be much cooler :)
Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<warren>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<williams>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2 Jun 21 23:06:04 mail dovecot: pop3-login: Aborted login (auth failed, 1 attempts): user=<www>, method=PLAIN, rip=68.14.228.186, lip=10.10.11.2
--On Friday, June 26, 2009 8:48 AM +1000 Noel Butler noel.butler@ausics.net wrote:
What would be nice is, an anti brute force option, like xinetd, X-number of connections from Y i.p. in Z seconds (optional setting of course) or maybe a way to extend that to detect if the same i.p is retrying constantly using different usernames on every new connection within X seconds, come to think of it, that way would be much cooler :)
Some good discussion about fighting dictionary attacks here:
On Fri, 2009-06-26 at 07:48 +1000, Noel Butler wrote:
What would be nice is, an anti brute force option, like xinetd, X-number of connections from Y i.p. in Z seconds (optional setting of course) or maybe a way to extend that to detect if the same i.p is retrying constantly using different usernames on every new connection within X seconds, come to think of it, that way would be much cooler :)
v2.0 makes it possible in a lot easier way. Maybe I'll get it implemented there.
On Thu, 2009-06-25 at 18:31 -0400, Timo Sirainen wrote:
On Fri, 2009-06-26 at 07:48 +1000, Noel Butler wrote:
What would be nice is, an anti brute force option, like xinetd, X-number of connections from Y i.p. in Z seconds (optional setting of course) or maybe a way to extend that to detect if the same i.p is retrying constantly using different usernames on every new connection within X seconds, come to think of it, that way would be much cooler :)
v2.0 makes it possible in a lot easier way. Maybe I'll get it implemented there.
That would be awesome :) Cheers
On Qui, 2009-06-25 at 11:15 -0700, V S Rao wrote:
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.
If you don't change the defaults that's right. But the *-login processes will never be less than login_processes_count so it does matter. And, as timo pointed out, you can put a upper limit with login_max_processes_count.
My idle box has 64 imap-login processes and no, I'm not under a dictionary attack :)
-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt --------------------------------------------------------------------- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
participants (7)
-
Dave McGuire
-
Jose Celestino
-
Kenneth Porter
-
Noel Butler
-
Rodman Frowert
-
Timo Sirainen
-
V S Rao