eEye Digital Security Papers
The Use of Application Specific Security Measures in a Modern Computing Environment
Current computer security practices tend to favor protecting the network as a whole, and avoid the specific issues regarding an application hosted on that network. For instance, a firewall that is configured to support SMTP (Simple Mail Transport Protocol) is rarely designed to deal with any specific implementation details pertaining to SMTP.
This leads to problems with granularity. A traditional solution requires that all external defenses force specific applications to deal with their own security implications. This practice has flaws because not all implementations of a specific service are created equal. By following bug reports and remote attacks on various applications, whether they are web servers, mail servers, IMAP/POP servers or even LDAP servers, you will notice a trend that would alarm any IT administrator.
We feel that it is worth considering the application of a set of "filtering" devices specific to any class of service that is hosted on a network. These devices can be implemented in hardware or software, and their purpose is to understand and protect the hosted service to a degree that traditional methods cannot.
The Internet Threat Model
Traditional packet-filtering firewalls are able to block packets based on specific packet characteristics, such as TCP flags, source IP address, destination IP address, or TCP and UDP ports. They are able to stop packets that do not meet a certain configurable criteria. Even newer state based firewalls still only look at packet information contained in the IP, TCP, or UDP headers. They tend not to look at specific data contained in those packets beyond the headers, and tend not to discern anything related to a specific protocol. The other disadvantage of firewalls is that if they are used to protect public services, by the very nature of the services being public, they must be allowed access by the Internet at large.
Current IDS in widespread commercial use are signature based. This means that the IDS only know to look for attacks that they have been programmed to catch. All new attacks have a "window of opportunity" between the time that an attack is developed and the time that patches are released, a signature is created for that attack by IDS vendors, and the signature is shipped to the network administrators.
This window of opportunity is dependent on numerous factors not in control of application developers, IDS vendors, or network administrators. These factors include disclosure by the hacker underground, leaks in application vendors, or improper bug reporting practices. Evidence of this can be seen in most major security related forums, such as bugtraq or ntbugtraq. Exploits are released for services everyday, sometimes before the vendor has a chance to provide a fix for the problem. There is also a large degree of underground activity, and some security problems are only found after having been actively used, sometimes for months, before they are noticed and released to the proper channels.
Enter the Application Firewall
Application firewalls are systems designed to protect specific services from attack. At its basest form, an application firewall is a reduced application that allows filtering of input for a specific service to allow only desired input. By defining what is acceptable and what is not, it can abort abnormal sessions of a protocol and stop them from continuing on to the actual application. If implemented correctly, this technique can stop not only specific vulnerabilities, but also general classes of vulnerabilities. This allows the application firewall to protect against new vulnerabilities before they are found and exploited. This philosophy should be implemented in service design, but rarely is.
A generic application firewall should take a "less is better" stance. It should be in place to limit the possible inputs to its service. It should understand the underlying protocol and be able to offer a higher degree of protection that a normal firewall. An application firewall will reassemble protocol state information beyond a normal firewall, and can block general classes of attacks (such as buffer overflow attacks and format string attacks) before they are handed off to the actual application for processing. Also, in addition to blocking attacks, application firewalls can also be used to reduce the amount of possible information that an attacker can glean from the system it protects. This means that it should be able to stop or change banner information, often it should allow everything as if normal and just discard it before passing it on to the actual application.
It is important to note that application firewalls must also take special care to make certain that they do not implement any types of new security bugs into the system. The application firewall designer should survey the current state of security and should attempt to lessen the impact of the firewall on the overall system. In reality, a successful application firewall design should not interrupt any normal protocol transaction, while stopping abnormal ones from affecting the actual system.
The New Model of Computer Security
All trademarks are property of their respective owners or holders. Information subject to change without notice
Copyright © 2000 - 2015 AMT Software. All rights reserved.