The following article is excerpted from the Computer Security Journal, Vol. XI, No. 2, Fall 1996. All rights reserved.

POINT/COUNTERPOINT: What kind of firewall should you buy?

By Richard Power

The Spring '95 Computer Security Journal (CSJ) "Special Report on Firewalls" featured CSI's "Firewall Product Matrix," an in-depth interview with firewall architect, Marcus Ranum of Network Flight Recorder (Baltimore, MD). In the Fall '95 CSJ, our editorial coverage of the firewall story takes another twist-we've pitted Ranum and another Internet security whiz, Andrew Molitor of Network Systems Corp. (Minneapolis, MN), against each other in a Point/Counterpoint on "What Kind of Firewall You Should Buy?"

There has been a proliferation of different types of firewall solutions: packet filters, dynamic packet filters, circuit relays, application gateways. The question is, "Can the market support all of these types? Will there be a shake-out? Is there a future for all these types? Should someone who has or is about to buy into one be concerned?

Molitor: Yes, yes, yes, and yes. There's room for a lot of network security technology. The vendors must, however, move away from trying to sell single box solutions, and work toward integrating their box(es) with other technology. Customers should be architecting future network growth to be more secure and should be demanding that each box they buy integrate with the current network and help move the network toward a more secure architecture.

Ranum: I agree 100% with Andrew. There's a proliferation of products on the market and I think it will shake itself out and mature soon. It has to. When a technology gets "hot" it attracts the attention of folks who just want to cash in on the fad. I think we'll start to see products come onto the market that are badly designed by people who don't really understand computer security, just because there's a perceived market. When that happens, something's got to give: either the market turns into a cesspool or it matures and the maturing process requires a shake-out.

Maturing a market means that a couple of things happen. Some standards and terms need to emerge and product prices need to somewhat even out. Right now, there are products priced all over the map and customers buy them based on the "more expensive must mean more secure" model, which simply doesn't apply-yet. But nobody has told the customer that. Someone buying a firewall should look four years ahead and not much farther. I know that sounds like heresy, but who would have predicted the Web four years ago? I remember, four years ago, I had just bought a new 386... These are not technologies we're going to pass on to our grandchildren.

Let's talk about the differences in approach between application-level firewalls and router firewalls?

Molitor: Application-level firewalls are good for perimeter firewalling, where performance is a low priority. Since they operate at a high level, it's relatively easy to make them work with really strong user level authentication and so forth. This is, however, a rather minor role in network security; it is a deadly mistake to decide that dropping a box in on your perimeter is going to make your network secure. Router based firewalls (that is, packet filtering technology) tends to have higher performance, so it's appropriate where performance is more important-for example, in firewalling one LAN or group of LANs from another to form intra-enterprise compartments. In these contexts, user-based authentication is often not really necessary, since access policies are more often phrased in terms like 'only mail traffic is permitted between marketing and engineering,' whereas perimeter firewalling policies are more likely to have clauses like "Joe is allowed to FTP in from the outside if he uses S/Key authentication." Packet filtering technology can easily handle policy of the first sort and do so both quickly and transparently.

Ranum: I think there's a lot of emphasis on the corporate firewall and what Andrew points out is correct: there's a lot of good cases for internal firewalling and internal network segregation. Anyone who has actually managed a network can tell you it makes them more reliable, too! Packet filtering is extremely fast and convenient but it may not be flexible enough for some uses. A number of my customers, for example, want to be able to know not just how much e-mail went into and out of the company's network, they want to know who the top senders and recipients were. It may not be because they want to audit it; it could simply be because management wants to know. I've seen a number of cases where this kind of thing pays off: one site had a firewall installed and instantly some guy started mailing out multimegabyte messages. Turns out he was "borrowing" a copy of a compiler.

A firewall that works at just a network level can only base its access control decisions on the information in the packet. An application level firewall can base access control decisions on a whole lot more, including the data that is going across the application stream.

What we're seeing, of course, is that firewalls are converging between application level and packet screening. The last application level firewall I built had extensive hooks into the operating system, in order to better take advantage of information available at the routing layer! More screening router-based firewalls will begin to monitor the traffic or state of the applications going across them. I seem to recall Andrew presented a paper recently that certainly hints he's working on adding much "higher level" capabilities into his router's screening rules.

Could you go into the pros and cons of each?

