Does supression in suricata mean blocking or hiding the alert?

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.