Filtering Packets with EHLO 'XYZ' Data

doktornotor

There's a (broken) postfix mail relay package.

dbennett

Thanks for the reply!

Dare I ask how "broken"?

Thanks

Dino

doktornotor

Well, search the Packages subforum and you can see for yourself. I'm not personally using it, so… :)

johnpoz

what exactly are you trying to accomplish might I ask?

dbennett

If EHLO = 'XYZ' and occurs > '###' of times than block. Preferably drop the connections for that IP and add a rule. But blocking is good enough for me right now.

I've noticed a pattern in some of the EHLO values over the course of the year and would like to target that instead of just the IP or subnet. In one example as to why I would want to do this; one EHLO pattern is known but that pattern has reused an IP only 5% of the time.

Thanks for the post!!

Dino

johnpoz

You would have to do something like that with layer 7

https://doc.pfsense.org/index.php/Layer_7

doktornotor

Really this is best done on a mailserver. If you are on 2.2.x, I wouldn't touch L7 at all since it only produces a CPU burn-in test - https://redmine.pfsense.org/issues/4276

Derelict

Exim:

If HELO/EHLO is "bad-helo" drop the connection after delay

acl_check_helo:
drop
message = Service temporarily unavailable
condition = ${if eq {$sender_helo_name}{bad-helo}{yes}{no}}
delay = 30s

accept

BBcan177

I have tried to do this in postfix but couldn't find a solution, so I ended up adding a custom rule to Snort…

Getting hit by a usually EHLO ylmf-pc (Chinese OS)

Snort won't block it fast enough to prevent a couple login attempts, but it will stop an IP after about three attempts. This is because currently Snort is acting on a copy of the packet.

alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP EHLO from ylmf-pc attempt"; threshold: type limit, track by_src, count 1, seconds 60; content:"ylmf-pc"; nocase; classtype:suspicious-login; sid:9000032; rev:2;)

johnpoz

ah ylmf-pc, isn't that pushdo – pretty sure most of the IPs that spambot net is coming from is in zen https://www.spamhaus.org/zen/

They are most likely hitting you fast are they not.. You could prob put in a rate limit rule on your rule that allows connection to your smtp server, pretty sure if that is triggered puts it into virusprot table and then they get dropped..

Not sure exactly when the virusprot table clears.. Check the crons

dcol

This is why we need Suricata Inline IPS. A good example here with EHLO from ylmf.
I want to block all EHLO's of localserv, but not block the IP from future access.

Can't be done without Inline Suricata, which is not working on PFsense right now. Not sure it ever will be.

jimp

It's better to properly configure the mail server rather than relying on other layers as your only means of protection. Postfix can do this very easily.

main.cf:

smtpd_helo_required = yes

smtpd_helo_restrictions =
          permit_sasl_authenticated
          permit_mynetworks
          check_helo_access hash:/usr/local/etc/postfix/helo_checks

/usr/local/etc/postfix/helo_checks


ylmf-pc REJECT Go away
localhost REJECT None for me, thanks
sometrustedserver OK

Every time you edit that file from that dir, run

postmap helo_checks

Derelict

pfSense and snort/suricata should not be able to see that traffic anyway because it should be encrypted.

I realize we have a LONG way to go with SMTP in this regard but it will only become more common, not less common.

So you are better off implementing the proper solution.