FortiGate Firewall Policy Audit

Firewall policy review

FortiGate firewall policy audit checklist.

A practical checklist for reviewing broad rules, addresses, services, interfaces, duplicates, logging and deployment context.

A firewall policy audit is more useful when it checks intent, scope and configuration context—not just whether the syntax is valid. Use this checklist before approving a new FortiGate change or when reviewing an existing rule matrix.

1. Check for unnecessarily broad access

ANY source

Confirm that traffic really needs to originate from every possible source represented by the policy context.

ANY destination

A broad destination may be intentional, but it should be explicitly justified and reviewed.

ANY service / port

Prefer the minimum protocol and service set needed for the application whenever possible.

2. Validate addresses and networks

Check host addresses, CIDR masks and subnet boundaries. A network such as 10.10.1.25/24 contains host bits and can represent an operator mistake even if a parser can normalize it.

3. Review interfaces and policy direction

Verify the source and destination interfaces against the real routing path. A syntactically valid rule attached to the wrong interface pair can be ineffective or expose unintended traffic.

4. Look for duplicates and overlaps

Duplicate policies increase operational complexity. Partial overlaps deserve manual review because policy order can change which rule is actually matched first.

5. Inspect management and legacy services

SSH, Telnet, RDP, VNC and similar management services deserve additional scrutiny when exposed from broad or untrusted networks. Legacy clear-text services should be challenged whenever a safer protocol is available.

6. Check logging and security controls

Confirm the required logging behavior and review NAT, security profiles, schedules and other controls that are outside a simple source/destination/port matrix.

7. Compare against the live configuration

A proposed rule can reuse existing objects or collide with existing names. Policy IDs may also already be occupied. Use a recent configuration export when the change process allows it, and verify the target device again immediately before deployment.

8. Prepare rollback before deployment

A useful change plan includes a rollback that identifies exactly which new policies and objects will be removed. Rollback generation does not replace a device backup or a complete operational recovery procedure.

Use the tool

Run the DeepCodeAgent matrix audit

Upload an XLSX/CSV matrix, review validation findings and generate FortiGate CLI locally in your browser.

Open DeepCodeAgent

Quick audit checklist

  • No unexplained ANY → ANY access
  • Ports and protocols match application requirements
  • IPv4/CIDR values are valid
  • Interfaces match the intended routing path
  • Duplicates and overlaps have been reviewed
  • Remote-management exposure is justified
  • Logging requirements are confirmed
  • NAT and security profiles are reviewed separately
  • Existing objects and policy IDs have been checked
  • Rollback and post-change validation are prepared

Related resources