Home / server / Questions / 872660
Accepted
MadHatter
Asked: 2017-09-09 01:51:35 +0800 CST

Why are people repeatedly connecting to my MTA, doing nothing, and leaving?

  • 772

I have a sendmail server. Periodically (ie, several times an hour) I get log entries like this:

Sep  3 10:06:49 lory sendmail[30561]: v8396nsQ030561: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:49 lory sendmail[30564]: v8396nmv030564: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
[29 very similar lines deleted]
Sep  3 10:06:50 lory sendmail[30654]: v8396or0030654: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:50 lory sendmail[30657]: v8396ou3030657: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6

This particular server went on for a bit at that rate, then got bursty, notching up in total some 600 connections in 110s; others are less prolix. They don't cause my server any problems; fail2ban gets a bit exercised, watching the mail log file for SMTP AUTH failures as it does, and having to ignore all these new entries, but it's nothing to make the server sweat.

What I'm curious about, and what I'm asking, is why anyone would do such a thing. Are they hoping my relaying/greylisting/SPF engine has a very small brain, and after 500 connections it says to itself gosh, they're really keen to talk to me, I'd better accept anything they send now? Are they hoping my server has no spare VM, and sendmail will bloat and invoke the OOM killer, thus DoSsing me? I presume someone's doing this sort of thing for a reason, but does anyone have the faintest idea what that reason might be?

security

1 Answers

  1. Best Answer

    The sendmail "did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA" warnings are, not unexpected, triggered by authentication attempts that get rejected, but not only when an incorrect username password combo is supplied, but you see the same error even when authentication is not supported (or at least not allowed without TLS):

    telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 hbruijn ESMTP Sendmail 8.14.4/8.14.4; Fri, 8 Sep 2017 13:06:31 +0200
AUTH LOGIN
   504 5.3.3 AUTH mechanism LOGIN not available
QUIT

    This generates the type of log event you see:

    Sep 8 13:06:39 hbruijn sendmail[11333]: v88B6VYg011333: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

    You don't see any actual usernames logged because the "attackers" don't even reach the stage at which they can supply a username or password.

    When I connect with STARTTLS and do supply an (incorrect) username and password combo sendmail logs exactly the same error. 

    openssl s_client -starttls smtp -connect localhost:25
   250 HELP
AUTH LOGIN
   334 VXNlcm5hbWU6
bXl1c2VybmFtZUBkb21haW4uY29t
   334 UGFzc3dvcmQ6
d2Vha3Bhc3M=
   535 5.7.0 authentication failed
QUIT
   DONE

    That generates an additional log line, but afterwards exactly the same event.

    Sep 8 13:24:22 hbruijn sendmail[11648]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
    Sep 8 13:24:32 hbruijn sendmail[11648]: v88BOMvW011648: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

    Never attribute to malice that which is adequately explained by stupidity:

    My own domain doesn't get much mail, but sufficient internet background noise with regards to port scans and brute force attempts. I captured all SMTP traffic over the last couple of days and, in addition to quite a few unique IP-addresses triggering such log events, my server had two IP addresses that didn't back away when my sendmail responded that AUTH isn't supported (without TLS) resulting in a large number of warnings from those IP's.

    At least for those two IP-addresses it was as I expected, they appear just dumb and stupid malware programs apparently working through a list of usernames/passwords without really doing any error control and not backing away after the initial failure ( which makes me wonder if they could even detect if/when they are successful ...)

    traffic capture

    and the associated log:

    Sep 10 04:04:34 hbruijn sendmail[7558]: v8A24YLM007558: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:34 hbruijn sendmail[7561]: v8A24Yi1007561: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:34 hbruijn sendmail[7564]: v8A24YHM007564: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:35 hbruijn sendmail[7567]: v8A24YSY007567: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:35 hbruijn sendmail[7570]: v8A24ZC2007570: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:35 hbruijn sendmail[7573]: v8A24ZYo007573: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:35 hbruijn sendmail[7576]: v8A24ZLt007576: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
    Sep 10 04:04:35 hbruijn sendmail[7579]: v8A24Zva007579: [196.196.27.126] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

    • 12