A new class of products - often-dubbed Web application firewalls - attempt to thwart Port 80 focused attacks by using blacklist- and whitelist-style input filtering. See how six products rated in our tests
Traditional firewalls - when properly configured and managed - do a good job of thwarting many network-level attacks, but do little to address gaping holes in Web applications where intruders commonly attack Web sites directly through form submissions or URL manipulations.
A new class of products - often-dubbed Web application firewalls - attempt to thwart Port 80 focused attacks by using blacklist- and whitelist-style input filtering. We examined six software-based offerings: eEye Digital Security's SecureIIS, KaVaDo's InterDo, MultiNet's iSecureWeb, Sanctum's AppShield, Turillion Software's eServer Secure and webScurity's webApp.secure. We tested all the products on Microsoft's Internet Information Services (IIS) but most also work with Linux and Apache. A future review will cover hardware-based products.
InterDo and AppShield stood above the rest in terms of ability to defend against attacks and suitability for large-scale Web site deployments. While extreme flexibility is the key to InterDo, the dynamic policy generation and strong default configuration of AppShield gave it a slight edge in our evaluation and earned it our World Class award.
Common attack methods come into play
To understand Web application firewalls you have to understand what they attempt to defend against. The most basic application attacks modify an HTTP request to cause a problem on the server or force it to divulge useful information. Generic attacks might use long URLs to trigger buffer overruns, attempt to traverse the site's root directory to run trusted commands, or exploit extended HTTP features to support online collaboration using WebDAV. WebDAV (Web-based Distributed Authoring and Versioning) is an extension of HTTP that lets users collaborate via the Internet.
More sophisticated attacks rely on knowledge of how the Web application works. In database-driven sites using dirty URLs like http://www.sitename.com/app.asp?id=5, SQL commands might be appended to the URL in an attempt to dump useful data or gain write access to the back-end database. Forms also might be open for SQL injection, and tampering with hidden data fields and manipulation of maximum data size limitations, which can lead to buffer-overrun problems. Given the multitude of possible attack methods, any data from the user - be it a simple HTTP request, URL or form submission - should not be trusted implicitly.
Divergent defensive strategies
To combat potential exploits, a Web application firewall will take one of two approaches. A negative model or blacklist product looks for common attack signatures and warns the administrator or blocks the user when it encounters one. A positive-model or whitelist firewall determines all the allowable requests, and inputs and disallows everything else. Some products try to blend the two approaches, but, essentially, all the products tested emphasize either a positive or negative model.
A few of the products also addressed common Web server information leakage issues such as masking server headers or sending back generic or configurable error pages. It was disconcerting, however, to see how easy it was to identify some of the application firewall products via hard-coded error pages or telltales (some signature response that is different enough for the intruder to know what kind of tool is in play) in response headers. Trying to improve security simply by obscuring potentially dangerous information is not true security. Such blatant information leakage seems foolish in a security product and fails to address the well-known fact that reconnaissance is a key part of successful intrusion strategies.
These tested products spread an obvious spectrum of cost vs. functionality. Those employing the positive model generally are more expensive and sophisticated than the products that use the negative-model approach. Another key cost factor is the underlying architecture. EServer Secure appears intended for single-server implementations, while AppShield, InterDo and webApp.secure serve more as proxies, capable of protecting multiple servers. Higher-end products AppShield and InterDo also possess remote-management capabilities and distributed architectures, features designed with server farm deployments in mind.
Raise your AppShield
Sanctum's AppShield boasts a fully distributed architecture designed for server farm deployments. Components include a crisp Java-based management console, a configuration server (mysql is used for database support) and one or more firewall nodes.
AppShield uses a positive model built around what Sanctum calls its Dynamic Policy Recognition Engine. Outgoing pages are scanned and the appropriate whitelist of allowable inputs is constructed accordingly. Such dynamic policy generation is a considerable help in getting the product up and running quickly, and maintaining security policies as the site/application changes. The general policy defaults put in place when one chooses the desired security level are easily loosened by browsing or crawling the site using a trusted IP address, if you find that the default level is too strict for a site or application.
AppShield has a "passive mode" that logs but does not block requests that would violate policy. This mode lets policies be tested, which the administrator can modify selectively in real time by right-clicking the request that is in violation. If there are multiple AppShield nodes deployed in a server farm, the passive mode role could be permanently given to a single node. That node could then serve as a monitor or honeypot for the entire farm. In general, AppShield gets high marks for ease of configurability.
AppShield's dynamic policy generation worked well to prevent forceful browsing by automatically restricting traffic patterns to legitimate navigation paths and limiting form-field tampering. AppShield's default policies, however, were more restrictive than other products tested when it came to preventing simple SQL injection. The default policies also block standard attacks such as buffer overruns, directory traversals and suspicious URLs. For preventing repeated attacks that violate security policies, AppShield can notify a Check Point firewall using the Open Platform for Security (OPSEC) standard that a particular IP should be blocked at the network level.
Customizable error pages are provided, but there are some shortcomings. Although the error page is passed with an HTTP reason code to display, the page itself is retrieved using a redirect, meaning that the underlying HTTP response code is always a 302 (a redirect) followed by a 200 (Ok) - not the code that reflects the actual state of the response. Like many of the firewalls, AppShield runs fast and loose with HTTP response codes, which is troubling from standards compliance and raises the possibility that potential hackers might fingerprint the security software in place from non-standard responses.
On a side note, AppShield takes advantage of being a proxy to provide some interesting security-oriented features that go beyond the usual menu of application firewall options: URL mapping (including regular express matching) and the ability to globally prohibit direct downloading of image and multimedia files, often dubbed "leeching." This interesting feature suggests the possibility of application firewalls eventually merging with authorization and access-control functionality to provide a complete application security framework.
InterDo can do
KaVaDo's InterDo was designed with a large distributed deployment in mind. One or more server nodes communicate with the Java-based management console via built-in Secure Sockets Layer (SSL) encryption - a feature none of the competing products equal. The application server nodes run as a set of services (in the Windows environment).
Although there is no central configuration server, administration of all nodes can be done from a single console. Strict password requirements and the ability to set up multiple users with different administrative privileges show that InterDo is serious about keeping its house in order, while supplying security for the Web application.
InterDo uses a positive-model approach with some novel architectural concepts. Trusted and untrusted zones are joined by what KaVaDo calls "tunnels," an abstraction describing a connection between trusted and untrusted IP address and port combinations. Within the metaphor of a tunnel, security policies are segregated into functional areas called "pipes," several of which can be combined within a single tunnel and selectively applied to one or more applications in a configurable order of precedence. Examples of pipes include general vulnerabilities (URL, header and entity pattern matches), database issues (parameter screening), cookies and HTTP methods. Default pipes do a good job with common buffer overruns, directory traversals and SQL injection. The default settings did not stop form manipulations by default, but it is possible to set up custom tunnels and rules.
InterDo gives administrators a great deal of flexibility in configuring security policies - more so than any other product we tested. On the downside, initial configuration is nowhere near as easy as AppShield's and is probably best undertaken only after reading the manual very carefully.
There is a "lean mode" that lets administrators monitor and selectively modify certain pipes in real time, and requests that run afoul of the security policies are blocked while these refinements are made. This is a safe and helpful way to manage the complexity of configuring multiple pipes.
Another helpful management feature is the update service that can securely update pipes in real time using SSL and digital signatures.
InterDo has an IP-blocking feature that temporarily prevents continued access from visitor IP addresses that have generated enough security policy violations to constitute a suspect pattern of malicious behavior. Suspect attackers are given a security score (high, medium or low) and blocked for varying durations. The response to further requests from a blocked IP is simply a dropped connection, but it might be better - especially for Level 1 attacks - to have the option to show the possibly malicious user a configurable message. For those with a Check Point firewall, InterDo is also OPSEC-compatible for firewall-based network blocking.
SecureIIS: URLScan on steroids
EEye Digital Security's SecureIIS has by far the best user interface of all the products tested. The program uses an interface similar to Microsoft Outlook's that makes configuring this negative-model application firewall trivial. Unfortunately, SecureIIS lacks the depth of many of the other products and appears to do little beyond what a capable administrator could do with Microsoft's free URLScan tool.
While SecureIIS could deal with malformed requests exceeding size limits and basic URL tampering, it couldn't detect and block any form tampering or careful SQL injection.
Furthermore, the product sent back the inappropriate 406 "Not Acceptable" HTTP response code on request rejection, rather than 403 "Forbidden" or 404 "Not Found" message, as it probably should. This is the wrong response code and informs a potential intruder that SecureIIS is being used.
SecureIIS does have some nice features to ease deployment in a multi-server environment by letting policies easily be replicated to other systems. The product also has some basic file-integrity monitoring features that could be useful if an intruder penetrated a machine, but they seem out of place in an application firewall offering.
SecureIIS is targeted at users looking to have the support and ease of use missing from URLScan. Interestingly, eEye recently announced a free personal-use version of its software that makes this product an obvious replacement for URLScan and obvious first step for those IIS administrators new to application firewalls.
EServer Secure for the entry level
Turillion's eServer Secure is designed specifically for the IIS Web server environment. Based on Internet Server Application Program Interface (ISAPI) technology, eServer Secure combines a host-based architecture with the flexibility of a Web-based management interface.
This is a strictly negative-model firewall, with a respectable blacklist of attack signatures that are blocked by default - long URLs, disallowed methods and directory traversals, for example - and the ability to revise these policies for tighter security. These attacks were blocked as expected.
SQL injection can be combated, but this is addressed through keyword filtering, and you likely will want to strengthen the default policies to make them more robust. This product does not obviously address manipulation of form-field sizes. An update subscription service is offered to keep the attack signatures current. Error pages are fully configurable.
The HTTP management interface is a convenient way to handle remote administrative duties but is also a liability. Security for remote management is provided via basic IP filtering. This is a nice feature, but the wise user most likely will want to employ SSL as well to further secure communication with the firewall.
When reporting on Friday’s DDoS attack, the national media should have warned consumers not to install...
The attacks that overwhelmed the internet-address lookup service provided by Dyn today were well...
By forcing Windows 10 on users, Microsoft has lost the tenuous trust and credibility users had in the...
Sponsored by AT&T
Everyone wants to know what the new Macs will have, and you need look no further than what's already...
Speculation is starting about what company Silver Lake will sell Avaya to. Here’s a look at companies...
What every citizen should know about the state of our voting systems and the security of our elections....
A Q&A on what caused the Dyn DDoS attacks and what to do to protect yourself and your network.