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

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.

dotlike

@jasonsansone vmxnet3-driver is working without problems in inline mode. i am running this setup since several weeks without problems

dotlike

@bmeeks Thanks a lot for your work. I was missing that feature for a long time.

I have one question regarding the payload dump-option (barnyard-settings).
Is this feature working? I am not getting any dumps for download in the alert-section. Thanks in advance!

BR

bmeeks

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

I have one question regarding the payload dump-option (barnyard-settings).
Is this feature working? I am not getting any dumps for download in the alert-section. Thanks in advance!

BR

I honestly do not know. I have not run Barnyard2 on my personal system for several years. The package is no longer really supported on FreeBSD (and I'm not sure it is supported anywhere anymore). By "supported" I mean updated and maintained. The only updates to the package in FreeBSD Ports have been done by the FreeBSD team themselves and involved only minor tweaks to the Makefile for various ports tree dependency issues. Nothing has been touched in the actual Barnyard2 source code in years. I know that it has issues with more recent versions of MySQL client.

So long lead-in to say Barnyard2 seems to be slowly decaying on the vine. The new direction in the Snort3 branch is JSON logging (much like Suricata has).

As for the current situation in pfSense, you can examine the Barnyard2 configuration file for the interface to see what is set in there. You can find the file in /usr/local/etc/snort/snort_xxxx (where that xxxxx will be a random UUID combined with the physical interface name).