Email server attack from telnet

Question

My mail server having a problem on blocking some attacker that trying to telnet to our mailserver. but i'm not able to block it, ip will keep changing even we block by ip. seems like he is trying to telnet instead of normal from smtp transaction. They are not able to enter our email server, but that is a transaction every second. is there any way to block it/stop it? below are the error message:

81.198.214.48   [0968] 16:14:01 Connected, local IP=xx.xx.xx.xx:25
81.198.214.48   [0968] 16:14:01 >>> 220 mymailserver.com ESMTP IceWarp 11.0.1.2; Fri, 13 Feb 2015 16:14:01 +0800
81.198.214.48   [0968] 16:14:02 <<< EHLO ylmf-pc
81.198.214.48   [0968] 16:14:02 >>> 250-mymailserver.com Hello ylmf-pc [81.198.214.48], pleased to meet you.
81.198.214.48   [0968] 16:14:03 <<< AUTH LOGIN
81.198.214.48   [0968] 16:14:03 >>> 334 VXNlcx5hbWU6
81.198.214.48   [0968] 16:14:04 <<< aGFua3M=
81.198.214.48   [0968] 16:14:04 >>> 334 UGFzcxdvcmQ6
81.198.214.48   [0968] 16:14:04 <<< ODg4ODg4
81.198.214.48   [0968] 16:14:24 >>> 535 5.7.8 Authentication credentials invalid
81.198.214.48   [0968] 16:14:24 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION 
81.198.214.48   [0968] 16:14:24 Disconnected

Answer 1

That idiosyncratic and invalid EHLO argument "ylmf-pc" is a known fingerprint of a widespread spamming botnet known as "PushDo" (and sometimes alternatively "Cutwail"). As shown in your transcript, it is mostly trying password guessing to authenticate and send mail through your server. Keeping it from sending spam to or through your server is easy, because of three characteristics:

1. It actually sends the EHLO command before it receives the SMTP banner sent by the target MTA, a behavior that any modern MTA worth using (i.e. maybe not Exchange or QMail) can detect as a definitive indication of an unwelcome, pure-spam client. No legitimate SMTP client exhibits such "fast-talking" behavior, since it breaks basic SMTP functionality.

2. The string "ylmf-pc" is not a valid EHLO argument, because it is not a fully qualified hostname or bracket-enclosed IP address literal. No legitimate SMTP client will ever use that argument. As with the fast-talk behavior, any decent MTA can be configured to reject mail from clients using an inherently invalid EHLO argument.

3. Nearly all infected members of PushDo/Cutwail are listed in the free zen.spamhaus.org DNSBL, by way of its "CBL" component. Even if you can't block for fast-talking or using a bogus EHLO arguiment, you should be able to block based on a DNSBL and doing so with the Zen list is almost universally a good choice.

Preventing your MTA from accepting any spam being offered should therefore be relatively easy with a well-configured MTA, but exactly how to do that with the "IceWarp" MTA you seem to be using is a question best asked of the vendor. It is more difficult to address the pure volume of traffic that can be involved, since a single PushDo zombie may try to open many hundreds of simultaneous sessions and come back multiple times in a day, while there can be dozens of different zombies actively trying to attack one server on any given day. Options to mitigate that can come from the MTA; for example recent versions of Postfix can be set to simply drop fast-talker clients unilaterally (using its 'postscreen' facility) instead of playing along with them through the whole SMTP conversation politely, and Sendmail can be similarly configured. To further reduce the problem, you can use a log-sniffing tool like fail2ban (described in a previous answer) to block traffic from the specific IPs. If you choose that option, note that PushDo infections tend to last for many days at a time so you shouldn't expire blocks any faster than about a week.

Answer 2

The helo name of the attacker is invalid (ylmf-pc) because it's neither a FQDN, nor resolvable via DNS, so you can easily get rid of it earlier, by blocking him after the invalid EHLO is sent.

To do this with postfix, for example, do:

smtpd_helo_restrictions = permit_mynetworks, check_helo_access reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit

But please also read the docs about smtpd_helo_restrictions

Then, you can use fail2ban to block him after some of those invalid queries came in. There's already an example for postfix included by fail2ban, but I don't know if it also includes rules for the HELO errors. You can add them if necessary.

jail.conf:

[postfix-ddos]

enabled  = true
port     = smtp,ssmtp
filter   = postfix-helo
logpath  = /var/log/mail.log
maxretry = 5

filter.d/postfix-helo:

[INCLUDES]
before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 504 5.5.2

ignoreregex =

This is totally sufficient to block those kiddies. You can turn down the maxretry setting in fail2ban to block the attack instantly, though I don't recommend that.

Answer 3

One of the other problems with the CutWail attacks, that while it is easy to stop on Port 25 as usually that is MTA->MTA traffic, it gets harder to address on port 587, where legitimate customers may be trying to connect. While the IP's might be on many RBL's such as SpamHaus and SpamRats, because customers use dynamic IP(s) to connect, shared connections etc, just because the IP is listed, doesn't mean the connection is bad. However, in order to be effective brute force attacks normally need lots of connections, and you can mitigate this be limiting the successive attempts, especially if the banner (HELO/EHLO) is 'ylmf-pc', but you should be aware that whatever tool you use to do this, make sure the block is temporary. And while the botnet will soon probably pick a different HELO, in the mean time blocking all attempts that present that EHLO on port 587 is probably best.