Sneak Preview: Forum Systems XWall

I tested the first 64-bit version of the XWall (5.3) in our Green Bay, Wis., Real-World Labs®. The software runs on almost any platform, including both 32- and 64-bit versions of Windows, IBM AIX, Linux and Sun Solaris (x86 and SPARC hardware). My test version came pre-installed on a 64-bit Linux appliance--a half-length, 1U hardware chassis with dual AMD 64-bit processors, 4 GB of RAM, dual Gigabit Ethernet NICs and a single 10/100 Ethernet management port--with the ForumOS riding atop the stripped-down distribution.

Using the command line, I powered up the XWall and configured basic networking to make the administrative Web console accessible on the network. I then used the Web console and its wizard-like task-based navigation to configure the XWall to protect back-end Web services. XWall's service setup is similar to that of other proxy-based SOAP security products: I had to access the service's WSDL (Web Service Definition Language) and secure all or selected operations exposed by the service.

XWall, which rejects infected messages, ships with a default antivirus gateway--the open-source Clam--but can be configured to work with other antivirus products, including CA Antitrust. Support for additional antivirus products is planned for future releases. XWall antivirus services must be enabled globally, and then can be excluded at the service or operation level (this setup avoids poorly configured updates taking down your system).

Pick Your Security Level

Nearly every security-configuration option is available at the service level as well as the operational and message levels, meaning that you can apply options globally or you can allow exceptions. This is useful in a scenario in which only one or two services must accept extremely large attachments; you can apply a global default size limit on messages, which then can be overridden at the service or operation level for particular services. This option protects services from DoS (denial-of-service) attacks using oversized payloads or attachments, and improves overall performance by not requiring extremely large messages to be parsed.

I configured the XWall to protect four basic doc/lit Web services emulated by a Spirent Reflector 2500. I set up specific operations across the services using the same base configuration we used in a recent review of XML gateways. These operations required message validation, protection against SQL-based attacks and service authorization through the use of WS-Security headers. I used the Spirent Avalanche 2500 to simulate no more than 2,000 concurrent clients (though XWall can support more) and blasted the XWall with both valid and invalid traffic. The XWall's performance was acceptable (see chart at right). However, its performance wasn't as impressive as that of Forum's Sentry.

Infected Files

Once I had some base performance numbers, I reconfigured the test and set up clients to send SOAP 1.2 messages with 10-KB attachments; half contained a known virus and half were clean. No other traffic was sent. XWall processed an average of 565 messages per second while correctly rejecting messages with virus-laden payloads, and incurred an average latency of only 260 msec.

CPU performance appeared to max out (based on my analysis of traffic patterns), but the XWall offers no mechanism for monitoring CPU utilization aside from SNMP traps, so I couldn't verify this. Forum engineers agreed the appliance was likely running at 99 percent of CPU utilization based on performance metrics.

Simple Firewall Setup

XWall's administrative interface and control options are impressive. The extensive firewalling settings can be applied globally, per service, per operation or even on a per message (input or output) basis, and almost all are explained in plain English.

To assign IDP rules to services or operations, just click the check box next to the rule indicating the desired granularity. I created a rule based on incoming message rates, choosing to block messages from any IP address from which more than 10 messages per minute were received, and then assigned the rule to the input message for the Echo operation. Using a test client, I fired off 11 messages in quick succession, and the 11th request from the same IP address was denied, as expected. You also can set up blocks by IP address or user. Administrators can configure XWall to automatically deny traffic that comes from an IP address in violation of a rule for a specified period of time, or manually unblock traffic through the admin console.

Actions also can be configured based on corporate policy. You can choose to block access or control access through rate limiting. The actions are then used in IDP policies, which are, in turn, applied to services, operations or messages.

You can even set rules based on WS-I compliance--an unusual feature. These rules normally would be used for testing and debugging clients. Forum doesn't suggest using this feature in a production environment due to the adverse impact on performance. The extraordinarily thorough information returned from a WS-I compliance check pinpoints problems with incoming documents. I configured the Echo service to require WS-I compliance and then modified the incoming message to remove the charset attribute on the incoming XML. XWall identified the missing charset attribute as the reason the document failed to comply and rejected the message with a SOAP fault indicating the problem.

The Forum XWall may be expensive, but when it comes to securing your network prevention is worth twice the price of a cure.

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. Write to her at [email protected].