Fail2ban

[benyanke]

It would be great to be able to add fail2ban on the front proxy container.

May try and work on this PR if you're interested.

[v1ru535]

Take a look here: #584

[benyanke]

I'm actually proposing something slightly different - implementing fail2ban baked into the proxy container, along with some sane defaults so that users gain the protection automatically. It seems #584 is talking about exposing the logs for an external fail2ban instance.

Or are we talking about the same thing?

[kaiyou]

Having fail2ban as part of the solution is pretty nice. Problem is: you won't be able to have a proper fail2ban in the front container unless you grant it unreasonable privileges on the host.

Instead, authentication rate limits were supposed to cover this use case, and are already in place. What kind of ban would you like to implement?

[benyanke]

I agree - let's not get into host privileges.

I'm still fleshing out the idea, but here's a stream of consciousness on ideas:

Currently, auth attempts are blocked, but not things like excessive 404s, or SQL injection traffic, etc, all of which indicate scanning activity before authentication is even attempted.

The real power of Fail2Ban is looking at not-just auth, but other access attempts. I have seen some schemes which ban very quickly if - for example - wordpress admin URLs are attempted to be accessed, PHPMyAdmin attempt traffic is seen, any traffic containing SQL, a certain number of 404s in a short period of time, etc. These are all good indicators of malicious (or at least unwanted) scanning, and can block hosts before they even have a chance to authenticate.

While it's not feasible to have it update the host firewall, I know fail2ban can also do other arbitrary actions upon ban. I have seen this used to update AWS VPC rules, external firewalls, etc. I wonder if we could leverage Nginx, along with hot-config reloading, to do something similar.

Finally, if this was going to be implemented, we may want to perhaps allow the admin interface to view blocked IPs so that they can be quickly unbanned by an admin. It could be as simple as a list with "x" next to each IP, or as complicated as a list with a modal on clicking the IP, which could detail why they were banned for debugging purposes, how much longer they have left in their ban, etc.

[kaiyou]

My thought on the matter: we need to detect:

• actual abuse use cases, like sending too many emails
• specific technical abuses, like too many authentication attempts
• maybe one day train a proper set of WAF rules for the web interfaces.

The first two should take a good couple hours to even get on rails while the last one is a bit more complicated to handle. What I really do not wish to get into is setting up a generic intrusion detection system for unforeseen attack schemes inside Mailu: generic attack pattern recognition belongs in a global and separate ids/ips while we should only take care of what we can anticipate.

[Harti]

I have no experience on this matter, so please excuse my naivety in my thoughts on the matter:

• Would it be feasible to only allow authentication attempts from a range of physical addresses / IMEIs (e.g. defined via a file or CLI)?
• Would it be possible to create a key pair / certificate, somehow include it in the mail clients, and deny any authentication attempts coming from a device with the wrong private key?

I'm not sure what's causing my mail clients to lose connection to my Mailu server, but if it's DDoS, it's pretty ridiculous that random machines with random IPs can DDoS it by making less than five auth attempts per minute.
Last time the attacker used a certain IP range, so my quick fix was to add it to my server's firewall - but this time around I won't be able to do that, as the client IPs are seemingly random.

Something does need to be done about this, though, and it needs to happen somewhat fast. It's no coincidence that interest in Fail2Ban@Mailu has emerged only recently. It's affecting us all, most of us just don't notice it.

[kaiyou]

@Harti there have been some efforts to lower the impact of authentication on CPU recently, did you notice any improvement on that side?
Aside from this, fail2ban is not a solution to prevent a DDoS attack, it is meant to ban users failing to authenticate, which is already done by the authentication rate limit.

If you are facing certain IP addresses starting hundreds of connections to your mail server, then you need to do something before the connections reach Mailu, for instance using connection rate limiting per-IP on your firewall.

[Harti]

@kaiyou Thanks for the reply! Indeed I did notice it being better currently.
And sorry about the confusion about DDoS - I meant the authentication attempts having acted like such an attack.

And yeah, I keep adding various IP addresses to iptables, but I would prefer there to be some automatic solution to this within the Docker container.