Molitor: Packet filtering is generally fast and transparent, but does not easily permit user-level policy to be implemented, nor does it easily allow for strong auxiliary authentication to be used. Packet filters are simpler and hence can be more easily deployed enterprise-wide. That is, given an enterprise-wide access policy defining what groups can use the networks for what purposes, it is relatively easy to deploy packet filtering in the existing routers and manage the access policy by managing the deployed filtering. Application firewalls, on the other hand, are add-on systems that are typically more difficult to manage individually, making them more expensive and considerably more difficult to manage as vehicles for an enterprise-wide access policy. In general, an application firewall is a one-box object out on the edge of the network that provides certain network security services, but does not integrate coherently with the rest of one's network security systems. It winds up being something of a management headache, since it's a strange, idiosyncratic little box that works differently from everything else on the network.

Ranum: It's probably because I'm a good C programmer and a terrible router programmer, but I find most router access control rules to be as easy to read as APL code or a plate of spaghetti. They can be terribly simple but often they're insanely complex! Of course, the C source code for your average application level firewall (if you get to look at it) is probably not light bedtime reading, either. Many of the application level firewall vendors are focusing on making integrated products that have nice management interfaces, which automatically generate reports and traffic summaries, etc.

I guess the main thing to recognize is that the router vendors are attacking two targets. One: they need a router that is super fast and cheap and gets packets from here to there. Two: sure, let's use it as a firewall too, and support some screening. For a big router vendor, only a small subset of the units they sell are going to be used for screening. It's just not their focus, and the router vendors aren't likely to be able to put the effort necessary into making their router a nice firewall. The folks who are building application level firewalls are working on making an integrated security product and usually performance is secondary. So they tend to be slower. Speed of firewalls is a touchy subject. I don't know of any reputable scientific testing that has been published on the topic. It's a tough problem.

For sure, your average application level firewall is not going to handle T3 or ATM speeds. On the other hand, your average network level firewall is not going to send the system manager mail when it detects someone guessing passwords trying to log into it.

Does what you want to do (or not do) with your Internet connection impact at all whether you choose an application-level firewall or router firewall?

Molitor: Probably not. What should matter more is what you have to protect. In general, using packet filtering to provide a protective barrier between you and the Internet will probably be more transparent and less difficult to manage. On the other hand, if you have requirements for access control that include strong authentication, high quality auditing, or some sort of application level data filtering (e.g. virus detection on inbound data, confidential data detection for outbound traffic), a packet filtering firewall is not going to be able to meet those requirements as easily. From the point of view of your users, either system can provide fairly seamless access to the Internet and either can provide reasonable confidence that you are protected to the level that you think you are. Depending on what level and kind of protection you need, one or the other or both will be appropriate.

Ranum: Andrew's absolutely right! Start with requirements, then worry about the implementation details like performance, what color the box is, etc.

What happens altogether too often is that requirements analysis gets completely ignored in favor of sexy technology or technical predispositions. A memo comes from on high: "buy a T1 line and a firewall; I want to surf the Web." The actual requirement (to surf the Web) gets buried by all the many choices that are out there. That echoes the first question about whether the market will or will not bear all these different techniques and products. The market won't settle down until people start to actually think about what they want to do before they decide on a technology! As Andrew says-both technologies fit a niche. Right now, if the primary criteria are speed and transparency, a router is great. If you need detailed audit logs, authentication and traffic reporting, then a router isn't going to cut it.

In a lot of cases, putting in a firewall is when you need to reasses what you're trying to do! I know one organization that staunchly insists they cannot put any security between their network and the Internet because they need to transfer huge amounts of data though the network link, many times a day, to a large number of business partners. When you point out that they could put a big data dump outside their network and secure it and get all that traffic off their internal network suddenly you see the light come on.

Does one or the other lend itself to a particular environment?

Molitor: This really goes back to what you have to protect or what your firewall requirements are. Before deploying any sort of network security technology, one must get some sort of handle on what one has to protect and what constitutes protection.

The plans for hydrogen bombs are things one absolutely cannot afford to have in the hands of random people and certain classes of people will aggressively try to pry them out of your network. Your plans for the soon-to-be-patented WidgetTronic are something you want to protect, but you probably do not have to worry about super spies hacking your network to get them. They will be a matter of public record as soon as the patent is granted, so it is not necessary to protect them for all time. The "Buy IBM now!" order is sensitive, but has a life span of seconds or minutes.

The hydrogen bomb plans should probably be protected on a physically secured network with cryptographic authentication required to do anything on the network. The plans for the WidgetTronic should be on a file server protected from the general public by a good solid firewall. The buy order may just need protection from the general public actually watching packets on your network.

