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

bmeeks

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

@bmeeks That makes sense,
I host a small site and a few apps with pfblocker for geofencing.
Would it still be a good idea to disable the ips on the wan with those services running?

To answer that question, trace a network packet from the Internet to your internal web server. Doesn't that packet have to traverse your DMZ interface (assuming the web server is on a DMZ subnet)? If configured on your DMZ interface, Snort will be seeing all traffic coming from and going to your web server from any other firewall interface (including the WAN). So it can offer exactly the same protection to the web server on the DMZ as it would offer if Snort were running on the WAN.

Now consider the potential issues/irritations if Snort is running on the WAN. I assume you are using NAT and port forwarding to reach your internal web server in the DMZ. If not, then skip the rest of this paragraph. That means all the alerts you see on your WAN have the firewall's public IP in them. So how do you determine if you have an infected internal host and which one it is? To do that you would likely want to run the same Snort setup on your internal interfaces. Now you have duplicate or triplicate Snort instances just chewing up RAM and CPU cycles for what real benfit?

Why not just put the IDS/IPS close to the hosts it is actually protecting? The IDS/IPS is for your internal network. It is not to protect your firewall. Right? If your firewall needs protection, then you would want to find you another firewall ... . And when on the WAN interface, Snort is just going to see and alert on all the Internet "noise" traffic that the firewall is not going to pass anway. So why bog down your CPU logging crap that your firewall is not going to pass anyway?

So my answer is run Snort on your DMZ and maybe your LAN, but you likely don't want or need the same rules in both places. Select and enable rules to protect from the actual threats you face on that interface based on the services provided behind it. If you don't have a DNS server on the DMZ, then you don't need any DNS rules taking up CPU cycles and chewing up RAM. If you don't have a mail server running, then you don't need any of the SMTP server rules enabled. Being smart about the rules you select and enable and choosing those rules by the actual attack surface behind the interface lets you be efficient with the resource consumption of the IDS/IPS.

I am trying to sort out another issue with port mirroring for Security Onion as I keep getting zeek/bro notices telling me there is packet loss over the pfsense port mirror.

In your experience, how is the port mirroring performance in pfsense compared to Cisco's port span?

Thanks again, it's good talking to a master!

Port-mirroring is a hardware-intensive task. And when you have very high speed network ports it can get overwhelming for any switch very quickly. How exactly do you have port mirroring configured? What brand of switch are you using?

chromefinch

@bmeeks I'm totally blown away, that makes perfect sense! Excellent example.

Thank you! Again!

Currently I am using pfsense to mirror my vlans, which run over a 3GB lagg. The mirror port is a 10GB nic which is direct/copper attach to my seconion box.
I monitor pfsense cpu usage closely with either the dashboard or pftop and it never seems overwhelmed.

pfsense specs: i3 4170 with 16gb ram.
switch: Cisco WS-C4948E-S

breaking out ports to get inline working will complicate my port mirroring. That should be fun!!

bmeeks

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

@bmeeks I'm totally blown away, that makes perfect sense! Excellent example.

Thank you! Again!

Currently I am using pfsense to mirror my vlans, which run over a 3GB lagg. The mirror port is a 10GB nic which is direct/copper attach to my seconion box.
I monitor pfsense cpu usage closely with either the dashboard or pftop and it never seems overwhelmed.

pfsense specs: i3 4170 with 16gb ram.
switch: Cisco WS-C4948E-S

breaking out ports to get inline working will complicate my port mirroring. That should be fun!!

I suspect you would get much better performance letting your Cisco switching fabric (which is pure hardware for the most part) do the mirroring (called a SPAN port in Cisco speak).

If SecurityOnion says you are dropping packets, then it would follow that the dashboard and pftop and not providing all the relevant data. Or else SecurityOnion is mistaken ... .

chromefinch

@bmeeks Yep, well...

That seems to have done it.
Stayed up to 3am Sat re-configuring the network, swapping the hypervisor's nics around, and replacing the router. I now have the span port on the switch instead of the pfSense box and while Seconion was up, it didn't have any packet loss, but now it's being crash-happy so I've re-imaged it.

Also, inline mode appears to be working on my dmz vlan, so that's a bonus.

We'll see how long this config lasts.

Thanks for your help, the guys at the office suggested it my be the span but I suppose I didn't want to believe them.

edit: Looks like the "CaptureLoss::Too_Much_Loss" is back, but inline mode is still holding strong!

