☰   How to use this guide

A firewall review is mostly a white-box config audit (read the running config and rule base) backed by active verification (prove from the wire what the rules actually do). The value isn't a dump of rules — it's finding the overly-permissive, shadowed, unused and unlogged rules that quietly widen the attack surface, and confirming the architecture enforces real segmentation. This guide turns every review item into how-to-check, vendor-agnostic first, then per-vendor.

# Automated config audit (offline, on the exported config)
nipper --input=running-config.txt --output=fw-report.html      # titania nipper-ng
# Vendor best-practice assessments:  Palo Alto BPA/Expedition · FortiGate Security Rating
#                                     Cisco Firepower reports · Check Point SmartEvent
# Active verification of what the ruleset really allows (in-scope only):
nmap -sS -p- -Pn <host-behind-firewall>        # which ports actually pass
firewalk -S1-1024 -i eth0 <gateway> <target>   # ACL/filter mapping

0   Scope & information gathering

Collect everything before judging anything: the full config, the topology, the asset/zone inventory, and the business justification source (change tickets).

# Pull a complete running config (examples)
# Cisco ASA:    show running-config            (or 'more system:running-config')
# FortiGate:    show full-configuration
# Palo Alto:    set cli config-output-format set ; configure ; show   (or export XML)
# Check Point:  policy in SmartConsole / $FWDIR/conf/*.W ; show configuration (Gaia)
# pfSense:      Diagnostics > Backup (config.xml) ; or  pfctl -sr / pfctl -sn

Scope & information gathering — full coverage

1   Rule base / policy review

The heart of the review. Hunt for overly-permissive rules, dead weight (shadowed/redundant/unused/expired), and rules with no logging or justification.

Overly-permissive & risky rules

1. Flag any rule with any in source, destination or service — especially any→any and any rule permitting any service.
2. Flag overly-broad objects (large subnets, whole zones) where a host/small group is intended.
3. Flag permissive rules to/from the internet on sensitive ports (RDP 3389, SSH 22, SMB 445, DB 1433/3306/5432, mgmt).
4. Confirm each risky rule's real effect with nmap/packet-tracer, not just by reading it.

# Grep an exported config for the worst offenders (Cisco ASA example)
grep -iE 'permit .* any any|permit ip any any' running-config.txt
# FortiGate: rules with 'all' service or 'all' address
grep -iE 'set (srcaddr|dstaddr|service) .?all' fortigate.conf
# Palo Alto: any/any in security rules (review 'show running security-policy')
# Then verify what truly passes:
nmap -sS -p3389,22,445,1433,3306 -Pn <internal-host>

Dead weight — shadowed, redundant, unused, expired

Shadowed rules never match (a broader rule above them wins); redundant rules duplicate others; unused rules have zero hits; temporary rules outlive their purpose. All add risk and confusion.

# Hit counts reveal unused rules
# Cisco ASA:    show access-list  | include hitcnt=0
# FortiGate:    diagnose firewall iprope show  /  policy hit count in GUI
# Palo Alto:    show running rule-use rule-base security type unused vsys vsys1
# Check Point:  SmartConsole > Logs & Monitor > rule hit count
# Shadow/redundancy analysis: Nipper, or FireMon/Tufin/AlgoSec/Skybox in enterprise

Rule-base review — full coverage

2   Default policy & cleanup rule

Everything not explicitly allowed must be denied — and that final deny should be logged so you can see what's being dropped.

Default policy & cleanup rule — full coverage

3   NAT review

NAT rules quietly publish internal services. Review every static/destination NAT (port forward) for whether it should be exposed, and whether a matching tight security rule guards it.

# Cisco ASA:   show nat ; show xlate
# FortiGate:   show firewall vip ; show firewall policy (with VIP as dstaddr)
# Palo Alto:   show running nat-policy
# pfSense:     pfctl -sn   (NAT rules) ; Firewall > NAT

NAT review — full coverage

4   Segmentation & zoning

The architecture question: are trust zones (internet / DMZ / internal / management / PCI / OT) properly separated, and are inter-zone flows least-privilege? Verify by trying to cross zones.

1. Map every interface/zone and its trust level; confirm the DMZ can't freely reach internal.
2. Review inter-zone rules: each should be specific, not zone-wide any.
3. Verify by attempting reachability from each zone to the others (in scope).

# From a host in one zone, test reachability into another (in-scope verification)
nmap -sS -p 22,445,3389,1433,3306 -Pn <other-zone-host>
# Cisco ASA: confirm a specific flow's verdict precisely
packet-tracer input dmz tcp 10.1.1.5 1234 10.0.0.10 445

Segmentation & zoning — full coverage

5   Egress / outbound filtering

Outbound is the forgotten direction. Unrestricted egress lets malware exfiltrate and C2 phone home. The firewall should allowlist outbound, not permit any-out.

# Look for permissive outbound from internal/user zones
grep -iE 'permit .*inside.* any|permit ip <internal> any' running-config.txt
# Verify what can actually leave (in-scope egress test):
for p in 53 80 443 4444 8080 6667; do nc -zvw2 <external-ip> $p; done

Egress filtering — full coverage

