Firewall Rule Analyzer for iptables, nftables, pfSense, OPNsense, FortiGate, Cisco ASA and Palo Alto Networks

About the Firewall Rule Analyzer for iptables, nftables, pfSense, OPNsense, FortiGate, Cisco ASA and Palo Alto Networks

A firewall’s rule base grows with every change: a rule added for a project and never removed, a copy of an existing rule, a block placed under the allow that already lets the same traffic through, an address group nobody uses any more. Each one makes the next review longer and the next mistake easier.

Open the configuration here and the page reads every rule on your device into one model, whatever the firewall: iptables, nftables, pfSense and OPNsense, FortiGate, Cisco ASA and PAN-OS. It compares the rules of each list in the order the firewall checks them, and finds shadowed rules that never apply, redundant and duplicate rules, any-any and overly wide permits (remote administration and database ports open to everyone among them), unused objects, disabled rules left in place and rules that do not log. Each finding names the rules involved and suggests the tidy-up, and the summary gives the rule base before and after it. Nothing is uploaded.

Without a pass the whole configuration is read and every rule compared: every count and each table’s first findings show in the free preview. The full tables, the PDF report, the workbook and the CSV of every finding come with an Ultimate pass: a starting pack for your auditor.

Common uses

• Preparing an audit: a review of the rule base with what each rule does, ready for the auditor to work from.
• Cleaning up a firewall that several people changed over the years, with the rules and objects that can go.
• Checking a change before it goes live: does the new rule ever apply, or does an earlier one take its traffic?
• Taking over a firewall from a provider or a previous administrator, and seeing at once what it lets through.
• Regular rule base reviews, which NIST SP 800-41 Rev. 1 asks for, with the same checks every time.

What it reads

• iptables: the output of iptables-save and ip6tables-save (with or without the counters of -c, and both in one file), every table and chain, the chain policies, jumps to your own chains and the matches people use most (addresses, interfaces, protocols, ports, multiport, connection state, comments). A built-in chain’s policy decides when no rule does (iptables manual page).
• nftables: the output of nft list ruleset, with tables, base chains and their hooks and policies (accept unless set to drop, nftables wiki), named sets and defines.
• pfSense and OPNsense: config.xml backups, with each interface’s rules, floating rules, OPNsense’s automation rules and the aliases of both. Floating rules come first, and traffic entering an interface that no rule matches is blocked (pfSense, OPNsense).
• FortiGate: configuration backups and show output, with VDOMs, firewall policies in the order they are checked, addresses, services and their groups; traffic no policy matches is denied (Fortinet).
• Cisco ASA: the running configuration, with extended access lists, the objects, object groups and names they use, and the access-group that applies each list; entries are tested in order and an implicit deny ends each list (Cisco).
• PAN-OS: XML configurations of a firewall or of Panorama, with the security rules of each virtual system or device group, the shared pre- and post-rules, addresses, services and their groups; rules are evaluated from the top and the first match decides (Palo Alto Networks). A firewall’s own rules come between Panorama’s pre- and post-rules and are not in a Panorama export, so no rule is said to be redundant across them.

What it finds

• Shadowed rules: an earlier rule with another action matches every packet the rule matches, so it never applies. A shadowed block is the dangerous kind: the traffic it was meant to stop gets through.
• Redundant and duplicate rules: an earlier rule with the same action matches everything the rule matches (a duplicate when both match the same packets), or a later rule with the same action does and no rule between them decides otherwise. Removing it changes nothing.
• Any-any and overly wide permits: allow rules for every address and every service, for every service from or to any address, and remote administration and database ports (SSH, Remote Desktop, SMB, SQL Server, MySQL, PostgreSQL, Redis, MongoDB and others) open to any address; also chains whose own policy accepts what no rule decides.
• Unused objects: addresses, services, groups, aliases and sets nothing else in the configuration names.
• Disabled rules left in place, and rules that do not log, in the firewall’s own terms (an ASA entry without the log keyword, a FortiGate policy left at logtraffic utm, a PAN-OS rule with log at session end off).

Shadowing and redundancy are the classic anomalies of rule bases; deny by default, removing rules that are no longer needed and choosing what to log are the checks of NIST SP 800-41 Rev. 1, which also asks for the firewall policy to be reviewed often, with tools that look for redundant rules where they exist (section 5.5).

Before and after the clean-up

Every shadowed, redundant and disabled rule and every unused object is counted as one that can go: the summary gives the rule base as it is and as it would be without them. A shadowed rule may instead be an exception placed too low: then move it above the rule that takes its traffic, and keep it. The page never changes the firewall; make each change through your own change process, and keep the report with it.

A starting pack for your auditor

The PDF report names the configuration file and its SHA-256, lists the rule lists read and what happens to traffic no rule decides, gives every finding with the rules involved and the suggested tidy-up, and ends with the method and its limits. The workbook has a sheet for each kind of finding and every rule as read, so the review can go on in a spreadsheet. The report says what the configuration does; whether the rule base meets a standard or a policy is for your auditor to judge.

Large rule bases, and what the device needs

The configuration is read and compared in a background worker, so the page stays responsive. Within each list every rule is compared with the rules before and after it, quickly set aside where their addresses and ports cannot overlap. In tests on a recent laptop, a list of 20,000 rules was read and compared in about 5 seconds, using about 250 MB of memory; an older computer takes a few times longer. Files of up to 64 MB are read.

Limitations

• Only the configuration file is read: rules added from elsewhere (a management server, scripts run at start-up, another device) and the traffic itself are not seen.
• A rule covered only by several earlier rules together is not found, and conditions the page does not compare (connection state, rate limits, schedules, URL categories) make a rule narrower: a rule with one is never said to cover a rule without it.
• Names whose addresses the configuration does not give (FQDN objects, URL tables, dynamic groups, countries, applications) are compared by their name only; a rule with parts the page could not read is listed, never said to cover another.
• A finding is a lead for the review, not a verdict: a duplicate may be kept for its counters, and a wide permit may be the intended policy.
• Configuration files hold secrets (password hashes, pre-shared keys): the page reads them on your device and never uploads them, but keep the file and the reports with the same care.
• MySmartCoPilot is not affiliated with or endorsed by Netgate (pfSense), Deciso (OPNsense), Fortinet (FortiGate), Cisco (ASA), Palo Alto Networks (PAN-OS) or the netfilter project (iptables and nftables).

Privacy

On this device: nothing is sent

The configuration is read by your browser on your device; nothing from it is sent anywhere, and the page works offline once it has loaded. Firewall configurations describe your network and may hold secrets: keep the reports with the same care as the configuration.

How to check that nothing is uploaded