new config for posterity:
So the lacp LAGG's gone, dual intel nic for wan (Intel 82576), single intel 10gb for lan (X520-DA1), same i3 4170 and now 8gb of ram. Cisco WS-C4948E-S now performing the port span to security onion.

brezlord

Hi all, I'm using a Chelsio T520-CR in a lagg0 with LACP and I get the following error when trying to select inline mode on one of the vlans;

The following input errors were detected:

The 'opt3' interface do not support Inline Mode.

The Chelsio does support netmap via the cxgbe driver. https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 any ideas what I might be doing wrong. Running 2.4.5-RELEASE-p1

Thanks

bmeeks

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

Hi all, I'm using a Chelsio T520-CR in a lagg0 with LACP and I get the following error when trying to select inline mode on one of the vlans;

The following input errors were detected:
The 'opt3' interface do not support Inline Mode.
The Chelsio does support netmap via the cxgbe driver. https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 any ideas what I might be doing wrong. Running 2.4.5-RELEASE-p1

Thanks

The cxgbe driver is included in the "acceptable" list recently added to the package code. Are you sure that your specific NIC is actually using that specific driver?

Additionally, LAGG interfaces have a special psudeo-interface driver that runs on top of the physical NIC driver, and that driver is still not, so far as I know, compatible with the netmap kernel device.

brezlord

Thanks. The NIC is using clx driver that come under the cxgbe(4) family. I thought that the issue might have been the lagg.

Thanks for the info.

bmeeks

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

Thanks. The NIC is using clx driver that come under the cxgbe(4) family. I thought that the issue might have been the lagg.

Thanks for the info.

The idea behind netmap is great, but unfortunately the implementation has not lived up to the promise. And by that I mean so many other parts of the kernel network stack don't work with the netmap device. That makes it difficult when trying to create a high-speed IPS engine for FreeBSD-derived firewall distros. Things like LAGG, VLANs and other psuedo drivers just don't work well - and some don't work at all.

wolfsden3

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

Then click the ADD button to

BTW...for those of you wanting to easily import something the exported file I have looks like this in plain text named "whatever.conf".

#Drop Rules
openappid-ads
snort_attack-responses
emerging-attack_response
snort_backdoor
emerging-botcc.portgrouped
emerging-botcc
snort_exploit-kit
emerging-ciarmy

...and so forth. You can get your list literally from the categories list from your interface.

You still have to go into all your individual IPS categories and "enable all". Lame!

I want to enable all + block all. The block all is here but not the enable all to be blocked.

Also, you have to still go and select the dumb rules with the tickbox. So putting them in that list doesn't tick them and enable them. Too much clicking here people! :)

bmeeks

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

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

Then click the ADD button to

BTW...for those of you wanting to easily import something the exported file I have looks like this in plain text named "whatever.conf".

#Drop Rules
openappid-ads
snort_attack-responses
emerging-attack_response
snort_backdoor
emerging-botcc.portgrouped
emerging-botcc
snort_exploit-kit
emerging-ciarmy

...and so forth. You can get your list literally from the categories list from your interface.

You still have to go into all your individual IPS categories and "enable all". Lame!

I want to enable all + block all. The block all is here but not the enable all to be blocked.

Also, you have to still go and select the dumb rules with the tickbox. So putting them in that list doesn't tick them and enable them. Too much clicking here people! :)

Do you know you can combine an enablesid.conf file with your dropsid.conf file? On the SID MGMT tab create an "enable" file and put the category names in there same as you are doing for the "drop" file. Assign that file in the Enable drop-down for the interface. That will eliminate you having to click categories on the CATEGORIES tab.

Too much clicking here people! :)

You simply need to learn how to use the tool ... .

Finally, enabling all rules and all categories is not a good move. You waste CPU cycles and RAM doing that, not to mention increasing your odds of getting a lot of false positives. You only need to enable categories that protect from threats that you are actually vulnerable to. My favorite three examples are these (but there are many others): (1) if you don't have a public-facing web server, then you don't need to enable any web server rules as they are pointless without an exposed web server to be attacked; (2) if you don't run a public DNS server, then you certainly do not need the DNS server rules; and (3) if you don't run a public-facing mail server behind your firewall, then you certainly do not need any of the SMTP, IMAP or POP3 server rules.

You generally do not want to "enable all" the rules in a given category either. They are default-disabled for a good reason! Mostly it's due to frequent false positive triggering, or the rule author considers that rule for very specific circumstances and does not suggest it for widespread use. Research default-disabled rules before you just willy-nilly do an "enable all" on a category. Failure to do that can result in you shooting your foot off.

