1Introduction
Internet security is certainly a hot topic these days. What was once a small research network, ahome for greybeard researchers and future millionaire geeks, is now front-page material. Internet
security has been the subject of movies, books, and real-life thrillers.
The Internet itself is an entirely new thing in the world: a marketplace, a backyard fence, akind of library, even a telephone. Its growth has been astounding, and the Web is ubiquitous. We
see URLs on beer bottles and TV commercials, and no movie trailer would be complete withoutone.
The Internet is a large city, not a series of small towns. Anyone can use it, and use it nearlyanonymously.
The Internet is a bad neighborhood.

1.1

Security Truisms
We have found that Internet security is not very different from other forms of security. The same
concepts used to design castles apply to the construction of a Web server that offers access to a
corporate database. The details are different, and the technical pieces are quite different, but thesame approaches, rules, and lessons apply.
We present here some important maxims to keep in mind. Most have stood the test of thousands of years.
There is no such thing as absolute security.
We can raise the attacker’s cost of breaching our security to a very high level, but absolute guarantees are not possible. Not even nuclear launch codes are absolutely secure; to give just one
example, a U.S. president once left the codes in a suit that was sent off for cleaning [Feaver,1992].
This fact should not deter connection to the Internet if you need the access. Banks don’t haveperfect security either; they are subject to robberies, fraud, and embezzlement. Long experience3
Licensed under a Creative Commons Attribution-Non-CommericialNoDerivatives 4.0 International (CC BY-NC-ND 4.0) license
https://creativecommons.org/licenses/by-nc-nd/4.0/

Introduction

4

has taught banks which security measures are cost-effective, and they can account for these expected loses in their business plans. Much of the remainder is covered by insurance.
The Internet is new, so the risks are less well understood. As more services are connected, we
will get a better idea of which measures are most effective, and what expected losses may occur.
The chief problem is that the net offers such fat targets to anonymous attackers.
Security is always a question of economics.
What is the value of what you are protecting? How much time, effort, money, and risk are youropponents willing to spend to get through your defenses?
One spook we know reports that there is a $100,000,000 surveillance device that can be
thwarted with something you can buy in a hardware store for $40. This is the kind of leverage we
defenders have in our favor—small steps can raise big barriers.
Keep the level of all your defenses at about the same height.
It makes no sense to fit a bank vault with a screen door in the back, yet we have seen equivalent arrangements on the Internet. Don’t waste time and money on one part of your defenses ifother parts have glaring weaknesses. A firewall makes little sense if the perimeter has numerous
breaches. If you don’t check the contents of parcels leaving the building, is it worth blocking
outgoing ftp connections?
There are many factors to Internet security. Is the firewall secure? Are your people trained toresist “social engineering” attacks (see Section 5.2)? Can you trust your people, and how far? Are
there holes in the perimeter? Are there back doors into your systems? Has the janitor sold out toyour opponents?
An attacker doesn’t go through security, but around it.
Their goal is to find and exploit the weakest link.
Put your defenses in layers.
This is called the belt-and-suspenders approach, or defense in depth. If one layer fails, perhaps
the backup will save you. The layers can take many different forms, and are often conceptual,rather than physical.
This concept has been a vital component of security for thousands of years. Most castles
have more than one wall. For example, one of the authorized roads into Edo Castle in Tokyo wasprotected by three banshos, or guard-houses; the samurai there were charged with watching theretinues of visiting dignitaries. The typical immune system has many overlapping components,and some are redundant.
It’s a bad idea to rely on “security through obscurity.”
You should assume that your adversaries know all of your security arrangements; this is thesafest assumption. It’s okay to keep your setup secret—that’s another layer your opponent has

Security Truisms

5

