How to Audit Firewall Rules: A Step-by-Step Guide

A firewall audit is a systematic review of your firewall's configuration — rules, zones, security profiles, firmware, and logging — to identify misconfigurations that create exploitable gaps. It's not a penetration test. It doesn't require active exploitation. It's a configuration analysis that answers a simple question: does your firewall actually enforce the security policy you think it does?

The answer is often no. According to Verizon's Data Breach Investigations Report, over 90% of ransomware incidents exploit firewall weaknesses — misconfigured rules, unpatched firmware, or missing security profiles that attackers use to establish footholds, move laterally, and exfiltrate data. Most of those weaknesses were present for months or years before they were exploited.

This guide walks through a complete firewall rule audit in seven steps, from exporting your config to generating a remediation plan. It applies to any major vendor — FortiGate, Palo Alto, Sophos, Check Point, Cisco ASA — and works whether you're preparing for a compliance audit or just want to understand your actual exposure.

Why Firewall Rules Drift Over Time

A freshly deployed firewall typically has a clean, well-reasoned rule base. Three years later, the same firewall often looks completely different — and not intentionally.

Rule drift happens through several predictable mechanisms. The first is accumulation: every time a new application is deployed, a new rule gets added at the top of the policy. Old rules are rarely removed because no one is certain what traffic they still carry. Over time, the rule base grows — 200 rules, 400 rules, 800 rules — and the cognitive overhead of understanding it becomes too high for anyone to audit manually.

The second is team changes. The engineer who designed the original segmentation leaves. Their replacement inherits a configuration they didn't build, doesn't fully understand, and is understandably reluctant to touch. Documentation, if it existed, goes stale.

The third is emergency rules — the most dangerous category. When a system is down at 2 AM, the fastest path to restoration is a broad permissive rule. The intent is always to lock it down later. In practice, "later" often means never. These rules accumulate silently, each one expanding attack surface without anyone noticing.

By the time you run a formal audit, you're often looking at a rule base that reflects years of accumulated decisions, half of which no one remembers making.

Step 1 — Export and Document Your Current Config

Before you can audit anything, you need a complete, structured export of your firewall configuration. What you export depends on your vendor:

• ✓ FortiGate: execute backup config flash or export from System > Dashboard > Config Backup. Results in a text .conf file.
• ✓ Palo Alto: Device > Setup > Operations > Export Named Configuration Snapshot. Results in an XML file.
• ✓ Sophos XG/XGS: Backup & Firmware > Backup. Entity export (Entities.xml) or pgdump format depending on firmware version.
• ✓ Check Point: Use mgmt_cli show access-rulebase or SmartConsole policy export. JSON output from the management API gives the most structured data.
• ✓ Cisco ASA: show running-config saved to a file. Capture from a terminal session or via ASDM.

Record the export date, firmware version, and the name of the person who performed the export. For compliance purposes, this export timestamp becomes the basis of your audit evidence package. If you're running a scheduled audit process, automate this export and store the output with cryptographic integrity verification (a SHA-256 hash of the config file) so you can prove the reviewed config matches what was running in production.

Do not begin analyzing rules before you have a complete config. Partial exports — just the firewall policy without the object definitions, or the policy without the security profile settings — will produce false negatives where you miss misconfigurations that only become visible when the full context is available.

Step 2 — Identify Shadow and Redundant Rules

Shadow rules are firewall rules that can never be matched because an earlier rule in the policy already matches all the same traffic. They exist silently, doing nothing, and create a maintenance burden: operators may believe a security control is active when it's actually unreachable.

A simple example: Rule 5 permits traffic from 10.0.0.0/8 to any destination on port 443. Rule 47 denies traffic from 10.10.1.0/24 to the finance subnet on port 443. Rule 47 is shadowed — all traffic from 10.10.1.0/24 is a subset of 10.0.0.0/8, so Rule 5 matches first and the deny in Rule 47 never executes. An administrator reviewing the policy might believe the finance subnet is protected. It isn't.

