PDA

View Full Version : Dovecot failes to free RAM after brute-force?!



zEitEr
08-14-2011, 07:07 AM
Hello,

I've noticed, that Dovecot on CentOS 5.x failes to free RAM after brute-force, it can even last for several days, after an attacker is blocked. RAM is not getting FREE until dovecot is stopped. Can anyone confirm that or comment?

I've noticed the same things on a dedicated server and on a VPS, both servers have Directadmin with dovecot installed.

After brute-force attack, before dovecot restart (according to top):


Mem: 4048276k total, 4021440k used, 26836k free, 45596k buffers
Swap: 9875300k total, 1489388k used, 8385912k free, 627600k cached

After dovecot restart:


Mem: 4048276k total, 1765008k used, 2283268k free, 51632k buffers
Swap: 8385880k total, 0k used, 8385880k free, 673288k cached

(one swap partition was switched off)


POP/IMAP Brute-force attack was registered today about 10 hours ago...

Dovecot 2.0.13

nobaloney
08-14-2011, 11:38 AM
Is there a Dovecot forum or list? If so, that would be a good place to ask.

Jeff

zEitEr
08-14-2011, 09:10 PM
Jeff, for sure it goes without saying, I'll ask the question on a dovecot forum. But I'm very curious, does anybody else face the same problem? As soon as default dovecot config (coming with directadmin custombuild) as far as I can see does not limit memory usage and number of max connections.

And of course, I'm not the only person who faced with Brute-Force attack. So the others can suffer the same way.

zEitEr
08-19-2011, 12:48 AM
OK, I tweaked dovecot settings a little bit, and now it seem to be OK:


service imap-login {
client_limit = 256
process_limit = 64
process_min_avail = 8
service_count = 1
user = dovecot
vsz_limit = 64 M
}
service pop3-login {
client_limit = 256
process_limit = 64
process_min_avail = 8
service_count = 1
user = dovecot
vsz_limit = 64 M
}

Someone might want to update limits to fit the needs.

The defaults are:


service imap-login {
process_min_avail = 16
user = dovecot
}
service pop3-login {
process_min_avail = 16
user = dovecot
}


As no limits are used, defaults are used, you can see them with


# doveconf

No limits at all:


...
...
client_limit = 0
...
process_limit = 0
...

on number of simultaneous connections and number of processes.

luck
03-20-2015, 05:49 AM
Hello,
dovecot 2.1.15 and got simillar problem. Under around 1,7k dovecot processes pop3 stops responding. imaps seems to be fine during these incidents.
It looks like it cannot authorize user:


S:+OK Dovecot DA ready.
C: CAPA
S:+OK
S:CAPA
S:TOP
S:UIDL
S:RESP-CODES
S:PIPELINING
S:STLS
S:USER
S:SASL PLAIN
S:.
C: USER xxx@yyyyy.aaa
S:+OK
C: PASS xxxx
S:
C: QUIT
S:

Already doubled most of the process_limits - no luck.


default_process_limit=4096
default_client_limit=6147
default_idle_kill = 1 mins



service pop3-login {
chroot = login
client_limit = 0
drop_priv_before_exec = no
executable = pop3-login
extra_groups =
group =
idle_kill = 0
inet_listener pop3 {
address =
port = 110
ssl = no
}
inet_listener pop3s {
address =
port = 995
ssl = yes
}
privileged_group =
process_limit = 0
process_min_avail = 16
protocol = pop3
service_count = 1
type = login
user = dovecot
vsz_limit = 18446744073709551615 B
}

service pop3 {
chroot =
client_limit = 1
drop_priv_before_exec = no
executable = pop3
extra_groups =
group =
idle_kill = 0
privileged_group =
process_limit = 3072
process_min_avail = 0
protocol = pop3
service_count = 1
type =
unix_listener login/pop3 {
group =
mode = 0666
user =
}
user =
vsz_limit = 18446744073709551615 B
}