mjl- / mox

modern full-featured open source secure mail server for low-maintenance self-hosted email
https://www.xmox.nl
MIT License
3.55k stars 100 forks source link

Question: protection against failed authentication attempts #141

Open pmarini-nc opened 6 months ago

pmarini-nc commented 6 months ago

As specified in the title this is not an issue, but a question. And from someone with little experience in running email servers, but given the purpose of Mox, I think that having this clarified could be beneficial to other similar users as well.

So the point is that I see a large amount of failed authentication attempts in the log:

l=info m="failed authentication attempt" pkg=smtpserver username=pippo remote=192.168.15.1 cid=18e2e026bb0 delta=1.307802432s

Since January 1st 2024, around 3,3k and with user names that don't exist on the instance. For how my network configuration is deployed, I cannot see the real IP of the attacker. I always see the local gateway IP, 192.168.15.1

So, a couple of questions here:

Thanks

mjl- commented 6 months ago

is the volume of authentication attempts in line with what we should expect for a personal email server instance?

Yes, it seems realistic. I just checked my logs. Over the past 6 days:

is there any impact on performance?

Mox has an IP-based rate limiter. After too many authentication failures, connections are rejected early with a temporary error code. But the connection is still made, which may involve TLS handshakes. For multiple attempts on a single connection, mox paces multiple authentication attempts (but this also consumes some resources).

Mox has these limits for ipv4 (and similar for ipv6 subnets):

This already prevents quite a few attempts to guess passwords. If you have random passwords, there should be no way for an attacker to guess it and log in. I hope everyone (especially mox users) know by now not to reuse passwords across sites. (:

It seems attackers are just trying random usernames/password (possibly leaked credentials). It doesn't appear too sophisticated. And it seems they aren't doing it at high speed, they probably know that will draw attention. I'm running mox on an entry-level machine with 1gb ram and 1 partial core, and it is mostly idle.

is there anything I can do to block these fake attempts before they reach the server?

I haven't seen attackers hammer at high speed. If they would do that, it would help to have connection (rate) limiting at a firewall, before connections reach mox. I would be interested learning how people set that up on various systems. A generic rate limiter at the firewall level should be relatively easy to set up. But if you want to use the information from the failed authentication attempts, you'll have to set up something that monitors logs and feeds IPs into firewall rules. I think fail2ban does that, but never used it, I haven't felt the need.

Could be good to make a FAQ entry out of this.

By the way, not having the actual remote IP address available is not recommended: The IP rate limiter will be operating on the same private IP for all connections. It will also lead to wrong results for SPF checks for incoming messages.

mjl- commented 6 months ago

Another thought: You could run IMAP and submission only on internal IPs (behind a VPN). It will prevent autoconfig from working though. And attackers will still try to login on port 25 for SMTP delivery (even though authentication is not available on that port).

pmarini-nc commented 6 months ago

Thank your for sharing.

Is there a way to restore the rate limiting counter without restarting the server? It seems that without VPNs it becomes an hard requirement to have access to remote IPs. In my installation after a while the server is on, I cannot login to the server anymore even from legitimate clients (those with the correct passwords), with a "too many authentication attempts" (wording by memory, would net to get the error again for the exact wording)

pmarini-nc commented 6 months ago

image

"cannot login" in my last message is "cannot send message over SMTP" from a previously logged in client.

Apart of being able to reset the rate limiting counter, it would be useful to have a way to edit those limits and even to completely disable the logic, even if not recommended.

mjl- commented 5 months ago

@pmarini-nc sorry for late reply, have been busy. do you still need this? or have you found another solution in the mean time? if this is still needed, i would propose we add a flag "-disable-ratelimits" to "mox serve", which makes all ratelimiting in package ratelimit a no-op. that would prevent any ratelimiting after failed authentication attempts, and also http/smtp/imap connection ratelimiting and limiting of total active connections at any moment. those are all not too useful if all connections are coming from 1 ip.