1.6. Religious ArgumentsThe world is full of "religious arguments", philosophical debates on which people hold strong and divisive beliefs. Firewalls are no exception to this rule.
1.6.1. Buying Versus BuildingInitially, if a site wanted a firewall, they had little choice but to design and build it themselves (perhaps with their own staff, or perhaps by hiring a consultant or contractor). Over the years, however, more and more commercial firewall offerings have reached the market. These products continue to grow in number and functionality at an astounding rate, and many sites may find that one of these products suits their needs. Most sites find that commercial products are at least a valuable component of their firewall solution.
In deciding whether or not a particular commercial firewall product will meet your needs, you have to understand what your needs are. Even if you decide to buy a firewall, you still need to understand a fair bit about how they're built and how they work in order to make an informed purchasing decision. Many sites spend as much or more effort evaluating commercial firewall products as they would building their own firewall.
We're not saying that nobody should buy a firewall, or that everybody should build their own. Our point is merely that it's not necessarily any easier to buy than it is to build; it all depends on your particular situation and what resources you have at your disposal. Sites with money to spend but little staff time or expertise available often find buying an attractive solution, while sites with expertise and time but little money often find building more attractive.
Just what expertise do you need to design and build your own firewall? Like everything else, it depends; it depends on what services you want to provide, what platforms you're using, what your security concerns are, and so on. To install most of the tools described in this book, you need basic Internet skills to obtain the tools, and basic system administration skills to configure, compile, and install them. If you don't know what those skills are, you probably don't have them; you can obtain them, but that's beyond the scope of this book.
Some people feel uncomfortable using software that's freely available on the Internet, particularly for security-critical applications. We feel that the advantages outweigh the disadvantages. You may not have the "guarantees" offered by vendors, but you have the ability to inspect the source code and to share information with the large community that helps to maintain the software. In practice, vendors come and go, but the community endures. The packages we discuss in this book are widely used; many of the largest sites on the Internet base their firewalls on them. These packages reflect years of real-life experience with the Internet and its risks.
Other people feel uncomfortable using commercial software for security-critical applications, feeling that you can't trust software unless you can read the code. While there are real advantages to having code available, auditing code is difficult, and few people can do an adequate job on a package of any significant size. Commercial software has its own advantages; when you buy software you have a legal contract with somebody, which may give you some recourse if things go wrong.
Frequently, people argue that open source software is more risky than commercial software because attackers have access to the source code. In practice, the attackers have access to all the source code they need, including commercial source code. If it's not given to them, they steal or reverse-engineer it; they have the motivation and time, and they don't have ethical constraints. There's no distinction between programs on this point.
While it's perfectly possible to build a firewall consisting solely of freely available software or solely of commercial software, there's no reason to feel that it's all or nothing; freely available tools provide a valuable complement to purchased solutions. Buying a firewall shouldn't make you reluctant to supplement with freely available tools, and building one shouldn't make you reluctant to supplement with purchased tools. Don't rule out a product just because it's commercial, or just because it's freely available. Truly excellent products with great support appear in both categories, as do poorly thought out products with no support.
1.6.2. Unix Versus Windows NTBuilding a firewall requires at least one Internet-aware server (and often more than one). Until relatively recently, the only popular platform that provided the necessary services was Unix. These days, Windows NT also has the necessary characteristics; it provides a security-aware and network-aware multi-user operating system and is widely used.
any people argue violently about which is better, Unix or Windows NT, in every domain. These arguments are particularly vociferous when it comes to firewalls, where Unix people tend to say that Windows NT machines are simply unsuited to building firewalls, and Windows NT people say that this is pure prejudice.
The truth, as always, is somewhere between the two camps. The Unix people who complain about Windows NT are usually working from a basis of both prejudice and ignorance, and have an annoying tendency to misconfigure machines and then complain that they don't work. A properly configured Windows NT machine is a reasonable machine for building a firewall.
On the other hand, Windows NT machines are genuinely more difficult to configure properly for firewalls, for two reasons. The most widely cited Windows NT problem has to do with the way Windows NT implements the TCP/IP networking standards. Unix is one of the earliest systems to do TCP/IP, and many Unix implementations of TCP/IP share a more than 20-year common heritage. In that time, they've seen almost every way you can torture a networking protocol, and they've been made quite reliable. Microsoft reimplemented TCP/IP from scratch for Windows NT, and the resulting code has problems that have faded into distant memories for Unix (or never existed; different programmers make different mistakes). An unstable TCP/IP implementation is a real problem in a firewall, which may be exposed to a lot of hostile or incompetent programs doing eccentric things with TCP/IP.
On the other hand, it's not as big a problem as many people give it credit for. Many ways of designing a firewall put a packet filtering router, built on a specialized, robust, and quickly upgradeable TCP/IP implementation, in front of any general-purpose computer in any case. In these designs, the router can offer some protection to Windows NT machines. Windows NT's TCP/IP implementation is also catching up rapidly, because problems with it tend to be extremely visible (once somebody's crashed a few hundred thousand hosts, people tend to take notice). It is painful to have to upgrade the operating system on your firewall, and the low-level TCP/IP is one of the most risky and painful parts to have to upgrade, so changes that come out after your machines are installed are not very comforting, but it is probable that most of the worst problems have been found already.
The second difficulty in securing Windows NT is more fundamental. Windows NT is designed to be opaque; things are supposed to just work without administrators knowing how they work. This simplifies the process of setting up a machine, as long as you want to set it up to do something expected. It vastly complicates the process of evaluating the machine's security, setting it up to do something unexpected (like run in a highly secure environment), or modifying the way it behaves.
Your average Windows NT machine looks less complex than your average Unix machine but actually supports many more protocols. Unix machines tend to provide a fairly straightforward set of TCP/IP services, while Windows NT machines provide servers and/or clients for most of those, plus support for multiple generations of Microsoft protocols, and optional support for NetWare and AppleTalk. Go to your local bookstore and look at the shelves of books for Windows NT compared to the shelves of books for Unix. Some of the difference is in popularity; some of the difference has to do with the economics of certification; but a lot of the difference is that Windows NT is just more complicated than Unix, and in security, complexity is bad.
Unix administrators who complain about Windows NT's complexities aren't merely ignorant (although the shock of learning a new operating system does have something to do with it), nor are they simply trying the wrong approach. Windows NT really is extremely complicated and difficult to understand, and in a security context, you do need to understand it. Trusting vendors to provide a secure solution is not going to be satisfactory for a site of any significant size.
That doesn't mean Windows NT is entirely unsuited to building firewalls. It may be complicated, but Unix isn't exactly trivial. A firewall is not a good place to learn a new operating system. Even commercial firewalls require some basic competency with the operating system they run on, in order to secure the base operating system and manage the software. If you're already experienced in Windows NT, you're better off using it and learning the previously hidden parts than trying to learn Unix from scratch. If you're experienced in Unix, you are still going to make stupid beginner mistakes trying to run Windows NT, even in a prepackaged commercial firewall.
If you find yourself stuck putting machines of the type you don't understand into your firewall, don't panic. You can survive the experience and come out of it with your security intact, and you might as well do it with as much grace as possible. Expect it to be difficult and confusing, and keep an open mind. You'll need basic training on the operating system as well as this book, which assumes that you are able to do normal administrative tasks already.
1.6.3. That's Not a Firewall!The world is full of people eager to assure you that something is not a firewall; it's "just a packet filter" or maybe it's "better than a mere firewall". If it's supposed to keep the bad guys out of your network, it's a firewall. If it succeeds in keeping the bad guys out, while still letting you happily use your network, it's a good firewall; if it doesn't, it's a bad firewall. That's all there is to it.
Copyright © 2002 O'Reilly & Associates. All rights reserved.