@Snailkhan:
It is not possible in pfSense to tie IDS/IPS rules or policies to the pf firewall engine. Thus it is impossible to tie IDS/IPS rules to IP source or destination pairs as evaluated by the firewall engine. That's just not how pfSense is designed. If you need this level of granularity, then pfSense is not the product for you. The best you could do is write your own custom IDS/IPS rules where you customize the Source/Destination fields of each IDS/IPS rule. I seriously doubt you want to get into that level of maintainence.

Snort is an add-on volunteer-maintained package for pfSense. It is not baked into the operating system nor into the design of the firewall. Therefore its capabilities will be nowhere near as flexible as say a customized Cisco hardware/software solution might be.

Later Edit: but compare the price you pay for pfSense and its Snort package to what the Cisco solution costs you 😁. Many times compromises are necessary when taking advantage of the "free" option.

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

is it necessary to have on all interfaces, or just the ones assigned to suricata?

Just the ones assigned to Suricata. But the general consensus these days with the super fast multicore CPUs most users have is that you should just disable all hardware offloading on all interfaces. It was helpful back in the days of Pentiums struggling to achieve line rate packet processing, but today's multicore CPUs generally don't break a sweat until you get to the 10 Gig area. There are several things (including some third-party packages) that can be negatively impacted by hardware offloading.

@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!