pfsense equivalent to SourceIP/SID whitelisting

[nekopep]

Hello,
I recently switched to opnsense and activated the suricata IPS.
One thing is missing to me is the DHCP lookup and IP whitelisting I got on pfsense snort/suricata interface.
On the attached screenshot, in purple you'll see 2 icons:
- 1 magnifying glass: cliking on it the interface try to resolve for example the local ip thanks to DHCP server registered data. So it is quicker to understand who is doing bad stuff.
- 1 "+ mark" that allow add the couple IP/rule SID to a passlist for example to disable alert for a specific IP/SID.

Is there any equivalent of "+" mark behaviour on opnsense (the one that is missing the most for me), that is defining a pass lsit with src_ip/SID ?
Any plan to add these 2 options?

[nekopep]

So far I think I found a kind of workaround:
I modify manually the file /usr/local/etc/suricata/threshold.config

#######################################################################
#suppress ET INFO File Hosting Service Domain Domain in DNS Lookup (files .pythonhosted .org)
suppress gen_id 1, sig_id 2049201
#suppress ET INFO Clearbit Logo Query in DNS Lookup (used by Odoo)
suppress gen_id 1, sig_id 2044300
#suppress ET POLICY External IP Lookup (avast .com)
suppress gen_id 1, sig_id 2029575
#http.user_agent CCleaner Update Agent
#suppress ET DNS Query for .to TLD
suppress gen_id 1, sig_id 2027757
#threshold ET POLICY Vulnerable Java Version 1.8.x Detected (1/day)
threshold gen_id 1, sig_id 2019401, type threshold, track by_src, count 1, seconds 86400
#threshold ET POLICY Vulnerable Java Version 17.0.x Detected
threshold gen_id 1, sig_id 2034817, type threshold, track by_src, count 1, seconds 86400

It could be interesting to add a "+" mark that popup a wizard asking to whitelist the sid, with:
- comment
- a tick for threshold
- if threshold: an int for count
- a choice for track_by: src/dst/none
- if threshold: seconds before next event

So user could review later is rules that he has whitelisted.

[Monviech (Cedrik)]

Im not sure a + or a magnifying glass can be added at that spot, without considerable effort or an own solution.

The suricata implementation in OPNsense uses MVC, and uses shared standardized components and api functions like the UIBootgrid plugin to render its table views.

https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/views/OPNsense/IDS/policy.volt

A better way would probably be to extend the custom rule view a little bit so a SID can be added there. The custom rule would then bypass the rule based in source IP and SID.

https://forum.opnsense.org/index.php?topic=36635.msg179005#msg179005

In this view:
/ui/ids#userrules

EDIT:

I just checked this out quickly and it seems like this would probably need an own new custom view where you can set thresholds in a style like this:

Code: [Select]

suppress gen_id 1, sig_id 172621, track by_src, ip 192.168.1.1
There would probably need to be a new import statement for threshold.custom.rules or equivalent in the existing threshold.config file. The new threshold.custom.rules would need to be generated by a template based on the data needed for it.

This new view partial could probably be embedded in the same tab as "user defined rules"

EDIT2:

https://forum.suricata.io/t/rule-threshold-configuration/2461

Though it seems like it would be better to have the rule itself fixed so the false positive isn't triggered anymore. It's probably a scope kind of issue:

- Is it in scope of OPNsense to allow the user to fix the logic of faulty rules?
- Is it in scope of the rule provider to fix their provided rule to not trigger false positives?

Right now, deactivating false positive rules for all traffic seems like the best choice until the rule is fixed and works properly. If it triggers wrongly a lot, who says any other triggered action is a real threat or not?

[nekopep]

Hello Monvieh
Your solution 1 is OK.

###
Though it seems like it would be better to have the rule itself fixed so the false positive isn't triggered anymore. It's probably a scope kind of issue:

- Is it in scope of OPNsense to allow the user to fix the logic of faulty rules?
No
- Is it in scope of the rule provider to fix their provided rule to not trigger false positives?
Yes
###

But!
In fact, here in my case, the rule is not faulty it is plain OK, just with this change you can deactivate a rule for a speciifc IP.

For example, one of my user raise ET INFO Clearbit Logo Query in DNS Lookup but it is normal behavior for this IP.

So adding "suppress gen_id 1, sig_id 2044300, track by_src, ip 192.168.0.4" is a good point in my case.

Also for example, it is ok to get ET POLICY Vulnerable Java Version 17.0.x Detected, but adding:
threshold gen_id 1, sig_id 2034817, type threshold, track by_src, count 1, seconds 86400

Will pop the info once per day, so your are not spammed until you take time to correct it.

The final idea behind these settings is just lowering the amount of unusefull info, so important one pop up more cleary.

Also it reminds me that on pfSense, there is an important column on alert tab, the rule priority. That is, alert with level 1 are high priority, and very suspicious while level 3 are just network traffic info (like ET INFO).
Could be interesting to be able to filter on these priority.

--> Once you modify a .volt file, do you know how to relaod the view , to get update?
I wanted to reduce the time column in alert tab as a first patch , so we could view full rule name

[Monviech (Cedrik)]

If you can, open an issue on github and make a feature request.

Since suricata is a core plugin maintained directly by the opnsense core developers, they have to decide if the feature is an essential addition or out of scope for the plugin. (If you don't want to fork the suricata plugin and maintain the fork yourself).

--> Once you modify a .volt file, do you know how to reload the view , to get update?

I don't know right now, sorry. This plugin is a little more involved than what I understand so far.

[nekopep]

Done: https://github.com/opnsense/core/issues/7138