inline custom pass rule no workie?

[Tantamount]

first, I've read the 2018 post here from @bmeeks about the use of the custom rules category to create pass rules instead of using the passlist:

I'm running a number of breach and attack simulation tests where I need the traffic to pass through Suricata unscathed.

I've got Suricata running on the WAN interface (don't yell at me, that's the only physical interface that allows for inline with this device until freebsd catches up with drivers).
Under WAN Rules, under the "custom.rules" category I've added the following rule:
pass ip 3.23.218.97/32 any <-> any any (msg: "Pass List Entry - allow all traffic to/from safebreach 3.23.218.97/32"; sid:1000102;

(I assume that sid is unused -- wish there was a way to autogen those)

I've restarted the service, and if I go into WAN Rules, under the "Active Rules" category I see the rule listed:

However, when I execute a test, I see that it still shows up as getting blocked:

fwiw, I have Checking this option will automatically block hosts that generate a Suricata alert and Enable automatic management of rule state and content using SID Management Configuration Lists enabled.

(I use dropsid.conf to disable a number of ET categories in SID Management)

[bmeeks]

Try removing the subnet mask from your custom rule. I'm not 100% sure that is supported. Suricata may not be properly recognizing the address when checking a match.

FWIW, the Suricata Docs do not show the subnet mask in their PASS rule example here: https://docs.suricata.io/en/latest/performance/ignoring-traffic.html#pass-rules.

So, edit your custom rule to read like this:

pass ip 3.23.218.97 any <-> any any (msg: "Pass List Entry - allow all traffic to/from safebreach 3.23.218.97/32"; sid:1000102;)

And, I'm assuming it was just an error when you pasted the rule text into your original post, but the custom rule is missing the closing parenthesis. I added it above.

[Tantamount]

So I was lazy and had copied that rule directly from your 2018 passlist post and swapped out the ip. It had the subnet mask and the missing closing parenthesis unfortunately.

Is it strange that the malformed rule would still show up under the active rules?

In any event, I tried two edits -- the first was just to add the missing parenthesis, and the second was to remove the subnet mask. This is the current rule:
pass ip 3.23.218.97 any <-> any any (msg: "Pass List Entry - allow all traffic to/from safebreach 3.23.218.97/32"; sid:1000102;)

For each edit I clicked the "Stop Suricata on this interface" button (and verified there was no suricata process running using ps aux from a shell).

Again, Active Rules shows that the rule is in place and is enabled.

But still, the traffic is blocked.

I saw something I thought might have been the cause -- under SID Management there's a "SID State Order" setting that was set to "disable / enable" but swapping that and restarting the process didn't help. I only have the drop SID list populated, but figured what the heck.

I also double checked that I didn't somehow add the custom.rules to the dropsid.conf file, but I assume had that been the case, it wouldn't have shown up under Active Rules.

Btw, I should mention versions in case that's relevant -- I believe I'm running the latest:

2.7.2-RELEASE (amd64)
built on Fri Dec 8 12:55:00 PST 2023
FreeBSD 14.0-CURRENT

Suricata 7.0.3

[bmeeks]

Well, that was a long shot in the dark kind of theory as I would really have expected a syntax error to be thrown if the Suricata binary could not parse the rule .

While I don't expect updating to have any impact on the issue, 7.0.3 is not the current package release. That is now 7.0.6. The updated package should show up under the SYSTEM > PACKAGE MANAGER menu.

I'm kind of out of ideas at the moment. The SID MGMT stuff has nothing to do with your custom rules. Those are always loaded, because it's assumed if the admin goes to the trouble of creating custom rules they wish to use them. The custom rules are the very last thing added and written to the active rules file that is passed off to the Suricata binary.

You can verify your rule is actually present by viewing the contents of the file on the file system. It will be located here: /usr/local/etc/suricata/suricata_xxxx/rules/suricata.rules, where _xxxx will be the physical interface name where Suricata is running combined with a UUID.

The YAML config file for the interface should have this section in it which tells the engine to always process PASS actions first.

# Set the order of alerts based on actions
action-order:
  - pass
  - drop
  - reject
  - alert

In your case it seems the PASS action is not "sticking" if the rule is being loaded and evaluated. Have you checked the suricata.log file for the interface to be sure the rule is loading and did not encounter some type of error? You can examine the log file under the LOGS VIEW tab. If the rule failed to load for any reason, that should produce an error in the suricata.log file for the interface.

[Tantamount]

Okay, I've updated to 7.0.6

If I check the file contents for the interface, I can see the custom rule in the custom.rule file, but not in the suricata.rules file:

[2.7.2-RELEASE][admin@pfSense]/usr/local/etc/suricata/suricata_55760_igc0/rules: cat custom.rules
pass ip 3.23.218.97 any <-> any any (msg: "Pass List Entry - allow all traffic to/from safebreach 3.23.218.97/32"; sid:1000102;)
[2.7.2-RELEASE][admin@pfSense]/usr/local/etc/suricata/suricata_55760_igc0/rules: grep "1000102" suricata.rules
[2.7.2-RELEASE][admin@pfSense]/usr/local/etc/suricata/suricata_55760_igc0/rules:

The action-order in the configuration file looks like what you provided -- pass is first.

[bmeeks]

@Tantamount said in inline custom pass rule no workie?:

If I check the file contents for the interface, I can see the custom rule in the custom.rule file, but not in the suricata.rules file:

I'm sorry, that is correct. I misspoke earlier. The custom rule should be in the custom.rules file and not the suricata.rules file. The suricata.yaml for the interface should contain a line that is loading both the suricata.rules file and the custom.rules file like this:

rule-files:
 - {path_to_rules_files}/suricata.rules
-  {path_to_rules_files}/custom.rules

Have you taken a look at the suricata.log file to see if anything is logged there while Suricata is starting up and parsing the rules? You can view it under the LOGS VIEW tab by choosing that logfile and then choosing the correct interface in the drop-down selector.

I'm beginning to wonder if the Suricata binary is rejecting the custom rule during startup and thus not actually loading it into memory. Having the rules in either of the two rules files does not guarantee the binary actually loads and uses them. If there is an error parsing a rule as it is read in from the rules file, the rule will be discarded by the engine and a log entry added to the suricata.log file.

[Tantamount]

Thanks for pointing me to the right log to look in:

[100782 - Suricata-Main] 2024-09-06 18:10:34 Error: detect-parse: "<->" is not a valid direction modifier, "->" and "<>" are supported.
[100782 - Suricata-Main] 2024-09-06 18:10:34 Error: detect: error parsing signature "pass ip 3.23.218.97 any <-> any any (msg: "Pass List Entry - allow all traffic to/from safebreach 3.23.218.97/32"; sid:1000102; rev:1;)" from file /usr/local/etc/suricata/suricata_55760_igc0/rules/custom.rules at line 1

I had previously grepped for "<->" wondering if it was valid and didn't get any matches in suricata.rules file which raised my suspicions so I asked ChatGPT 4o if it saw any mistakes in the rule and it gave it a clean bill of health. I even directly asked about it:

I know LLMs can hallucinate, but historically I've found that it will add qualifier words like "probably" when it's making crap up.

Appreciate the help, changing it to '<>' solved the problem! I wonder, if you are still able to edit that 2018 post and correct the examples, it might save you from future threads created by copy-paste numb nuts like myself. :)

[bmeeks]

@Tantamount said in inline custom pass rule no workie?:

I wonder, if you are still able to edit that 2018 post and correct the examples,

I should be able to. Will give it a whirl.

Update: fixed it!