IDS Block All HELO *.* Who Try to Authenticate

Idea shared by caseyw - 12/5/2017 at 10:27 AM

Completed

It would be nice to be able to have an IDS SMTP rule that would block HELO *.* followed by an AUTH LOGIN.

I would set it like;
Time Frame: 1440

Threshold: 2

Block Time: 43200

And if one really automated this, the third offense would add them to the black list :-)

Our logs are filled with this kind of garbage...

00:04:12 [46.13.150.215][22201523] rsp: 220 mail.your-domain.com  Mon, 04 Dec 2017 08:04:12 +0000 UTC - SmarterMail
00:04:12 [46.13.150.215][22201523] connected at 12/4/2017 12:04:12 AM
00:04:13 [46.13.150.215][22201523] cmd: HELO *.*
00:04:13 [46.13.150.215][22201523] rsp: 250 mail.your-domain.com Hello [46.13.150.215]
00:04:13 [46.13.150.215][22201523] The domain given in the HELO command violates an EHLO SMTP blocking rule.  Any authentication attempts or RCPT commands will be rejected.
00:04:13 [46.13.150.215][22201523] cmd: AUTH LOGIN
00:04:13 [46.13.150.215][22201523] rsp: 334 VXNlcm5hbWU6
00:04:13 [46.13.150.215][22201523] Authenticating as liz
00:04:13 [46.13.150.215][22201523] rsp: 334 UGFzc3dvcmQ6
00:04:13 [46.13.150.215][22201523] rsp: 535 Authentication failed
00:04:14 [46.13.150.215][22201523] cmd: QUIT
00:04:14 [46.13.150.215][22201523] rsp: 221 Service closing transmission channel
00:04:14 [46.13.150.215][22201523] disconnected at 12/4/2017 12:04:14 AM

We, and I'm sure others, would gladly take advantage of such a rule. There are a few other great ideas on here that should be considered as well.

6 Replies

Reply to Thread

network admin Replied

12/5/2017 at 1:12 PM

Unless they broke this in the recent builds they added a built in block over the summer for that exact problem. I know because I reported it.

Version 16.0.6362 (Jun 2, 2017)

Changed: "*.*" HELO commands are now rejected.

Scarab Replied

12/5/2017 at 1:27 PM

Clever spammers, knowing that Mail Server Software can't block a HELO/EHLO of *.* if wildcards are enabled without blocking everyone! Not sure whether to be impressed or disgusted by their cleverness. Although from your log excerpt it looks like you did SMTP Block the EHLO domain of *.*. Does that actually work in SM without blocking all EHLO domains?

About the closest you can come would be to make an IDS Rule for Bad SMTP Sessions (Harvesting) with your criteria and do second rule that on the third offense blocks for a ridiculously long time like 525,600 or 10,512,000 minutes (1 year and 20 years). The problem being is that you could potentially block a lot of legitimate traffic this way whenever an email address is no longer valid and senders attempt to send to that address.

To be honest they are already blocked by the SMTP Blocking of the EHLO (still not sure how you got that wildcard string to work without blocking everything). Although SM is humoring them as a Honeypot for SMTP Blocking of EHLO they aren't ever able to do anything more than take up a single connection for a second or two and waste their own time. They are effectively blocked already and don't require a need to be further blocked by IP using IDS Rules. If you really feel the need for blocking these by IP I would suggest not going any lower than 50 Bad Sessions Per 60 minutes to prevent blocking legitimate senders (that's what we use with a 0.5% false-positive rate where we have to manually unblock a handful of legitimate IPs out of the thousands we block...although most of them we just end up adding to Whitelists to avoid having to unblock them again a week or two later).

Scarab Replied

12/5/2017 at 1:29 PM

Didn't see your post before I replied. Good catch!

network admin Replied

12/5/2017 at 1:41 PM

No worries Scarab. I have the good fortune for no customers outside of the US. And very few inside. So I have a well developed Blacklist (602) and Email/HELO reject list (495). I am not beyond using very large ranges to block most of the rest of the world. I use a script in PowerShell on my server to watch the SMTP log, I also have a monitor for the delivery log. So at least during the day I am not caught to unawares by those who would abuse the email server.

get-content "c:\smartermail\Logs\$(get-date -format yyyy.MM.dd)-smtpLog.log" -tail 5 -wait

Make sure you change the Drive letter to reflect your installation.

caseyw Replied

12/5/2017 at 2:14 PM

The HELO *.* block is built-in to SM now (we're on 16.3.sumpin).

When they are blacklisted;
they are much more likely to give up or spend less time trying
logs are smaller
Blacklisted: 4 log lines per attempt
Not blacklisted: 13 lines or more

I manually blacklist repeat offenders and persistent ones - just hit 800. It would just be nice to not have to spend time doing it. Gung-ho offenders get firewalled, some block themselves as an intrusion attempt.

Guess I'm just looking for smaller logs and some of my time back.

network admin Replied

12/5/2017 at 3:14 PM

The way I fixed that was change the rules. Increase the penalty for violation and decrease the number of attempts while increasing the time for number of attempts before triggering.
Look at your IDS Rule Set Time is in Minutes. 5 failed logins in a 60 minute time results in an automatic 36000 minute (25 day block). This is not the rule I actually use. Just an example.

Password Brute Force by Protocol SMTP 60 5 36000 Edited SMTP brute force relaxed rule

By increasing the time period for failed logins I catch most of the idiots out there. And because it is automatic I really only monitor how many IDS blocks are active at any given time. If there is a sudden increase I take a look at the list of networks and where I see a bunch from the same subnet or country I then can take action against that entire network or subnet.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text