to surmount—but don’t make that your only protection. The working assumption at the National
Security Agency (NSA) is that serial number 1 of any new device is hand-delivered to the enemy.
Secrets often end up pasted to terminals, or in a corporate dumpster.
Sometimes the appearance of good security will be enough to help deter attackers. For example, the Great Wall of China is a familiar image, and an icon of security. It deterred many attacks,
and suppressed unwanted trade, which was one of its design goals. Some parts, however, used
rice for mortar, and we have heard that some remote parts of the Wall were simply piles of rockand earth. Such cheats remind us of some contemporary security arrangements. Ghengis Kahn
marched through the gates of the wall and into Beijing without trouble; insiders had paved theway for him.
We advocate security without these cheats. It’s a good sign if you can’t reach a host you areworking on because the only way in is broken somehow, and even you don’t have a back door.
Keep it simple.
To paraphrase Einstein: Make your security arrangements as simple as possible, but no simpler.
Complex things are harder to understand, audit, explain, and get right. Try to distill the security portions into simple, manageable pieces. Complicated security measures often are often not
fail-safe.
Don’t give a person or a program any more privileges than those necessary to do thejob.
In the security field, this is called least privilege, and it’s a very important concept. A common
example of this is the valet key for a car, which lets the valet drive the car, but won’t open thetrunk or glove box.
Programming is hard.
This quote of Dijkstra is still true. It is very hard to write bug-free programs, and the difficultyincreases by some power of the program size. We like crucial security programs to be about apage long. Huge security-sensitive programs have been a constant and reliable source of security
problems.
Security should be an integral part of the original design.
Security that is added after the initial design is seldom as reliable. The designer must keep thesecurity assumptions in mind at the design stage or something will be overlooked. Changing
security assumptions later on is a surefire source of security trouble. (On the other hand, networks
aren’t static, either; as you change your network, be sure to examine it for new vulnerabilities.)
If you do not run a program, it does not matter if it has security holes.
Exposed machines should run as few programs as possible; the ones that are run should be as
small as possible. Any program, no matter how innocuous it seems, can harbor security holes.

Introduction

6(Who would have guessed that on some machines, integer divide exceptions1 could lead to systempenetrations?)
A program or protocol is insecure until proven secure.
Consequently, we configure computers in hostile environments to reject everything, unless wehave explicitly made the choice—and accepted the risk—to permit it. Taking the opposite tack,of blocking only known offenders, has proven extremely dangerous.
A chain is only as strong as its weakest link.
An attacker often needs to find only one weakness to be successful. The good news is that we
can usually detect attempts to find the weak link, if we want to. (Alas, most people don’t take thetime.)
Security is a trade-off with convenience.
It is all but impossible to use technical means to enforce more security than the organizational
culture will permit—and most organizational cultures are not very receptive to security systems
that get in the way. Annoyed computer users are a major source of security problems. If security
measures are onerous, they will go around them, or get angry, or complain to management. (Evenintelligence agencies experience this.) Our job as security people is to make the security both asstrong and as unobtrusive as possible.
Well-designed security doesn’t have to be onerous. Good design and appropriate technology
can make security almost painless. The modern hotel door lock contains a computer and perhaps
a network connection to a central control room. It is no longer a security problem for the hotel if
you forget to turn in your key. The hotel can keep track of its own employees when they enter aroom. There are even warnings when a door is left ajar for an unusual length of time. The guest
still needs to carry a key, but it works much better. Automobile locks are getting so good that thethief has to physically remove the entire car—a teenager can’t hot-wire it anymore. Soon, we will
have transmitters and no keys at all. (Of course, transmitters have evolved, too, as car thieves havediscovered scanners and replay attacks.)
Don’t underestimate the value of your assets.
Often, common everyday data is underestimated. Mundane data can be very important. It is said
that pizza shop owners around the Pentagon can tell when a major military action is afoot: They
get numerous calls late at night. A reporter we know asserted that he had no sensitive information
on his computer. We reminded him of his contact lists, story ideas, partial stories, and so on.
Could his competitor across town use this information?
1. See CERT Advisory CA-1992:15, July 21, 1992.

Picking a Security Policy

1.2

7

Picking a Security Policy
Even paranoids have enemies.
—A NONYMOUS
The idea of creating a security policy may smack of bureaucracy to some, especially an eager
technocrat. It brings to mind thick books of regulations and rules that must be read, understood,
and followed. While these may have their place, it’s not what we are talking about here.
A security policy is the set of decisions that, collectively, determines an organization’s posture
toward security. More precisely, a security policy delimits the boundaries of acceptable behavior, and what the response to violations should be. Naturally, security policies will differ fromorganization to organization. An academic department in a university has different needs thana corporate product development organization, which in turn differs from a military site. Everyorganization should have one, however, if only to let it take action when unacceptable eventsoccur.
Your security policy may determine what legal recourse you have if you are ever attacked. In
some jurisdictions, a welcome screen has been interpreted as an invitation to guest users. Furthermore, logging policy may determine whether specific logs are admissible as evidence.
You must first decide what is and is not permitted. To some extent, this process is driven by thebusiness or structural needs of the organization. Thus, some companies may issue an edict thatbars personal use of corporate computers. Some companies wish to restrict outgoing traffic, toguard against employees exporting valuable data. Other policies may be driven by technologicalconsiderations: A specific protocol, though undeniably useful, may not be used because it cannot
be administered securely. Still others are concerned about employees importing software without
proper permission: a company doesn’t want to be sued for infringing on someone else’s rights.
Making such decisions is clearly an iterative process, and one’s choices should never be carved instone (or etched into silicon).
It is hard to form these policies, because they boil down to specific services, which can behighly technical. You often need someone with both the clout of a CEO and the expertise of asecurity wizard. The wizard alone can’t do it; security policies can often be trumped by businessplans [Schneier, 2000].

