|
|
| Previous | Table of Contents | Next |
The products evaluated in this section are as follows:
When evaluating firewalls, you should consider products that work on both Unix and Windows NT. For many environments, the operating system under the firewall is largely irrelevant, so you should not let any pre-existing prejudice about operating system color your decision.
You will probably find that your experience with the Windows NT versions will contrast sharply with the Unix-based firewalls. Early firewall vendors included hardware with their software, because setting up the Unix platform to run these products on generic Intel hardware is a major chore. In contrast, the Windows NT platforms are trivial to install.
The flexibility and generality of Unix brings little to the tightly controlled environment of a firewall, while the complexity of dealing with an operating system so picky about hardware configuration makes building a firewall a major chore.
On the other hand, Windows NT has its own problems. For NT-based firewalls that depend on the Microsoft-provided TCP/IP stack (all but Network-1 Software and Technology, Inc.’s Firewall/Plus), some weaknesses exist in the TCP/IP stack. For example, simply bringing up another system with the same IP address as the firewall can lock up Windows NT—and the firewall.
If you are platform neutral, you will probably find Windows NT as a firewall platform generally more favorable than Unix. As firewalls move from specially constructed fortresses by Unix and security gurus to more of a commodity item, NT will become the platform of choice. Most of the products in this chapter (Digital AltaVista Firewall, TIS’s Gauntlet, Network-1 Firewall/Plus, Check Point Firewall-1, Global Internet Centri, and Raptor Eagle) offer the NT option.
In the Opus One tests, the Unix operating system was a major stumbling block to testing.
Livermore Software Laboratories, Inc.’s (LSLI) PORTUS firewall, which was tested on Sun’s Solaris, was the only Unix-based that Opus One was able to bring up in their test labs. Even then, it was necessary to do a considerable amount of hardware fiddling to find a configuration acceptable to Solaris.
The other Unix-based vendors, Secure Computing Corp.’s Borderware, Milkyway Networks’ Black Hole, and Trusted Information Systems’ Gauntlet, all run on Berkeley Software Design, Inc.’s BSDI Internet Server. This Unix was so picky that the standard lab testing systems at Opus One could not work with it.
After BSDI support was unable to make its operating system work on the Opus One hardware, all vendors shipped preconfigured hardware.
As you read earlier, the traditional firewall taxonomy starts with packet filters (such as are built into most routers) and works its way up to application-level proxies that understand and filter at the highest level. In reality, all the products have a mix of technologies. It’s impossible to pigeonhole any one product in a particular niche.
For example, LSLI’s PORTUS is primarily an application-level proxy, but also includes a transport-level proxy (usually called a “plug gateway”), an SMTP relay, and support for SOCKS. SOCKS is a special kind of transport-level proxy that requires customized clients. Global Internet’s Centri, TIS’s Gauntlet, and Check Point’s Firewall-1 mix application and transport-level proxies and relays with additional packet filter capabilities. Raptor’s Eagle, Digital’s AltaVista Firewall, and Milkyway’s Black Hole all include only transport and application-level proxies and relays, while Network-1’s Firewall/Plus ranges across the board concentrating on frame-level filtering but with some very limited application proxy capability.
Firewall products bear the unmistakable stamp of their designers. When it comes to making your network secure, the firewall lets you do only what the designer allows. For example, if you want to authenticate user access through the firewall, Digital’s AltaVista Firewall requires that you use one-time passwords (normally with a hand-held token). If your corporate security policy allows for reusable passwords then forget AltaVista Firewall.
You would have a similar experience with LSLI’s PORTUS if you wanted to use reusable passwords. Not an option. The designer knows what’s secure and won’t let you do the wrong thing—as long as you agree with the designer.
Other restrictions are more subtle. For example, Raptor’s Eagle allows many-to-one connections from the outside, but not many-to-many. This restriction means that if you want to have a news server inside the firewall, you can only have one. For many organizations, even one server is too many. But these highlight the importance of determining your policy and requirements before you select a firewall.
Many of the firewalls have features that may be of use in very special situations. For example, TIS’ Gauntlet has an application-level proxy for lp, a client/server printing protocol. Although other firewalls can pass lp through their firewall (if necessary) using a TCP-level proxy (usually called a “plug gateway”), TIS is the only product that does a true application-level proxy. Of course, not many people would want to print through their firewall. But if you need that option, TIS is the place to get it.
In the same vein, Check Point’s Firewall-1 supports remote procedure call (RPC), which allows mounting of NFS volumes across a firewall (among other things); LSLI’s PORTUS supports a special out-of-band authentication protocol; Milkyway’s Black Hole and TIS’ Gauntlet support X Window System; and Network-1’s Firewall/Plus supports non-IP protocols, such as AppleTalk, IPX and DECnet. If you have an unusual requirement, you may find that only a single product meets your needs.
| Previous | Table of Contents | Next |