Few firewalls belong in only one of these categories, and fewer still exactly match the definition I will offer for any one category. Nevertheless, these definitions reflect the key capabilities that differentiate one firewall from another.

Packet-filtering Firewall

A packet-filtering firewall is a router or computer running software that has been configured to screen incoming and outgoing packets. A packet-filtering firewall accepts or denies packets based on information contained in the packets' TCP and IP headers. For example, most packet-filtering firewalls can accept or deny a packet based on the packet's full association, which consists of the following:

 Source address
 Destination address
 Application or protocol
 Source port number
 Destination port number

All routers (even those that are not configured to filter packets) routinely check the full association to determine where to send the packets they receive. However, a packet-filtering firewall goes one step further: Before forwarding a packet, the firewall compares the full association against a table containing rules that dictate whether the firewall should deny or permit packets to pass.

A packet-filtering firewall scans these rules until it finds one that agrees with the information in a packet's full association. If the firewall encounters a packet that does not meet one of the rules, the firewall will apply the default rule. A default rule should be explicitly defined in the firewall's table and, for strict security, should instruct the firewall to drop a packet that meets none of the other rules.

Rules to Live By. You can define packet-filtering rules that indicate which packets should be accepted and which packets should be denied. For example, you could configure rules that instructed the firewall to drop packets from specific untrusted servers (generally called hosts on the Internet), which you would identify in the table by their IP addresses. You could also create a rule that permitted only incoming e-mail messages traveling to your mail server and another rule that blocked incoming e-mail messages from an untrusted host that had flooded your network with several gigabytes of data in the past.

In addition, you can configure a packet-filtering firewall to screen packets based on TCP and User Datagram Protocol (UDP) port numbers. Configuring a firewall in this way enables you to implement a rule that tells the firewall to permit particular types of connections (such as Telnet and FTP connections) only if they are traveling to appropriate trusted servers (such as the Telnet and FTP server, respectively). However, the success of such a rule depends on a TCP/IP network convention: Servers (and clients) generally run particular TCP/IP applications over particular ports (often referred to as well-known ports), but servers are not required to use these ports.

Low Cost for Relatively Low Protection? The primary advantage of using a packet-filtering firewall is that it provides some measure of protection for relatively low cost and causes little to no delay in network performance. If you already have an IP router with packet-filtering capabilities, setting up a packet-filtering firewall will cost no more than the time it takes to create packet-filtering rules. Most IP routers, including those manufactured by Novell, Cisco Systems, and Bay Networks, can filter incoming and outgoing packets.

Although the cost of a packet-filtering firewall is attractive, this firewall alone is often not secure enough to keep out hackers with more than a passing interest in your network. Configuring packet-filtering rules can be difficult, and even if you manage to create effective rules, a packet-filtering firewall has inherent limitations. For example, suppose you created a rule that instructed the firewall to drop incoming packets with unknown source addresses. This rule would make it more difficult--but not impossible--for a hacker to access at least some trusted servers with IP addresses: The hacker could simply substitute the actual source address on a malicious packet with the source address of a trusted client.

Layer Upon Layer. In addition, a packet-filtering firewall primarily operates only at the network layer of the Open Systems Interconnection (OSI) model. The OSI model, which was developed by the International Standards Organization (ISO), identifies the seven layers at which computers communicate, ranging from the physical media over which they communicate to the applications they use to communicate.

All firewalls rely on information generated by protocols that function at various layers of the OSI model. Knowing the OSI layer at which a firewall operates is one of the keys to understanding different types of firewalls. Generally speaking, the higher the OSI layer at which a firewall filters packets, the greater the level of protection the firewall provides.

Because a packet-filtering firewall generally checks information only in IP packet headers, sneaking packets through this type of firewall is relatively easy: A hacker simply creates packet headers that satisfy the firewall's rules for permitting packets. Beyond that, a packet-filtering firewall cannot detect the contents of a packet.

Circuit-level Gateway

A circuit-level gateway monitors TCP handshaking between packets from trusted clients or servers to untrusted hosts and vice versa to determine whether a requested session is legitimate. To filter packets in this way, a circuit-level gateway relies on data contained in the packet headers for the Internet's TCP session-layer protocol. Because a circuit-level gateway filters packets at the session layer of the OSI model, this gateway operates two layers higher than a packet-filtering firewall does.

Monitoring Handshaking--Circuitously. To determine whether a requested session is legitimate, a circuit-level gateway uses a process similar to the following: A trusted client requests a service, and the gateway accepts this request, assuming that the client meets basic filtering criteria (such as whether DNS can locate the client's IP address and associated name).

Next, acting on behalf of the client, the gateway opens a connection to the requested untrusted host and then closely monitors the TCP handshaking that follows. This handshaking involves an exchange of TCP packets that are flagged SYN (synchronize) or ACK (acknowledge). These packet types are legitimate only at certain points during the session. See the SYNDefender white paper for a more detailed description of the SYN/ACK process.

A circuit-level gateway determines that a requested session is legitimate only if the SYN flags, ACK flags, and sequence numbers involved in the TCP handshaking between the trusted client and the untrusted host are logical.

Pipe Proxies. After a circuit-level gateway determines that the trusted client and the untrusted host are authorized to participate in a TCP session and verifies the legitimacy of this session, the gateway establishes a connection. From this point on, the circuit-level gateway simply copies and forwards packets back and forth without further filtering them.

The gateway maintains a table of established connections, allowing data to pass when session information matches an entry in the table. When the session is completed, the gateway removes the associated entry in the table and closes the circuit this session used.

A circuit-level gateway relies on special applications to perform copy and forward services. These applications are sometimes called pipe (or generic) proxies because they establish a virtual circuit, or pipe, between two networks and then allow packets (generated by one or more types of TCP/IP applications) to pass through this pipe.

Seldom Standalone. Because pipe proxies generally support several TCP/IP services, a circuit-level gateway can extend the number of services supported by an application-level gateway, which relies on application-specific proxies. In fact, most circuit-level gateways are not stand-alone products but instead are packaged with application-level gateways.

Proxy Server Protection. A circuit-level gateway provides one other important security function: It is a proxy server. Although the term proxy server suggests a server that runs proxies (which is true of a circuit-level gateway), the term actually means something different. A proxy server is a firewall that uses a process called address translation to map all of your internal IP addresses to one "safe" IP address. This address is associated with the firewall from which all outgoing packets originate.

As a result, on a network with a circuit-level gateway, all outgoing packets appear to have originated from that gateway, preventing direct contact between the trusted network and the untrusted network. That is, a circuit-level gateway's IP address is the only active IP address and the only IP address that the untrusted network is aware of. Thus, a circuit-level gateway and other proxy servers protect trusted networks from spoofing attacks.

Circumventing Circuits. A circuit-level gateway does have one inherently vulnerable characteristic, however: Once a circuit-level gateway establishes a connection, any application can run across that connection because a circuit-level gateway filters packets only at the session layer of the OSI model. In other words, a circuit-level gateway cannot examine the application-level content of the packets it relays between a trusted network and an untrusted network.

Because a circuit-level gateway does not filter individual packets but blindly relays packets back and forth across established connections, a hacker on an untrusted network could possibly slip malicious packets past the gateway. The hacker could then deal directly with an internal server, such as a WWW server, which may not be as carefully monitored or configured as the firewall itself.

As long as the initial TCP packets exchanged between the trusted WWW server and the untrusted host met the handshaking criteria, the gateway would establish a connection and copy and forward subsequent packets--regardless of their content. To filter the application-level content of individual packets generated by particular services, you need an application-level gateway.