0

When I look at my sendmail logs, by far the most common "error" I see is the following:

Nov 22 16:49:50 MyHostname sendmail[18832]: rAMMnj2u018832: [IP address redacted to hide the guilty] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

This is not coming from poorly configured MUA's inside my small network. It always comes from outside my network, from where only MTA's should be communicating with my sendmail. Overwhelmingly, the single largest source of these IP addresses is China, but plenty of other countries are sources of this as well.

I assume that this must be part of some sort of attempt to hack, but I cannot figure what it is. Is this coming from hackers/scripts that connect to port 25, figure out that my sendmail isn't a combination of MTA/OS/version that they can crack into, and disconnect without doing anything? (If that's it, why do they connect repeatedly?) Or is something else going on? While I have fail2ban running, and I see regular bans occur, is there anything else to do about this? For context, the OS is Fedora 19.

Note: What especially confuses me about this is that I typically see many of this in a row from the same IP address. I almost never see this just once from a given IP address. I've even been "attacked" in this way, before, by multiple servers in the same subnet ... after each one gets banned (via fail2ban), they just move to the next server in the same /24 subnet. I finally changed my sendmail fail2ban rule to ban a whole /24 subnet instead of just a single IP address -- just to cut down on the noise. If this were just a "checking in to see if we could exploit" then I'd expect a single knock at the door, not such repeated attempts.

I'm actually tempted to put a 24 hour listen on port 25 -- I get little enough mail that this wouldn't kill me -- just to try to figure out what is going on in these connections. Some days I get dozens of these connections from the same IP address.

Improve this question
3

SMTP expects commands in the following sequence:

HELO or EHLO servername
MAIL FROM: <address>
RCPT TO: <address>
DATA

Though technically instead of MAIL FROM, the server could send EXPN, VRFY, or ETRN, though nobody ever does.

Apparently your server got the HELO or EHLO greeting, but then nothing after that, or something after that that wasn't expected.

Often this comes from monitoring agents or other scanners who aren't interested in actually sending mail, but rather just testing to see what's listening. Also, it's quite likely that they're attempting to exploit some old vulnerability, which is (correctly) simply being interpreted as garbage and terminating the connection.

Typically when a server takes some unusual steps (such at prematurely terminating a conversation) it will make a log entry noting the fact, just in case you need to debug it later.

Improve this answer
1
  • 1
    I use EXPN and VRFY all the time. Surprisingly, a lot of the time they actually work. – Michael Hampton Nov 25 '13 at 0:59
2
did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

This sometimes happens when the client hasn't issued any commands related to actually sending mail to your server (MTA). This might mean that you are being scanned and that they are just grabbing your banner to see what version of server you are running. It could therefore be part of an information gathering phase, and thus a forewarning of incoming spam.

Improve this answer
2
  • @Falcon Momot: By incoming SPAM, I assume you mean if they discovered an open relay, they'd use it to issue SPAM? Otherwise, why would someone scan a server before issuing SPAM to it? – Eddie Nov 23 '13 at 19:12
  • You can also spam things like root@[192.0.2.1], but yes, this is almost always an open relay scan. However, open relay scanning is more helpful when you actually send a message, so this might even be a first pass, though it's certainly not how I would scan for open relays. MTAs cannot make the relay denial until the RCPT, which must come after the MAIL if memory serves. – Falcon Momot Nov 24 '13 at 14:36
0

I started WireShark on port 25, and it's been running for almost 24 hours so far. I've seen three different variants of this so far. I'm guessing there are many more. This also helped me to realize that my sendmail is giving its exact name (sendmail as opposed to postfix or something else) and version. I've modified the 220 response below.

There are the "attacks" I've seen so far:

  1. The client issued FIN before my SMTP server event issued the 220. In other words, I saw the three-way handshake, followed by a FIN packet closing the client side, followed by my sendmail issuing its 220 identification line, followed by FIN/ACK and the socket closing. I have no idea what the point of that connection was! By issuing FIN before sendmail actually sent the 220, the client gave up the ability to interact with it in any way. If a bunch of these happened, I'd think maybe it was a DoS, but it happened exactly once. Weird.

  2. One client issued HELO with an invalid domain name, then EHLO with the same invalid domain name, where sendmail apparently just doesn't log the fact that it's returning 501 "Invalid domain name" complaints. It only logged that it never received MAIL/EXPN/VRFY/ETRN, which is misleading. Below is an edited SMTP transcription from WireShark, where the names have been suppressed to hide the guilty and the numbers in [ ] are the hex values of what was sent as part of the hostname. suppressed is where I'm suppressing the actual host name sent.

220 MyHostname ESMTP Sendmail version/version; Sun, 24 Nov 2013 04:05:22 -0400
EHLO [c7 cf bf b5 c1 f8].suppressed.co.kr
501 5.0.0 Invalid domain name
HELO [c7 cf bf b5 c1 f8].suppressed.co.kr
501 5.0.0 Invalid domain name

So basically it sent six characters with the high bit set, then what is actually a valid domain after that. Perhaps some MTA's choke on the bogus characters?

  1. This one is a "knocking" attempt, I'm guessing. e.g., that it sees the wrong version and gives up.

220 MyHostname ESMTP Sendmail version/version; Sun, 24 Nov 2013 09:52:59 -0400
RSET
250 2.0.0 Reset state
QUIT
221 2.0.0 MyHostname closing connection

Either this was knocking, or maybe some MTA's do something funny after getting RSET?

The moral of the story? Sendmail gives this log complaint for a variety of different malicious or weird client behaviours.

Improve this answer

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.