Mailcow-dockerized: Dynamic fail2ban whitelisting

[alexandernst]

I have a website and mailcow in the same server, and from time to time some user triggers a ban because PEBKAC. fail2ban kicks in and blocks the traffic for that IP, which means that the entire office get's banned (which is actually fine).

The problem is that aside from the mail, fail2ban blocks website traffic. That occurs because of how Docker operates inside the kernel.

A container that blocks an IP (using DROP), actually makes the entire physical machine drop the traffic from that IP. (if you don't believe me you're more than free to test it yourself)

The point is, every time mailcow/fail2ban DROP an IP, they DROP all the traffic from all ports (including websites). Is it possible to make mailcow block only the mail-related ports?

[andryyy]

We can make this optional.

[andryyy]

I think we could drop traffic to the mailcow network. Dropping a brute force attack on the web interface would still drop traffic to 80/443 after all.

You should really fix this problem on the client side. :-/ Or whitelist them.

[mkuron]

The reason why this happens is that we add rules to both the INPUT and the FORWARD chain. The former has the side effect you mention, but that is intended so that fail2ban also applies to a reverse proxy.

[alexandernst]

🤔 I wonder if it's somehow possible for fail2ban to act only on the mailcow containers, instead of blocking literally everything (all containers and all servers outside of docker)?

[mkuron]

Why would you want someone who repeatedly enters wrong passwords to be able to access your website? They most likely are not a user or customer, but rather someone nefarious trying to guess a password.

[alexandernst]

@mkuron As I explained in my first comment, this situation happens in a company's office (we're talking about ~100 people). Statistically speaking the "I forgot my password and I tried 5 times in a row" situation can happen (and happens) several times per day.

It's not unreasonable to want to NOT block the web access to all users in the company just because one person wrote the incorrect password 5 times in a row.

[mkuron]

In that case, the reasonable thing to do is to whitelist your company network.

You'd still be banning everyone from email if the ban didn't apply to INPUT as you requested.

[alexandernst]

@mkuron I thought about that, but the office doesn't have a static IP. I'm open to other suggestions. (Not No-IP, DynDNS and stuff like that, please).

[EnriqCG]

Can bans be applied via API? Because that can solve the issue.

[andryyy]

You need to whitelist them. What else do you want to happen? Give an attacker the chance to try on port 80, then 443, then 587, then 465, then 110 etc.? That doesn't sound very reasonable. We could make this optional, but it will not solve your problem, I'm afraid.

@EnriqCG - no, the failed attempts are written to a Redis channel, where netfilter-mailcow watches for patterns.

You can solve this by disabling netfilter-mailcow and parse the Docker logs yourself. You can then decide what exactly should happen. :-)

[mkuron]

The API is still incomplete (#1374), but you might be able to figure out how to whitelist addresses.
Whitelisting really is the only reasonable solution to your problem.

[wedi]

If a mail client gets configured with a wrong password it tries again and again. Finally the IP gets blocked and it is quite inconvenient when your server gets blocked and you have no chance to unban neither via website nor ssh.
I learned this now and I have no problem with SSH tunneling but this situation might become a problem for someone with an unknown colleague keeping the IP blocked. You are locked out from the logs as well...

[wedi]

A solution to the problem could be relaxing the rules for IPs from which a successful login has been logged during last n hours.