Although FireWall-1 is not considered a proxy type of firewall, its stateful inspection capabilities approach those of a proxy firewall. For example, in addition to NAT, it offers user authentication and defends against SYN and packet-fragmentation attacks. FTP restrictions can be implemented based on "put" and "get" commands as well as file names. For SMTP, you can limit commands and arrange to drop any mail beyond a certain size. Mail also can be scanned for viruses, and information in the mail header revealing details about the internal network can be stripped before the mail leaves the internal network. FireWall-1 also prevents potentially harmful SMTP commands, such as "debug," from being executed. While these features were impressive, the SMTP proxy in Raptor's product goes a step further and limits the size of e-mail headers on incoming mail to prevent buffer overrun attacks.

FireWall-1 also scans HTTP traffic for ActiveX and Java applets, and implements URL filtering based on a manually entered file or integrated with third-party URL filtering services. Raptor's HTTP proxy again goes further by limiting the size of URLs to avoid buffer overflow attacks. And since it is actually running HTTP server code, only valid HTTP syntax is permitted.

FireWall-1's user interface provides a centralized point of control that makes it easy to define and implement a complex security policy. All related hosts, networks and services are defined as objects with associated icons. It's easy to nest objects within groups that can be represented with their own icons. These icons can then be used when defining rules. Other icons representing various levels of logging and alerting also can be specified by each individual rule.

Each rule has a comment field for adding invaluable documentation, a feature we use extensively at Syracuse University. Months or years down the road, it could be helpful to know why a particular rule was specified, as well as the date and even the name of the person who added the rule. Version 4.0 adds the ability to enter a rule, then comment it out with a red "X." We also temporarily hid rules with this version, making long sets of rules easier to read. A nice user interface like this can't guarantee security, but it can save you time and decrease the likelihood of making a mistake. It also makes it easier to train others to administer the firewall. The GUI also lets you control numerous FireWall-1 modules remotely, and can be used to manage and implement filtering for Bay Networks, Cisco and 3Com Corp. routers, and even the Cisco PIX firewall.

We launched the Log Viewer from the FireWall-1 policy editor. Depending on the selected level of logging, the viewer shows source and destination addresses, and ports associated with each rule, all with a time-and-date stamp. All this information is sorted into easy-to-read columns--all entries representing accepted packets were displayed in green text, while all entries representing dropped or rejected packets showed up in red. With a few points and clicks, we were able to customize what was displayed in the Log Viewer. For example, by displaying only log entries of dropped and rejected packets, we easily detected attempts at unauthorized access. This can be a great way to troubleshoot a sudden disturbance in desirable communications through the firewall--the log will show you the IP addresses involved as well as the intended service. And you can be sure that any time a desirable communication is interrupted, a newly installed firewall will be one of the primary suspects. The only other product that even came close to FireWall-1's logging information was AXENT's Raptor. But though Raptor's logs were quickly updated and were fairly detailed, the columns were not formatted, and there was no color-coding, making them much harder to read.

NAT was the one area where the FireWall-1 user interface disappointed us. To set up a static mapping, for example, you had to go in and out of a number of network object definition windows. After the map was set up, rules were automatically generated that could be displayed in a rules window very similar to that of the policy editor. Two rules were generated for each mapping and we found it very difficult to understand the configuration simply by looking at the display. We also had to go to the Unix command line and set up a route for every mapping. By contrast, even though Cisco's PIX had generally inferior management features, its one-line command for setting up NAT was far easier to understand. Moreover, while FireWall-1's performance when running NAT was still better than that of any of the proxy firewalls--including Raptor, which came installed on the same Solaris Ultra 2 platform--it was measurably slower than without using NAT. Check Point did warn us before our testing that activating NAT would affect performance.

Through its OPSEC (Open Platform for Secure Enterprise Connectivity) program, Check Point provides APIs for third-party vendors to develop products that can be integrated into the firewall. As a result, more than 100 products complement FireWall-1's built-in features with content security, intrusion detection, fault tolerance and reporting capabilities. FireWall-1 uses a macro language, called "Inspect," for building stateful inspection macros. This makes it possible to define new services even for complex new protocols, though the average user probably won't delve into this. It also enables Check Point to define protocols for new services that can be easily downloaded from its Web site and loaded into the firewall.