About the New Block-on-Drops Only Option in Suricata 4.0.0

bmeeks

Version 4.0.0 of the Suricata package contains a new option on the INTERFACE SETTINGS tab in the section where blocking is configured. The new option is called Block Drops Only. It applies only to Legacy Blocking Mode operation. If you use the Inline IPS mode for blocking, then this new option is not used and is in fact hidden by the GUI code when Inline IPS mode is enabled.

The new option allows Legacy Blocking Mode users the same flexibility with rule actions as Inline IPS Mode users enjoy. That would be the ability to use the SID MGMT tab options to turn individual rules (or entire rule categories) from ALERT to DROP action. So now with the new option enabled, rules that have the ALERT action keyword (the first word of the rule signature text) will only generate alerts in the log on the ALERTS tab but no blocks. Only rules with the DROP action keyword will generate blocks that show up on the BLOCKS tab. You have to specifically enable this behavior by checking the box to enable this new option on the INTERFACE SETTINGS tab. Then you will need to restart Suricata for the change to take effect. If you leave this new option unchecked, which is the default, then Legacy Mode operation continues to function as it always has whereby every rule firing will generate a block (assuming the IP address of the offender is not in a Pass List configured on the interface).

Bill

dcol

I am a bit unclear about this option in Legacy Mode.
So if Block Drops Only is enabled, the only rules/categories that are blocked are ones specified in the dropsid.conf file. Correct?
Will the drops only appear in the alerts in red like in inline mode, or will they be in the block tab?

dcol

So it appears that when you select Block Drops Only the blocks do appear in red in alerts, but they also appear in the block list. So the results are not just like Inline where nothing appears in the block list.

bmeeks

@dcol:

So it appears that when you select Block Drops Only the blocks do appear in red in alerts, but they also appear in the block list. So the results are not just like Inline where nothing appears in the block list.

This is because Inline IPS Mode operates fundamentally different from Legacy Mode. Go read this thread for details: https://forum.pfsense.org/index.php?topic=135331.0. The BLOCKS tab GUI code simply displays the contents of the snort2c packet filter firewall table. When using Inline IPS Mode, that table is not used so there is nothing for the GUI code to read and display.

Bill

NollipfSense

I am running Suricata 4.0.3.1…How do I determine what mode I have set up? I looked through every tab, and I don't see anything specifying "Legacy Mode" or "Inline mode." Also, I have not enabled blocking yet as I am still learning.

NollipfSense

@NollipfSense:

I am running Suricata 4.0.3.1…How do I determine what mode I have set up? I looked through every tab, and I don't see anything specifying "Legacy Mode" or "Inline mode." Also, I have not enabled blocking yet as I am still learning.

Found it…one has to enable blocking to see it...I am still not ready to enable it.

JasonAU

I'm testing this out on my home system as Legacy Mode is really the only stable option for my APUC4 inline will crash after several days for me

So by switching this on all the rules marked as 'Alert' that previously got blocked will neither block or drop is that correct ? Do I have the ability to drop at all for rules if I wanted to

bmeeks

@JasonAU:

I'm testing this out on my home system as Legacy Mode is really the only stable option for my APUC4 inline will crash after several days for me

So by switching this on all the rules marked as 'Alert' that previously got blocked will neither block or drop is that correct ? Do I have the ability to drop at all for rules if I wanted to

When you enable blocking (Block Offenders = yes) and enable "block-on-drops-only", then Legacy Mode will operate just like Inline IPS mode with respect to rule actions. So rules with ALERT as the action will only alert (no block), and rules with DROP as the action will cause blocks. All the vendor rule packages come with their rule actions set to ALERT. You have to manually alter a rule action to DROP either via the icons on the RULES tab or using the SID MGMT features.

If you run the Snort Subscriber rules with Suricata, then you have another option on the CATEGORIES tab. You can enable an IPS Policy and then make sure the Policy Action selector is set to "Policy". This will use the metadata embedded in the Snort Subscriber rule set to automatically select rules to be enabled and their action will be set to the value specified in the rule policy metadata. Only the Snort Subscriber rule set offers this ability.

Bill

JasonAU

Great tip about the subscriber rules thank you ! I have them but had not noticed this option

bmeeks

@JasonAU:

Great tip about the subscriber rules thank you ! I have them but had not noticed this option

To see what I mean about IPS policy metadata, open a CLI session on the firewall and do the following to find all the rules with IPS policy metadata in them:

Note: pay attention to the quotes and spaces in the command below and duplicate them in the CLI session


cd /usr/local/share/suricata/rules

grep "policy [*-ips]" *.rules

You will see a long list of lines scroll by. You can page through it by piping the output to "more" if desired. Look at the rules that are displayed. If you look carefully at various rules you will see that many rules participate in multiple IPS policies. And there can be different actions for a rule depending on which IPS policy is used. For example, a rule might suggest ALERT for the policy action when the IPS policy is "Connectivity", but DROP when the IPS policy is "Security".

Just taking a quick look at the output of the grep command above will provide valuable insight into what IPS Policy is and how the GUI code uses it. So when you pick an IPS Policy in the GUI, the code searches through the Snort Subscriber rules and finds and enables all the rules that have an IPS Policy metadata tag matching the policy you chose (Connectivity, Balanced, Security or Max Detect). The GUI can also apply the rule action specified for the chosen policy if you use the "Policy" option when choosing the rule action on the CATEGORIES tab when using IPS Policy.

As I mentioned earlier, only the Snort Subscriber rules contain these IPS policy metadata tags. These tags are not present in the Emerging Threat rules and thus you can't use policy to automatically select ET rules.

Bill

Edited January 16, 2019 to correct RULES path for Suricata 4.1.x versions

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?

bmeeks

@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