Perimeter Firewalls: Strong Technology, Weak Defences
This article is part of a series unpacking the NSA and CISA’s Top Ten Cybersecurity Misconfigurations through the lens of real-world breaches and assessment findings.
This entry covers Misconfiguration 4: Lack of Network Segmentation, with a focus on perimeter firewalls. While most enterprises have invested in ‘next-generation firewalls’, the absence of careful configuration, disciplined rule management, and full use of available features leaves openings that adversaries repeatedly exploit.
TL;DR:
Perimeter firewalls in most enterprises start strong, but in a number of assessments I found organisations not getting the full value of what they paid for. Intrusion prevention left in monitor mode, SSL inspection not enabled, unnecessary outbound traffic, undocumented rules, lack of application-aware policies, IPv6 left open, exposed management planes, and unprotected VPN portals all compound risk. On their own these gaps may seem manageable, but together they create blind spots and pathways that attackers can exploit.
What’s Working at the Perimeter
Despite the recurring gaps I will get into later, most enterprises are not neglecting their firewalls. In fact, I’ve seen the majority of organisations invest in next-generation platforms like Palo Alto Networks, Fortinet, Cisco Firepower, or Check Point, and maintain a reasonably solid foundation. The basics are usually in place: implicit deny rules sit at the end of the rule base, teams at least attempt to apply least privilege when new rules are added, and most require a ticket or change request before making firewall modifications.
Those basics matter. A few examples stand out:
Implicit deny rules are now fairly common. They often come by default on modern platforms, and unlike a decade ago, I haven’t seen an organisation miss this control in recent years.
Ticketing or change request processes reduce the risk of unauthorised or rapid changes that could introduce unnecessary exposure.
Many firewall teams do attempt to restrict traffic using the least privilege principle, and often question the need for holes to be poked in the firewall.
Intrusion prevention features are at least enabled in monitoring mode, and in most cases the logs are collected by a SIEM for later review.
Most organisations maintain a DMZ zone, keeping public-facing services separate from the WAN and LAN, which provides a clear buffer against direct exposure.
Firewall patch management is also common practice. Often driven by vulnerability remediation and the need to enable new features, it ensures most devices are not left running outdated or unsupported code.
The intent is there. These organisations are not ignoring their defences, and in many cases the foundation does provide deterrence against opportunistic scanning and low-skill attacks. The problem is not that the basics are missing, but that they rarely go far enough.
Where Perimeters Fall Short
These mini kill-chains visualise failure patterns I have observed in assessments. Not every environment had all of these, however any combination compounds risk and reduces the value of the firewall investment.
IDPS left in monitor-only mode
Blind alertingSuspicious traffic hits a DMZ web app. The IDPS detects an XSS attack but only logs it, it does not block the request. A SOC analyst may or may not respond in time if they are drowning in alerts.
SSL/TLS inspection disabled
Encrypted blind spotAn employee uploads a sensitive spreadsheet to Google Drive. With HTTPS inspection disabled the firewall cannot verify content. From a network perspective, staff cannot see that a sensitive file was uploaded.
SSH reverse shell over 443
Service mismatchTraffic allowed on TCP 443 is assumed to be HTTPS, but an attacker uses it for an SSH reverse shell, bypassing port-based rules.
Unnecessary outbound traffic from servers
C2 riskServers, including domain controllers, make generic outbound connections. If compromised, they can beacon to C2 and exfiltrate directly.
IPv6 left enabled, organisation does not use it
Policy bypassThe organisation does not support IPv6, yet it is enabled. IPv6 paths are not governed by the same controls, creating a blind spot.
Note: IPv6 not monitored, prevented, or utilised.
Management plane exposed to the internet
High impactFirewall management reachable from the internet. Example seen: https://panorama01.contoso.co.nz responding on standard ports.
Exposed VPN web portals, weak auth
Credential riskRemote access portals on the internet accept default or weak credentials. Attacker attempts admin/admin and pivots inside.
No user identification in policy
Identity blind spotA privileged user account connects from a laptop over the VPN to VMware ESXi via SSH. Allowed because policy is IP and port based, with no user identification enforcement. The path bypasses the approved jump box.
Jump box bypassed
Practical next steps: enable application‑aware policies, enforce server egress allowlists, apply parity to IPv6, restrict management and VPN portals, and add user identification to rules that touch privileged systems.
Practical Guidance: From Quick Wins to Hard Lifts
Start with the hygiene items that close obvious gaps. Then move through moderate improvements before tackling the hard lifts that require deeper planning and stakeholder buy-in.
| Control | Description | Effort |
|---|---|---|
| Secure firewall admin credentials | Ensure each firewall has unique, long, complex credentials. Store in a vault. Do not reuse even if using a management server (e.g., Panorama). | Easy |
| Enforce MFA on management plane | Require MFA for firewall administration, even from internal networks. | Easy |
| Remove IPv6 if unsupported | Disable IPv6 where not used to eliminate unmonitored blind spots. | Easy |
| Approval workflow and documentation | Require ticket-based approvals for changes. Document reasoning in the firewall tool itself using naming conventions, notes, and rule/object metadata. | Moderate |
| Lock down server egress | Prioritise critical infrastructure (Tier-0 such as domain controllers, certificate authorities) before broader server classes. Replace “any to internet” with explicit allowlists. | Moderate |
| Audit and enforce advanced features | Review modules such as intrusion prevention, vulnerability protection, malware prevention, URL filtering, DNS security. Begin by dropping malicious traffic flagged as critical, then expand to high and medium as tuning matures. | Moderate |
| Enforce user identification | Make user-ID a universal control, not just for privileged accounts. Use it to block high-risk flows such as direct privileged user access to backend systems without a jump box. | Moderate |
| Recertify and clean firewall rules | Periodically audit the rulebase for shadow rules, duplicates, and legacy entries. Remove or tighten what’s no longer required. | Moderate |
| Apply application-aware policies | Replace port-based rules with layer 7 application controls. Prevent mismatched services (e.g., SSH reverse shell over 443) from bypassing intent. Requires thorough discovery and tuning. | Hard |
| Deploy SSL/TLS inspection | Enable decryption and inspection for both inbound and outbound traffic. Start with outbound web traffic. The appliance should re-encrypt connections with its trusted certificate after inspection. | Hard |
Get in touch