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

@bmeeks Hi, thanks for a great explanation and for taking the time to answer everyone's questions.

Do they still recommend enabling SNORT on the LAN/VLAN interface? To clarify, you mentioned snort working before the pfSense firewall? Therefore there's no need to enable on the WAN?

Yes, I still suggest putting your Snort (or Suricata) instances inside the firewall perimeter on your LAN and other internal interfaces for most setups. Snort and Suricata receive network packets directly from the NIC driver BEFORE they hit the pf packet filter firewall engine. This is true no matter which interface (WAN or LAN) the IDS/IPS instance runs on. So, when talking about the WAN, there is very little benefit to putting Snort or Suricata there as it will be busy intercepting and analyzing traffic that the next step of packet processing- the pf packet filter- is probably going to drop via a default rule anyway. That would mean burning CPU cycles for zero benefit.

And, nowadays, if we choose to use SID, do we have to include .rules in the SID Auto-Management List Editor when listing the rules?

I don't fully understand this question. You seem to be mixing up two quite different concepts here. SID (Signature ID) is the unique serial number identifier for each rule used by an IDS/IPS. The folks who write rules tend to group them into logically related categories by virtue of including those SIDs in a common *.rules file. As an example, the Emerging-Scan.rules file contains a collection of rule SIDs that work to detect various types of scans. How you choose to use a collection of SIDs or groups of *.rules files is determined by what you want to accomplish. Using SIDs by themselves lets you be more selective than using the rules file category name would be.

Also, could you please discuss Choosing the Networks Snort Should Inspect and Whitelist under the SNORT INTERFACES, WAN or LAN SETTINGS tab? What that does and when and how to configure?

Short answer here is DO NOT touch this or change it from the default unless you fully understand how it works and what it is for.

There is information about HOME_NET and EXTERNAL_NET to be found on Google. Those terms are used in all variations of the Snort and Suricata packages whether used on pfSense or not. The simplest explanation is the HOME_NET variable contains all the interface IP and subnet addresses that you want to protect. EXTERNAL_NET contains everything NOT defined as being part of HOME_NET (usually). This is most commonly done by defining EXTERNAL_NET this way in the configuration file:

where the leading exclamation point is the logical NOT operator.

Getting these two variables properly set up is critical because many of the rules use $HOME_NET and $EXTERNAL_NET as conditionals for determining if a rule should trigger. Examine some of the text of the rules and you will see how those variables are used. If not correctly set up, then rules will not trigger as expected because that network conditional will not match what the rule is written to look for.

@boobletins said in Configuring pfSense/netmap for Suricata Inline IPS mode on em/igb interfaces:

Verify that all hardware offloading is disabled (also note your mtu) by running ifconfig igb0

see https://redmine.pfsense.org/issues/10836

@qinn, it depends totally on which precise rules are enabled and what the traffic on your network actually consists of. The goal in IDS/IPS is to get no or very few alerts and blocks. That means your network is relatively secure and clients are following the rules ... ☺ .

I don't mean that to say you should never get alerts, though. Just that you don't want to be receiving hundreds per hour. Once blocking is enabled that might drive you crazy as an admin. Within the IPS Polices, the Snort team has selected rules that provide security without a ton of false positive alerts.

@cyberzeus said in How Automatic SID Management and User Rule Overrides Work in Snort and Suricata:

bmeeks - I found the following link that describes what is included in each of the 3 IPS policies.  Note there is a 4th policy - MaxDetect.  Do you know if there are any plans to implement this in the Snort package for pfSense?

https://www.snort.org/documents/215

Replying to an old thread, but the answer is "yes". The new MaxDetect policy is now present and selectable in the Snort and Suricata packages. Just remember that the Snort folks recommend enabling that only for testing purposes! It is most definitely not recommended for a production network. It will generate a lot of false positives!

For those looking to create their own rules, the "sid:1000006;" part of the example is NOT a reference to an existing SID. It needs to be a unique number otherwise Suricata won't load the rule.

To whitelist for a rule for an IP, search for the SID in /usr/local/etc/suricata/suricata_(interface)/rules/suricata.rules. Duplicate the conditions like "flow:from_server,established; content:"403"; http_stat_code;" into the custom rule so it matches, like

