It is scarcely possible to enter a bookstore, read a magazine or a newspaper, or listen to a news broadcast without seeing or hearing something about the Internet in some guise. It's become so popular that no advertisement is complete without a reference to a web page. While nontechnical publications are obsessed with the Internet, the technical publications have moved on and are obsessed with security. It's a logical progression; once the first excitement of having a superhighway in your neighborhood wears off, you're bound to notice that not only does it let you travel, it lets a very large number of strangers show up where you are, and not all of them are people you would have invited.
Both views are true: The Internet is a marvelous technological advance that provides access to information, and the ability to publish information, in revolutionary ways. But it's also a major danger that provides the ability to pollute and destroy information in revolutionary ways. This book is about one way to balance the advantages and the risks — to take part in the Internet while still protecting yourself.
Later in this chapter, we describe different models of security that people have used to protect their data and resources on the Internet. Our emphasis in this book is on the network security model and, in particular, the use of Internet firewalls. A firewall is a form of protection that allows a network to connect to the Internet while maintaining a degree of security. The section later in this chapter called "What is an Internet Firewall?" describes the basics of firewalls and summarizes what they can — and cannot — do to help make your site secure. Before we discuss what you can do with a firewall, though, we want to describe briefly why you need one. What are you protecting on your systems? What types of attacks and attackers are common? What types of security can you use to protect your site?
A firewall is basically a protective device. If you are building a firewall, the first thing you need to worry about is what you're trying to protect. When you connect to the Internet, you're putting three things at risk:
Your data: the information you keep on the computers
Your resources: the computers themselves
You might not want other people to know it.
You probably don't want other people to change it.
You almost certainly want to be able to use it yourself.
People tend to focus on the risks associated with secrecy, and it's true that those are usually large risks. Many organizations have some of their most important secrets — the designs for their products, financial records, or student records — on their computers. On the other hand, you may find that at your site it is relatively easy to separate the machines containing this kind of highly secret data from the machines that connect to the Internet. (Or you may not; you can't do Internet electronic commerce without having information about orders and money pass through Internet-accessible machines.)
Suppose that you can separate your data in this way, and that none of the information that is Internet accessible is secret. In that case, why should you worry about security? Because secrecy isn't the only thing you're trying to protect. You still need to worry about integrity and availability. After all, if your data isn't secret, and if you don't mind its being changed, and if you don't care whether or not anybody can get to it, why are you wasting disk space on it?
Even if your data isn't particularly secret, you'll suffer the consequences if it's destroyed or modified. Some of these consequences have readily calculable costs: if you lose data, you'll have to pay to have it reconstructed; if you were planning to sell that data in some form, you'll have lost sales regardless of whether the data is something you sell directly, the designs from which you build things, or the code for a software product. Intangible costs are also associated with any security incident. The most serious is the loss of confidence (user confidence, customer confidence, investor confidence, staff confidence, student confidence, public confidence) in your systems and data and, consequently, a loss of confidence in your organization.
Even if you have data you don't care about — if you enjoy reinstalling your operating system every week because it exercises the disks, or something like that — if other people are going to use your computers, you probably would like to benefit from this use in some way. Most people want to use their own computers, or they want to charge other people for using them. Even people who give away computer time and disk space usually expect to get good publicity and thanks for it; they aren't going to get it from intruders. You spend good time and money on your computing resources, and it is your right to determine how they are used.
Intruders often argue that they are using only excess resources; as a consequence, their intrusions don't cost their victims anything. There are two problems with this argument.
First, it's impossible for an intruder to determine successfully what resources are excess and use only those. It may look as if your system has oceans of empty disk space and hours of unused computing time; in fact, though, you might be just about to start computing animation sequences that are going to use every bit and every microsecond. An intruder can't give back your resources when you want them. (Along the same lines, I don't ordinarily use my car between midnight and 6 A.M., but that doesn't mean I'm willing to lend it to you without being asked. What if I have an early morning flight the next day, or what if I'm called out to deal with an emergency?)
Second, it's your right to use your resources the way you want to, even if you merely feel some sort of Zen joy at the sight of empty disk space, or if you like the way the blinky lights look when nothing's happening on your computer. Computing resources are not natural resources that belong by right to the world at large, nor are they limited resources that are wasted or destroyed if they're not used.
Most of the time, the consequences are simply that other sites — or law enforcement agencies — start calling you to ask why you're trying to break into their systems. (This isn't as rare an occurrence as it may seem. One site got serious about security when its system administration staff added a line item to their time cards for conversations with the FBI about break-in attempts originating from their site.)
Sometimes, such impostors cost you a lot more than lost time. An intruder who actively dislikes you, or simply takes pleasure in making life difficult for strangers, may change your web site, send electronic mail, or post news messages that purport to come from you. Generally, people who choose to do this aim for maximum hatefulness, rather than believability, but even if only a few people believe these messages, the cleanup can be long and humiliating. Anything even remotely believable can do permanent damage to your reputation.
A few years ago, an impostor posing as a Texas A&M professor sent out hate email containing racist comments to thousands of recipients. The impostor was never found, and the professor is still dealing with the repercussions of the forged messages. In another case, a student at Dartmouth sent out email over the signature of a professor late one night during exam period. Claiming a family emergency, the forged email canceled the next day's exam, and only a few students showed up.
It's possible to forge electronic mail or news without gaining access to a site, but it's much easier to show that a message is a forgery if it's generated from outside the forged site. The messages coming from an intruder who has gained access to your site will look exactly like yours because they are yours. An intruder will also have access to all kinds of details that an external forger won't. For example, an intruder has all of your mailing lists available and knows exactly who you send mail to.
Currently, attacks that replace web sites are very popular; one list shows more than 160 successful attacks where sites were replaced, in 18 countries, in a single month. Many of those attacks simply replaced the sites with boasting by the attackers, but a significant portion of them were directed at the content of the sites. A site that should have touted Al Gore's suitability for the U.S. presidency was replaced by a similar anti-Gore site, for instance; political movements in Peru, Mexico, and China put up slogans; and there's no need to feel safe merely because your site concerns frivolity, as pop stars, Pro Wrestling, and the Boston Lyric Opera all suffered as well.
Even if an intruder doesn't use your identity, a break-in at your site isn't good for your reputation. It shakes people's confidence in your organization. In addition, most intruders will attempt to go from your machines to others, which is going to make their next victims think of your site as a platform for computer criminals. Many intruders will also use compromised sites as distribution sites for pirated software, pornography, and/or other stolen information, which is not going to endear you to many folks either. Whether or not it's your fault, having your name linked to other intrusions, software piracy, and pornography is hard to recover from.
What's out there to worry about? What types of attacks are you likely to face on the Internet, and what types of attackers are likely to be carrying them out? And what about simple accidents or stupidity? In the sections that follow, we touch on these topics, but we don't go into any technical detail; later chapters describe different kinds of attacks in some detail and explain how firewalls can help protect against them.
There are many types of attacks on systems, and many ways of categorizing these attacks. In this section, we break attacks down into three basic categories: intrusion, denial of service, and information theft.
Attackers have dozens of ways to get access. They range from social engineering attacks (you figure out the name of somebody high up in the company; you call a system administrator, claiming to be that person and claiming to need your password changed right now, so that you can get important work done), to simple guesswork (you try account names and password combinations until one works), to intricate ways to get in without needing to know an account name and a password.
As we describe in this book, firewalls help prevent intrusions in a number of ways. Ideally, they block all ways to get into a system without knowing an account name and password. Properly configured, they reduce the number of accounts accessible from the outside that are therefore vulnerable to guesswork or social engineering. Most people configure their firewalls to use one-time passwords that prevent guessing attacks. Even if you don't use these passwords, which we describe in Chapter 21, a firewall will give you a controlled place to log attempts to get into your system, and, in this way, they help you detect guessing attacks.
In late 1994, writers Josh Quittner and Michelle Slatalla were the target of an "electronic mail bomb". Apparently in retaliation for an article on the cracker community they'd published in Wired magazine, someone broke into IBM, Sprint, and the writers' network provider, and modified programs so their email and telephone service was disrupted. A flood of email messages so overwhelmed their network service that other messages couldn't get through; eventually, their Internet connection was shut down entirely. Their phone service also fell victim to the intruders, who reprogrammed the service so that callers were routed to an out-of-state number where they heard an obscene recording.
Although some cases of electronic sabotage involve the actual destruction or shutting down of equipment or data, more often they follow the pattern of flooding seen in the Quittner-Slatalla case or in the case of the 1988 Morris Internet worm. An intruder so floods a system or network — with messages, processes, or network requests — that no real work can be done. The system or network spends all its time responding to messages and requests, and can't satisfy any of them.
While flooding is the simplest and most common way to carry out a denial of service attack, a cleverer attacker can also disable services, reroute them, or replace them. For example, the phone attack in the Quittner-Slatalla case denied phone service by rerouting their phone calls elsewhere; it's possible to mount the same kind of attack against Internet services.
It's close to impossible to avoid all denial of service attacks. Sometimes it's a "heads, I win; tails, you lose" situation for attackers. For example, many sites set accounts up to become unusable after a certain number of failed login attempts. This prevents attackers from simply trying passwords until they find the right one. On the other hand, it gives the attackers an easy way to mount a denial of service attack: they can lock any user's account simply by trying to log in a few times.
Most often, the risk of denial of service attacks is unavoidable. If you accept things from the external universe — electronic mail, telephone calls, or packages — it's possible to get flooded. The notorious college prank of ordering a pizza or two from every pizzeria in town to be delivered to your least favorite person is a form of denial of service; it's hard to do much else while arguing with 42 pizza deliverers. In the electronic world, denial of service is as likely to happen by accident as on purpose (have you ever had a persistent fax machine try to fax something to your voice line?). The most important thing is to set up services so that if one of them is flooded, the rest of your site keeps functioning while you find and fix the problem.
Flooding attacks are considered unsporting by many attackers, because they aren't very difficult to carry out. For most attackers, they're also pointless, because they don't provide the attacker with the information or the ability to use your computers (the payoff for most other attacks). Intentional flooding attacks are usually the work of people who are angry at your site in particular, and at most sites such people are quite rare.
With the right tools and cooperation, it's fairly easy to trace flood packets back to their source, but that might not help you figure out who is behind the attacks. The attacks almost always come from machines that have themselves been broken into; only a really stupid attacker generates an easily traced flood of packets from their own machine. Sometimes flooding attacks are carried out by remote control. Attackers install remotely controlled flooding software on systems that they break into over the course of many weeks or months. This software lies dormant and undiscovered until some later time, when they trigger many of these remotely controlled installations simultaneously to bombard their victims with massive floods of traffic from many different directions at once. This was the method behind the highly publicized denial of service attacks on Yahoo!, CNN, and other high-profile Internet sites early in the year 2000.
You are far more likely to encounter unintentional flooding problems, as we discuss in Section 1.2.3, later in this chapter.
On the other hand, some denial of service attacks are easier for attackers, and these are relatively popular. Attacks that involve sending small amounts of data that cause machines to reboot or hang are very popular with the same sort of people who like to set off fire alarms in dormitories in the middle of the night, for much the same reason; with a small investment, you can massively annoy a very large number of people who are unlikely to be able to find you afterwards. The good news is that most of these attacks are avoidable; a well-designed firewall will usually not be susceptible to them itself, and will usually prevent them from reaching internal machines that are vulnerable to them.
Some types of attacks allow an attacker to get data without ever having to directly use your computers. Usually these attacks exploit Internet services that are intended to give out information, inducing the services to give out more information than was intended, or to give it out to the wrong people. Many Internet services are designed for use on local area networks, and don't have the type or degree of security that would allow them to be used safely across the Internet.
Information theft doesn't need to be active or particularly technical. People who want to find out personal information could simply call you and ask (perhaps pretending to be somebody who had a right to know): this is an active information theft. Or they could tap your telephone: this is a passive information theft. Similarly, people who want to gather electronic information could actively query for it (perhaps pretending to be a machine or a user with valid access) or could passively tap the network and wait for it to flow by.
Most people who steal information try to get access to your computers; they're looking for usernames and passwords. Fortunately for them, and unfortunately for everybody else, that's the easiest kind of information to get when tapping a network. Username and password information occurs quite predictably at the beginning of many network interactions, and such information can often be reused in the same form.
How would you proceed if you want to find out how somebody answers her telephone? Installing a tap would be an easy and reliable way to get that information, and a tap at a central point in the telephone system would yield the telephone greetings of hundreds or thousands of people in a short period of time.
On the other hand, what if you want to know how somebody spells his or her last name, or what the names and ages of his or her children are? In this case, a telephone tap is a slow and unreliable way to get that information. A telephone tap at a central point in the system will probably yield that information about some people, and it will certainly yield some secret information you could use in interesting ways, but the information is going to be buried among the conversations of hundreds of people setting up lunch dates and chatting about the weather.
Similarly, network taps, which are usually called sniffers, are very effective at finding password information but are rarely used by attackers to gather other kinds of information. Getting more specific information about a site requires either extreme dedication and patience, or the knowledge that the information you want will reliably pass through a given place at a given time. For example, if you know that somebody calls the bank to transfer money between his or her checking and savings accounts at 2 P.M. every other Friday, it's worth tapping that phone call to find out the person's access codes and account numbers. However, it's probably not worth tapping somebody else's phone, on the off chance that they too will do such a transfer, because most people don't transfer money over the phone at all.
Network sniffing is much easier than tapping a telephone line. Historically, the connectors used to hook a computer to an Ethernet network were known as network taps (that's why the term tapping isn't used for spying on a network), and the connectors behave like taps too. In most networks, computers can see traffic that is intended for other hosts. Traffic that crosses the Internet may cross any number of local area networks, any one of which can be a point of compromise. Network service providers and public-access systems are very popular targets for intrusions; sniffers placed there can be extremely successful because so much traffic passes through these networks.
There are several types of protection against information theft. A properly configured firewall will protect you against people who are trying to get more information than you intended to give. Once you've decided to give information out across the Internet, however, it's very difficult to protect against that information's reaching an unintended audience, either through misauthentication (somebody claiming to be authorized, when he or she isn't) or through sniffing (somebody simply reading information as it crosses a correctly authorized channel). For that matter, once you have given the information to somebody, you have no way to prevent that person from distributing it to other people. Although these risks are outside of the protection a firewall can give (because they occur once information has intentionally been allowed to go outside your network), we do discuss them and the methods used to reduce them, as appropriate in this book.
This section very briefly describes the types of attackers who are out there on the Internet. There are many ways to categorize these attackers; we can't really do justice to the many variants of attackers we've seen over the years, and any quick summary of this kind necessarily presents a rather stereotyped view. Nevertheless, this summary may be useful in distinguishing the main categories of attackers.
All attackers share certain characteristics. They don't want to be caught, so they try to conceal themselves, their identity and real geographic location. If they gain access to your system, they will certainly attempt to preserve that access, if possible, by building in extra ways to get access (and they hope you won't notice these access routes even if you find the attackers themselves). Most of them have some contact with other people who have the same kinds of interests ("the underground" is not hard to find), and most will share the information they get from attacking your system. A secondary group of attackers may not be as benign.
Joyriders are bored people looking for amusement. They break in because they think you might have interesting data, or because it would be amusing to use your computers, or because they have nothing better to do. They might be out to learn about the kind of computer you have or about the data you have. They're curious but not actively malicious; however, they often damage the system through ignorance or in trying to cover their tracks. Joyriders are particularly attracted to well-known sites and uncommon computers.
Vandals are a big problem if you're somebody that the Internet underground might think of as The Enemy (for example, the phone company or the government) or if you tend to annoy people who have computers and time (for example, you're a university with failing students, or a computer company with annoyed customers, or you have an aggressively commercial presence on the Internet). You can also become a target simply by being large and visible; if you put a big wall up in certain neighborhoods, people will put graffiti on it no matter how they feel about you.
Fortunately, vandals are fairly rare. People don't like them, even people in the underground who have nothing against breaking into computers in general. Vandals also tend to inspire people to go to great lengths to find them and stop them. Unlike more mundane intruders, vandals have short but splashy careers. Most of them also go for straightforward destruction, which is unpleasant but is relatively easily detected and repaired. In most circumstances, deleting your data, or even ruining your computer equipment, is not the worst thing somebody could do to you, but it is what vandals do. (Actually, introducing subtle but significant changes in programs or financial data would be much harder to detect and fix.)
Unfortunately, it's close to impossible to stop a determined vandal; somebody with a true vendetta against your site is going to get you, sooner or later. Certain attacks are attractive to vandals but not to other types of attackers. For example, denial of service attacks are not attractive to joyriders; while joyriders are around in your system, they are just as interested as you are in having your computers up, running, and available to the Internet.
Like joyriders and vandals, scorekeepers may prefer sites of particular interest. Breaking into something well known, well defended, or otherwise especially cool is usually worth more points to them. However, they'll also attack anything they can get at; they're going for quantity as well as quality. They don't have to want anything you've got or care in the least about the characteristics of your site. They may or may not do damage on the way through. They'll certainly gather information and keep it for later use (perhaps using it to barter with other attackers). They'll probably try to leave themselves ways to get back in later. And, if at all possible, they'll use your machines as a platform to attack others.
These people are the ones you discover long after they've broken in to your system. You may find out slowly, because something's odd about your machine. Or you'll find out when another site or a law enforcement agency calls up because your system is being used to attack other places. Or you'll find out when somebody sends you a copy of your own private data, which they've found on a cracked system on the other side of the world.
Many scorekeepers are what are known as script kiddies—attackers who are not themselves technically expert but are using programs or scripts written by other people and following instructions about how to use them. Although they do tend to be young, they're called "kiddies" mostly out of contempt aimed at them by more experienced intruders. Even though these attackers are not innovators, they still pose a real threat to sites that don't keep rigorously up to date. Information spreads very rapidly in the underground, and the script kiddies are extremely numerous. Once a script exists, somebody is almost guaranteed to attack your site with it.
These days, some scorekeepers aren't even counting machines they've broken into but are keeping score on crashed machines. On the one hand, having a machine crash is generally less destructive than having it broken into; on the other hand, if a particular attack gets into the hands of the script kiddies, and thousands of people use it to crash your machine, it's not funny any more.
Most people who break into computers do so for the same reason people climb mountains — because they're there. While these people are not above theft, they usually steal things that are directly convertible into money or further access (e.g., credit card, telephone, or network access information). If they find secrets they think they can sell, they may try to do so, but that's not their main business.
As far as anybody knows, serious computer-based espionage is much rarer, outside of traditional espionage circles. (That is, if you're a professional spy, other professional spies are probably watching you and your computers.) Espionage is much more difficult to detect than run-of-the-mill break-ins, however. Information theft need not leave any traces at all, and even intrusions are relatively rarely detected immediately. Somebody who breaks in, copies data, and leaves without disturbing anything is quite likely to get away with it at most sites.
In practical terms, most organizations can't prevent spies from succeeding. The precautions that governments take to protect sensitive information on computers are complex, expensive, and cumbersome; therefore, they are used on only the most critical resources. These precautions include electromagnetic shielding, careful access controls, and absolutely no connections to unsecured networks.
What can you do to protect against attackers of this kind? You can ensure that your Internet connection isn't the easiest way for a spy to gather information. You don't want some kid to break into your computers and find something that immediately appears to be worth trying to sell to spies; you don't want your competitors to be trivially able to get to your data; and you do want to make it expensive and risky to spy on you. Some people say it's unreasonable to protect data from network access when somebody could get it easily by coming to your site physically. We don't agree; physical access is generally more expensive and more risky for an attacker than network access.
Most disasters are not caused through ill will; they're accidents or stupid mistakes. One study estimates that 55 percent of all security incidents actually result from naive or untrained users doing things they shouldn't.
Denial of service incidents, for example, frequently aren't attacks at all. Apple's corporate electronic mail was rendered nonfunctional for several days (and their network provider was severely inconvenienced) by an accident involving a single mail message sent from a buggy mail server to a large mailing list. The mail resulted in a cascade of hundreds of thousands of error messages. The only hostile person involved was the system administrator, who wasn't hostile until he had to clean up the resulting mess.
Similarly, it's not uncommon for companies to destroy their own data or release it to the world by accident. Firewalls aren't designed to deal with this kind of problem. In fact, there is no known way to fully protect yourself from either accidents or stupidity. However, whether people are attacking you on purpose, or are simply making mistakes, the results are quite similar. (Hence the saying, "Never ascribe to malice that which can adequately be explained by stupidity".) When you protect yourself against evildoers, you also help protect yourself against the more common, but equally devastating, unintentional or well-intentioned error.
It's relatively easy to determine the risk involved in attacks that are currently under way, but what do you do about attacks that are theoretically possible but have not yet been used? It's very tempting to dismiss them altogether—after all, what matters to you is not what might happen to you, but what actually does happen to you. You don't really care if it's possible to do something, as long as nobody ever does it. So why should you worry if somebody produces a proof that an attack is possible, but it's so difficult that nobody is actually doing it?
Because the limits on what's difficult change rapidly in computing.
Because problems rarely come in isolation, and one attack that's too difficult may help people find an easier one.
Because eventually people run out of easier attacks and turn to more difficult ones.
And most importantly, because attacks move almost instantly from "never attempted" to "widely used".
The moment at which an attack is no longer merely theoretical, but is actually in use against your site, is that time that is technically called "too late". You certainly don't want to wait until then. You'll have a calmer and more peaceful life if you don't wait until the moment when an attack hits the newspaper headlines, either, and that's where a lot of theoretical attacks suddenly end up.
One computer vendor decided that a certain class of attacks, called stack attacks, were too difficult to exploit, and it was not worth trying to prevent them. These attacks are technically challenging on any hardware, and more difficult on their machines. It seemed unlikely that attackers would bother to go to the considerable effort necessary, and preventing the attacks required rewriting fundamental parts of the operating system. Thus, the vendor elected to avoid doing tedious and dangerous rewriting work to prevent what was then considered a purely theoretical risk. Six months later, somebody found and exploited one of the vulnerabilities; once the hard work had been done for one, the rest were easy, so that started a landslide of exploits and bad publicity.
Much of security is about trust; who do you trust to do what? The world doesn't work unless you trust some people to do some things, and security people sometimes seem to take an overly suspicious attitude, trusting nobody. Why shouldn't you trust your users, or rich, famous software vendors?
We all know that in day-to-day life there are various kinds of trust. There are people you would lend a thousand dollars but not tell a secret to; people you would ask to babysit but not lend a book to; people you love dearly but don't let touch the good china because they break things. The same is true in a computer context. Trusting your employees not to steal data and sell it is not the same thing as trusting them not to give it out by accident. Trusting your software vendor not to sell you software designed to destroy your computer is not at all the same thing as trusting the same vendor not to let other people destroy your computer.
You don't need to believe that the world is full of horrible, malicious people who are trying to attack you. You do need to believe that the world has some horrible, malicious people who are trying to attack you, and is full of really nice people who don't always pay attention to what they're doing.
When you give somebody private information, you're trusting them two ways. First, you're trusting them not to do anything bad with it; second, you're trusting them not to let anybody else steal it. Most of the time, most people worry about the first problem. In the computer context, you need to explicitly remember to think about the second problem. If you give somebody a credit card number on paper, you have a good idea what procedures are used to protect it, and you can influence them. If carbon sheets are used to make copies, you can destroy them. If you give somebody a credit card electronically, you are trusting not only their honesty but also their skill at computer security. It's perfectly reasonable to worry about the latter even if the former is impeccable.
If the people who use your computers and who write your software are all trustworthy computer security experts, great; but if they're not, decide whether you trust their expertise separately from deciding whether you trust their honesty.
What approaches can you take to protect against the kinds of attacks we've outlined in this chapter? People choose a variety of security models, or approaches, ranging from no security at all, through what's called "security through obscurity" and host security, to network security.
The simplest possible approach is to put no effort at all into security, and run with whatever minimal security your vendor provides you by default. If you're reading this book, you've probably already rejected this model.
Another possible security model is the one commonly referred to as security through obscurity. With this model, a system is presumed to be secure simply because (supposedly) nobody knows about it — its existence, contents, security measures, or anything else. This approach seldom works for long; there are just too many ways to find an attractive target. One of the authors had a system that had been connected to the Internet for only about an hour before someone attempted to break in. Luckily, the operating system that was in the process of being installed detected, denied, and logged the access attempts.
Many people assume that even though attackers can find them, the attackers won't bother to. They figure that a small company or a home machine just isn't going to be of interest to intruders. In fact, many intruders aren't aiming at particular targets; they just want to break into as many machines as possible. To them, small companies and home machines simply look like easy targets. They probably won't stay long, but they will attempt to break in, and they may do considerable damage. They may also use compromised machines as platforms to attack other sites.
To function on any network, the Internet included, a site has to do at least a minimal amount of registration, and much of this registration information is available to anyone, just for the asking. Every time a site uses services on the network, someone — at the very least, whoever is providing the service — will know they're there. Intruders watch for new connections, in the hope that these sites won't yet have security measures in place. Some sites have reported automated probes apparently based on new site registrations.
You'd probably be amazed at how many different ways someone can determine security-sensitive information about your site. For example, knowing what hardware and software you have and what version of the operating system you're running gives intruders important clues about what security holes they might try. They can often get this information from your host registration, or by trying to connect to your computer. Many computers disclose their type of operating system in the greeting you get before you log in, so an intruder doesn't need access to get it.
In addition, you send out all sorts of information when you deal with other sites on the Internet. Whenever you visit a web site, you tell that site what kind of browser you are running, and often what kind of machine you are using. Some email programs include this information in every piece of mail you send out.
Even if you manage to suppress all of these visible sources of information, intruders have scripts and programs that let them use much subtler clues. Although the Internet operates according to standards, there are always loopholes, or questionable situations. Different computers do different things when presented with exceptional situations, and intruders can figure out a lot by creating these situations and seeing what happens. Sometimes it's possible to figure out what kind of machine you're dealing with just by watching the sizes and timings it uses to send out data packets!
If all of that fails, intruders have a lot of time on their hands, and can often avoid having to figure out obscure facts by simply trying all the possibilities. In the long run, relying on obscurity is not a smart security choice.
Probably the most common model for computer security is host security. With this model, you enforce the security of each host machine separately, and you make every effort to avoid or alleviate all the known security problems that might affect that particular host. What's wrong with host security? It's not that it doesn't work on individual machines; it's that it doesn't scale to large numbers of machines.
The major impediment to effective host security in modern computing environments is the complexity and diversity of those environments. Most modern environments include machines from multiple vendors, each with its own operating system, and each with its own set of security problems. Even if the site has machines from only one vendor, different releases of the same operating system often have significantly different security problems. Even if all these machines are from a single vendor and run a single release of the operating system, different configurations (different services enabled, and so on) can bring different subsystems into play (and into conflict) and lead to different sets of security problems. And, even if the machines are all absolutely identical, the sheer number of them at some sites can make securing them all difficult. It takes a significant amount of up-front and ongoing work to effectively implement and maintain host security. Even with all that work done correctly, host security still often fails due to bugs in vendor software, or due to a lack of suitably secure software for some required functions.
Host security also relies on the good intentions and the skill of everyone who has privileged access to any machine. As the number of machines increases, the number of privileged users generally increases as well. Securing a machine is much more difficult than attaching it to a network, so insecure machines may appear on your network as unexpected surprises. The mere fact that it is not supposed to be possible to buy or connect machines without consulting you is immaterial; people develop truly innovative purchasing and network-connection schemes if they feel the need.
A host security model may be highly appropriate for small sites, or sites with extreme security requirements. Indeed, all sites should include some level of host security in their overall security plans. Even if you adopt a network security model, as we describe in the next section, certain systems in your configuration will benefit from the strongest host security. For example, even if you have built a firewall around your internal network and systems, certain systems exposed to the outside world will need host security. (We discuss this in detail in Chapter 10.) The problem is, the host security model alone just isn't cost-effective for any but small or simple sites; making it work requires too many restrictions and too many people.
As environments grow larger and more diverse, and as securing them on a host-by-host basis grows more difficult, more sites are turning to a network security model. With a network security model, you concentrate on controlling network access to your various hosts and the services they offer, rather than on securing them one by one. Network security approaches include building firewalls to protect your internal systems and networks, using strong authentication approaches (such as one-time passwords), and using encryption to protect particularly sensitive data as it transits the network.
A site can get tremendous leverage from its security efforts by using a network security model. For example, a single network firewall of the type we discuss in this book can protect hundreds, thousands, or even tens of thousands of machines against attack from networks beyond the firewall, regardless of the level of host security of the individual machines.
This kind of leverage depends on the ability to control the access points to the network. At sites that are very large or very distributed, it may be impossible for one group of people to even identify all of those access points, much less control them. At that point, the network security model is no longer sufficient, and it's necessary to use layered security, combining a variety of different security approaches.
Although this book concentrates on network security, please note that we aren't suggesting you ignore host security. As mentioned previously, you should apply the strongest possible host security measures to your most important machines, especially to those machines that are directly connected to the Internet. (This is discussed in more detail in Chapter 10.) You'll also want to consider using host security on your internal machines in general, to address security problems other than attacks from the Internet.
No security model can solve all your problems. No security model — short of "maximum security prison" — can prevent a hostile person with legitimate access from purposefully damaging your site or taking confidential information out of it. To get around powerful host and network security measures, a legitimate user can simply use physical methods. These may range from pouring soda into your computers to carrying sensitive memos home. You can protect yourself from accidents and ignorance internally, and from malicious external acts, but you cannot protect yourself from your legitimate users without severely damaging their ability to use their computers. Spies succeed in breaching government security with depressing regularity despite regulations and precautions well beyond the resources and tolerance of civilians.
No security model can take care of management problems; computer security will not keep your people from wasting time, annoying each other, or embarrassing you. Sites often get sucked into trying to make security protect against these things. When people are wasting time surfing the Web, annoying each other by playing tricks with window systems, and embarrassing the company with horrible email, computer security looks like a promising technological solution that avoids difficult issues. However tempting this may be, a security model won't work here. It is expensive and difficult to even try to solve these problems with computer security, and you are once again in the impossible situation of trying to protect yourself from legitimate users.
No security model provides perfect protection. You can expect to make break-ins rare, brief, and inexpensive, but you can't expect to avoid them altogether. Even the most secure and dedicated sites expect to have a security incident every few years.
Why bother, then? Security may not prevent every single incident, but it can keep an incident from seriously damaging or even shutting down your business. At one high-profile company with multiple computer facilities, a manager complained that his computer facility was supposed to be the most secure, but it got broken into along with several others. The difference was that the break-in was the first one that year for his facility; the intruder was present for only eight minutes; and the computer facility was off the Internet for only 12 hours (from 6 P.M. to 6 A.M.), after which it resumed business as usual with no visible interruption in service to the company's customers. For one of the other facilities, it was the fourth time; the intruder was present for months before being detected; recovery required taking the facility down for four days; and they had to inform customers that they had shipped them tapes containing possibly contaminated software. Proper security made the difference between an annoying occurrence and a devastating one.
As we've mentioned, firewalls are a very effective type of network security. This section briefly describes what Internet firewalls can do for your overall site security. Section 5.1 and Chapter 7 define the firewall terms used in this book and describe the various types of firewalls in use today, and the other chapters in Part II and those in Part III describe the details of building those firewalls.
In building construction, a firewall is designed to keep a fire from spreading from one part of the building to another. In theory, an Internet firewall serves a similar purpose: it prevents the dangers of the Internet from spreading to your internal network. In practice, an Internet firewall is more like a moat of a medieval castle than a firewall in a modern building. It serves multiple purposes:
It restricts people to entering at a carefully controlled point.
It prevents attackers from getting close to your other defenses.
It restricts people to leaving at a carefully controlled point.
An Internet firewall is most often installed at the point where your protected internal network connects to the Internet, as shown in Figure 1.1.
All traffic coming from the Internet or going out from your internal network passes through the firewall. Because the traffic passes through it, the firewall has the opportunity to make sure that this traffic is acceptable.
What does "acceptable" mean to the firewall? It means that whatever is being done—email, file transfers, remote logins, or any kinds of specific interactions between specific systems — conforms to the security policy of the site. Security policies are different for every site; some are highly restrictive and others fairly open, as we'll discuss in Chapter 25.
Logically, a firewall is a separator, a restricter, an analyzer. The physical implementation of the firewall varies from site to site. Most often, a firewall is a set of hardware components — a router, a host computer, or some combination of routers, computers, and networks with appropriate software. There are various ways to configure this equipment; the configuration will depend upon a site's particular security policy, budget, and overall operations.
A firewall is very rarely a single physical object, although some commercial products attempt to put everything into the same box. Usually, a firewall has multiple parts, and some of these parts may do other tasks besides function as part of the firewall. Your Internet connection is almost always part of your firewall. Even if you have a firewall in a box, it isn't going to be neatly separable from the rest of your site; it's not something you can just drop in.
We've compared a firewall to the moat of a medieval castle, and like a moat, a firewall is not invulnerable. It doesn't protect against people who are already inside; it works best if coupled with internal defenses; and, even if you stock it with alligators, people sometimes manage to swim across. A firewall is also not without its drawbacks; building one requires significant expense and effort, and the restrictions it places on insiders can be a major annoyance.
Given the limitations and drawbacks of firewalls, why would anybody bother to install one? Because a firewall is the most effective way to connect a network to the Internet and still protect that network. The Internet presents marvelous opportunities. Millions of people are out there exchanging information. The benefits are obvious: the chances for publicity, customer service, and information gathering. The popularity of the information superhighway is increasing everybody's desire to get out there. The risks should also be obvious: any time you get millions of people together, you get crime; it's true in a city, and it's true on the Internet. Any superhighway is fun only while you're in a car. If you have to live or work by the highway, it's loud, smelly, and dangerous.
How can you benefit from the good parts of the Internet without being overwhelmed by the bad? Just as you'd like to drive on a highway without suffering the nasty effects of putting a freeway off-ramp into your living room, you need to carefully control the contact that your network has to the Internet. A firewall is a tool for doing that, and in most situations, it's the single most effective tool for doing that.
There are other uses of firewalls. For example, they can be used to divide parts of a site from each other when these parts have distinct security needs (and we'll discuss these uses in passing, as appropriate). The focus of this book, however, is on firewalls as they're used between a site and the Internet.
Firewalls can do a lot for your site's security. In fact, some advantages of using firewalls extend even beyond security, as described in the sections that follow.
Think of a firewall as a choke point. All traffic in and out must pass through this single, narrow choke point. A firewall gives you an enormous amount of leverage for network security because it lets you concentrate your security measures on this choke point: the point where your network connects to the Internet.
Focusing your security in this way is far more efficient than spreading security decisions and technologies around, trying to cover all the bases in a piecemeal fashion. Although firewalls can cost tens of thousands of dollars to implement, most sites find that concentrating the most effective security hardware and software at the firewall is less expensive and more effective than other security measures — and certainly less expensive than having inadequate security.
Many of the services that people want from the Internet are inherently insecure. The firewall is the traffic cop for these services. It enforces the site's security policy, allowing only "approved" services to pass through and those only within the rules set up for them.
For example, one site's management may decide that certain services are simply too risky to be used across the firewall, no matter what system tries to run them or what user wants them. The firewall will keep potentially dangerous services strictly inside the firewall. (There, they can still be used for insiders to attack each other, but that's outside of the firewall's control.) Another site might decide that only one internal system can communicate with the outside world. Still another site might decide to allow access from all systems of a certain type, or belonging to a certain group. The variations in site security policies are endless.
A firewall may be called upon to help enforce more complicated policies. For example, perhaps only certain systems within the firewall are allowed to transfer files to and from the Internet; by using other mechanisms to control which users have access to those systems, you can control which users have these capabilities. Depending on the technologies you choose to implement your firewall, a firewall may have a greater or lesser ability to enforce such policies.
Because all traffic passes through the firewall, the firewall provides a good place to collect information about system and network use — and misuse. As a single point of access, the firewall can record what occurs between the protected network and the external network.
Although this point is most relevant to the use of internal firewalls, which we describe in Chapter 6, it's worth mentioning here. Sometimes, a firewall will be used to keep one section of your site's network separate from another section. By doing this, you keep problems that impact one section from spreading through the entire network. In some cases, you'll do this because one section of your network may be more trusted than another; in other cases, because one section is more sensitive than another. Whatever the reason, the existence of the firewall limits the damage that a network security problem can do to the overall network.
Firewalls offer excellent protection against network threats, but they aren't a complete security solution. Certain threats are outside the control of the firewall. You need to figure out other ways to protect against these threats by incorporating physical security, host security, and user education into your overall security plan. Some of the weaknesses of firewalls are discussed in the sections that follow.
A firewall might keep a system user from being able to send proprietary information out of an organization over a network connection; so would simply not having a network connection. But that same user could copy the data onto disk, tape, or paper and carry it out of the building in his or her briefcase.
If the attacker is already inside the firewall — if the fox is inside the henhouse — a firewall can do virtually nothing for you. Inside users can steal data, damage hardware and software, and subtly modify programs without ever coming near the firewall. Insider threats require internal security measures, such as host security and user education. Such topics are beyond the scope of this book.
A firewall can effectively control the traffic that passes through it; however, there is nothing a firewall can do about traffic that doesn't pass through it. For example, what if the site allows dial-in access to internal systems behind the firewall? The firewall has absolutely no way of preventing an intruder from getting in through such a modem.
Sometimes, technically expert users or system administrators set up their own "back doors" into the network (such as a dial-up modem connection), either temporarily or permanently, because they chafe at the restrictions that the firewall places upon them and their systems. The firewall can do nothing about this. It's really a people-management problem, not a technical problem.
A firewall is designed to protect against known threats. A well-designed one may also protect against some new threats. (For example, by denying any but a few trusted services, a firewall will prevent people from setting up new and insecure services.) However, no firewall can automatically defend against every new threat that arises. People continuously discover new ways to attack, using previously trustworthy services, or using attacks that simply hadn't occurred to anyone before. You can't set up a firewall once and expect it to protect you forever. (See Chapter 26 for advice on keeping your firewall up to date.)
Firewalls can't keep computer viruses out of a network. It's true that all firewalls scan incoming traffic to some degree, and some firewalls even offer virus protection. However, firewalls don't offer very good virus protection.
Detecting a virus in a random packet of data passing through a firewall is very difficult; it requires:
Recognizing that the packet is part of a program
Determining what the program should look like
Determining that a change in the program is because of a virus
Even the first of these is a challenge. Most firewalls are protecting machines of multiple types with different executable formats. A program may be a compiled executable or a script (e.g., a Unix shell script or a Microsoft batch file), and many machines support multiple, compiled executable types. Furthermore, most programs are packaged for transport and are often compressed as well. Packages being transferred via email or Usenet news will also have been encoded into ASCII in different ways.
For all of these reasons, users may end up bringing viruses behind the firewall, no matter how secure that firewall is. Even if you could do a perfect job of blocking viruses at the firewall, however, you still haven't addressed the virus problem. You've done nothing about the other sources of viruses: software downloaded from dial-up bulletin-board systems, software brought in on floppies from home or other sites, and even software that comes pre-infected from manufacturers are just as common as virus-infected software on the Internet. Whatever you do to address those threats will also address the problem of software transferred through the firewall.
The most practical way to address the virus problem is through host-based virus protection software, and user education concerning the dangers of viruses and precautions to take against them. Virus filtering on the firewall may be a useful adjunct to this sort of precaution, but it will never completely solve the problem.
Every firewall needs some amount of configuration. Every site is slightly different, and it's just not possible for a firewall to magically work correctly when you take it out of the box. Correct configuration is absolutely essential. A misconfigured firewall may be providing only the illusion of security. There's nothing wrong with illusions, as long as they're confusing the other side. A burglar alarm system that consists entirely of some impressive warning stickers and a flashing red light can actually be effective, as long as you don't believe that there's anything else going on. But you know better than to use it on network security, where the warning stickers and the flashing red light are going to be invisible. Unfortunately, many people have firewalls that are in the end no more effective than that, because they've been configured with fundamental problems. A firewall is not a magical protective device that will fix your network security problems no matter what you do with it, and treating it as if it is such a device will merely increase your risk.
There are two main arguments against using firewalls:
Firewalls interfere with the way the Internet is supposed to work, introducing all sorts of problems, annoying users, and slowing down the introduction of new Internet services.
The problems firewalls don't deal with (internal threats and external connections that don't go through the firewall) are more important than the problems they do deal with.
It's true that the Internet is based on a model of end-to-end communication, where individual hosts talk to each other. Firewalls interrupt that end-to-end communication in a variety of ways. Most of the problems that are introduced are the same sorts of problems that are introduced by any security measure. Things are slowed down; things that you want to get through can't; it's hard to introduce changes. Having badge readers on doors introduces the same sorts of problems (you have to swipe the badge and wait for the door to open; when your friends come to meet you they can't get in; new employees have to get badges). The difference is that on the Internet there's a political and emotional attachment to the idea that information is supposed to flow freely and change is supposed to happen rapidly. People are much less willing to accept the sorts of restrictions that they're accustomed to in other environments.
Furthermore, it's truly very annoying to have side effects. There are a number of ways of doing things that provide real advantages and are limited in their spread by firewalls, despite the fact that they aren't security problems. For instance, broadcasting audio and video over the Internet is much easier if you can use multiple simultaneous connections, and if you can get quite precise information about the capabilities of the destination host and the links between you and it. However, firewalls have difficulty managing the connections, they intentionally conceal some information about the destination host, and they unintentionally destroy other information. If you're trying to develop new ways of interacting over the Internet, firewalls are incredibly frustrating; everywhere you turn, there's something cool that TCP/IP is supposed to be able to do that just doesn't work in the real world. It's no wonder that application developers hate firewalls.
Unfortunately, they don't have any better suggestions for how to keep the bad guys out. Think how many marvelous things you could have if you didn't have to lock your front door to keep strangers out; you wouldn't have to sit at home waiting for the repairman or for a package to be delivered, just as a start. The need for security is unavoidable in our world, and it limits what we can do, in annoying ways. The development of the Internet has not changed human nature.
You also hear people say that firewalls are the wave of the past because they don't deal with the real problems. It's true that firewall or no firewall, intruders get in, secret data goes out, and bad things happen. At sites with really good firewalls, these things occur by avoiding the firewalls. At sites that don't have really good firewalls, these things may go on through the firewalls. Either way, you can argue that this shows that firewalls don't solve the problem.
It's perfectly true, firewalls won't solve your security problem. Once again, the people who point this out don't really have anything better to offer. Protecting individual hosts works for some sites and will help the firewall almost anywhere; detecting and dealing with attacks via network monitoring, once again, will work for some problems and will help a firewall almost anywhere. That's basically the entire list of available alternatives. If you look closely at most of the things promoted as being "better than firewalls", you'll discover that they're lightly disguised firewalls marketed by people with restrictive definitions of what a firewall is.
The world is full of "religious arguments", philosophical debates on which people hold strong and divisive beliefs. Firewalls are no exception to this rule.
Initially, 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.
Building 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.
Many 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.
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.
 Richard Power, Current and Future Danger: A CSI Primer on Computer Crime and Information Warfare (San Francisco: Computer Security Institute, 1995).
 You can impress a security expert by saying you've been broken into only once in the last five years; if you say you've never been broken into, they stop being impressed and decide that either you can't detect break-ins, or you haven't been around long enough for anyone to try seriously!