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

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

pfcode

If only 2 or 3 rules in a category need to be ALERTed, the rest need to be DROP, what will be the easiest way to set up?

bmeeks

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

If only 2 or 3 rules in a category need to be ALERTed, the rest need to be DROP, what will be the easiest way to set up?

Use SID MGMT features to set the category to DROP. Then go to the RULES tab, select that category in the drop-down selector and find the 2 or 3 rules you want to be ALERT and change the action of just those rules using the icon under the ACTION column. Changes you make to individual rules on the RULES tab take precedence over all other modifications. Those are the last changes applied to rules.

pfcode

@bmeeks Thank you.

murzik

This post is deleted!

tbr45

@bmeeks Is it also possible to mark packets with the new Inline IPS Mode? This would allow the Traffic Shaper to apply rules based on the hostname, for example.

bmeeks

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

@bmeeks Is it also possible to mark packets with the new Inline IPS Mode? This would allow the Traffic Shaper to apply rules based on the hostname, for example.

No, you can't mark packets. The binary can only pass them, reject them or drop them. A reject sends a notice back to the sender so it will not keep trying. A drop sends back nothing to the sender (the packet just appears to have fallen into a blackhole).

murzik

I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)

Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...

bmeeks

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

I am experiencing very strange behavior . Manged to track it down to one of emerging-scan.rules.
alert tcp $HOME_NET any -> any 445 (msg:"ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection"; flags: S,12; threshold: type both, track by_src, count 70 , seconds 60; metadata: former_category SCAN; reference:url,doc.emergingthreats.net/2001569; classtype:misc-activity; sid:2001569; rev:14; metadata:created_at 2010_07_30, updated_at 2017_05_11;)

Rule was set by Automatic SID managed to DROP, however no alert appeared in Alert List. But until I changed action for the rule from DROP to Alert, I could not get access to remote SMB share...

The only possibility I can imagine that would cause a DROP action to not appear on the ALERTS tab (highlighted in RED to indicate a drop) is if the alert line from the log did not parse correctly. The code on the ALERTS tab reads the alert log for the interface line-by-line and parses each line into a set of fields delimited by commas. If a line does not parse out the correct number of fields, it is discarded and not displayed on the ALERTS tab.

To see if this is the case, get to the command line in pfSense either directly via the console or remotely via SSH. Then change to the correct Snort log interface directory in /var/log/snort. There will be a separate sub-directory under that path for each configured Snort interface. Once in the correct sub-directory, use grep to search the alert file for the rule SID in question to see if it is in there. Post back here with your findings. If the SID is there but is not showing on the ALERTS tab, then it is a parsing issue I need to look into. If you don't see the SID in the alert file for the interface, then that would be a binary issue you would take up with the upstream Snort team.

murzik

@bmeeks
I think that is a binary issue. Alert is not in alert file.
Thanks...