1.2.1 Policy Questions
To devise a security policy, you must answer several questions. The first question is obvious:
What resources are you trying to protect?
The answer is not always obvious. Is it the CPU cycles? At one time, that made a great deal of
sense; computer time was very expensive. That is no longer true in most situations, supercomputers being a notable exception.
More seriously, a host—or rather, a host running certain software with certain configuration
files—has a name, an identity, that lets it access other, more critical resources. A hacker who

Introduction

8

compromises or impersonates a host will usually have access to all of its resources: files, storage devices, cryptographic keys, and so on. A common goal is to eavesdrop on Net traffic thatflows past the host. Some hackers are most interested in abusing the identity of the host, not somuch to reach its dedicated resources, but to launder further outgoing connections to other, moreinteresting, targets. Others might actually be interested in the data on your machine, whether it issensitive company material or government secrets.
The answer to this first question will dictate the host-specific measures that are needed. Machines with sensitive files may require extra security measures: stronger authentication, keystroke
logging and strict auditing, or even file encryption. If the target of interest is the outgoing connectivity, the administrator may choose to require certain privileges for access to the network. Maybe
all such access should be done through a daemon or proxy that will perform extra logging.
Often one wants to protect all such resources. The obvious answer is to stop the attackers at
the front door, i.e., not let them into the computer system in the first place. Such an approach isalways a useful start, although it tacitly assumes that one’s security problems originate from theoutside.
This leads us to our second major question:
Who is interested in attacking you?
Techniques that suffice against a teenager with a modem are quite useless against a major intelligence agency. For the former, mild encryption might do the trick, whereas the latter can and will
resort to wiretapping, cryptanalysis, monitoring spurious electronic emissions from your computers and wires, and even “black-bag jobs” aimed at your machine room. (Do not underestimate
the teenager, though. He might get the coveted midnight-to-eight janitorial shift in your machineroom [Voyager, 1994].) Furthermore, the intelligence agency may well try the easy stuff first.
Computer security is not a goal, it is a means toward a goal: information security. Whennecessary and appropriate, other means should be used as well. The strength of one’s computer
security defenses should be proportional to the threat. Other defenses, though beyond the scopeof this book, are needed as well.
The third question one must answer before deploying a security mechanism represents the
opposite side of the coin:
How much security can you afford?
Part of the cost of security is direct financial expenditures, such as the extra routers, firewalls,
software packages, and so on. Often, the administrative costs are overlooked. There is anothercost, however, a cost in convenience and productivity, and even morale. Too much security canhurt as surely as too little can. Annoyed by increases in security, good people have left companies.
Finding the proper balance is tricky, but utterly necessary—and it can only be done if you haveproperly assessed the risk to your organization from either extreme.
One more point is worth mentioning. Even if you do not believe you have valuable assets, it isstill worth keeping hackers out of your machines. You may have a relaxed attitude, but that may
not be evident to the attackers. There are far too many cases on record of systems being trashedby hackers who thought they had been detected. (Someone even tried it on us; see Chapter 16.)

Picking a Security Policy

9

1.2.2 Stance
The moral of this story is, anything you don’t understand is dangerous until you do
understand it.

