B
@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 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 won't 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
