SID mgmt enable/disable question
-
I'd like to disable all rules in a given category and selectively enable others.
Ok, I know this question has been asked and I've spent the last couple days searching the forums but for the life of me I can't get this to work.
Let's take for example all rules that contain pfSense. A quick look in the rules files shows there are 16, all in /usr/local/etc/suricata/rules/snort_snort3-server-webapp.rules
# grep -ri 'pfsense' /usr/local/etc/suricata/rules | wc -l 16Ok. As per https://forum.pfsense.org/index.php?topic=95822.msg766436#msg766436, bmeeks states:
Simply put the name of the rule category in the disablesid.conf file to disable an entire category. Now to come back and selectively enable just some of the rules in that category will take a fancy PCRE in the enablesid.conf file.
I assume this would mean something like this:
enablesid.confpcre:(?i)pfsensedisablesid.conf
snort_snort3-server-webapp.rulesNo matter what I do, including toggling the SID State Order, rearranging the disable/enable rules in all possible orders, or changing from pcre to specifically add the rules by GID:SID, it simply never enables the category and thus doesn't enable the rules. The Active Rules remains empty. Now, if I enable the rule category manually, the pcre works fine and enables the rules, however, then the default rules are also enabled, leaving me the only option of disabling 242.
This approach works perfectly for the base rules such as files.rules, where if I add "files.rules" to disablesid.conf and then add "pcre:(?i)file magic" it works as expected and enables SIDS 1:16,1:23,1:17,1:18.
Any help from the experts is greatly appreciated.
-
Have you checked out this Sticky Topic? It explains the logic flow for SID MGMT.
https://forum.pfsense.org/index.php?topic=145467.0
Essentially what's going on is that your PCRE string is only matched against currently enabled rules, so that would mean only rules that you have manually enabled on the CATEGORIES tab or rules that have gotten enabled from having the category name (filename) listed in the enablesid.conf configuration.
Read the Sticky Post I referenced and see if that helps with a solution. I think you are going to have to enable that category and then disable the rules you don't want, or else just manually search through the file to find the SIDs you want to use and use SID ranges in the disablesid.conf configuration to disable the remainder.
Maybe the current SID MGMT logic within the package needs rethinking ???
Bill
-
Thanks for your response, bmeeks. I did see that page, and I indeed tried that.
For example:
enablesid.confsnort_snort3-server-webapp pcre:(?i)pfsensedisablesid.conf
snort_snort3-server-webapp.rulesThis results in snort_snort3-server-webapp.rules being completely disabled as a category and no rules from it active.
Leaving snort_snort3-server-webapp.rules out of disablesid.conf results in the category enabled with all the rules.
And finally, manually enabling snort_snort3-server-webapp.rules and only having the pcre or specified GID:SIDs in enablesid.conf results in the default rules enabled plus the additional rules in enablesid.conf.
I've tried every combination I can think of and was wondering if there was something I was missing. I've had to resort to enabling the category, placing the rules I want in enablesid.conf and then one by one disabling the other rules with disablesid.conf via pcre. It works but it's a long list of nots.
-
The difficulty you are running into stems from the logic of how SID MGMT works in the package. I'll try to explain without getting too deep into the woods.
All of the rules packages you enable for download (Snort, Emerging Threats, and/or Snort GPLv2) get unpacked and the individual files are stored in a common subdirectory. The vendors (with the exception of the GPLv2 rules) organize their rules such that related rules are in categories, and each category has its own *.rules file. So there exists a single sub-directory that has all the downloaded rules files in it.
When building the actual set of rules your Snort or Suricata instance will use, the GUI code starts by creating a list of of all the categories you have enabled (on the CATEGORIES tab). It pulls all of the rules from those files into an in-memory array. Next, it looks at the enablside.conf content to see if any additional categories (file names) need to be added. But at this stage in the rules building process it is only looking at the category names and is not doing any PCRE evaluations. At the end of this stage it has the list of all enabled categories (and thus the included rules, both default enabled and default disabled). This is Step #1.
Next, it evaluates the enablesid.conf content and will use any SID matching or PCRE matching statements to enable rules from the already selected categories (established in step #1 above). These would be default-disabled rules from the selected categories that you actually want enabled. This is Step #2 or #3 (depends on SID State Order setting).
Next, it evaluates the disablesid.conf content to see if what specific rules or categories should be removed the list. This is Step #2 or #3 (depends on SID State Order setting).
The "SID State Order" setting determines which of the two steps immediately above are executed first.
Finally, it looks through the modifysid.conf content using PCRE matches to change rule content.
So right now the logic in the GUI code is not set up to allow you to use PCRE to choose rules unless the category containing those rules is "turned on". That's what I meant by stating perhaps another look is needed at how the SID MGMT logic works.
Bill
-
Bill,
First of, thanks for taking the time to reply. I've spent the last couple days rereading your reply/linked post and implementing different variations but it appears to be the case that the only way to disable the default enabled rules is either by PCRE or one-by-one.
As I understand it, there is no way to disable the default enabled rules categorically once the category is enabled?
1. Enable rule category in GUI
2. Disable/Enable state order disables selected default rules via PCRE (placing the category disables everything doesn't reenable)
3. Selected rules are enabled via PCREI can't seem to disable a category, then enable just the rules I want. :-[
-
I can't seem to disable a category, then enable just the rules I want. :-[
[/quote]Unfortunately, that is the way the logic was implemented with the idea being that folks most often simply to want to tweak individual rules from an enabled category (such as change them from on to off or vice versa). So the logic starts off by only working with enabled categories. You can't select and enable rules from a disabled category because by disabling the category you've already told the package you don't want any of those rules. At least that's how I implemented the logic.
Bill
-
Thank you for this reply, Bill. I thought this was the case; I couldn't figure out why I just didn't get it.
I appreciate your work in maintaining the package. May I suggest a feature that would allow to PCRE through the rules folder and pick just the rules wanted would be nice. If I have the time maybe I'll try a submitting a PR after I delve deeper into the package source. Cheers!
-
Thank you for this reply, Bill. I thought this was the case; I couldn't figure out why I just didn't get it.
I appreciate your work in maintaining the package. May I suggest a feature that would allow to PCRE through the rules folder and pick just the rules wanted would be nice. If I have the time maybe I'll try a submitting a PR after I delve deeper into the package source. Cheers!
All of the code for the SID MGMT rule selection logic is in the file /usr/local/pkg/snort/snort.inc and the initial function in that file is snort_prepare_rule_files(). That main function calls a number of other functions to build the rule set using the SID MGMT configurations. It is all commented fairly well. The one big concern would be not to break any of the existing functionality, so lots of testing would be required to verify no unexpected behavior creeps in.
Bill