tman222

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

Thanks. The NIC is using clx driver that come under the cxgbe(4) family. I thought that the issue might have been the lagg.

Thanks for the info.

@brezlord - just a quick info for future reference, if you are looking to use native netmap support on the Chelsio cards, you'll have to enable the vxcl interfaces - more details here (check out post 23 and forward):

https://forum.netgate.com/topic/156861/upcoming-snort-package-updates-for-pfsense-2-4-5-and-pfsense-2-5-0/23

Hope this helps

promo76

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

The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.

Not if you have open ports and serving websites! Is that correct? You can still take advantage of the Rules that block known bad hosts.

bmeeks

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

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

The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.

Not if you have open ports and serving websites! Is that correct? You can still take advantage of the Rules that block known bad hosts.

I would still put the IDS/IPS on the internal interface closest to those hosts. For example, the DMZ, since external-facing hosts should be isolated on a DMZ of some sort. On the WAN the IDS will see and trigger on a lot of stuff that the firewall is not going to pass. Folks a lot of times forget that the IDS sees network traffic from the Internet "raw" directly off the NIC before the firewall has taken any action. So attempts to access closed ports, for example, will still trigger. But if the port is closed, the firewall is going to block the traffic anyway.

If you want the IDS on the WAN, have at it. I'm just saying that some disadvantages come from that configuration, and IMHO those disadvantages outweigh the advantages the majority of the time.

promo76

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

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

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

The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.

Not if you have open ports and serving websites! Is that correct? You can still take advantage of the Rules that block known bad hosts.

I would still put the IDS/IPS on the internal interface closest to those hosts. For example, the DMZ, since external-facing hosts should be isolated on a DMZ of some sort. On the WAN the IDS will see and trigger on a lot of stuff that the firewall is not going to pass. Folks a lot of times forget that the IDS sees network traffic from the Internet "raw" directly off the NIC before the firewall has taken any action. So attempts to access closed ports, for example, will still trigger. But if the port is closed, the firewall is going to block the traffic anyway.

If you want the IDS on the WAN, have at it. I'm just saying that some disadvantages come from that configuration, and IMHO those disadvantages outweigh the advantages the majority of the time.

I see! Thank you for your answer! It sucks that I cannot enable Inline Mode on my LAN since it is a bridge. It seems SNORT does not support Inline Mode on GRIDGE interfaces. Do you know if Surricata does?

bmeeks

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

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

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

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

The WAN interface on pfSense will, by default, block all unsolicited inbound traffic. So having Snort detecting and blocking something the firewall is likely to block anyway is not beneficial IMHO.

Not if you have open ports and serving websites! Is that correct? You can still take advantage of the Rules that block known bad hosts.

I would still put the IDS/IPS on the internal interface closest to those hosts. For example, the DMZ, since external-facing hosts should be isolated on a DMZ of some sort. On the WAN the IDS will see and trigger on a lot of stuff that the firewall is not going to pass. Folks a lot of times forget that the IDS sees network traffic from the Internt "raw" directly off the NIC before the firewall has taken any action. So attempts to accessed closed ports, for example, will still trigger. But if the port is closed, the firewall is going to block the traffic anyway.

If you want the IDS on the WAN, have at it. I'm just saying that some disadvantages come from that configuration, and IMHO those disadvantages outweigh the advantages the majority of the time.

I see! Thank you for your answer! It sucks that I cannot enable Inline Mode on my LAN since it is a bridge. It seems SNORT does not support Inline Mode on GRIDGE interfaces. Do you know if Surricata does?

No, neither package does that. A bridge setup is really not what they are internally plumbed up for nor expecting.

tsmalmbe

Could this be clarified still a bit.

I choose to use the INLINE mode. I choose NOT to use the "Use IPS Policy" because I don't get any visibility into what is going on. So I need to use the SID management then, This is where it becomes confusing.

I do not understand what enabled/disabled means. Does it mean I enable/disable a category, with the default alert/block rules - or does it mean I enable/disable alerting of all individual rules within that category?

How would I go about if I want to enable a set of categories and make sure that each of the individual rules within those categories that are set to enabled would automatically also create an alert (this would as I see it be equivalent of how LEGACY mode actually works - correct?)?

Does the Enable/DisableSID lists work on categories rather than on SID's? Does Enable(Disable here mean it enables or disables the category/SID itself without considering it's action state? Is Drop SID and Reject SID both working on the action state of a rule/category? What does Modify SID even mean in this context?

