EHLO Domain block via regex
Question asked by J. LaDow - 6/26/2023 at 1:47 AM
We are trying to implement an EHLO Domain block for connections that are IP address only in the EHLO string:


With our particular configuration, every machine that connects with this format EHLO domain is attempting to brute force credentials or is attempting to use stolen credentials.  They only connect once from a particular IP - then within a second, they try again from another IP and add or remove a domain name from the attempted user login string passed.  IDS rules never catch them - EHLO block would work because they never get a chance to authenticate.

We have read the thread (portal.smartertools.com/community/a861/smtp-blocking-ehlo-domain.aspx) where it states regular expressions are usable in the EHLO Domain entry, but it doesn't seem they work (or at least any variants we have tried) --

Is there something we're missing to trigger regex style scanning in the EHLO Domain string?  Wildcards work, but that isn't a workable solution - too many false blocks.

An additional note - we have also read in the documentation where SM uses a "soft-block" when it comes to certain blocks in IDS.  It would be nice to have the option to just hard-block the connection with a "Policy Violation" response and not give them a chance to waste any more bandwidth or other resources.  Responding with "server busy" just encourages them to try again later from our experience.
MailEnable survivor / convert --

7 Replies

Reply to Thread
Use [*.*.*.*] in EHLO blocking.

It works.
Hi all!

Could you explain better how HELO blocking works using filter "[*.*.*.*]"?

I'm always afraid that filters of this kind (i.e. very large and generalized...) can also block valid emails...

What are the problems that could occur with this filter and in which cases?
Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Senders with no reverse ptr gets blocked.

Most proper mailservers has a reverse PTR and therefore you will deal with 99% of shit from even before it hits the server....
Douglas Foster Replied
Based on my data, if the HELO name is an IP address in quotes, you are probably looking a Spam.   Apparently your results are similar.   A subset of spammers are really sloppy, so it can be useful to look for sloppy.

The big problem with parsing Received headers is that there will be more than one, and you may only be interested in the last one.   If  you use Declude or Declude Reboot, SmarterMail will pass the current HELO name in the .HDR file.  With just SmarterMail, you may trigger on some earlier Received entries which may or may not indicate a problem.
I will assume that you are only interested in IPv4 addresses.   We are looking for a pattern of the form:

A simplified version of the IPv4 match looks for 1-3 digits, separated by dots. repeated several times.
The token \s+ is used to indicate whitespace (any type), of one or more characters.
[0-9] says any character in this range
{1,3} says the previous thing must occur one to three times.
The \[ character forces the "[" character to be treated as a literal, rather than a code.
The \] character forces the "]" character to be treated as a literal, rather than a code.
So we have

Look at "Raw Content" from several messages to get your real-world examples, then test the guess that I have provided, using a regex testing site like regex101.com

For example, you need a switch to make the word FROM case-insensitive.   The test site will help you with that syntax.
Millennium Systems Replied
That didn't work out well for us. Adding [*.*.*.*] to SMTP blocked prevents some users from authenticating.

[2023.06.27] 16:42:47.156 [][23461360] cmd: EHLO []
[2023.06.27] 16:42:47.157 [][23461360] rsp: 250-mail.*****.com Hello []250-SIZE 41943040250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK
[2023.06.27] 16:42:47.157 [][23461360] The domain given in the EHLO command violates an EHLO SMTP blocking rule. Any authentication attempts or RCPT commands will be rejected.
[2023.06.27] 16:42:47.183 [][23461360] cmd: AUTH LOGIN
[2023.06.27] 16:42:47.183 [][23461360] rsp: 334 VXNlcm5hbWU6
[2023.06.27] 16:42:47.204 [][23461360] Authenticating as ***@****.com
[2023.06.27] 16:42:47.204 [][23461360] rsp: 334 UGFzc3dvcmQ6
[2023.06.27] 16:42:47.232 [][23461360] rsp: 535 Authentication failed

Client started authenticating again after removing the block.
Douglas Foster Replied
Overall, SmarterMail provides a pretty rudimentary toolkit for spam filtering.   Their business is mail processing, not primarily mail filtering.   Serious filtering requires additional tools.

Server architecture also matters.   As you discovered, unauthenticated SMTP requires different filtering strategies than authenticated SMTP.   Consequently, you gain a lot of benefit by separating them onto separate servers.  Use an incoming gateway to filter the unauthenticated traffic coming from the Internet on port 25.   Use ports 587 on your mail server for secure SMTP traffic from POP and IMAP clients.  Then configure your firewall for the geo-ip sources that are accepted for the two different purposes.

SmarterMail provides a free incoming gateway, with lots of options for plugging in your favorite free spam filtering products.  Alternatively, use a commercial product as your incoming gateway.   My organization actually uses both:   SmarterMail with Declude filters out unwanted senders, then two commercial products filter out unwanted content.   

Just for fun, we are adding a fourth server to do in-depth parsing of the traffic that makes it through the first three hurdles.   It is another SmarterMail incoming gateway for transport, with a new bunch of custom code to do parsing and logging.

J. LaDow Replied
Use [*.*.*.*] in EHLO blocking.

It works.
For us, this solution is what we are currently using.  We have about half a dozen clients that had issues with their device not properly reporting at least some host name - I would rather force them to fix their configuration than deal with the onslaught of login attempts if we disabled this rule.

It would be preferable if we could use regex in this field, as this only works for IPv4 addresses and since enabling it, we're now seeing attempts from IPv6 addresses -- which are much harder to scan for without a regex option.
MailEnable survivor / convert --

Reply to Thread