Converting undesired Snort blocks into suppression list entries

oak9

I'm wondering if there are reasonable improvements to make to the following workflow I use to suppress IDS/IPS blocks interfering with normal activity such as Windows Update or Linux-related apt updating.

pfSense CE 2.6.0
pfSense Snort 4.1.6 / snort-2.9.20
Snort / LAN Settings, Alert Suppression: <suppression_list_name>
Snort / LAN Categories, IPS Policy: "Security"

Workflow:

Go to Snort / Blocked Hosts, observe blocked entry, take note of its IP address, N.N.N.N in this example.
Go to Snort / Alerts, use browser CTRL-F to find the IP address from step #1 on the alerts page (i.e., search for "N.N.N.N" and find matches).
For each entry, click the '+' icon next to the IP address (N.N.N.N) to add to suppression list.
Rinse/repeat to deal with all blocks.
Optional: Edit the new suppression list entry to use a subnet specification instead of a single IP if a subnet is known to be entirely acceptable.

I do not see a way to click in the Blocked tab to have it directly create a suppression list entry.

Anyone have thoughts/suggestions on improvements?

bmeeks

You can do all of this directly from the ALERTS tab. Since you mention "blocks" and the BLOCKS tab, I assume you are using Legacy Blocking Mode. In that mode, alerts on the ALERTS tab that are currently producing "blocks" will have a red X icon under the IP address column. Hovering over that icon will cause a tooltip to appear letting you know that clicking that icon will remove the block. Under the same column are the icons for adding the IP to the existing Suppression List for the interface.

No need to swap back and forth and perform searches as you are doing now. Simply scroll down the ALERTS tab page and find the red X icons under the IP Address columns (SRC or DST) and add those to the Suppression List if desired.

You might also consider further refining or tuning your rule set. If you are seeing blocks for normal Windows or Linux updates, my first suspicion is that you have enabled the ET-Info category of rules. Rules like that should not be enabled for blocking. They are designed as "informational rules" and do not necessarily indicate an "attack". If you are chasing the IP addresses of the CDNs used by Microsoft and Linux distros to distribute updates, then you are on a neverending quest. There are many, many of those IP addresses and they change quite frequently.

oak9

@bmeeks said in Converting undesired Snort blocks into suppression list entries:

... alerts on the ALERTS tab that are currently producing "blocks" will have a red X icon ... clicking that icon will remove the block. Under the same column are the icons for adding the IP to the existing Suppression List ...

Very helpful, thank you.

... You might also consider further refining or tuning your rule set. ... my first suspicion is that you have enabled the ET-Info category of rules. Rules like that should not be enabled for blocking. They are designed as "informational rules" ...

You are correct... I am in Legacy Mode, with "Block Offenders" checked. IPS Policy is "Security" and emerging* are all checked (including emerging-info.rules).

A point of confusion... how does one retain emerging rules meant for causing informational only alerts while using the "Block Offenders" feature, or is that not possible?

bmeeks

@oak9 said in Converting undesired Snort blocks into suppression list entries:

A point of confusion... how does one retain emerging rules meant for causing informational only alerts while using the "Block Offenders" feature, or is that not possible?

That's not possible using Legacy Blocking Mode. The only alternative would be to disable either that entire Rules Category, or manually disable the particular offending rules in the category.

Inline IPS Mode would allow you to choose which rules drop traffic and which rules simply alert on but allow traffic. Suricata, which operates much the same as Snort, has a special mode available for its Legacy Blocking Mode operation called "Block on DROPs Only". That allows you to configure the rule actions for either DROP or ALERT and only those set to DROP would actually block traffic. This mode in Suricata lets you emulate a true Inline IPS Mode when you have a NIC that does not support Inline IPS operation with netmap. Unfortunately Snort does not support that Legacy Blocking Mode operation option due to how its internal network traffic plumbing works.

oak9

@bmeeks said in Converting undesired Snort blocks into suppression list entries:

Inline IPS Mode would allow you to choose which rules drop traffic ...

Thanks... I think I've had an "ah ha" moment... From what you say, the way Snort Legacy Mode works—I believe it processes packets asynchronously to actual flow which seems to tie into your clarification—it seems there is no Legacy Mode dropping of packets, just alerting/blocking in Legacy Mode.

