FortiGate firewall policy assessment

What the assessment is

MagenX reads every FortiGate under a FortiManager through the FortiManager API with a read-only profile: the policy packages and the devices they are installed on, the address objects, groups, services and virtual IPs, each device's interfaces, zones and static routes, and the live routing table, which is the only place an OSPF or BGP estate's subnets exist. From that it answers the questions a rule base is bad at answering about itself: which rules are permissive, which are shadowed, what the internet can reach, what the DMZ can reach on the inside, and whether a web service is behind the WAF or beside it.

The 48 firewall checks, the 7 attack-path checks, and the checks for segments, shadow rules and cross-zone risk are the ones that raise findings. Under them sits the reachability engine, which every other layer uses to ask whether a packet is permitted, and which is described on its own page.

Evaluated the way FortiOS evaluates it

A FortiGate decides a session in a fixed order, and an analysis that gets the order wrong produces answers that look reasonable and are wrong. The packet arrives on an ingress interface. A route lookup on the destination picks the egress interface before any policy is consulted. Only policies whose source interface includes the ingress and whose destination interface includes the egress are candidates. Within those, the first match in sequence order wins, and the device does not look for a better or more specific match further down. No match is the implicit deny.

The single most common mistake in firewall analysis is to prefer the most specific rule. An any-to-any accept at sequence three beats a precise deny at sequence forty-one, every time. MagenX computes specificity as explanation and never as the decision: the useful sentence is "permitted by a broad rule at sequence 3; the specific rule meant to control it sits at sequence 41 and never runs". That sentence is the finding.

What is examined

Permissive rules: any source, any destination, any service, or all three, with the interface pair they apply to
Shadowed rules: an allow rule that can never match because an earlier allow rule already covers all of its traffic, usually a control somebody believes is in force. Partial overlap is normal in any rule base and is not reported as shadowing
Disabled rules, shown and never allowed to decide, because an operator asking why something is blocked needs to see the disabled permit; rules by age; permit rules that log nothing, and where each firewall sends its logs
Services published to the internet through virtual IPs and port forwards, with the rule that publishes each one, the source restriction on it, and the inspection profile it carries
A private address in a public column is reported as private, and an external address on a private WAN is told apart from an internet address, everywhere either is shown
Web services published around their WAF: one rule sends the service through a WAF profile while another opens the same service to any source. The finding names every open rule to close
Rules from the DMZ into the LAN, with the machines on both ends resolved by name from the address objects, using the device's own interface roles rather than a guess from the interface name
VPN and site-to-site links and the networks they join, the WAN exposure map placed by each firewall's own coordinates, and the address objects whose meaning cannot be evaluated from configuration, FQDN, geography and fabric connectors, declared as such rather than guessed

Matching, exactly

A subnet object matches by prefix containment, so 10.7.0.0/16 matches 10.7.13.2. Address groups match if any member matches, and nesting is followed. A virtual IP is matched against its external address while the traffic is delivered to the mapped internal one, so a destination NAT changes what the destination means mid-path, and MagenX carries both. A zone matches any member interface, and an interface name that is not in the inventory is not treated as a zone. Names are matched case-insensitively and interface lists are split on commas and semicolons only, because interface names contain spaces.

Several firewalls, one path

When the endpoints sit behind different devices the traffic crosses both, and either can deny independently. MagenX walks the path rather than choosing both ends: the source firewall is the device holding the most specific local entry for the source; from there the most specific route for the destination gives a gateway, the firewall whose interface holds that address is the next hop, and the walk ends where the destination is local. Interfaces are resolved per device, because the same subnet reaches one firewall on port3 and the next on port7, and the ingress interface at each hop is derived from the gateway it was entered on. A route with a gateway says a device can forward there; only a local entry says the subnet lives there, and on a flooded OSPF estate where thirty firewalls carry every prefix, ownership is the only thing that discriminates.

A firewall the scan never read is never counted as a control that is holding. An unreachable FortiManager lends no protection to the score; its absence is stated on the page.

What configuration analysis cannot decide, said out loud

Policy routes and SD-WAN can change the path, source NAT changes the address the next hop sees, an accept rule with an intrusion prevention or web filter profile can still drop a session, and a schedule only applies inside its window. MagenX states each of these on the verdict, and the verdict always reads "permitted by policy", never "reachable". The machine's own firewall is the one limit MagenX has lifted: where CrowdStrike Falcon manages a host's firewall policy, the same packet is checked against it as the last hop.

What it does not do

It sends no test traffic through the firewall and changes no policy. It reads FortiManager with a read-only profile, plus any FortiGate you add directly with an API token. It does not read traffic logs, so "a rule that carries no traffic" refers to the hit counter FortiManager reports, and a counter that could not be read is reported as unread, never as dead. Vendors other than Fortinet are not read.

FAQ

Does this cover more than one firewall?

Yes. Policy is collected for every firewall under the FortiManager, and a path that crosses several devices is walked hop by hop, with the deciding rule on each device shown. Estates of thirty and more firewalls running OSPF are the shape the engine was built on.

Does it need access to the firewalls themselves?

No. Everything comes through the FortiManager API with a read-only administrator profile, including each device's live routing table. You can also add a FortiGate directly with an API token.

Why does the report show a rule further down the list than the one that decided?

Because the most common argument with a firewall administrator is "there is a permit further down". MagenX shows the deciding rule and every rule that would have matched below it, each labelled with how specifically it matched, so a broad-rule permit is visible as one.

What is a WAF bypass gap?

A web service that one rule publishes through a WAF profile and another rule publishes to any source without it. The WAF is decorative in that arrangement. MagenX names the open rule to close, and the verdict is computed by one deterministic function that a build gate runs on a fixed case before every release.

Can this run on an isolated network?

Yes. MagenX installs on a server inside your network and reads FortiManager from there, so the full firewall assessment runs on an estate with no internet access.