I recently set up an SMTP server for myself to use, and I am getting some traffic from two IP addresses and none else (though for obvious reasons I will not state the addresses here).

An example session (which, in fact, repeats itself EVERY TIME) would be:

Server: 220 <hostname> ESMTP
Client: HELO *.*
Server: 250 <hostname>
Server: 503 5.5.1 Error: authentication not enabled
Client: QUIT
Server: 221 2.0.0 Bye

Why would the attacker(s) keep trying this, when LOGIN auth is clearly disabled?

Furthermore, why would the potential attacker(s) use SMTP (when ESMTP is clearly available), and what does HELO *.* mean? (I am aware of what the HELO command does)

For reference, I am getting roughly one "attack" every 15 minutes.

  • The log you got is the typical signature of an automatic attack badly coded. If the origin IP isn’t changing, I advise you to put it on black list for one year. You can’t waste your time to eliminate such stupid attacks. – dan Jan 14 '19 at 9:00

Attack code is often a hastily scripted affair, poorly written and without proper error handling. It’s probably only checking for a a 200 OK response, and retrying in case of any non-200 response.

To elaborate further, the attacker isn’t interested in complying with the protocol. His goal is not to make your server happy. He’s only interested in testing login credentials.

There’s not much you’ll be able to do about it. Make sure your SMTP server is patched and on the most current levels, etc.

  • So "bad code" is really the answer? Interesting, if no other answers show up I'll accept yours, in the mean time, could you please answer the other two subquestions? – Kryštof Píštěk Jan 13 '19 at 17:12
  • 2
    @KryštofPíštěk: I agree with JohnDeters and the answer to the other two subquestions is also bad code. Such tools are commonly just quickly hacked together by someone who has no deeper understanding of the protocol and just saw some old protocol examples. Additionally servers often accept any protocol which looks sufficiently correct and do not actually enforce protocol standards. And, as long as it works for enough cases it is not worth to be improved. – Steffen Ullrich Jan 13 '19 at 17:17

It does seems like a script left unattended. See if you can block the IP address. Besides, once every 15min may not have performance impact anyway.

If you can find a specific pattern in the log files, you can block using fail2ban.

  • The OP says that the events are being generated by two IPs. That should be enough to block. I'm not sure why one would configure fail2ban for this. – schroeder Jan 21 '19 at 9:19
  • Yes, manually block 2 IPs. But it can happen from elsewhere too. Just being proactive. – user195975 Jan 21 '19 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.