Sure, I have read thru this thread a million times I think, still struggling to understand how this works - and therefore still running everything in LEGACY mode.

bmeeks

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

Could this be clarified still a bit.

I choose to use the INLINE mode. I choose NOT to use the "Use IPS Policy" because I don't get any visibility into what is going on. So I need to use the SID management then, This is where it becomes confusing.

I do not understand what enabled/disabled means. Does it mean I enable/disable a category, with the default alert/block rules - or does it mean I enable/disable alerting of all individual rules within that category?

How would I go about if I want to enable a set of categories and make sure that each of the individual rules within those categories that are set to enabled would automatically also create an alert (this would as I see it be equivalent of how LEGACY mode actually works - correct?)?

Does the Enable/DisableSID lists work on categories rather than on SID's? Does Enable(Disable here mean it enables or disables the category/SID itself without considering it's action state? Is Drop SID and Reject SID both working on the action state of a rule/category? What does Modify SID even mean in this context?

Sure, I have read thru this thread a million times I think, still struggling to understand how this works - and therefore still running everything in LEGACY mode.

Okay, prepare for a bit of a long post ... . It will take a little time to tell this story --

On the SID MGMT tab, when you "enable" a category by placing the category's file name on a line in say an enablesid.conf file, it is the same as clicking the checkbox for that category on the CATEGORIES tab. The rules from that selected category will be loaded and parsed. Any rules that are "default enabled" by the category author will stay enabled, and any rules that are "default disabled" by the category author will stay disabled.

Just to be sure I'm clear, when I say "default enabled" or "default disabled", what I mean is that some rules in a category will be commented-out by the rule author/vendor. These rules will have a pound sign ("#") at the beginning of the line to indicate the rule is commented-out and should be not loaded by the IDS/IPS. I point this out because a lot of users have the mistaken impression that all the rules in a category are "active". That is not true. The rule authors/vendors will comment-out some rules in a category for one or more of the following reasons:

the rule is prone to false positives in many environments;
the rule protects against a very old vulnerability that is most likely patched in all of today's software;
the rule is designed to detect a somewhat esoteric or rare threat that the majority of users won't be exposed to; or
the rule may be still in an alpha or beta test phase and not ready for general production use.

So back on topic again --

Putting category names in an enablesid.conf file will tell the IDS/IPS to load the rules from the category "as-is" -- meaning don't load and use any "default disabled" rules (i.e., those rules the author/vendor has left commented-out).

If you want to enable some of those default disabled rules in your environment, then you will need to list those GID:SIDs individually in the enablesid.conf file. This would tell the GUI code that you want these specific GID:SID rules enabled even if they are, by default, commented-out by the rule author/vendor.

The disablesid.conf file works in a similar manner, but in reverse. You would put GID:SID pairs in that file if you wanted to override the default enabled state for the rule as specified by the author/vendor. So putting a GID:SID pair in the disablesid.conf file would in effect "comment-out" the matching rule because it tells the IDS/IPS to not even load that rule.

There is an important parameter at the bottom of the SID MGMT tab in the section that shows each IDS/IPS enabled interface. That parameter is the SID State Order drop-down selector. The two choices in that box determine which SID Management file is executed first and which is executed last when building the rules package. If a GID:SID value is matched by some entry in both files, then the last file processed wins.

For example, suppose I enabled a category called "MyRules" in the enablesid.conf file. Assume also that category contains the rule GID:SID value 1:1234, and that rule is default-enabled. Now, in the disablesid.conf file, assume I also put the GID:SID value 1:1234 on a line in that file. That means that GID:SID 1:1234 will match from both files. It will match in the enablesid.conf file processing because it is a rule that is default enabled in the "MyRules" category. But it will also match in the disablesid.conf file because I explicitly put the GID:SID pair (1:1234) on a line in that file. Therefore, whichever SID Mangement conf file gets processed "last" wins. So if I am not careful in choosing the proper value for the SID State Order drop-down, I might not get the state I want for my 1:1234 rule GID:SID. Usually the best order is to process "Enable, Disable". That way you can selectively disable rules as the last step in SID Management processing. But depending on circumstances, choosing "Disable, Enable" might work better.

The Drop SID List and Reject SID List parameters modify the "action" keyword for a rule. All rules come from the vendors with the action set as ALERT. But you can change that action verb to be DROP, PASS, or REJECT. For pfSense, the only two actions that are editable are DROP and REJECT. But modifying the rule action is only possible in Snort when using Inline IPS Mode operation. And with Suricata, you can only modify the rule's action when using Inline IPS Mode or using the "Block Drops Only" option in Legacy Mode operation. If the current operating mode for the inteface does not support modifying rule actions, these choices will be grayed-out and disabled on the SID MGMT tab.

