Страница:
Path: gold!nadia!smurf!ira.uka.de!snorkelwacker!usc!ucsd!brian
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: comp.doc
Subject: IMPROVING THE SECURITY OF YOUR UNIX SYSTEM
Message-ID: <13498@ucsd.Edu>
Date: 7 May 90 19:42:47 GMT
Organization: The Avant-Garde of the Now, Ltd.
Lines: 4354
Approved: brian@throne-of-blood.ucsd.edu
Final Report + April 1990
IMPROVING THE SECURITY OF YOUR
UNIX SYSTEM
David A. Curry, Systems Programmer
Information and Telecommunications Sciences and
Technology Division
ITSTD-721-FR-90-21
Approved:
Paul K. Hyder, Manager
Computer Facility
Boyd C. Fair, General Manager
Division Operations Section
Michael S. Frankel, Vice President
Information and Telecommunications Sciences and
Technology Division
SRI International 333 Ravenswood Avenue + Menlo Park, CA 94025 +
(415) 326-6200 + FAX: (415) 326-5512 + Telex: 334486
1 INTRODUCTION........................................... 1
1.1 UNIX Security.......................................... 1
1.2 The Internet Worm...................................... 2
1.3 Spies and Espionage.................................... 3
1.4 Other Break-Ins........................................ 4
1.5 Security is Important.................................. 4
2 IMPROVING SECURITY..................................... 5
2.1 Account Security....................................... 5
2.1.1 Passwords.............................................. 5
2.1.1.1 Selecting Passwords.................................... 6
2.1.1.2 Password Policies...................................... 8
2.1.1.3 Checking Password Security............................. 8
2.1.2 Expiration Dates....................................... 9
2.1.3 Guest Accounts......................................... 10
2.1.4 Accounts Without Passwords............................. 10
2.1.5 Group Accounts and Groups.............................. 10
2.1.6 Yellow Pages........................................... 11
2.2 Network Security....................................... 12
2.2.1 Trusted Hosts.......................................... 13
2.2.1.1 The hosts.equiv File................................... 13
2.2.1.2 The .rhosts File....................................... 14
2.2.2 Secure Terminals....................................... 15
2.2.3 The Network File System................................ 16
2.2.3.1 The exports File....................................... 16
2.2.3.2 The netgroup File...................................... 17
2.2.3.3 Restricting Super-User Access.......................... 18
2.2.4 FTP.................................................... 19
2.2.4.1 Trivial FTP............................................ 20
2.2.5 Mail................................................... 21
2.2.6 Finger................................................. 22
2.2.7 Modems and Terminal Servers............................ 23
2.2.8 Firewalls.............................................. 23
2.3 File System Security................................... 24
2.3.1 Setuid Shell Scripts................................... 25
2.3.2 The Sticky Bit on Directories.......................... 26
2.3.3 The Setgid Bit on Directories.......................... 26
2.3.4 The umask Value........................................ 27
2.3.5 Encrypting Files....................................... 27
2.3.6 Devices................................................ 28
2.4 Security Is Your Responsibility........................ 29
3 MONITORING SECURITY.................................... 31
3.1 Account Security....................................... 31
3.1.1 The lastlog File....................................... 31
3.1.2 The utmp and wtmp Files................................ 31
3.1.3 The acct File.......................................... 33
3.2 Network Security....................................... 34
3.2.1 The syslog Facility.................................... 34
3.2.2 The showmount Command.................................. 35
3.3 File System Security................................... 35
3.3.1 The find Command....................................... 36
3.3.1.1 Finding Setuid and Setgid Files........................ 36
3.3.1.2 Finding World-Writable Files........................... 38
3.3.1.3 Finding Unowned Files.................................. 38
3.3.1.4 Finding .rhosts Files.................................. 39
3.3.2 Checklists............................................. 39
3.3.3 Backups................................................ 40
3.4 Know Your System....................................... 41
3.4.1 The ps Command......................................... 41
3.4.2 The who and w Commands................................. 42
3.4.3 The ls Command......................................... 42
3.5 Keep Your Eyes Open.................................... 42
4 SOFTWARE FOR IMPROVING SECURITY........................ 45
4.1 Obtaining Fixes and New Versions....................... 45
4.1.1 Sun Fixes on UUNET..................................... 45
4.1.2 Berkeley Fixes......................................... 46
4.1.3 Simtel-20 and UUNET.................................... 47
4.1.4 Vendors................................................ 47
4.2 The npasswd Command.................................... 48
4.3 The COPS Package....................................... 48
4.4 Sun C2 Security Features............................... 49
4.5 Kerberos............................................... 50
5 KEEPING ABREAST OF THE BUGS............................ 51
5.1 The Computer Emergency Response Team................... 51
5.2 DDN Management Bulletins............................... 51
5.3 Security-Related Mailing Lists......................... 52
5.3.1 Security............................................... 52
5.3.2 RISKS.................................................. 52
5.3.3 TCP-IP................................................. 53
5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS...................... 53
5.3.5 VIRUS-L................................................ 53
6 SUGGESTED READING...................................... 55
7 CONCLUSIONS............................................ 57
REFERENCES..................................................... 59
APPENDIX A - SECURITY CHECKLIST................................ 63
INTRODUCTION
1.1 UNIX SECURITY
The UNIX operating system, although now in widespread use
in environments concerned about security, was not really
designed with security in mind [Ritc75]. This does not mean
that UNIX does not provide any security mechanisms; indeed,
several very good ones are available. However, most ``out of
the box'' installation procedures from companies such as Sun
Microsystems still install the operating system in much the
same way as it was installed 15 years ago: with little or no
security enabled.
The reasons for this state of affairs are largely histori-
cal. UNIX was originally designed by programmers for use by
other programmers. The environment in which it was used was
one of open cooperation, not one of privacy. Programmers typi-
cally collaborated with each other on projects, and hence pre-
ferred to be able to share their files with each other without
having to climb over security hurdles. Because the first sites
outside of Bell Laboratories to install UNIX were university
research laboratories, where a similar environment existed, no
real need for greater security was seen until some time later.
In the early 1980s, many universities began to move their
UNIX systems out of the research laboratories and into the com-
puter centers, allowing (or forcing) the user population as a
whole to use this new and wonderful system. Many businesses
and government sites began to install UNIX systems as well,
particularly as desktop workstations became more powerful and
affordable. Thus, the UNIX operating system is no longer being
used only in environments where open collaboration is the goal.
Universities require their students to use the system for class
assignments, yet they do not want the students to be able to
copy from each other. Businesses use their UNIX systems for
confidential tasks such as bookkeeping and payroll. And the
government uses UNIX systems for various unclassified yet sen-
sitive purposes.
To complicate matters, new features have been added to
UNIX over the years, making security even more difficult to
control. Perhaps the most problematic features are those
_________________________
UNIX is a registered trademark of AT&T. VAX is a trademark of
Digital Equipment Corporation. Sun-3 and NFS are trademarks of
Sun Microsystems. Annex is a trademark of Xylogics, Inc.
relating to networking: remote login, remote command execu-
tion, network file systems, diskless workstations, and elec-
tronic mail. All of these features have increased the utility
and usability of UNIX by untold amounts. However, these same
features, along with the widespread connection of UNIX systems
to the Internet and other networks, have opened up many new
areas of vulnerability to unauthorized abuse of the system.
On the evening of November 2, 1988, a self-replicating
program, called a worm, was released on the Internet [Seel88,
Spaf88, Eich89]. Overnight, this program had copied itself
from machine to machine, causing the machines it infected to
labor under huge loads, and denying service to the users of
those machines. Although the program only infected two types
of computers,* it spread quickly, as did the concern, confu-
sion, and sometimes panic of system administrators whose
machines were affected. While many system administrators were
aware that something like this could theoretically happen - the
security holes exploited by the worm were well known - the
scope of the worm's break-ins came as a great surprise to most
people.
The worm itself did not destroy any files, steal any
information (other than account passwords), intercept private
mail, or plant other destructive software [Seel88]. However,
it did manage to severely disrupt the operation of the network.
Several sites, including parts of MIT, NASA's Ames Research
Center and Goddard Space Flight Center, the Jet Propulsion
Laboratory, and the U. S. Army Ballistic Research Laboratory,
disconnected themselves from the Internet to avoid recontamina-
tion. In addition, the Defense Communications Agency ordered
the connections between the MILNET and ARPANET shut down, and
kept them down for nearly 24 hours [Eich89, Elme88]. Ironi-
cally, this was perhaps the worst thing to do, since the first
fixes to combat the worm were distributed via the network
[Eich89].
This incident was perhaps the most widely described com-
puter security problem ever. The worm was covered in many
newspapers and magazines around the country including the New
York Times, Wall Street Journal, Time and most computer-
oriented technical publications, as well as on all three major
_________________________
* Sun-3 systems from Sun Microsystems and VAX systems from
Digital Equipment Corp., both running variants of 4.x BSD UNIX
from the University of California at Berkeley.
television networks, the Cable News Network, and National Pub-
lic Radio. In January 1990, a United States District Court
jury found Robert Tappan Morris, the author of the worm, guilty
of charges brought against him under a 1986 federal computer
fraud and abuse law. Morris faces up to five years in prison
and a $250,000 fine [Schu90]. Sentencing is scheduled for May
4, 1990.
1.3 SPIES AND ESPIONAGE
In August 1986, the Lawrence Berkeley Laboratory, an
unclassified research laboratory at the University of Califor-
nia at Berkeley, was attacked by an unauthorized computer
intruder [Stol88, Stol89]. Instead of immediately closing the
holes the intruder was using, the system administrator, Clif-
ford Stoll, elected to watch the intruder and document the
weaknesses he exploited. Over the next 10 months, Stoll
watched the intruder attack over 400 computers around the
world, and successfully enter about 30. The computers broken
into were located at universities, military bases, and defense
contractors [Stol88].
Unlike many intruders seen on the Internet, who typically
enter systems and browse around to see what they can, this
intruder was looking for something specific. Files and data
dealing with the Strategic Defense Initiative, the space shut-
tle, and other military topics all seemed to be of special
interest. Although it is unlikely that the intruder would have
found any truly classified information (the Internet is an
unclassified network), it was highly probable that he could
find a wealth of sensitive material [Stol88].
After a year of tracking the intruder (eventually involv-
ing the FBI, CIA, National Security Agency, Air Force Intelli-
gence, and authorities in West Germany), five men in Hannover,
West Germany were arrested. In March 1989, the five were
charged with espionage: they had been selling the material
they found during their exploits to the KGB. One of the men,
Karl Koch (``Hagbard''), was later found burned to death in an
isolated forest outside Hannover. No suicide note was found
[Stol89]. In February 1990, three of the intruders (Markus
Hess, Dirk Bresinsky, and Peter Carl) were convicted of
espionage in a German court and sentenced to prison terms,
fines, and the loss of their rights to participate in elections
[Risk90]. The last of the intruders, Hans Hubner (``Pengo''),
still faces trial in Berlin.
Numerous other computer security problems have occurred in
recent years, with varying levels of publicity. Some of the
more widely known incidents include break-ins on NASA's SPAN
network [McLe87], the IBM ``Christmas Virus'' [Risk87], a virus
at Mitre Corp. that caused the MILNET to be temporarily iso-
lated from other networks [Risk88], a worm that penetrated DEC-
NET networks [Risk89a], break-ins on U. S. banking networks
[Risk89b], and a multitude of viruses, worms, and trojan horses
affecting personal computer users.
As the previous stories demonstrate, computer security is
an important topic. This document describes the security
features provided by the UNIX operating system, and how they
should be used. The discussion centers around version 4.x of
SunOS, the version of UNIX sold by Sun Microsystems. Most of
the information presented applies equally well to other UNIX
systems. Although there is no way to make a computer com-
pletely secure against unauthorized use (other than to lock it
in a room and turn it off), by following the instructions in
this document you can make your system impregnable to the
``casual'' system cracker,* and make it more difficult for the
sophisticated cracker to penetrate.
_________________________
* The term ``hacker,'' as applied to computer users, originally
had an honorable connotation: ``a person who enjoys learning the
details of programming systems and how to stretch their
capabilities - as opposed to most users of computers, who prefer
to learn only the minimum amount necessary'' [Stee88].
Unfortunately, the media has distorted this definition and given
it a dishonorable meaning. In deference to the true hackers, we
will use the term ``cracker'' throughout this document.
IMPROVING SECURITY
UNIX system security can be divided into three main areas
of concern. Two of these areas, account security and network
security, are primarily concerned with keeping unauthorized
users from gaining access to the system. The third area, file
system security, is concerned with preventing unauthorized
access, either by legitimate users or crackers, to the data
stored in the system. This section describes the UNIX security
tools provided to make each of these areas as secure as possi-
ble.
One of the easiest ways for a cracker to get into a system
is by breaking into someone's account. This is usually easy to
do, since many systems have old accounts whose users have left
the organization, accounts with easy-to-guess passwords, and so
on. This section describes methods that can be used to avoid
these problems.
The password is the most vital part of UNIX account secu-
rity. If a cracker can discover a user's password, he can then
log in to the system and operate with all the capabilities of
that user. If the password obtained is that of the super-user,
the problem is more serious: the cracker will have read and
write access to every file on the system. For this reason,
choosing secure passwords is extremely important.
The UNIX passwd program [Sun88a, 379] places very few res-
trictions on what may be used as a password. Generally, it
requires that passwords contain five or more lowercase letters,
or four characters if a nonalphabetic or uppercase letter is
included. However, if the user ``insists'' that a shorter
password be used (by entering it three times), the program will
allow it. No checks for obviously insecure passwords (see
below) are performed. Thus, it is incumbent upon the system
administrator to ensure that the passwords in use on the system
are secure.
In [Morr78], the authors describe experiments conducted to
determine typical users' habits in the choice of passwords. In
a collection of 3,289 passwords, 16% of them contained three
characters or less, and an astonishing 86% were what could gen-
erally be described as insecure. Additional experiments in
[Gram84] show that by trying three simple guesses on each
account - the login name, the login name in reverse, and the
two concatenated together - a cracker can expect to obtain
access to between 8 and 30 percent of the accounts on a typical
system. A second experiment showed that by trying the 20 most
common female first names, followed by a single digit (a total
of 200 passwords), at least one password was valid on each of
several dozen machines surveyed. Further experimentation by
the author has found that by trying variations on the login
name, user's first and last names, and a list of nearly 1800
common first names, up to 50 percent of the passwords on any
given system can be cracked in a matter of two or three days.
The object when choosing a password is to make it as dif-
ficult as possible for a cracker to make educated guesses about
what you've chosen. This leaves him no alternative but a
brute-force search, trying every possible combination of
letters, numbers, and punctuation. A search of this sort, even
conducted on a machine that could try one million passwords per
second (most machines can try less than one hundred per
second), would require, on the average, over one hundred years
to complete. With this as our goal, and by using the informa-
tion in the preceding text, a set of guidelines for password
selection can be constructed:
+ Don't use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
+ Don't use your first or last name in any form.
+ Don't use your spouse's or child's name.
+ Don't use other information easily obtained about
you. This includes license plate numbers, telephone
numbers, social security numbers, the brand of your
automobile, the name of the street you live on, etc.
+ Don't use a password of all digits, or all the same
letter. This significantly decreases the search time
for a cracker.
+ Don't use a word contained in (English or foreign
language) dictionaries, spelling lists, or other
lists of words.
+ Don't use a password shorter than six characters.
+ Do use a password with mixed-case alphabetics.
+ Do use a password with nonalphabetic characters,
e.g., digits or punctuation.
+ Do use a password that is easy to remember, so you
don't have to write it down.
+ Do use a password that you can type quickly, without
having to look at the keyboard. This makes it harder
for someone to steal your password by watching over
your shoulder.
Although this list may seem to restrict passwords to an
extreme, there are several methods for choosing secure, easy-
to-remember passwords that obey the above rules. Some of these
include the following:
+ Choose a line or two from a song or poem, and use the
first letter of each word. For example, ``In Xanadu
did Kubla Kahn a stately pleasure dome decree''
becomes ``IXdKKaspdd.''
+ Alternate between one consonant and one or two
vowels, up to eight characters. This provides non-
sense words that are usually pronounceable, and thus
easily remembered. Examples include ``routboo,''
``quadpop,'' and so on.
+ Choose two short words and concatenate them together
with a punctation character between them. For exam-
ple: ``dog;rain,'' ``book+mug,'' ``kid?goat.''
The importance of obeying these password selection rules
cannot be overemphasized. The Internet worm, as part of its
strategy for breaking into new machines, attempted to crack
user passwords. First, the worm tried simple choices such as
the login name, user's first and last names, and so on. Next,
the worm tried each word present in an internal dictionary of
432 words (presumably Morris considered these words to be
``good'' words to try). If all else failed, the worm tried
going through the system dictionary, /usr/dict/words, trying
each word [Spaf88]. The password selection rules above suc-
cessfully guard against all three of these strategies.
Although asking users to select secure passwords will help
improve security, by itself it is not enough. It is also
important to form a set of password policies that all users
must obey, in order to keep the passwords secure.
First and foremost, it is important to impress on users
the need to keep their passwords in their minds only. Pass-
words should never be written down on desk blotters, calendars,
and the like. Further, storing passwords in files on the com-
puter must be prohibited. In either case, by writing the pass-
word down on a piece of paper or storing it in a file, the
security of the user's account is totally dependent on the
security of the paper or file, which is usually less than the
security offered by the password encryption software.
A second important policy is that users must never give
out their passwords to others. Many times, a user feels that
it is easier to give someone else his password in order to copy
a file, rather than to set up the permissions on the file so
that it can be copied. Unfortunately, by giving out the pass-
word to another person, the user is placing his trust in this
other person not to distribute the password further, write it
down, and so on.
Finally, it is important to establish a policy that users
must change their passwords from time to time, say twice a
year. This is difficult to enforce on UNIX, since in most
implementations, a password-expiration scheme is not available.
However, there are ways to implement this policy, either by
using third-party software or by sending a memo to the users
requesting that they change their passwords.
This set of policies should be printed and distributed to
all current users of the system. It should also be given to
all new users when they receive their accounts. The policy
usually carries more weight if you can get it signed by the
most ``impressive'' person in your organization (e.g., the
president of the company).
The procedures and policies described in the previous sec-
tions, when properly implemented, will greatly reduce the
chances of a cracker breaking into your system via a stolen
account. However, as with all security measures, you as the
system administrator must periodically check to be sure that
the policies and procedures are being adhered to. One of the
unfortunate truisms of password security is that, ``left to
their own ways, some people will still use cute doggie names as
passwords'' [Gram84].
The best way to check the security of the passwords on
your system is to use a password-cracking program much like a
real cracker would use. If you succeed in cracking any pass-
words, those passwords should be changed immediately. There
are a few freely available password cracking programs distri-
buted via various source archive sites; these are described in
more detail in Section 4. A fairly extensive cracking program
is also available from the author. Alternatively, you can
write your own cracking program, and tailor it to your own
site. For a list of things to check for, see the list of
guidelines above.
Many sites, particularly those with a large number of
users, typically have several old accounts lying around whose
owners have since left the organization. These accounts are a
major security hole: not only can they be broken into if the
password is insecure, but because nobody is using the account
anymore, it is unlikely that a break-in will be noticed.
The simplest way to prevent unused accounts from accumu-
lating is to place an expiration date on every account. These
expiration dates should be near enough in the future that old
accounts will be deleted in a timely manner, yet far enough
apart that the users will not become annoyed. A good figure is
usually one year from the date the account was installed. This
tends to spread the expirations out over the year, rather than
clustering them all at the beginning or end. The expiration
date can easily be stored in the password file (in the full
name field). A simple shell script can be used to periodically
check that all accounts have expiration dates, and that none of
the dates has passed.
On the first day of each month, any user whose account has
expired should be contacted to be sure he is still employed by
the organization, and that he is actively using the account.
Any user who cannot be contacted, or who has not used his
account recently, should be deleted from the system. If a user
is unavailable for some reason (e.g., on vacation) and cannot
be contacted, his account should be disabled by replacing the
encrypted password in the password file entry with an asterisk
(*). This makes it impossible to log in to the account, yet
leaves the account available to be re-enabled on the user's
return.
Guest accounts present still another security hole. By
their nature, these accounts are rarely used, and are always
used by people who should only have access to the machine for
the short period of time they are guests. The most secure way
to handle guest accounts is to install them on an as-needed
basis, and delete them as soon as the people using them leave.
Guest accounts should never be given simple passwords such as
``guest'' or ``visitor,'' and should never be allowed to remain
in the password file when they are not being used.
Some sites have installed accounts with names such as
``who,'' ``date,'' ``lpq,'' and so on that execute simple com-
mands. These accounts are intended to allow users to execute
these commands without having to log in to the machine. Typi-
cally these accounts have no password associated with them, and
can thus be used by anyone. Many of the accounts are given a
user id of zero, so that they execute with super-user permis-
sions.
The problem with these accounts is that they open poten-
tial security holes. By not having passwords on them, and by
having super-user permissions, these accounts practically
invite crackers to try to penetrate them. Usually, if the
cracker can gain access to the system, penetrating these
accounts is simple, because each account executes a different
command. If the cracker can replace any one of these commands
with one of his own, he can then use the unprotected account to
execute his program with super-user permissions.
Simply put, accounts without passwords should not be
allowed on any UNIX system.
Group accounts have become popular at many sites, but are
actually a break-in waiting to happen. A group account is a
single account shared by several people, e.g., by all the col-
laborators on a project. As mentioned in the section on pass-
word security, users should not share passwords - the group
account concept directly violates this policy. The proper way
to allow users to share information, rather than giving them a
group account to use, is to place these users into a group.
This is done by editing the group file, /etc/group [Sun88a,
1390; Sun88b, 66], and creating a new group with the users who
wish to collaborate listed as members.
A line in the group file looks like
groupname:password:groupid:user1,user2,user3,...
The groupname is the name assigned to the group, much like a
login name. It may be the same as someone's login name, or
different. The maximum length of a group name is eight charac-
ters. The password field is unused in BSD-derived versions of
UNIX, and should contain an asterisk (*). The groupid is a
number from 0 to 65535 inclusive. Generally, numbers below 10
are reserved for special purposes, but you may choose any
unused number. The last field is a comma-separated (no spaces)
list of the login names of the users in the group. If no login
names are listed, then the group has no members. To create a
group called ``hackers'' with Huey, Duey, and Louie as members,
you would add a line such as this to the group file:
hackers:*:100:huey,duey,louie
After the group has been created, the files and direc-
tories the members wish to share can then be changed so that
they are owned by this group, and the group permission bits on
the files and directories can be set to allow sharing. Each
user retains his own account, with his own password, thus pro-
tecting the security of the system.
For example, to change Huey's ``programs'' directory to be
owned by the new group and properly set up the permissions so
that all members of the group may access it, the chgrp and
chmod commands would be used as follows [Sun88a, 63-66]:
# chgrp hackers ~huey/programs
# chmod -R g+rw ~huey/programs
The Sun Yellow Pages system [Sun88b, 349-374] allows many
hosts to share password files, group files, and other files via
the network, while the files are stored on only a single host.
Unfortunately, Yellow Pages also contains a few potential secu-
rity holes.
The principal way Yellow Pages works is to have a special
line in the password or group file that begins with a ``+''.
In the password file, this line looks like
+::0:0:::
and in the group file, it looks like
+:
These lines should only be present in the files stored on Yel-
low Pages client machines. They should not be present in the
files on the Yellow Pages master machine(s). When a program
reads the password or group file and encounters one of these
lines, it goes through the network and requests the information
it wants from the Yellow Pages server instead of trying to find
it in the local file. In this way, the data does not have to
be maintained on every host. Since the master machine already
has all the information, there is no need for this special line
to be present there.
Generally speaking, the Yellow Pages service itself is
reasonably secure. There are a few openings that a sophisti-
cated (and dedicated) cracker could exploit, but Sun is rapidly
closing these. The biggest problem with Yellow Pages is the
``+'' line in the password file. If the ``+'' is deleted from
the front of the line, then this line loses its special Yellow
Pages meaning. It instead becomes a regular password file line
for an account with a null login name, no password, and user id
zero (super-user). Thus, if a careless system administrator
accidentally deletes the ``+''. the whole system is wide open
to any attack.*
Yellow Pages is too useful a service to suggest turning it
off, although turning it off would make your system more
secure. Instead, it is recommended that you read carefully the
information in the Sun manuals in order to be fully aware of
Yellow Pages' abilities and its limitations.
_________________________
* Actually, a line like this without a ``+'' is dangerous in
any password file, regardless of whether Yellow Pages is in use.
As trends toward internetworking continue, most sites
will, if they haven't already, connect themselves to one of the
numerous regional networks springing up around the country.
Most of these regional networks are also interconnected, form-
ing the Internet [Hind83, Quar86]. This means that the users
of your machine can access other hosts and communicate with
other users around the world. Unfortunately, it also means
that other hosts and users from around the world can access
your machine, and attempt to break into it.
Before internetworking became commonplace, protecting a
system from unauthorized access simply meant locking the
machine in a room by itself. Now that machines are connected
by networks, however, security is much more complex. This sec-
tion describes the tools and methods available to make your
UNIX networks as secure as possible.
One of the most convenient features of the Berkeley (and
Sun) UNIX networking software is the concept of ``trusted''
hosts. The software allows the specification of other hosts
(and possibly users) who are to be considered trusted - remote
logins and remote command executions from these hosts will be
permitted without requiring the user to enter a password. This
is very convenient, because users do not have to type their
password every time they use the network. Unfortunately, for
the same reason, the concept of a trusted host is also
extremely insecure.
The Internet worm made extensive use of the trusted host
concept to spread itself throughout the network [Seel88]. Many
sites that had already disallowed trusted hosts did fairly well
against the worm compared with those sites that did allow
trusted hosts. Even though it is a security hole, there are
some valid uses for the trusted host concept. This section
describes how to properly implement the trusted hosts facility
while preserving as much security as possible.
The file /etc/hosts.equiv [Sun88a, 1397] can be used by
the system administrator to indicate trusted hosts. Each
trusted host is listed in the file, one host per line. If a
user attempts to log in (using rlogin) or execute a command
(using rsh) remotely from one of the systems listed in
hosts.equiv, and that user has an account on the local system
with the same login name, access is permitted without requiring
a password.
Provided adequate care is taken to allow only local hosts
in the hosts.equiv file, a reasonable compromise between secu-
rity and convenience can be achieved. Nonlocal hosts (includ-
ing hosts at remote sites of the same organization) should
never be trusted. Also, if there are any machines at your
organization that are installed in ``public'' areas (e.g., ter-
minal rooms) as opposed to private offices, you should not
trust these hosts.
On Sun systems, hosts.equiv is controlled with the Yellow
Pages software. As distributed, the default hosts.equiv file
distributed by Sun contains a single line:
+
This indicates that every known host (i.e., the complete con-
tents of the host file) should be considered a trusted host.
This is totally incorrect and a major security hole, since
hosts outside the local organization should never be trusted.
A correctly configured hosts.equiv should never list any
``wildcard'' hosts (such as the ``+''); only specific host
names should be used. When installing a new system from Sun
distribution tapes, you should be sure to either replace the
Sun default hosts.equiv with a correctly configured one, or
delete the file altogether.
The .rhosts file [Sun88a, 1397] is similar in concept and
format to the hosts.equiv file, but allows trusted access only
to specific host-user combinations, rather than to hosts in
general.* Each user may create a .rhosts file in his home
directory, and allow access to her account without a password.
Most people use this mechanism to allow trusted access between
accounts they have on systems owned by different organizations
who do not trust each other's hosts in hosts.equiv. Unfor-
tunately, this file presents a major security problem: While
hosts.equiv is under the system administrator's control and can
be managed effectively, any user may create a .rhosts file
granting access to whomever he chooses, without the system
administrator's knowledge.
_________________________
Actually, hosts.equiv may be used to specify host-user
combinations as well, but this is rarely done.
The only secure way to manage .rhosts files is to com-
pletely disallow them on the system. The system administrator
should check the system often for violations of this policy
(see Section 3.3.1.4). One possible exception to this rule is
the ``root'' account; a .rhosts file may be necessary to allow
network backups and the like to be completed.
Under newer versions of UNIX, the concept of a ``secure''
terminal has been introduced. Simply put, the super-user
(``root'') may not log in on a nonsecure terminal, even with a
password. (Authorized users may still use the su command to
become super-user, however.) The file /etc/ttytab [Sun88a,
1478] is used to control which terminals are considered
secure.| A short excerpt from this file is shown below.
console "/usr/etc/getty std.9600" sun off secure
ttya "/usr/etc/getty std.9600" unknown off secure
ttyb "/usr/etc/getty std.9600" unknown off secure
ttyp0 none network off secure
ttyp1 none network off secure
ttyp2 none network off secure
The keyword ``secure'' at the end of each line indicates that
the terminal is considered secure. To remove this designation,
simply edit the file and delete the ``secure'' keyword. After
saving the file, type the command (as super-user):
# kill -HUP 1
This tells the init process to reread the ttytab file.
The Sun default configuration for ttytab is to consider
all terminals secure, including ``pseudo'' terminals used by
the remote login software. This means that ``root'' may log in
remotely from any host on the network. A more secure confi-
guration would consider as secure only directly connected ter-
minals, or perhaps only the console device. This is how file
servers and other machines with disks should be set up.
The most secure configuration is to remove the ``secure''
designation from all terminals, including the console device.
This requires that those users with super-user authority first
log in as themselves, and then become the super-user via the su
_________________________
| Under non-Sun versions of Berkeley UNIX, this file is called
/etc/ttys.
command. It also requires the ``root'' password to be entered
when rebooting in single-user mode, in order to prevent users
from rebooting their desktop workstations and obtaining super-
user access. This is how all diskless client machines should
be set up.
The Network File System (NFS) [Sun88d] is designed to
allow several hosts to share files over the network. One of
the most common uses of NFS is to allow diskless workstations
to be installed in offices, while keeping all disk storage in a
central location. As distributed by Sun, NFS has no security
features enabled. This means that any host on the Internet may
access your files via NFS, regardless of whether you trust them
or not.
Fortunately, there are several easy ways to make NFS more
secure. The more commonly used methods are described in this
section, and these can be used to make your files quite secure
from unauthorized access via NFS. Secure NFS, introduced in
SunOS Release 4.0, takes security one step further, using
public-key encryption techniques to ensure authorized access.
Discussion of secure NFS is deferred until Section 4.
The file /etc/exports [Sun88a, 1377] is perhaps one of the
most important parts of NFS configuration. This file lists
which file systems are exported (made available for mounting)
to other systems. A typical exports file as installed by the
Sun installation procedure looks something like this:
/usr
/home
/var/spool/mail
#
/export/root/client1 -access=client1,root=client1
/export/swap/client1 -access=client1,root=client1
#
/export/root/client2 -access=client2,root=client2
/export/swap/client2 -access=client2,root=client2
The root= keyword specifies the list of hosts that are allowed
to have super-user access to the files in the named file
system. This keyword is discussed in detail in Section
(separated by colons) that are allowed to mount the named file
system. If no access= keyword is specified for a file system,
any host anywhere on the network may mount that file system via
NFS.
Obviously, this presents a major security problem, since
anyone who can mount your file systems via NFS can then peruse
them at her leisure. Thus, it is important that all file sys-
tems listed in exports have an access= keyword associated with
them. If you have only a few hosts which must mount a file
system, you can list them individually in the file:
/usr -access=host1:host2:host3:host4:host5
However, because the maximum number of hosts that can be listed
this way is ten, the access= keyword will also allow netgroups
to be specified. Netgroups are described in the next section.
After making any changes to the exports file, you should
run the command
# exportfs -a
in order to make the changes take effect.
The file /etc/netgroup [Sun88a, 1407] is used to define
netgroups. This file is controlled by Yellow Pages, and must
be rebuilt in the Yellow Pages maps whenever it is modified.
Consider the following sample netgroup file:
A_Group (servera,,) (clienta1,,) (clienta2,,)
B_Group (serverb,,) (clientb1,,) (clientb2,,)
AdminStaff (clienta1,mary,) (clientb3,joan,)
AllSuns A_Group B_Group
This file defines four netgroups, called A_Group, B_Group,
AdminStaff, and AllSuns. The AllSuns netgroup is actually a
``super group'' containing all the members of the A_Group and
B_Group netgroups.
Each member of a netgroup is defined as a triple: (host,
user, domain). Typically, the domain field is never used, and
is simply left blank. If either the host or user field is left
blank, then any host or user is considered to match. Thus the
triple (host,,) matches any user on the named host, while the
triple (,user,) matches the named user on any host.
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: comp.doc
Subject: IMPROVING THE SECURITY OF YOUR UNIX SYSTEM
Message-ID: <13498@ucsd.Edu>
Date: 7 May 90 19:42:47 GMT
Organization: The Avant-Garde of the Now, Ltd.
Lines: 4354
Approved: brian@throne-of-blood.ucsd.edu
Final Report + April 1990
IMPROVING THE SECURITY OF YOUR
UNIX SYSTEM
David A. Curry, Systems Programmer
Information and Telecommunications Sciences and
Technology Division
ITSTD-721-FR-90-21
Approved:
Paul K. Hyder, Manager
Computer Facility
Boyd C. Fair, General Manager
Division Operations Section
Michael S. Frankel, Vice President
Information and Telecommunications Sciences and
Technology Division
SRI International 333 Ravenswood Avenue + Menlo Park, CA 94025 +
(415) 326-6200 + FAX: (415) 326-5512 + Telex: 334486
1 INTRODUCTION........................................... 1
1.1 UNIX Security.......................................... 1
1.2 The Internet Worm...................................... 2
1.3 Spies and Espionage.................................... 3
1.4 Other Break-Ins........................................ 4
1.5 Security is Important.................................. 4
2 IMPROVING SECURITY..................................... 5
2.1 Account Security....................................... 5
2.1.1 Passwords.............................................. 5
2.1.1.1 Selecting Passwords.................................... 6
2.1.1.2 Password Policies...................................... 8
2.1.1.3 Checking Password Security............................. 8
2.1.2 Expiration Dates....................................... 9
2.1.3 Guest Accounts......................................... 10
2.1.4 Accounts Without Passwords............................. 10
2.1.5 Group Accounts and Groups.............................. 10
2.1.6 Yellow Pages........................................... 11
2.2 Network Security....................................... 12
2.2.1 Trusted Hosts.......................................... 13
2.2.1.1 The hosts.equiv File................................... 13
2.2.1.2 The .rhosts File....................................... 14
2.2.2 Secure Terminals....................................... 15
2.2.3 The Network File System................................ 16
2.2.3.1 The exports File....................................... 16
2.2.3.2 The netgroup File...................................... 17
2.2.3.3 Restricting Super-User Access.......................... 18
2.2.4 FTP.................................................... 19
2.2.4.1 Trivial FTP............................................ 20
2.2.5 Mail................................................... 21
2.2.6 Finger................................................. 22
2.2.7 Modems and Terminal Servers............................ 23
2.2.8 Firewalls.............................................. 23
2.3 File System Security................................... 24
2.3.1 Setuid Shell Scripts................................... 25
2.3.2 The Sticky Bit on Directories.......................... 26
2.3.3 The Setgid Bit on Directories.......................... 26
2.3.4 The umask Value........................................ 27
2.3.5 Encrypting Files....................................... 27
2.3.6 Devices................................................ 28
2.4 Security Is Your Responsibility........................ 29
3 MONITORING SECURITY.................................... 31
3.1 Account Security....................................... 31
3.1.1 The lastlog File....................................... 31
3.1.2 The utmp and wtmp Files................................ 31
3.1.3 The acct File.......................................... 33
3.2 Network Security....................................... 34
3.2.1 The syslog Facility.................................... 34
3.2.2 The showmount Command.................................. 35
3.3 File System Security................................... 35
3.3.1 The find Command....................................... 36
3.3.1.1 Finding Setuid and Setgid Files........................ 36
3.3.1.2 Finding World-Writable Files........................... 38
3.3.1.3 Finding Unowned Files.................................. 38
3.3.1.4 Finding .rhosts Files.................................. 39
3.3.2 Checklists............................................. 39
3.3.3 Backups................................................ 40
3.4 Know Your System....................................... 41
3.4.1 The ps Command......................................... 41
3.4.2 The who and w Commands................................. 42
3.4.3 The ls Command......................................... 42
3.5 Keep Your Eyes Open.................................... 42
4 SOFTWARE FOR IMPROVING SECURITY........................ 45
4.1 Obtaining Fixes and New Versions....................... 45
4.1.1 Sun Fixes on UUNET..................................... 45
4.1.2 Berkeley Fixes......................................... 46
4.1.3 Simtel-20 and UUNET.................................... 47
4.1.4 Vendors................................................ 47
4.2 The npasswd Command.................................... 48
4.3 The COPS Package....................................... 48
4.4 Sun C2 Security Features............................... 49
4.5 Kerberos............................................... 50
5 KEEPING ABREAST OF THE BUGS............................ 51
5.1 The Computer Emergency Response Team................... 51
5.2 DDN Management Bulletins............................... 51
5.3 Security-Related Mailing Lists......................... 52
5.3.1 Security............................................... 52
5.3.2 RISKS.................................................. 52
5.3.3 TCP-IP................................................. 53
5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS...................... 53
5.3.5 VIRUS-L................................................ 53
6 SUGGESTED READING...................................... 55
7 CONCLUSIONS............................................ 57
REFERENCES..................................................... 59
APPENDIX A - SECURITY CHECKLIST................................ 63
INTRODUCTION
1.1 UNIX SECURITY
The UNIX operating system, although now in widespread use
in environments concerned about security, was not really
designed with security in mind [Ritc75]. This does not mean
that UNIX does not provide any security mechanisms; indeed,
several very good ones are available. However, most ``out of
the box'' installation procedures from companies such as Sun
Microsystems still install the operating system in much the
same way as it was installed 15 years ago: with little or no
security enabled.
The reasons for this state of affairs are largely histori-
cal. UNIX was originally designed by programmers for use by
other programmers. The environment in which it was used was
one of open cooperation, not one of privacy. Programmers typi-
cally collaborated with each other on projects, and hence pre-
ferred to be able to share their files with each other without
having to climb over security hurdles. Because the first sites
outside of Bell Laboratories to install UNIX were university
research laboratories, where a similar environment existed, no
real need for greater security was seen until some time later.
In the early 1980s, many universities began to move their
UNIX systems out of the research laboratories and into the com-
puter centers, allowing (or forcing) the user population as a
whole to use this new and wonderful system. Many businesses
and government sites began to install UNIX systems as well,
particularly as desktop workstations became more powerful and
affordable. Thus, the UNIX operating system is no longer being
used only in environments where open collaboration is the goal.
Universities require their students to use the system for class
assignments, yet they do not want the students to be able to
copy from each other. Businesses use their UNIX systems for
confidential tasks such as bookkeeping and payroll. And the
government uses UNIX systems for various unclassified yet sen-
sitive purposes.
To complicate matters, new features have been added to
UNIX over the years, making security even more difficult to
control. Perhaps the most problematic features are those
_________________________
UNIX is a registered trademark of AT&T. VAX is a trademark of
Digital Equipment Corporation. Sun-3 and NFS are trademarks of
Sun Microsystems. Annex is a trademark of Xylogics, Inc.
relating to networking: remote login, remote command execu-
tion, network file systems, diskless workstations, and elec-
tronic mail. All of these features have increased the utility
and usability of UNIX by untold amounts. However, these same
features, along with the widespread connection of UNIX systems
to the Internet and other networks, have opened up many new
areas of vulnerability to unauthorized abuse of the system.
On the evening of November 2, 1988, a self-replicating
program, called a worm, was released on the Internet [Seel88,
Spaf88, Eich89]. Overnight, this program had copied itself
from machine to machine, causing the machines it infected to
labor under huge loads, and denying service to the users of
those machines. Although the program only infected two types
of computers,* it spread quickly, as did the concern, confu-
sion, and sometimes panic of system administrators whose
machines were affected. While many system administrators were
aware that something like this could theoretically happen - the
security holes exploited by the worm were well known - the
scope of the worm's break-ins came as a great surprise to most
people.
The worm itself did not destroy any files, steal any
information (other than account passwords), intercept private
mail, or plant other destructive software [Seel88]. However,
it did manage to severely disrupt the operation of the network.
Several sites, including parts of MIT, NASA's Ames Research
Center and Goddard Space Flight Center, the Jet Propulsion
Laboratory, and the U. S. Army Ballistic Research Laboratory,
disconnected themselves from the Internet to avoid recontamina-
tion. In addition, the Defense Communications Agency ordered
the connections between the MILNET and ARPANET shut down, and
kept them down for nearly 24 hours [Eich89, Elme88]. Ironi-
cally, this was perhaps the worst thing to do, since the first
fixes to combat the worm were distributed via the network
[Eich89].
This incident was perhaps the most widely described com-
puter security problem ever. The worm was covered in many
newspapers and magazines around the country including the New
York Times, Wall Street Journal, Time and most computer-
oriented technical publications, as well as on all three major
_________________________
* Sun-3 systems from Sun Microsystems and VAX systems from
Digital Equipment Corp., both running variants of 4.x BSD UNIX
from the University of California at Berkeley.
television networks, the Cable News Network, and National Pub-
lic Radio. In January 1990, a United States District Court
jury found Robert Tappan Morris, the author of the worm, guilty
of charges brought against him under a 1986 federal computer
fraud and abuse law. Morris faces up to five years in prison
and a $250,000 fine [Schu90]. Sentencing is scheduled for May
4, 1990.
1.3 SPIES AND ESPIONAGE
In August 1986, the Lawrence Berkeley Laboratory, an
unclassified research laboratory at the University of Califor-
nia at Berkeley, was attacked by an unauthorized computer
intruder [Stol88, Stol89]. Instead of immediately closing the
holes the intruder was using, the system administrator, Clif-
ford Stoll, elected to watch the intruder and document the
weaknesses he exploited. Over the next 10 months, Stoll
watched the intruder attack over 400 computers around the
world, and successfully enter about 30. The computers broken
into were located at universities, military bases, and defense
contractors [Stol88].
Unlike many intruders seen on the Internet, who typically
enter systems and browse around to see what they can, this
intruder was looking for something specific. Files and data
dealing with the Strategic Defense Initiative, the space shut-
tle, and other military topics all seemed to be of special
interest. Although it is unlikely that the intruder would have
found any truly classified information (the Internet is an
unclassified network), it was highly probable that he could
find a wealth of sensitive material [Stol88].
After a year of tracking the intruder (eventually involv-
ing the FBI, CIA, National Security Agency, Air Force Intelli-
gence, and authorities in West Germany), five men in Hannover,
West Germany were arrested. In March 1989, the five were
charged with espionage: they had been selling the material
they found during their exploits to the KGB. One of the men,
Karl Koch (``Hagbard''), was later found burned to death in an
isolated forest outside Hannover. No suicide note was found
[Stol89]. In February 1990, three of the intruders (Markus
Hess, Dirk Bresinsky, and Peter Carl) were convicted of
espionage in a German court and sentenced to prison terms,
fines, and the loss of their rights to participate in elections
[Risk90]. The last of the intruders, Hans Hubner (``Pengo''),
still faces trial in Berlin.
Numerous other computer security problems have occurred in
recent years, with varying levels of publicity. Some of the
more widely known incidents include break-ins on NASA's SPAN
network [McLe87], the IBM ``Christmas Virus'' [Risk87], a virus
at Mitre Corp. that caused the MILNET to be temporarily iso-
lated from other networks [Risk88], a worm that penetrated DEC-
NET networks [Risk89a], break-ins on U. S. banking networks
[Risk89b], and a multitude of viruses, worms, and trojan horses
affecting personal computer users.
As the previous stories demonstrate, computer security is
an important topic. This document describes the security
features provided by the UNIX operating system, and how they
should be used. The discussion centers around version 4.x of
SunOS, the version of UNIX sold by Sun Microsystems. Most of
the information presented applies equally well to other UNIX
systems. Although there is no way to make a computer com-
pletely secure against unauthorized use (other than to lock it
in a room and turn it off), by following the instructions in
this document you can make your system impregnable to the
``casual'' system cracker,* and make it more difficult for the
sophisticated cracker to penetrate.
_________________________
* The term ``hacker,'' as applied to computer users, originally
had an honorable connotation: ``a person who enjoys learning the
details of programming systems and how to stretch their
capabilities - as opposed to most users of computers, who prefer
to learn only the minimum amount necessary'' [Stee88].
Unfortunately, the media has distorted this definition and given
it a dishonorable meaning. In deference to the true hackers, we
will use the term ``cracker'' throughout this document.
IMPROVING SECURITY
UNIX system security can be divided into three main areas
of concern. Two of these areas, account security and network
security, are primarily concerned with keeping unauthorized
users from gaining access to the system. The third area, file
system security, is concerned with preventing unauthorized
access, either by legitimate users or crackers, to the data
stored in the system. This section describes the UNIX security
tools provided to make each of these areas as secure as possi-
ble.
One of the easiest ways for a cracker to get into a system
is by breaking into someone's account. This is usually easy to
do, since many systems have old accounts whose users have left
the organization, accounts with easy-to-guess passwords, and so
on. This section describes methods that can be used to avoid
these problems.
The password is the most vital part of UNIX account secu-
rity. If a cracker can discover a user's password, he can then
log in to the system and operate with all the capabilities of
that user. If the password obtained is that of the super-user,
the problem is more serious: the cracker will have read and
write access to every file on the system. For this reason,
choosing secure passwords is extremely important.
The UNIX passwd program [Sun88a, 379] places very few res-
trictions on what may be used as a password. Generally, it
requires that passwords contain five or more lowercase letters,
or four characters if a nonalphabetic or uppercase letter is
included. However, if the user ``insists'' that a shorter
password be used (by entering it three times), the program will
allow it. No checks for obviously insecure passwords (see
below) are performed. Thus, it is incumbent upon the system
administrator to ensure that the passwords in use on the system
are secure.
In [Morr78], the authors describe experiments conducted to
determine typical users' habits in the choice of passwords. In
a collection of 3,289 passwords, 16% of them contained three
characters or less, and an astonishing 86% were what could gen-
erally be described as insecure. Additional experiments in
[Gram84] show that by trying three simple guesses on each
account - the login name, the login name in reverse, and the
two concatenated together - a cracker can expect to obtain
access to between 8 and 30 percent of the accounts on a typical
system. A second experiment showed that by trying the 20 most
common female first names, followed by a single digit (a total
of 200 passwords), at least one password was valid on each of
several dozen machines surveyed. Further experimentation by
the author has found that by trying variations on the login
name, user's first and last names, and a list of nearly 1800
common first names, up to 50 percent of the passwords on any
given system can be cracked in a matter of two or three days.
The object when choosing a password is to make it as dif-
ficult as possible for a cracker to make educated guesses about
what you've chosen. This leaves him no alternative but a
brute-force search, trying every possible combination of
letters, numbers, and punctuation. A search of this sort, even
conducted on a machine that could try one million passwords per
second (most machines can try less than one hundred per
second), would require, on the average, over one hundred years
to complete. With this as our goal, and by using the informa-
tion in the preceding text, a set of guidelines for password
selection can be constructed:
+ Don't use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
+ Don't use your first or last name in any form.
+ Don't use your spouse's or child's name.
+ Don't use other information easily obtained about
you. This includes license plate numbers, telephone
numbers, social security numbers, the brand of your
automobile, the name of the street you live on, etc.
+ Don't use a password of all digits, or all the same
letter. This significantly decreases the search time
for a cracker.
+ Don't use a word contained in (English or foreign
language) dictionaries, spelling lists, or other
lists of words.
+ Don't use a password shorter than six characters.
+ Do use a password with mixed-case alphabetics.
+ Do use a password with nonalphabetic characters,
e.g., digits or punctuation.
+ Do use a password that is easy to remember, so you
don't have to write it down.
+ Do use a password that you can type quickly, without
having to look at the keyboard. This makes it harder
for someone to steal your password by watching over
your shoulder.
Although this list may seem to restrict passwords to an
extreme, there are several methods for choosing secure, easy-
to-remember passwords that obey the above rules. Some of these
include the following:
+ Choose a line or two from a song or poem, and use the
first letter of each word. For example, ``In Xanadu
did Kubla Kahn a stately pleasure dome decree''
becomes ``IXdKKaspdd.''
+ Alternate between one consonant and one or two
vowels, up to eight characters. This provides non-
sense words that are usually pronounceable, and thus
easily remembered. Examples include ``routboo,''
``quadpop,'' and so on.
+ Choose two short words and concatenate them together
with a punctation character between them. For exam-
ple: ``dog;rain,'' ``book+mug,'' ``kid?goat.''
The importance of obeying these password selection rules
cannot be overemphasized. The Internet worm, as part of its
strategy for breaking into new machines, attempted to crack
user passwords. First, the worm tried simple choices such as
the login name, user's first and last names, and so on. Next,
the worm tried each word present in an internal dictionary of
432 words (presumably Morris considered these words to be
``good'' words to try). If all else failed, the worm tried
going through the system dictionary, /usr/dict/words, trying
each word [Spaf88]. The password selection rules above suc-
cessfully guard against all three of these strategies.
Although asking users to select secure passwords will help
improve security, by itself it is not enough. It is also
important to form a set of password policies that all users
must obey, in order to keep the passwords secure.
First and foremost, it is important to impress on users
the need to keep their passwords in their minds only. Pass-
words should never be written down on desk blotters, calendars,
and the like. Further, storing passwords in files on the com-
puter must be prohibited. In either case, by writing the pass-
word down on a piece of paper or storing it in a file, the
security of the user's account is totally dependent on the
security of the paper or file, which is usually less than the
security offered by the password encryption software.
A second important policy is that users must never give
out their passwords to others. Many times, a user feels that
it is easier to give someone else his password in order to copy
a file, rather than to set up the permissions on the file so
that it can be copied. Unfortunately, by giving out the pass-
word to another person, the user is placing his trust in this
other person not to distribute the password further, write it
down, and so on.
Finally, it is important to establish a policy that users
must change their passwords from time to time, say twice a
year. This is difficult to enforce on UNIX, since in most
implementations, a password-expiration scheme is not available.
However, there are ways to implement this policy, either by
using third-party software or by sending a memo to the users
requesting that they change their passwords.
This set of policies should be printed and distributed to
all current users of the system. It should also be given to
all new users when they receive their accounts. The policy
usually carries more weight if you can get it signed by the
most ``impressive'' person in your organization (e.g., the
president of the company).
The procedures and policies described in the previous sec-
tions, when properly implemented, will greatly reduce the
chances of a cracker breaking into your system via a stolen
account. However, as with all security measures, you as the
system administrator must periodically check to be sure that
the policies and procedures are being adhered to. One of the
unfortunate truisms of password security is that, ``left to
their own ways, some people will still use cute doggie names as
passwords'' [Gram84].
The best way to check the security of the passwords on
your system is to use a password-cracking program much like a
real cracker would use. If you succeed in cracking any pass-
words, those passwords should be changed immediately. There
are a few freely available password cracking programs distri-
buted via various source archive sites; these are described in
more detail in Section 4. A fairly extensive cracking program
is also available from the author. Alternatively, you can
write your own cracking program, and tailor it to your own
site. For a list of things to check for, see the list of
guidelines above.
Many sites, particularly those with a large number of
users, typically have several old accounts lying around whose
owners have since left the organization. These accounts are a
major security hole: not only can they be broken into if the
password is insecure, but because nobody is using the account
anymore, it is unlikely that a break-in will be noticed.
The simplest way to prevent unused accounts from accumu-
lating is to place an expiration date on every account. These
expiration dates should be near enough in the future that old
accounts will be deleted in a timely manner, yet far enough
apart that the users will not become annoyed. A good figure is
usually one year from the date the account was installed. This
tends to spread the expirations out over the year, rather than
clustering them all at the beginning or end. The expiration
date can easily be stored in the password file (in the full
name field). A simple shell script can be used to periodically
check that all accounts have expiration dates, and that none of
the dates has passed.
On the first day of each month, any user whose account has
expired should be contacted to be sure he is still employed by
the organization, and that he is actively using the account.
Any user who cannot be contacted, or who has not used his
account recently, should be deleted from the system. If a user
is unavailable for some reason (e.g., on vacation) and cannot
be contacted, his account should be disabled by replacing the
encrypted password in the password file entry with an asterisk
(*). This makes it impossible to log in to the account, yet
leaves the account available to be re-enabled on the user's
return.
Guest accounts present still another security hole. By
their nature, these accounts are rarely used, and are always
used by people who should only have access to the machine for
the short period of time they are guests. The most secure way
to handle guest accounts is to install them on an as-needed
basis, and delete them as soon as the people using them leave.
Guest accounts should never be given simple passwords such as
``guest'' or ``visitor,'' and should never be allowed to remain
in the password file when they are not being used.
Some sites have installed accounts with names such as
``who,'' ``date,'' ``lpq,'' and so on that execute simple com-
mands. These accounts are intended to allow users to execute
these commands without having to log in to the machine. Typi-
cally these accounts have no password associated with them, and
can thus be used by anyone. Many of the accounts are given a
user id of zero, so that they execute with super-user permis-
sions.
The problem with these accounts is that they open poten-
tial security holes. By not having passwords on them, and by
having super-user permissions, these accounts practically
invite crackers to try to penetrate them. Usually, if the
cracker can gain access to the system, penetrating these
accounts is simple, because each account executes a different
command. If the cracker can replace any one of these commands
with one of his own, he can then use the unprotected account to
execute his program with super-user permissions.
Simply put, accounts without passwords should not be
allowed on any UNIX system.
Group accounts have become popular at many sites, but are
actually a break-in waiting to happen. A group account is a
single account shared by several people, e.g., by all the col-
laborators on a project. As mentioned in the section on pass-
word security, users should not share passwords - the group
account concept directly violates this policy. The proper way
to allow users to share information, rather than giving them a
group account to use, is to place these users into a group.
This is done by editing the group file, /etc/group [Sun88a,
1390; Sun88b, 66], and creating a new group with the users who
wish to collaborate listed as members.
A line in the group file looks like
groupname:password:groupid:user1,user2,user3,...
The groupname is the name assigned to the group, much like a
login name. It may be the same as someone's login name, or
different. The maximum length of a group name is eight charac-
ters. The password field is unused in BSD-derived versions of
UNIX, and should contain an asterisk (*). The groupid is a
number from 0 to 65535 inclusive. Generally, numbers below 10
are reserved for special purposes, but you may choose any
unused number. The last field is a comma-separated (no spaces)
list of the login names of the users in the group. If no login
names are listed, then the group has no members. To create a
group called ``hackers'' with Huey, Duey, and Louie as members,
you would add a line such as this to the group file:
hackers:*:100:huey,duey,louie
After the group has been created, the files and direc-
tories the members wish to share can then be changed so that
they are owned by this group, and the group permission bits on
the files and directories can be set to allow sharing. Each
user retains his own account, with his own password, thus pro-
tecting the security of the system.
For example, to change Huey's ``programs'' directory to be
owned by the new group and properly set up the permissions so
that all members of the group may access it, the chgrp and
chmod commands would be used as follows [Sun88a, 63-66]:
# chgrp hackers ~huey/programs
# chmod -R g+rw ~huey/programs
The Sun Yellow Pages system [Sun88b, 349-374] allows many
hosts to share password files, group files, and other files via
the network, while the files are stored on only a single host.
Unfortunately, Yellow Pages also contains a few potential secu-
rity holes.
The principal way Yellow Pages works is to have a special
line in the password or group file that begins with a ``+''.
In the password file, this line looks like
+::0:0:::
and in the group file, it looks like
+:
These lines should only be present in the files stored on Yel-
low Pages client machines. They should not be present in the
files on the Yellow Pages master machine(s). When a program
reads the password or group file and encounters one of these
lines, it goes through the network and requests the information
it wants from the Yellow Pages server instead of trying to find
it in the local file. In this way, the data does not have to
be maintained on every host. Since the master machine already
has all the information, there is no need for this special line
to be present there.
Generally speaking, the Yellow Pages service itself is
reasonably secure. There are a few openings that a sophisti-
cated (and dedicated) cracker could exploit, but Sun is rapidly
closing these. The biggest problem with Yellow Pages is the
``+'' line in the password file. If the ``+'' is deleted from
the front of the line, then this line loses its special Yellow
Pages meaning. It instead becomes a regular password file line
for an account with a null login name, no password, and user id
zero (super-user). Thus, if a careless system administrator
accidentally deletes the ``+''. the whole system is wide open
to any attack.*
Yellow Pages is too useful a service to suggest turning it
off, although turning it off would make your system more
secure. Instead, it is recommended that you read carefully the
information in the Sun manuals in order to be fully aware of
Yellow Pages' abilities and its limitations.
_________________________
* Actually, a line like this without a ``+'' is dangerous in
any password file, regardless of whether Yellow Pages is in use.
As trends toward internetworking continue, most sites
will, if they haven't already, connect themselves to one of the
numerous regional networks springing up around the country.
Most of these regional networks are also interconnected, form-
ing the Internet [Hind83, Quar86]. This means that the users
of your machine can access other hosts and communicate with
other users around the world. Unfortunately, it also means
that other hosts and users from around the world can access
your machine, and attempt to break into it.
Before internetworking became commonplace, protecting a
system from unauthorized access simply meant locking the
machine in a room by itself. Now that machines are connected
by networks, however, security is much more complex. This sec-
tion describes the tools and methods available to make your
UNIX networks as secure as possible.
One of the most convenient features of the Berkeley (and
Sun) UNIX networking software is the concept of ``trusted''
hosts. The software allows the specification of other hosts
(and possibly users) who are to be considered trusted - remote
logins and remote command executions from these hosts will be
permitted without requiring the user to enter a password. This
is very convenient, because users do not have to type their
password every time they use the network. Unfortunately, for
the same reason, the concept of a trusted host is also
extremely insecure.
The Internet worm made extensive use of the trusted host
concept to spread itself throughout the network [Seel88]. Many
sites that had already disallowed trusted hosts did fairly well
against the worm compared with those sites that did allow
trusted hosts. Even though it is a security hole, there are
some valid uses for the trusted host concept. This section
describes how to properly implement the trusted hosts facility
while preserving as much security as possible.
The file /etc/hosts.equiv [Sun88a, 1397] can be used by
the system administrator to indicate trusted hosts. Each
trusted host is listed in the file, one host per line. If a
user attempts to log in (using rlogin) or execute a command
(using rsh) remotely from one of the systems listed in
hosts.equiv, and that user has an account on the local system
with the same login name, access is permitted without requiring
a password.
Provided adequate care is taken to allow only local hosts
in the hosts.equiv file, a reasonable compromise between secu-
rity and convenience can be achieved. Nonlocal hosts (includ-
ing hosts at remote sites of the same organization) should
never be trusted. Also, if there are any machines at your
organization that are installed in ``public'' areas (e.g., ter-
minal rooms) as opposed to private offices, you should not
trust these hosts.
On Sun systems, hosts.equiv is controlled with the Yellow
Pages software. As distributed, the default hosts.equiv file
distributed by Sun contains a single line:
+
This indicates that every known host (i.e., the complete con-
tents of the host file) should be considered a trusted host.
This is totally incorrect and a major security hole, since
hosts outside the local organization should never be trusted.
A correctly configured hosts.equiv should never list any
``wildcard'' hosts (such as the ``+''); only specific host
names should be used. When installing a new system from Sun
distribution tapes, you should be sure to either replace the
Sun default hosts.equiv with a correctly configured one, or
delete the file altogether.
The .rhosts file [Sun88a, 1397] is similar in concept and
format to the hosts.equiv file, but allows trusted access only
to specific host-user combinations, rather than to hosts in
general.* Each user may create a .rhosts file in his home
directory, and allow access to her account without a password.
Most people use this mechanism to allow trusted access between
accounts they have on systems owned by different organizations
who do not trust each other's hosts in hosts.equiv. Unfor-
tunately, this file presents a major security problem: While
hosts.equiv is under the system administrator's control and can
be managed effectively, any user may create a .rhosts file
granting access to whomever he chooses, without the system
administrator's knowledge.
_________________________
Actually, hosts.equiv may be used to specify host-user
combinations as well, but this is rarely done.
The only secure way to manage .rhosts files is to com-
pletely disallow them on the system. The system administrator
should check the system often for violations of this policy
(see Section 3.3.1.4). One possible exception to this rule is
the ``root'' account; a .rhosts file may be necessary to allow
network backups and the like to be completed.
Under newer versions of UNIX, the concept of a ``secure''
terminal has been introduced. Simply put, the super-user
(``root'') may not log in on a nonsecure terminal, even with a
password. (Authorized users may still use the su command to
become super-user, however.) The file /etc/ttytab [Sun88a,
1478] is used to control which terminals are considered
secure.| A short excerpt from this file is shown below.
console "/usr/etc/getty std.9600" sun off secure
ttya "/usr/etc/getty std.9600" unknown off secure
ttyb "/usr/etc/getty std.9600" unknown off secure
ttyp0 none network off secure
ttyp1 none network off secure
ttyp2 none network off secure
The keyword ``secure'' at the end of each line indicates that
the terminal is considered secure. To remove this designation,
simply edit the file and delete the ``secure'' keyword. After
saving the file, type the command (as super-user):
# kill -HUP 1
This tells the init process to reread the ttytab file.
The Sun default configuration for ttytab is to consider
all terminals secure, including ``pseudo'' terminals used by
the remote login software. This means that ``root'' may log in
remotely from any host on the network. A more secure confi-
guration would consider as secure only directly connected ter-
minals, or perhaps only the console device. This is how file
servers and other machines with disks should be set up.
The most secure configuration is to remove the ``secure''
designation from all terminals, including the console device.
This requires that those users with super-user authority first
log in as themselves, and then become the super-user via the su
_________________________
| Under non-Sun versions of Berkeley UNIX, this file is called
/etc/ttys.
command. It also requires the ``root'' password to be entered
when rebooting in single-user mode, in order to prevent users
from rebooting their desktop workstations and obtaining super-
user access. This is how all diskless client machines should
be set up.
The Network File System (NFS) [Sun88d] is designed to
allow several hosts to share files over the network. One of
the most common uses of NFS is to allow diskless workstations
to be installed in offices, while keeping all disk storage in a
central location. As distributed by Sun, NFS has no security
features enabled. This means that any host on the Internet may
access your files via NFS, regardless of whether you trust them
or not.
Fortunately, there are several easy ways to make NFS more
secure. The more commonly used methods are described in this
section, and these can be used to make your files quite secure
from unauthorized access via NFS. Secure NFS, introduced in
SunOS Release 4.0, takes security one step further, using
public-key encryption techniques to ensure authorized access.
Discussion of secure NFS is deferred until Section 4.
The file /etc/exports [Sun88a, 1377] is perhaps one of the
most important parts of NFS configuration. This file lists
which file systems are exported (made available for mounting)
to other systems. A typical exports file as installed by the
Sun installation procedure looks something like this:
/usr
/home
/var/spool/mail
#
/export/root/client1 -access=client1,root=client1
/export/swap/client1 -access=client1,root=client1
#
/export/root/client2 -access=client2,root=client2
/export/swap/client2 -access=client2,root=client2
The root= keyword specifies the list of hosts that are allowed
to have super-user access to the files in the named file
system. This keyword is discussed in detail in Section
(separated by colons) that are allowed to mount the named file
system. If no access= keyword is specified for a file system,
any host anywhere on the network may mount that file system via
NFS.
Obviously, this presents a major security problem, since
anyone who can mount your file systems via NFS can then peruse
them at her leisure. Thus, it is important that all file sys-
tems listed in exports have an access= keyword associated with
them. If you have only a few hosts which must mount a file
system, you can list them individually in the file:
/usr -access=host1:host2:host3:host4:host5
However, because the maximum number of hosts that can be listed
this way is ten, the access= keyword will also allow netgroups
to be specified. Netgroups are described in the next section.
After making any changes to the exports file, you should
run the command
# exportfs -a
in order to make the changes take effect.
The file /etc/netgroup [Sun88a, 1407] is used to define
netgroups. This file is controlled by Yellow Pages, and must
be rebuilt in the Yellow Pages maps whenever it is modified.
Consider the following sample netgroup file:
A_Group (servera,,) (clienta1,,) (clienta2,,)
B_Group (serverb,,) (clientb1,,) (clientb2,,)
AdminStaff (clienta1,mary,) (clientb3,joan,)
AllSuns A_Group B_Group
This file defines four netgroups, called A_Group, B_Group,
AdminStaff, and AllSuns. The AllSuns netgroup is actually a
``super group'' containing all the members of the A_Group and
B_Group netgroups.
Each member of a netgroup is defined as a triple: (host,
user, domain). Typically, the domain field is never used, and
is simply left blank. If either the host or user field is left
blank, then any host or user is considered to match. Thus the
triple (host,,) matches any user on the named host, while the
triple (,user,) matches the named user on any host.