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

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.

Enso_

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.

None of the IP addresses whether SRC or DST is being blocked. Speaking of, if I'd enabled to block 'BOTH' in the settings, would that still prevent my internal host IP's from being blocked? I've read some recommend setting it to BOTH and others do not.

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:

Yes, Snort is running and generating alerts. Just not blocking, even though I enabled 'Block Offenders" (Legacy Mode) and "Which IP" = SRC.

ps -ax | grep snort
You should see a running Process ID for each configured Snort instance.

Yes, process is running.

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>

I did do this test, and it generates alerts. However, generating alerts isn't the issue, it is generating 'real' alerts as well.

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.

Any other advice/ideas what could be going on?

The 'Pass List' and 'Suppress' list is empty.

Thanks!

bmeeks

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

None of the IP addresses whether SRC or DST is being blocked. Speaking of, if I'd enabled to block 'BOTH' in the settings, would that still prevent my internal host IP's from being blocked? I've read some recommend setting it to BOTH and others do not.

Post back here the specific addresses. Are they contained within networks directly attached to the firewall? If yes, then those will never be blocked. The Snort package automatically whitelists all IP subnets directly attached to a firewall interface (meaning the network is defined on the interface). In this context, "whitelist" means the internal automatically generated pass list. If you get alerts, but are not seeing blocks, then only two things are possible.

You have enabled the option to automatically clear blocked hosts, and by the time you are cross correlating alerts with blocks the blocks have been automatically cleared by the cron task. That would not be a common occurrence, though.
Both IP addresses in the alerts are covered by the internal automatic pass list (see description above for directly attached networks).

I am also explicitly assuming that anytime you alter the blocking mode (either enabling or disabling it) that you are restarting Snort on the interface. The underlying binary executable that does all the actual work only reads its configuration once during startup. Certain configuration changes made in the GUI after that require a restart of Snort for them to be effective.

The way the code works internally it is impossible for an alert to not result in the offending IP being placed in the snort2c block table UNLESS the offending IP is part of a pass list. There are user-defined pass lists (which you say none exist on your firewall) and an automatic pass list. The automatic pass list contains the subnets of every interface and VLAN defined on the firewall except for the WAN.

SRC, DST, and BOTH refer to the addresses contained within the IP header. These can change depending on the directon of the traffic. Normally you want to select BOTH so that malicious traffic is stopped whether the traffic is flowing from a host in your network out to the bad guy, or from the bad guy to a host within your network.

Enso_

@bmeeks

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

This leads me back to a question regarding a comment you made. If I set 'Which IP to Block" to "both" (on the LAN interface), how does it behave? It wouldn't block an internal IP from communicating with the world, would it?
Would it just block the internal IP from communicating with the specific External IP that was associated with the Alert?
Or, based on what you mentioned, would it not block the internal IP at all if it's part of the network (in our case a VLAN) directly attached to the LAN interface?

bmeeks

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

@bmeeks

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

This leads me back to a question regarding a comment you made. If I set 'Which IP to Block" to "both" (on the LAN interface), how does it behave? It wouldn't block an internal IP from communicating with the world, would it?
Would it just block the internal IP from communicating with the specific External IP that was associated with the Alert?
Or, based on what you mentioned, would it not block the internal IP at all if it's part of the network (in our case a VLAN) directly attached to the LAN interface?

Maybe an example will help you understand the built-in automatic pass list. Suppose I have two internal networks defined as follows:

LAN - 192.168.0.1/24 (firewall LAN interface is 192.168.0.1)
DMZ - 192.168.1.0/24 (firewall DMZ interface is 192.168.1.1)

No IP from either of the two networks defined above would ever be blocked. Both networks would be covered by the automatic pass list. But, if an IP in one of those networks was communicating with an IP that is not within the LAN or DMZ internal networks, then that external IP would be blocked depending on how the SRC, DST, or BOTH setting is configured. See below for further details.

As for the difference between SRC, DST or BOTH, let's look at another example:

A host in your LAN at 192.168.0.5 is communicating with an external host at 64.60.80.5 (just a random IP on the web). That communication could happen in one or both of these directions:

192.168.0.5 --> 64.60.80.5 (in this case 192.168.0.5 is SRC and 64.60.80.5 is DST)
64.60.80.5 --> 192.168.0.5 (in this case 64.60.80.5 is SRC and 192.168.0.5 is DST)

So, in the first example above of your internal host initiating a conversation with 64.60.80.5, if you blocked SRC only then the conversation would be allowed to proceed since the SRC IP is covered by the automatic pass list of internal networks, and the external IP is the DST IP in this case and we've told Snort to only block the SRC address in a traffic flow.

