The following article is excerpted from Computer Security Journal, Vol. XII, No. 1, Spring 1996. All rights reserved.

How to Pick a Firewall with the Right Stuff

By Rik Farrow

Imagine, instead of a firewall, a force field as seen in Star Trek.

This invisible barrier has the amazing property that it will pass all forms of matter or energy that are permitted and blocks everything else. You can see the starship, so visible light passes through unimpeded, but the force field stops photon torpedos and other light-based weapons. A prison cell force field permits beings to talk in normal voices through the field while it prevents bodies or phasor fire from passing through. A marvel in flexibility indeed.

Only in science fiction, you say? But isn't this what you want in a firewall, a normally transparent device that passes everything you want passed, blocks everything else, while keeping track of what it is doing and setting off alarms when something is amiss? Really, a firewall is not so far removed from the mythical force field.

This year's firewall matrix attempts to pick out the areas that indicate a product's capabilites in filtering out attacks while passing other data through transparently. We looked for indications of flexibility that do not come at the expense of security, value-added features such as training, source code or built-in encryption, and remote administration and alarm capabilties. While this is not a review of products, or even a comprehensive list of all products, we want to provide you with a good starting point on your search for the perfect force field, er, firewall.

Draw up a list of field requirements

Your search for a firewall best begins with a list of your requirements. These requirements include the protocols and services that must be supported and also requirements for level of security and auditing. Most firewall products can be characterized by a particular level of flexibility and you don't want to chose a product with less flexibility than you require.

The firewall products that support the greatest protocol flexibility include packet filters or circuit gateways. Packet filters look at the header information, which is a part of TCP/IP, and make access control decisions based on this data. TCP/IP headers are standardized, so it is possible to filter packets based the address fields, application protocol (port), and certain flag bits for just about any application.

