Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions

bmeeks

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.

Configuring Inline IPS Mode Operation:

Go to the INTERFACE SETTINGS tab for the interface and scroll down to the Block Settings section. Click to enable Block Offenders and then choose Inline Mode in the IPS Mode drop-down. See the image below. Note that in the screenshot below the WAN interface was chosen for Snort, but using the LAN interface is generally better and is now the recommended choice.

You now must decide which method you want to use for changing rule actions to DROP for those rules you wish to block traffic. There are up to three methods to choose from: (1) use the SID MGMT tab; (2) manually force rule action changes on the RULES tab; or (3) use the Snort Subscriber Rules and choose an IPS Policy and set the policy action to "Policy". Each method is detailed below.

Using IPS Policy to Automatically Change Rule Actions:
Use of this method requires usage of the Snort Subscriber Rules. You may also use Emerging Threats rules for other purposes, but only the Snort Subscriber Rules contain IPS Policy metadata. If you want to change the action for Emerging Threats rules, you must use one of the alternative methods of SID MGMT or manual rule action forcing (both described later in this post).

After enabling and downloading the Snort Subscriber Rules set, go to the CATEGORIES tab and click the checkbox to enable Use IPS Policy and then choose a policy from the IPS Policy Selection drop-down selector. If you are new to an IPS such as Snort, I strongly recommend you start with the "Connectivity" policy and do not choose one of the more stringent policies until after you gain experience using an IPS. If you choose "Balanced", or the more stringent "Security" policy, be prepared for some headaches due to potential false positives. Take my advice and don't do that to yourself if you are new to administering an IPS!

The screenshot below shows how to enable and choose an IPS Policy. Set the IPS Policy Mode setting to "Policy". This will let Snort automatically change the rule action according to the metadata encoded into the Snort Subscriber rule by the Snort Vulnerability Research Team. If you choose "Alert" here, then every rule in the policy will be set to ALERT. Note that if you do this, then none of the IPS Policy rules would block traffic.

Using SID MGMT to Automatically Change Rule Actions:
Go to the SID MGMT tab and click the checkbox to enable Automatic SID State Managment if not already enabled. Then click the ADD button to create a new SID managment list. See the screenshot below for an example.

Clicking the Add button will open the Editor Dialog where you specify the selection criteria for the rules that will have their action changed to DROP at runtime. You can specify a single SID, multiple SIDs separated by commas, a range of SIDs using the minus character ('-'), or provide a rule category name to select all rules in that category. In the example below the rule category emerging-scan rules will be selected and all of the rules in that category will be modified. Make sure you give the list a name and then click Save. You can use any name, but something descriptive such as dropsid.conf as shown below is helpful for easy future maintenance. To see the various option for selecting rules, open up and read the dropsid-example.conf file or any of the other example files. The rules selection criteria syntax is the same for all of the SID mangagement configuration files. Note that the name of the file is completely arbritrary. The name does not cause the action. You choose which rule selector file will be used for what purpose down below when you assign a file to an interface. With that said, it is still a good idea to name your SID management configuration files so that the name reflects which modify action you intend to use.

After creating a SID management list, you must then assign the list to one or more Snort interfaces. You do this at the bottom of the page in the SID Mangement List Interface Assignments section. In the example below, our just created dropsid.conf file is assigned to the WAN interface by choosing it in the drop-down selector for Drop SID List.

You can create and assign other SID management lists in the same manner. If an interface's blocking mode is configured such that a particular SID action change is not applicable, then "N/A" will be shown under the appropriate selector column. In the example above the LAN is configured for Legacy Blocking Mode and thus a Drop SID or Reject SID list can't be used and so the corresponding drop-downs are hidden.

The Rebuild checkbox, when checked, will cause an immediate recalculation/rebuild of the active rules for that interface using the current SID management settings. The changes will be written to the snort.conf and snort.rules files for the interface and then the interface is signaled to reload the configuration.

Force Rule Actions Using Icons on the RULES Tab:
You can also change rule actions from the default ALERT to either DROP or REJECT by clicking on the icon in the Action column on the RULES tab. For example, assume that for the rules in the OpenAppID category of Social Networking Rules I want to change rule SID 70101 for "facebook_apps" from ALERT to DROP. First, choose the appropriate rule category from Category Selection drop-down. Next click on the Alert icon under the Action column for the rule you want to change as highlighted below.

