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 Abusixcombined.mail.abusix.zone shows very good incidence (account/key required and free for low-use).
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).
This summary and rationale of my changes appears in the README file there:
After some numbers of years using these changes, there are several things that are less than optimum with the approach of pushing all blocking into the firewall.
The firewall, quite reasonably, has to build up a history of unwanted behaviour for an IP before it will block it. So the miscreant site has a chance of doing what it wants to do for several iterations, and exim4 has to detect and block any problem.
Most of the blocks in the standard set of configuration files are placed in the RCPT access control list. At this time in the SMTP conversation, all the information needed to see if this is a valid piece of inbound mail is present. However, part of that validation can be to check on any user ids and passwords, which happens before the RCPT command is received. So all of the sites wanting to look up user names and passwords will get confirmation of their failure (hopefully) before trying to send some mail. OK, they will only get a few attempts before the firewall will block them, but that few may be too many.
My firewall, nftfw, detects failed password attempts in the mail logs and will block the IP address, limiting the number of attempts that one IP can use. After a small number of attempts, the IP address is loaded into the firewall and is blocked. The IP will continue to stay blocked while nftfw’s blacklist scanner finds output from the kernel signalling that the IP has tried again to access the machine. If the IP doesn’t attempt to connect, the IP address is moved from being on the active list, but is retained for quite a long period.
The firewall database of blocked IPs and their activity history had grown to over 4000 entries, of which around 650 were currently active blocked sites. Some of these IPs had been active for over a year. The daily activity of blocking IPs has increased dramatically since I last seriously looked at what was going on. There seem to be many robot sites pointing at my server. They relentlessly and fruitlessly keep trying to connect and were firewall blocked. Looking up these IPs showed that they were very nearly all known to one DNS blacklist or another. Basically what I was doing was slowly mirroring the DNSBL contents in my firewall.
The solution seemed to be to move or replicate some of the checks currently in the RCPT ACL to earlier in the process. The only viable candidate for the early checks is in the CONNECT ACL, because the ACLs that are invoked between the start of the conversation and the RCPT either don’t allow active blocking, or are just don’t run early enough.
So the 2024 changes only need the IP of the connecting machine and:
Moves the test that uses a reverse lookup of the incoming IP and denies access if there is no associated name. This is a huge win, it’s still the case that many bad connections are coming in from machines where there is no reverse PTR record available.
Sets up DNSBL tests for Spamhaus, Spamcop and Barracuda and deny access on any hit. These work for every connection to the mail system and don’t seek permission from the existence of a Sympl control file placed in a server’s config area. At this point in the conversation, the destination of the mail is unknown, so this selection cannot be made. The tests that are run can be selected from an Exim4 list.
The result of the changes are spectacular. I cleaned out the firewall database to reset things, and no unwanted authentication lookups are now happening. I have blocked via the firewall a couple of IP’s that are trying to connect relentlessly, for example several attempts every minute.