The whole of this chapter so far has protected a conversation. A firewall protects a boundary — and it does that by judging traffic on what its headers say, which turns out to be both remarkably useful and easy to fool.
Words you will meet
-
Firewall firewall Simple A checkpoint at the network's edge that decides which packets may pass. Precise A combination of hardware and software isolating an organisation's internal network from the Internet at large. It has three goals: all traffic passes through it, only authorised traffic is allowed through, and the firewall itself is immune to penetration. introduced in ch. 8 — open in glossary — hardware and software isolating an internal network from the Internet.
-
Packet filter packet filter Simple A firewall that judges each packet on its own, with no memory. Precise A traditional firewall that examines each datagram in isolation, deciding from header fields alone — source and destination IP address, protocol, port numbers, TCP flag bits — with no record of what came before. introduced in ch. 8 — open in glossary — judges each datagram alone, on header fields only.
-
Access control list — the ordered rules a filter applies; the first match decides.
-
Stateful filter stateful filter Simple A firewall that remembers which connections are open. Precise A firewall that tracks TCP connections in a connection table, observing the handshake and the teardown, so it can allow a packet only if it belongs to an established connection. introduced in ch. 8 — open in glossary — the same, plus a table of connections it has watched open.
-
Application gateway application gateway Simple A firewall that understands the application, not just the headers. Precise An application-specific server through which all application data must pass, so filtering decisions can be made on the application data itself rather than only on header fields. introduced in ch. 8 — open in glossary — a server in the path that reads the application data itself.
Why this matters
Everything from section 8.2 to section 8.8 has protected a conversation between two parties. This section changes subject completely.
A network administrator sees the world in two camps: people inside the organisation, who should reach its resources fairly freely, and everyone else, whose access must be scrutinised. That is not a cryptographic problem. It is the problem a castle solved with a gate on the drawbridge, and an office building solves with a security desk.
None of the cryptography in this chapter is used here. That is why operational security waited until the end, and why it sat apart in section 8.1’s grid of four properties.
What a firewall promises
A firewall isolates an organisation’s internal network from the Internet at large, letting some packets pass and blocking others. It has three goals, and the third is the one people forget.
All traffic in both directions passes through it. Large organisations may use several firewalls, or distributed ones — but putting one at a single access point makes a security policy far easier to manage and enforce.
Only authorised traffic passes, as defined by the local security policy. Because everything crosses the firewall, the firewall can restrict what gets through.
The firewall itself cannot be penetrated. It is a device on the network, and a badly designed or installed one can be compromised. As the book puts it, it then provides only a false sense of security — which is worse than no firewall at all.
In plain words
The third goal is the one that makes the other two meaningful.
A firewall is a single point that everything must pass. That is exactly what makes it useful, and exactly what makes it worth attacking. A compromised checkpoint is not a neutral outcome — it is worse than no checkpoint, because everyone behind it believes they are protected.
Traditional packet filters
An organisation has a gateway router joining its internal network to its ISP (Internet Service Provider) Internet Service Provider Connects hosts, and other ISPs, to the rest of the Internet. introduced in ch. 1 . Everything crosses that router, and that is where filtering happens.
A packet filter examines each datagram in isolation and decides, from administrator-written rules, whether to pass it or drop it. The decisions can be based on the source or destination IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 address, and on the protocol type — TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 , UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 , ICMP (Internet Control Message Protocol) Internet Control Message Protocol Carries error and diagnostic messages between hosts and routers. A ping is an ICMP message. Covered in §5.6. introduced in ch. 2 , OSPF (Open Shortest Path First) Open Shortest Path First The Internet’s intra-AS link-state routing protocol. Each router builds a complete map of its autonomous system and runs Dijkstra locally. introduced in ch. 5 . They can also use the TCP or UDP source and destination ports, the TCP flag bits such as SYN (synchronize) synchronize The TCP flag bit that marks a connection-establishment segment. Set in the first two segments of the three-way handshake (§3.5.6). introduced in ch. 3 and ACK (acknowledgement) acknowledgement A message, or a header field, saying that data was received correctly. Written ACK in diagrams and code, "acknowledgement" in prose. introduced in ch. 3 , and the ICMP message type. Different rules can apply in each direction and on each router interface.
| Policy | Firewall setting |
|---|---|
Cells marked ⓘ have an explanation — click to read it.
For an organisation on 130.207/16 with its public web server at 130.207.244.203. Each row is a sentence an administrator says, turned into something a router can check.
Each of those is an administrator’s sentence, translated into something a router can check at link rate. Notice how much a policy can achieve with header fields alone — and notice the third row, which the book presents honestly as a blunt instrument.
Where the packet filter fails
Here is the problem, and it has a specific shape.
A filter that lets replies in has to recognise a reply. From the header alone, a reply looks like: TCP, source port 80, ACK bit set. So the rule admits anything matching that description.
An attacker can simply write those fields into a datagram.
Packets arriving at the gateway
| packet | source | destination | proto | flag | verdict |
|---|---|---|---|---|---|
| Malformed packet from an attacker | 150.23.23.155:80 | 222.22.1.7:12543 | TCP | ACK | passes |
| Reply to an inside user browsing the web | 37.96.87.123:80 | 222.22.1.7:12699 | TCP | ACK | passes |
| Inside user opening a web connection | 222.22.1.7:12699 | 37.96.87.123:80 | TCP | SYN | passes |
| DNS reply to an inside resolver | 198.41.0.4:53 | 222.22.93.2:40001 | UDP | — | passes |
| Inbound telnet attempt | 150.23.23.155:40000 | 222.22.1.7:23 | TCP | SYN | dropped |
2 packets get a different verdict from the two filters: Malformed packet from an attacker, DNS reply to an inside resolver. Every other packet is treated identically.
The access control list
| # | action | source | dest | proto | src port | dst port | flag | check conxion |
|---|---|---|---|---|---|---|---|---|
| 1 | allow | 222.22/16 | outside of 222.22/16 | TCP | >1023 | 80 | any | |
| 2 | allow | outside of 222.22/16 | 222.22/16 | TCP | 80 | >1023 | ACK | (ignored) |
| 3 | allow | 222.22/16 | outside of 222.22/16 | UDP | >1023 | 53 | — | |
| 4 | allow | outside of 222.22/16 | 222.22/16 | UDP | 53 | >1023 | — | (ignored) |
| 5 | deny | all | all | all | all | all | all |
This is Table 8.6 and Table 8.8 at once. They are the same five rules; the last column is the only difference, and a stateless filter cannot act on it.
The connection table — unused while stateless
| source address | dest address | source port | dest port |
|---|---|---|---|
| 222.22.1.7 | 37.96.87.123 | 12699 | 80 |
| 222.22.93.2 | 199.1.205.23 | 37654 | 80 |
| 222.22.65.143 | 203.77.240.43 | 48712 | 80 |
Table 8.7 — three connections, all opened from inside the organisation. The filter learns them by watching the three-way handshake, and forgets a connection on a FIN or after about 60 seconds of silence.
Press the button. The access control list does not change and neither does the rule that matches — only whether the connection table is consulted. One packet flips.
Press the button in the widget. The access control list does not change. The rule that matches does not change. The verdict on one packet does.
Why the obvious fix does not work
You might tighten the rule instead — refuse inbound TCP with the ACK bit unless it comes from somewhere you trust.
But an inside user browsing the web receives exactly such packets, from servers nobody could have listed in advance. A stateless list strict enough to block the attack also stops internal users surfing the web, which is precisely the bind the book describes.
The information needed to separate the two cases is not in the packet. It is in the history: did anybody inside actually open this connection?
Stateful filters
A stateful filter tracks ongoing TCP connections in a connection table.
It can do this because the connections are observable. The filter sees the three-way handshake — SYN, SYNACK, ACK — and records the connection; it sees the FIN (finish) finish The TCP flag bit meaning "I have no more data to send". A full teardown uses two, one from each side (§3.5.6). introduced in ch. 3 and removes it. If it sees no activity for, say, 60 seconds, it may conservatively assume the connection is over.
The access control list gains one column: check connection. For rules carrying it, a matching packet is admitted only if the table agrees.
The two cases, traced
The attacker’s packet. Source port 80, ACK set, from 150.23.23.155 to an inside host on port 12543. It matches the rule that admits replies. The filter then consults the connection table, finds no such connection, and rejects it.
The inside user’s web browsing. The user’s TCP SYN went out first, so the connection was recorded. When the server’s packets come back — with the ACK bit necessarily set — the filter finds the matching connection and lets them through, not interfering at all.
Same list, same matching rule, opposite outcomes. That is the entire argument
for stateful filtering, and tools/check-firewall-ch08.mjs verifies both cases
against the shipped matching code.
Application gateways
Packet filtering, stateful or not, is coarse-grained. It works on IP and TCP/UDP headers: addresses, port numbers, acknowledgement bits.
Now suppose an organisation wants to allow telnet out to the world, but only for a restricted set of internal users rather than internal addresses. And only after those users authenticate.
That is beyond any packet filter. The identity of an internal user is application-layer data, and it appears nowhere in the IP, TCP or UDP headers.
An application gateway is an application-specific server that all application data must pass through, so decisions can be made on the data itself.
| Traditional packet filter | Stateful filter | Application gateway | |
|---|---|---|---|
| What it looks at | |||
| Does it remember anything? | |||
| Can it tell a reply from a forgery? | |||
| Can it act on who the user is? | |||
| What it costs |
Cells marked ⓘ have a reason behind them — click to read it.
A ladder, like every other one in this chapter: each sees more than the last, and costs more to run. Click any cell.
Anonymity, from the other side of the same idea
The book closes this section with a case history that inverts everything above. Suppose you want to visit a site without revealing your address to it, and without your ISP (Internet Service Provider) Internet Service Provider Connects hosts, and other ISPs, to the rest of the Internet. introduced in ch. 1 knowing which site you visited or what you exchanged.
Connecting directly fails all three. Using TLS (Transport Layer Security) Transport Layer Security Encryption, integrity and authentication added above TCP, in the application layer. introduced in ch. 2 alone still fails two: your source address reaches the site in every datagram, and your ISP can sniff the destination address of everything you send.
The answer is a trusted proxy plus TLS. You open a TLS connection to the proxy and send your request inside it; the proxy decrypts it, fetches the page, and returns the response over TLS. The site sees only the proxy’s address, and your ISP sees only encrypted traffic to the proxy.
And the proxy knows everything — your address, the site’s address, and all the traffic in cleartext. The solution is only as good as the proxy’s trustworthiness, which is why the Tor anonymizing and privacy service routes traffic through a series of non-colluding proxies instead.
The mental model
A firewall is a checkpoint that decides from what it can see, and the three kinds differ only in how much they are allowed to see.
A packet filter sees one datagram. A stateful filter sees one datagram plus the history of connections it has watched open. An application gateway sees the conversation.
Each step up buys precision and costs work — a table to maintain, or a server in the path of every session. Which is the same trade this book has made in every chapter, arriving one last time at the boundary of a network rather than inside a protocol.
Check yourself
Check yourself
0 of 7 answered1.A firewall has three goals. Which is the one that makes the other two meaningful?
2.predictAn attacker sends a TCP datagram with source port 80 and the ACK bit set, to an inside host on a high port. What does a stateless packet filter do?
3.Why can the rule not simply be tightened to block that attack?
4.How does a stateful filter learn which connections are open?
5.What is the difference between Table 8.6 and Table 8.8 in the book?
6.An organisation wants to allow telnet out, but only for certain internal users, and only after they authenticate. Why is this beyond any packet filter?
7.In the anonymity case history, you use a trusted proxy plus TLS. What does the proxy know?
What to remember
-
A compromised firewall is worse than no firewall, because everyone behind it believes they are protected. That is why immunity to penetration is one of the three goals rather than an implementation detail.
-
The same access control list gives opposite verdicts on the same packet, depending only on whether a connection table is consulted. A forged reply and a genuine one are identical in their headers; only the history separates them.
-
A packet filter cannot act on who a user is, because that information is application-layer data and appears in no header. Filtering on identity requires a server that reads the application data itself.