Firewall #

A firewall is an access-control device that blocks any traffic not permitted by an explicit rule (policy). At its most basic, a firewall inspects each packet's 5-tuple (source IP / destination IP / source port / destination port / protocol) and decides allow / deny / drop.

Since DEC shipped the world's first commercial firewall, SEAL, in 1988, firewalls have become the standard gateway between corporate LANs and the internet and the foundation underneath every modern network-security product. Stateful Inspection (Check Point's 1990 patent), NGFW (Next Generation Firewall, late 2000s), WAF (Web Application Firewall, 2000s onward), and cloud-era Security Groups / NACLs (2010s) all built on top — but the basic action of "block what doesn't match the rules" hasn't changed.

This article frames firewalls along three axes — type, history, and limits: the five generations (SVG 1) / what Stateful Inspection actually does (SVG 2) / placement-based classification (Network / Host / WAF / Cloud SG) / how NAT gets confused with firewalling / NGFW and WAF / cloud-era firewalls / and finally why perimeter firewalls alone no longer protect, pushing the industry toward Zero Trust. The most widely deployed networking device after routers and switches is now hitting fundamental limits — that's the subject here.

1. What is a firewall — 5-tuple and policy #

A network firewall's basic loop:

1. Receive the packet (at the NIC)
2. Extract the 5-tuple — source IP / destination IP / source port / destination port / protocol (TCP/UDP/ICMP, etc.)
3. Walk the rule list (ACL = Access Control List) top to bottom
4. Apply the action of the first match — allow / deny / drop / log
5. If nothing matches, apply the default policy (usually deny)

Typical rules:

# Allow internal LAN to reach external HTTPS
allow from 10.0.0.0/24 to any port 443 proto tcp

# Allow external hits to a DMZ web server on 80/443
allow from any to 203.0.113.10 port {80,443} proto tcp

# Drop everything else from outside to inside
deny from any to 10.0.0.0/24

deny vs drop: deny (reject) returns an ICMP unreachable; drop discards silently. Drop is generally preferred because "port closed" and "no response" look the same to a scanner, slowing reconnaissance.

Default-deny with explicit allow lists is the correct modern design. Default-allow with explicit deny lists leaks holes every time a new protocol or app appears, and is now anti-pattern.

2. Five generations — what each generation can see #

Firewall history is the history of "seeing higher layers." The five generations: Packet Filter → Stateful → Application Proxy → NGFW → Cloud/Zero Trust.

The important point: newer generations didn't replace older ones — modern systems run multiple generations simultaneously, as layers:

• Perimeter: NGFW (gen 4)
• In front of DMZ web servers: WAF (specialized gen 5)
• Per EC2 / VM: Cloud Security Group (gen 5)
• Inside the OS: Host Firewall (gen 1-2 lineage)
• Between containers: Network Policy / Service Mesh (gen 5)

The pattern is Defense in Depth — if one layer is misconfigured, the next should still stop the attack.

3. Stateless vs Stateful — the central concept #

Gen-2 Stateful Inspection is the de-facto baseline of every modern firewall. Here's the difference in one diagram.

Why Stateful Inspection is qualitatively better:

• Only the inside-initiated session and its return are permitted — outside-initiated new connections are default-denied
• Response-packet spoofing (an attacker sends a forged TCP ACK to look like return traffic) is blocked
• Rules are easier to write — only the side you initiated needs to be listed

State table limits:

• Table capacity is typically hundreds of thousands to a few million entries. On busy firewalls, table exhaustion becomes the throughput bottleneck.
• TTLs matter — too short and legitimate sessions are dropped; too long and the table fills.
• SYN Flood specifically targets filling the table to lock out legitimate connections — the inherent weakness of stateful inspection.
• UDP pseudo-state — stateless protocols get fake state entries based on 5-tuple + TTL.

Linux conntrack lets you see this live:

# Current connections
sudo conntrack -L
# tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=93.184.216.34 sport=48772 dport=443 ...

# Table capacity vs current usage
sudo sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

# Increase under DDoS / connection storms
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576

4. Placement and types — what does "firewall" even mean today #

