Bidirectional static source NAT creates an implicit inbound path
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
A static source NAT with bi-directional enabled also creates the reverse destination NAT. The internal host becomes addressable from outside without an explicit inbound NAT rule that a reviewer would notice.
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.
- Turn off bi-directional and write the inbound NAT explicitly if it is needed.
- Make sure a security rule restricts the inbound direction.
Command line
PAN-OS CLI, standalone firewall, vsys1
set vsys vsys1 rulebase nat rules <object-name> source-translation static-ip bi-directional noAn 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 nat rules <object-name>Values to fill in1
- <object-name>
- The object's name, as it appears on your firewall
Before you type it1
- Removing the bidirectional flag closes the inbound path it created. Anything relying on that path stops.
How to confirm the fix
- Confirm a security rule restricts the inbound direction before or after the change.
Limits
- Bi-directional NAT is a valid design for published servers when the matching security rule is tight.
Compliance references
No benchmark recommendation is mapped to this control in this version.
See it on your own firewall
One complete analysis of one firewall costs nothing. A card is required and nothing is charged.