Beowulf Schaefer in Flatlander—L ARRY N IVEN
A key decision in the policy is the stance of your design. The stance is the attitude of the designers.
It is determined by the cost of failure and the designers’ estimate of that likelihood. It is also basedon the designers’ opinions of their own abilities. At one end of the scale is a philosophy that says,“We’ll run it unless you can show me that it’s broken.” People at the other end say, “Show methat it’s both safe and necessary; otherwise, we won’t run it.” Those who are completely off thescale prefer to pull the plug on the network, rather than take any risks at all. Such a move might
be desirable, but it is usually impractical these days. Conversely, one can best appreciate just how
little confidence the U.S. military has in computer security techniques by realizing that connecting
machines containing classified data to unsecured networks is forbidden.
(There’s another lesson to be learned from the military: Their unclassified machines are connected, and have been attacked repeatedly and with some success. Even though the data is (probably) not classified, it is sensitive and important. Don’t underestimate the value of your data.
Furthermore, don’t rely on air gaps too much; users often rely on “sneaker-net” when they need tomove some data between the inside net and the outside one. There are reliable reports of assorted
viruses making their way into classified networks, and the spooks clam up when you ask if viruseshave ever made their way out.)
In general, we have leaned toward the paranoid end of the scale (for our corporate environment, we should stress). In the past, we’ve tried to give our firewalls a fail-safe design: If we haveoverlooked a security hole or installed a broken program, we believe our firewalls are still safe.
This is defense in depth. Compare this approach to a simple packet filter. If the filtering tables
are deleted or installed improperly, or if there are bugs in the router software, the gateway may
be penetrated. This non-fail-safe design is an inexpensive and acceptable solution if your stanceallows a somewhat looser approach to gateway security. In recent years, we’ve eased our stanceon our corporate firewalls. A very tight firewall was inconsistent with the security of our large andgrowing corporate perimeter.
We do not advocate disconnection for most sites. Most people don’t think this is an option
anymore. Our philosophy is simple: there are no absolutes. (And we believe that absolutely. . . )One cannot have complete safety; to pursue that chimera is to ignore the costs of the pursuit.
Networks and internetworks have advantages; to disconnect from a network is to deny oneself
those advantages. When all is said and done, disconnection may be the right choice, but it is a
decision that can only be made by weighing the risks against the benefits.
In fact, disconnection can be self-defeating. If security is too onerous, people will go around
it. It is easy to buy a modem and establish a personal IP link.

Introduction

10

We advocate caution, not hysteria. For reasons that are spelled out below, we think that firewalls are an important tool that can minimize the risk, while providing most of the benefits of a
network connection.
Whether or not a security policy is formally spelled out, one always exists. If nothing else issaid or implemented, the default policy is “anything goes.” Needless to say, this stance is rarely
acceptable in a security-conscious environment. If you do not make explicit decisions, you havemade the default decision to allow almost anything.
It is not for us to decree what services are or are not acceptable. As stated earlier, suchdecisions are necessarily context-dependent. The rules we have provided, however, are universal.

1.3

Host-Based Security
If a host is connected to a network, it ought to be up to the host to protect itself from networkborne abuses. Many opponents of firewalls espouse this, and we don’t disagree—in theory. It is
possible to tighten up a host to a fair degree, possibly far enough that attackers will resort to otherless-convenient and less-anonymous avenues of attack.
The problem is that most commercial systems are sold with glaring security holes. Most of theoriginal suite of traditional Internet services are unsafe to some degree. The vendors sell systems
this way because these services are popular and useful. Traditional U NIX workstations come withdozens of these services turned on. Routers are generally administered through the telnet service,
which is subject to at least two easy attacks. Even PCs, which used to be too dumb to havedangerous services, are now beginning to offer them. For example, at least two different packages
allow even a Windows 95 or 98 machine to host a simple Web server. Both of these have hadvery serious security holes. Modern versions of Windows run many more services, resulting inmany more potential holes. (Do you know what services are running on your corporate Windows
machines? Do you know how to find out, how to disable them, and how to do it reliably on all
such machines, including every new one that is delivered? Can you tell if some user has turned aservice back on? Do you know what new functions are enabled by vendor service packs?)
The hosts that tend to be safer include the commercial firewalls, which were originally builtwith security as their primary goal, and multilevel secure systems (MLSs), for the same reason.
The software market is starting to offer relatively secure services. The Secure Socket Layer(SSL) provides reasonably easy access to encrypted connections, and numerous similar attempts
are evolving.
The old services persist, however. Most hosts in an administrative zone trust one another, so
one weak link can compromise the whole cluster. We suspect that it will be a long time before
this general situation is improved, so we must resort to perimeter security.

1.4

Perimeter Security
If it is too difficult to secure each house in a neighborhood, perhaps the residents can band together
to build a wall around the town. Then the people need fear only themselves, and an invading force

Strategies for a Secure Network

11

