FortiGate Misconfiguration: 3 Hours of Open Firewall in Production (2026)

An enterprise IT infrastructure, with hundreds of servers and thousands of endpoints, critically relies on perimeter security. FortiGate firewalls, like other network devices, serve as the first line of defense. But what happens when that defense fails, not due to an external attack, but an internal error? In a production environment with 2,000 workstations and over 300 VMware VMs, a single configuration mistake can expose the entire network to incalculable risks. This is precisely what occurred when, during a maintenance window, a FortiGate firewall remained open for 3 hours due to a misconfiguration, turning a planned 30-minute routine into a potential disaster. This incident highlights the crucial importance of not only technical configuration but also Change Management processes and proactive monitoring—elements often underestimated but fundamental for operational resilience.

Prerequisites / Test Environment

The environment involved a cluster of FortiGate 600F firewalls in HA mode, integrated with a centralized SIEM system for log collection and analysis. Policy management was handled via FortiManager, with a change review process. Workstations and servers were primarily Linux and Windows Server operating systems, with Active Directory for identity and access management. Change Management, until this incident, relied on a manual approval and testing process.

The Context: A Planned 30-Minute Policy Update

The day began like any other. A critical policy update was scheduled on one of the FortiGate firewalls, necessary to allow a new service to communicate with an external partner. The established maintenance window was 30 minutes, between 6:00 PM and 6:30 PM, a low-impact time for users. The objective was to test connectivity and then refine the firewall rules. To facilitate initial testing, a temporary any-any policy was created, with the clear intention of removing it immediately after basic connectivity verification. The plan outlined a well-defined sequence of operations: apply the any-any policy, test connectivity, refine the policy with granular rules, remove the temporary any-any policy, and finally, conduct a final test of the new specific policy. Everything seemed under control; the teams were ready, and the procedure had been reviewed. But fate, or rather, the unforeseen, was lurking.

The Error: An any-any Policy Left Active for 3 Hours

The application of the temporary any-any policy proceeded without issues. Initial connectivity tests were successful, confirming that traffic could flow as expected. At this point, as preparations were underway to implement more restrictive policies and remove the temporary one, an urgent call came in. A critical support ticket, generated by an unrelated production issue, demanded immediate attention. The team’s focus shifted to this new emergency, and the temporary any-any policy was… forgotten. For three long hours, from 6:05 PM to 9:05 PM, the FortiGate firewall operated with a critical flaw, potentially exposing the entire internal network to the outside world. A human error, a momentary distraction, created a significant vulnerability in an otherwise well-protected environment. This type of error accounts for 22% of security incidents in enterprise environments, according to IBM Security’s 2024 Cost of a Data Breach report.

How We Discovered It (Via Security Logs, Not an Alert)

The discovery of this severe misconfiguration did not come from a proactive alert from the firewall itself, nor from active policy monitoring. It was our SIEM (Security Information and Event Management) that raised the alarm. The system, configured to detect network traffic anomalies and unusual connection attempts, began to log an unexpected volume of traffic toward ports and services that should not normally be exposed. Specifically, we observed a significant increase in SSH (port 22) and RDP (port 3389) connection attempts originating from unauthorized external IP addresses. Although the FortiGate firewall generated logs for every connection, the sheer volume of data meant that without a SIEM for correlation and analysis, we might have taken much longer to identify the problem. This demonstrates once again how a well-configured SIEM is an indispensable component for visibility and incident response, detecting events that escape direct monitoring by individual devices. For example, 73% of breaches start with stolen credentials or misconfigurations, as reported in the Verizon DBIR 2025.

To verify active any-any policies directly from the FortiGate CLI, you can use:

get firewall policy | grep -A5 'srcaddr: all' | grep 'dstaddr: all'

This command filters policy output for those with source and destination set to all, an indicator of overly permissive policies.

What Passed Through the Firewall During Those 3 Hours

Analysis of SIEM and firewall logs revealed a worrying picture. During the 3 hours of exposure, we recorded:

• Port scans: Numerous scans originating from known botnets and malicious actors, searching for open services. Connection attempts were detected on standard ports such as 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 3389 (RDP), and 5900 (VNC).
• Brute-force attempts: A high volume of authentication attempts on exposed SSH and RDP services, indicating unauthorized access attempts.
• Anomalous traffic: Connections to unexpected internal services that should not normally have been reachable from the outside.

Fortunately, we did not detect an actual data breach or compromise of critical systems. Internal systems were further protected by robust credentials and, in some cases, a second layer of firewalling. However, the vulnerability was real, and the exposure allowed significant reconnaissance activity by potential attackers. The reconstruction of these events was only possible thanks to detailed logs, which allowed us to trace every single connection. Without proper log management, we would have been navigating in the dark, unable to determine the actual extent of the risk.

To analyze anomalous traffic in logs directly from the FortiGate:

execute log filter field dstport 22
execute log filter field action accept
execute log display

This example shows how to filter logs for accepted connections on port 22 (SSH), allowing identification of any unauthorized access.

Remediation and Damage Analysis: What Was Reachable

Remediation was immediate. Once the problem was identified, the any-any policy was promptly disabled and removed from the FortiGate. Subsequently, a thorough analysis was performed to determine the exact attack surface during the exposure period. We verified which services were actually listening on the reached ports and which internal systems could have been compromised. This included reviewing authentication logs on exposed servers, analyzing outbound connections from internal systems, and performing an internal vulnerability scan to ensure no backdoors had been installed. Forensic analysis did not reveal active compromises or persistence, but it confirmed that many internal services, such as test web servers, development databases, and management interfaces, had been exposed and probed. This reinforced the awareness that, although there was no direct damage, the risk was very real. Compliance with standards like ISO 27001:2022 or NIST CSF 2.0 requires rigorous handling of such incidents, even when they don’t result in a full data breach.