6   Management plane & administrative access

How the firewall itself is administered. Management reachable from anywhere, weak/default creds, no MFA, cleartext protocols and no RBAC are the high-impact findings.

# Cisco ASA: who/where can manage, and how
show run | include ^(ssh|http|telnet|enable|username|aaa)
# FortiGate: admin access + trusthosts + protocols
grep -iE 'set (trusthost|allowaccess|admin-https|telnet)' fortigate.conf
# Flags: telnet/http (cleartext), management on untrusted iface, no trusthost ACL,
#        default/shared admin accounts, no MFA, SNMP community public/private

Management plane & admin access — full coverage

7   Device hardening & secure config

The device's own posture: firmware currency, secure services, time sync, banners and disabled junk. Map against the vendor CIS benchmark.

# Version + support/EoL status
# Cisco: show version   FortiGate: get system status   Palo Alto: show system info
# Benchmark the config against CIS:
#   CIS-CAT Pro (vendor benchmark)  or  Nipper's hardening section

Device hardening — full coverage

8   VPN review (site-to-site & remote access)

Site-to-site and remote-access VPNs terminating on the firewall: weak crypto (IKEv1/aggressive mode, DES/3DES/MD5), split tunneling, no MFA, and over-broad access once connected.

# Cisco ASA: review IKE/IPsec proposals + tunnel-groups
show run crypto ; show run | include (ikev1|ikev2|group-policy|split-tunnel)
# Flags: IKEv1 aggressive mode, DES/3DES/MD5/DH group 1-2, PSK reuse,
#        split-tunnel enabled, no MFA, VPN pool with any-any access

VPN review — full coverage

9   Logging, monitoring & alerting

Can the firewall tell you what happened? Logs going off-box, retained, and alerted-on for denies and config changes.

Logging, monitoring & alerting — full coverage

10   High availability & backup

Resilience and recoverability: HA pairing, config backups, and a tested restore path.

High availability & backup — full coverage

11   Change management & rule lifecycle

Governance: every rule should trace to a request, an owner and an approval, and the rule base should be reviewed on a cadence (PCI-DSS requires at least every 6 months).

Change management & rule lifecycle — full coverage

12   Advanced threat prevention (NGFW)

On a next-gen firewall, the L3/L4 rules are only half the story. Review whether IPS, application control, URL filtering, TLS inspection, threat intel and geo-blocking are enabled and tuned — profiles attached to rules, not just licensed.

Advanced threat prevention — full coverage

A   Palo Alto (PAN-OS)

Palo Alto (PAN-OS): App-ID and the Best Practice Assessment do a lot of the work; watch for application-default vs any-service, unused rules, and decryption coverage.

show running security-policy
show running rule-use rule-base security type unused vsys vsys1   # unused rules
test security-policy-match from trust to untrust source 10.0.0.5 destination 8.8.8.8 \
  protocol 6 destination-port 443                                 # verify a flow
# Run Expedition / BPA against a tech-support file for a full best-practice report

Palo Alto (PAN-OS) — full coverage

B   Cisco ASA / Firepower (FTD)

Cisco ASA/Firepower (FTD): classic ACLs — check for permit ip any any, zero-hit ACEs, weak crypto and management exposure. packet-tracer is your verification tool.

show running-config
show access-list | include hitcnt=0          # unused ACEs
show run | include ^(http|ssh|telnet|enable|aaa|snmp-server)
packet-tracer input outside tcp 1.2.3.4 1234 10.0.0.10 443   # verify a flow

Cisco ASA / Firepower (FTD) — full coverage

C   FortiGate (FortiOS)

FortiGate (FortiOS): check for policies using all address/service, missing UTM/security profiles, broad trusthosts, and the built-in Security Rating.

get system status                                 # version
show full-configuration | grep -iE 'set (srcaddr|dstaddr|service) .?all'
diagnose firewall iprope show                      # policy/hit info
# Run the GUI 'Security Rating' (Security Fabric) for a best-practice score

FortiGate (FortiOS) — full coverage

D   Check Point

Check Point: layered policy — check for an Any/Any/Accept rule, missing cleanup rule, disabled logging (track=None), and rule hit counts in SmartConsole.

Check Point — full coverage

E   pfSense / OPNsense

pfSense/OPNsense: per-interface rules — check for allow-any rules, missing logging, default WebGUI exposure, and that outbound isn't wide open.

pfctl -sr            # show active filter rules
pfctl -sn            # show NAT rules
# Flags: 'pass ... from any to any', WebGUI on WAN, no rule logging, default creds

pfSense / OPNsense — full coverage

✓   Coverage map & how to run it

Work the universal sections (0–12) on every firewall review, then the vendor block. The rule-base review (§1) and segmentation (§4) carry the most risk; management/hardening (§6–7) carry the easiest criticals.

Core principle: a firewall review is config audit + active verification. Don't just read the rule base — prove from the wire what it actually permits (nmap/packet-tracer), and tie every finding to least privilege, segmentation impact and the rule's missing justification. Map results to PCI-DSS req 1, NIST 800-41 and the vendor CIS benchmark, and tick a box only when you've verified it.