📋 05-02: Packet-Filtering Firewalls¶
📌 What Is a Packet Filter?¶
A packet-filtering firewall (also called a stateless firewall) is the earliest and simplest kind of firewall. It examines each packet in complete isolation — looking only at the information available in that one packet's headers — and compares it against a static list of rules.
It never asks "have I seen packets related to this one before?" It has no memory. Every packet is judged purely on its own headers, as if it just appeared out of nowhere.
What a Packet Filter Can Look At¶
| Field | Example |
|---|---|
| Source IP address | 203.0.113.5 |
| Destination IP address | 192.168.1.10 |
| Source port | 54321 |
| Destination port | 22 (SSH), 80 (HTTP) |
| Protocol | TCP, UDP, ICMP |
| TCP flags (sometimes) | SYN, ACK, FIN |
💡 Notice what's not in that list: application content. A packet filter has no idea whether port 80 traffic is really HTTP, a tunneled SSH session, or garbage — it only sees the header.
🧾 A Worked Example Rule Set¶
Imagine a small office network (192.168.1.0/24) with a single web server at 192.168.1.10. A stateless rule set to allow web traffic in and block everything else inbound might look like this:
Rule 1: ALLOW IN proto=TCP dst=192.168.1.10 dport=80 (HTTP requests in)
Rule 2: ALLOW IN proto=TCP dst=192.168.1.10 dport=443 (HTTPS requests in)
Rule 3: ALLOW OUT proto=TCP src=192.168.1.10 sport=80 (HTTP replies out)
Rule 4: ALLOW OUT proto=TCP src=192.168.1.10 sport=443 (HTTPS replies out)
Default: DROP everything else
Notice Rule 3 and Rule 4. Because the firewall has no concept of "connection," it cannot express the idea "allow replies to connections that were legitimately initiated by Rule 1/2." Instead, the administrator has to write a separate, standing rule that blindly allows any packet with source port 80/443 outbound — whether or not it's actually a reply to a real request.
⚠️ The Key Weakness: No Concept of "Reply"¶
This is the fundamental flaw of stateless filtering, and it's worth sitting with:
A packet filter cannot distinguish a legitimate reply packet from a spoofed packet that was crafted to look like a reply.
Concrete Example of the Problem¶
Look again at Rule 4 above: ALLOW OUT proto=TCP src=192.168.1.10 sport=80.
This rule was written with good intentions — "let the web server's responses go out." But read literally, it says: any outbound TCP packet whose source port happens to be 80 is allowed, no matter what triggered it. Reverse the direction and the same blind spot exists on inbound rules too: if an administrator (trying to be helpful) adds ALLOW IN proto=TCP dport=1024-65535 flags=ACK to "let return traffic in" for outbound-initiated connections, an attacker can simply craft a packet with the ACK flag set and a source port in that range — the firewall has no way to check whether an actual outbound SYN ever happened. It will accept the forged packet as if it were a real reply, because it never tracked the original request in the first place.
💡 This is precisely the gap that stateful firewalls were invented to close — see 05-03: Stateful Firewalls.
✅ Strengths of Packet Filters¶
| Strength | Why It Matters |
|---|---|
| Very fast | No connection table to maintain or look up — just a header match |
| Low resource usage | Works even on low-power routers and embedded devices |
| Simple to reason about | Each rule is a standalone, independent statement |
| Still the basis for ACLs | Router/switch ACLs (see 05-07: ACLs, DMZ & Segmentation) are essentially stateless packet filters |
❌ Weaknesses of Packet Filters¶
| Weakness | Consequence |
|---|---|
| No connection awareness | Can be tricked by spoofed "reply" packets |
| Rule sets grow large and duplicated | Every direction of every allowed conversation needs its own rule |
| Can't inspect payload | Malicious content riding on an allowed port/protocol sails through |
| Vulnerable to IP spoofing | Since decisions rely only on header fields, a forged source IP can pass rules meant for a trusted host |
| Fragmented packets are hard to filter correctly | Filtering rules that depend on TCP/UDP port numbers may not see them if the port info is in a later fragment |
📌 Key Takeaways¶
- A packet filter (stateless firewall) judges every packet independently, based only on IP/port/protocol header fields.
- It has no memory of past packets or connections — it cannot tell "this is part of a conversation I approved" from "this looks similar by coincidence."
- Because outbound and inbound legs of a conversation need separate standing rules, stateless rule sets are verbose and error-prone.
- The critical weakness: a spoofed packet crafted to resemble a legitimate reply will be accepted, because there's no real request being tracked against it.
- Packet filters are fast and lightweight, which is why router/switch ACLs still use this model today.
- Packet filters cannot see inside the payload — they're blind to application-layer attacks.
- This weakness is exactly what motivated the invention of stateful inspection, covered next.