Application Layer Filtering

Application proxy firewalls are the most intelligent firewall architecture. By intelligent, we mean that an application proxy firewall can perform the most detailed inspection on data before making a filtering decision. An application proxy firewall can decode and process at the application layer the data contained in packets. Consequently, application proxy firewalls can filter based on the actual application data content. For example, with a packet-filtering firewall, the firewall can merely permit or deny traffic based on data such as the IP protocol in use. So a packet-filtering firewall merely knows whether it should permit or deny HTTP traffic, for example, and processes the traffic accordingly. With an application proxy firewall, however, it not only knows whether it should permit or deny HTTP traffic, it can also be configured to filter based on the type of HTTP traffic. Such a configuration allows an application proxy firewall to interrogate the data and identify malicious web traffic, such as being able to distinguish between normal HTTP traffic and Code Red HTTP traffic, and filter accordingly. This capability gives firewall administrators a tremendous amount of flexibility and control over exactly what traffic will and will not be permitted.

How Application Filtering Works

Application filtering typically functions through the use of processes known as application proxies, application gateways, service proxies, application filters (Microsoft ISA Server 2004 term), or fixups (Cisco term). These application filters typically provide stateful application layer filtering of the data that is traversing the firewall. Generally, the application filters perform two functions:

• Protocol access Protocol access provides a means of permitting secondary connections for protocols and applications that use multiple protocols (for example, FTP, which uses separate and distinct control [TCP port 21] and data (TCP port 20] protocols).

• Protocol security Protocol security is the meat of application filtering and provides the mechanisms by which the application filter protects and inspects the protocols that are traversing the firewall.

Most application filters required dedicated filters to provide for the protocol security functionality. For example, if the firewall is going to filter HTTP traffic, it has to know how to process HTTP traffic at an application layer level. Some common application filters are Simple Mail Transport Protocol (SMTP), Domain Name System (DNS), POP, FTP, HTTP, and Remote Procedure Call (RPC). These filters are, for all intents and purposes, fully functioning processes that can act, function, and process data as if they were actually the SMTP, DNS, POP, FTP, http, or RPC application in question. For example, an application-filtering firewall that is configured for SMTP can typically not only process SMTP traffic, but you can also control the SMTP functions that will or will not be allowed. You could, for instance, allow only HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT commands per RFC 821. And, potentially, you could provide advanced application filtering on SMTP traffic such as spam and antivirus filtering of the SMTP traffic.

In addition, many application layer firewalls provide a generic filtering process that allows for rudimentary configuration for any application that is being filtered. The problem with these generic application filters is that although they may be able to effectively filter any given application, they may not be able to perform all the required functions to adequately filter the given application (because they were not specifically designed for the given application).

The Difference Between Application Filtering and Deep Packet Inspection

Deep packet inspection is sometimes referred to in the same context as application filtering, but some subtle differences force us to treat each method as a separate and distinct method. Whereas application filtering can truly masquerade and provide the application functionality, deep packet inspection is more of an integration of intrusion detection system (IDS) and intrusion prevention system (IPS) functionality into a stateful packet-inspecting firewall. Deep packet inspecting firewalls typically contain a database of attack signatures and attack patterns, just like an IDS/IPS would. In fact, to be brutally honest, deep packet inspection is merely a good marketing term to describe integrating IDS/IPS functionality into the firewall. After all, because the firewall is going to see all the traffic anyway, why not just let it handle the IDS/IPS functionality? This is the thought process behind newer firewalls such as the Cisco Adaptive Security Appliance (ASA) and Juniper Networks Integrated Security Gateways (ISG).

The most important distinction to remember about deep packet inspection is that the firewall typically is not really application aware. Sure, it can determine what constitutes a bad application or protocol (such as HTTP) from its database of signatures, but it cannot actually act and function like an HTTP server, which is what an application-filtering proxy firewall can do.