Fail2Ban is no longer working for Mailu 2.0 and documentation provided.

[lucassith]

Hey everyone.

Couple of months ago I updated your documentation for fail2ban since there were couple of bugs there.
Now I come back, because there is something off with the fail2ban configuration in the docs for version 2.0.

First of all, I no longer get authorization errors in journal.d from mailu-front, it means that fail2ban will never catch failed attempts.

Second issue is for mailu-admin -> regexp is listening for

failregex = : Authentication attempt from <HOST> has been rate-limited\.$

but it will fail to work if I have rate-limitting disabled, right?

Why not listening on failed attempts then? I can clearly see that these are being logger.

[lucassith]

Okay I can see that fail2ban has following regexp in your documentation:

failregex = ^\s?\S+ mailu\-front\[\d+\]: \S+ \S+ \[info\] \d+#\d+: \*\d+ client login failed: \"AUTH not supported\" while in http auth state, client: <HOST>, server:

Meanwhile failed authorization has following format in Mailu 2.0

[info] 12#12: *210 client login failed: "Authentication credentials invalid" while in http auth state, client: 77.73.32.213, server: 0.0.0.0:465, login: "test@test.com"

For sure it won't catch this message because it expect string "AUTH not supported".
Or maybe there is a reason to listen for this format?

I can see that in 1.9 it didn't care about the reason and the regexp was following:

failregex = .* client login failed: .+ client:\ <HOST>

and it is much better.

[nextgens]

First of all, I no longer get authorization errors in journal.d from mailu-front, it means that fail2ban will never catch failed attempts.

That is not surprising if you have disabled rate limiting and is your problem.

Why not listening on failed attempts then? I can clearly see that these are being logger.

Because Mailu does "better", it only accounts distinct attempts (attempts with a different passwords to avoid getting a user who has just changed his password locked-out as his MUA is retrying to login with the now-old password in the background).

[lucassith]

That is not surprising if you have disabled rate limiting and is your problem.

Because Mailu does "better", it only accounts distinct attempts (attempts with a different passwords to avoid getting a user who has just changed his password locked-out as his MUA is retrying to login with the now-old password in the background).

I see, thank you for quick response. It makes perfect sense for more tolerant security settings. However I fixed my configuration to be more vigiliant and for anyone who would like to have it more rigorous for Mailu 2.0, here is my confinguration:

Steps:

1. Follow documentation here https://mailu.io/2.0/faq.html#fail2ban
2. Change /etc/fail2ban/filter.d/bad-auth-bots.conf to

# Fail2Ban configuration file 
[Definition]
failregex = .* client login failed: .+ client:\ <HOST>
ignoreregex =
journalmatch = CONTAINER_TAG=mailu-front

3. Change /etc/fail2ban/filter.d/bad-auth.conf to

# Fail2Ban configuration file
[Definition]
failregex = Login failed for ([^\s]+) from <HOST>\.$
ignoreregex =
journalmatch = CONTAINER_TAG=mailu-admin

4. Change /etc/fail2ban/jail.d/bad-auth-bots.conf to

[bad-auth-bots]
enabled = true
backend = systemd
filter = bad-auth-bots
bantime = 7776000
findtime = 600
maxretry = 3
action = docker-action

Changes are following:

1. Every failed login attempt to SMTP server is counted.
2. Every failed login to admin panel is counted.
3. We always lock IP from connecting to all ports. (previously lock happened only on port 25 for SMTP [even though SSL connections were on 465 and it wasn't banned and you could do unlimited calls])

Caveat emptor:
Make sure you pass x-real-ip if serving Mailu behind proxy. Otherwise you'll lock your internal docker IP from connecting and services will start to time-out each-other.