🧱 05-01: Firewall Concepts & History¶

📌 What Is a Firewall?¶

A firewall is a policy enforcement point — a device or piece of software that sits at the boundary between two zones of differing trust and decides, packet by packet or connection by connection, what is allowed to cross that boundary.

That's the whole idea in one sentence: a firewall doesn't make a network secure by itself — it enforces a security policy that a human designed. If the policy is wrong, sloppy, or too permissive, the firewall will faithfully enforce a bad policy just as well as a good one.

Example¶

Trust zone A: Your home/office LAN (192.168.1.0/24)
Trust zone B: The public Internet
Firewall: The router/gateway sitting between them, deciding which packets pass

💡 A firewall is not a single product — it's a role. That role can be played by a dedicated appliance, a router's built-in filter, a Linux kernel feature (iptables/nftables), or software running on an individual host (a "host-based firewall" like Windows Defender Firewall).

🧭 Ingress vs. Egress¶

Firewalls filter traffic in two directions, and it's easy to only think about one of them:

Direction	Meaning	Typical Concern
Ingress	Traffic coming into the protected network/host	Stop attackers from reaching internal services
Egress	Traffic leaving the protected network/host	Stop malware from phoning home, stop data exfiltration

💡 Many real-world breaches are only caught because someone was filtering (or logging) egress traffic — the initial break-in got through, but the malware's outbound connection to a command-and-control server got blocked or noticed. Beginners often build ingress-only rule sets and forget egress entirely.

🏛️ Default Deny vs. Default Allow¶

Every firewall rule set ends with an implicit final rule — the default policy — that decides what happens to a packet that matched none of the explicit rules above it.

Policy	Behavior	When It's Used
Default Deny	Block everything not explicitly allowed	Best practice for security-sensitive networks
Default Allow	Allow everything not explicitly blocked	Easier to set up, but leaves unknown gaps open

Example¶

# Default-deny philosophy: allow only what you name, drop the rest
Rule 1: ALLOW  tcp  dport 22   (SSH management)
Rule 2: ALLOW  tcp  dport 443  (HTTPS)
Rule 3: ALLOW  established/related traffic
Default: DROP  everything else

💡 Default deny is the gold standard in security engineering. It flips the burden of proof: instead of asking "is there a reason to block this?", you ask "is there a reason to allow this?" Anything you forgot to think about is blocked by default rather than allowed by default. The tradeoff is that default-deny requires more upfront work — you have to explicitly enumerate every legitimate use of the network — and a missing rule causes an outage rather than a silent security hole, which is a much better failure mode.

🕰️ A Brief History of Firewalls¶

Firewall technology evolved in stages, each one fixing a blind spot in the previous generation. Understanding this evolution matters because all four generations are still in use today — you'll meet plain packet filters on routers, stateful firewalls on Linux boxes, and next-gen firewalls at the enterprise edge, sometimes all in the same network.

Generation 1        Generation 2        Generation 3          Generation 4
Packet Filter   →   Stateful      →    Proxy / App-Layer  →  Next-Gen Firewall
(late 1980s)        (early 1990s)      (1990s)                (2000s-present)

1. Packet-Filtering Firewalls (~1988)¶

The earliest firewalls simply inspected each packet's IP header and transport-layer header (source/destination IP, port, protocol) in isolation and matched it against a static rule list. No memory of prior packets. Fast and simple, but easy to fool because it couldn't tell a legitimate reply from a forged one.

See 05-02: Packet-Filtering Firewalls for the full picture.

2. Stateful Firewalls (~early 1990s)¶

Firewalls gained a connection tracking table, so they could recognize "this packet is part of a connection I already approved" and automatically allow the reply traffic — without needing a separate rule for every possible response.

See 05-03: Stateful Firewalls.

3. Proxy / Application-Layer Firewalls (~1990s)¶

Instead of just looking at headers, these firewalls terminate the connection themselves and inspect the actual application data (e.g., the HTTP request line, FTP commands) before deciding whether to relay it onward.

4. Next-Generation Firewalls, NGFW (~2000s onward)¶

Modern firewalls combine stateful inspection with deep packet inspection, intrusion prevention, application awareness (recognizing "this is Netflix traffic" not just "this is port 443 traffic"), and even TLS decryption.

Both #3 and #4 are covered in 05-04: Proxy & Next-Gen Firewalls.

🧩 Where Firewalls Fit in the OSI Model¶

Firewall Type	OSI Layers Inspected
Packet Filter	Layer 3 (IP), Layer 4 (TCP/UDP/ICMP headers)
Stateful Firewall	Layer 3, Layer 4 + connection state
Proxy/Application Firewall	Layer 7 (application data)
NGFW	Layers 3 through 7, plus behavioral/signature analysis

💡 The higher up the stack a firewall can inspect, the more context it has to make a smart decision — but also the more CPU work it has to do per packet, and the more complexity (and potential for bugs) it introduces.

📌 Key Takeaways¶

A firewall is a policy enforcement point between trust zones — it enforces a policy, it doesn't invent one.
Filtering happens in two directions: ingress (inbound) and egress (outbound) — don't neglect egress.
Default deny (block everything not explicitly allowed) is the security best practice; default allow is easier but riskier.
Firewalls evolved through four generations: packet filter → stateful → proxy/application → next-generation (NGFW).
Each generation added the ability to inspect more context: from raw headers, to connection state, to application content, to full deep packet inspection.
All four generations are still deployed today — the newest firewall doesn't automatically replace the need to understand the older, simpler models.
The higher up the OSI stack a firewall inspects, the smarter its decisions can be, at the cost of more processing overhead.
A firewall is only as good as the policy it's configured with — misconfiguration is a bigger real-world risk than the technology itself (more in 05-08: Firewall Limitations & Evasion).