Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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.

  • 1