Home --> IAQ -->

Packet Filter vs. Proxy Firewalls

By Jeffrey Howard
All rights reserved unless noted otherwise

On a mailing list I read, someone asked the difference between three types of firewalls: packet filters, stateful packet filters, and proxies. To some extent, the motive behind the question was to evaluate which of the three is most secure. What is most secure is a matter of what you're trying to protect, and what you're trying to protect against, and judgment. The differences between the types of firewall are a matter of how they operate.

Packet Filters

A packet filter sits between the internal network and the rest of the world. Clients and servers connect directly, but the packets pass through the packet filter to travel between the internal network and the outside world. When packets pass through, the packet filter compares the packets to a set of filter rules. If the configuration is set up to permit a packet, it continues its travels through the network, forwarded on to its next hop. If the configuration does not permit the packet, it is discarded. (Optionally, some firewalls will send a notice to the source of the that the packet was rejected or log the action.)

Typically, the comparison performed by the packet filter involves the source address, the source port, the destination address, and the destination port. Filtering on source and destination addresses grants control over who may communicate with the internal network. All traffic from undesirable networks can be screened out. Ports, on the other hand, are used to distinguish network services. By filtering out a port, it is possible to deny the outside world access to a service offered on the internal network.

Stateful Packet Filters

Stateful Packet Filters are very similar to packet filters, offering a slightly expanded functionality. Stateful packet filters (SPFs) keep some state about each connection passing through them. The SPF is supposed to have built-in knowledge about TCP/IP's rules for data flow between the two hosts. The extra advantage is that an SPF can detect incorrectly sequence numbered packets or inconsistent IP protocol options. The security benefit is protection against some attacks involving bugs in network handling code on the host's part.

A more significant advantage is that attackers cannot send packets that fraudulently appear to be part of an existing connection. With a regular packet filter, an attacker could start sending packets from port 80 on the attacker's machine. Since port 80 is a permitted source from the outside world (to permit web traffic), that packet would pass right through the firewall to destination machines on the protected network, even though those machines didn't initiate a connection to the attacker. The problem is even greater with UDP; assuming the packet filter permits UDP DNS queries to port 53, the attacker may send UDP packets from port 53 to ports on machines behind the firewall. A stateful packet filer, because it keeps state on what connections have been initiated by hosts inside the firewall, can reject these spurious packets.

Some people express reservations about the marketing hype of SPFs vs. the reality. In general, unless a feature of a networking protocol has been used as an attack vector, most companies won't think to keep state about it or filter based on it. Therefore, the protection afforded by SPFs from new methods of attack may not match the claims in the marketing brochure.

From a strictly theoretical viewpoint, SPFs shouldn't understand the application data inside packets; that functionality is found in full application proxies. In practice, some hybrid systems, still calling themselves SPFs or Stateful Inspection Packet Filters, will look at the first few packets of a new flow and act upon the data inside.

Proxies

On networks with packet filters, a connection is formed directly between the client and the server. Proxies break up the connection between the client and the server. To the server, the proxy pretends to be the client. To the client, the proxy pretends to be the server. No direct communication takes place between the client and the server. If an attacker tries to play tricks by working with fragmented packets or fields in the IP packet, the internal server never sees it. Additionally, proxies have access to all the application data in the protocol. A proxy can therefore check the legality of traffic between the client and server. For example, a web proxy can check the legality of a GET command before passing it on to a server.

That said, the reality is not as bright as what proxies could do. In practice, few proxies actually do analysis of the application protocol. Most proxies mindlessly copy the protocol data across from one connection to the other.

So What?

Everything is a matter of "if", "maybe", and "depends on your configuration". But all else being equal, proxies can be more secure than filters. Filters just look at the protocol level information in the packet. Application proxies look at the contents of the data flow. For example, a web application proxy should look at the GET request being sent to your server and ensure that it's a valid request. And because no traffic travels directly to the server from the client (or vice versa), neither has to worry about the other's tampering with the structure or options of the network protocol packets. However, filters are less resource consumptive in terms of RAM and CPU usage. Filters are also less complicated, which may allow for better code auditing or easier configuration.

While these are good philosophical, theoretical, and maybe even theological answers, there's nothing saying that one must settle on a single firewall technology. Some people choose to use some combination, or even all three types of firewall technologies. It may seem like overkill, but it's a common enough philosophy to have earned its own buzz-phrase: defense in depth. The doctrine of defense in depth is that more layers of defense makes for more difficulty on the attacker's end. Why merely require attackers to bypass a packet filter when you can require them ot bypass a packet filter and then break through a proxy firewall as well?

A counter-argument says that proxies are not significantly more secure. The reasoning behind the counter-argument is that most attacks are on the application layer are data-driven. A data-driven attack is a perfectly legitimate message within the rules of the application protocol. However, a server or client receiving that message will act on the data in such a way that compromises the system. These attacks often depend on bugs in the client or server. Proxies are not sufficient to catch these bugs if they are limited to enforcing the rules of the application protocol. Proponents of this viewpoint tend to use SPFs or regular packet filters, relying on hardening the hosts attached to the network individually, rather than placing their trust in a firewall.

Another argument for hardening host security rather than worrying about the details of the firewall technology used cites that firewalls are, quite simply, a less effective tool than they used to be. The reasoning is that protocols like HTTP already permit CGI, scripts, Java, Javascript, and plug-ins of all types. Even if a firewall restricts traffic to something supposedly innocuous, like web traffic and mail, technologies like ASP, Javascript, MIME attachments, and more are still quite capable of wreaking absolute havoc if the end system is not secured in its own right.

But, I didn't promise an easy answer, merely a definition of three types of firewall and a comparison of them.

In the... what... years?... since I first wrote this, many proxy firewalls have become more potent. Many of them will actually inspect the contents of a data flow. For example, there are proxy filters that will inspect mail and screen out messages with viruses. This doesn't make proxy firewalls a panacea — what about the virus the proxy isn't build to catch? But they have evolved significantly from their first appearance on the market.