When you click the icon, the Rule Action Selection dialog will appear. Choose the new rule action and click Save. In the example below we are changing the rule action to DROP. Click Cancel to abandon any change. Choosing DEFAULT in this dialog will restore the original default action the rule had from the vendor (this is almost always going to be ALERT).

When you click Save, the dialog will close and you will be returned to the RULES tab. At the top a message is displayed, as shown below, telling you of the rule action change and that you must hit Apply to actually make the change to any running Snort process. Notice, too, that the action for SID 70101 is now showing as DROP (the red thumbs-down icon).

Changing Rule Actions on the ALERTS Tab:
You can also change rule actions directly on the ALERTS tab. On the event row for the rule you wish to change, click the pencil-on-pad icon under the GID:SID column. The icon is highlighted in the image below.

Clicking the icon will open the same Editor Dialog for Rule Action Selection as shown previously for the RULES tab. You can change the rule's action by choosing a new value.

Viewing and Searching for Alert, Drop or Reject Actions on the ALERTS Tab:
On the ALERTS tab the various rule event actions (ALERT, DROP or REJECT) are indicated by the icon in the new Action column. See the example below. The red thumbs-down icon indicates a DROP action rule. The yellow exclamation point triangle indicates an ALERT rule. Events with a REJECT action will be shown with the yellow hand icon (see farther down below).

You can filter the view of events using the Alert Log View Filter section. Click the plus sign ('+') as marked in the screenshot below.

This will open the section where you can specify values in certain filter fields as shown below. In the example shown we are going to filter the events view based on rule action.

Click the Action drop-down selector and choose an action, the click the Filter button. In the example below only Reject actions will be shown because we filtered for "Action = Reject".

The list of rule events will then be filtered such that only events resulting from rules with the REJECT action are shown. See the example below.

NollipfSense

When will Snort 4.0 roll our? Is cxbge the family tree for bge interface?

bmeeks

@NollipfSense said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

When will Snort 4.0 roll our?

Snort 4 is already available for pfSense-2.5 and plans are for it to stay there, meaning that it will only be available with pfSense 2.5 both now in DEVEL and later when it goes RELEASE. There are currently no plans to release Snort 4.0 for pfSense 2.4.4.

@NollipfSense said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

Is cxbge the family tree for bge interface?

No, I do not believe they are the same family.

crazybrain

Hi, I have an Atom 3558 processor with Intel X553 nics (aka ix). Do you know if these nics will be supported with Inline IPS Mode given they're the same nics on Netgate devices.

bmeeks

@crazybrain said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

Hi, I have an Atom 3558 processor with Intel X553 nics (aka ix). Do you know if these nics will be supported with Inline IPS Mode given they're the same nics on Netgate devices.

Only if the FreeBSD developer for that NIC driver family makes it netmap compatible. The pfSense guys take whatever comes down from FreeBSD when it comes to drivers. To my knowledge they do not write any of their own drivers (nor do they modify any).

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.

Intel NICs for the em and igb family are quite cheap. If you want inline IPS mode, consider swapping your NIC to one of those.

jasonsansone

"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."

Do you know if vmx will be supported? Many of us use pfSense inside of ESXi.

bmeeks

@jasonsansone said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

"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."

Do you know if vmx will be supported? Many of us use pfSense inside of ESXi.

I believe the vmxnet3 driver will work with Inline IPS mode. If you have issues, you could always change the virtual machine VMX file to use the e1000 driver instead (which will force em driver operation).

jasonsansone

@bmeeks Thank you. I haven't tested 2.5 yet so I don't know, but I wanted to ask before I got there.

MikeV7896

Just trying to figure out the policy and rule action bits. I'm using Snort Subscriber rules and OpenAppID. To make sure I'm understanding correctly... the IPS Policy settings only apply to the Snort Subscriber rules, which I've already been using anyway. But to use Inline mode, I'd need to force rule actions on the OpenAppID rules, either through SID Management, the Rules tab, or changing actions based on alerts, correct?

