I’m reaching out because I’ve been noticing a significant number of unauthorized SMTP scans and relay attempts targeting kumomta server. These scans seem to come from various sources, including well-known security scanners like Expanse (Palo Alto Networks), as well as potential malicious actors attempting to exploit open relays.
Here are some of the responses with kumomta webhooks:
Relaying not permitted
AUTH NTLM not supported
Command unimplemented
Syntax error in command or arguments
While it’s good to see these rejected, I’m concerned about the ongoing noise in the logs and potential risks.
I’ve already implemented SPF, DKIM, DMARC, and restricted relaying with authz (user and pass), but the volume of these scans is becoming overwhelming, and I’m trying to determine the best way to automatically block or filter these types of connections while ensuring legitimate traffic isn’t disrupted.
Specific Questions:
How can I configure KumoMTA to block or rate-limit these scans more effectively?
Are there specific settings or techniques I can use to automate the detection of known scanners like the following :
Syntax error in command or arguments: → 1:1 | 1 | User-Agent: Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo@paloaltonetworks.com | ^— | = expected mail, rcpt, ehlo, helo, data, rset, quit, vrfy, expn, help, noop, starttls, or auth
This is a very important matter, especially we are dealing with real time webhooks, thatt will explose the logs even for kafka.
it’s a good practice to auto block those scanners, maybe using iptables or else.
I haven’t gotten around to doing this myself, but I was planning to write the offending IPs to redis or something with a counter, and null-route those IPs using iptables if they reach some threshold of rejections. There are also some Bad IP Lists out there (like DNR from Spamhaus) that you can safely null-route (but you’ll need to update / un-ban from time to time to prevent null-routing IPs that have been removed from those lists).
I also use fail2ban heavily in many environments ( not yet on KumoMTA, since we’re not in production yet ).
It’s definitely the right approach: implement blocking or tarpitting using a tool that’s built for it, rather than trying to force KumoMTA to handle it.
Kumo might help to patch a few situations with some custom logic (as Tom suggested), but it will never fully replace a system designed specifically for that purpose.
Also, like I do, after a ban in fail2ban you can automatically report the offending IP to AbuseIPDB (Integrating AbuseIPDB with Fail2Ban), helping to feed their global blacklist ( once you’ve gained enough trust and reputation, of course ), which you can then use yourself to check if an IP has been reported.
It would be really cool to eventually create a fail2ban filter.d/kumomta.conf and a jail.d/kumomta.conf on kumomta github, so we can all contribute and share useful filters/failregex
).