as part of a router, although a personal firewall may be implemented on an end-user machine. Firewall-based security depends on the firewall being
the only connectivity to the site from outside; there should be no way to bypass the fi rewall via other gateways, wireless connections, or dial-up connections. The
“ wall ” metaphor is misleading in the context of networks since it is the absence of connectivity—not the presence of a barrier—that prevents communication. In terms
of walls, a firewall is like the only door (connection) through a wall (the absence of any other connection). A firewall provides access control by restricting which
messages it will relay between the site and the rest of the network; it forwards messages that are allowed, and filters out messages that are disallowed. For example, it
might filter out all incoming messages addressed to a particular IP address or to a particular TCP port number.
In effect, a fi rewall divides a network into a more-trusted zone internal to the
fi rewall, and a less-trusted zone external to the firewall. This is useful if you do not
want external users to access a particular host or service within your site. Much
of the complexity comes from the fact that you want to allow different kinds of
access to different external users, ranging from the general public, to business
partners, to remotely located members of your organization. A firewall may also
impose restrictions on outgoing traffic, to prevent certain attacks and to limit
losses if an adversary succeeds in getting access inside the firewall.
Firewalls may be used to create multiple zones of trust , such as a hierarchy of
increasingly trusted zones. A common arrangement involves three zones of trust:
the internal network, the demilitarized zone (DMZ) , and the rest of the Internet.
The DMZ is used to hold services such as DNS and email servers that need to
be accessible to the outside. Both the internal network and the outside world
can access the DMZ, but hosts in the DMZ cannot access the internal network.
Therefore, if an adversary succeeds in compromising a host in the exposed DMZ,
it still cannot access the internal network. The DMZ can be periodically restored
to a “ clean ” state.
Firewalls filter based on IP, TCP, and UDP information, among other things.
They are configured with a table of addresses that characterizes the packets they
will, and will not, forward. By addresses, we mean more than just the destination’s
IP address, although that is one possibility. Generally, each entry in the table is a
4-tuple: It gives the IP address and TCP (or UDP) port number for both the source
and destination.
For example, a firewall might be confi gured to fi lter out (not forward) all packets
that match the following description:
<>
This pattern says to discard all packets from port 1234 on host 192.12.13.14
addressed to port 80 on host 128.7.6.5. (Port 80 is the well-known TCP port for
HTTP.) Of course it’s often not practical to name every source host whose packets
you want to fi lter, so the patterns can include wildcards.
For example,
<*,*,128.7.6.5, 80>
<*,*,128.7.6.5, 80>
says to fi lter out all packets addressed to port 80 on 128.7.6.5, regardless of what
source host or port sent the packet. Notice that address patterns like these require
the fi rewall to make forwarding/fi ltering decisions based on level 4 port numbers,
in addition to level 3 host addresses. It is for this reason that network layer fi rewalls
are sometimes called level 4 switches .
In the preceding discussion, the fi rewall forwards everything except where
specifi cally instructed to fi lter out certain kinds of packets. A fi rewall could
also fi lter out everything unless explicitly instructed to forward it, or use a mix
of the two strategies. For example, instead of blocking access to port 80 on host
128.7.6.5, the fi rewall might be instructed to only allow access to port 25 (the
SMTP mail port) on a particular mail server,
for example,
<*, *,128.19.20.21,25>
but to block all other traffi c. Experience has shown that fi rewalls are very frequentlyconfi gured incorrectly, allowing unsafe access. Part of the problem is that
fi ltering rules can overlap in complex ways, making it hard for a system administrator
to correctly express the fi ltering she intends. A design principle that maximizes
security is to confi gure a fi rewall to discard all packets other than those
that are explicitly allowed.
Many client-server applications dynamically assign a port to the client. If a client
inside a fi rewall initiates access to an external server, the server’s response
would be addressed to the dynamically assigned port. This poses a problem: How
can a fi rewall be confi gured to allow an arbitrary server’s response packet but disallow
a similar packet for which there was no client request? This is not possible
with a stateless fi rewall , which evaluates each packet in isolation. It requires a
stateful fi rewall , which keeps track of the state of each connection. An incoming
packet addressed to a dynamically assigned port would then be allowed only if it
is a valid response in the current state of a connection on that port.
Modern fi rewalls also understand and fi lter based on many specifi c applicationlevel
protocols such as HTTP, Telnet, or FTP. They use information specifi c to that
protocol, such as URLs in the case of HTTP, to decide whether to discard a message.