🚧 05-08: Firewall Limitations & Evasion¶
📌 Firewalls Are Not a Silver Bullet¶
Everything in this module has built toward increasingly capable firewalls — from stateless packet filters, to stateful inspection, to proxy and next-generation firewalls with deep packet inspection and TLS decryption. It would be easy to walk away thinking a well-configured, modern firewall makes a network "secure." It doesn't. A firewall is one control among many, and it has real, structural limitations that no amount of configuration tuning can fully eliminate.
🚫 What Firewalls Cannot Do¶
1. Stop Insider Threats¶
A firewall enforces a boundary between trust zones — but it has nothing to say about what a trusted, already-authorized user does once they're inside that boundary. An employee with legitimate access who steals data, sabotages systems, or misuses their credentials is operating entirely within the zone the firewall was built to protect. The firewall never even sees a "boundary crossing" event to evaluate.
2. Inspect Traffic It Cannot Decrypt¶
Even NGFWs with TLS inspection (see 05-04: Proxy & Next-Gen Firewalls) can only decrypt traffic where they hold a trusted certificate the client accepts. Traffic using certificate pinning, end-to-end encrypted messaging apps, or any protocol the firewall wasn't configured to intercept remains opaque. Encrypted malicious traffic looks identical to encrypted legitimate traffic from the firewall's point of view unless it can actually decrypt and inspect the content.
3. Detect Application-Layer Attacks a Simple Rule Can't See¶
A rule like ALLOW tcp dport 443 says nothing about what is being sent to that web application. A SQL injection payload, a malicious file upload, or an authentication bypass exploit riding on an already-open, already-allowed port is invisible to a firewall that isn't specifically doing application-layer inspection (and even then, it can only catch attacks matching known patterns/signatures — novel attacks can slip past). This is why web application firewalls (WAFs) and secure coding practices exist as separate layers, not replacements for network firewalls.
4. Compensate for Misconfiguration¶
A firewall is only as good as its rule set. Common, very real misconfiguration risks include:
| Misconfiguration | Consequence |
|---|---|
An overly broad rule (ALLOW any any) left in from testing |
Defeats the purpose of every other carefully written rule |
| Forgetting to set the default policy to DROP | Silently falls back to default-allow behavior |
| A rule ordered incorrectly (a broad ACCEPT placed before a specific DROP) | The DROP rule never gets a chance to match, because the first match wins |
| Leaving a management/debug port open "temporarily" | Becomes a permanent, forgotten hole |
| Not updating rules when the network topology changes | Rules reference IPs/subnets/services that have since moved, leaving new hosts unprotected or old rules pointlessly restrictive |
💡 Security research consistently finds that misconfiguration, not a flaw in the firewall technology itself, is the most common real-world cause of firewall-related breaches. The tool is rarely the weak point — the policy design and change-management process around it usually is.
🕳️ Common Evasion Techniques¶
Attackers have developed a number of well-known techniques specifically to slip malicious traffic past firewalls that are otherwise configured reasonably well.
1. Packet Fragmentation¶
IP allows large packets to be broken into smaller fragments that get reassembled at the destination. Some firewalls (especially older, simpler stateless filters) inspect each fragment independently rather than reassembling the full packet first. An attacker can deliberately fragment a malicious packet so that no single fragment contains enough information to trigger a filtering rule — for example, splitting the TCP header itself across two fragments so the destination port number (which the firewall's rule is trying to match against) isn't fully present in the first fragment the firewall inspects.
Normal packet: [ IP Header | TCP Header (dport=22) | Payload ]
Fragmented evasion: Fragment 1: [ IP Header | partial TCP Header ]
Fragment 2: [ rest of TCP Header (dport=22) | Payload ]
A firewall that only checks Fragment 1 for a --dport 22 match may miss it, because the port number doesn't fully appear until Fragment 2. Modern stateful firewalls generally defend against this by reassembling fragments before inspecting them, but it remains a classic example of why naive header matching is fragile.
2. Tunneling Over Allowed Protocols¶
If a firewall allows DNS (port 53) or ICMP (ping) outbound — which almost every firewall does, because those protocols are needed for basic connectivity — an attacker can encode arbitrary data inside DNS queries/responses or ICMP echo payloads and use that as a covert communication channel (DNS tunneling, ICMP tunneling). The firewall sees "allowed protocol, allowed port" and passes the traffic through, with no idea that the payload has been repurposed to smuggle command-and-control traffic or exfiltrate data.
Legitimate DNS query: example.com → A record lookup
Tunneled DNS query: dGhpcyBpcyBzZWNyZXQgZGF0YQ.evil.com → encodes stolen data
in the subdomain label
3. Using Port 443 for Non-HTTPS Traffic¶
Because port 443 (HTTPS) is allowed outbound almost everywhere — blocking it would break the modern web — attackers and evasive tools alike run entirely different protocols over port 443 to blend in with normal traffic. A stateful firewall that only checks "is this TCP traffic on port 443?" will happily allow it, because the port number matches its rule, even though the payload isn't HTTPS at all. This is precisely the gap that NGFW application awareness (see 05-04: Proxy & Next-Gen Firewalls) was built to close, by fingerprinting the actual protocol behavior rather than trusting the port number.
4. Exploiting Trusted/Allowed Third Parties¶
Attackers increasingly route command-and-control traffic through legitimate cloud services (file storage, CDNs, chat/collaboration platforms) that are already on an organization's allow-list for business reasons. The firewall isn't wrong to allow traffic to those trusted providers — it simply has no way to distinguish an employee's legitimate use of the service from an attacker abusing the same trusted domain as a relay.
🧅 Firewalls as One Layer of Defense-in-Depth¶
Every limitation above points to the same conclusion: a firewall should never be the only control standing between an organization and a breach. It is one layer in a broader defense-in-depth strategy that should also include:
| Layer | Complements the Firewall By |
|---|---|
| Network segmentation (see 05-07: ACLs, DMZ & Segmentation) | Limiting how far an attacker can move even after getting past a boundary |
| Intrusion Detection/Prevention Systems | Watching for attack patterns and anomalies inside allowed traffic |
| Endpoint protection | Catching malicious activity on the host itself, regardless of how it arrived |
| Strong authentication (MFA) | Reducing the value of stolen credentials, which firewalls can't evaluate |
| Encryption and secure coding practices | Reducing what an attacker can do even if application-layer traffic reaches its target |
| Logging, monitoring, and incident response | Detecting and reacting to the things the firewall let through or couldn't see |
| Security awareness training | Reducing the likelihood of the initial compromise (phishing, social engineering) that firewalls can't prevent |
💡 The mental model to keep from this whole module: a firewall answers the question "should this traffic be allowed to cross this specific boundary?" It was never designed to answer "is this network secure?" — that requires many independent layers working together, so that when (not if) one layer fails or is bypassed, another is there to catch what got through.
📌 Key Takeaways¶
- Firewalls cannot stop insider threats — they only govern traffic crossing a boundary, not misuse by already-trusted users.
- Encrypted traffic that a firewall cannot decrypt is largely opaque to it, regardless of how malicious the content actually is.
- Firewalls without deep, up-to-date application-layer inspection cannot catch attacks embedded in otherwise-allowed traffic.
- Misconfiguration — overly broad rules, wrong rule order, forgotten temporary openings — is one of the most common real-world causes of firewall-related security failures.
- Fragmentation attacks exploit firewalls that inspect packet fragments independently instead of reassembling them first.
- Tunneling (DNS tunneling, ICMP tunneling) smuggles data through protocols the firewall already trusts and allows.
- Running non-HTTPS protocols over port 443 exploits the fact that most firewalls trust the port number more than they verify the actual protocol.
- Firewalls are one layer of defense-in-depth — segmentation, IDS/IPS, endpoint protection, strong authentication, and monitoring must work alongside them, not be replaced by them.