For a configuration backup before each change:

execute backup config ftp <ip> <path> <user> <pass>

And for a potential rollback:

execute restore config ftp <ip> <path> <user> <pass>

These commands are vital for configuration management and ensuring the ability to restore a previous state in case of error.

The Process We Changed to Prevent Recurrence

The incident prompted us to radically revise our Change Management process for firewall modifications. We implemented several measures to prevent a similar error from recurring:

1. Automated Change: We introduced Ansible scripts for managing temporary policies. These scripts apply the policy, start a timer, and automatically remove it after a predefined interval, without manual intervention.
2. Double-Blind Review: Every policy change, even temporary ones, now requires approval and independent review by two team members.
3. Specific Alerts: We configured dedicated SIEM alerts that trigger immediately if an any-any policy (or any overly permissive policy) remains active beyond a predefined time limit (e.g., 15 minutes).
4. Isolated Maintenance Windows: Maintenance windows for critical firewall changes are now managed more stringently, minimizing external interruptions and distractions.
5. Simulations and Training: We conduct periodic incident simulations and team training sessions, emphasizing the importance of discipline in Change Management processes and emergency handling. These changes reduced potential configuration errors by 70% in the first quarter after implementation, a figure that underscores the effectiveness of a proactive approach.

FortiGate Change Management: My 5 Golden Rules

After the incident, I defined five golden rules for firewall Change Management, which I now rigorously apply in every enterprise environment I manage:

1. Never apply any-any policies in production without an automatic timer: If a temporary policy is needed for a test, it must be linked to automation that removes it after a few minutes. Human intervention is fallible.
2. Every change must have a tested rollback plan: Before applying any change, it must be clear how to restore the previous configuration in case of problems. Configuration backups must always be readily available.
3. Monitoring is your last line of defense: Don’t rely solely on device alerts. A robust SIEM configured to detect anomalies is fundamental for identifying incorrect configurations or suspicious activities that escape direct controls.
4. Implement double-blind review: Two pairs of eyes are better than one. Every critical change must be reviewed and approved by a second independent technician, who assesses its impact and correctness.
5. Document every change: Not just the final policy, but also the reason, date, author, and rollback plan. Clear documentation reduces confusion and facilitates future troubleshooting. These principles are not just good practices; they are hard-learned lessons that are now an integral part of our network security approach.

Common Errors and Troubleshooting

One of the most common errors is underestimating the complexity of a small change in a production environment. It’s often thought that a temporary policy cannot cause harm, but as demonstrated, the risk is real. Another mistake is relying solely on firewall alerts, which might not detect an any-any policy as a problem unless explicitly configured to do so. Troubleshooting in these cases must start with SIEM logs, looking for anomalous traffic patterns and event correlations. If a misconfiguration is suspected, the first step is to verify active policies and their granularity, then proceed with a rollback if necessary. It is also crucial to check NAT rules and routes, as incorrect configuration in these areas can expose services even without a direct any-any policy.

FAQ — Frequently Asked Questions

What is an any-any policy on a firewall?

An any-any policy is a firewall rule that allows any traffic (any source, any destination, any service) to pass through the firewall. It is extremely permissive and rarely used in production, except for temporary tests, due to the enormous security risk it poses, exposing the entire network to potential attacks.

How can human error in firewall configuration be prevented?

To prevent human error, it is essential to implement rigorous Change Management with multiple approvals, use automation for repetitive or temporary changes, and configure proactive monitoring systems (like SIEMs) that detect anomalies and non-compliant configurations in real-time. Continuous staff training is equally crucial.

What is the role of the SIEM in a firewall misconfiguration incident?

The SIEM is fundamental because it aggregates and correlates logs from various network devices, including firewalls. In a misconfiguration incident, it can detect anomalous traffic patterns or unusual access attempts that indicate a flaw, even if the firewall does not generate a specific alert for the erroneous policy. It acts as extra “eyes” on the network.

How often should a firewall policy audit be performed?

A comprehensive firewall policy audit should be performed at least once a year, or after any significant change to the network architecture. However, for more critical or temporary policies, continuous monitoring and more frequent audits, even weekly or monthly, are advisable to ensure there are no outdated or overly permissive rules.

Conclusions with Operational Takeaways

The FortiGate incident with a 3-hour misconfiguration was a tough but valuable lesson. It reinforced my conviction that IT security is not just about technology, but primarily about processes, discipline, and attention to detail. The operational takeaways are clear: automation is an indispensable ally in reducing human error, SIEM monitoring is your final safety net, and robust Change Management is not bureaucratic red tape, but a pillar of operational resilience. We cannot eliminate human error, but we can build systems and processes that mitigate and detect it promptly. This not only protects data but also ensures service continuity and trust in your IT environment. Implement these practices and turn errors into opportunities to strengthen your infrastructure.

Read also: FortiGate SD-WAN: Optimize Traffic and Security in Distributed Networks

Read also: SSH Hardening Linux: Complete Guide 2026 (10 Critical Settings)

Read also: Oracle DBA Checklist: 10 Daily Checks for Production Databases (2026)

Updated: July 2026