Manually managing rules and actions can be a pain over time, as new rules are created for new things... would it be possible to have a default that applies to all rules in a category? Like for example, "openappid-hacktools.rules"... pretty sure I'd not want those ever... but if a new rule is created for a new tool a month from now, I'd have to manually add that SID to be dropped, correct? Unless I keep up on these rules on a regular basis, things could start getting through since they'd only be alerting instead of dropping.

I'm not running 2.5 yet (will likely wait for release, whenever that comes to be), but just want to make sure I know what I'm doing when the time comes!

bmeeks

@virgiliomi said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

Just trying to figure out the policy and rule action bits. I'm using Snort Subscriber rules and OpenAppID. To make sure I'm understanding correctly... the IPS Policy settings only apply to the Snort Subscriber rules, which I've already been using anyway. But to use Inline mode, I'd need to force rule actions on the OpenAppID rules, either through SID Management, the Rules tab, or changing actions based on alerts, correct?

Manually managing rules and actions can be a pain over time, as new rules are created for new things... would it be possible to have a default that applies to all rules in a category? Like for example, "openappid-hacktools.rules"... pretty sure I'd not want those ever... but if a new rule is created for a new tool a month from now, I'd have to manually add that SID to be dropped, correct? Unless I keep up on these rules on a regular basis, things could start getting through since they'd only be alerting instead of dropping.

I'm not running 2.5 yet (will likely wait for release, whenever that comes to be), but just want to make sure I know what I'm doing when the time comes!

Correct. There is no IPS Policy metadata encoded into the OpenAppID rules. The OpenAppID rules were written by an independent third-party volunteer contributor, and the tarball file is currently hosted by the pfSense team on their infrastructure.

Just to be sure everyone understands, there are two parts of OpenAppID. There is the internal plumbing provided by the Snort development team (actually Cisco/Talos). Those plumbing parts are called the OpenAppID stubs. They are required for OpenAppID detection to work, but installing just those would mean nothing: no alerts on OpenAppID stuff. In order to get alerts or drops, you must have text rules that make use of the appid keyword that the OpenAppID stubs provide. These text rules are what the third-party volunteer contributor provided for pfSense users. You can also write your own OpenAppID text rules. You can put them in the Custom Rules category.

So back to your original question. You will need to manually manage your OpenAppID rules, but you can use SID MGMT features for that. Back when he created them, I asked the OpenAppID rule author to divide his rules into categories much like the other Snort and Emerging Threats rules are divided. He did that, and that's why you see categories of OpenAppID rules on the CATEGORIES tab when OpenAppID is enabled. You can use SID MGMT to control those rule categories by, for example, changing a category to DROP (if using Inline IPS Mode) or enabling or disabling an entire category by putting the category name in the appropriate SID MGMT conf file. In that case, if filtering by say category name, any rule change within that specific category would be covered (for instance, if a new rule were added). However, if an entire new category were added, then you would need to take manual action by going to the SID MGMT tab and creating a new filter or editing an existing one to match the new category..

Of course there is always the option of managing rules individually on the RULES tab or by using the icons provided on the ALERTS tab.

Effectively managing an IDS/IPS requires fairly constant vigilance by the admin. And you would need to keep abreast of the latest rules updates. The Snort team summarizes each Snort Subscriber Rules update on their blog here: https://blog.snort.org/.

Simbad

Hi!

Can you please add options to "Drop All" ?

bmeeks

@Simbad said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

Hi!

Can you please add options to "Drop All" ?

What do you mean by "Drop All"? If you mean change all rules to DROP, that is not a good policy in my view and basically defeats the whole purpose of having selectivity between ALERT rules and DROP rules. For large numbers of rule action changes, I suggest you use the SID MGMT tab and the rule selection filtering/matching features available there.

Simbad

Thanks for the answer, ... I already have my policy of rules that meets and effectively protects the network. With such a policy, I successfully protect the network and follow the rule: block everything except what I allow.

With this feature, it would be easier to maintain the network / rules in the new function.

bmeeks

@Simbad: my reply was really a question back to you. How would you use a "Drop All" option if available, and where should the option be shown (on what tab)?

