Firewalls Explained - Part 1 Published: Nov 19, 2003

• Rating

  4/5

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.

[pagebreak title='Firewall Types Continued']
Application-level Gateway

Like a circuit-level gateway, an application-level gateway intercepts incoming and outgoing packets, runs proxies that copy and forward information across the gateway, and functions as a proxy server, preventing any direct connection between a trusted server or client and an untrusted host. However, the proxies that an application-level gateway runs differ in two important ways from the pipe proxies that a circuit-level gateway uses:

 The proxies are application specific.
 The proxies can filter packets at the application layer of the OSI model.

Application-specific Proxies. Unlike pipe proxies, application-specific proxies accept only packets generated by services they are designed to copy, forward, and filter. For example, only a Telnet proxy can copy, forward, and filter Telnet traffic. If a network relies only on an application-level gateway, incoming and outgoing packets cannot access services for which there is not a proxy. For example, if an application-level gateway ran FTP and Telnet proxies, only packets generated by these services could pass through the firewall. All other services would be blocked.

Application-level Filtering. Unlike a circuit-level gateway, an application-level gateway runs proxies that examine and filter individual packets, rather than simply copying them and blindly forwarding them across the gateway. Application-specific proxies check each packet that passes through the gateway, verifying the contents of the packet up through the application layer (which is the highest layer) of the OSI model. These proxies can filter particular kinds of commands or information in the application protocols the proxies are designed to copy, forward, and filter.

Application gateways can also restrict specific actions from being performed. For example, the gateway could be configured to prevent users from performing the FTP put command. This command lets users write to the FTP server. Prohibiting this action can prevent serious damage of the information stored on the server.

Transparency--Ah, There's the Rub! An application-level gateway is one of the most secure firewalls available, but some vendors (usually those that market stateful inspection firewalls) and users claim that the security an application-level gateway offers has a drawback--lack of transparency. Ideally, an application-level gateway would be as transparent as it is secure. Users on the trusted network would not notice that they were accessing Internet services through a firewall. In reality, however, users often experience delays or must perform multiple logins before they are connected to the Internet or an intranet via an application-level gateway.

Although most vendors claim that application-level gateways are transparent, many vendors recommend that you configure the gateway to require user authentication before users access an untrusted network, a process that foils true transparency.

Some firewall vendors that market products as application-level gateways have tried to overcome the transparency problem. For example, one particular application gateway uses a version of the SOCKS protocol (rather than application-specific proxies) to route TCP/IP services. SOCKS is a proposed Internet Engineering Task Force (IETF) standard that provides transparent authentication services for clients requesting connections to devices through firewalls. However, a SOCKS server is not transparent to network administrators: You must modify the applications running on each client that will use the firewall.

Also, although SOCKS includes other security features (such as private-key and public-key encryption), it does not filter individual packets. Therefore, the products that rely on SOCKS might fall justifiably into the realm of circuit-level gateways rather than application-level gateways.

Stateful Inspection Firewall

A stateful inspection firewall combines aspects of a packet-filtering firewall, a circuit-level gateway, and an application-level gateway. Like a packet-filtering firewall, a stateful inspection firewall operates at the network layer of the OSI model, filtering all incoming and outgoing packets based on source and destination IP addresses and port numbers.

A stateful inspection firewall also functions as a circuit-level gateway, determining whether the packets in a session are appropriate. For example, a stateful inspection firewall verifies that SYN and ACK flags and sequence numbers are logical.

Finally, a stateful inspection firewall mimics an application-level gateway: The firewall evaluates the contents of each packet up through the application layer and ensures that these contents match the rules in your company's network security policy.

Better Performance, Same Level of Security? Like an application-level gateway, a stateful inspection firewall can be configured to drop packets that contain specific commands. For example, you could configure a stateful inspection firewall to drop FTP packets containing a Put or Get command.

Unlike an application-level gateway, however, a stateful inspection firewall does not break the client-server model to analyze application-layer data. An application-level gateway requires two connections: one connection between the trusted client and the gateway and another connection between the gateway and the untrusted host. The gateway then relays information between the two connections. Although some people insist that this configuration ensures the highest degree of security, other people argue that this configuration slows performance unnecessarily.

A stateful inspection firewall, on the other hand, does not require two connections, allowing a direct connection between a trusted client and an untrusted host. To provide a secure connection, a stateful inspection firewall intercepts and examines each packet up through the application layer of the OSI model.

Rather than relying on application-specific proxies (and thus limiting users to the services for which you are running a proxy), a stateful inspection firewall relies on algorithms to recognize and process application-layer data. These algorithms compare packets against known bit patterns of authorized packets and are theoretically able to filter packets more efficiently than application-specific proxies.

Because a stateful inspection firewall allows a direct connection between a trusted client and an untrusted host, some people believe this firewall is less secure than an application-level gateway. However, other people argue that using a direct connection makes a stateful inspection firewall perform better than an application-level gateway at no cost to security.

What's Out There? A stateful inspection firewall is a popular solution for securing Internet and intranet connections because this firewall is transparent to users, scrutinizes data at the highest OSI layer, and does not require you to modify clients or run a separate proxy for each service that runs over the firewall. In fact, Check Point Software Technologies, Ltd.'s FireWall-1, which is one of the most popular commercial firewalls, is a stateful inspection firewall. Credited with coining the term stateful inspection, Check Point began selling FireWall-1 in 1993 and now owns 44 percent of the firewall market.Don't be Careless. Stateful inspection firewalls are among the most secure firewalls available today and "fooling them can be a lot of work," according to Jon McCown, a network security analyst for the U.S. National Compter Security Agency (NCSA).

Nevertheless, stateful inspection firewalls, like all firewalls are not 100 percent effective. So why bother implementing a firewall at all? You should implement a firewall for the same reason you protect your home by locking your doors, despite the fact that this safey measure does not guarntee that an intruder cannot enter your house. Leaving an Internet or intranet connection without a firewall is a careless, open invitation to would-be intruders.

Keep an eye out for Part 2 of Firewalls Explained coming soon!