that is strong enough to breach the wall. Alert, well-trained guards can be posted at the gates while
the people go about their business. Similarly, the king’s residence can be enclosed in another wall,
adding an additional layer of defense (at least for the king).
This approach is called perimeter security, and it is very important on the Internet. It has twocomponents: the wall and the gate. On the Internet, the gate is implemented with a firewall, a
configuration of machines and software that allows the townspeople to do their business, without
letting the Bad Guys in. To be effective, the wall should go all the way around the town, and behigh enough and thick enough to withstand attack. It also must not have holes or secret entrancesthat allow an attacker to creep in past the guards.
The perimeter approach is not effective if the town is too large. The protected “towns” on theInternet are growing as quickly as the Internet as a whole. Just before it split into three companies,
AT&T had several times as many hosts “inside” its perimeter as the entire Internet had when the
Morris Worm was released in 1988. No one individual knew the location, the policies, the security,or the connectivity of all of these hosts. Lack of knowledge alone can call into question a perimeter
defense.

1.5

Strategies for a Secure Network
1.5.1 Host Security
To some people, the very notion of a firewall is anathema. In most situations, the network is not
the resource at risk; rather, it is the endpoints of the network that are threatened. By analogy, conartists rarely steal phone service per se; instead, they use the phone system as a tool to reach theirreal victims. So it is, in a sense, with network security. Given that the target of the attackers is thehosts on the network, should they not be suitably configured and armored to resist attack?
The answer is that they should be, but probably cannot. There will be bugs, either in the
network programs or in the administration of the system. It is this way with computer security:
the attacker only has to win once. It does not matter how thick are your walls, nor how lofty yourbattlements; if an attacker finds one weakness—say, a postern gate (back door), to extend our
metaphor—your system will be penetrated. Unfortunately, that is not the end of your troubles.
By definition, networked machines are not isolated. Typically, other machines will trust themin some fashion. It might be the almost-blind faith of rlogin, or it might be the sophisticatedcryptographic verification used by the Kerberos authentication system [Bryant, 1988; Kohl and
Neuman, 1993; Miller et al., 1987; Steiner et al., 1988], in which case a particular user will be
trusted. It doesn’t matter—if the intruder can compromise the system, he or she will be able toattack other systems, either by taking over root, and hence the system’s identity, or by taking oversome user account. This is called transitive trust.
It might seem that we are unduly pessimistic about the state of computer security. This ishalf-true: we are pessimistic, but not, we think, unduly so. Nothing in the recent history of either
network security or software engineering gives us any reason to believe otherwise. Nor are wealone in feeling this way.
Consider, for example, the famous Orange Book [Brand, 1985]. The lists of features foreach security level—auditing, access controls, trusted path, and the like—got all the attention,

Introduction

12

Boom!
Not all security holes are merely bad. Some are truly horrendous. We use a “bomb”
symbol to indicate a particularly serious risk. That doesn’t mean you can be sanguine about the others—the intruders don’t care much how they get in—but it does
provide some rough guidance about priorities.

but the higher levels also have much more stringent assurance requirements. That is, there must
be more reason to believe that the system actually functions as designed. (The Common Criteria[CC, 1999] made this distinction even clearer.) Despite those requirements, even the most trusted
system, with an A1 evaluation, is not trusted with the most sensitive information if uncleared users
have access to the system [Neugent and Olson, 1985]. Few systems on the Internet meet even the
C2 requirements; their security is not adequate.
Another challenge exists that is totally unrelated to the difficulty of creating secure systems:
administering them. No matter how well written the code and how clean the design, subsequent
human error can negate all of the protections. Consider the following sequence of events:
1. A gateway machine malfunctioned on a holiday weekend, when none of the usual systemadministrators was available.
2. The backup expert could not diagnose the problem over the phone and needed a guest
account created.
3. The operator added the account guest, with no password.
4. The expert neglected to add a password.
5. The operator forgot to delete the account.
6. Some university students found the account within a day and told their friends.
Unlikely? Perhaps, but it happened to one of our gateways. The penetration was discovered only
when the unwanted guests happened to trigger an alarm while probing our other gateway machine.
Our firewall machines are, relatively speaking, simple to administer. They run minimal configurations, which in and of itself eliminates the need to worry about certain things. Off-the-shelfmachines have lots of knobs, buttons, and switches with which to fiddle, and many of the settings
are insecure. Worse yet, many are shipped that way by the vendor; higher security generally makesa system less convenient to use and administer. Some manufacturers choose to position their products for the “easy-to-use” market. Our internal network has many machines that are professionallyadministered. However, it also has many departmental machines that are unpacked, plugged in,Strategies for a Secure Network

