Securing Dovecot Email Server

[xml]

I'm running a LAMP VPS with AlmaLinux 8 and Apache, and I've installed a mail server using Postfix and Dovecot. Everything works fine for sending and receiving emails. However, I noticed that an intruder can establish a connection to Dovecot (e.g., using openssl s_client -connect mail.domain.com:993) and then brute force the username and password with unlimited attempts within the same live session.

Is there a configuration in Dovecot to terminate the current live session after 3 failed password attempts?

 

[Sim]

Can't fail2ban help with that? A quick google shows quite a few results for "fail2ban dovecot" - I've not done it myself, but that's probably the thing I'd check out first.

 

[Masetrix]

Can't fail2ban help with that?

...terminate the current live session after 3 failed password attempts?

With Plesk, easy to do.

Others...

How to Prevent Brute-Force Attacks on Linux Using Fail2ban

Reduce the chances of hackers gaining access to your Linux servers by installing and configuring Fail2ban.

www.makeuseof.com

 

[xml]

Can't fail2ban help with that? A quick google shows quite a few results for "fail2ban dovecot" - I've not done it myself, but that's probably the thing I'd check out first.

With Plesk, easy to do.

Others...

How to Prevent Brute-Force Attacks on Linux Using Fail2ban

Reduce the chances of hackers gaining access to your Linux servers by installing and configuring Fail2ban.

www.makeuseof.com

Unfortunately Fail2Ban can take action starting from the second connection, but during the first live connection, Fail2Ban cannot intervene. That's why I am struggling to terminate the first connection

 

[Masetrix]

Unfortunately Fail2Ban can take action starting from the second connection, but during the first live connection, Fail2Ban cannot intervene. That's why I am struggling to terminate the first connection

Fail2Ban blocks IP addresses according to your settings.
For example, if you use the wrong password 3 times, the (source) IP is blocked.

 

[xml]

Fail2Ban blocks IP addresses according to your settings.
For example, if you use the wrong password 3 times, the (source) IP is blocked.

That's true for services like SSH, where after 3 failed attempts, the connection is terminated, and Fail2Ban blocks the IP on any subsequent connection attempts. Unfortunately, that's not the case with Dovecot. Dovecot doesn’t terminate the connection after a certain number of failed attempts, so Fail2Ban can't step in during the active session

 

[Masetrix]

That's true for services like SSH, where after 3 failed attempts, the connection is terminated, and Fail2Ban blocks the IP on any subsequent connection attempts. Unfortunately, that's not the case with Dovecot. Dovecot doesn’t terminate the connection after a certain number of failed attempts, so Fail2Ban can't step in during the active session

Hmmm.... (maxretry = 3)

Using Fail2ban with Dovecot — Dovecot documentation

 

[xml]

Hmmm.... (maxretry = 3)

Using Fail2ban with Dovecot — Dovecot documentation

will not work for the first connection. I’m curious if the Dovecot team thoroughly tests their Fail2Ban "how-to" guide before publishing it on their website.

 

[DotWeb]

I'm running a LAMP VPS with AlmaLinux 8 and Apache, and I've installed a mail server using Postfix and Dovecot. Everything works fine for sending and receiving emails. However, I noticed that an intruder can establish a connection to Dovecot (e.g., using openssl s_client -connect mail.domain.com:993) and then brute force the username and password with unlimited attempts within the same live session.

Is there a configuration in Dovecot to terminate the current live session after 3 failed password attempts?

You can prevent this by setting up SSL and requiring auth attempts over SSL only with

in /etc/postfix/main.cf

smtpd_tls_auth_only = yes

Then restart postfix: service postfix restart

This doesn't present the AUTH option to the remote client after EHLO, so the spammers/hackers give up because establishing an SSL connection takes too much time.

If you have fail2ban installed, you can enable sasl (or sometimes called postfix-sasl) in your jail.local (or jail.d), and that should make the annoyances go away.

## for me this is in /etc/fail2ban/jail.d/defaults-debian.conf
[postfix]
enabled = true

[postfix-sasl]
enabled = true

 

[Kirby]

Dovecot doesn’t terminate the connection after a certain number of failed attempts, so Fail2Ban can't step in during the active session

Hmm, it should't really matter if Dovecot is able to terminate a session or not, as long as Dovecot does log every failed attempt (including multiple failed attempts within one session) Fail2Ban can be used to action this:
The "trick" would be to inject firewall rules that are executed before packets on already established connections are accepted and to reject or drop those packets.
Might (will) require custom config and may not be terribly efficient, but should work.

A (probably simpler) alternative to mitigate password brute forcing attempts might be https://doc.dovecot.org/main/core/config/auth/penalty.html

 

[xml]

smtpd_tls_auth_only = yes

That directive is for postfix while the command "openssl s_client -connect mail.domain.com:993" is specifically for testing the connection to the Dovecot mail server using the IMAPS protocol which operates over port 993

 

[xml]

Hmm, it should't really matter if Dovecot is able to terminate a session or not, as long as Dovecot does log every failed attempt (including multiple failed attempts within one session) Fail2Ban can be used to action this:
The "trick" would be to inject firewall rules that are executed before packets on already established connections are accepted and to reject or drop those packets.
Might (will) require custom config and may not be terribly efficient, but should work.

A (probably simpler) alternative to mitigate password brute forcing attempts might be https://doc.dovecot.org/main/core/config/auth/penalty.html

The easy solution I use is:
1. /etc/dovecot/conf.d/10-auth.conf

# Time to delay before replying to failed authentications.
auth_failure_delay = 20

This will make brute force attacks harder by slowing them down by increasing the number of seconds bitween login attempts in the same live session connection

2. strong password