Project

General

Profile

Actions

Bug #16808

open

During re-install or update, suricata re-enables rules that were disabled

Added by CMDesign CMDesign 23 days ago. Updated 21 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Suricata
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:

Description

Whenever suricata is re-installed, or updated (i.e. after it was previously installed and configured), it re-enables all the "Ruleset: Default Rules" rulesets/categories in all interfaces, even though it retains all the other rulesets/categories enable/disable settings.

This is a significant issue, particularly on updates, because as those rules seem to be mostly informational, when they get re-enabled especially on an interface that has blocking turned on, it causes problems, and I'm guessing that many users don't know or remember to go in and turn them back off after a pfSense/suricata update. An update (or re-install) should not change existing settings/configuration without a warning/explanation notification/popup).

Actions #1

Updated by Marcos M 22 days ago

  • Affected Plus Version deleted (26.03)
  • Affected Architecture deleted (SG-2100, arm64)

There's no code to handle this case currently. I recommend using SID management; it would deal with this issue on top of generally being a better approach to rule management.

As an example, go to Services > Suricata > SID Mgmt and enable it with the following:
- dropsid.conf list: Show


- disablesid.conf list: Show
- SID State Order: Enable, Disable
- Enable list: dropsid.conf
- Disable list: disablesid.conf
- Drop list: dropsid.conf

Actions #2

Updated by Marcos M 22 days ago

  • Status changed from New to Confirmed
Actions #3

Updated by CMDesign CMDesign 21 days ago

Thank you for workaround and detailed example (and I'm aware that only certain entries in the "disablesid.conf" file related to this), but in my situation, I don't believe that will work.

"SID management" is a global level control, affecting all Interfaces. So for handling rule "Categories", that would be fine if there is only one interface, or if one doesn't want certain rule categories in any interface.

In my case, I have two interfaces, one interface configured for blocking (with threat-type rule categories), the other configured for informational purposes (with informational-type rule categories, mostly the suricata "Ruleset: Default Rules"). So I need the categories in that ruleset disabled in my blocking interface, and enabled in my informational interface - I presume that is why suricata has an interface-level "Categories" tab within each interface, so we can specify which interface uses (ideally uniquely) each rule category from the globally available rulesets.

For me, the only workaround is to hopefully remember, after an update, to go into the interface I used for blocking, and manually disable those categories again, with the other interface being fine as they are meant to be enabled there anyway. The enabled/disabled settings for all other rulesets and categories are remembered (after an update).

I would suggest/request that suricata be modified to do the same for it's own "Ruleset: Default Rules", as having an update change a users configuration without warning is not generally a good thing.

Thanks for the reply/help

Actions

Also available in: Atom PDF