10

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?

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • 7
    *Never attribute to malice that which is adequately explained by stupidity* ;) – HBruijn Sep 08 '17 at 10:15
  • 2
    @HBruijn Never undervalue stupidity as an (official) excuse for malice :-) – AnFi Sep 08 '17 at 10:53
  • 3
    Probably someone scanning the network for vulnerable software versions. – ThoriumBR Sep 08 '17 at 12:42
  • @ThoriumBR I'm unconvinced: why would they have to connect *600* times to find out the software version? Either you find it out on first connect, or the service is configured not to tell you - unless you know of an MTA *whose behaviour changes after multiple rapid, serial connections*, which would be **really useful** to know. – MadHatter Sep 11 '17 at 07:50

1 Answers1

12

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

HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • I see your point (after initially missing it). Oh, that is elegant, and having tested it, it produces exactly the same log footprint (my server also requires `TLS` before offering `AUTH`). I hadn't suspected there'd be no `auth` syslog footprint from an authentication attempt that failed *because the facility wasn't available at that stage of the transaction*. I'd like to catch one of my own attackers on the fly to confirm, but *this explanation makes sense* - **thank you so much!** Well-deserved bounty on confirmation. – MadHatter Sep 11 '17 at 07:59
  • @MadHatter Thank you for your feedback, My point was indeed not very clear and I have updated my answer to clarify my point that you see the same error regardless of whether or not authentication is supported and that many repeated log events are probably a very poorly written piece of malware that doesn't check for error responses. – HBruijn Sep 11 '17 at 11:22
  • 1
    The difference in the second case (TLS engaged, AUTH attempted) is that there are corresponding saslauthd syslog entries (facility authpriv). My mystery was that I was getting *only* the sendmail connection logs and *no* other log activity. I never for a moment dreamed that people would be running brute-forcing code that *did not even check that it could try to log in before so doing*. – MadHatter Sep 11 '17 at 12:45
  • 1
    Caught one - just like yours. System won't let me award the bounty yet, so I'll try to remember to do that tomorrow. By the way, my opening comment about initially missing your point was entirely a criticism of *me*, in that I did not read your answer sufficiently carefully before concluding it was unhelpful. Once I re-read and understood it, I quickly suspected you were right. I honestly think your answer was better in its earlier form, but it is of course yours to polish as you see fit! – MadHatter Sep 11 '17 at 14:50