Lastly, the Modify SID List parameter allows you select rules for modification of the rule signature itself. It allows you to do a sort of "search and replace" operation on the entire contents of the rule signature. Look at the examples given in the modifysid-sample.conf file. The comments in there show a number of ways to use the feature. It's true that you could just use the Modify SID List parameter to make all of the changes we discussed up above, but it would get a little tricky with all the regex. Think of the other lists (enablesid, disablesid, dropsid, and rejectsid) as being specialized and more limited versions of the more generic modifysid list.

tsmalmbe

@bmeeks Excellent post. I did some testing today and this very kuch verifies what I saw.

So, how would diaable SID and suppressing then relate? Suppressing is based on for instamce ip addresses?

What about pressing the red X in the gui for a specific block or snort hit? Is that then equal to disablesid and which comes first when rules are evaluated? Which should be preferred, and what is the philosophocal difference?

If I enable all categories without modifying the actions, is that equal to which of the predefined ”policies”?

bmeeks

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

So, how would diaable SID and suppressing then relate? Suppressing is based on for instamce ip addresses?

Disabling a rule is not the same as suppressing the rule. When a rule is disabled (or when commented-out in the corresponding category file), the rule is not loaded into the IDS/IPS memory space at all. It does not consume any resources, because as far as the IDS/IPS is concerned, that rule does not exist.

When a rule is suppressed, that means the alert (and the corresponding log entry) from the rule when it fires is not created. But the rule is loaded into memory by the IDS/IPS, and the rule consumes resources, and traffic is checked against the rule; but when traffic matches, the rule does not log an alert. But if the action of the rule is DROP or REJECT, that action is taken even if the rule is suppressed. It just is not logged. That can be a bit confusing, but it's just how the IPS binaries work.

What about pressing the red X in the gui for a specific block or snort hit? Is that then equal to disablesid and which comes first when rules are evaluated? Which should be preferred, and what is the philosophocal difference?

Clicking the red X on the ALERTS tab disables the corresponding GID:SID. So that disables the rule. We call this method "user-forced", because the admin purposely clicked a choice indicating that rule should be removed from the current rule set and not be loaded anymore (even after a restart). You can also user-force rule states on the RULES tab. There is a user-forced "enable" option to go along with the user-forced "disable" one.

If I enable all categories without modifying the actions, is that equal to which of the predefined ”policies”?

You are talking apples to oranges here. An IPS Policy is a special construct only available from the Snort Subscriber Rules. When the Snort rule creators make rule signatures, they add a special metadata tag to the signature that links the rule to an IPS policy. Literally inside the text of the rule a tag is created that links the rule to one or more IPS policies. A rule can belong to none, one; or multiple IPS policies. Also, for each policy, there is an associated metadata tag that provides a suggested "action" for the rule in that policy.

So for example, a given GID:SID signature might be assigned the following two IPS policies: IPS-Connectivity and IPS-Balanced. But when the rule is used with the IPS-Connectivity policy the suggested action is ALERT, and when the rule is used with the IPS-Balanced policy (a more restrictive one) the suggested action is DROP. So depending on which IPS Policy you selected on the CATEGORIES tab, the same rule could have two different actions (ALERT or DROP). The beauty of using IPS Policies is that most all of the investigation and legwork is done for you by the rule creators. They decide which rules are included in each policy, and what the suggested action should be for the rule in each policy. When you enable an IPS Policy, the GUI code will automatically determine which rules match that policy and load them. It will also automatically read the suggested action for the policy for each rule and change the rule actions for you.

When creating the final rules file, the Snort package processes things this way:

Load all the enabled categories the user has checked on the CATEGORIES tab.
Load and process any IPS Policy selection, if one is enabled.
Process the assigned SID managment conf files for the interface.
Automatically resolve needed flowbits rules and add them to the rules set.
Lastly, process any user-forced enable or disable GID:SID options (these are rules the user has clicked the "force a state" icon for on either the ALERTS or RULES tabs).

tsmalmbe

Case: If I choose "Policy Security" (which applies to my Snort rules not my ET Open Rules or Snort OPENAPPI Rules) and then add an enablesid that enables all snort_server -rules - is this a cumulative operation in a sense?

(btw, there is a typo at the category page "Snort OPENAPPI Rules" it should be OPENAPPID Rules I think)