How Automatic SID Management and User Rule Overrides Work in Snort and Suricata

[bmeeks]

Automatic SID Management and User Rule Overrides in the Snort and Suricata Packages

Both Snort and Suricata offer two similar ways to customize the rules utilized for inspecting traffic.  You can use the CATEGORIES tab or the SID MGMT tab.  Before diving off into the details, let's first review a few basic points.

General Information About the Rules
IDS (Intrusion Detection System) rules in both Snort and Suricata have two identification keys.  The first one is called the Generator ID, or GID.  The second one is called the Signature ID, or SID.  The SID must be unique for every single rule.  The GID, on the other hand, can be the same for many rules.  GID is primarily used in Snort where the key value is used to indicate if a rule belongs to a particular preprocessor or if it is a general text rule.  Snort has a few pre-defined GID values such as 116 for the decoder rules and 138 for the sensitive data rules.  For the vast majority of rules, though, the GID is always "1".  However, just to be sure we always identify the rule we want, it is customary to refer to rules by their GID:SID such as 138:4 (for a given sensitive data rule) or 1:21019 for a generic text rule.  One key point to always remember, especially if you create your own custom rules, is that the SID must be unique!  You cannot have duplicate SIDs with the same GID.  So two rules with the GID:SID keys of 1:20119 and 1:20119 is illegal, but two rules can have the same SID so long as they have different GIDs (at least in Snort).

Several vendors maintain and publish collections of Snort and Suricata rules.  The two most popular are Emerging Threats (a.ka. Proofpoint) and Snort (a.k.a Talos).  These vendors publish a gzip archive containing thousands of rules organized into various categories.  Similar rules are grouped into individual category files whose file name sort of indicates the purpose of the rules.  For example, one Emerging Threats rule category is Emerging-DNS.  They include a file called emerging-dns.rules in their gzip archive.  This file includes a collection of IDS rules designed to detect known threats to DNS (domain name service) hosts.

A common misconception among IDS/IPS newbies is thinking all of the rules in a category file are enabled and used.  That is not, in fact, true.  Some of the rules within a category are what we call "default disabled".  This means the rule vendor has "commented out" those rules so they are not used.  Rules may be disabled by the vendor for several reasons, but the most likely is that the rule is prone to false positives in many environments.  A false positive is what we call it when a rule triggers but the actual traffic that caused the trigger is not really malicious.  There can be many reasons for this.  That does not mean the rule is useless, it just means that it is designed to function under a very specific set of circumstances that only a few users might experience.  Thus the rule vendor may elect to "default disable" that rule and let the admins of networks decide if they want to enable it or not depending on the unique configuration of their network.  The prior mentioned emerging-dns.rules category is a great example of this. Nearly one-third of the rules in that category are default disabled by the vendor.

Enabing Rules in Snort and Suricata
There are three ways to enable rules and rule categories in the pfSense Snort and Suricata packages.  The first is to use the CATEGORIES tab to select (by checking) the rule categories you want to use from the list extracted from the gzip rule archives you have enabled for download (Snort, Emerging Threats, etc.).  Checking boxes on the CATEGORIES tab will add those categories to your list of rules.  However, (and this is key!); it won't enable every rule in the category.  It will only use the rules from the category that the vendor left enabled.  Those "default disabled' rules we mentioned earlier won't be used in your rule set unless you take action on either the SID MGMT tab or utilize the User-Forced actions on the RULES tab to manually add them.  If you subscribe to and enable the Snort rules for download, then you have the option of choosing a pre-defined IPS Policy on the CATEGORIES tab.  This policy will automatically choose a set of rules from the entire Snort gzip archive collection.  When you choose to use a Snort IPS Policy, the manual selection of Snort categories is disabled.

Another way to select rules or rule categories is by using the features on the SID MGMT tab of each IDS package.  I won't go into the details of using SID MGMT here.  There are example files pre-loaded on the tab.  To see them, check the box to enable Automatic SID Management and they will be displayed along with the rest of the settings.  You can select rules in SID MGMT by Category Name or by the individual GID:SID values.

The third way to select individual rules is by using the User-Forced Enable/Disable icons on the RULES tab.  When a category is selected for viewing on that tab, the first icon on the left of each row of displayed rules will indicate the current "state" of that rule.  It will be one of "default enabled", "default disabled", "user-forced enabled" or "user-forced disabled".  Various icon shapes and colors are used to indicate the current rule state.  A legend at the top of the rules display list describes the icons used.  You can click on the icon to change the state of the rule to a user-forced value.

Who Has Precedance?
Snort and Suricata load your active rules using this process –

• Load all default-enabled rules from the various categories selected on the CATEGORIES tab.

• Add any rules found in additional categories enabled by name from the enablesid.conf configuration on the SID MGMT tab.

• Process any IPS Policy rules defined by the policy selected on the CATEGORIES tab.

• Remove any rules (or entire rules categories) from the list if the rule or category matches an entry in the disablesid.conf configuration on the SID MGMT tab.

• Process any forced user overrides of rule states (these are the GID:SID values the user may have selected for force-enable or force-disable on the RULES tab).

• Process and enable any rules required by Automatic Flowbit Resolution (when that feature is enabled)

• Process any forced user overrides of rules states one more time in case Flowbit Resolution enabled something the user really wants disabled

• Add any user-supplied Custom Rules (entered on the RULES tab under "Custom Rules") to the set of active rules

The complete list of active rules for the interface is then written to the Snort or Suricata interface subdirectory.  Only enabled rules are written to the file.  Writing the disabled rules would serve no useful purpose.

What Does "SID State Order" Mean on the SID MGMT Tab?
The SID State Order setting tells Snort or Suricata whether to process the enablesid.conf configuration or the disablesid.conf configuration first.  With SID MGMT, the last match wins.  So if you enable a rule in the enablesid.conf configuration and disable the same rule in the disablesid.conf configuration, then the rule will wind up disabled if your SID State Order is "enable/disable", but the same rule will wind up enabled if your SID State Order is "disable/enable".  So it pays to think through carefully what you want to accomplish and choose the appropriate SID State Order to fit your goals.

Bill

[cyberzeus]

bmeeks - I found the following link that describes what is included in each of the 3 IPS policies.  Note there is a 4th policy - MaxDetect.  Do you know if there are any plans to implement this in the Snort package for pfSense?

https://www.snort.org/documents/215

[boobletins]

@bmeeks Very cool. There's a lot happening in the pfSense package that I didn't know about -- I really appreciate the work you put into it.

[bmeeks]

@cyberzeus said in How Automatic SID Management and User Rule Overrides Work in Snort and Suricata:

bmeeks - I found the following link that describes what is included in each of the 3 IPS policies.  Note there is a 4th policy - MaxDetect.  Do you know if there are any plans to implement this in the Snort package for pfSense?

https://www.snort.org/documents/215

Replying to an old thread, but the answer is "yes". The new MaxDetect policy is now present and selectable in the Snort and Suricata packages. Just remember that the Snort folks recommend enabling that only for testing purposes! It is most definitely not recommended for a production network. It will generate a lot of false positives!