We’ve often had our email servers under “attack”, so I wonder if there are effective strategies to defend against what seem to be brute-force attempts.
We log numerous failed logins on the smtp submission and the dovecot imaps servers. Usernames are almost always actual existing email addresses of my users, sometimes standard non-existent email addresses such as admin@, only rarely usernames. I know at least a couple of accounts have had their password guessed because they’ve been used to send out some 1000 email spam messages, after which I suspended the account and asked the user to reset their password. In both instances I asked the users, and the guessed password turned out to having been really trivial and unchanged for the last twenty years. They didn’t confess to using the same password for other services on the Internet, but it’s easy to imagine they did.
The remote ip addresses are always v4, and mostly from China, followed at a distance by Russia and Brazil, then at least a few k from practically every country in the world but mainly Asian countries.
We’ve got some defenses: the full email addresses are not accepted as usernames, accounts get disabled in case of too many consecutive failed logins and fail2ban bans ips like there’s no tomorrow. It wasn’t however until I blocked all of APNIC, LACNIC and AFRINIC on the external firewall that the failed logins dropped to just a dozen an hour. The firewall currently drops roughly 12,000 connections a day to port 993 alone. This is obviously not sustainable in the long run because even though we hardly have any users outside of North America and Europe, they do travel abroad and they happen to expect to be able to check their email when they do.
I intend to change the servers’ public ips, ask all users to reset they password, and start enforcing a stricter password complexity policy.
Apart from this, I would appreciate any shared knowledge about how this type of behaviour should be handled.
I want to say enforcing stronger passwords is an option, but unlike you I see plenty of compromised email accounts and not one to date (since late 2013 when I started MXroute) has one shown evidence of being effectively brute forced. It was always that they just knew the password ahead of time, suggesting compromise elsewhere (shared password, virus, etc). Just noteworthy is all.
Using CSF with some block lists has helped reduce brute force attempts quite a bit. Here’s a look at the ones I use:
Since these are dynamic and regularly updated, I haven’t yet hat a customer complain that they were blocked from it, and I’ve deployed it across all servers.
Other than that, I think focusing on reducing the damage one can do from a compromised email account is probably a place you can be most effective in. Even if it’s as simple as counting the mail queue and alerting you when it’s unusually high.
Thanks, I agree that limiting potential damage is paramount, and we’ve been doing some hard thinking about it ever since the first incident. Will look into replacing fail2ban with CSF, which seems capable of doing much more. Features such as login tracking and directory watching could help satisfy some customer requests.
I cannot say for sure that the passwords of the compromised accounts have been brute-forced and not gleaned elsewhere. As one user once told me: «My password is secure: it’s the same one that I always use for all my personal and work-related accounts ».
You could enforce at least some background check using the haveibeenpwnd API
I look at how CSF updates its configs from time to time but I craft blocklist using firehol’s iplists and some tools included in that suite (the iprange and the update-ipsets tools, which are triggered by a cron job)
Also, postscreen does wonders (in case you’re using postfix) and blacklists aid quite a bit
You could enforce at least some background check using the