Ranum: Router-based firewalls are best for a really dynamic environment where lots of things change in a short time frame. After all, that's what routers are designed to cope with. Application level firewalls, generally, are better if you're taking a more deliberate approach to what you're doing.

One of the things that scares me a lot is whiz-bang new services that crop up. Instantly someone is going to open a hole in the firewall and let them through because they're new, they're cool, and nobody has found a problem with them yet. All that flexibility you get with packet level systems is sometimes dangerous. With most of the application-level firewalls out there you need to actually do something to let a new service through; possibly some coding and design review or protocol analysis. That's a good thing to do, but often it doesn't get done in the rush to adopt new technology.

When I talk to my customers I encourage them to do what I call a service-oriented requirements analysis. List the things you need to do and ignore completely how you're going to do them. All that stuff is an implementation detail. Then, for each thing you need to do (e-mail, WWW, Telnet, whatever) think about the risks it entails and what kind of protection is appropriate for your environment; then find an implementation that fits.

In some cases, a router-based solution will fit the bill perfectly. In others, even the most restrictive application-level firewall in the world is not good enough.

If you're the organization with the H-bomb launch codes and your requirement is that you need to surf the Web, my response is to just buy everyone accounts on AOL or Compuserve. All too often people jump right from requirements to implementation without bothering to think. It's kind of scary.

Does one or the other type of firewall spell trouble for any particular environment?

Molitor: In general, any technology you deploy for any purpose will be bad news if used inappropriately. The biggest dangers are not knowing what you need and not knowing what you've bought. If you know what you need and you know what the product you're deploying does, you should be fine.

Ranum: What Andrew's saying, in fewer words than I usually do, is that you can't pick a technology until you've done some analysis and risk assessment.

Are there differences in the policies and procedures (vis-a-vis users, network administration, etc.) that would be put in place along with the implementation of one or the other?

Molitor: Policies, at least access policies, should be driving the selection of technology (that is, technology should be selected and deployed to implement the access policy), not the other way around. The procedures for managing firewalls will differ in detail depending of the type of firewall(s) installed, but in general the procedures should boil down to 'implement the policy, or as close an approximation to it as possible.'

Ranum: Management is the major difference. Managing a router firewall looks a lot like, well, managing a router. Managing an application level firewall usually entails managing some kind of host operating system. Most application firewalls have a nice user interface of some sort that does basic setup stuff, but if you want to go beyond that, you'll need to learn a bit about what the underlying software base is.

That's one area where router-based firewalls are a bit deceptive. A lot of folks I know think they're much easier to set up and it's probably because they are-they're not running a nameserver, and they're not acting as a mail gateway, and they're not acting as a Web server, or whatever else. A lot of the high-end application-level firewalls include higher level services that you usually have to set up on a different machine someplace else if you're just using a router. The flip side of the coin is that if you don't want all that stuff, a router is much less complicated and it's doing a lot less busy-work.

Nine out of ten firewall-related support calls I've ever fielded had to do with other services not related to security-for example, DNS or sendmail configuration. No matter what kind of firewall you set up, be it router or application based, you're going to need to take care of those other details.

How does someone choose a router firewall?

Molitor: Choose a router that works for you, select a vendor that you're comfortable with ,either because you're familiar with and like their products, or because the product meets other requirements (performance, reliability, supports necessary protocols, etc) and then make sure it has some sort of packet filtering. I know of no modern router that cannot be persuaded to do a respectable job of packet filtering. Typically, the router you already own is the right one to use. Future growth of your network may well include more routers and at that time it makes sense to add packet filtering capabilities to the other capabilities you evaluate in selecting a router (performance, price, supported protocols, and so forth).

Ranum: I choose stereo equipment by buying the one that's heaviest. Probably not a good way of choosing a router. But seriously, though, using the tools that you know best is a sensible approach. If you have an installed base of one type of router, there's little benefit (unless the cost differences are huge) in learning how to manage and configure a different one.

How do you choose an application level firewall?

Molitor: Beats me! Ask Marcus.

Ranum: Most application level firewalls do the same kinds of things.

The selection criteria to look at are:

How is the system designed? Can the vendor

explain how the security of the firewall is a logical extension of its design?

Audit/logging/reporting capabilities:

what does the firewall keep track of? What does it report? How easily can the reporting/audit be customized?

Installation: how much assistance does

the vendor provide in installing the firewall and helping the customer build a sensible security policy?

Support: support hours, hardware support,

software support.