I have an i211 ("i211 gigabit network connection")... I saw mixed reports but ultimately got the notion it should work in Inline mode, but not sure. I tried switching to Inline earlier today but network went down... I restored Legacy Mode for now, need to look closer at what happened. I'm not assuming it's the adapter, from a quick look at logs, there was lots of repeat activity of some kind, so wondering if something got saturated... need to look more, did not have cycles this morning.

Given your overall clarifications, seems best for me to start with reduction of unnecessary rules...

I notice lots of emerging rule categories which seem to cover certain protocols, such as VOIP or SMTP, and so forth. If an environment is not using those protocols, I assume it's generally a safe bet to remove those categories.

Have you ever heard of any rule categories applicable to environments not using the protocols named within the category name itself?

For example, there is no POP3 or FTP in use so seems disabling both emerging-pop3.rules and emerging-ftp.rules should not result in loss of any benefits.

bmeeks

@oak9 said in Converting undesired Snort blocks into suppression list entries:

I notice lots of emerging rule categories which seem to cover certain protocols, such as VOIP or SMTP, and so forth. If an environment is not using those protocols, I assume it's generally a safe bet to remove those categories.

Yes, it is safe to disable rules (and even entire rule categories at times) if the rules cover vulnerabilities that are not present in your environment. If you do not have a local web server that is accessible from the WAN, then you don't need any web server rules. If you do not run a public DNS server that is used by random folks on the Internet, then you do not need any DNS server rules. Ditto for a mail server. This is what is meant by "tuning" your rules. Only select and enable rules that address vulnerabilities that actually exist in your protected networks.

One other thing to remember is that the vast majority of network traffic today is end-to-end encrypted. Snort can't see any of those encrypted packet payloads. The bytes just show up as random numbers. That will render many rules toothless if they are expecting to examine the packet payload for content matching and alerting.

Legacy Mode Blocking uses the libpcap library to scan copies of packets as they traverse the NIC. This means initial packet leakage will happen before a block is created. Snort blocks in Legacy Mode using a custom output plugin compiled into the binary. That plugin uses a system call to send the IP address to be blocked over to the pf (packet filter) engine in FreeBSD. The IP is stashed into the snort2c pf table. Any IP address placed in that table is blocked by a built-in, hidden firewall rule added by pfSense during bootup.

Inline IPS Mode works quite differently. It uses the netmap kernel device to intercept packets between the NIC and the host network stack. Packets that "pass" are copied on to their destination. Packets that are "dropped" are simply not copied to their destination.

Here are a couple of diagrams illustrating how the two modes operate.

oak9

@bmeeks said in Converting undesired Snort blocks into suppression list entries:

... One other thing to remember is that the vast majority of network traffic today is end-to-end encrypted. Snort can't see any of those encrypted packet payloads. The bytes just show up as random numbers. That will render many rules toothless ...

That is a phenomenal point... for this environment, with most things using encryption, most rules are not used most of the time. The only cleartext transmissions I've seen recently were around the blocks discussed earlier (updater-related stuff apparently still using HTTP).

Legacy Mode Blocking uses ... Inline IPS Mode works quite differently. .... Here are a couple of diagrams illustrating how the two modes operate. ...

Great overview, thanks... seems like Inline is the way to go... if my hardware at this time cannot handle Inline, I'll push it out to a future upgrade.

Okay, time for me to disable some unneeded rule categories, maybe get Inline going. This has been super helpful, thank you again.

bmeeks

@oak9 said in Converting undesired Snort blocks into suppression list entries:

The only cleartext transmissions I've seen recently were around the blocks discussed earlier (updater-related stuff apparently still using HTTP).

Some DNS lookups are still cleartext (if you do not have TLS enabled).

Most all websites are now HTTPS including most (if not all) of the Microsoft sites. Rules can trigger off metadata without actually looking at the payload. That is what many of the ET-Info rules look at. Examples are source or destination IP addresses, protocols, ports, and certain non-encrypted metadata present in some protocols. SNI is an example of metadata associated with HTTPS connections that is still mostly unencrypted. But that is changing with the coming introduction of encrypted SNI.

But metadata analysis is not effective for malware detection. After all, a blackhat hacker is not going to clearly identify his malware unless he is a complete idiot .