IDS Block All HELO *.* Who Try to Authenticate
Idea shared by caseyw - December 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.

3 Replies

Reply to Thread
2
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.
1
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).
2
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.

Reply to Thread