Delays on SMTP replies discourage apparently SMTP AUTH scanners

November 22, 2017

One of the things that my sinkhole SMTP server can do is trickle out all of its SMTP replies at a rate of one character every tenth of a second. This is a feature that I blatantly stole from OpenBSD's spamd when I read about it years ago, mostly because it seemed like a good idea. The effects of doing this have been interesting, because there's a real split in the results.

At the moment I have my sinkhole server listening on two IP addresses. One IP address is the MX target for some long-standing host names that collect a bunch of spam. The other IP address used to be the MX target for one such host, but that ended several months ago; it's run a SMTP server for years, though. As far as I've seen, all spam email attempts come to the first IP address and those senders are generally completely indifferent to the slow output they're getting. I'm not really surprised by this; real mail software is going to be willing to cope with relatively slow responses because there are all sorts of reasons they can happen, including overloaded destination systems. Even if you're writing your own software, you have to go out of your way to have timeouts so fast that they'd trigger on my responses.

(There was a day when some spam software working through compromised end machines and open proxies would respond to slow 'tarpit' responses by disconnecting, but I'm not convinced anything does that any more. However I haven't attempted to do any real study of this, partly because it's hard to sort out noise from signal in my current setup.)

Things are very different on the second IP, the one that isn't an MX target of anything currently but which used to run a SMTP server. There, there is a huge number of IP addresses that connect and then disconnect before my greeting banner even finishes trickling out. When I've turned my slow replies tarpit off to see what these connections looked like, they've all turned out to behave like SMTP AUTH scanners. Some of them will EHLO (often with with suggestive names) and then disconnect when they don't see AUTH advertised in my EHLO greeting; others will go through the EHLO and then start blindly spitting AUTH LOGIN requests at me. Not infrequently they'll do this repeatedly, or with a lot of concurrent connections, or both.

(To my surprise I don't think any of them ever tried STARTTLS, which I do advertise and which SMTP authentication is often gated behind.)

We have a very simple connection time delay in our external mail gateway and now that I check, we are seeing a certain amount of Exim messages about 'unexpected disconnection while reading SMTP command from ...'. However, I'm not sure how far these connections have gotten before then. They do generally seem to have hostnames typical of end-user IPs, just like the connections I see to my second IP, so it's possible that these are attempts at SMTP AUTH probing.

(We probably don't care enough to bother adding logging that would tell us. It's not exactly actionable information; everyone with exposed IPs and services on the Internet is getting probed all the time.)

Written on 22 November 2017.
« Major version changes are often partly a signal about support
Understanding a tricky case of Bourne shell redirection and command parsing »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Nov 22 01:23:08 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.