The point I was making with my question is that I don't see the utility of a feature that sets all rules to DROP because that is not usually a good course of action in my view. The whole point of having ALERT versus DROP versus REJECT rule options with Inline IPS Mode is that it gives the security admin a mechanism to improve connectivity while still gaining insight into questionable or suspicious activity. If every rule was DROP, then you are back to the way Legacy Mode works where every alert is a block (the functional equivalent of DROP). You would want some rules to just ALERT so you could check the unusual condition, and then decide if it was truly malicious and warranted a DROP, or if it was just a false positive. Having a good mix of ALERT and DROP improves connectivity for clients and still gives the security admin insight into the traffic types on his network.

I think a lot of pfSense users of the IDS/IPS packages (both Snort and Suricata) fail to appreciate the true role of an IDS/IPS (especially an IPS with blocking capability). They seem to think every rule that triggers represents some banking malware trojan and needs to trigger a block that persists forever (yes, I'm exaggerating a little bit, but my general point is valid). That is definitely not the case. Many of the rules are actually designed more as a "hey, check this out" sort of rule because many times the traffic that triggers the rule is benign in most environments. A perfect example is one of the ET-Policy rules. It alerts (and would block if set to DROP or using Legacy Mode Blocking) anytime it sees a traffic stream containing an EXE file. Well, that will kill most any Microsoft Security Hotfix or Service Pack download if that rule is set to DROP. Do you really want that? You would only want that if you were a corporation that ran a Microsoft shop (Active Directory and all), and you had your own internal WSUS infrastructure where you wanted users to only get updates from there.

That's not the case for the vast majority of pfSense users. So giving them an upfront in-your-face option to set all rules to DROP would just give them an easy way to bring their entire network to its knees ... . Then they would be posting here complaining about all the various apps and services that are not working on their network after they installed Suricata or Snort. The key takeaway in my opinion is that IDS/IPS rules are not like anti-virus signatures. With an AV client, you can be near 100% sure that any virus signature that triggers represents a bad thing so you want the code blocked or quarantined. That's not the case with IDS/IPS rules. A given rule is not necessarily detecting something evil, so having it always block or drop may be just irritating instead of improving security.

So bottom line is I am going to need a lot of "convincing" to persuade me to add a feature like that. I see it causing more issues rather than solving problems.

MikeV7896

@bmeeks said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

I think a lot of pfSense users of the IDS/IPS packages (both Snort and Suricata) fail to appreciate the true role of an IDS/IPS (especially an IPS with blocking capability). They seem to think every rule that triggers represents some banking malware trojan and needs to trigger a block that persists forever (yes, I'm exaggerating a little bit, but my general point is valid). That is definitely not the case. Many of the rules are actually designed more as a "hey, check this out" sort of rule because many times the traffic that triggers the rule is benign in most environments. A perfect example is one of the ET-Policy rules. It alerts (and would block if set to DROP or using Legacy Mode Blocking) anytime it sees a traffic stream containing an EXE file. Well, that will kill most any Microsoft Security Hotfix or Service Pack download if that rule is set to DROP. Do you really want that? You would only want that if you were a corporation that ran a Microsoft shop (Active Directory and all), and you had your own internal WSUS infrastructure where you wanted users to only get updates from there.

So... while I agree with you on this regarding general IDS/IPS rules, like the regular Snort and ET rules, things like OpenAppID rules are more likely to want a whole category blocked, not unlike a web filter that can block entire categories of websites with just a click. I have no interest in any "hacktools" being allowed to access the internet so I'm happy to block that whole category. Same with "p2p_file_sharing".

My concern is that I will have to go into each individual rule for 30+ rules in multiple categories to change their actions all to Block. Yeah, I'll only need to do it once (after that first time, it's just maintenance, which will probably be just one or two rules at a time), but that's still a time-consuming task. Having the ability to mass-change all rules in a category would make this much easier.

As a possible compromise to one setting that changes all rules in a category... how about allowing changing the action directly from the list of rules? Rather than clicking the Action icon and selecting an action in a dialog, put a drop-down right on the main list instead. At least then I could keyboard the changes (tab, down, down, tab, down, down, etc.) instead of having to click on different things. Plus, then you can eliminate the need for those additional legend icons, since the element would clearly indicate the action.

bmeeks

It's been a while since I've looked (I don't use the OpenAppID rules in my setup), but I thought the OpenAppID rules are divided into categories with each category having its own filename. So you could use SID MGMT to modify an entire category of OpenAppID rules the same as you would for an Emerging Threats or Snort Subscriber category.

Creating a "Drop All" button would be easy in terms of coding, but I really think it would just lead folks into shooting themselves in the foot. I could perhaps create a category "Drop All" button to match the current "Enable All" and "Disable All" buttons. Is that what you meant by "Drop All"? I initially thought you meant a button to change all rules in all categories to DROP. Based on your lastest reply, maybe I misunderstood your original request.

I will look into a multiple select feature on the RULES tab, but coding something like that is not as straightforward as it may seem at first glance.

Finally, I will add that using the SID MGMT feature is much more efficient in terms of configuration storage space. When you make a change to a rule's action or state on the RULES tab (or the ALERTS tab), the specific GID:SID of that rule is stored in a long string of values separated by the pipe symbol ( | ) in the config.xml file. As originally envisioned where the user made changes to maybe several dozen rules, that method is fine. But if we start talking about folks wanting changes to several thousand rules, that begins to take up a lot of space in the config.xml file. So consider that you want to set the category openappid-social-media rules to all DROP. For this example, assume there are 100 rules in there. Changing each one to DROP on the RULES tab would create a pretty large string in config.xml because you have the GID:SID value of each rule along with the pipe separator/delimiter. Using SID MGMT, on the other hand, would require just this single line in the dropsid.conf file:

openappid-social-media

That's a lot more efficient in terms of storage space within config.xml.

I keep pushing the SID MGMT tab because that is a really efficient way to manage rules. You really shoud make all rules changes there instead of using the buttons/icons on the RULES or ALERTS tabs. And if you were running Snort on any other platform besides pfSense (which is the only platform out there that has a GUI for managing Snort), you would have to use SID managment conf files in a command-line tool such as PulledPork to manage your rules (or else manually edit the text rule files). I really intended for the icons on the RULES tab to be used for a tiny handful of one-off quickie rule modifications to state or action, and the SID MGMT tab to be used for changes to large groups of rules (say more than five per category).

MikeV7896

I guess I've never used SID MGMT, so I suppose what you're saying is possible, since you're the one that made the package.

I tend to be more GUI-oriented, so clicking buttons and whatnot is more intuitive to me than a bunch of different config files. If it's really that easy to just add a line to a config file in SID MGMT to have all rules in a category have a drop action, I'd be happy with that then.

bmeeks

@virgiliomi said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

I guess I've never used SID MGMT, so I suppose what you're saying is possible, since you're the one that made the package.

I tend to be more GUI-oriented, so clicking buttons and whatnot is more intuitive to me than a bunch of different config files. If it's really that easy to just add a line to a config file in SID MGMT to have all rules in a category have a drop action, I'd be happy with that then.

It is that easy. Just create a file named dropsid.conf (or any name, the name does not matter). Then add the category names (visible on the CATEGORIES tab) or individual GID:SID rule ID pairs. Then save the new file. At the bottom of the tab, assign the list you just created to the DROPSID drop-down. Click the checkbox over on the far left (the "Rebuild" box) to force the creation of a new rules file for that interface and have Snort be sent a "reload rules" command. Open up the sample lists on the SID MGMT tab to see examples of the various selector syntax you can use to choose rules for modification. You can change rule state, action and even content using features on that tab.

rebytr

For Snort Inline IPS, are the same config settings needed for netmap like in the Suricata post here? (https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces)

bmeeks

@rebytr said in Snort Package 4.0 -- Inline IPS Mode Introduction and Configuration Instructions:

For Snort Inline IPS, are the same config settings needed for netmap like in the Suricata post here? (https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces)

Likely "yes". Snort simply opens the netmap device and then depends on the kernel settings for any additional configuration options. That's the same way Suricata works. So those tuning parameters outlined in the post you linked may prove helpful depending on the specific NIC hardware you have.