Shadow rules are dangerous specifically because they create a false sense of security. Someone deliberately added Rule 47 to protect something. The protection isn't working.

Redundant rules are a related problem: multiple rules that permit the same traffic, where removing one would have no effect on behavior. These aren't security vulnerabilities on their own, but they inflate rule count, reduce readability, and make it harder to reason about what the policy actually does.

To identify shadow rules manually, you need to work through the policy top-to-bottom and track which source/destination/service combinations are already fully covered by earlier rules. On a policy with 50 rules this is tractable. On a policy with 400 rules across 20 zones, it requires tooling. For automated detection, check each rule against all preceding rules: if the source, destination, and service of rule N is a subset of any rule 1..N-1, rule N is shadowed.

Step 3 — Find Overly Permissive Policies

Overly permissive rules are the leading source of preventable breaches. They fall into several categories with increasing severity:

ANY/ANY rules are the most dangerous. A rule with source=any, destination=any, service=any, action=accept means any host can reach any other host on any protocol. These are occasionally defensible in specific architectural contexts (a completely isolated test environment, a single-host DMZ segment with no lateral movement risk) but are almost always findings that require remediation.

Broad subnet policies are more common and harder to detect. A rule permitting 10.0.0.0/8 to reach the server subnet is technically scoped, but if your server subnet contains payment systems and the source covers 60,000 workstations, the practical impact of a workstation compromise is unrestricted access to those servers. Review whether source and destination ranges are as tight as they could be given the actual traffic requirements.

All-services rules permit specific source-destination pairs but allow all protocols. A rule permitting a developer workstation to reach a database server on all services means an attacker who compromises that workstation can reach the database on RDP, SSH, SMB, and any other protocol — not just the database port. Service fields should be as specific as possible.

When reviewing for permissiveness, pay particular attention to rules that touch internet-facing zones, management networks, and systems holding sensitive data. A broadly permissive rule in a low-value network segment is a lower priority than the same rule touching a payment system or domain controller.

Step 4 — Review Zone Segmentation

Firewall rules don't exist in isolation — they implement a zone segmentation model. Part of auditing the rules is auditing whether that model is correctly implemented and whether the model itself is sound.

DMZ isolation is the first thing to check. DMZ hosts should be able to reach the internet (outbound) and accept traffic from the internet on specific ports (inbound). They should not be able to initiate connections to internal trust zones — servers, workstations, or management networks. A DMZ-to-trust rule is one of the highest-severity findings in a firewall audit because it means a compromised web server in the DMZ can pivot directly to internal systems without traversing an additional security boundary.

East-west traffic deserves scrutiny. Many organizations implement strong north-south controls (perimeter rules) while leaving east-west traffic — server to server, segment to segment within the internal network — largely unrestricted. This is where ransomware spreads. If your firewall handles internal segmentation, check that high-value segments (finance, HR, domain controllers) are not accessible from general workstation segments without explicit rules.

Management access should come from dedicated management addresses only. A rule permitting SSH or HTTPS management access from any internal source means any compromised workstation can attempt to authenticate to the firewall. Management plane access should be scoped to a management VLAN or specific jump host IPs, ideally with MFA enforced at the firewall level.

Map your zones against a reference model: external/WAN, DMZ, internal/LAN, server/data, management/OOB, VPN. Any rule that crosses these boundaries in the "wrong" direction (DMZ to internal, external to management, VPN to management without explicit justification) is a candidate finding.

Step 5 — Check Firmware and CVE Exposure

Firewall policy analysis covers configuration — what the rules allow. Firmware CVE analysis covers vulnerabilities — what an attacker can exploit before traffic even reaches your rules.

The most authoritative source for actively exploited vulnerabilities is the CISA Known Exploited Vulnerabilities (KEV) catalog. If your firewall's firmware version has a CVE listed in CISA KEV, treat it as a critical finding regardless of your internal CVSS scoring policies. KEV entries represent vulnerabilities that adversaries are actively using in real-world attacks, not theoretical risks.