13

turned on, and thereafter all but ignored. These machines run old releases of the operating system,with bugs that are fixed if and only if they directly affect the user population. If the system works,
why change it? A reasonable attitude much of the time, but a risky one, given the intertwined
patterns of transitive network trust.
(Even a firewall may not be secure. Many firewalls are add-on packages to off-the-shelf operating systems. If you haven’t locked down the base platform, it may be susceptible to attack.
Apart from that, some firewalls are themselves quite complex, with numerous programs runningthat must pass very many protocols through the firewalls. Are these programs correct? Is the administration of this complex configuration correct? We hope so, but history suggests otherwise.)

1.5.2 Gateways and Firewalls’Tis a gift to be simple,’Tis a gift to be free,’Tis a gift to come down where we ought to be,
And when we find ourselves in the place just right,
It will be in the valley of love and delight.
When true simplicity is gained,
To bow and to bend, we will not be ashamed
To turn, turn, will be our delight,’Til by turning, turning, we come round right.
—S HAKER DANCE SONG
By this point, it should be no surprise that we recommend using firewalls to protect networks. We
define a firewall as a collection of components placed between two networks that collectively havethe following properties:• All traffic from inside to outside, and vice-versa, must pass through the firewall.
• Only authorized traffic, as defined by the local security policy, will be allowed to pass.
• The firewall itself is immune to penetration.
We should note that these are design goals; a failure in one aspect does not mean that the collection
is not a firewall, but that it is not a very good one.
That firewalls are desirable follows directly from our earlier statements. Many hosts—andmore likely, most hosts—cannot protect themselves against a determined attack. Firewalls haveseveral distinct advantages.
The biggest single reason that a firewall is likely to be more secure is simply that it is nota general-purpose host. Thus, features that are of doubtful security but add greatly to userconvenience—NIS, rlogin, and so on—are not necessary. For that matter, many features of unknown security can be omitted if they are irrelevant to the firewall’s functionality.
A second benefit comes from having professional administration of the firewall machines. We
do not claim that firewall administrators are necessarily more competent than your average system

Introduction

14

administrator. They may be more security conscious. However, they are almost certainly better
than non-administrators who must nevertheless tend to their own machines. This category would
include physical scientists, professors, and the like, who (rightly) prefer to worry about their own
areas of responsibility. It may or may not be reasonable to demand more security consciousness
from them; nevertheless, it is obviously not their top priority.
A third benefit is that commercial firewalls are designed for the job. People can build fairly
secure machines when there is a commercial need for it. Occasionally, they are broken, but usually
they fail when misconfigured.
A firewall usually has no normal users. This is a big help: users can cause many problems.
They often choose poor passwords, a serious risk. Without users, one can make more or lessarbitrary changes to various program interfaces if that would help security, without annoying a
population that is accustomed to a different way of doing things. One example is the use ofhandheld authenticators for logging in (see Chapter 7). Many people resent them, or they may
be too expensive to be furnished to an entire organization. A gateway machine should have arestricted-enough user community that these concerns are negligible.
Gateway machines have other, nonsecurity advantages as well. They are a central point for
mail, FTP, and Web administration, for example. Only one machine need be monitored for delayed
mail, proper header syntax, spam control, alias translation, and so on. Outsiders have a single pointof contact for mail problems and a single location to search for files being exported.
Our main focus, though, is security. For all that we have said about the benefits of a firewall,it should be stressed that we neither advocate nor condone sloppy attitudes toward host security.
Even if a firewall were impermeable, and even if the administrators and operators never made any
mistakes, the Internet is not the only source of danger. Apart from the risk of insider attacks—andin many environments, that is a serious risk—an outsider can gain access by other means. Often,
a hacker has come in through a modem pool, and attacked the firewall from the inside [Hafner andMarkoff, 1991]. Strong host security policies are a necessity, not a luxury.
For that matter, internal firewalls are a good idea, to protect very sensitive portions of organizational networks. As intranets grow, they become harder to protect, and hence less trustworthy.
A firewall can protect your department from intruders elsewhere in the company. Schools must
protect administrative computers containing grades, payroll, and alumni data from their general
student population. We expect this Balkanization of intranets to increase.