The word firewall now covers several different devices. Sorted by what it protects and where it sits, four lineages:

These don't compete — modern systems layer them. A typical 3-tier web app on AWS:

• AWS WAF: in front of CloudFront / ALB, blocking L7 attacks (SQLi / XSS / bots / rate limits)
• Security Groups: ALB allows 80/443, App accepts only from ALB, DB accepts only from App
• NACLs: broad subnet-level control (stateless, complements SGs)
• Host firewall: nftables inside each EC2, tightening further (defense in depth)

The right design is to never expect one firewall to do everything — split the role across layers so a misconfiguration at one layer doesn't expose everything.

5. NAT vs firewall — a common confusion #

People say their home Wi-Fi router has "a built-in firewall," but really what they have is NAT (Network Address Translation) that incidentally behaves like one. NAT and firewalling are different functions:

NAT builds its mapping table from outbound flows initiated from inside, so inbound unsolicited connections find no mapping and never reach the inside. That's the "I'm protected by NAT" effect.

But NAT is not a firewall:

• Port forwarding punches holes (this is where most home-router misconfigs live)
• UPnP / NAT-PMP lets applications open their own ports (some IoT cameras, game consoles)
• IPv6 generally does not use NAT — moving to IPv6 removes the incidental protection, so an explicit firewall becomes mandatory

Modern guidance: enable an explicit firewall on your home/edge router and don't rely on NAT to do the security work, especially with IPv6.

6. NGFW — what L7 visibility adds #

NGFW was popularized by Palo Alto Networks around 2007 — Stateful Firewall + DPI (Deep Packet Inspection) + IPS + Application ID + URL Filtering + User ID + SSL Inspection, all in one box. The distinguishing capability: identifying what's flowing through port 443 by looking at the actual content.

Vs. classical stateful:

SSL Inspection (= TLS decryption) is the biggest debate point of NGFW:

• Install the corporate CA on every endpoint → NGFW intercepts → decrypts → scans → re-encrypts
• ○ L7 attack detection and DLP (Data Loss Prevention) become possible
• × Privacy — the employer can read employees' HTTPS traffic
• × Certificate Pinning breaks some apps (banking apps, some Google services)
• × Performance cost — even 10 Gbps appliances pay heavily for decryption

Operational pain points:

• App-ID signatures drift — new apps, new versions, or traffic obfuscation defeat detection
• Rule sprawl — "app × user × category" combinations push rule counts into the thousands
• False positives break business — a SaaS update can silently block valid traffic

7. WAF — an L7-only firewall for web apps #

A Web Application Firewall is an L7 firewall specialized for HTTP/HTTPS web applications. Deeper but narrower than NGFW: it inspects HTTP requests for SQLi / XSS / CSRF / command injection / path traversal / bots / rate-limit abuse.

Typical placement:

[Internet] → [CDN/WAF] → [ALB/Load Balancer] → [Web Server] → [App Server] → [DB]

OWASP CRS (Core Rule Set) is the de-facto rule library — one ruleset covers most of OWASP Top 10.

Major WAFs:

• AWS WAF / Cloudflare / Akamai / Fastly — cloud-edge (deployed in front of the web)
• F5 BIG-IP ASM / Imperva — on-prem appliances
• ModSecurity (OSS) — Apache / Nginx module, often paired with CRS

What a WAF stops, and doesn't:

A WAF is not a substitute for fixing app bugs. It's one layer in defense in depth. "We have a WAF, so we don't need to patch SQLi" is dangerous — prepared statements + ORM + input validation are the primary control, WAF is the last line.

8. Cloud-era firewalls — Security Groups, NACLs, SASE #

In cloud (AWS / Azure / GCP), the firewall concept changed substantially. Control moves from "IP-based boundary" to per-resource and per-identity.

On AWS:

What's distinctive about Security Groups:

• You can use a Security Group ID as a source, not just an IP CIDR. Auto-scaling instances stay correctly authorized because the SG reference updates as IPs change.
• Default deny inbound / default allow outbound (you opt into outbound restrictions)
• Stateful — return is automatic

