Does supression in suricata mean blocking or hiding the alert?

bmeeks

A rule on a Suppression List is still evaluated, but it will not log an alert and will not cause a block. However, CPU cycles are still expended evaluating packets against the suppressed rule.

A disabled rule is not even loaded into memory by the Suricata engine. Thus disabled rules do not consume CPU cycles and, since they are not even loaded, can't produce either alerts or blocks.

A Pass List is a different animal entirely and is a pfSense-specific customization in Suricata. Legacy Mode blocking uses a custom output plugin compiled into the Suricata binary. That plugin receives a copy of every single alert generated by the Suricata traffic inspection engine. The custom plugin examines the IP addresses in the alerting packet and checks if they are on a configured Pass List for the interface. If they are, then no block is generated for that rule BUT the alert from the rule will still print to the log and show up on the ALERTS tab. It just does not result in blocked traffic. However, if an IP address in the alerting rule is not covered by a configured Pass List, then a block for that IP is inserted into the firewall's pf packet filter table called snort2c.

So how do suppressed rules fit into the block logic? A suppressed rule can't generate an alert, and with no alert generated to be passed over to the custom blocking plugin, suppressed rules can't generate blocks.

strongthany

@bmeeks Thank you for the very informative response. I want to ask once more, however, only for clarification sake to me:

When you say a block, that is referring to the action of suricata blocking a connection.
When a rule is processed from the suppression list against a connection, that takes a cycle and, provided that the connection fits what's in the suppression list, will allow it through.

Am I correct in my statements and understanding of how these functions and nomenclature work?

Thank you again for the help!

Bob.Dig

@bmeeks Can it generate drops though?

bmeeks

@strongthany said in Does supression in suricata mean blocking or hiding the alert?:

@bmeeks Thank you for the very informative response. I want to ask once more, however, only for clarification sake to me:

When you say a block, that is referring to the action of suricata blocking a connection.

When a rule is processed from the suppression list against a connection, that takes a cycle and, provided that the connection fits what's in the suppression list, will allow it through.

Am I correct in my statements and understanding of how these functions and nomenclature work?

Thank you again for the help!

Yes, that is correct. Suricata on pfSense "blocks" by way of the custom output plugin I mentioned, That plugin implements a block by making a system ioctl() call to the kernel to add an IP address to a pre-existing pf table called snort2c.

Suppression Lists prevent alerts, and because of the way the custom blocking plugin works, when there is no alert there can be no block either. The plugin works only by looking at alerts.

bmeeks

@Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

@bmeeks Can it generate drops though?

No, a suppressed rule cannot generate a drop. Suppressed rules don't "fire", and thus they can't produce the action contained in their "action" verb keyword (be it ALERT, REJECT, PASS or DROP).

Think of a suppressed rule as being the same as a disabled rule, but suppressed rules use CPU cycles while disabled rules do not. The purpose of Suppress Lists in an IDS/IPS is so you can create certain situations where problematic or false-positive prone rules in your environment can be, in effect, bypassed when certain conditions are met (the suppression criteria).

strongthany

Thank you for the reply, that all made it very clear.

Bob.Dig

@bmeeks Thanks, that I didn't understand till now, have to clear the suppression list.

Bob.Dig

@Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows

ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
ET INFO Windows OS Submitting USB Metadata to Microsoft

which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

bmeeks

@Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

@Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows
ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
ET INFO Windows OS Submitting USB Metadata to Microsoft
which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

Unfortunately that's just not how Suricata (or any IDS/IPS that I am familiar with) works. And think about the puzzling issues that would be caused by a rule whose action fired (drop or reject, for instance), but nothing was logged about the action.

bmeeks

@Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

@Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows
ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
ET INFO Windows OS Submitting USB Metadata to Microsoft
which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

One other point -- if you are using Inline IPS Mode I suggest changing the action of these types of rules to REJECT instead of DROP. Since it is your clients initiating the transfer to Microsoft, they will attempt the connection. If it is dropped, the client gets nothing back and will probably sit and wait for a timeout. If the action is REJECT, the client is immediately sent back a notification by Suricata that the destination is not accepting connections and thus your LAN clients will not wait for a timeout.

Drops are good on the WAN or for external connections coming in where you want the attacker to think nothing is even there. Rejects work better when trying to block LAN-initiated traffic (or in many cases such as blocking routine telemetry). For malware type rules, a drop is perferred.

Bob.Dig

@bmeeks Thanks again. I have to use the Legacy Mode, because the virtual NICs in Hyper-V are not supported for inline mode.

strongthany

On the note of that, how would one check if their interface supports netmap/inline?

Bob.Dig

@strongthany Test it.

bmeeks

@strongthany said in Does supression in suricata mean blocking or hiding the alert?:

On the note of that, how would one check if their interface supports netmap/inline?

These NIC drivers currently support the netmap device in FreeBSD: em(4), igb(4), ixbge(4), lem(4), re(4).

Features such as limiters and alternate queing algorithms do not work with netmap. So if your NIC is using one of the drivers listed above, and you are not doing using limiters, then inline mode with netmap should work for you.

Information on configuring the supported Intel NICs can be found in this forum sticky post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.