Snort Inline IPS Mode
Snort Package 4.0 Inline IPS Mode Configuration
IMPORTANT HARDWARE LIMITATION
The new Inline IPS Mode of Snort will only work on interfaces running on a supported network interface card (NIC). Only the following NIC families currently have netmap support in FreeBSD and hence pfSense: em, igb, ixgb, ixl, lem, re or cxgbe. If your NIC driver is not from one of these families, netmap and Inline IPS Mode is not going to work properly, if it works at all.
Introduction:
The Snort 4.0 package offers a new mode of operation called Inline IPS Mode. This mode operates quite differently from the original Legacy Mode blocking. To contrast the difference, let's briefly dive into the details of how Snort works on pfSense.
Snort on pfSense uses a custom output plugin to implement the Legacy Mode blocking. This custom plugin receives a copy of every single alert generated by a Snort rule. The custom blocking plugin extracts the IP addresses from the alerting packet and then, after screening them through a Pass List filter, will make a FreeBSD system call to place the offending IP addresses in a pf (packet filter) table called snort2c. This table is created by pfSense at boot-up. A hidden firewall rule (hidden from the GUI but visible if you view the contents of the /tmp/rules.debug file) then blocks any IP address entered into the snort2c table. That's how Legacy Mode blocking works. Any alert can generate a block. The downside of this approach is that the admin can't choose rules to just alert and other rules to block. It's either all block or all alert (blocking off).
The new Inline IPS Mode dispenses with the custom output plugin used by the Legacy Mode blocking. Instead, it uses the netmap module within the DAQ library to create a netmap pipe between a physical NIC driver and the pfSense operating system network stack. In this manner, all traffic flowing to and from the physical interface and the operating system must pass through Snort. Snort can then either allow the packet to pass, or it can drop it. A dropped packet is the same as "blocked". The major advantage offered by this new operating mode is the ability to now select which rules alert but don't block, and which rules alert and block. You do this by changing the rule's action from the default ALERT to either DROP or REJECT. DROP rules drop the packet without any indication to the sender. REJECT rules drop the packet but send either a RST (for TCP traffic) or a "Destination port unreachable" (for UDP or ICMP traffic) to the originating host.
Key and Important Difference Between Inline Mode and Legacy Mode:
With Legacy Mode blocking, once you enable "Block Offenders" there is nothing else to do. All alerts will generate blocks.
However, Inline IPS Mode is quite different! Because the default action of all rules from the rule vendors is ALERT, if you enable Inline IPS Mode but don't change the rule actions, you will get no blocks. You must change the action of rules you wish to block traffic to be either DROP or REJECT. Details on how to do that follow below.
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.
============== End