Maintenance: how much maintenance

does the firewall require? How much support does the vendor provide in the event of hardware or software problems?

Price/capacity/performance: Since the firewall market is still pretty immature, price and capacity and performance numbers may not mean enough to be valid criteria for selection. It is absolutely not the case that a more expensive firewall is somehow more secure! Lots of people still seem to operate under that impression, though. Vendors need to do a better job of explaining the design of their system and how it fosters security. There are some efforts on an emerging standard for publishing that kind of information. (See http://iwi.com for more information.)

Should performance be considered in evaluating firewalls for purchase?

Molitor: For application firewalls, yes, generally, unless your needs are minor. If you are comfortable within a T1 line, any application firewall will probably be adequate. If you have multi-megabit pipes, you'll need to be careful. For router-based firewalls, select the router that meets your performance requirements. Turning on packet filtering slows a router down substantially in the lab, but in the real world, in most cases, the router you bought has lots of power left over.

Ranum: Performance is a factor that should always be considered when buying a networking system. But I believe the real question is not "is it fast enough to handle what I'll be doing forever?" the question is "does it get the job done now?" Nobody I know buys a PC and asks the PC seller if they can expect that system to be adequate for the next 10 years. When evaluating systems for purchase, I look four to five years ahead at most. With a technology like firewalls, the evolution seems to be within a two year cycle. I suspect that most of the firewalls out there will be obsolete within three years. So will most workstations, desktops, etc.

A T1 is relatively slow these days, even a 386-class system can easily consume a T1 worth of bandwidth. If I were firewalling off a T3 or higher network then I'd be worried. Most high- end desktop systems can't keep up at those speeds. Obviously, a router can and might be the only solution in those cases.

How does performance evaluation differ between application-level firewalls and router firewalls?

Molitor: Application firewalls are going to be slower and will tend to run into a bytes per second limit first, due to details of how operating systems do networking. Packet filtering systems will tend to be limited by packet rate. That is, if your packet filter can process 10,000 packets per second, it makes no difference whether those packets are 40 byte packets carrying keystrokes typed by users into terminal sessions, or 1500 byte packets carrying bulk data transfer traffic such as mail or FTP. This gives the users the impression of even better performance through a packet filter, since the need for high performance usually occurs during bulk data transfers. Users don't really care how fast the router is when they're just typing a command into a terminal session, but they do care when they FTP a large file from one place to another. Since the router can filter a fixed number of packets per second, it's processing a lot more data per second in the case when the packets are large.

Ranum: Application-level firewalls do a lot more bookkeeping, which is the network's equivalent of friction in physics. It slows things down and can cause problems when you run out of space for keeping the books. The router-based firewalls don't do a lot of bookkeeping so they can be quicker and can scale better to large networks. In an application level firewall, if there are 2,000 users surfing the Web through it, it has to be keeping track of 2,000 connections. The router doesn't keep track of connections at all.

We don't yet have a very good idea of the performance implications of application-level firewalls. Nobody has published any formal testing results, and it'd be questionable how well a general test could be applied to all the different networks out there. It'd be irresponsible to publish a single number (like "MIPS") but whenever someone asks for performance figures I suspect that's what they want-a simple, meaningless answer. I've had a number of callers who have complained about their firewall being really slow and had to explain to them that a 56kb line is going to be slow with 100 users surfing the Web, whether there's a firewall in there or not!

So, I'd worry about performance, but I'd only worry about it if I had performance problems!

What do you think the life span of solution you buy today will be?

Molitor: Any solution deployed today should be deployed with the idea that it will still be a useful network component in five years, but not necessarily playing the same role. It would be foolish to plan to deploy a box that's not fast enough or strong enough as deployed, and then throw it out. Networks grow and change over time: central hubs are redeployed as workgroup hubs; routers have boards replaced to support new LAN technologies and to work faster; new fiber is pulled and traffic load balanced across the old fiber and the new. So it should be with network security technology. The ideal plan for deploying a firewall or firewalls should include scenarios for redeployment, included in the enterprise plans for network growth.

Indeed, from a corporate accounting point of view, one of the major problems with application firewalls is that they're difficult to re-deploy. By the time it's outlived its usefulness as a firewall, it's just a PC that's too old and small to give to even the most shunned intern.

Ranum: Andrew's speaking like a network infrastructure builder, not an application/service provider, so we have a different perspective. Most applications and servers are not on a five year lifecycle. It's a lot shorter than that. Unlike a desktop system, a firewall is not something you can "trickle down" and put on a secretary's desktop when it's no longer able to keep up with growth of the network.

Router-type firewalls can be incorporated into the infrastructure. After all, they will work correctly as long as the protocol running over them doesn't change! Application level firewalls "know" the applications base and are going to be married to it: if it changes they will either change too or become obsolete and need to be replaced or upgraded. This is a blessing and a curse.

Care to take a stab at what the firewall of the future will look like? Two, five, ten years down the arc? Or will there be firewalls at all?

Molitor: With any luck at all, we won't be worrying about firewalls in a two or three years, but instead will be thinking about secure networks. We'll have application proxies and packet filtering routers in the bag of technologies we know about and can deploy to build our networks securely, along with smart hubs, encryption and authentication products and so on.

Ranum: Two years from now, firewalls (be they application-level or network) will support peer-to-peer encryption and Virtual Network Perimeters (VNPs). I suspect mobile computers will also be able to be members of VNPs, so that I could travel to a remote site, jack in, and be on my "home" network via an encrypted link.

Five years from now, there won't be a difference between application level firewalls and network-level firewalls. They'll be the same thing, more or less.

Ten years from now, there will be "virtual networks" running within the same wire, separated by routers that enforce the traffic via screening and encryption. Note that you can do that today, with existing technology, but nobody is doing it. The real break-through will come if the hosts on the network are able to take part in the virtual networks as full-fledged members. This will take place at both the network layer and in applications, with legacy systems taking part via software and newer systems supporting it in the operating system itself.

Did you notice I didn't say "security problems will all be solved"?

Someone made an interesting remark on a panel at CSI's Netsec conference. He called firewalls "an unfortunate artifact of our time." In hindsight, would there have been a better solution than the firewall approach?

Molitor: I liken the firewall to the tumbler lock. Long ago, people secured their doors with leather straps and iron latches and it was awkward because bad guys could just walk in and take your belongings. Then some clever chap invented the tumbler lock and one can at least imagine that a lot of excitement was generated. People started thinking in terms of buying a lock for their house and using it on their door, or their silver cabinet, or possibly attaching it to their dog's tail if they were unclear on the whole thing. This is where we are with firewalls now. Lock technologies have moved on. We now have many kinds of locks of various strengths-motion detectors, infrared detectors, alarms, outdoor lighting, and so forth. Nobody thinks tumbler locks are particularly neat, they're just one of the many things you can and should deploy-possibly in conjunction with many other technologies-to keep your home or business safe.

Ranum: There are loads of better approaches than firewalls, but they are all revolutionary, not evolutionary steps. Firewalls came about because networks grew without anyone worrying about the security of them. Nobody ever dreamed they'd want to hook to another network. Suddenly it's "Oops, let's get an Internet connection," then they have 4,000 nodes on their corporate WAN and are faced with a choice of retrofitting security onto 4,000 nodes or putting in a firewall and hoping they've walled themselves off.

Someone once asked me if there was a simple thing that could be done to improve the state of network security. There is and it's something nobody seems to consider: just throw away the existing network applications suite and redesign them so that they don't assume the network is trusted. That means Telnet, FTP, http, rlogin, etc, all get thrown onto the scrap heap and re-written to use application-level encryption and authentication services, with support for service-level delegation of trust and access control policies defined via a global repository. It's just such an outré concept I don't think anyone considers it seriously. It'd probably take less effort to implement something good than to keep patching up what's already out there but the tyranny of the installed base is not something to take lightly.

Firewalls are a result of choosing to retain legacy systems and legacy networks. When an organization that has not designed security into their network connects to an untrusted network, they don't have much choice other than to tear their network down and rebuild it. Compared to that, firewalls are very cost effective and attractive!

Marcus Ranum is President and CEO of Network Flight Recorder, Inc., a security startup which he founded early in 1997. As Chief Scientist for V-One Corporation, Ranum worked as an executive manager for a high-tech security product startup, with duties including strategic market analysis, technology evolution, software engineering process management, reseller and business partner relationships, and corporate positioning.
At Trusted Information Systems, Inc., as senior scientist and development manager for Internet security products, Marcus designed and implemented the TIS Internet Firewall Toolkit under a grant from ARPA on behalf of the Executive Office of The President of the United States, and configured and managed whitehouse.gov for its first year of operation. Marcus architected and managed the implementation of the TIS Gauntlet Internet Firewall product, and acted as a senior consultant and trainer for managing reseller relationships and training reseller marketing and technical staff.