Strategies for a Secure Network

1.3.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, con
artists rarely steal phone service per se; instead, they use the phone system as a tool to reach their
real victims. So it is, in a sense, with network security. Given that the target of the attackers is the
hosts on the network, should they not be suitably configured and armored to resist attack?
The answer is that they should be, but probably cannot. Theorem 3 shows that such attempts are
probably futile. 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 your battlements; if an attacker finds one weakness—say, a
postern gate (backdoor), to extend our metaphor—your system will be penetrated. Unfortunately,
that is not the end of your woes.
By definition, networked machines are not isolated. Typically, other machines will trust them
in some fashion. It might be the almost-blind faith of rlogin, or it might be the sophisticated
cryptographic 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 to
attack other systems, by taking over either root, and hence the system’s identity, or some user
account.
It might seem that we are unduly pessimistic about the state of computer security. This is
half-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 we
alone in feeling this way.
Consider, for example, the famous Orange Book [DoD, 1985a]. The lists of features for each
security level—auditing, access controls, trusted path, and the like—get all the attention, 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. 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 [DoD, 1985b]. 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, later 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 system
administrators 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.
Strategies for a Secure Network 9
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-theshelf
machines 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; given that higher
security generally makes a 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 professionally administered. But it also has many departmental machines that
are unpacked, plugged in, and turned on, and thereafter all but ignored. They run old releases of
the operating system, with bugs 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.
1.3.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.
—SHAKER HYMN
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 have
the 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.
10 Introduction
Boom!
Not all security holes are merely bad. Some go all the way to 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 give some rough guidance about priorities.
We should note that these are design goals; a failure in one aspect does not mean that the collection
is not a firewall, simply that it is not a very good one.
That firewalls are desirable follows directly from our earlier statements. Many hosts—and
more likely, most hosts—cannot protect themselves against a determined attack. Firewalls have
several distinct advantages.
The biggest single reason that a firewall is likely to be more secure is simply that it is not
a general-purpose host. Thus, features that are of doubtful security but add greatly to user
convenience—NIS, rlogin, etc.—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
administrator, but they may be more security conscious. However, they are almost certainly better
than nonadministrators 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.
Fewer normal users is a help as well. Poorly chosen passwords are a serious risk; if users and
their attendant passwords do not exist, this isn’t a problem. Similarly, one can make more or less
arbitrary 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 would be the use
of hand-held authenticators for logging in (Chapter 5). Many people resent them, or they may be
too expensive to be furnished to an entire organization; a gateway machine, however, should have
a restricted-enough user community that these concerns are negligible.
More subtly, gateway machines need not, and should not, be trusted by any other machines.
Thus, even if the gateway machine has been compromised, no others will fall automatically. On
the other hand, the gateway machine can, if you wish (and if you decide against using hand-held
authenticators), trust other machines, thereby eliminating the need for most passwords on the
few accounts it should have. Again, something that is not there cannot be compromised. (Other
components of the firewall can shield vulnerable services on the gateway machine; see Chapter 3.)
Strategies for a Secure Network 11
Gateway machines have other, nonsecurity advantages as well. They are a central point for
mail and FTP administration, for example. Only one machine need be monitored for delayed
mail, proper header syntax, return-address rewriting (i.e., to Firstname.Lastname@ORG.DOMAIN
format), etc. Outsiders have a single point of contact for mail problems and a single location to
search for files being exported.
Our main focus, though, is security. And for all that we have said about the benefits of a
firewall, it should be stressed that we neither advocate nor condone sloppy attitudes towards 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—and in some environments, that is a serious risk—an outsider can gain access by other
means. In at least one case, a hacker came in through a modem pool, and attacked the firewall
from the inside [Hafner and Markoff, 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. AT&T uses them; we leave to your imagination exactly what is being
protected.
1.3.3 Protecting Passwords
􀀀__________ _ ___ _________
(Speak, friend, and enter.)
“What does it mean by speak, friend, and enter? asked Merry.
“That is plain enough,” said Gimli. “If you are a friend, speak the password, and the
doors will open, and you can enter.”
􀀀_􀀀_􀀀
“But do not you know the word, Gandalf?” asked Boromir in surprise.
“No!” said the wizard􀀀_􀀀_􀀀 . “I do not know the word—yet. But we shall soon see.”
Lord of the Rings
—J.R.R. TOLKIEN
1
System bugs are the exciting way to crack a system, but they are not the most common
attack. That honor is reserved for a rather mundane feature: user passwords. A high
percentage of system penetrations occur because of the failure of the entire password
system.
We write “password system” because there are several causes of failure. However, the most
common problem is that people tend to pick very bad passwords. Repeated studies have shown that
password-guessing is likely to succeed; see, for example, [Klein, 1990] or [Morris and Thompson,
1979]. We are not saying that everyone will pick a poor password; however, enough people will
that password-guessing remains a high-probability approach for an attacker.
Password-guessing attacks take two basic forms. The first involves attempts to log in using
known or assumed user names and likely guesses at passwords. This succeeds amazingly often;
12 Introduction
root:DZo0RWR.7DJuU:0:2:0000-Admin(0000):/:
daemon:*:1:1:0000-Admin(0000):/:
bin:*:2:2:0000-Admin(0000):/bin:
sys:*:3:3:0000-Admin(0000):/usr/v9/src:
adm:*:4:4:0000-Admin(0000):/usr/adm:
uucp:*:5:5:0000-uucp(0000):/usr/lib/uucp:
nuucp:*:10:10:0000-uucp(0000):/usr/spool/uucppublic:/usr/lib/uucp/uucico
ftp:anonymous:71:14:file transfer:/:no soap
research:nologin:150:10:ftp distribution account:/forget:/it/baby
ches:La9Cr9ld9qTQY:200:1:me:/u/ches:/bin/sh
dmr:laHheQ.H9iy6I:202:1:Dennis:/u/dmr:/bin/sh
rtm:5bHD/k5k2mTTs:203:1:Rob:/u/rtm:/bin/sh
adb:dcScD6gKF./Z6:205:1:Alan:/u/adb:/bin/sh
td:deJCw4bQcNT3Y:206:1:Tom:/u/td:/bin/sh
Figure 1.2: The bogus /etc/passwd file in our anonymous FTP area.
sites often have account-password pairs such as field-service, guest-guest, etc. These pairs
often come out of system manuals! The first try may not succeed, nor even the tenth, but all too
often, one will work—and once the attacker is in, your major line of defense is gone. Regrettably,
few operating systems can resist attacks from the inside.
This approach should not be possible! Users should not be allowed an infinite number of login
attempts with bad passwords, failures should be logged, users should be notified of failed login
attempts on their accounts, etc. None of this is new technology, but these things are seldom done,
and even more seldom done correctly. Many common mistakes are pointed out in [Grampp and
Morris, 1984], but few developers have heeded their advice. Worse yet, much of the existing
logging on UNIX systems is in login and su; other programs that use passwords—ftpd, rexecd,
various screen-locking programs, etc.—do not log failures on most systems.
The second way hackers go after passwords is by matching guesses against stolen password
files (/etc/passwd on UNIX systems). These may be stolen from a system that is already
cracked, in which case the attackers will try the cracked passwords on other machines (users
tend to reuse passwords), or they may be obtained from a system not yet penetrated. These are
called dictionary attacks, and they are usually very successful. Make no mistake about it: if your
password file falls into enemy hands, there is a very high probability that your machine will be
compromised. Klein [1990] reports cracking about 25% of the passwords; if that figure is accurate
for your machine, and you have just 16 user accounts, there is a 99% chance that at least one of
those passwords will be weak.
A third approach is to tap a legitimate terminal session and log the password used. With this
approach, it doesn’t matter how good a password you have chosen; your account, and probably
your system, is compromised.
We can draw several conclusions from this. The first, of course, is that user education in how
to choose good passwords is vital. Sadly, although almost 15 years have passed since Morris and
Thompson’s paper [Morris and Thompson, 1979] on the subject, user habits have not improved
much. Nor have tightened system restrictions on allowable passwords helped that much, although
there have been a number of attempts, e.g., [Spafford, 1992b; Bishop, 1992]. Others have tried
Strategies for a Secure Network 13