Rules can be merged without changing what they permit
At a glance
Base severity
Area
Platform
Evidence level
Benchmark reference
Reads the export, not the device
ConfigProof reads a configuration export. This control is evaluated against the objects in that file, and it reports what the file says. It does not connect to the device and sees no traffic, so a finding here describes the configuration, not what the firewall is doing right now.
Why it matters
Rules that differ in one field and share everything else can be one rule. The merged rule keeps the first rule's place, and only the later rules' traffic moves up to it; where every rule in between is proven apart from that traffic, the rulebase gets shorter and nothing is permitted or denied that was not before.
How to fix it
Web interface
The steps below are written for the web interface. A finding raised on your own export carries the same steps with your object names filled in.
- Set the field on the first rule to the merged value, then delete the rules folded into it.
- For a candidate marked needs review, resolve the named reason first; until then it is not a merge this analysis supports.
Command line
PAN-OS CLI, standalone firewall, vsys1
show vsys vsys1 rulebase security rules <object-name>show vsys vsys1 rulebase security rules <rule-to-remove>
An example. Values in angle brackets are yours to supply; a finding on your own export fills in the names it read. Nothing here commits. Review the candidate configuration, then commit it yourself.
Read it back
show vsys vsys1 rulebase security rules <object-name>Values to fill in2
- <object-name>
- The object's name, as it appears on your firewall
- <rule-to-remove>
- A rule folded into the rule kept
Before you type it1
- No set or delete is written for this merge until it is shown to keep what the rules permit. Resolve what blocks the merge, then analyze again.
How to confirm the fix
- Compare the merged rule against the originals: same zones, addresses, users, applications, services, categories, profiles and logging, with one field widened to the union.
- Run a policy match test for a flow of each removed rule and confirm the merged rule answers it.
Limits
- The proof reads the configuration. It cannot see traffic, hit counts, or rules a managed firewall holds locally, and those never sit between two rules of one rulebase.
- Rules kept apart on purpose, for example one per owner or ticket, match this pattern and may be meant to stay apart.
Compliance references
No benchmark recommendation is mapped to this control in this version.
More in Security Policies
- PAN-SEC-040Two rules are exact duplicates
- PAN-SEC-041Two rules differ in one dimension and could be reviewed for consolidation
- PAN-SEC-042Duplicate rules log differently
- PAN-SEC-094Enabled rule names a zone only a disabled tunnel feeds
- PAN-SEC-104Built-in interzone default rule does not log
- PAN-SEC-110No deny rule names the Palo Alto Networks threat IP lists
- PAN-SEC-164An application override rule is configured to bypass App-ID
- PAN-SEC-170Enabled rule with no hit in the counted window
See it on your own firewall
One complete analysis of one firewall costs nothing. A card is required and nothing is charged.