Otherwise with only the IP address, port, and unique SID it will allow all traffic for that IP.

Also note the directional (<-) only allows for two directions..."both" or "left."

@JasonAU:

You put a lot of effort into this forum & Pfsense thank you! Seriously a lot of people would be lost without somebody doing the answering on the forum

I’m having a lot of fun toying with this after work in my lab the only thing that I don’t currently understand is can I make some rules drop rather than block when I’m configured with:

*Legacy mode not inline

*Block on DROP only enabled

*IPS Policy Security with ‘policy’ mode

Snort Subscriber + ET

Let’s say I like one of the rules FILE tracking GIF (1x1 pixel) from the files.rules category sounds like a good thing to help with privacy but the blocking action causes problems as often the IP that gets blocked is hosting other legitimate images in the page, Can I use SID Management to modify this rule to drop even when I have block on drop enabled?

Your question leads me to believe you are misunderstanding a key piece of the puzzle.  There is no difference between DROP and BLOCK in Legacy Mode.  They are the same thing.  Both lead to the exact same result:  traffic from the offending IP address (the one that triggered the rule) is blocked by placing the SRC, DST or BOTH IP addresses from the offending packet into the snort2c pf firewall table.  After that, all further traffic from those IP addresses is blocked until the IP addresses are removed from the snort2c table.  Legacy Mode can't do what you want.

The whole reason I created the new "Block-on-drops-only" option was so you can tailor rules actions to get the results you desire.  See, all rules by default from the rule set vendors come with the action set to ALERT.  With Legacy Mode Blocking, and before the new "Block-on-drops-only" option was added, any alert also generated a corresponding block.  It was an all or nothing arrangement.  When you enabled blocking, any rule that generated an alert would also cause a block.  With the new "Block-on-drops-only" option, I added some extra intelligence within the custom blocking module so that it could look at the rule action (ALERT or DROP) of the triggered rule and take the action specified.  So if the rule says ALERT, then only an alert is generated but no block is created.  If the rule says DROP, then both an alert and a block are generated.

SID MGMT has options that allow you to alter rule actions from the default value of ALERT.  So now you can pick and choose which rules you want to just alert and which you want to drop (or block traffic).  This new "Block-on-drops-only" option was born out of the way the Inline IPS mode operates.  With Inline IPS Mode, you must specifically change rule actions to DROP in order to drop or block traffic.  You could also leave some rules with the default ALERT action and those rules would generate alerts but would not block or drop traffic.  That's the way most commercial proprietary Intrusion Prevention Systems operate.  So I thought it would be useful to port that same functionality (the choice of ALERT or DROP) over to Legacy Mode operation.  Hence the new "Block-on-drops-only" option.

I still don't want folks to confuse Legacy Mode's use of DROP with the way IPS Mode works, though.  In Legacy Mode, even though I'm using the term "drop", the actual blocking of traffic is done the old way using libpcap to get copies of every packet traversing the interface, and when a rule fires to create a block, the IP addresses from the offending packet are copied to the snort2c table in pf to implement a firewall block.  So when I say "drop" in the context of Legacy Mode and the new "Block-on-drops-only" option, I really mean that only rules with DROP as the action will add the offender's IP address to the snort2c table.  The "drop" is really still the old fashioned block.  With Inline IPS Mode, the snort2c table is not used at all.  There is another Sticky Post here on the forum that describes the difference between Legacy Mode and Inline IPS Mode.

Read both of the Sticky Posts in this forum about Passlists and Suricata.  Each of them also contains some key points about blocks, drops and Legacy vs Inline IPS modes.

Bill

@bmeeks said in Using Snort VRT Rules With Suricata and Keeping Them Updated:

@MxcZXAKM said in Using Snort VRT Rules With Suricata and Keeping Them Updated:

@bmeeks So is this the best release to reference for now?

snortrules-snapshot-29160.tar.gz

Yes. You want to use the most current version of the Snort 2.9.x rules with Suricata. Since Snort 2.9.16 is the current release, then the snortrules-snapshot-29160.tar.gz rules archive contains the latest ones.

Very helpful, Thank you!