But if you had blocking set to DST, then the reverse would be true. The 64.60.80.5 address would be blocked on the initial outbound connection because it is the DST address in that first instance and it is not covered by a pass list (automatic or user-created).

If you set the blocking to BOTH, then no matter which direction the initial traffic flow occurs, the "bad" external IP of 64.60.80.5 will get blocked because that setting would block an IP address that is not covered by the automatic pass list no matter if it was the SRC or DST. That's why BOTH is the suggested default.

Just remember, internally locally attached networks are never blocked no matter how you set SRC, DST, or BOTH. That setting only matters when looking at IP addresses that are not protected by a pass list.

Enso_

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

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

@bmeeks

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

This leads me back to a question regarding a comment you made. If I set 'Which IP to Block" to "both" (on the LAN interface), how does it behave? It wouldn't block an internal IP from communicating with the world, would it?
Would it just block the internal IP from communicating with the specific External IP that was associated with the Alert?
Or, based on what you mentioned, would it not block the internal IP at all if it's part of the network (in our case a VLAN) directly attached to the LAN interface?

Maybe an example will help you understand the built-in automatic pass list. Suppose I have two internal networks defined as follows:

LAN - 192.168.0.1/24 (firewall LAN interface is 192.168.0.1)
DMZ - 192.168.1.0/24 (firewall DMZ interface is 192.168.1.1)

No IP from either of the two networks defined above would ever be blocked. Both networks would be covered by the automatic pass list. But, if an IP in one of those networks was communicating with an IP that is not within the LAN or DMZ internal networks, then that external IP would be blocked depending on how the SRC, DST, or BOTH setting is configured. See below for further details.

As for the difference between SRC, DST or BOTH, let's look at another example:

A host in your LAN at 192.168.0.5 is communicating with an external host at 64.60.80.5 (just a random IP on the web). That communication could happen in one or both of these directions:

192.168.0.5 --> 64.60.80.5 (in this case 192.168.0.5 is SRC and 64.60.80.5 is DST)
64.60.80.5 --> 192.168.0.5 (in this case 64.60.80.5 is SRC and 192.168.0.5 is DST)

So, in the first example above of your internal host initiating a conversation with 64.60.80.5, if you blocked SRC only then the conversation would be allowed to proceed since the SRC IP is covered by the automatic pass list of internal networks, and the external IP is the DST IP in this case and we've told Snort to only block the SRC address in a traffic flow.

But if you had blocking set to DST, then the reverse would be true. The 64.60.80.5 address would be blocked on the initial outbound connection because it is the DST address in that first instance and it is not covered by a pass list (automatic or user-created).

If you set the blocking to BOTH, then no matter which direction the initial traffic flow occurs, the "bad" external IP of 64.60.80.5 will get blocked because that setting would block an IP address that is not covered by the automatic pass list no matter if it was the SRC or DST. That's why BOTH is the suggested default.

Just remember, internally locally attached networks are never blocked no matter how you set SRC, DST, or BOTH. That setting only matters when looking at IP addresses that are not protected by a pass list.

Done and done.

Thanks, all clear now!

bmeeks

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

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

I recommend leaving that setting alone, too. You generally don't want blocks hanging around forever. Not only do they consume resources, but if the block was due to a false positive you would like it to automatically clear in a reasonable time without requiring admin action.

If Snort blocked the traffic the first time, it will block it a subsequent time later on (if the blocked host is automatically periodically cleared).

One issue with Legacy Blocking Mode is that it is a big hammer. It blocks ALL traffic to a blocked IP for ALL internal hosts.

Inline IPS Mode, if you can use it (your NICs must support netmap natively), drops individual packets instead of blocking everything to/from the IP. That's much more granular. But with Inline IPS Mode, you must explicitly change rules you want to block traffic from ALERT to DROP using the features on the SID MGMT tab.

Enso_

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

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

Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time.

I recommend leaving that setting alone, too. You generally don't want blocks hanging around forever. Not only do they consume resources, but if the block was due to a false positive you would like it to automatically clear in a reasonable time without requiring admin action.

If Snort blocked the traffic the first time, it will block it a subsequent time later on (if the blocked host is automatically periodically cleared).

One issue with Legacy Blocking Mode is that it is a big hammer. It blocks ALL traffic to a blocked IP for ALL internal hosts.

Inline IPS Mode, if you can use it (your NICs must support netmap natively), drops individual packets instead of blocking everything to/from the IP. That's much more granular. But with Inline IPS Mode, you must explicitly change rules you want to block traffic from ALERT to DROP using the features on the SID MGMT tab.

I'm leaving the setting to remove the blocked host after 1h.

As for inline mode; that is something I want to circle back to in the future. However, currently there are no resources that could configure inline mode in a timely fashion. Plus, I'm quite sure I'd have to upgrade the NICs to support netmap.