Stateless matching

Stateless filtering trades connection memory for more rules

A stateless firewall judges each packet against its rules and keeps no connection history. The administrator has to recognise replies from fields in the packet itself, such as TCP flags.

A stateless firewall operates only on the rules and each individual packet. No state information is generated when a packet is processed.

• Keeping state is expensive and needs fast memory.
• With only a few rules, stateless filtering may be faster.
• With many rules, stateful filtering may be faster, since the majority of packets match the first rule.
• As a rule of thumb, stateless is harder to configure, and mistakes are more likely.

Compare

Stateless

Each packet judged in isolation by the rules. No state table, so less memory. Faster with few rules. Harder to configure correctly, because every direction of every flow needs a rule.

Stateful

Tracks connections, so replies are recognised by state. Needs more memory and hardware. Faster with many rules, since most packets match one established rule at the top. Easier to write the rules.

ACK flags suggest reply direction without proving state

The TCP handshake is the cue a stateless rule uses. The client sends a packet with SYN. The server replies with SYN/ACK. The client confirms with a third packet carrying only ACK. After that, every packet during data transmission has ACK set.

So the rule is: the first packet of a connection has no ACK and every later packet has it. A rule that accepts a reply requires ACK to be set. A rule that accepts a new connection puts * in the Ack column, so it admits both the setup and the ongoing packets.

The lecture accepts one weakness. An attacker could send SYN/ACK in a first packet to trick the firewall, but the receiving host ignores it.

UDP is different. It has no state information, so the Ack column is * for UDP (the web-server table below writes it as -). It also means the firewall cannot tell the sender from the responder in a UDP exchange.

Stateless SMTP needs a separate rule for each direction

The mail-server policy is the same one as on the stateful page: only email in and out, anyone inside may send to any mail server, incoming email only to the mail server.

Rule	Interface	Source IP	Destination IP	Protocol	Source port	Destination port	Ack	Action
A1	inet	external	mailserver	TCP	*	25	*	Accept
A2	lan	mailserver	external	TCP	*	> 1023	Yes	Accept
B1	lan	internal	external	TCP	*	25	*	Accept
B2	inet	external	internal	TCP	*	> 1023	Yes	Accept
C	*	*	*	*	*	*	*	Drop

• A1 lets incoming email reach the mail server.
• A2 lets the mail server’s answers leave the network.
• B1 and B2 are the same pair for outgoing email.
• C drops everything else.

The stateful version needed four rules. This one needs five, because each direction of each flow is its own rule. Source and destination addresses name external, internal and the mail server rather than using *, as a guard against spoofing. The slides say rules A1 and B2 then block spoofed inbound packets, and A2 and B1 do the same for outbound.

HTTP and DNS need separate request and reply rules

The second example is a LAN with a web server. The policy:

• Allow HTTP traffic initiated by external hosts to the web server.
• Allow internal hosts to initiate HTTP and DNS. HTTP is TCP port 80, DNS is UDP port 53.
• Allow no other communication, in particular nothing initiated by external hosts to local hosts other than the web server.

The stateless table:

Rule	Interface	Source IP	Destination IP	Protocol	Source port	Destination port	Ack	Action
B1	inet	external	webserver	TCP	> 1023	80	*	Accept
B2	lan	webserver	external	TCP	80	> 1023	Yes	Accept
C1	lan	internal	external	TCP	> 1023	80	*	Accept
C2	inet	external	internal	TCP	80	> 1023	Yes	Accept
D1	lan	internal	external	UDP	> 1023	53	-	Accept
D2	inet	external	internal	UDP	53	> 1023	-	Accept
E	*	*	*	*	*	*	*	Drop

Rows B1 and B2 serve the first line of the policy, C1 and C2 serve internal HTTP, D1 and D2 serve internal DNS, and E is the default deny.

Try it — worked example

Tracing packets through the stateless mail-server table

Show answer and steps

Answer1 is accepted by A1, 2 is dropped by C, 3 is accepted by B2.

1. Packet 1 arrives on inet from an external host to the mail server, TCP, destination port 25, with SYN only so no ACK. Rule A1 matches, since its Ack column is *. Accepted.
2. Packet 2 arrives on inet from an external host to an internal workstation, TCP, destination port 80, no ACK. A1 needs the mail server as destination, so no. A2 and B1 need interface lan, so no. B2 needs destination port above 1023 and ACK, so no. C matches everything. Dropped.
3. Packet 3 arrives on inet from an external mail server to an internal host, TCP, destination port above 1023, ACK set. A1 needs the mail server as destination, so no. A2 and B1 need lan, so no. B2 matches. Accepted.

Pitfall

A stateless table accepts anything that fits the fields, including a packet that merely claims to be a reply. Packet 3 above is accepted because it has ACK set, not because the firewall knows an internal host asked. The lecture accepts this and relies on end hosts ignoring packets that belong to no connection they know. This is why the lecture calls stateless harder to configure and mistakes more likely.

Exam detail

Know the comparison the practice quiz tests: with fewer rules a stateless firewall may be faster, and a stateful firewall needs more hardware resources because it must maintain state. Both statements are true.

For a stateless table, say what the Ack column is doing in each row. * for a rule that must allow both the first packet and the rest, Yes for a rule that only allows a reply. For UDP there is no ACK flag, so the column does not apply.

Optional aside

For UDP, the lecture text writes Ack as * and the web-server table writes -; both mean the field is unused. The stateful web-server version starts by accepting established connections and ends with a drop.

Recall

Why does a stateless rule for outgoing email in the mail-server table use * in the Ack column, but the rule for the answers requires Yes?

The first packet of a connection has no ACK and later packets all have ACK. The rule that lets a connection start has to allow both, so it uses *. The rule for the answers only ever sees traffic inside an established connection, which always has ACK set, so it can require it.