Firewall Rule Analysis - Learn

Blue Team · Medium

Firewall Rule Analysis

Master systematic firewall ruleset auditing — identifying any/any rules, rule shadowing, missing egress controls, stale access, and weak protocols — understanding network segmentation architecture, and producing a prioritised remediation report that directly improves an organisation's perimeter posture.

Medium Blue Team Path ⏱ 22 min read

Learning Progress

What is it?

Firewall Rule Auditing

A firewall is only as strong as its ruleset. Over time, firewall rules accumulate — temporary rules made permanent, overly broad rules added in haste, and conflicting rules that produce unexpected behaviour. A firewall audit reviews every rule to ensure it is necessary, correctly scoped, and achieving its intended effect.

Firewall rule analysis is a core Blue Team skill that directly closes gaps exploited by attackers. Penetration testers regularly find that "secure" networks have firewall misconfigurations that allow lateral movement, data exfiltration, or direct access to sensitive systems. An organisation that has never audited its firewall ruleset is almost certainly operating with significant unintended access paths that neither the security team nor the business is aware of.

💡Implicit deny: Every well-configured firewall ends with an implicit or explicit deny-all rule. Traffic not explicitly permitted should be denied by default — this is the foundational firewall security principle. Any ruleset without a final deny-all is permitting unknown traffic by default.

How Firewall Rulesets Degrade Over Time

Firewall rulesets rarely degrade from a single bad decision — they degrade from the accumulation of many small compromises over years. A developer needs temporary database access for an urgent weekend deployment; the rule gets created and never removed. A new system is rolled out and added to a broad subnet rule rather than getting its own specific permissions. A vendor requires connectivity for remote support, gets an overly broad rule, and the engagement ends but the rule remains. Understanding these accumulation patterns helps auditors know where to look for problems.

📌 Non-Technical Analogy

Imagine a building's access control system that started with a clear policy: every door locked except the main entrance, with keycards required for specific internal rooms. Over five years: a contractor needed temporary access to the server room, so the door was propped open "just for the weekend" and never secured again. A new department's entire floor got blanket access to save time configuring individual rooms. An old room that was decommissioned still has active keycards associated with employees who left the company. A firewall ruleset that has never been audited is exactly this building — the original design intent is invisible under years of accumulated shortcuts, and nobody is entirely sure anymore what goes where or why.

How it works

Common Firewall Misconfigurations

Rule Audit Checklist — Six Core Problem Categories

Any/Any rules     Permits all traffic on all ports -- functionally disables the firewall
Overly broad      Entire /16 subnet permitted when only one specific IP needed
Rule shadowing    Earlier broad rule makes a later specific rule unreachable
Missing egress    Outbound traffic unrestricted -- enables C2 beaconing and exfiltration
Stale rules       Rules for decommissioned systems, old vendors, past employees still active
Weak protocols    Telnet, FTP, or HTTP permitted where encrypted versions exist

Examples

Firewall Audit in Practice

Example 01Identifying any/any rules

An any/any rule permits all traffic between zones — functionally disabling the firewall for that traffic flow. These are most often created for testing and never removed.

Rule 47:
  Source:      ANY
  Destination: ANY
  Port:        ANY
  Action:      PERMIT
# CRITICAL: This rule permits all traffic in both directions
# Added "temporarily" in 2023 during an outage and never removed
# Recommendation: Delete immediately, replace with specific rules

Example 02Rule shadowing

A broad rule earlier in the list matches all traffic that a more specific rule lower down was intended to catch — the specific rule never fires.

Rule 12:  Source: 10.0.0.0/8  Dest: ANY  Port: 443  Action: PERMIT
...
Rule 31:  Source: 10.0.5.44   Dest: 10.1.0.0/24  Port: 443  Action: DENY
# Rule 31 is shadowed -- Rule 12 already permits this traffic
# 10.0.5.44 can reach 10.1.0.0/24 on 443 despite the DENY intent
# Fix: move the specific DENY above the broad PERMIT

Example 03Missing egress controls

Unrestricted outbound traffic allows malware to beacon to C2 infrastructure, exfiltrate data, and download additional tools — a critical gap in any perimeter defence.

Outbound ruleset from internal network:
Rule 1:  Source: 10.0.0.0/8  Dest: ANY  Port: ANY  Action: PERMIT
# No outbound restrictions at all
# Any infected host can freely communicate with C2 infrastructure
# Any user can exfiltrate data to personal cloud storage
# Fix: whitelist required destinations (web proxies, DNS servers),
# deny everything else and route general web traffic through a proxy

Example 04Weak protocol permissions

Permitting cleartext protocols when encrypted alternatives exist exposes credentials and data to anyone with network access — including a post-compromise attacker performing lateral movement.

