Suricata policies are not applied

[buletti]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

I have selected a few rules sets and activated them. By default all the rules use the alert action. In order to make the IDS actually drop packets found by the rules, I want to switch them to the drop action. In order to do so I added a policy. Modifying all the rules manually breaks the GUI. Here's the policy I created:

• I did not select any "Rulesets", because I want all rule sets to be modified. No selection means "all" according to the tool tip. However, for the record I tried the same with explicitly selecting all the rule sets to no avail.
• As Action I selected "Alert".
• I did not select any "Rules". Again, I do not want to reduce the set of rules to which this policy applies.
• As New action I selected "Drop".

Now, If I check the applied policy on the rules in the "Rule adjustment" tab, then only a handful of the 30k rules are set to drop. Almost all rules are still using the alert action as you can see on the following screenshot. The table is sorted descending by the 'Action' column. All rules with a drop action are listed on top of the list.

So it seems the policy is not properly or only partially applied to the rules.

To Reproduce

Steps to reproduce the behavior:

1. create a policy for all rule sets to switch the rule actions from alert to drop.
2. check the rule adjustment tab, if the rules are modified according to the policy.

Expected behavior

The policy is applied to all rule sets and the result of the policy can be inspected in the "Rule adjustment" tab.

Describe alternatives you considered

None

Screenshots

see above

Relevant log files

Nothing in the Suricata log except for the ominous flowbit entries.

Additional context .

Environment

OPNsense 23.1.9-amd64 FreeBSD 13.1-RELEASE-p7 OpenSSL 1.1.1t 7 Feb 2023

Protectli FW2B Intel(R) Celeron(R) CPU J3060 @ 1.60GHz (2 cores, 2 threads) Coreboot v4.9.0.3

[AdSchellevis]

forgot to hit apply? I can't reproduce this on my end, given the cpu isn't very fast it might take some time to render. You can manually trigger the action to refresh the rules using /usr/local/opnsense/scripts/suricata/rule-updater.py when in doubt the script executes without issues. The policy configuration itself is stored in /usr/local/etc/suricata/rule-updater.config (after hitting apply)

[buletti]

Thank you @AdSchellevis for your support. I appreciate it!

No, I don't think it's the apply button. It seems to be something different. I'm a bit short on time at the moment and foreseeable for the next few days. I'll provide a more thorough response later on by the end of the week.

As for your points:

• /usr/local/opnsense/scripts/suricata/rule-updater.py seems to execute just fine. There's no indication of an error.

• A quick look into /usr/local/etc/suricata/rule-updater.config seems to have most rules enabled as expected.

• However, when I look into /usr/local/etc/suricata/rules.config, then most rules are still using the alert instead of the drop action and look like this:

[rule_08c68180a9c9401dbf12ba2d1fd985a1]
enabled=1
action=alert
sid=2100162

[AdSchellevis]

@buletti the overwrites in rules.config ([rule_XXX]) are populated from the "rule adjustments" tab and have a higher priority.

[buletti]

Is it correct to assume that the "Rule adjustments" tab displays the rules that are eventually used and applied?

I'm not sure how this whole rule processing works, but I believe it works like this according to my mental model: There are rule sets downloaded from the internet. The individual rules of the rule sets are set to the alert action by default. One has 3 possibilities to modify the downloaded default rules:

1. Modify the rules manually in the "Rules" tab. This is discourage as the UI, even though it supports bulk operations, is too sluggish to work on huge lists. Also this seems to blow up the configuration file, which is bad.
2. Apply a policy to the rule sets. There is some script applying the directives of the policy to all the downloaded rules according to the policy selection criteria and the modification operation selected. The result of these rule modifications can be inspected in the "Rule adjustment" tab.
3. Modify the rules manually in the "Rule adjustment" tab. There are no bulk operations supported, so it is really only feasible to modify single rules.

What I try to do, is to use 2.) to change all rules from "alert" to "drop" action. The policy seems not to change the rules, though, based on what I can see in the "Rule adjustment" tab resp. the rules.config file.

I will attach my suricata configuration of /usr/local/etc/suricata as a zip file for inspection. suricata.zip

[AdSchellevis]

Is it correct to assume that the "Rule adjustments" tab displays the rules that are eventually used and applied?

No, these are manual overwrites per rule (sid) which are applied (supersede) after the policies.

[buletti]

OK, thank you for the clarification. Then I'd assume the "Rule adjustment" tab should be empty in my case of only applying a policy. I have deleted all the rules listed in the "Rule adjustment" tab.

Now, where can I see the results of the policy being applied? How can I verify that the rules are modified correctly and the policy processing is working as expected?

[AdSchellevis]

Apply and check the adminstration->rules tab?

[buletti]

Ok, alright. I wasn't sure, if the policy was working, because the rules tab contained lots of rules still having the alert action. However, on second sight all rules that are enabled, are indeed switched to the drop action. So, I assume the policy is working despite only being applied to enabled rules. Now, having the overwrites removed, I can see drop rules being applied in the suricata log. So everything seems to be in order now. I'll close this ticket. Again thank you very much for your support @AdSchellevis