It is clear after this - our second - round of Web application firewall testing that these products are becoming more capable of addressing application-level exploits. However, the rough edges of these products means it will take significant time and effort by administrators and Web developers to deploy a reasonable security  policy using them.

Teros 100 applies a nice blend of positive and negative firewall model features that should be capable of protecting all but the most sensitive applications. On top of its solid security offering, features that address performance and content safety make Teros 100 the Network World Clear Choice winner.

While it would be possible to set up a similar configuration on the MagniFire product, we found the more explicit approach an encouraging step to securing the unit itself. Access to the Web console is conducted via a Secure Sockets Layer (SSL ) encrypted browser session, but the device does not promote strong passwords, limiting the user to eight characters. The unit does have an increasing wait time on failed attempts, but console security certainly could be improved.

Further configuration is performed via a highly polished Web-based interface. However, that is not to say it is without annoyances. For example, the system's fixed window size presented a professional-looking interface, but rendered the logging interface somewhat useless as full request path entries were often clipped. The data is available, but you are required to export the log. We also found intermittent selection and refresh problems, particularly when we accessed the interface via terminal services and KVM setups. Annoyances aside, we found the interface generally was well executed, and context-sensitive help screens were readily available if needed.

It's important to point out that the product firmly embraces varied roles and management  levels. We found that the division between a device administrator and an application administrator clearly indicates Teros' understanding of the typical communication gap between Web developers and network administrators. Even the documentation was split out into different books to present details relevant to each audience individually. This approach to management makes Teros ideally suited for a multisite hosted environments or large-scale corporation with multiple sites and owners.

Using the Web interface, we found defining protect applications to be very easy, but it was somewhat awkward to address sites with multiple domain aliases. Given the common practice of setting many domains for the same public facing site, we felt this aspect of the interface could be reworked.

Setting the rules

Once a Web application is defined, Teros 100 should be put into a learning mode to monitor user activity and infer an appropriate rule set. While the traffic-based learning approach lets the product quickly understand JavaScript client-side interactions and data types sent via forms easily, the downside is suggested rules might be related to user error or even hack attempt. Tolerance levels defined in the device for observed activity help keep the system from suggesting too many incorrect rules, but it isn't perfect.

Administrators cannot assume that all suggested rules are valid or that observed site traffic will cover the whole application. It is appropriate to observe usage over time and study the Web application carefully to develop a quality security policy.

Once it was set up completely and had time to establish an adequate rule set, we found that the device was capable of detecting and blocking all the common attacks including forceful browsing, SQL injection, form-field tampering, cookie tampering and cross-site scripting.

In addition to the positive firewall model, Teros 100 also features a blacklist of common attack signatures to immediately address common server attacks. The blend of these two approaches is a nice one, but there is a little room for trouble in areas such as buffer overflow  attacks via headers, and URLs were lengths were somewhat larger than expected (such as Error Message 4096). However, these values are easily tunable by a less-trusting administrator.

During testing we encountered one significant configuration headache. When protecting a Microsoft Internet Information Server-based site using SSL, importing the certificate information was awkward because IIS does not use the .PEM format by default, which is common to OpenSSL. It would be nice to see some help here for Windows administrators with either a utility or some documentation to address this. The MagniFire offering shared this headache, and it is likely to be common for any Linux-based security appliance trying to protect a Windows environment.

A particular positive aspect of the Teros offering is that it addresses the unthinkable - site or application breach. A variety of features are included to help mitigate the fallout from potential intrusions or site errors. To thwart site defacement, the device can checksum static pages and not deliver them if modified. We felt it would be better if the device hosted a standby page rather than not responding, but the feature, though incomplete, was still a welcome one.

The Teros device also lets you filter pages for specific words. For example, you might wish to define curse words as "stop" words and define a common legal statement that must be included in all legitimate pages as a "go" word.

Teros also offers some built-in filters to protect against information. And the device can detect for common data formats such as credit card numbers or Social Security numbers. In practice, we found a few glitches in this feature. Under the permissive settings we established at one point, the firewall aggressively matched numeric sequences looking like Social Security numbers that occurred in headers. This match caused Teros 100 to block all subsequent requests to the site because it mangled the cookie it used for integrity checking. Certainly an oversight that needs to be corrected, but despite the rough edges, when used properly, output blocking was an appropriate feature.