1.5.3 DMZs
Some servers are difficult to trust because of the size and the complexity of the code they run.
Web servers are a classic example. Do you place your external Web server inside the firewall, or
outside? If you place it inside, then a compromise creates a launch point for further attacks on
inside machines. If you place it outside, then you make it even easier to attack. The common
approach to this is to create a demilitarized zone (DMZ) between two firewalls. (The name is apoor one—it’s really more like a no-man’s land—but the phrase is common terminology in thefirewall business.) Like its real-world analog in Korea, the network DMZ needs to be monitored
carefully, as it is a place where sensitive objects are exposed to higher risk than services all theway on the inside.

Strategies for a Secure Network15

It is important to carefully control administrative access to services on the DMZ. Most likely,
this should only come from the internal network, and preferably over a cryptographically protectedconnection, such as ssh.
A DMZ is an example of our general philosophy of defense in depth. That is, multiple layers of security provide a better shield. If an attacker penetrates past the first firewall, he or she
gains access to the DMZ, but not necessarily to the internal network. Without the DMZ, the firstsuccessful penetration could result in a more serious compromise.
You should not fully trust machines that reside in the DMZ—that’s the reason we put them
there. Important Web servers may need access to, say, a vital internal database, but ensure that the
database server assumes that queries may come from an untrusted source. Otherwise, an attacker
may be able to steal the crown jewels via the compromised Web server. We’ll stress this point
again and again: Nothing is completely secure, but some situations need more care (and moredefenses) than do others.

1.5.4 Encryption—Communications Security
Encryption is often touted as the ultimate weapon in the computer security wars. It is not. It is
certainly a valuable tool (see Chapter 18), but if encryption is used improperly, it can hurt the real
goals of the organization.
The difference here is between cryptography, the encryption methods themselves, and theapplication or environment using the cryptography. In many cases, the cryptographic systemdoesn’t need to be cracked, just evaded. You don’t go through security, you go around it.
Some aspects of improper use are obvious. One must pick a strong enough cryptosystem
for the situation, or an enemy might cryptanalyze it. Similarly, the key distribution center mustbe safeguarded, or all of your secrets will be exposed. Furthermore, one must ensure that thecryptographic software isn’t buggy; that has happened, too (see e.g., CERT Advisory CA-199503a, CERT Advisory CA-1998-07, CERT Advisory CA-1999-15, CERT Advisory CA-2002-23,
and CERT Advisory CA-2002-27).
Other dangers exist as well. For one thing, encryption is best used to safeguard file transmission, rather than file storage, especially if the encryption key is generated from a typed password. Few people bequeath knowledge of their passwords in their wills; more have been known
to walk in front of trucks. There are schemes to deal with such situations (e.g., [Shamir, 1979;
Gifford, 1982; Blaze, 1994]), but these are rarely used in practice. Admittedly, you may not be
concerned with the contents of your files after your untimely demise, but your organization—in
some sense the real owner of the information you produce at work—might feel differently.
Even without such melodrama, if the machine you use to encrypt and decrypt the files is
not physically secure, a determined enemy can simply replace the cryptographic commands withvariants that squirrel away a copy of the key. Have you checked the integrity of such commands on
your disk recently? Did someone corrupt your integrity-checker? Or perhaps someone is logging
keystrokes on your machine.
Finally, the biggest risk of all may be your own memory. Do you remember what password
you used a year ago? (You do change your password regularly, do you not?) You used thatpassword every day; how often would you use a file encryption key?

Introduction

16

If a machine is physically and logically secure enough that you can trust the encryption process, encryption is most likely not needed. If the machine is not that secure, encryption may not
help. A smart card may protect your keys, which is good; however, an attacker who has penetrated
your machine may be able to ask your smart card to decrypt your files.
There is one exception to our general rule: backup tapes. Such tapes rarely receive sufficient
protection, and there is never any help from the operating system. One can make a very good casefor encrypting the entire tape during the dump process—if there is some key storage mechanism
guaranteed to permit you to read the year-old backup tape when you realize that you are missing
a critical file. It is the information that is valuable; if you have lost the contents of a file, it matterslittle if the cause was a hacker, a bad backup tape, a lost password, or an errant rm command.

1.6

