Firewalls are still the front door to most corporate networks and the fastest way to undermine them is a configuration that no longer matches reality.
Most security programmes run vulnerability scans and penetration tests. Useful, but they often miss a harder truth: a firewall can be “working” while still allowing the wrong traffic, from the wrong places, with the wrong visibility. That’s what makes firewall misconfiguration so dangerous, it’s usually not a single dramatic mistake.
It’s drift.
At Secon, we see the same pattern repeatedly: complexity grows, rulebases expand, exceptions pile up, and governance doesn’t keep up. The result is silent exposure that attackers can exploit quickly.
This post breaks down what firewall misconfiguration actually looks like, why it happens, and how to reduce the risk in practical terms.
What counts as a firewall misconfiguration?
A misconfiguration is any firewall setting that creates unnecessary risk or violates your organisation’s security intent, even if nothing is “broken”.
Common examples include:
- Overly permissive rules (the classic “any/any” problem)
- Inbound services exposed more broadly than intended
- Management interfaces reachable from untrusted networks
- Weak administrative controls (shared accounts, missing MFA, old crypto)
- Logging that is incomplete, inconsistent, or not monitored
- Security profiles not applied (IPS/AV/URL filtering where expected)
- Legacy rules that no longer have a business owner
These issues are rarely visible in a typical vulnerability scan because they’re not always tied to a single CVE.
They’re control failures, and control failures are why attacks keep working.
Organisations don’t lose because they lack tools; they lose because controls aren’t consistently implemented and governed.
Why misconfiguration happens (even in mature teams)
Misconfiguration is usually the output of normal business pressure:
1) “Temporary” access becomes permanent
A rule is opened to support a project, a supplier, a migration, a test. Nobody closes it because nothing broke.
2) Too many changes, not enough review
Firewall policies evolve fast. Without routine validation, you end up with policy sprawl, hundreds or thousands of rules with unclear intent.
3) Ownership is unclear
If a rule doesn’t have an owner, it doesn’t have a lifecycle. That’s how risk becomes institutionalised.
4) “We’re covered, we have a firewall”
A firewall is not a control by default. NIST is clear that firewall security depends on policy, correct configuration, testing, and ongoing management, not just deployment.
The most common firewall misconfigurations we encounter
Overly permissive access rules
These are rules that allow broad source/destination ranges, wide port ranges, or “temporary” any/any exceptions. They often exist because tightening them feels operationally risky, until an attacker finds them.
What to check
- Any/any or “wide” rules that bypass segmentation
- Rules allowing inbound services from “any” source
- Rules where the service definition is broader than required
Internet-exposed management interfaces
If a firewall’s admin interface is reachable from the internet (or from user networks that don’t need it), you’ve created a high-value target.
What to check
- Admin GUI/SSH exposure beyond a hardened management network
- Vendor remote-access features enabled unnecessarily
- No MFA / weak admin authentication paths
Weak or inconsistent admin controls
You’re relying on the firewall to enforce access, so administrative access must be treated like tier-0 identity.
What to check
- Shared admin accounts
- Lack of MFA for admin access
- Old TLS/crypto settings
- Excessive admin roles
Logging that doesn’t support detection or investigation
If you can’t reliably answer “what was allowed, from where, when, and why?” then your firewall isn’t supporting incident response.
What to check
- Missing logs on key rule categories (inbound, VPN, admin, critical segments)
- Logs retained but not monitored
- No integration with SIEM/SOC workflows
Best-practice drift vs. secure baselines
Configuration baselines exist for a reason. CIS Benchmarks provide consensus-based, prescriptive security configuration recommendations across many products and platforms.
Even where a CIS Benchmark isn’t available for a specific model/version, vendors provide hardening guidance, the point is to measure your live configuration against a known-secure standard, not assumptions.
Why this matters: misconfiguration is a breach accelerator
Attackers don’t need to “beat” your firewall. They look for where it already says “yes”.
Firewall misconfiguration increases your likelihood of:
- Unauthorised inbound access (especially into legacy or exposed services)
- Lateral movement across flat networks
- Poor visibility during an incident (limited log coverage)
- Audit and compliance failures (controls exist on paper, not in reality)
Misconfiguration is also part of a broader pattern: OWASP lists security misconfiguration as a top category because highly configurable systems routinely ship and operate insecurely without strict governance.
How to reduce firewall misconfiguration risk (without slowing the business)
You don’t fix this with a one-time clean-up. You fix it with repeatable controls:
Step 1: Define and enforce a rule lifecycle
- Every rule has an owner, a purpose, and a review date
- Temporary rules expire by default
Step 2: Reduce admin exposure
- Separate management plane network
- Tight source restrictions
- MFA for administrators
- Monitor admin activity
Step 3: Baseline against best practice
- Use CIS Benchmarks where available
- Use vendor hardening guidance where not
- Track deviations deliberately (with justification)
Step 4: Review the rulebase for intent, not just syntax
- Identify high-risk patterns (wide rules, inbound exposure, segmentation bypass)
- Validate security profiles are applied where expected
Step 5: Make logging operational
- Log what matters, retain it properly, and ensure someone is watching it
Where Secon’s Firewall Configuration Review supports
A typical pen test shows you what an attacker can exploit today. A firewall configuration review shows you what your firewall is currently permitting and where your controls have drifted from best practice.
Secon’s Firewall Configuration Review is a manual, consultant-led assessment that:
- Reviews the firewall configuration (with read-only access) for best-practice deviations and realistic risk
- Evaluates the rule-set to identify dangerous, risky, or overly permissive rules
- Reviews authentication mechanisms, logging processes, ACLs/rules, and security profiles
- Benchmarks against published industry standards like CIS (when available) and vendor security guidance
- Prioritises findings based on the risk they pose
- Produces both an executive summary and a technical findings report with remediation actions
- We support common firewall vendors including Cisco, Palo Alto, Check Point, Fortinet and Sophos.
If you suspect your firewall policy has grown faster than your governance, a best-practice review is a good next step. To discuss this with our team, fill out the form below.