Rule 8:   Source: ANY  Dest: 10.0.10.5  Port: 23 (Telnet)  Action: PERMIT
# Telnet to a network device -- admin credentials visible in cleartext on wire
Rule 14:  Source: ANY  Dest: 10.0.0.0/8  Port: 21 (FTP)    Action: PERMIT
# FTP permitted internally -- credentials and data in cleartext
# Fix: deny Telnet (23) and FTP (21), permit SSH (22) and SFTP/FTPS only

Key Concepts

What You Need to Know

🚫

Default Deny

All traffic not explicitly permitted should be denied. Default-deny is the foundational firewall security principle — permit only what is necessary, deny everything else.

👕

Rule Shadowing

A broad rule earlier in the list matches traffic that a specific rule lower down was meant to handle. The specific rule never fires — a common misconfiguration in rulesets that grew without systematic review.

📤

Egress Filtering

Controlling outbound traffic. Without egress filtering, malware can freely beacon to C2 servers and exfiltrate data. Outbound should be as tightly controlled as inbound.

🧹

Rule Hygiene

Regular firewall audits to remove stale rules, tighten overly broad permissions, and document the business justification for every rule. Every rule that cannot be justified should be removed.

Architecture

Network Segmentation — Zones, Trust, and Firewall Position

Firewall rules do not exist in isolation — they implement a network segmentation architecture that defines which zones of the network can communicate with which other zones, under what conditions. Understanding the intended architecture is essential for auditing rules accurately: a rule that looks permissive in isolation may be correct given the zone it governs; a rule that looks restrictive may be defeating the purpose of a security boundary it was supposed to protect.

Internet

Untrusted. Assume hostile.

⇌

DMZ

Semi-trusted. Web servers, email gateways, public-facing services.

⇌

Internal

Trusted. User workstations, file servers, business applications.

⇌

Restricted

Highly trusted. Domain controllers, HR data, financial systems.

What Each Boundary Should Enforce

Internet → DMZ: Permit only specific public-facing services (80, 443 to web servers; 25 to mail relay). Deny everything else. The DMZ exists precisely to absorb the risk of internet-facing services without exposing the internal network if a DMZ host is compromised.
DMZ → Internal: Highly restricted. DMZ hosts should not initiate connections to the internal network. If a web application needs to query a database, the database should be in the DMZ or the connection should be proxied through a tightly controlled path. A compromised DMZ host that can freely connect to internal systems is a direct pivot path.
Internal → Restricted: Need-to-know access only. Workstations should not be able to reach domain controllers directly on LDAP/Kerberos except through specific managed paths. Financial and HR systems should be reachable only from explicitly authorised workstations or application servers.
Internal → Internet (egress): Route all outbound web traffic through a proxy for inspection and logging. Deny direct internet access from workstations. Block known-bad categories at the proxy level.

Example 05DMZ to Internal pivot — the most dangerous misconfiguration

A compromised DMZ host with unrestricted access to the internal network collapses the entire value of the DMZ architecture. This is the most common way perimeter breaches become full internal compromises.

# Discovered ruleset: DMZ to Internal zone
Rule 3:  Source: 10.100.0.0/24 (DMZ)  Dest: 10.0.0.0/8 (Internal)
         Port: ANY  Action: PERMIT
# CRITICAL: Any DMZ host can reach any internal host on any port
# DMZ should be ISOLATED from internal. This rule destroys zone separation.
# Attack chain: Attacker compromises web server in DMZ →
#               pivots freely to all internal hosts via this rule →
#               reaches domain controllers, HR data, financial systems

# Correct DMZ-to-internal ruleset:
Rule 3a: Source: 10.100.0.5 (web01-DMZ)  Dest: 10.0.5.20 (db01-internal)
         Port: 3306  Action: PERMIT  Comment: "web01 needs MySQL access"
Rule 3b: Source: 10.100.0.0/24  Dest: 10.0.0.0/8  Port: ANY  Action: DENY

Rule Lifecycle

Stale Rules, Scope Creep, and the Change Management Gap

Two of the most common sources of firewall misconfiguration are rules that outlive their justification (stale rules) and rules that were correctly scoped at creation but expanded over time without re-review (scope creep). Both result from the same root cause: changes to the firewall were not tied to a change management process that requires periodic review and automatic expiry.

Identifying Stale Rules

Stale rules fall into several identifiable categories that an auditor can check systematically:

Rules referencing decommissioned hosts: The destination IP resolves to nothing, or CMDB shows the asset was decommissioned. The rule remains because nobody removed it when the system was turned off.
Rules for terminated vendor relationships: A vendor was permitted access for a project engagement. The engagement ended. The rule was never removed.
Rules for temporary access: A developer needed a connection for an urgent deployment. The rule was created with "temporary" in the comment. It is now three years old.
Rules with no documentation: No comment, no ticket reference, no owner. These are impossible to evaluate without extensive investigation and should be treated with suspicion.

Example 06Stale vendor access and undocumented rules

A rule audit commonly surfaces rules from terminated vendor relationships that provide unnecessary external access to internal systems — often with no documentation identifying why the rule was created.

