AppShield edges InterDo in battle of Port 80 filters

1 2 Page 2
Page 2 of 2

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.

The Web interface suffers from the statelessness and latency one would expect from HTTP, and some quirks exist - probably a function of the tricky interprocess communication between the ISAPI extension that supports the user interface and the ISAPI filter that is responsible for actually carrying out the security policies.

Changes to the administration interface do not always seem to take effect immediately or consistently, and some of the integrated reporting and statistical features display disconcerting inaccuracies. For example, a single request generated approximately 60 "requests processed," and a number of common attacks were miscategorized.

In general, eServer Secure struck us as a good example of an entry-level product. In that sense, its most direct competitors in this review are iSecureWeb and SecureIIS. Among those products, eServer Secure does not stand out for having any major flaws (apart from its user interface quirks) but neither does it distinguish itself as superior.

WebApp.secure: Positive model on the cheap?

WebScurity's webApp.secure attempts to bring the benefits of positive-model application firewalls within reach of smaller organizations.

Like most positive-model firewalls, webApp.secure bases its security model on a whitelist of permitted requests called Intended Use Guidelines. In webApp.secure's case, this is a list of legal URLs for the entire site, which is built through the use of what webScurity calls "entry points." Entry points let administrators adjust the relative "porousness" of a site/application, by forcing users to come into it through certain pages but not others and also to control URL jumping within the site.

During configuration, entry points that the administrator has designated are treated as starting points for building the map of permitted URLs and navigational paths between them. Essentially, a trusted user (or script) must navigate from each designated entry point to all the pages that are to be treated as legally accessible from that entry point. From this configuration-time traversal, webApp.secure learns where traffic is allowed to enter the site, and where it is allowed to go, establishing positive-model access control. In theory this should be quite useful in combating exploits that depend on URL jumping and other forceful browsing techniques. However, during testing it didn't always work correctly.

WebApp.secure also shines in protecting against form-field manipulation and in blocking the usual run of common attack signatures. SQL injection and cross site scripting are not well defended against by default, but lexical blocking is available by disallowing specific characters in form field values - an example of where the positive model implementation gives way to standard negative model techniques, with a resulting extra burden on the administrator.

Implemented as a proxy that is controlled via an XML configuration file, webApp.secure also provides a native - but somewhat awkward - Windows GUI for administration. When inspecting the configuration or making changes, we often preferred to access the XML configuration file directly.

The product has a number of shortcomings that suggest a lack of overall polish. The error/block pages are hard-coded, making them impossible to edit. Without such modification, the software immediately tells the potential intruder what kind of countermeasure software is installed. However, Version 2.0 of webApp.secure was released after testing and many of these issues might have been addressed.

MultiNet iSecureWeb focuses on Microsoft's IIS

MultiNet's iSecureWeb also is built with ISAPI technology and intended for deployment on IIS hosts. A proxy site (the "Gateway") is set up to filter incoming requests headed to an origin site. Policy administration is done via a stand-alone interface (the "Studio") that can be installed on a separate box. Studio is a two-pane, native Windows affair. Getting used to navigating around its multi-tab, multi-level tree view control - and learning how to make sense of it all - takes a considerable investment of time and patience.

As for the security capabilities of the default rules, common buffer overflow, the default policies handle the illicit character sequence and directory traversal attacks well. However, neither SQL injection nor form-field manipulations are dealt with adequately.

The predominant approach is clearly negative-model, which limits the reach of the default rule set and makes post-installation configuration a must for a secure setup. At that point, considerable power is available to the administrator - especially one willing to wade through the intricacies of the user interface and, in the case of certain rules, deal with the complexities of regular expression syntax. There is probably no Web-based attack that one cannot stop with an iSecureWeb rule, if you've got the patience and knowledge to create and apply it properly.

Error pages are easily located and edited, a good anti-fingerprinting measure. However, it is all for naught because our installation of iSecureWeb doubled the HTTP headers in every response and certain HTTP response codes lacked the usual response message following the numeric code. Not only does such behavior make a host easy to fingerprint, it raises serious doubts about the soundness of MultiNet's proxy implementation in general. Before running iSecureWeb in a production environment, we would want more assurance that it can be set up in a way that makes it fully HTTP-compliant.

Conclusion

The products we tested fall into two distinct classes. The low-end products -SecureIIS, webApp.secure, iSecureWeb, and eServer Secure - are useful but have configuration or occasional operational problems. SecureIIS - while potentially the least capable - is probably the best bet for someone looking for some simple protection for the most basic attacks. However, for those administrators who want to get serious about application-level protection, it is really only a choice between InterDo and App.Shield, with AppShield having a slight advantage in our assessment. However, both have significant learning curves and might require consulting services for correct usage.

In the final analysis there is a lingering question of whether some of the "exploits" these products protect against shouldn't be dealt with during the Web application development process.

Obviously filtering out bad requests is a wise addition to a Web server, but shouldn't a Web application keep track of field sizes and allowed data directly? It would be less expensive and more effective to design security into a Web application in the first place.

Given Sanctum's recently released developer-focused product AppScan DE, it would seem that even Web application firewall vendors understand the need to have security designed into the application from the start. However, the cost of reworking an existing Web application might be significant enough to make even expensive Web application firewalls cost-effective additions to the Web administrator's security arsenal.

Powell is the CEO of PINT, a Web development and consulting firm in San Diego. He is also the author of numerous Web development books. He can be reached at tpowell@pint.com.

Learn more about this topic

Firewall research center

The latest news, reviews, how-tos and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
1 2 Page 2
Page 2 of 2
Now read: Getting grounded in IoT