Show Posts
1
Tutorials and FAQs / Intrusion Prevention System (IPS): Understanding Policies
« on: December 09, 2023, 11:12:36 pm »
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.
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.