Suricata inline whitelisting

btspce

Is there a way to whitelist a specific rule for a specific ip in inline mode?

I tried using a supression list for wan like below to disable the rule for that source ip (example ip)

suppress gen_id 1, sig_id 2220006, track by_src, ip 8.8.8.8

The alert still shows up and traffic is blocked. (Suricata is restarted on wan)

Is IP reputation list the only way. Would prefer to not whitelist a host on all rules.

bmeeks

I'm not sure about this. You will probably get a better answer over on the Suricata Redmine site. It would depend on where in the packet processing chain within Suricata a "suppress" action is checked versus where the "inline drop" action is taken. Logically you would assume suppress would be evaluated first, but I don't know. All this happens within the Suricata binary and that is not something maintained on the pfSense side. It is just a loaded dependency in the package for pfSense. The package on pfSense is really just a GUI that generates the suricata.yaml file used by the suricata binary as its configuration.

Bill

btspce

I've been reading here: http://suricata.readthedocs.io/en/latest/performance/ignoring-traffic.html

When reading the above I get the impression that a suppressed rule should never result in a drop?
So the suppression lists is only to "hide" the alert? not stopping a potential drop?
Can we use pass rules in pfsense? where do I put them?
Use modifysid ?

Thanks for your work bmeeks!

bmeeks

@btspce:

I've been reading here: http://suricata.readthedocs.io/en/latest/performance/ignoring-traffic.html

When reading the above I get the impression that a suppressed rule should never result in a drop?
So the suppression lists is only to "hide" the alert? not stopping a potential drop?
Can we use pass rules in pfsense? where do I put them?
Use modifysid ?

Thanks for your work bmeeks!

You found a key piece of info that I had not seen before (admittedly I had not gone looking for it either … :(). Here it is:

Suppress rules can be used to make sure no alerts are generated for a host. This is not efficient however, as the suppression is only considered post-matching. In other words, Suricata first inspects a rule, and only then will it consider per-host suppressions.

This means to me that the pass, drop, reject, etc., decision is made first and then the suppress list is checked to see whether or not to suppress the alert in the logs. I need to dive into the source code for the Suricata binary and see if I can precisely determine how suppression affects dropping.

I can read the linked information to mean if the rule was "drop" but was suppressed, the packet is still dropped but would not alert. This is different than what happens in Legacy Mode with the package on pfSense. Legacy mode actually uses the "alert" action to know what to block, so when a rule is suppressed it generates no alert and thus no block can happen.

Inline IPS mode is different and may require a paradigm shift in how we use the Suricata package on pfSense. I must admit I had not thoroughly researched this before, but now I see a potential issue. Suppress Lists may no longer have the same action as they did in Legacy Mode. Namely, simply putting in a suppress rule might not prevent a drop of a packet even though it will prevent the alert from showing up on the ALERTS tab.

I need to dig into this some more before I can post a definitive answer.

Bill

bmeeks

A fix for Suricata inline IPS mode whitelisting will be in the next GUI package release which is coming soon. The update will restore the old PASS LIST functionality from the Legacy Mode GUI, but will actually implement the pass list by automatically creating appropriate PASS rules for you and adding them to the rule set. Since the default priority mode in the package for rules is PASS, DROP, REJECT and then ALERT, these pass rules will let the traffic for pass list hosts pass without ever being blocked.

Bill

btspce

Thanks. Updated now. Is there a way in the new version to whitelist a specific rule on a specific host like when writing the suppress rules?
As I understand it we can now whitelist all traffic from a host or no whitelist at all?

btspce

Just found your thread: https://forum.pfsense.org/index.php?topic=124270.msg686427#msg686427

what is the better way of protecting hosts from being blocked (or having their traffic dropped)?  You might want to consider using the Suppress List feature to selectively bypass only the rules giving you trouble for specific hosts.  You can use the icons on the ALERTS tab to accomplish this.  Hover over the plus signs (+) in the alert rows to see a tooltip popup describing what clicking the icon does.  A Suppress List entry bypasses a single rule GID:SID.  It can be bypassed for all hosts, or only select hosts by either source IP or destination IP.  A Pass List entry, on the other hand, will bypass all rules for the host IP addresses in the list.

So suricata is not just hiding the alert anymore as in the previous version?

SteveITS

@bmeeks said in Suricata inline whitelisting:

Suppress rules can be used to make sure no alerts are generated for a host. This is not efficient however, as the suppression is only considered post-matching. In other words, Suricata first inspects a rule, and only then will it consider per-host suppressions.

This means to me that the pass, drop, reject, etc., decision is made first and then the suppress list is checked to see whether or not to suppress the alert in the logs. I need to dive into the source code for the Suricata binary and see if I can precisely determine how suppression affects dropping.

I need to dig into this some more before I can post a definitive answer.

Hi, did this get figured out/resolved? We may have run into this today on Suricata package v4.0.4_1...I suppressed an alert but the behavior didn't seem to change until I disabled the rule.
(FWIW it was rule 1:2013744 "ET INFO DYNAMIC_DNS HTTP Request to a no-ip Domain" which would make sense for dynamic domains but was for cdn.no-ip.com which is their actual domain. The rule only excludes www.no-ip.com.)