Skip to content

05-02: Exercises

Question

A firewall uses a stateless packet filter with only this single rule (plus a default-deny policy):

ALLOW  outbound  tcp  dst-port 80

An internal host (10.0.0.5) opens a normal web request to 93.184.216.34:80. The web server replies from 93.184.216.34:80 back to 10.0.0.5 on some ephemeral port (e.g., 51342).

  1. Under this stateless rule set, will the reply packet be allowed back in?
  2. What extra rule (if any) would a stateless firewall need to make this work?
  3. How would a stateful firewall handle the same scenario differently?

Solution

Step 1: Trace the outbound packet

The outbound request (10.0.0.5:51342 → 93.184.216.34:80) matches the rule (dst-port 80, outbound) and is allowed. So far, so good.

Step 2: Trace the inbound reply

The reply travels in the opposite direction: 93.184.216.34:80 → 10.0.0.5:51342. This is an inbound packet with a source port of 80, not a destination port of 80.

A stateless filter only understands static header fields — it has no concept of "this reply belongs to a connection I already allowed out." The existing rule only matches outbound traffic to destination port 80; it says nothing about this inbound packet at all. Under a default-deny policy, the reply is dropped, and the web request effectively fails even though the outbound leg was "allowed."

👉 (1) No — the reply is dropped by a purely stateless rule set as given.

Step 3: What a stateless firewall needs instead

To fix this without any connection tracking, you'd need a second rule that allows inbound traffic where the source port is 80 (matching a typical web server reply) back to your internal ephemeral port range:

ALLOW  inbound  tcp  src-port 80  dst-port 1024-65535

👉 (2) A separate inbound rule matching src-port 80 (and, ideally, restricted to the expected ephemeral port range) is needed.

⚠️ This is exactly the weakness covered in 05-02: Packet-Filtering Firewalls: this rule is far too permissive. It allows any inbound packet claiming to come from source port 80, from anywhere — an attacker can simply set their tool's source port to 80 and walk right through this rule, since a stateless filter can't tell a legitimate reply from a forged packet with a convenient source port.

Step 4: How a stateful firewall differs

A stateful firewall (see 05-03: Stateful Firewalls) tracks the outbound connection when it's first allowed out, and automatically permits only the specific matching reply traffic for that exact connection (same IP/port 4-tuple) using a state table — commonly expressed as:

ALLOW  inbound  ctstate ESTABLISHED,RELATED

This one rule safely covers replies to any outbound connection the firewall already approved, without opening a blanket hole for anything merely claiming to originate from port 80.

👉 (3) A stateful firewall needs only one generic ESTABLISHED/RELATED rule, and it's actually more secure than the stateless fix — because it matches the specific tracked connection, not just a spoofable header field.

Final Answer

  • The reply is dropped by the stateless rule set as originally written.
  • A stateless fix requires a broad src-port 80 inbound allow rule — which is a real security weakness (spoofable).
  • A stateful firewall solves this correctly and more safely with a single ESTABLISHED,RELATED rule, since it tracks actual connections rather than trusting header values alone.