5 Firewall Misconfigurations That Lead to Real Breaches

The majority of ransomware incidents don't begin with a zero-day exploit. They begin with a firewall policy that nobody cleaned up after an emergency change three years ago. According to breach investigation data, misconfigured network controls — not novel vulnerabilities — remain the most common initial access vector across SMB and mid-market environments.

The problem isn't that organizations don't care about firewall hygiene. It's that firewall configurations accumulate complexity silently. Rules added for a one-time project stay active indefinitely. A temporary ANY/ANY policy opened during an outage never gets reverted. An admin interface left reachable from the internet "just for this week" becomes permanent. Over time, the gap between what you believe your firewall enforces and what it actually permits grows — invisibly.

What follows are five misconfiguration patterns that appear consistently in real firewall audits. They're not theoretical. They're the findings that show up in configs from organizations that believe their perimeter is locked down.

1 — ANY/ANY Policies Left Open After Emergency Changes

ANY/ANY rules — policies that permit all source addresses, all destinations, and all services — are sometimes the fastest way to restore connectivity during an incident. A link goes down, a critical application stops working, and the fastest path to resolution is a broad permit rule followed by a promise to tighten it later.

Later rarely comes. The application works, the incident is closed, and the ANY/ANY rule sits quietly in the policy table. In environments with high change velocity, these rules accumulate. It's not uncommon to audit a firewall with 200+ policies and find five or six broad permits that no one can attribute to a current business requirement.

The risk is lateral movement and data exfiltration. An attacker who establishes a foothold anywhere in the network — via phishing, a compromised credential, or a vulnerable service — can traverse segments freely if ANY/ANY rules are present between zones. The firewall that was supposed to contain the blast radius does nothing.

On FortiGate, you can surface these directly from the CLI:

show firewall policy | grep -A5 "set srcaddr.*all"

Any policy where both srcaddr and dstaddr resolve to "all" should be treated as a finding requiring justification. If no justification exists, the rule should be removed or constrained.

2 — Management Interface Exposed to the Internet

Administrative interfaces — SSH on port 22, HTTPS on port 443 or 8443, SNMP — accessible directly from the WAN interface are a persistent problem. The reasons are usually legitimate: a contractor needs remote access for a maintenance window, a small organization doesn't have a VPN, or the firewall itself is the only device with a public IP and there's no obvious alternative path for management.

The exposure is severe. CVE-2024-21762, a critical authentication bypass in FortiOS SSL-VPN and administrative interfaces, was actively exploited in the wild within days of disclosure. The affected organizations weren't running ancient software — they were running supported versions with management exposed to the internet. Patch cadence doesn't help if the attack surface is this broad.

"Trusted hosts" configuration — restricting management access to specific source IP ranges — reduces risk but doesn't eliminate it. IP allowlists protect against opportunistic scanning but don't defend against an attacker who has already compromised a host in the allowed range, or against future CVEs in the management stack itself. The only configuration that substantially reduces this risk is moving management traffic off the internet entirely, behind a VPN gateway.

In practice, this means: management interfaces should bind to a dedicated management interface or loopback, not the WAN interface. Access should require a VPN tunnel to reach the management plane. If VPN isn't operationally feasible, trusted hosts should be configured as a compensating control, not a primary defense.

3 — Missing Security Profiles on Internet-Facing Rules

A firewall policy that permits traffic from the internet to an internal resource without IPS, antivirus, or SSL inspection applied is doing network access control — but not security inspection. The distinction matters: the policy allows the connection, but nothing is analyzing the payload for malicious content.

The blind spot compounds when traffic is encrypted. In environments where SSL/TLS inspection is not deployed, HTTPS traffic — which accounts for the large majority of web traffic — passes through completely uninspected. IPS signatures, AV scanning, and web filtering operate on plaintext. Encrypted payloads bypass all of them.

The combined risk is higher than either issue alone. A permissive internet-facing policy with no security profiles and no SSL inspection creates a path where an attacker can deliver malware, establish command-and-control, and exfiltrate data entirely within encrypted channels that the firewall logs show as legitimate HTTPS traffic. From the firewall's perspective, everything looks normal.

Remediation requires two parallel workstreams: profile assignment (every internet-facing policy should have IPS and AV profiles applied as a minimum) and SSL inspection deployment (which introduces its own operational complexity around certificate management and application compatibility, but is necessary for meaningful visibility).

4 — Stale VPN Configurations with Weak Crypto

IKEv1 aggressive mode, DES and 3DES encryption, MD5 authentication, and pre-shared key (PSK) only authentication — these are cryptographic configurations that were deprecated years ago and remain present in production VPN tunnels because the tunnels "still work."

Legacy tunnels accumulate for understandable reasons: a partner organization hasn't upgraded their endpoint, a branch office runs hardware that doesn't support IKEv2, or the tunnel was configured by a contractor who is no longer available and no one wants to risk disrupting the connection. The result is a VPN estate where modern tunnels use AES-256 and certificate authentication, and three tunnels from 2016 use 3DES and a PSK that hasn't changed since initial deployment.

The cryptographic risk is real but often overstated in practice — breaking 3DES requires non-trivial resources. The more immediate compliance risk is concrete: PCI DSS 4.0 explicitly prohibits DES, 3DES, and RC4. NIST SP 800-131A designates DES and 3DES as disallowed for new applications, with 3DES deprecated entirely as of 2023. An organization that believes it's PCI compliant but has a 3DES tunnel in its VPN configuration has a compliance gap that auditors will find.

IKEv1 aggressive mode carries a separate risk: it transmits the PSK hash in cleartext during negotiation, making offline dictionary attacks feasible against weak pre-shared keys. For tunnels using common or default PSKs, this is a practical attack path, not a theoretical one.

