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,
N
OOP, 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.