The Ethics of Computer Security
Sed quis custodiet ipsos custodes? (But who will guard the guards themselves?)
Satires, VI, line 347—J UVENAL , C . 100 C.E.
At first blush, it seems odd to ask if computer security is ethical. We are, in fact, comfortable withwhat we are doing, but that is because we have asked the question of ourselves, and then answered
it to our own satisfaction.
There are several different aspects to the question. The first is whether or not computer security
is a proper goal. We think so; if you disagree, there is probably a deep philosophical chasm
between you and us, one that we may not be able to bridge. We will therefore settle for listing ourreasons, without any attempt to challenge yours.
First, in a technological era, computer security is fundamental to individual privacy. A great
deal of very personal information is stored on computers. If these computers are not safe fromprying eyes, neither is the data they hold. Worse yet, some of the most sensitive data—credit
histories, bank balances, and the like—lives on machines attached to very large networks. We
hope that our work will in some measure contribute to the protection of these machines.
Second, computer security is a matter of good manners. If people want to be left alone,they should be, whether or not you think their attitude makes sense. Our employer demonstrably
wants its computer systems to be left in peace. That alone should suffice, absent an exceedinglycompelling reason for feeling otherwise.
Third, more and more of modern society depends on computers, and on the integrity of the
programs and data they contain. These range from the obvious (the financial industry comes tomind) to the ubiquitous (the entire telephone system is controlled by a vast network of computers) to the life-critical (computerized medical devices and medical information systems). The
problems caused by bugs in such systems are legion; the mind boggles at the harm that could becaused—intentionally or not!—by unauthorized changes to any such systems. Computer security
is as important in the information age as were walled cities a millennium ago.
A computer intrusion has already been blamed for loss of life. According to Scotland Yard,an attack on a weather computer stopped forecasts for the English Channel, which led to the loss

The Ethics of Computer Security17

of a ship at sea [Markoff, 1993]. (Recent legal changes in the U.S. take cognizance of this, too:hacking that results in deaths can be punished by life imprisonment.)
That the hackers behave badly is no excuse for us doing the same. We can and must do better.
Consider the question of “counterintelligence,” the activities we undertake to learn who has
been pounding on our door. Clearly, it is possible to go too far in that direction. We do not,and will not, attempt to break into a malefactor’s system in order to learn more about the attacks.
(This has been done at least once by a government organization. They believed they had proper
legal authorization.) Similarly, when we found that our machine was being used as a repository for
pirated software, we resisted the temptation to replace those programs with virus-infected versions(but we did joke about it).
The ethical issues go even further. Some people have suggested that in the event of a successful
attack in progress, we might be justified in penetrating the attacker’s computers under the doctrineof self-defense. That is, it may be permissible to stage your own counterattack in order to stop an
immediate and present danger to your own property. The legal status of such an action is quitemurky, although analogous precedents do exist. Regardless, we have not carried out any suchaction, and we would be extremely reluctant to. If nothing else, we would prefer to adhere to ahigher moral standard than might be strictly required by law.
It was suggested by a federal prosector that pursuit in this manner by a foreign country would
constitute an act of war. This may be a little extreme—a private citizen can perform an act ofterrorism, not war. However, acts of terrorism can elicit military responses.
Overall, we are satisfied with what we are doing. Within the bounds set by legal restrictions,
we do not regard it as wrong to monitor our own machine. It is, after all, ours; we have the rightto control how it is used, and by whom. (More precisely, it is a company-owned machine, but
we have been given the right and the responsibility to ensure that it is used in accordance withcompany guidelines.) Most other sites on the Internet feel the same way. We are not impressed by
the argument that idle machine cycles are being wasted. They are our cycles: we will use them as
we wish. Most individuals’ needs for computing power can be met at a remarkably modest cost.
Finally, given the currently abysmal state of host security, we know of no other way to ensure that
our firewall itself is not compromised.
Equally important, the reaction from system administrators whom we have contacted has generally been quite positive. In most cases, we have been told that either the probe was innocent, inwhich case nothing is done, or that the attacker was in fact a known troublemaker. In that case,the very concept of entrapment does not apply, as by definition, entrapment is an inducement tocommit a violation that the victim would not otherwise have been inclined to commit. In a few
cases, a system administrator has learned, through our messages, that his or her system was itself
compromised. Our peers—the electronic community of which we are a part—do not feel that wehave abused their trust.
Of course, cyberwarfare is now an active part of information warfare. These rules are a bit
genteel in some circumstances.

Introduction

18

1.7

WARNINGIn the past, some people have interpreted our descriptions of our security mechanisms as an invitation to poke at us, just to see if we would notice. We are sure, of course, that their hearts were
pure. Conceivably, some of you might entertain similar misconceptions. We therefore humbly
beseech you, our gentle readers:

PLEASE DON’T.
We have quite enough other things to do; it is a waste of your time and ours, and we don’t
really need the extra amusement. Besides, our companies’ corporate security departments seldom
exhibit a sense of humor.