Intrusion Prevention System (IPS): Understanding Policies

[lifepillar]

These are some notes I've gathered while trying to figure out how IPS policies work in OPnsense v23.7.9, which I initially found utterly confusing. I am not an expert and these notes may be inaccurate or plainly wrong: enjoy at your own risk. I hope this will help others kickstart the use of IPS!

Policies are the preferred way to manage IPS rules and rulesets, and should be used instead of user-defined rules in most cases.

IMPORTANT: these notes assume that the OPNsense's IPS (not IDS!) has been correctly enabled and configured in Services > Intrusion Detection > Administration > Settings. In my simple network with two physical interfaces (LAN1 and WAN) and a few VLANs, that means enabling both IPS mode and Promiscuous mode and setting the Interfaces field to LAN1. Besides, all hardware offloading and VLAN filtering has been disabled in Interfaces > Settings (Hardware CRC, Hardware TSO, Hardware LRO are checked, and VLAN Hardware Filtering is set to Disable VLAN Hardware Filtering). Reboot after changing those settings.

The following abbreviations for OPNsense pages or tabs are used in these notes:

- Alerts: visit Services > Intrusion Detection > Administration > Alerts.
- Download: visit Services > Intrusion Detection > Administration > Download.
- Rules: visit Services > Intrusion Detection > Administration > Rules.
- Policy: visit Services > Intrusion Detection > Policy > Policy.
- Rule adjustments: visit Services > Intrusion Detection > Policy > Rule adjustments.

IMPORTANT! Make sure to click the Apply button every time you make changes to a page or tab before leaving that page or tab. Otherwise, you risk seeing inconsistent views from different parts of the interface.

Now, let's come to the meat. If and how rules are applied can be inspected in Rules: in particular, the state of a rule (enabled or disabled) is shown in the Info/Enabled column, and the action to apply when a rule triggers is shown in the Action column. If the IPS behavior deviates from what is shown in Rules then that should be considered a bug (but make sure all the changes you have made have been applied—see above).

The states and actions in Rules are determined for each rule R as follows:

1. if there is an entry in Rule adjustments for rule R then the state (enabled or disabled) and action (drop or alert) in that entry will take precedence over anything else. If a rule adjustment exists for rule R, but the information in Rules differs from the rule adjustment settings, that is to be considered a bug.

2. If no rule adjustment exists for rule R, then the policy with the highest priority (that is, with the lowest priority integer value) that applies to the rule is used, if any.

3. Otherwise, the default state and action as defined by the ruleset are used.

A few remarks:

- in case it is not clear, if no policy is defined then obviously only (1) and (3) above apply. Defining policies is not mandatory.

- Any change to a rule done via the controls in the Rules tab automatically creates or updates an entry in Rule adjustments. Therefore, as soon as you manually change a rule, policies won't apply to that rule any longer until you go and manually delete the corresponding rule adjustment.

- When you create a policy (by clicking `+` in Policy), a dialog is shown. The Action field in that dialog has (confusingly enough) three values: Disabled, Alert, and Drop (it is confusing because that puts under the “Action” label both the state of the rule and the corresponding action). That should be interpreted (I believe) as follows:

  - disabled:: apply the policy to any rule (of the selected rulesets) that is by default not enabled no matter what action is associated to the rule;
  - alert: apply the policy to any rule that by default (is enabled and) should be logged;
  - drop: apply the policy to any rule that by default (is enabled and) causes traffic to be blocked.

  Since a policy does not apply to rules for which a rule adjustment has been defined, the state and action referred to in the Action dropdown menu are the default state and action as defined by the ruleset (that is why I have emphasized "by default").

  Now, one of the most confusing aspects from my perspective is that, after a policy is applied (by clicking on the Apply button in Policy), in Rules you do not see the default state and action as defined by the ruleset any longer; rather, the actual state and action of the rule are shown (as I've said previously). That makes sense, but it is not apparent any more in the UI to what rules the policy was applied.

- To avoid any confusion, if you have more than one policy, assign your policies different priorities.

- Before defining a policy, download the rulesets you wish to use.


EXAMPLE

The best way to understand how the IPS works is to play with a single test rule.

0. Make sure Rule adjustments is empty and that you have no policies and no enabled rulesets. Clear the logs in Alerts.

1. Enable and download the OPNsense-App-detect/test ruleset. Such ruleset has a single rule that by default prevents downloading the file at http://pkg.opnsense.org/test/eicar.com.txt.

2. Go to Rules and verify that the rule (a) is enabled and (b) its default action is "drop".

3. In Rules, change the action to "alert". Click Apply.

4. In Rule adjustments, verify that a new entry has been created for the rule (state: "enabled", action: "alert").

5. From the command line: fetch http://pkg.opnsense.org/test/eicar.com.txt. You should be able to download the file without any problem. Go to Alerts and verify that the downloading attempt has been logged.

6. Go to Rule adjustments and delete the entry for the rule. Click Apply (Do not forget to click Apply!)

7. Go to Rules and verify that the rule is again "enabled" with a "drop" action.

8. From the command line: fetch http://pkg.opnsense.org/test/eicar.com.txt. You should not be able to get the file any longer. Go to Alerts and verify that there are one or more "blocked" entries matching the rule.

9. Go to Policy and create a new policy as follows:

  - Enabled: checked.
  - Priority: 0.
  - Ruleset: opnsense.test.rules
  - Action: Drop
  - Rules: Nothing selected
  - New Action: Alert
  - Description: Test Drop to Alert

  Click Save, then click Apply.

10. Go to Rule adjustments to double-check that no rule adjustment exists.

11. Go to Rules and verify that the rule (a) is enabled and (b) its action is set to "alert", because the policy has been applied to the rule. Note: AFAICS, at this point there is nothing in the UI that signals that this rule was changed by a policy.

12. From the command line: fetch http://pkg.opnsense.org/test/eicar.com.txt. You should be able to get the file again. Go to Alerts and verify that there is a new "allowed" entry matching the rule.

13. In Rules, change the action associated to the rule to "drop". Click Apply.

14. In Rule adjustments verify that a rule adjustment has been added again (state: "enabled", action: "drop"). So, now there is a policy that applies to the rule, but the rule adjustment overrides the policy.

15. From the command line: fetch http://pkg.opnsense.org/test/eicar.com.txt. That should fail and in Alerts the blocked attempt should be logged.

Let's summarize what we have done. After these steps:

- in Rules you see an enabled rule with a "drop" action from the opnsense.test.rules.

- in Policy you have a policy that applies to the rules of the opnsense.test.rules ruleset that have a "drop" action, and turn them into "alert" rules.

- But the policy does not apply to that rule because a rule adjustment exists.

This all makes sense, but it would be much clearer if the Rules table showed why a rule is what it is. A column with three values (e.g., "ruleset", "policy", "adjusted/overriden") would suffice.

16. In Rule adjustments delete the rule adjustment. Click Apply.

17. In Rules, verify that now the policy applies again: the rule has an "alert" action.

18. In Policy, edit the policy by setting Action to Alert only (deselect Drop). Click Save then Apply.

19. In Rules verify that the rule is back to its ruleset defaults: enabled and with a "drop" action. The policy does not apply to this rule because its default action as defined by the ruleset is "drop", not "alert".

20. From the command line: fetch http://pkg.opnsense.org/test/eicar.com.txt. The action fails and in Alerts the blocked attempt is logged, as expected.

[barold]

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.