Suricata custom rule alerts but won't block

[RedDelPaPa]

Hello,

I'm trying to keep hackers and spammers from beating the bejesus out of my mail server.

Can anyone tell me why this rule will alert successfully, but will not block the remote IP in Suricata? This rule is only a slight modification from one that already exists within the rule sets. I had to create my own custom rule because my mail server responds with "Authentication failed" instead of "Authentication unsuccessful".

alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any (msg:"Custom SMTP AUTH LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; threshold:type threshold, track by_dst, count 3, seconds 60; classtype:suspicious-login; sid:1000001; rev:3;)

I have block offenders and kill states enabled in the Suricata interface settings.

Thanks for any help!
N8

[kiokoman]

i'm using fail2ban, it seems like i learned something new today..
port 25 should be used for SMTP relaying not authentication. 587 is the default mail submission port, coupled with TLS encryption, will ensure that email is submitted securely if you want/can follow the guidelines set out by the IETF.

anyway check if this can help you
someone else was doing something similar here
https://www.reddit.com/r/snort/comments/an5vbc/snort_alerts_and_hydra_brute_force/

[RedDelPaPa]

Thanks but I don't have the means to toss this pfsense box in favor of some new system or software at the moment. Thanks for the link. I'm looking into it now.

[kiokoman]

i hope it help, or i'm sure that @bmeeks can help you with this

[RedDelPaPa]

@kiokoman I hope he can respond. As again, that rule I have will alert, but it will not block the remote IP on 3 unsuccessful login attempts in 60 seconds as it should.

[bmeeks]

@RedDelPaPa said in Suricata custom rule alerts but won't block:

@kiokoman I hope he can respond. As again, that rule I have will alert, but it will not block the remote IP on 3 unsuccessful login attempts in 60 seconds as it should.

Are you running Suricata in Legacy Blocking Mode or Inline IPS Mode? If using Inline IPS Mode (or if using Legacy Blocking Mode with the Block on DROPS Only option enabled, then you will need to change the action verb of your rule to DROP from ALERT.

You will also need to be sure that the IP you want to block is not included in your Pass List (if using Legacy Blocking Mode).

[RedDelPaPa]

@bmeeks Hello.

So I have tried using this rule with drop instead of alert. It still will not block remote IP's.

[bmeeks]

@RedDelPaPa said in Suricata custom rule alerts but won't block:

@bmeeks Hello.

So I have tried using this rule with drop instead of alert. It still will not block remote IP's.

You didn't answer my questions, though.

1. Are you running with Inline IPS Mode or Legacy Mode blocking?

2. If using Legacy Mode, do you have the "Block on Drops Only" option checked?

And one more question, if using Legacy Mode, how is the "Block Which IP" option configured? My guess is the IP you think should be blocked is actually in your Pass List.

Follow-up edit: after looking again at your rule, I suspect the problem is your rule is backwards. At least what you copied into your post is not correct. The rule you copied in your post says this --

"if any server whose IP is in the SMTP_SERVERS variable attempts an outbound connection from port 25 to any external host and any port on the Internet, then alert."

I doubt that is what you want. You are wanting to see traffic inbound to your own mail server I suspect. Your rule should instead look like this if I am correct:

$EXTERNAL_NET any-> $SMTP_SERVERS 25 (msg:"Custom SMTP AUTH LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; threshold:type threshold, track by_dst, count 3, seconds 60; classtype:suspicious-login; sid:1000001; rev:3;)

The way you have your rule written, you are getting an alert when servers in your SMTP_SERVERS variable try to login to external mail servers. I suspect all of the IP addresses in SMTP_SERVERS are likely within a local subnet defined on your firewall (either LAN or DMZ), so these would all be in the default Pass List and therefore not blocked.

[kiokoman]

i think that the logic is that you see "Authentication failed" when $SMTP_SERVERS 25 answer back to $EXTERNAL_NET
and in this case the
"Which IP to Block" should be set to DST or BOTH after putting $SMTP_SERVERS to the white list

[RedDelPaPa]

@bmeeks Oops, I apologize.

1 I'm running in legacy mode.

2 I'm not aware of a "Block on drops only" setting. I will look for it.

What do you mean by block which IP? How and where is that determined?

Pretty sure the test public IP I'm trying to block is not in my pass list because I have a different test rule that will block it on alert.

Ideally, I wanted suricata to block the remote IP when the SMTP server behind pfsense returns an auth failed message to the client. I reckon I could write to block on too many AUTH LOGIN attempts from a client? In fact, I have a test rule for that which does work. So maybe it has something to do with which direction the content message travels?

[RedDelPaPa]

@kiokoman Hello,

What sets which IP to block? Is that the track by setting in the rule?

[RedDelPaPa]

This post is deleted!

[RedDelPaPa]

@bmeeks

[bmeeks]

@kiokoman said in Suricata custom rule alerts but won't block:

i think that the logic is that you see "Authentication failed" when $SMTP_SERVERS 25 answer back to $EXTERNAL_NET
and in this case the
"Which IP to Block" should be set to DST or BOTH after putting $SMTP_SERVERS to the white list

Yeah, you are correct on the rule logic. It was late last night when I posted and I was not thinking clearly ... .

[bmeeks]

@RedDelPaPa said in Suricata custom rule alerts but won't block:

@bmeeks

This is the screen for the "Which IP to Block" setting. It literally means which IP out of the two contained in the IP header should be blocked (source or destination IP). However, the Pass List still applies; so if either of the IP addresses is in the Pass List then that IP won't be blocked.

[bmeeks]

Just for a test, rewrite the rule and omit the thresholding parameters. I wonder if the threshold logic might could be responsible for my custom blocking plugin not getting a copy of the alert.

[RedDelPaPa]

@bmeeks Ok, here is the new version:

alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any (msg:"SMTP AUTH FAILED LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; classtype:suspicious-login; sid:1000005; rev:3;)

Again, it alerts, but no blocky.

[bmeeks]

@RedDelPaPa said in Suricata custom rule alerts but won't block:

@bmeeks Ok, here is the new version:

alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any (msg:"SMTP AUTH FAILED LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; classtype:suspicious-login; sid:1000005; rev:3;)

Again, it alerts, but no blocky.

Hmm...this is puzzling. There is another user (from Southeast Asia, I believe) that is having a similar problem with alerts but no blocks. His posts are in the IDS/IPS sub-forum. So far I have been unable to reproduce his issue as the same setup results in blocks in my test lab but not on his production system. I'm wondering if his is load related as his firewall is processing a ton of traffic as a hub for 170 school systems.

In your case I would not suspect loading as much, but I assume since you protecting a mail server that your firewall is for some type of business or other high user count environment. Is that true?

Suricata has a chain of processing that packets go through, and an API is provided that allows you to register your own custom plugin into that processing chain. That's how the Legacy Mode blocking module works in Suricata for pfSense. I wrote a custom plugin that registers itself as a "log output module". In this manner, Suricata is supposed to send my plugin a copy of every single alerting packet. My plugin then analyzes the IP addresses in the packet, compares them to the Pass List addresses, and blocks the IPs if they are not in the Pass List.

The actual alert logging, however, is done by the built-in Suricata alert-fast module. That module is the one creating the alert.log file that the GUI package then reads to display alerts on the ALERTS tab. So that means there could be a theoretical circumstance where an alert was channeled through the alert-fast module and thus logged, but that same alert did not make it to my custom blocking module. At least that's a theory I'm currently mulling around in my head.

I've been reading through all the Suricata binary's source code trying to figure out what could possibly account for such a weird situation as experienced by the guy in Southeast Asia. Perhaps that situation is also applicable to you in some manner. I may try and get some assistance from the upstream Suricata developers to see if there is something I might be misunderstanding about the packet processing chain.

[RedDelPaPa]

No, my pfsense box is for personal use. Loading is minimal.

Does my rule block for you on your test box?

I can make a rule that alerts and blocks if I have it check for content coming from the client instead of being sent by the smtp server.

[RedDelPaPa]

@bmeeks There is also a default rule in the rule set that is almost exactly the same as mine, but I can't use it because it checks for content: Authentication unsuccessful. My server doesn't respond with that message to failed auth. My server uses: "Authentication failed".