Messages

Hello everyone.

I've encountered the fabulous packet flow diagram at https://forum.opnsense.org/index.php?topic=36326.0. (It's so good that it gives me goosebumps.) One thing in the diagram confuses me quite a bit. Whenever that happens I usually learn something new. :)

The diagram depicts that Suricata processes ingress traffic before pf scrubs. How does Suricata manage that before potentially fragmented packets are reassembled?

Thank you for this post; I learned a lot from it.

I'm not sure policies are practical for me. I don't want to speak for others, but I'll raise my issues on the hope it adds some useful information.

Initially I was lulled into a false sense of security when setting up a policy. After studying the details of the implementation, I couldn't figure out a way to use them reliably. This is likely the result of my inexperience.

The biggest problem I have is in specification of "Rules" in the "Rule details" dialog used when setting up a Policy. The choices presented are across every installed ruleset. Choosing a particular ruleset does *not* cause the collection of rule choices to be limited to the metadata of that ruleset. Further, even if the metadata is represented in the chosen ruleset, it doesn't mean that the metadata is consistently applied by the original ruleset. Some examples:

Suppose I set up a policy for the emerging-exploit.rules where you focus on the affected_product=Adobe_Coldfusion. Unfortunately, one of the rules in that ruleset did not include that piece of metadata. The rule sid:2025836, msg:"ET EXPLOIT Adobe Coldfusion BlazeDS Java Object Deserialization Remote Code Execution" does not include the "affected_product" metadata.

Suppose I want to target particular rules in emerging-exploit.rules that have a particular "confidence" ("High", "Medium", or "Low). While many rules in that ruleset specify a confidence, most do not. I might even think to specify confidence, thinking it applied to some ruleset I'm targeting, but that ruleset doesn't use that metadata at all.

At the end of the day, I have to make a careful study of every ruleset before settling on any policy. Generally, policies seem too course-grained for my use, but even if I do manage to settle on one, I have two issues.

1 - When rulesets are updated, things could have changed to make the policies that were set up obsolete. That's my inexperience talking; maybe there are conventions in place to prevent that. But if, say, metadata was subtly modified on new versions of some rules, the policies set up could easily miss their targets. If I really want set "drop" on a rule that had a default of "alert", then the only way I see to do that with confidence that it lasts into the future is to do that with a "Rule Adjustment".

2 - I have not found a convenient way to figure out which rules are affected by policies. When I just had a single policy, I tried to just diff the two folders /usr/local/etc/suricata/rules and /usr/local/etc/suricata/opnsense.rules. I thought to just see which files were modified and review the rule changes. Seemed easy enough. Unfortunately, OPNsense makes subtle modifications to every file (adding spaces in the comments at the top), so every file shows as modified.

This thread is really about policies, so the following comment is off-topic. Rule adjustments only show the sid, they don't show the msg: attribute. That makes it very hard to review the adjustments. Once again, the diff'ing the original rules and generated rules is problematic. However, this is solvable with a little scripting.