# Rule with no documentation, pointing to external IP range:
Rule 89:  Source: 203.0.113.0/24  Dest: 10.0.20.5:8443  Action: PERMIT
          Comment: (none)  Created: 2021-03-15  Last modified: 2021-03-15
# Investigation: 203.0.113.0/24 belongs to former HVAC vendor
# 10.0.20.5 is the building management system (BMS) controller
# Vendor contract ended 2022 -- rule never removed
# BMS access from internet = physical security risk (door locks, HVAC)

# Rule created with "temporary" comment, never removed:
Rule 102: Source: 10.0.5.0/24  Dest: 10.99.0.0/16  Port: 1521 (Oracle)
          Comment: "TEMP - dev team access for Q3 project"  Created: 2022-08-01
# Dev team project ended Q3 2022. Rule still active 3.5 years later.
# 10.99.0.0/16 is the production Oracle database subnet.
# Entire dev subnet has direct Oracle access to production.

Methodology

Structured Audit Methodology — From Export to Report

A professional firewall rule audit follows a systematic process that ensures complete coverage and produces output a change management team can act on. The goal is not just finding problems but prioritising them by risk, documenting them with sufficient evidence that each rule change can be approved by a business owner, and structuring remediation recommendations that can be implemented incrementally without disrupting operations.

Export the complete ruleset from all firewall devices in scope. For enterprise environments this typically means multiple firewalls at different segmentation boundaries. Export as text or CSV — tools like Tufin, FireMon, or AlgoSec can automate analysis, but understanding manual review is foundational.
Build a network topology map showing which zones exist and which firewalls govern which boundaries. Rules can only be evaluated in the context of the segmentation they're intended to enforce.
Flag structural misconfigurations first — any/any rules, rules that collapse zone boundaries (DMZ to Internal permits), missing default-deny. These are unconditionally wrong regardless of business justification.
Identify shadowed rules by walking the ruleset from top to bottom for each traffic type and checking whether any rule is fully covered by a rule above it.
Cross-reference with CMDB — destination IPs against asset inventory to identify stale rules for decommissioned hosts. Destination IP with no CMDB entry warrants investigation.
Review rule documentation — every rule should have a comment with business justification and a ticket reference. Rules without documentation are candidates for removal.
Produce a prioritised findings report with Critical (immediate risk, structural misconfiguration), High (significant overpermission), Medium (stale/undocumented), and Low (weak protocols, documentation gaps) severity levels.

✅The Change Management Imperative: A firewall audit without a change management process attached to it will produce findings that are remediated once and then re-accumulated. The most durable improvement is establishing a process that prevents the problem from recurring: every firewall rule requires a ticket reference, a named business owner, a review date, and an expiry date for temporary rules. Firewall platforms that support rule tagging can enforce this policy at creation time, alerting on any rule missing required documentation. This converts firewall hygiene from a periodic audit event into a continuous operational standard.

Reference

Core Concepts Summary

🚫

Default Deny

Final rule denies all traffic not explicitly permitted. Without it, unmatched traffic passes through. Verify every firewall ends with an explicit or implicit deny-all — it is the safety net for the entire ruleset.

👕

Rule Shadowing

Broad rule above a specific rule — the specific rule never matches. Walk ruleset top-to-bottom for each traffic type to identify. Especially common when DENYs are added after broad PERMITs without reordering.

📤

Egress Filtering

Inbound-only firewalling leaves outbound unrestricted. Malware C2 beaconing, data exfiltration, and lateral pivoting all exploit unrestricted egress. Route via proxy, whitelist required destinations, deny the rest.

🧹

Rule Hygiene

Documentation (business justification + ticket), expiry dates for temporary rules, CMDB cross-reference for stale host detection. Change management process prevents re-accumulation after each audit.

🏗️

Zone Architecture

Internet → DMZ → Internal → Restricted. Each boundary firewall enforces that zone's trust level. DMZ-to-Internal permit on any/any collapses the entire DMZ value — it is the highest-risk single misconfiguration type.

⏰

Stale Rules

Decommissioned hosts, terminated vendors, "temporary" rules that persisted. Cross-reference destination IPs against CMDB. Any rule without documentation or business owner is a removal candidate pending investigation.

🔒

Least Privilege

Specific source IP, not /16 subnet. Named service port, not ANY. Named destination, not ANY. Every generalisation above the minimum required is unnecessary attack surface. Tighten iteratively with business owners.

📋

Audit Output

Critical (structural/any-any), High (overpermissive/zone collapse), Medium (stale/undocumented), Low (weak protocols). Each finding needs: rule number, current config, risk explanation, specific remediation, and business owner to approve the change.

Ready to put it into practice?

Proceed to the Lab

You've covered the theory. Now apply it hands-on in the simulated environment.

Start Lab — Firewall Rule Analysis→
← Return to all labs