Recommended Snort rules to change from "Alert" to "Block"?

Enso_

Now that I have Snort up and running without any issues, are there any rules you recommend changing from Alert to Block? I’ve noticed that most rules triggered during tests or actual events only generate alerts and don’t block, even though I have the Automatically Block setting enabled. Is there a resource or guideline on which rules should be set to Block, in addition to those that are already blocked by default?

I’m aware this depends on the specific environment, but I’m hoping there are some general guidelines available.

Thank you!

bmeeks

You can't do this in Snort unless you are using the Inline IPS Mode with netmap.

Since you asked the question, I'm assuming you must be using Inline IPS Mode. With Legacy Blocking Mode, all alerts result in "blocks" unless the offending IP is covered by a Pass List entry. With Inline IPS Mode, only rules whose action keyword is changed to DROP will actually block traffic.

For a beginner IPS admin using Snort, I recommend you choose the option on the CATEGORIES tab to use an IPS Policy and set that policy to "Connectivity". That is a good starter policy that will not generate a ton of false positives. It will automatically set some rules to ALERT and others to DROP based on the internal IPS policy metadata coded into each rule by the Snort VRT (vunerability research team).

It is also good practice to first run in IDS-only mode (meaning do not enable blocking on the INTERFACE SETTINS tab) for a few weeks to get a feel for what kind of traffic is flowing on your network and what, if any, false positives might occur. You can tune the rules if necessary during this period by disabling or suppressing particular SIDs (signature IDs) on the ALERTS tab. You also need to regularly check the ALERTS tab during this period to see what's been logged.

Once you feel comfortable with the setup, you can enable blocking and still keep an eye on things by regularly checking the ALERTS tab.

As you enable more rules (such as selecting Emerging Threats rules, for example) or try to move to a more stringent IPS Policy (like "Balanced"), you can expect to see more false positives depending on the particular normal traffic on your network. The "Security" IPS Policy is sure to generate a number of nuisance blocks, so I never recommend it unless you are protecting a network containing the nuclear missle launch codes or something . And never enable the "Max Protect" policy as the Snort VRT explicitly says that one is for extreme testing only. It will most surely nearly cripple regular traffic flow.

Enso_

I'm using Legacy Mode. I checked other pfSense boxes with the same or similar Snort setups, and you’re correct—on those systems, Snort automatically blocks all alerts in Legacy Mode. However, on this one, it doesn’t.

Settings:

Use IPS Policy: **Enabled**
IPS Policy: **Balanced**
“Automatically block hosts that generate a Snort alert”: **Enabled**
Mode: **Legacy Mode**
Pass List: **None**
Alerts: **230**
Blocked: **None (empty)**

I’ve updated the rules and restarted the Snort interface, but the behavior remains the same.

Does anyone know why this particular instance isn’t blocking anything in Legacy Mode, even with the auto block option enabled?

JonathanLee

@Enso_

Did you try this

Block Settings
Block OffendersChecking this option will automatically block hosts that generate a Snort alert. Default is Not Checked.
IPS Mode
Legacy Mode
Select blocking mode operation. Legacy Mode inspects copies of packets while Inline Mode inserts the Snort inspection engine into the network stack between the NIC and the OS. Default is Legacy Mode.
Legacy Mode uses the PCAP engine to generate copies of packets for inspection as they traverse the interface. Some "leakage" of packets will occur before Snort can determine if the traffic matches a rule and should be blocked. Inline mode instead intercepts and inspects packets before they are handed off to the host network stack for further processing. Packets matching DROP rules are simply discarded (dropped) and not passed to the host network stack. No leakage of packets occurs with Inline Mode. WARNING: Inline Mode only works with NIC drivers which properly support Netmap! Supported drivers: bnxt, cc, cxgbe, cxl, em, em, ena, ice, igb, igc, ix, ixgbe, ixl, lem, re, vmx, vtnet. If problems are experienced with Inline Mode, switch to Legacy Mode instead.
Kill StatesChecking this option will kill firewall established states for the blocked IP. Default is checked.
Which IP to Block
BOTH
Select which IP extracted from the packet you wish to block. Default is BOTH.

bmeeks

@Enso_ said in Recommended Snort rules to change from "Alert" to "Block"?:

Does anyone know why this particular instance isn’t blocking anything in Legacy Mode, even with the auto block option enabled?

Are the IP addresses in the alerts part of your internal network? If so, they are automatically added to the internal Pass List so that they are not blocked. External hosts they communicate with (like out on the Internet) should be getting blocked, but internal hosts residing on networks connected to a firewall interface will generate alerts but no blocks. That is by design so you don't get locked out of the firewall.

Is Snort actually running on that interface? Verify by executing this command from a shell prompt either directly on the firewall console or via an SSH session:

ps -ax | grep snort

You should see a running Process ID for each configured Snort instance.

As a test, enable the ET Scan rules on the interface, save the change, then restart Snort.

From a machine on an internal network run nmap and scan the firewall's interface on the internal network as follows:

nmap -sS <IP_of_firewall_interface>

You should see a few alerts, but you won't see a block because the scanning host will be on the automatic Pass List since it resides within an internal protected network. The alerts will prove Snort is operational.