Dovecot failes to free RAM after brute-force?!

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
15,143
Location
GMT +7.00
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):

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

After dovecot restart:

Code:
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
 
Is there a Dovecot forum or list? If so, that would be a good place to ask.

Jeff
 
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.
 
OK, I tweaked dovecot settings a little bit, and now it seem to be OK:

Code:
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:

Code:
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

Code:
# doveconf

No limits at all:

Code:
...
...
client_limit = 0
...
process_limit = 0
...

on number of simultaneous connections and number of processes.
 
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:

Code:
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 [email][email protected][/email]
S:+OK
C: PASS xxxx
S:
C: QUIT
S:
Already doubled most of the process_limits - no luck.

Code:
default_process_limit=4096 
default_client_limit=6147
default_idle_kill = 1 mins


Code:
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
}
 
Back
Top