Stopping brute force email auth attacks

At present I am getting zillions of connects to my mail system with what may or may not be script kiddies attempting to get account names and passwords. Randomly looking at the source IP addresses finds that they are often in Spamhaus or one of the other blocking lists. They come from all over the world, so it’s probably being run from botnets - who knows.

So I am wondering about moving or duplicating the IP based DNSBL checks that currently reside in 50-acl-check-rcpt to perhaps the check connect ACL. So if you connect and are in a DNSBL, then you don’t get a chance to test for account credentials because you are instantly gone. I think this will dump a lot of this traffic without having to store ‘bad’ IP addresses and use the firewall.

What is the general feeling about this idea. Bad idea? Good idea? Are the snags? Anyone tried it?


I like the idea, my main concern would be whether it ends up hammering the DNSBLs and ends up getting you banned from them? Unless you somehow cache the results?

I am having the same problem and wondering if I can tackle it via fail2ban.

That seems like a bad idea - DNSBLs are for mail being sent, rather than mailbox logins (and likely credential stuffing, attempting to find valid they can use to send spam) which is what you’re seeing - assuming you’re successful you’ll never see them listed on any of the lists.

However, there is a (very poorly) documented feature in Symbiosis which was retained in Sympl (and is still poorly documented), of the ‘blocklist patterns’ which should do the same job (and is basically a lighter fail2ban).

In /etc/sympl/firewall/patterns.d you should find a list of pattern definitions, with log files to check and patterns to match against, so adding one of these for the mail logs should manage to block them.

For a working example, see openssh.patterns, as that’s what’s used to block IPs hammering SSH.

My firewall, nftfw, is catching repeat offenders, but currently you have to be a bad IP 10 times before it gets banned. Today NOW @ 11:50 I’ve had 108 new attempts, from a total of 235. Yesterday I had 132 attempts out of a total of 259. So the firewall is working - but essentially it’s building a cache of the spambots. I’ve got 4096 IP addresses in the database, while there are 603 addresses being actively banned. And I block all attempts at connecting from several countries that I never expect to get mail from.

Repeat attempts from the same IP address vary from 1/day to 15/14 minutes. I’ve got some repeat offenders that go back to June of last year, and keep coming back.

I’d like to reduce the ability of new connections to do an authentication lookup before I reject them in the RCPT acl. Having thought some more, the checks need to go into the HELO.

Another idea was to use a TCP wrapper passing off to a script that looks up the DNSBLs, As far as I can tell, and I may be wrong, the standard exim4 binary isn’t built with tcp_wrapper support that exim4 supports, and I don’t want to have to maintain a copy of the binary.

As for Spamhaus, I have a free account, when I was a business I paid them for their work. I’ve converted to a free account. I think that this is fair use and I suspect that they would think the same.

TTL on Spamhaus queries is 60 seconds, so I’ll guess that most attempts don’t happen fast enough to use the caching in the local DNS server.

I may well be misreading you. If not, I suspect that the datasets have moved on – at least in terms of Spamhaus, especially the Data Query Service (free for ‘reasonable use’ and I guess good for most Sympletons ;)).

A random, brief scan of local logs shows all smtp auth-fails being listed by DQS at connection time. Similarly, the excellent Abusix shows very good incidence (account/key required and free for low-use).

Indeed, top dogs, Spamhaus, recommend rejection at connection and helo: see BEST PRACTICE | DNSBLs and email filtering - how to get it right - Spamhaus Technology
(At HELO, I’d be cautious purely rejecting on rDNS mismatch but if the domain’s listed then it’s fair game - even if it’s only on spamhaus ZRD).

I don’t expect any real impact on lookup volume by going early – not tested, yet. The only downside I can see is not revealing the RCPT target(s). (Tweaking dovecot to show failed passwords pointed to an unexpected external account compromise on one occasion).

So, early lookup is on my list!