Also unique to the Teros 100 are acceleration features including HTTP encoding using gzip, SSL acceleration and connection offloading. Given that application security checks will add some overhead to site response times, it was nice to see some efforts to mitigate the issue. Mixing security and performance features in an appliance form factor follows the trend of generalizing the duties of the front-end devices to Web farms being promoted by vendors such as NetScaler and Redline Networks.

MagniFire can burn potential app hackers

The MagniFire TrafficShield is also a Linux-based appliance that takes a different approach to policy generation and maintenance than the Teros offering. While the strict, positive model MagniFire promotes would suggest even tighter application security, we found it lacks polish and that its implementation could be stronger.

Getting started with the TrafficShield is straightforward. You follow a simple script to define the basic network configuration. More detailed configuring is performed via a Web interface, which we found to be simpler and more approachable than that of the Teros 100, but it is not as well implemented. During testing, consistent user errors occurred because of simple problems such as having similarly labeled "update" buttons next to each other. Some pages were not well organized, and others were very clumsy. We could not turn to the help system for assistance, as it was not functional in the unit we tested. The company promised these interface glitches would be fixed in a forthcoming release slated for late June.

A differentiating aspect of management vs. the Teros offering is that the MagniFire lacks role-based administrative access to the unit or its associated sites. This feature would be sorely missed in a hosted environment or a large-scale enterprise deployment. The company says this also will be addressed in its new release.

Like the Teros 100, the console security could stand some improvement. The MagniFire device does not limit password length and appears to have no countermeasures against excessive password guessing.

Once familiar with the device, you set up a base security policy using a built-in crawler, rather than immediately monitoring user traffic. The crawler is very able, considering the difficulties that can be encountered when crawling a complex site using JavaScript, frames and the like. However, we found the crawler could be fooled by some types of JavaScript usage, including code that is similar to what might be used in a Dynamic-HTML-based navigation system. Fortunately, to address such possibilities you can add entry points and adjust the crawler settings.

After the initial policy is built, you can accept the generated rules right away and begin blocking, but it would be better to let the device monitor actual traffic and learn any extra rules necessary. Regardless of being crawler- or usage-generated, adding rules was easy. And it was sometimes easier to understand MagniFire's suggestions as compared with Teros' regular expression-based system.

Like Teros 100, TrafficShield identified forceful browsing, data tampering and other common exploits. However, we noted that the MagniFire approach emphasizes very tight security policies. Cookie lengths and request lengths are controlled down to the exact length. Unlike Teros 100, where set limits were defined on certain aspects of site usage, TrafficShield leaves little wiggle room for bad data. The only downside of this tight approach is that it makes maintaining the policy arduous.

During penetration testing, we found Teros' approach to field monitoring to be superior overall, but MagniFire was more adept with flow and entry point management. We particularly liked the ability to visualize the flows in the site.

MagniFire could improve how it monitors protected applications. Because TrafficShield does not break out site applications within its logging system, it was difficult to see what was going on at times. We also found the detailed messages in the logs to be generic at times, and single requests showed multiple errors, making it difficult to understand which was the primary trigger. Even in our static Web page testing, we saw befuddling warnings messages, suggesting that too tight of a security policy might result in false positives.

As with Teros 100, there were many items we wished we had control over, including things such as custom HTTP method allow/disallow, which would be required in complex WebDAV-oriented sites. Simple anti-reconnaissance features such as changing the server response headers were not readily available but have to be accessed via an undocumented switch. Error pages also need to be more flexible.We even were required to upload the error page to the device and perform a restart to make it take effect.

In other cases, TrafficShield was over the top in terms of granularity. The system embraced detailed control over character usage in URLs and form inputs, complete with pull-downs for every single ASCII character. While character set attacks are possible, the approach seemed overkill, save to zealous administrators who , for example, wants to filter against the use of the letter "D" in the site.

TrafficShield provides a powerful positive security model, and in the hands of a competent administrator a very strict security posture could be defined and enforced. However, it could be improved with more features including breach mitigation, acceleration and improved device security.

RELATED LINKS

Powell (tpowell@pint.com) is the founder of PINT, a San Diego Web development and consulting firm. He is also the author of numerous books on Web development practices, including JavaScript: The Complete Reference and Web Design: The Complete Reference.

Powell is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.nwfusion.com/alliance.