The flexibility of packet filters comes with certain disadvantages too. The packet filter can be fooled (just because the header information matches a safe service, the data in the packet's payload may not). Router-based packet filters also do a poor job of logging, in some cases reporting only blocked (dropped) packets to another host, which you must provide and manage to handle the logs. While this form of logging is better than nothing, it means that any successful attack will not be reported (those packets were not blocked).

Circuit gateways are a step below application gateways. Another name for a circuit gateway is simply a relay program, because the circuit gateway accepts packets from one host and relays them to another. The circuit gateway can perform access control based on address and protocol, like the packet filter, but can also do more logging, because it can count every character that passes through it. Circuit gateways are always host based, which means they include their own logging and monitoring systems, and can generate alarms. SOCKS, the most popular circuit gateway, also requires that client applications include support for SOCKS.

Application gateways actually implement part of the protocol they support, making gateways very protocol specific (and less flexible). The advantage of application gateways (also called proxy servers) is finer-grained control. Application gateways can be used to allow certain activities, for example, copying a file from an untrusted network, while blocking a user from sending a file to any untrusted network. The circuit gateway or packet filter can be fooled by an attacker who can pass a forbidden protocol through a channel (port address) allowed by the filter or circuit gateway. The application gateway will refuse to permit the passing of one application protocol through a gateway designed for a different protocol.

The tradeoff between these three strategies, then, is greater flexibility in the packet filters versus more security and finer-grained control of a application gateway. Although at first glance it would seem that packet filters would be faster because they are simpler, this is not necessarily true. Many application gateway-based firewalls have shown higher performance than routers, and are a better choice for for access control at Ethernet speeds (10 megabits per second).

Price is always an issue, and seems even more so when it comes to security products. Most of the products listed here fall in the $10,000 to $20,000 range, with some notable exceptions. Remember that these are list prices, and you might pay much more when you add hardware, installation, training, and annual support. If availability of source code is important, see if that adds to the cost too. Annual support was not included in the matrix and ranges from 11 to 15% of the product's initial cost per year.

Control and alarms are key features

Administration of the firewall is a key issue. The task of managing a firewall will probably fall to a network manager whose hands are full. The administration will hopefully be foolproof, obvious, and easy-to-use a tall order indeed. Early firewalls required a lot of expertise in hand-editing configuration files. You'll notice that most of the products listed here include either graphical user interfaces, or at least menu systems to make configuration simpler.

Another important aspect, report generation, should not be ignored. Do you want to see reports listing individual usage of different services, a summary of Web sites visited, or just a report of rejected connection attempts that might indicate a foiled attack? Some firewall products offer all of these features, while others offer none. The matrix includes categories about different report features, and most products produce reports for host-based usage. Only firewalls that can authenticate internal users can be relied upon to generate user-based usage reports.

Notice that not all of products support remote administration through a secure (encrypted) channel. I have found that large organizations install their firewall where their Internet connection is made, and that is usually not a very convenient location. Remote administration becomes essential in these cases. I always look for an encrypted channel for remote administration. One popular vendor's product was compromised last summer when the password they used for remote administration was sniffed, making it possible for an intruder to reconfigure the firewall. Even strong authentication is not enough-TCP/IP sessions can be hi-jacked after authentication.

Alarms must work remotely as well. Having alarm messages silently scrolling off the monitor locked away in a safe location with the firewall is not my idea of an effective system (a stealth alarm). You want alarms to appear not only at the desktop of the firewall's administrator, but a firewall with a capability for remote paging (how often do you find network administrators sitting at their own desks?)

Flexibility is important here too. In Firewalls and Internet Security (Wiley and Sons, New York, NY), Cheswick and Bellovin point out that they quickly tired of attempting to track down every probe of their firewall. Alarms need to be tuned so that significant events, not noise, come to the administrator's attention. Attempts to retrieve the latest pinup from Playboy's Web site shouldn't result in a page to the administrator at four in the morning. Yet a new, never-before-seen attack will hopefully generate an alarm (it will likely be an exceptional event).

Stealth for firewalls is an advantage

In many cases, you want your firewall to be like the force field-invisible until needed. If users can access Internet resources without knowing the firewall is there, the firewall is transparent to those users. If your security policy requires that internal users be authenticated before using the firewall, the firewall will not be transparent, as users must first provide a password to prove their identity. At least one vendor uses a host-based server that identifies users with RFC-931, also known as identd. Identd does not authenticate users, just offers hints as to their identity (the protocol permits responding with ìunknownî as a user name, and can also easily be spoofed).

In most cases, transparency only extends to internal users. You want external users to use a mechanism for strong authentication, such as time-based systems (Security Dynamics), challenge response systems (Digital Pathways, Cryptocard, or S/Key), or some other one-time password system. Password sniffing software is endemic on the Internet today and people who enter re-usable passwords to enter your firewall will have those passwords sniffed. One estimate I have heard is that you should expect to have your password sniffed within two weeks if you use the Internet often, one month if you are an occasional user. Reusable passwords fall into the same category as teletypewriter terminals-obsolete.

Another aspect of a stealth fighter is its offensive capabilties. Firewalls do not have offensive capabilties-they can't shoot back, and really shouldn't drop bombs on attackers either. Most firewalls refuse connections that they have been configured not to accept. Launch-ing munitions at the offending site would not be a good idea, as most competent at-tackers use many levels of redirection be-fore probing a target site. One firewall vendor talks about striking back, but the site they will most likely reach is not the attacker's home base, but a surrogate site used to hide the attacker's true origin. You could compare this to launching rockets at a building with mirrored windows being used by an attacker to reflect a laser beam.

Another technology that is becoming both more popular and important is encryption. Many firewall products will transparently encrypt all of the traffic between two sites. Encryption can be used to protect the contents of transmitted packets from being disclosed or modified. Important things to look for in encryption capabilities are the types of encryption and methods for key exchange offered.

If you choose firewalls or devices that utilize a private encryption algorithm, you'll have two problems. First, you must use the same vendor's product at every site with which you want to exchange encrypted communications. Second, creating a good encryption algorithm is very difficult, and cryptologists never recommend using private, unpublished algorithms because they may have problems the authors did not anticipate.

Key exchange is also a compatibility issue. Some firewall products rely on manual key distribution, which is difficult even when used between just a few sites, and totally un-manageable when the number of sites is large. On the other hand, if the firewall product uses one of the emerging standards for key distribution, such as SKIP, Photuris, or X.509 key certificates, then interoperability with other products becomes possible.

Raise shields

While force fields appear to be quite flexible in science fiction, firewalls are often a lot less flexible. Certainly you want a product that supports all of the protocols in your requirements. But what if you need something that is not supported by the product? Packet filters make it fairly easy to add new protocols, but with less security. Circuit gateways such as SOCKS will support just about any new application protocol as long as support for SOCKS can be compiled into the application.

Application gateways, on the other hand, must be written to support the new application. Products that include source code make this process easier-if you have a competent in-house development team. If they can write an application with a new protocol, the same folks could, working from secure examples, create a new application gateway for it. You could also pay the vendor to create a new application gateway, but this may turn out to be a slow and expensive process.

All in all, it makes sense to look before you leap into choosing a firewall product. The last thing your organization needs is to have Klingons materializing behind your force fields.

Rik Farrow has worked with the UNIX system since 1982, and has written two books, UNIX Administration Guide to System V (Prentice Hall, 1989) and UNIX System Security (Addison-Wesley, 1991). Since 1986, he has taught courses on UNIX security and system administration for conferences, user groups and businesses in the U.S. and Europe. He is former technical editor of UNIX Worldís Open Computing and still writes for several trade publications. Farrow has been self-employed for 15 years providing consulting services through his firm Internet Security Consulting. He recently received highest ratings by attendees for his presentation at CSIís 22nd Annual conference, and is author and instructor of CSIís newest class on Internet security.