Each vendor also publishes a PSIRT (Product Security Incident Response Team) advisory feed:

• Fortinet PSIRT: psirt.fortinet.com — advisories are versioned and map directly to FortiOS releases
• Palo Alto PSIRT: security.paloaltonetworks.com — pan-os advisories with affected version ranges
• Sophos Security Advisories: www.sophos.com/en-us/security-advisories
• Check Point Security Alerts: support.checkpoint.com/results/sk/sk167832

Cross-reference your firmware version against these feeds. Note that many firewall CVEs are only exploitable if specific features are enabled — SSL VPN, the web management interface exposed to the internet, specific protocols. A feature-aware assessment checks not just whether the CVE affects your version, but whether you have the vulnerable feature enabled. This avoids both false positives (flagging a CVE for a feature you don't use) and false negatives (dismissing a CVE because "we don't use that" when you actually do).

For each CVE finding, identify the minimum firmware version that patches it and document whether a safe upgrade path exists. On production infrastructure, firmware upgrades carry operational risk — you want to know the target version before planning the maintenance window, not during it.

Step 6 — Validate Security Profiles

Most enterprise firewalls are next-generation firewalls (NGFWs) — they don't just permit or deny traffic, they apply security profiles that inspect the traffic they allow. A firewall policy that permits traffic from the internet but applies no security profiles is functionally equivalent to a legacy stateful firewall: it lets traffic through and does nothing to inspect it.

For each internet-facing policy (rules with a source zone of external/WAN/untrusted), validate that the following profiles are applied:

SSL/TLS inspection deserves particular attention. Approximately 90% of modern malware uses encrypted channels for command-and-control and data exfiltration. A firewall without SSL inspection is blind to this traffic — it can see the metadata (source, destination, port) but not the payload. Without SSL inspection, your IPS, AV, and web filtering profiles are only examining the minority of traffic that isn't encrypted.

When auditing SSL inspection, distinguish between internet-facing policies and east-west policies. Requiring SSL inspection on all internal server-to-server traffic may introduce unacceptable latency or break certificate pinning. The highest-value targets for SSL inspection are outbound web traffic from workstations and inbound HTTPS to DMZ services.

Profile assignment is not enough — also check profile quality. An IPS profile in detection-only mode doesn't block anything. An AV profile with only file scanning (no stream inspection) misses malware delivered in real-time streams. Verify that profiles are set to block, not just detect, for high-severity signatures.

Step 7 — Document Findings and Generate Remediation

An audit produces findings. Findings without remediation guidance are academic exercises. The output of a firewall audit should be a structured document that a network engineer can work from directly — specific findings, risk context, and vendor-specific CLI commands to fix each one.

Structure each finding with the following fields:

• ✓ Finding ID — unique reference for tracking and communication
• ✓ Severity — critical / high / medium / low / informational
• ✓ Affected rule or component — policy name, rule number, firmware version
• ✓ Description — what the misconfiguration is and why it's a problem
• ✓ Evidence — the relevant config excerpt or rule text that demonstrates the finding
• ✓ Remediation — specific steps and CLI commands to fix it
• ✓ Compliance reference — relevant CIS Benchmark control, PCI-DSS requirement, or NIST CSF function

For FortiGate, remediation commands look like this for a shadow rule finding:

For compliance audits, generate an evidence package that includes the config export (with integrity hash), the list of findings with severity classifications, and a mapping of findings to control requirements. This package becomes the artifact your auditor reviews — having it structured and reproducible means audit cycles are a matter of running the analysis, not manually assembling spreadsheets.

Prioritize remediation by risk. Not all findings can be fixed in the same maintenance window. A shadow rule on a low-traffic internal segment is lower priority than a missing IPS profile on an internet-facing policy. Sort findings by severity and address critical findings — those with active CVE exposure or ANY/ANY rules on internet-facing zones — first.

Manual vs Automated Auditing

A manual firewall audit of a single device — one engineer, structured methodology, no tooling — takes between two and five days depending on rule base size and complexity. That timeline assumes the engineer has deep familiarity with the vendor's configuration format. Cross-vendor audits (a mixed environment with FortiGate, Palo Alto, and Sophos devices) multiply the time because the format, terminology, and risk context differ across platforms.

Manual audits also have a consistency problem. Two engineers auditing the same firewall will produce different findings lists. Coverage depends on individual expertise and attention — shadow rule detection is tedious enough that manual analysis reliably misses instances in large rule bases.

Automated analysis addresses both problems. A consistent analysis engine applies the same checks to every policy, every zone, every profile — regardless of rule count. It catches shadow rules through exact algorithmic comparison rather than manual inspection. It cross-references firmware versions against CVE databases in real time rather than requiring the auditor to maintain that knowledge themselves.

The trade-off is context. A manual audit performed by an engineer who understands your environment will catch business logic misconfigurations — a rule that's technically correct but wrong for your architecture — that automated tools miss. The most effective approach combines both: automated analysis to achieve consistent, comprehensive coverage, with human review focused on findings that require business context to interpret.

For compliance-driven audits (PCI-DSS 1.3, CIS Benchmark, ISO 27001 A.13), frequency matters as much as depth. Quarterly manual audits may satisfy a compliance requirement but leave months of exposure between reviews. Automated analysis can run on a scheduled basis — weekly or after every config change — and flag regressions before they accumulate into a systemic problem.

Frequently Asked Questions

What is the difference between a firewall audit and a penetration test?

A firewall audit is a configuration review — it analyzes what your firewall is configured to allow and block, and identifies misconfigurations that create risk. No traffic is generated, no systems are attacked. A penetration test actively attempts to exploit vulnerabilities to demonstrate what an attacker could achieve. The two are complementary: a firewall audit identifies the configuration gaps; a penetration test validates whether those gaps are actually exploitable given your full defense stack. Firewall audits run quarterly and after significant changes. Penetration tests typically run annually.

How long does a manual firewall audit take?

A single-device manual audit takes two to five business days for an experienced network security engineer. The range depends on rule base size (50 rules vs. 500), vendor complexity (Palo Alto XML configs are more structured than Fortinet text configs), and the depth of documentation required. Multi-device environments — a typical mid-market organization might have three to eight firewalls — multiply that timeline. Automated tools reduce this to minutes for the analysis phase, with human review time proportional to finding count.

What are the most common firewall misconfigurations?

Based on analysis of real-world firewall configs, the most prevalent findings are: missing IPS profiles on internet-facing policies (present in roughly 60% of audited configs), overly broad source or destination ranges in allow rules (40%), missing SSL/TLS inspection on outbound web traffic (55%), shadow rules that silently override intended security controls (30%), and management access permitted from general user segments rather than dedicated management networks (45%). Firmware CVE exposure — running a version with known exploited vulnerabilities — is present in approximately 35% of production firewalls at any given time.

Can you audit a firewall without network downtime?

Yes. A firewall audit is a read-only process — you export the configuration and analyze it offline. No changes are made to the running firewall during the audit itself. Config export takes seconds on any major vendor platform and has no impact on traffic. The remediation phase, where you implement changes based on findings, does carry change management risk and should follow your standard maintenance window process. Critical security fixes (actively exploited CVEs, ANY/ANY internet-facing rules) may warrant expedited change procedures rather than waiting for the next scheduled maintenance window.

What should a firewall audit report include?

A complete firewall audit report should include: an executive summary with overall risk posture and a count of findings by severity; a detailed finding list with severity, affected component, evidence (the relevant config text), and vendor-specific remediation commands; a firmware assessment with current version, applicable CVEs, and recommended upgrade target; a zone segmentation assessment; a security profile coverage analysis; a compliance mapping to relevant frameworks (PCI-DSS, CIS Benchmark, ISO 27001); and an integrity-verified config export as an appendix for audit evidence purposes. The report should be reproducible — running the same analysis against the same config should produce the same findings, so auditors can verify the evidence.