
Cisco Systems Cisco PIX Firewall 520
The performance of the PIX was by far the best of all the products. It achieved a throughput rate of 150 Mbps, which was only slightly slower than what we achieved on our baseline, with just a crossover cable between both switches. What was even more remarkable was that activating NAT did not slow down the performance. Unfortunately, the management capabilities did not fare nearly as well and were the worst of all the products we tested. We were impressed that PIX could block potentially harmful SMTP commands, but for FTP it was not able to regulate puts and gets as most of the other products did.
Most of PIX's management is best done via the command line. The good news here is that if you are one of the many who are at home with a Cisco router command-line interface, you might not be bothered by the lack of a slick management GUI. In fact, it is probably no coincidence that many of the commands and operations are very similar to those on a Cisco router. We found that setting up NAT was especially easy using the command line, and was even easier than using most of the GUIs. But we found it very awkward to set up anything except very simple security policies involving access based on services, hosts and networks. The biggest problem occurred whenever we had to make a change in the security policy that involved reordering the rules; the original list of rules had to be removed before inserting a new list from scratch. This is one feature carried over from Cisco routers that provides no advantages.
PIX came with a management application, but it required that an NT server be dedicated to run the software that could then be accessed via the Web. When using the Web interface to manage PIX, we could only look at the configuration and make very simple changes. Cisco told us it is coming out with new software by the end of this year that should improve PIX's management capabilities.
Logging and monitoring were also much weaker on PIX than on all the other products. There was no real-time logging, and all the logging information had to be sent to another machine running syslog. However, it was possible to set up alerts based on the syslog events.
NetScreen Technologies NetScreen-100
Like Cisco's PIX, NetScreen-100 runs a proprietary OS. Unlike PIX, which runs on Intel hardware, NetScreen uses proprietary ASICs to provide a high-performance firewall that is both inexpensive and easy to install. We found installation to be a simple matter of assigning IP addresses to the interfaces via a serial connection. Once this was accomplished, we performed all further tasks via a Netscape or Microsoft browser.
Only PIX and FireWall-1 topped NetScreen-100's performance without running NAT. With NAT activated, however, the NetScreen box suffered no degradation and beat out FireWall-1.
The NetScreen firewall was the only one that could pass packets without routing them. With this feature, any hosts or routers behind the firewall continue to use the gateway address of the Internet router or any other router providing access to an external network. This eliminates the need to add another subnet between the firewall and the external router. It also makes it unnecessary to move the external router's address to the internal interface of the firewall, so internal hosts need not change their gateway address. We successfully ran routing both through normal firewall procedures and through this transparent mode of operation.
The network access controls on the NetScreen firewall were among the weakest of all the products. In fact, aside from URL filtering and FTP, we determined that it was not capable of anything more than simple packet filtering.
NetGuard Guardian 3.0 Firewall for Windows NT
Guardian was the only product that came installed on an NT box. Despite its straightforward user interface, its access-control capabilities were better than only NetScreen's.
Guardian's performance was the worst of all the firewalls we tested. When we revealed the results to NetGuard, it appeared to be genuinely surprised. As a result, we reinstalled the software and carefully repeated the configuration. Yet after retesting, we saw no improvement. NetGuard offered to send us another machine to test, but we had run out of time. We did agree to share the fact that when NetGuard's firewall was tested by KeyLabs, using its "Firebench" product, it achieved throughput of over 60 Mbps--which was 50 percent better than the 40 Mbps tallied on our tests. KeyLabs' performance was observed on a 200-MHz machine, while we ran it on a 233-MHz machine. After activating NAT, performance degraded seriously on the NetGuard product. Based on our testing, you should have no problem supporting multiple T1s or 10-Mbps Ethernet even with NAT turned on, but you would want to be careful about pushing it any further.
Guardian's interface was similar to FireWall-1's. We defined networks and hosts as objects that could be added to filtering rules in a table. The table used simple icons to indicate actions that would be performed on traffic that matched the rules. Although it did not equal FireWall-1, we found it easy to define access rules. The user interface could be run from any NT or Windows95/98 machine, and it was easy to remotely manage the NT machines running the firewall engine.
The access-control features were fairly rudimentary. While better than NetScreen-100, Guardian was not able to achieve anything more than simple access control based on IP address and port number. It was also the only product without IPSec-compatible VPN capabilities. One unique feature of the NetGuard was the ability to monitor for invalid telnet login attempts.
Peter Morrissey is a network systems programmer at Syracuse University. Send your comments on this article to him at ppmorris@syr.edu.
|