• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Brute force attack has put down dovecot service

OverWolf

Regular Pleskian
Hi,

I've received some email from watchdog that inform me that dovecot service is down for about 10 minutes, and then it is been restarted. So, I've read some log and I found that from an only ip, my server has received a series of attempts to access on dovecot.
Now, I would like to know why my server (and fail2ban) haven't response as I expected (after 3 attempts you are banned), but that ip could do several attempts before it was banned and then it put down my service.

Is there something can I do ?

Thank you

P.S.: I attach some screenshot.
 

Attachments

  • Dovecot_down_restart.png
    Dovecot_down_restart.png
    7.5 KB · Views: 14
  • Dovecot_down.png
    Dovecot_down.png
    32.3 KB · Views: 14
Fail2Ban cannot monitor logs realtime, but only neartime. There is a latency window between an event and a ban. If the log has many entries or if it is a large file of several megabytes in size, Fail2Ban will need more time to process the entries. During that latency window, attacks can continue.
 
ipset is an extension to iptables that allows to create sets of IP addresses. It does not reduce Fail2Ban latency.
 
So, what you can suggest to have a "realtime" protection ? Set a number of login attempts per minute ?
 
I doubt that there is a better solution for the situation that can be implemented on the server. There is no "realtime" protection, because that would require the service itself to monitor what is passing through it and blocking frequent connection attempts. Fail2Ban only blocks what has been written to a log, so it will not be super fast. MANUAL 0 8 - Fail2ban

You could try to limit the number of concurrent connections to the dovecot service by the corresponding mail server setting in Plesk, but if an attack closes the connection after a login attempt, it won't help, because then the connections are not concurrent. Limiting the number of dovecot processes won't help either, because the regular users will be blocked by that, too. When you know that your users are located in your area or country, you could limit IMAP port access to IPs of a certain region or country and block all others.
 
Back
Top