Types of Firewalls
Firewalls have a wide range
of capabilities. Types of firewalls include
packet filtering gateways or screening routers
stateful inspection firewalls
Each type does different
things; no one is necessarily "right" and the others
"wrong." In this section, we examine each type to see what it is, how
it works, and what its strengths and weaknesses are. In general, screening
routers tend to implement rather simplistic security policies, whereas guards
and proxy gateways have a richer set of choices for security policy. Simplicity
in a security policy is not a bad thing; the important question to ask when
choosing a type of firewall is what threats an installation needs to counter.
Because a firewall is a type of host, it often
is as programmable as a good-quality workstation. While a screening router can
be fairly primitive, the tendency is to host even routers on complete computers
with operating systems because editors and other programming tools assist in
configuring and maintaining the router. However, firewall developers are
minimalists: They try to eliminate from the firewall all that is not strictly
necessary for the firewall's functionality. There is a good reason for this
minimal constraint: to give as little assistance as possible to a successful
attacker. Thus, firewalls tend not to have user accounts so that, for example,
they have no password file to conceal. Indeed, the most desirable firewall is
one that runs contentedly in a back room; except for periodic scanning of its
audit logs, there is seldom reason to touch it.
Packet Filtering Gateway
A packet filtering gateway or screening router
is the simplest, and in some situations, the most effective type of firewall. A
packet filtering gateway controls access to packets on the basis of packet
address (source or destination) or specific transport protocol type (such as
HTTP web traffic). As described earlier in this chapter, putting ACLs on
routers may severely impede their performance. But a separate firewall behind
(on the local side) of the router can screen traffic before it gets to the
protected network. Figure 7-34 shows a
packet filter that blocks access from (or to) addresses in one network; the
filter allows HTTP traffic but blocks traffic using the Telnet protocol.
For example, suppose an international company
has three LANs at three locations throughout the world, as shown in Figure 7-35. In this example, the router has two
sides: inside and outside. We say that the local LAN is on the inside of the
router, and the two connections to distant LANs through wide area networks are
on the outside. The company might want communication only among the three LANs
of the corporate network. It could use a screening router on the LAN at
22.214.171.124 to allow in only communications destined to the host at 126.96.36.199
and to allow out only communications addressed either to address 188.8.131.52 or
Packet filters do not "see inside" a
packet; they block or accept packets solely on the basis of the IP addresses
and ports. Thus, any details in the packet's data field (for example, allowing
certain Telnet commands while blocking other services) is beyond the capability
of a packet filter.
Packet filters can perform the very important
service of ensuring the validity of inside addresses. Inside hosts typically
trust other inside hosts for all the reasons described as characteristics of
LANs. But the only way an inside host can distinguish another inside host is by
the address shown in the source field of a message. Source addresses in packets
can be forged, so an inside application might think it was communicating with
another host on the inside instead of an outside forger. A packet filter sits
between the inside network and the outside net, so it can know if a packet from
the outside is forging an inside address, as shown in Figure 7-36. A screening packet filter might be
configured to block all packets from the outside that claimed their source
address was an inside address. In this example, the packet filter blocks all
packets claiming to come from any address of the form 100.50.25.x (but, of
course, it permits in any packets with destination 100.50.25.x).
The primary disadvantage of packet filtering
routers is a combination of simplicity and complexity. The router's inspection
is simplistic; to perform sophisticated filtering, the filtering rules set
needs to be very detailed. A detailed rules set will be complex and therefore
prone to error. For example, blocking all port 23 traffic (Telnet) is simple
and straightforward. But if some Telnet traffic is to be allowed, each IP
address from which it is allowed must be specified in the rules; in this way,
the rule set can become very long.
Stateful Inspection Firewall
Filtering firewalls work on
packets one at a time, accepting or rejecting each packet and moving on to the
next. They have no concept of "state" or "context" from one
packet to the next. A stateful
inspection firewall maintains state information from one packet to another
in the input stream.
One classic approach used by
attackers is to break an attack into multiple packets by forcing some packets
to have very short lengths so that a firewall cannot detect the signature of an
attack split across two or more packets. (Remember that with the TCP protocols,
packets can arrive in any order, and the protocol suite is responsible for
reassembling the packet stream in proper order before passing it along to the
application.) A stateful inspection firewall would track the sequence of
packets and conditions from one packet to another to thwart such an attack.
Packet filters look only at
the headers of packets, not at the data inside the packets. Therefore, a packet
filter would pass anything to port 25, assuming its screening rules allow
inbound connections to that port. But applications are complex and sometimes
contain errors. Worse, applications (such as the e-mail delivery agent) often
act on behalf of all users, so they require privileges of all users (for example,
to store incoming mail messages so that inside users can read them). A flawed
application, running with all users' privileges, can cause much damage.
An application proxy gateway, also called a bastion host , is a firewall that simulates the (proper) effects of
an application so that the application receives only requests to act properly.
A proxy gateway is a two-headed device: It looks to the inside as if it is the
outside (destination) connection, while to the outside it responds just as the
An application proxy runs
pseudoapplications. For instance, when electronic mail is transferred to a
location, a sending process at one site and a receiving process at the
destination communicate by a protocol that establishes the legitimacy of a mail
transfer and then actually transfers the mail message. The protocol between
sender and destination is carefully defined. A proxy gateway essentially
intrudes in the middle of this protocol exchange, seeming like a destination in
communication with the sender that is outside the firewall, and seeming like
the sender in communication with the real destination on the inside. The proxy
in the middle has the opportunity to screen the mail transfer, ensuring that
only acceptable e-mail protocol commands are sent to the destination.
As an example of application
proxying, consider the FTP (file transfer) protocol. Specific protocol commands
fetch (get) files from a remote location, store (put) files onto a remote host,
list files (ls) in a directory on a remote host, and position the process (cd)
at a particular point in a directory tree on a remote host. Some administrators
might want to permit gets but block puts, and to list only certain files or
prohibit changing out of a particular directory (so that an outsider could
retrieve only files from a prespecified directory). The proxy would simulate
both sides of this protocol exchange. For example, the proxy might accept get
commands, reject put commands, and filter the local response to a request to
To understand the real
purpose of a proxy gateway, let us consider several examples.
A company wants to set up an
online price list so that outsiders can see the products and prices offered. It
wants to be sure that (a) no outsider can change the prices or product list and
(b) outsiders can access only the price list, not any of the more sensitive
files stored inside.
A school wants to allow its
students to retrieve any information from World Wide Web resources on the
Internet. To help provide efficient service, the school wants to know what
sites have been visited and what files from those sites have been fetched;
particularly popular files will be cached locally.
A government agency wants to
respond to queries through a database management system. However, because of
inference attacks against databases, the agency wants to restrict queries that
return the mean of a set of fewer than five values.
A company with multiple
offices wants to encrypt the data portion of all e-mail to addresses at its
other offices. (A corresponding proxy at the remote end will remove the
A company wants to allow
dial-in access by its employees, without exposing its company resources to
login attacks from remote nonemployees.
Each of these requirements
can be met with a proxy. In the first case, the proxy would monitor the file
transfer protocol data to ensure that only the price list file was accessed,
and that file could only be read, not modified. The school's requirement could
be met by a logging procedure as part of the web browser. The agency's need
could be satisfied by a special-purpose proxy that interacted with the database
management system, performing queries but also obtaining the number of values
from which the response was computed and adding a random minor error term to
results from small sample sizes. The requirement for limited login could be
handled by a specially written proxy that required strong user authentication
(such as a challengeresponse system), which many operating systems do not require.
These functions are shown in Figure 7-37.
The proxies on the firewall
can be tailored to specific requirements, such as logging details about
accesses. They can even present a common user interface to what may be
dissimilar internal functions. Suppose the internal network has a mixture of
operating system types, none of which support strong authentication through a
challengeresponse token. The proxy can demand strong authentication (name,
password, and challengeresponse), validate the challengeresponse itself, and
then pass on only simple name and password authentication details in the form
required by a specific internal host's operating system.
The distinction between a
proxy and a screening router is that the proxy interprets the protocol stream
to an application, to control actions through the firewall on the basis of
things visible within the protocol, not just on external header data.
A guard is a sophisticated
firewall. Like a proxy firewall, it receives protocol data units, interprets
them, and passes through the same or different protocol data units that achieve
either the same result or a modified result. The guard decides what services to
perform on the user's behalf in accordance with its available knowledge, such
as whatever it can reliably know of the (outside) user's identity, previous
interactions, and so forth. The degree of control a guard can provide is
limited only by what is computable. But guards and proxy firewalls are similar
enough that the distinction between them is sometimes fuzzy. That is, we can
add functionality to a proxy firewall until it starts to look a lot like a
Guard activities can be quite
sophisticated, as illustrated in the following examples:
A university wants to allow
its students to use e-mail up to a limit of so many messages or so many
characters of e-mail in the last so many days. Although this result could be
achieved by modifying e-mail handlers, it is more easily done by monitoring the
common point through which all e-mail flows, the mail transfer protocol.
A school wants its students
to be able to access the World Wide Web but, because of the slow speed of its
connection to the web, it will allow only so many characters per downloaded
image (that is, allowing text mode and simple graphics, but disallowing complex
graphics, animation, music, or the like).
A library wants to make
available certain documents but, to support fair use of copyrighted matter, it
will allow a user to retrieve only the first so many characters of a document.
After that amount, the library will require the user to pay a fee that will be
forwarded to the author.
A company wants to allow its
employees to fetch files via ftp. However, to prevent introduction of viruses,
it will first pass all incoming files through a virus scanner. Even though many
of these files will be nonexecutable text or graphics, the company
administrator thinks that the expense of scanning them (which should pass) will
Each of these scenarios can
be implemented as a modified proxy. Because the proxy decision is based on some
quality of the communication data, we call the proxy a guard. Since the
security policy implemented by the guard is somewhat more complex than the
action of a proxy, the guard's code is also more complex and therefore more
exposed to error. Simpler firewalls have fewer possible ways to fail or be
Firewalls typically protect a
(sub)network of multiple hosts. University students and employees in offices
are behind a real firewall. Increasingly, home users, individual workers, and
small businesses use cable modems or DSL connections with unlimited, always-on
access. These people need a firewall, but a separate firewall computer to
protect a single workstation can seem too complex and expensive. These people
need a firewall's capabilities at a lower price.
A personal firewall is an application program that runs on a
workstation to block unwanted traffic, usually from the network. A personal
firewall can complement the work of a conventional firewall by screening the
kind of data a single host will accept, or it can compensate for the lack of a
regular firewall, as in a private DSL or cable modem connection.
Just as a network firewall
screens incoming and outgoing traffic for that network, a personal firewall
screens traffic on a single workstation. A workstation could be vulnerable to
malicious code or malicious active agents (ActiveX controls or Java applets),
leakage of personal data stored on the workstation, and vulnerability scans to
identify potential weaknesses. Commercial implementations of personal firewalls
include Norton Personal Firewall from Symantec, McAfee Personal Firewall, and
Zone Alarm from Zone Labs (now owned by CheckPoint).
The personal firewall is
configured to enforce some policy. For example, the user may decide that
certain sites, such as computers on the company network, are highly
trustworthy, but most other sites are not. The user defines a policy permitting
download of code, unrestricted data sharing, and management access from the
corporate segment, but not from other sites. Personal firewalls can also
generate logs of accesses, which can be useful to examine in case something
harmful does slip through the firewall.
Combining a virus scanner
with a personal firewall is both effective and efficient. Typically, users
forget to run virus scanners daily, but they do remember to run them
occasionally, such as sometime during the week. However, leaving the virus
scanner execution to the user's memory means that the scanner detects a problem
only after the factsuch as when a virus has been downloaded in an e-mail
attachment. With the combination of a virus scanner and a personal firewall,
the firewall directs all incoming e-mail to the virus scanner, which examines
every attachment the moment it reaches the target host and before it is opened.
A personal firewall runs on
the very computer it is trying to protect. Thus, a clever attacker is likely to
attempt an undetected attack that would disable or reconfigure the firewall for
the future. Still, especially for cable modem, DSL, and other "always
on" connections, the static workstation is a visible and vulnerable target
for an ever-present attack community. A personal firewall can provide reasonable
protection to clients that are not behind a network firewall.
Comparison of Firewall Types
We can summarize the
differences among the several types of firewalls we have studied in depth. The
comparisons are shown in Table 7-8.