5 — Shadow Rules That Mask Real Traffic Patterns

A shadow rule is a firewall policy that makes one or more other policies unreachable. Because firewalls evaluate rules in order — top to bottom, first match wins — a higher-priority rule that matches the same traffic as a lower rule means the lower rule never evaluates. The lower rule exists in the configuration but has no effect on actual traffic.

Shadow rules accumulate over years of policy changes. An organization adds a broad permit rule for a project, then later adds a specific deny rule for a subset of that traffic — but adds the deny below the broad permit. The deny rule looks correct in isolation. In context, traffic never reaches it. The security control that the team believes is enforced is not enforced.

This is the specific danger: shadow rules create a false sense of security. A security engineer reviewing the policy table sees a deny rule blocking traffic from a sensitive segment to a critical server. They conclude that path is protected. It isn't. The broad permit above it matches first. Without analyzing rule ordering and traffic intersection, the misconfiguration is invisible.

Detection requires policy analysis tools that evaluate rules in sequence and flag cases where a policy's traffic set is fully subsumed by higher-priority policies. Manual review of large policy tables — 300, 500, 800 rules — doesn't reliably catch this. It requires automated analysis.

How Attack Path Analysis Connects the Dots

The five findings above are each significant in isolation. What makes them dangerous in practice is how they combine. A single finding is a risk. Multiple findings on the same firewall create compound risk that is greater than the sum of its parts.

Consider this example: a FortiGate with a permissive ANY/ANY rule between the DMZ and internal segments (finding 1), no IPS or AV profiles on internet-facing policies (finding 3), and the management HTTPS interface accessible from the WAN (finding 2). In isolation, each finding has a severity rating. In combination, they describe a complete exfiltration path:

• → Attacker exploits a public-facing service in the DMZ (no IPS to block the payload over encrypted HTTPS)
• → From the compromised DMZ host, pivots to internal network via the ANY/ANY rule
• → Accesses the management interface from the internal segment, establishes persistent access with admin credentials
• → Exfiltrates data outbound over encrypted channels — invisible to a firewall with no SSL inspection

Attack path analysis maps these compound risk chains automatically. Instead of reviewing 200 findings and trying to mentally correlate which ones combine into actual attack paths, you get a ranked list of multi-hop paths — the routes through your network that an attacker could traverse given your current configuration.

The output changes remediation prioritization. A finding that appears moderate in isolation may move to critical when it's identified as a required hop in five different attack paths. A finding that looks severe may have no viable attack path connecting to it from the internet. Remediation effort should follow actual exposure, not raw severity scores.

FAQ

What percentage of breaches involve firewall misconfigurations?

Exact figures vary by source and methodology, but industry breach investigation data consistently places misconfigured network controls among the top three initial access vectors. Verizon's annual Data Breach Investigations Report has attributed a significant share of intrusions to "misconfiguration" as a contributing action for several consecutive years. The more relevant framing for practitioners: in environments where a breach occurred, post-incident analysis routinely finds firewall misconfigurations that, if corrected, would have contained or blocked the attack — even when the initial access vector was something else entirely.

What is a shadow firewall rule?

A shadow rule is a firewall policy that is unreachable because a higher-priority rule in the same policy table already matches all traffic that would reach it. Firewalls evaluate rules in sequential order — first match wins. If rule 50 permits traffic from subnet A to subnet B on port 443, and rule 75 denies traffic from subnet A to a specific server in subnet B on port 443, rule 75 never executes — traffic matches rule 50 first and is permitted. Rule 75 is "shadowed." It appears in the configuration and in compliance documentation, but it has no effect on actual traffic flow.

How does attack path analysis differ from a vulnerability scan?

A vulnerability scan identifies weaknesses in individual systems — missing patches, exposed services, weak credentials. It operates host by host or service by service. Attack path analysis operates at the network level: given your current firewall policies, routing configuration, and zone topology, what routes can an attacker traverse from an external network to a critical internal asset? It's the difference between knowing that a server has an unpatched vulnerability and knowing whether an attacker can actually reach that server given your network controls. Both are necessary. A vulnerability in a server that no firewall policy permits traffic to reach is a lower priority than a moderate vulnerability in a server with permissive inbound rules and no security profiles applied.

Can misconfigured firewall rules cause false PCI DSS compliance?

Yes. PCI DSS requires documented justification for all firewall rules, prohibition of ANY/ANY rules, restriction of inbound and outbound traffic to what is necessary, and regular review of firewall rule sets. An organization can have a Qualified Security Assessor sign off on a policy review without a detailed technical analysis of the actual rule behavior. Shadow rules are a specific example: a deny rule protecting cardholder data that is shadowed by a higher-priority permit rule will appear compliant in a rule-table review but provides no actual protection. Automated policy analysis that evaluates rule ordering and traffic intersection is necessary to verify that the policy table matches the intended security model.

How do I check if my firewall firmware has known CVEs?

Start with your vendor's PSIRT (Product Security Incident Response Team) feed — Fortinet, Palo Alto, Sophos, and Check Point all publish machine-readable advisory feeds. Cross-reference your running firmware version against the affected version ranges in current advisories. For FortiOS, the Fortinet PSIRT portal at psirt.fortinet.com publishes advisories with affected version ranges and fixed version targets. The CISA Known Exploited Vulnerabilities catalog is a useful secondary reference — any CVE listed there is being actively exploited in the wild and should be treated as urgent regardless of your internal risk tolerance. CRWLR performs this cross-reference automatically as part of a config scan: it extracts the firmware version from the configuration file and matches it against current CISA KEV, NVD, and vendor PSIRT feeds to surface applicable CVEs with feature-aware filtering — it only flags a CVE if the vulnerable feature is actually enabled in your configuration.