# Terraform: ALB allowed to talk to App
resource "aws_security_group_rule" "app_from_alb" {
  type                     = "ingress"
  from_port                = 8080
  to_port                  = 8080
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.alb.id  # An SG ID, not an IP
  security_group_id        = aws_security_group.app.id
}

SASE (Secure Access Service Edge) — coined by Gartner in 2019. Firewall + VPN + SWG (Secure Web Gateway) + CASB + ZTNA all bundled in a cloud service. Cloudflare One / Zscaler / Netskope / Palo Alto Prisma are the major players.

Traditional (hub-and-spoke):

employee → branch → HQ firewall → SaaS

SASE model:

employee → cloud POP (firewall + SWG + ZTNA) → SaaS / HQ

"The same firewall policy applies no matter where the user is" is the essence of SASE, and remote work after COVID-19 accelerated its adoption.

9. Why firewalls alone no longer protect — toward Zero Trust #

The industry-wide consensus is now that firewalls alone don't stop most modern breaches. Verizon DBIR and Mandiant M-Trends consistently show that most successful intrusions pass through firewalls as "legitimate" traffic.

Attacks firewalls are blind to:

• Malware / phishing / dropper PDFs inside HTTPS (L4 firewalls can't see; even NGFW needs SSL inspection)
• Intrusions using valid credentials (phished or bought from an Initial Access Broker) — the firewall sees legitimate traffic
• Lateral movement after initial intrusion — AD / SSH / RDP / SMB inside the LAN are usually under-firewalled
• Supply-chain attacks (SolarWinds, 3CX) — software updates are trusted by the firewall
• Data exfiltration via SaaS — outbound to SaaS is permitted by policy

As a result, the industry pivoted to Zero Trust:

Firewalls under Zero Trust:

• Perimeter firewalls remain necessary as basic filtering, but "made it past the firewall = trusted" is dead
• ZTNA (Zero Trust Network Access) is replacing VPNs — instead of "VPN into the LAN," per-application identity-checked direct access
• Micro-segmentation turns the inside into a firewall mesh — per-VM, per-container, per-Pod firewall rules
• Service Mesh (Istio / Linkerd) acts as "the firewall between microservices," with mTLS plus authorization policies

Today's strongest defenses combine Firewall + EDR + SIEM + ZTNA + WAF + DLP + IAM, with firewalls as one important layer among many — not the whole answer.

10. Canonical incidents — where firewall limits showed up #

Common pattern: not "no firewall, so they got in," but rather "the attacker came in as legitimate traffic the firewall was meant to allow," "the inside was under-firewalled," or "the firewall device itself was attacked." Keeping a perimeter firewall is still mandatory — but relying on it alone is the old mental model.

11. Making firewalls useful in modern designs #

Practical principles to keep firewalls effective:

# Minimal Linux nftables firewall (outbound + return, plus inbound ssh)
sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0 ; policy drop ; }'
sudo nft add chain inet filter forward '{ type filter hook forward priority 0 ; policy drop ; }'
sudo nft add chain inet filter output '{ type filter hook output priority 0 ; policy accept ; }'
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iifname "lo" accept
sudo nft add rule inet filter input tcp dport 22 accept

The core idea of a firewall — "block traffic that doesn't match the rules" — hasn't changed since 1988, but the layer it can look at has steadily climbed: Packet Filter → Stateful → Application Proxy → NGFW → Cloud/Zero Trust. Stateful Inspection (1990) is the de-facto baseline today, with L7 app-aware (NGFW), Web-specialized (WAF), Cloud SG, and SASE stacked on top.

The classical mental model of "firewall = the box at the network perimeter" is no longer enough — Host firewalls, WAFs, Cloud SGs, and Service Meshes all act as firewalls in modern systems, and Defense in Depth requires combining them as layers.

We've also clearly entered an era where firewalls alone don't protect: attacks inside HTTPS, valid-credential misuse, supply-chain compromises, internal lateral movement, and exploits of the firewall device itself are the new mainstream. Zero Trust — don't trust the inside, decide on identity + device posture, stop lateral movement with micro-segmentation — is the path that makes firewalls genuinely useful again, as one disciplined layer in a multi-layer defense.