💾 Archived View for spam.works › mirrors › textfiles › programming › security.hac captured on 2023-11-14 at 11:51:55.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
Final Report +o 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 +o Menlo Park, CA 94025 +o
(415) 326-6200 +o FAX: (415) 326-5512 +o Telex: 334486
CONTENTS
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
iii
CONTENTS (concluded)
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
iv
SECTION 1
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.
1
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.
1.2 THE INTERNET WORM
On the evening of November 2, 1988, a self-replicating
program, called a _w_o_r_m, 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 _N_e_w
_Y_o_r_k _T_i_m_e_s, _W_a_l_l _S_t_r_e_e_t _J_o_u_r_n_a_l, _T_i_m_e 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.
2
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 Hu"bner (``Pengo''),
still faces trial in Berlin.
3
1.4 OTHER BREAK-INS
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.
1.5 SECURITY IS IMPORTANT
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.
4
SECTION 2
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.
2.1 ACCOUNT SECURITY
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.
2.1.1 Passwords
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 _p_a_s_s_w_d 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.
5
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.
2.1.1.1 Selecting Passwords
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:
+o _D_o_n'_t use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
+o _D_o_n'_t use your first or last name in any form.
+o _D_o_n'_t use your spouse's or child's name.
+o _D_o_n'_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.
+o _D_o_n'_t use a password of all digits, or all the same
letter. This significantly decreases the search time
for a cracker.
+o _D_o_n'_t use a word contained in (English or foreign
6
language) dictionaries, spelling lists, or other
lists of words.
+o _D_o_n'_t use a password shorter than six characters.
+o _D_o use a password with mixed-case alphabetics.
+o _D_o use a password with nonalphabetic characters,
e.g., digits or punctuation.
+o _D_o use a password that is easy to remember, so you
don't have to write it down.
+o _D_o 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:
+o 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.''
+o 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.
+o 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, /_u_s_r/_d_i_c_t/_w_o_r_d_s, trying
each word [Spaf88]. The password selection rules above suc-
cessfully guard against all three of these strategies.
7
2.1.1.2 Password Policies
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).
2.1.1.3 Checking Password Security
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
8
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.
2.1.2 Expiration Dates
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
9
leaves the account available to be re-enabled on the user's
return.
2.1.3 Guest Accounts
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.
2.1.4 Accounts Without Passwords
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.
2.1.5 Group Accounts and Groups
Group accounts have become popular at many sites, but are
actually a break-in waiting to happen. A group account is a
10
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, /_e_t_c/_g_r_o_u_p [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 _g_r_o_u_p_n_a_m_e 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 _g_r_o_u_p_i_d 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 _c_h_g_r_p and
_c_h_m_o_d commands would be used as follows [Sun88a, 63-66]:
# chgrp hackers ~huey/programs
# chmod -R g+rw ~huey/programs
2.1.6 Yellow Pages
The Sun Yellow Pages system [Sun88b, 349-374] allows many
11
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.
2.2 NETWORK SECURITY
_________________________
* Actually, a line like this without a ``+'' is dangerous in
any password file, regardless of whether Yellow Pages is in use.
12
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.
2.2.1 Trusted Hosts
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.
2.2.1.1 The hosts.equiv File
The file /_e_t_c/_h_o_s_t_s._e_q_u_i_v [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 _r_l_o_g_i_n) or execute a command
(using _r_s_h) remotely from one of the systems listed in
13
_h_o_s_t_s._e_q_u_i_v, 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 _h_o_s_t_s._e_q_u_i_v 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, _h_o_s_t_s._e_q_u_i_v is controlled with the Yellow
Pages software. As distributed, the default _h_o_s_t_s._e_q_u_i_v file
distributed by Sun contains a single line:
+
This indicates that _e_v_e_r_y _k_n_o_w_n _h_o_s_t (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 _h_o_s_t_s._e_q_u_i_v 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 _h_o_s_t_s._e_q_u_i_v with a correctly configured one, or
delete the file altogether.
2.2.1.2 The .rhosts File
The ._r_h_o_s_t_s file [Sun88a, 1397] is similar in concept and
format to the _h_o_s_t_s._e_q_u_i_v file, but allows trusted access only
to specific host-user combinations, rather than to hosts in
general.* Each user may create a ._r_h_o_s_t_s 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 _h_o_s_t_s._e_q_u_i_v. Unfor-
tunately, this file presents a major security problem: While
_h_o_s_t_s._e_q_u_i_v is under the system administrator's control and can
be managed effectively, any user may create a ._r_h_o_s_t_s file
granting access to whomever he chooses, without the system
administrator's knowledge.
_________________________
Actually, _h_o_s_t_s._e_q_u_i_v may be used to specify host-user
combinations as well, but this is rarely done.
14
The only secure way to manage ._r_h_o_s_t_s 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 ._r_h_o_s_t_s file may be necessary to allow
network backups and the like to be completed.
2.2.2 Secure Terminals
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 _s_u command to
become super-user, however.) The file /_e_t_c/_t_t_y_t_a_b [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 _i_n_i_t process to reread the _t_t_y_t_a_b file.
The Sun default configuration for _t_t_y_t_a_b 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 _s_u
_________________________
|- Under non-Sun versions of Berkeley UNIX, this file is called
/_e_t_c/_t_t_y_s.
15
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.
2.2.3 The Network File System
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.
2.2.3.1 The exports File
The file /_e_t_c/_e_x_p_o_r_t_s [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 _e_x_p_o_r_t_s 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 _r_o_o_t= 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
16
2.2.3.3. The _a_c_c_e_s_s= keyword specifies the list of hosts
(separated by colons) that are allowed to mount the named file
system. If no _a_c_c_e_s_s= 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 _e_x_p_o_r_t_s have an _a_c_c_e_s_s= 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 _a_c_c_e_s_s= keyword will also allow netgroups
to be specified. Netgroups are described in the next section.
After making any changes to the _e_x_p_o_r_t_s file, you should
run the command
# exportfs -a
in order to make the changes take effect.
2.2.3.2 The netgroup File
The file /_e_t_c/_n_e_t_g_r_o_u_p [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 _n_e_t_g_r_o_u_p 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__G_r_o_u_p, _B__G_r_o_u_p,
_A_d_m_i_n_S_t_a_f_f, and _A_l_l_S_u_n_s. The _A_l_l_S_u_n_s netgroup is actually a
``super group'' containing all the members of the _A__G_r_o_u_p and
_B__G_r_o_u_p netgroups.
Each member of a netgroup is defined as a triple: (host,
user, domain). Typically, the _d_o_m_a_i_n field is never used, and
is simply left blank. If either the _h_o_s_t or _u_s_e_r field is left
17
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.
Netgroups are useful when restricting access to NFS file
systems via the _e_x_p_o_r_t_s file. For example, consider this modi-
fied version of the file from the previous section:
/usr -access=A_Group
/home -access=A_Group:B_Group
/var/spool/mail -access=AllSuns
#
/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 /_u_s_r file system may now only be mounted by the hosts in
the _A__G_r_o_u_p netgroup, that is, _s_e_r_v_e_r_a, _c_l_i_e_n_t_a_1, and _c_l_i_e_n_t_a_2.
Any other host that tries to mount this file system will
receive an ``access denied'' error. The /_h_o_m_e file system may
be mounted by any of the hosts in either the _A__G_r_o_u_p or _B__G_r_o_u_p
netgroups. The /_v_a_r/_s_p_o_o_l/_m_a_i_l file system is also restricted
to these hosts, but in this example we used the ``super group''
called _A_l_l_S_u_n_s.
Generally, the best way to configure the _n_e_t_g_r_o_u_p file is
to make a single netgroup for each file server and its clients,
and then to make other super groups, such as _A_l_l_S_u_n_s. This
allows you the flexibility to specify the smallest possible
group of hosts for each file system in /_e_t_c/_e_x_p_o_r_t_s.
Netgroups can also be used in the password file to allow
access to a given host to be restricted to the members of that
group, and they can be used in the _h_o_s_t_s._e_q_u_i_v file to central-
ize maintenance of the list of trusted hosts. The procedures
for doing this are defined in more detail in the Sun manual.
2.2.3.3 Restricting Super-User Access
Normally, NFS translates the super-user id to a special id
called ``nobody'' in order to prevent a user with ``root'' on a
remote workstation from accessing other people's files. This
is good for security, but sometimes a nuisance for system
administration, since you cannot make changes to files as
``root'' through NFS.
The _e_x_p_o_r_t_s file also allows you to grant super-user
18
access to certain file systems for certain hosts by using the
_r_o_o_t= keyword. Following this keyword a colon-separated list
of up to ten hosts may be specified; these hosts will be
allowed to access the file system as ``root'' without having
the user id converted to ``nobody.'' Netgroups may not be
specified to the _r_o_o_t= keyword.
Granting ``root'' access to a host should not be done
lightly. If a host has ``root'' access to a file system, then
the super-user on that host will have complete access to the
file system, just as if you had given him the ``root'' password
on the server. Untrusted hosts should never be given ``root''
access to NFS file systems.
2.2.4 FTP
The File Transfer Protocol, implemented by the _f_t_p and
_f_t_p_d programs [Sun88a, 195-201, 1632-1634], allows users to
connect to remote systems and transfer files back and forth.
Unfortunately, older versions of these programs also had
several bugs in them that allowed crackers to break into a sys-
tem. These bugs have been fixed by Berkeley, and new versions
are available. If your _f_t_p_d* was obtained before December
1988, you should get a newer version (see Section 4).
One of the more useful features of FTP is the
``anonymous'' login. This special login allows users who do
not have an account on your machine to have restricted access
in order to transfer files from a specific directory. This is
useful if you wish to distribute software to the public at
large without giving each person who wants the software an
account on your machine. In order to securely set up anonymous
FTP you should follow the specific instructions below:
1. Create an account called ``ftp.'' Disable the
account by placing an asterisk (*) in the password
field. Give the account a special home directory,
such as /_u_s_r/_f_t_p or /_u_s_r/_s_p_o_o_l/_f_t_p.
2. Make the home directory owned by ``ftp'' and unwrit-
able by anyone:
# chown ftp ~ftp
# chmod 555 ~ftp
_________________________
* On Sun systems, _f_t_p_d is stored in the file /_u_s_r/_e_t_c/_i_n._f_t_p_d.
On most other systems, it is called /_e_t_c/_f_t_p_d.
19
3. Make the directory ~_f_t_p/_b_i_n, owned by the super-user
and unwritable by anyone. Place a copy of the _l_s
program in this directory:
# mkdir ~ftp/bin
# chown root ~ftp/bin
# chmod 555 ~ftp/bin
# cp -p /bin/ls ~ftp/bin
# chmod 111 ~ftp/bin/ls
4. Make the directory ~_f_t_p/_e_t_c, owned by the super-user
and unwritable by anyone. Place copies of the pass-
word and group files in this directory, with all the
password fields changed to asterisks (*). You may
wish to delete all but a few of the accounts and
groups from these files; the only account that must
be present is ``ftp.''
# mkdir ~ftp/etc
# chown root ~ftp/etc
# chmod 555 ~ftp/etc
# cp -p /etc/passwd /etc/group ~ftp/etc
# chmod 444 ~ftp/etc/passwd ~ftp/etc/group
5. Make the directory ~_f_t_p/_p_u_b, owned by ``ftp'' and
world-writable. Users may then place files that are
to be accessible via anonymous FTP in this directory:
# mkdir ~ftp/pub
# chown ftp ~ftp/pub
# chmod 777 ~ftp/pub
Because the anonymous FTP feature allows anyone to access
your system (albeit in a very limited way), it should not be
made available on every host on the network. Instead, you
should choose one machine (preferably a server or standalone
host) on which to allow this service. This makes monitoring
for security violations much easier. If you allow people to
transfer files to your machine (using the world-writable _p_u_b
directory, described above), you should check often the con-
tents of the directories into which they are allowed to write.
Any suspicious files you find should be deleted.
2.2.4.1 Trivial FTP
The Trivial File Transfer Protocol, TFTP, is used on Sun
20
workstations (and others) to allow diskless hosts to boot from
the network. Basically, TFTP is a stripped-down version of FTP
- there is no user authentication, and the connection is based
on the User Datagram Protocol instead of the Transmission Con-
trol Protocol. Because they are so stripped-down, many imple-
mentations of TFTP have security holes. You should check your
hosts by executing the command sequence shown below.
% tftp
tftp> connect _y_o_u_r_h_o_s_t
tftp> get /etc/motd tmp
_E_r_r_o_r _c_o_d_e _1: _F_i_l_e _n_o_t _f_o_u_n_d
_t_f_t_p> _q_u_i_t
%
If your version does not respond with ``_F_i_l_e _n_o_t _f_o_u_n_d,'' and
instead transfers the file, you should replace your version of
_t_f_t_p_d* with a newer one. In particular, versions of SunOS
prior to release 4.0 are known to have this problem.
2.2.5 Mail
Electronic mail is one of the main reasons for connecting
to outside networks. On most versions of Berkeley-derived UNIX
systems, including those from Sun, the _s_e_n_d_m_a_i_l program
[Sun88a, 1758-1760; Sun88b, 441-488] is used to enable the
receipt and delivery of mail. As with the FTP software, older
versions of _s_e_n_d_m_a_i_l have several bugs that allow security vio-
lations. One of these bugs was used with great success by the
Internet worm [Seel88, Spaf88]. The current version of _s_e_n_d_-
_m_a_i_l from Berkeley is version 5.61, of January 1989. Sun is,
as of this writing, still shipping version 5.59, which has a
known security problem. They have, however, made a fixed ver-
sion available. Section 4 details how to obtain these newer
versions.
Generally, with the exception of the security holes men-
tioned above, _s_e_n_d_m_a_i_l is reasonably secure when installed by
most vendors' installation procedures. There are, however, a
few precautions that should be taken to ensure secure opera-
tion:
1. Remove the ``decode'' alias from the aliases file
(/_e_t_c/_a_l_i_a_s_e_s or /_u_s_r/_l_i_b/_a_l_i_a_s_e_s).
_________________________
* On Sun systems, _t_f_t_p_d is stored in the file
/_u_s_r/_e_t_c/_i_n._t_f_t_p_d. On most other systems, it is called
/_e_t_c/_t_f_t_p_d.
21
2. If you create aliases that allow messages to be sent
to programs, be absolutely sure that there is no way
to obtain a shell or send commands to a shell from
these programs.
3. Make sure the ``wizard'' password is disabled in the
configuration file, _s_e_n_d_m_a_i_l._c_f. (Unless you modify
the distributed configuration files, this shouldn't
be a problem.)
4. Make sure your _s_e_n_d_m_a_i_l does not support the
``debug'' command. This can be done with the follow-
ing commands:
% telnet localhost 25
220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST
debug
500 Command unrecognized
quit
%
If your _s_e_n_d_m_a_i_l responds to the ``debug'' command
with ``_2_0_0 _D_e_b_u_g _s_e_t,'' then you are vulnerable to
attack and should replace your _s_e_n_d_m_a_i_l with a newer
version.
By following the procedures above, you can be sure that your
mail system is secure.
2.2.6 Finger
The ``finger'' service, provided by the _f_i_n_g_e_r program
[Sun88a, 186-187], allows you to obtain information about a
user such as her full name, home directory, last login time,
and in some cases when she last received mail and/or read her
mail. The _f_i_n_g_e_r_d program [Sun88a, 1625] allows users on
remote hosts to obtain this information.
A bug in _f_i_n_g_e_r_d was also exercised with success by the
Internet worm [Seel88, Spaf88]. If your version of _f_i_n_g_e_r_d* is
older than November 5, 1988, it should be replaced with a newer
version. New versions are available from several of the
sources described in Section 4.
_________________________
* On Sun systems, _f_i_n_g_e_r_d is stored in /_u_s_r/_e_t_c/_i_n._f_i_n_g_e_r_d. On
most other systems, it is called /_e_t_c/_f_i_n_g_e_r_d.
22
2.2.7 Modems and Terminal Servers
Modems and terminal servers (terminal switches, Annex
boxes, etc.) present still another potential security problem.
The main problem with these devices is one of configuration -
misconfigured hardware can allow security breaches. Explaining
how to configure every brand of modem and terminal server would
require volumes. However, the following items should be
checked for on any modems or terminal servers installed at your
site:
1. If a user dialed up to a modem hangs up the phone,
the system should log him out. If it doesn't, check
the hardware connections and the kernel configuration
of the serial ports.
2. If a user logs off, the system should force the modem
to hang up. Again, check the hardware connections if
this doesn't work.
3. If the connection from a terminal server to the sys-
tem is broken, the system should log the user off.
4. If the terminal server is connected to modems, and
the user hangs up, the terminal server should inform
the system that the user has hung up.
Most modem and terminal server manuals cover in detail how
to properly connect these devices to your system. In particu-
lar you should pay close attention to the ``Carrier Detect,''
``Clear to Send,'' and ``Request to Send'' connections.
2.2.8 Firewalls
One of the newer ideas in network security is that of a
_f_i_r_e_w_a_l_l. Basically, a firewall is a special host that sits
between your outside-world network connection(s) and your
internal network(s). This host does not send out routing
information about your internal network, and thus the internal
network is ``invisible'' from the outside. In order to config-
ure a firewall machine, the following considerations need to be
taken:
1. The firewall does not advertise routes. This means
that users on the internal network must log in to the
firewall in order to access hosts on remote networks.
Likewise, in order to log in to a host on the
23
internal network from the outside, a user must first
log in to the firewall machine. This is incon-
venient, but more secure.
2. All electronic mail sent by your users must be for-
warded to the firewall machine if it is to be
delivered outside your internal network. The
firewall must receive all incoming electronic mail,
and then redistribute it. This can be done either
with aliases for each user or by using name server MX
records.
3. The firewall machine should not mount any file sys-
tems via NFS, or make any of its file systems avail-
able to be mounted.
4. Password security on the firewall must be rigidly
enforced.
5. The firewall host should not trust any other hosts
regardless of where they are. Furthermore, the
firewall should not be trusted by any other host.
6. Anonymous FTP and other similar services should only
be provided by the firewall host, if they are pro-
vided at all.
The purpose of the firewall is to prevent crackers from
accessing other hosts on your network. This means, in general,
that you must maintain strict and rigidly enforced security on
the firewall, but the other hosts are less vulnerable, and
hence security may be somewhat lax. But it is important to
remember that the firewall is not a complete cure against
crackers - if a cracker can break into the firewall machine, he
can then try to break into any other host on your network.
2.3 FILE SYSTEM SECURITY
The last defense against system crackers are the permis-
sions offered by the file system. Each file or directory has
three sets of permission bits associated with it: one set for
the user who owns the file, one set for the users in the group
with which the file is associated, and one set for all other
users (the ``world'' permissions). Each set contains three
identical permission bits, which control the following:
_r_e_a_d If set, the file or directory may be read. In
the case of a directory, read access allows a
user to see the contents of a directory (the
24
names of the files contained therein), but not to
access them.
_w_r_i_t_e If set, the file or directory may be written
(modified). In the case of a directory, write
permission implies the ability to create, delete,
and rename files. Note that the ability to
remove a file is _n_o_t controlled by the permis-
sions on the file, but rather the permissions on
the directory containing the file.
_e_x_e_c_u_t_e If set, the file or directory may be executed
(searched). In the case of a directory, execute
permission implies the ability to access files
contained in that directory.
In addition, a fourth permission bit is available in each
set of permissions. This bit has a different meaning in each
set of permission bits:
_s_e_t_u_i_d If set in the owner permissions, this bit controls
the ``set user id'' (setuid) status of a file.
Setuid status means that when a program is exe-
cuted, it executes with the permissions of the
user owning the program, in addition to the per-
missions of the user executing the program. For
example, _s_e_n_d_m_a_i_l is setuid ``root,'' allowing it
to write files in the mail queue area, which nor-
mal users are not allowed to do. This bit is
meaningless on nonexecutable files.
_s_e_t_g_i_d If set in the group permissions, this bit controls
the ``set group id'' (setgid) status of a file.
This behaves in exactly the same way as the setuid
bit, except that the group id is affected instead.
This bit is meaningless on non-executable files
(but see below).
_s_t_i_c_k_y If set in the world permissions, the ``sticky''
bit tells the operating system to do special
things with the text image of an executable file.
It is mostly a holdover from older versions of
UNIX, and has little if any use today. This bit
is also meaningless on nonexecutable files (but
see below).
2.3.1 Setuid Shell Scripts
Shell scripts that have the setuid or setgid bits set on
25
them are _n_o_t secure, regardless of how many safeguards are taken
when writing them. There are numerous software packages avail-
able that claim to make shell scripts secure, but every one
released so far has not managed to solve all the problems.
Setuid and setgid shell scripts should never be allowed on
any UNIX system.
2.3.2 The Sticky Bit on Directories
Newer versions of UNIX have attached a new meaning to the
sticky bit. When this bit is set on a directory, it means that
users may not delete or rename other users' files in this direc-
tory. This is typically useful for the /_t_m_p directory. Nor-
mally, /_t_m_p is world-writable, enabling any user to delete
another user's files. By setting the sticky bit on /_t_m_p, users
may only delete their own files from this directory.
To set the sticky bit on a directory, use the command
# chmod o+t _d_i_r_e_c_t_o_r_y
2.3.3 The Setgid Bit on Directories
In SunOS 4.0, the setgid bit was also given a new meaning.
Two rules can be used for assigning group ownership to a file in
SunOS:
1. The System V mechanism, which says that a user's pri-
mary group id (the one listed in the password file) is
assigned to any file he creates.
2. The Berkeley mechanism, which says that the group id of
a file is set to the group id of the directory in which
it is created.
If the setgid bit is set on a directory, the Berkeley
mechanism is enabled. Otherwise, the System V mechanism is
enabled. Normally, the Berkeley mechanism is used; this mechan-
ism must be used if creating directories for use by more than one
member of a group (see Section 2.1.5).
To set the setgid bit on a directory, use the command
26
# chmod g+s _d_i_r_e_c_t_o_r_y
2.3.4 The umask Value
When a file is created by a program, say a text editor or a
compiler, it is typically created with all permissions enabled.
Since this is rarely desirable (you don't want other users to be
able to write your files), the _u_m_a_s_k value is used to modify the
set of permissions a file is created with. Simply put, while the
_c_h_m_o_d command [Sun88a, 65-66] specifies what bits should be
turned _o_n, the umask value specifies what bits should be turned
_o_f_f.
For example, the default umask on most systems is 022. This
means that write permission for the group and world should be
turned off whenever a file is created. If instead you wanted to
turn off all group and world permission bits, such that any file
you created would not be readable, writable, or executable by
anyone except yourself, you would set your umask to 077.
The umask value is specified in the ._c_s_h_r_c or ._p_r_o_f_i_l_e files
read by the shell using the _u_m_a_s_k command [Sun88a, 108, 459].
The ``root'' account should have the line
umask 022
in its /._c_s_h_r_c file, in order to prevent the accidental creation
of world-writable files owned by the super-user.
2.3.5 Encrypting Files
The standard UNIX _c_r_y_p_t command [Sun88a, 95] is not at all
secure. Although it is reasonable to expect that _c_r_y_p_t will keep
the casual ``browser'' from reading a file, it will present noth-
ing more than a minor inconvenience to a determined cracker.
_C_r_y_p_t implements a one-rotor machine along the lines of the Ger-
man Enigma (broken in World War II). The methods of attack on
such a machine are well known, and a sufficiently large file can
usually be decrypted in a few hours even without knowledge of
what the file contains [Reed84]. In fact, publicly available
packages of programs designed to ``break'' files encrypted with
_c_r_y_p_t have been around for several years.
There are software implementations of another algorithm, the
Data Encryption Standard (DES), available on some systems.
27
Although this algorithm is much more secure than _c_r_y_p_t, it has
never been proven that it is totally secure, and many doubts
about its security have been raised in recent years.
Perhaps the best thing to say about encrypting files on a
computer system is this: if you think you have a file whose con-
tents are important enough to encrypt, then that file should not
be stored on the computer in the first place. This is especially
true of systems with limited security, such as UNIX systems and
personal computers.
It is important to note that UNIX passwords are _n_o_t
encrypted with the _c_r_y_p_t program. Instead, they are encrypted
with a modified version of the DES that generates one-way encryp-
tions (that is, the password cannot be decrypted). When you log
in, the system does not decrypt your password. Instead, it
encrypts your attempted password, and if this comes out to the
same result as encrypting your real password, you are allowed to
log in.
2.3.6 Devices
The security of devices is an important issue in UNIX. Dev-
ice files (usually residing in /_d_e_v) are used by various programs
to access the data on the disk drives or in memory. If these
device files are not properly protected, your system is wide open
to a cracker. The entire list of devices is too long to go into
here, since it varies widely from system to system. However, the
following guidelines apply to all systems:
1. The files /_d_e_v/_k_m_e_m, /_d_e_v/_m_e_m, and /_d_e_v/_d_r_u_m should
never be readable by the world. If your system sup-
ports the notion of the ``kmem'' group (most newer sys-
tems do) and utilities such as _p_s are setgid ``kmem,''
then these files should be owned by user ``root'' and
group ``kmem,'' and should be mode 640. If your system
does not support the notion of the ``kmem'' group, and
utilities such as _p_s are setuid ``root,'' then these
files should be owned by user ``root'' and mode 600.
2. The disk devices, such as /_d_e_v/_s_d_0_a, /_d_e_v/_r_x_y_1_b, etc.,
should be owned by user ``root'' and group ``opera-
tor,'' and should be mode 640. Note that each disk has
eight partitions and two device files for each parti-
tion. Thus, the disk ``sd0'' would have the following
device files associated with it in /_d_e_v:
28
sd0a sd0e rsd0a rsd0e
sd0b sd0f rsd0b rsd0f
sd0c sd0g rsd0c rsd0g
sd0d sd0h rsd0d rsd0h
3. With very few exceptions, all other devices should be
owned by user ``root.'' One exception is terminals,
which are changed to be owned by the user currently
logged in on them. When the user logs out, the owner-
ship of the terminal is automatically changed back to
``root.''
2.4 SECURITY IS YOUR RESPONSIBILITY
This section has detailed numerous tools for improving secu-
rity provided by the UNIX operating system. The most important
thing to note about these tools is that although they are avail-
able, they are typically not put to use in most installations.
Therefore, it is incumbent on you, the system administrator, to
take the time and make the effort to enable these tools, and thus
to protect your system from unauthorized access.
29
30
SECTION 3
MONITORING SECURITY
One of the most important tasks in keeping any computer sys-
tem secure is monitoring the security of the system. This
involves examining system log files for unauthorized accesses of
the system, as well as monitoring the system itself for security
holes. This section describes the procedures for doing this. An
additional part of monitoring security involves keeping abreast
of security problems found by others; this is described in Sec-
tion 5.
3.1 ACCOUNT SECURITY
Account security should be monitored periodically in order
to check for two things: users logged in when they ``shouldn't''
be (e.g., late at night, when they're on vacation, etc.), and
users executing commands they wouldn't normally be expected to
use. The commands described in this section can be used to
obtain this information from the system.
3.1.1 The lastlog File
The file /_u_s_r/_a_d_m/_l_a_s_t_l_o_g [Sun88a, 1485] records the most
recent login time for each user of the system. The message
printed each time you log in, e.g.,
Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c
uses the time stored in the _l_a_s_t_l_o_g file. Additionally, the last
login time reported by the _f_i_n_g_e_r command uses this time. Users
should be told to carefully examine this time whenever they log
in, and to report unusual login times to the system administra-
tor. This is an easy way to detect account break-ins, since each
user should remember the last time she logged into the system.
3.1.2 The utmp and wtmp Files
The file /_e_t_c/_u_t_m_p [Sun88a, 1485] is used to record who is
31
currently logged into the system. This file can be displayed
using the _w_h_o command [Sun88a, 597]:
% who
hendra tty0c Mar 13 12:31
heidari tty14 Mar 13 13:54
welgem tty36 Mar 13 12:15
reagin ttyp0 Mar 13 08:54 (aaifs.itstd.sri.)
ghg ttyp1 Mar 9 07:03 (hydra.riacs.edu)
compion ttyp2 Mar 1 03:01 (ei.ecn.purdue.ed)
For each user, the login name, terminal being used, login time,
and remote host (if the user is logged in via the network) are
displayed.
The file /_u_s_r/_a_d_m/_w_t_m_p [Sun88a, 1485] records each login and
logout time for every user. This file can also be displayed
using the _w_h_o command:
% who /usr/adm/wtmp
davy ttyp4 Jan 7 12:42 (annex01.riacs.ed)
ttyp4 Jan 7 15:33
davy ttyp4 Jan 7 15:33 (annex01.riacs.ed)
ttyp4 Jan 7 15:35
hyder ttyp3 Jan 8 09:07 (triceratops.itst)
ttyp3 Jan 8 11:43
A line that contains a login name indicates the time the user
logged in; a line with no login name indicates the time that the
terminal was logged off. Unfortunately, the output from this
command is rarely as simple as in the example above; if several
users log in at once, the login and logout times are all mixed
together and must be matched up by hand using the terminal name.
The _w_t_m_p file may also be examined using the _l_a_s_t command
[Sun88a, 248]. This command sorts out the entries in the file,
matching up login and logout times. With no arguments, _l_a_s_t
displays all information in the file. By giving the name of a
user or terminal, the output can be restricted to the information
about the user or terminal in question. Sample output from the
_l_a_s_t command is shown below.
% last
davy ttyp3 intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00)
hyder ttyp3 clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04)
reboot ~ Mon Mar 12 15:16
shutdown ~ Mon Mar 12 15:16
arms ttyp3 clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04)
hyder ttyp3 spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04)
reboot ~ Sat Mar 10 20:05
davy ftp hydra.riacs.edu Sat Mar 10 13:23 - 13:30 (00:07)
32
For each login session, the user name, terminal used, remote host
(if the user logged in via the network), login and logout times,
and session duration are shown. Additionally, the times of all
system shutdowns and reboots (generated by the _s_h_u_t_d_o_w_n and
_r_e_b_o_o_t commands [Sun88a, 1727, 1765]) are recorded. Unfor-
tunately, system crashes are not recorded. In newer versions of
the operating system, pseudo logins such as those via the _f_t_p
command are also recorded; an example of this is shown in the
last line of the sample output, above.
3.1.3 The acct File
The file /_u_s_r/_a_d_m/_a_c_c_t [Sun88a, 1344-1345] records each exe-
cution of a command on the system, who executed it, when, and how
long it took. This information is logged each time a command
completes, but only if your kernel was compiled with the SYSACCT
option enabled (the option is enabled in some GENERIC kernels,
but is usually disabled by default).
The _a_c_c_t file can be displayed using the _l_a_s_t_c_o_m_m command
[Sun88a, 249]. With no arguments, all the information in the
file is displayed. However, by giving a command name, user name,
or terminal name as an argument, the output can be restricted to
information about the given command, user, or terminal. Sample
output from _l_a_s_t_c_o_m_m is shown below.
% lastcomm
sh S root __ 0.67 secs Tue Mar 13 12:45
atrun root __ 0.23 secs Tue Mar 13 12:45
lpd F root __ 1.06 secs Tue Mar 13 12:44
lpr S burwell tty09 1.23 secs Tue Mar 13 12:44
troff burwell tty09 12.83 secs Tue Mar 13 12:44
eqn burwell tty09 1.44 secs Tue Mar 13 12:44
df kindred ttyq7 0.78 secs Tue Mar 13 12:44
ls kindred ttyq7 0.28 secs Tue Mar 13 12:44
cat kindred ttyq7 0.05 secs Tue Mar 13 12:44
stty kindred ttyq7 0.05 secs Tue Mar 13 12:44
tbl burwell tty09 1.08 secs Tue Mar 13 12:44
rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38
rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41
stty kindred ttyq7 0.05 secs Tue Mar 13 12:44
The first column indicates the name of the command. The next
column displays certain flags on the command: an ``F'' means the
process spawned a child process, ``S'' means the process ran with
the set-user-id bit set, ``D'' means the process exited with a
core dump, and ``X'' means the process was killed abnormally.
The remaining columns show the name of the user who ran the
program, the terminal he ran it from (if applicable), the amount
33
of CPU time used by the command (in seconds), and the date and
time the process started.
3.2 NETWORK SECURITY
Monitoring network security is more difficult, because there
are so many ways for a cracker to attempt to break in. However,
there are some programs available to aid you in this task. These
are described in this section.
3.2.1 The syslog Facility
The _s_y_s_l_o_g facility [Sun88a, 1773] is a mechanism that
enables any command to log error messages and informational mes-
sages to the system console, as well as to a log file. Typi-
cally, error messages are logged in the file /_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s
along with the date, time, name of the program sending the mes-
sage, and (usually) the process id of the program. A sample seg-
ment of the _m_e_s_s_a_g_e_s file is shown below.
Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri
Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries
Mar 13 06:01:18 sparkyfs vmunix: /: file system full
Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3
Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding
Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM
intrepid.itstd.s, daemon
Of particular interest in this sample are the messages from the
_l_o_g_i_n and _s_u programs. Whenever someone logs in as ``root,''
_l_o_g_i_n logs this information. Generally, logging in as ``root''
directly, rather than using the _s_u command, should be
discouraged, as it is hard to track which person is actually
using the account. Once this ability has been disabled, as
described in Section 2.2.2, detecting a security violation
becomes a simple matter of searching the _m_e_s_s_a_g_e_s file for lines
of this type.
_L_o_g_i_n also logs any case of someone repeatedly trying to log
in to an account and failing. After three attempts, _l_o_g_i_n will
refuse to let the person try anymore. Searching for these
messages in the _m_e_s_s_a_g_e_s file can alert you to a cracker
34
attempting to guess someone's password.
Finally, when someone uses the _s_u command, either to become
``root'' or someone else, _s_u logs the success or failure of this
operation. These messages can be used to check for users sharing
their passwords, as well as for a cracker who has penetrated one
account and is trying to penetrate others.
3.2.2 The showmount Command
The _s_h_o_w_m_o_u_n_t command [Sun88a, 1764] can be used on an NFS
file server to display the names of all hosts that currently have
something mounted from the server. With no options, the program
simply displays a list of all the hosts. With the -_a and -_d
options, the output is somewhat more useful. The first option,
-_a, causes _s_h_o_w_m_o_u_n_t to list all the host and directory combina-
tions. For example,
bronto.itstd.sri.com:/usr/share
bronto.itstd.sri.com:/usr/local.new
bronto.itstd.sri.com:/usr/share/lib
bronto.itstd.sri.com:/var/spool/mail
cascades.itstd.sri.com:/sparky/a
clyde.itstd.sri.com:/laser_dumps
cm1.itstd.sri.com:/sparky/a
coco0.itstd.sri.com:/sparky/a
There will be one line of output for each directory mounted by a
host. With the -_d option, _s_h_o_w_m_o_u_n_t displays a list of all
directories that are presently mounted by some host.
The output from _s_h_o_w_m_o_u_n_t should be checked for two things.
First, only machines local to your organization should appear
there. If you have set up proper netgroups as described in Sec-
tion 2.2.3, this should not be a problem. Second, only ``nor-
mal'' directories should be mounted. If you find unusual direc-
tories being mounted, you should find out who is mounting them
and why - although it is probably innocent, it may indicate some-
one trying to get around your security mechanisms.
3.3 FILE SYSTEM SECURITY
Checking for security holes in the file system is another
important part of making your system secure. Primarily, you need
to check for files that can be modified by unauthorized users,
files that can inadvertently grant users too many permissions,
35
and files that can inadvertently grant access to crackers. It is
also important to be able to detect unauthorized modifications to
the file system, and to recover from these modifications when
they are made.
3.3.1 The find Command
The _f_i_n_d command [Sun88a, 183-185] is a general-purpose com-
mand for searching the file system. Using various arguments,
complex matching patterns based on a file's name, type, mode,
owner, modification time, and other characteristics, can be con-
structed. The names of files that are found using these patterns
can then be printed out, or given as arguments to other UNIX com-
mands. The general format of a _f_i_n_d command is
% find _d_i_r_e_c_t_o_r_i_e_s _o_p_t_i_o_n_s
where _d_i_r_e_c_t_o_r_i_e_s is a list of directory names to search (e.g.,
/_u_s_r), and _o_p_t_i_o_n_s contains the options to control what is being
searched for. In general, for the examples in this section, you
will always want to search from the root of the file system (/),
in order to find all files matching the patterns presented.
This section describes how to use _f_i_n_d to search for four
possible security problems that were described in Section 2.
3.3.1.1 Finding Setuid and Setgid Files
It is important to check the system often for unauthorized
setuid and setgid programs. Because these programs grant special
privileges to the user who is executing them, it is necessary to
ensure that insecure programs are not installed. Setuid ``root''
programs should be closely guarded - a favorite trick of many
crackers is to break into ``root'' once, and leave a setuid pro-
gram hidden somewhere that will enable them to regain super-user
powers even if the original hole is plugged.
The command to search for setuid and setgid files is
# find / -type f -a \( -perm -4000 -o -perm -2000 \) -print
The options to this command have the following meanings:
/ The name of the directory to be searched. In this
case, we want to search the entire file system, so we
specify /. You might instead restrict the search to
36
/_u_s_r or /_h_o_m_e.
-type f
Only examine files whose type is ``f,'' regular file.
Other options include ``d'' for directory, ``l'' for
symbolic link, ``c'' for character-special devices, and
``b'' for block-special devices.
-a This specifies ``and.'' Thus, we want to know about
files whose type is ``regular file,'' _a_n_d whose permis-
sions bits match the other part of this expression.
\( -perm -4000 -o -perm -2000 \)
The parentheses in this part of the command are used
for grouping. Thus, everything in this part of the
command matches a single pattern, and is treated as the
other half of the ``and'' clause described above.
-perm -4000
This specifies a match if the ``4000'' bit (speci-
fied as an octal number) is set in the file's per-
mission modes. This is the set-user-id bit.
-o This specifies ``or.'' Thus, we want to match if
the file has the set-user-id bit _o_r the set-
group-id bit set.
-perm -2000
This specifies a match if the ``2000'' bit (speci-
fied as an octal number) is set in the file's per-
mission modes. This is the set-group-id bit.
-printThis indicates that for any file that matches the
specified expression (is a regular file _a_n_d has the
setuid _o_r setgid bits set in its permissions), print
its name on the screen.
After executing this command (depending on how much disk
space you have, it can take anywhere from 15 minutes to a couple
of hours to complete), you will have a list of files that have
setuid or setgid bits set on them. You should then examine each
of these programs, and determine whether they should actually
have these permissions. You should be especially suspicious of
programs that are _n_o_t in one of the directories (or a subdirec-
tory) shown below.
/bin
/etc
/usr/bin
/usr/ucb
/usr/etc
37
One file distributed with SunOS, /_u_s_r/_e_t_c/_r_e_s_t_o_r_e, is dis-
tributed with the setuid bit set on it, and should not be,
because of a security hole. You should be sure to remove the
setuid bit from this program by executing the command
# chmod u-s /usr/etc/restore
3.3.1.2 Finding World-Writable Files
World-writable files, particularly system files, can be a
security hole if a cracker gains access to your system and modi-
fies them. Additionally, world-writable directories are
dangerous, since they allow a cracker to add or delete files as
he wishes. The _f_i_n_d command to find all world-writable files is
# find / -perm -2 -print
In this case, we do not use the -_t_y_p_e option to restrict the
search, since we are interested in directories and devices as
well as files. The -_2 specifies the world write bit (in octal).
This list of files will be fairly long, and will include
some files that _s_h_o_u_l_d be world writable. You should not be con-
cerned if terminal devices in /_d_e_v are world writable. You
should also not be concerned about line printer error log files
being world writable. Finally, symbolic links may be world writ-
able - the permissions on a symbolic link, although they exist,
have no meaning.
3.3.1.3 Finding Unowned Files
Finding files that are owned by nonexistent users can often
be a clue that a cracker has gained access to your system. Even
if this is not the case, searching for these files gives you an
opportunity to clean up files that should have been deleted at
the same time the user herself was deleted. The command to find
unowned files is
# find / -nouser -print
The -_n_o_u_s_e_r option matches files that are owned by a user id not
contained in the /_e_t_c/_p_a_s_s_w_d database. A similar option,
-_n_o_g_r_o_u_p, matches files owned by nonexistent groups. To find all
files owned by nonexistent users _o_r groups, you would use the -_o
option as follows:
38
# find / -nouser -o -nogroup -print
3.3.1.4 Finding .rhosts Files
As mentioned in Section 2.2.1.2, users should be prohibited
from having ._r_h_o_s_t_s files in their accounts. To search for this,
it is only necessary to search the parts of the file system that
contain home directories (i.e., you can skip / and /_u_s_r):
# find /home -name .rhosts -print
The -_n_a_m_e option indicates that the complete name of any file
whose name matches ._r_h_o_s_t_s should be printed on the screen.
3.3.2 Checklists
Checklists can be a useful tool for discovering unauthorized
changes made to system directories. They aren't practical on
file systems that contain users' home directories since these
change all the time. A checklist is a listing of all the files
contained in a group of directories: their sizes, owners, modif-
ication dates, and so on. Periodically, this information is col-
lected and compared with the information in the master checklist.
Files that do not match in all attributes can be suspected of
having been changed.
There are several utilities that implement checklists avail-
able from public software sites (see Section 4). However, a sim-
ple utility can be constructed using only the standard UNIX _l_s
and _d_i_f_f commands.
First, use the _l_s command [Sun88a, 285] to generate a master
list. This is best done immediately after installing the operat-
ing system, but can be done at any time provided you're confident
about the correctness of the files on the disk. A sample command
is shown below.
# ls -aslgR /bin /etc /usr > MasterChecklist
The file _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t now contains a complete list of all the
files in these directories. You will probably want to edit it
and delete the lines for files you know will be changing often
(e.g., /_e_t_c/_u_t_m_p, /_u_s_r/_a_d_m/_a_c_c_t). The _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t file
should be stored somewhere safe where a cracker is unlikely to
39
find it (since he could otherwise just change the data in it):
either on a different computer system, or on magnetic tape.
To search for changes in the file system, run the above _l_s
command again, saving the output in some other file, say
_C_u_r_r_e_n_t_L_i_s_t. Now use the _d_i_f_f command [Sun88a, 150] to compare
the two files:
# diff MasterChecklist CurrentList
Lines that are only in the master checklist will be printed pre-
ceded by a ``<,'' and lines that are only in the current list
will be preceded by a ``>.'' If there is one line for a file,
preceded by a ``<,'' this means that the file has been deleted
since the master checklist was created. If there is one line for
a file, preceded by a ``>,'' this means that the file has been
created since the master checklist was created. If there are two
lines for a single file, one preceded by ``<'' and the other by
``>,'' this indicates that some attribute of the file has changed
since the master checklist was created.
By carefully constructing the master checklist, and by
remembering to update it periodically (you can replace it with a
copy of _C_u_r_r_e_n_t_L_i_s_t, once you're sure the differences between the
lists are harmless), you can easily monitor your system for unau-
thorized changes. The software packages available from the pub-
lic software distribution sites implement basically the same
scheme as the one here, but offer many more options for control-
ling what is examined and reported.
3.3.3 Backups
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the even
of hardware failure or accidental deletions, but they also pro-
tect you against unauthorized file system changes made by a
cracker.
A good backup strategy will dump the entire system at level
zero (a ``full'' dump) at least once a month. Partial (or
``incremental'') dumps should be done at least twice a week, and
ideally they should be done daily. The _d_u_m_p command [Sun88a,
1612-1614] is recommended over other programs such as _t_a_r and
_c_p_i_o. This is because only _d_u_m_p is capable of creating a backup
that can be used to restore a disk to the exact state it was in
when it was dumped. The other programs do not take into account
files deleted or renamed between dumps, and do not handle some
specialized database files properly.
40
3.4 KNOW YOUR SYSTEM
Aside from running large monitoring programs such as those
described in the previous sections, simple everyday UNIX commands
can also be useful for spotting security violations. By running
these commands often, whenever you have a free minute (for exam-
ple, while waiting for someone to answer the phone), you will
become used to seeing a specific pattern of output. By being
familiar with the processes normally running on your system, the
times different users typically log in, and so on, you can easily
detect when something is out of the ordinary.
3.4.1 The ps Command
The _p_s command [Sun88a, 399-402] displays a list of the
processes running on your system. _P_s has numerous options, too
many to list here. Generally, however, for the purpose of moni-
toring, the option string -_a_l_x_w_w is the most useful.* On a Sun
system running SunOS 4.0, you should expect to see at least the
following:
_s_w_a_p_p_e_r, _p_a_g_e_d_a_e_m_o_n
System programs that help the virtual memory system.
/_s_b_i_n/_i_n_i_t
The _i_n_i_t process, which is responsible for numerous
tasks, including bringing up login processes on termi-
nals.
_p_o_r_t_m_a_p, _y_p_b_i_n_d, _y_p_s_e_r_v
Parts of the Yellow Pages system.
_b_i_o_d, _n_f_s_d, _r_p_c._m_o_u_n_t_d, _r_p_c._q_u_o_t_a_d, _r_p_c._l_o_c_k_d
Parts of the Network File System (NFS). If the system
you are looking at is not a file server, the _n_f_s_d
processes probably won't exist.
_r_a_r_p_d, _r_p_c._b_o_o_t_p_a_r_a_m_d
Part of the system that allows diskless clients to
boot.
Other commands you should expect to see are _u_p_d_a_t_e (file
system updater); _g_e_t_t_y (one per terminal and one for the
_________________________
* This is true for Berkeley-based systems. On System V
systems, the option string -_e_l_f should be used instead.
41
console); _l_p_d (line printer daemon); _i_n_e_t_d (Internet daemon, for
starting other network servers); _s_h and _c_s_h (the Bourne shell and
C shell, one or more per logged in user). In addition, if there
are users logged in, you'll probably see invocations of various
compilers, text editors, and word processing programs.
3.4.2 The who and w Commands
The _w_h_o command, as mentioned previously, displays the list
of users currently logged in on the system. By running this
periodically, you can learn at what times during the day various
users log in. Then, when you see someone logged in at a dif-
ferent time, you can investigate and make sure that it's legiti-
mate.
The _w command [Sun88a, 588] is somewhat of a cross between
_w_h_o and _p_s. Not only does it show a list of who is presently
logged in, but it also displays how long they have been idle
(gone without typing anything), and what command they are
currently running.
3.4.3 The ls Command
Simple as its function is, _l_s is actually very useful for
detecting file system problems. Periodically, you should use _l_s
on the various system directories, checking for files that
shouldn't be there. Most of the time, these files will have just
``landed'' somewhere by accident. However, by keeping a close
watch on things, you will be able to detect a cracker long before
you might have otherwise.
When using _l_s to check for oddities, be sure to use the -_a
option, which lists files whose names begin with a period (.).
Be particularly alert for files or directories named ``...'', or
``..(space)'', which many crackers like to use. (Of course,
remember that ``.'' and ``..'' are supposed to be there.)
3.5 KEEP YOUR EYES OPEN
Monitoring for security breaches is every bit as important
as preventing them in the first place. Because it's virtually
impossible to make a system totally secure, there is always the
chance, no matter how small, that a cracker will be able to gain
42
access. Only by monitoring can this be detected and remedied.
43
44
SECTION 4
SOFTWARE FOR IMPROVING SECURITY
Because security is of great concern to many sites, a wealth
of software has been developed for improving the security of UNIX
systems. Much of this software has been developed at universi-
ties and other public institutions, and is available free for the
asking. This section describes how this software can be
obtained, and mentions some of the more important programs avail-
able.
4.1 OBTAINING FIXES AND NEW VERSIONS
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes
some of the larger repositories.
4.1.1 Sun Fixes on UUNET
Sun Microsystems has contracted with UUNET Communications
Services, Inc. to make fixes for bugs in Sun software available
via anonymous FTP. You can access these fixes by using the _f_t_p
command [Sun88a, 195-201] to connect to the host _f_t_p._u_u._n_e_t.
Then change into the directory _s_u_n-_f_i_x_e_s, and obtain a directory
listing, as shown in the example on the following page.
45
% ftp ftp.uu.net
Connected to uunet.UU.NET.
220 uunet FTP server (Version 5.93 Mar 20 11:01:52 EST 1990) ready
Name (ftp.uu.net:davy): anonymous
331 Guest login ok, send ident as password.
Password: _e_n_t_e_r _y_o_u_r _m_a_i_l _a_d_d_r_e_s_s _y_o_u_r_n_a_m_e@_y_o_u_r_h_o_s_t _h_e_r_e
230 Guest login ok, access restrictions apply.
ftp> cd sun-fixes
_2_5_0 _C_W_D _c_o_m_m_a_n_d _s_u_c_c_e_s_s_f_u_l.
_f_t_p> _d_i_r
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 2258
-rw-r--r-- 1 38 22 4558 Aug 31 1989 README
-rw-r--r-- 1 38 22 484687 Dec 14 1988 ddn.tar.Z
-rw-r--r-- 1 38 22 140124 Jan 13 1989 gated.sun3.Z
-rwxr-xr-x 1 38 22 22646 Dec 14 1988 in.ftpd.sun3.Z
.....
.....
-rw-r--r-- 1 38 22 72119 Aug 31 1989 sendmail.sun3.Z
-rwxr-xr-x 1 38 22 99147 Aug 31 1989 sendmail.sun4.Z
-rw-r--r-- 1 38 22 3673 Jul 11 1989 wall.sun3.Z
-rw-r--r-- 1 38 22 4099 Jul 11 1989 wall.sun4.Z
-rwxr-xr-x 1 38 22 7955 Jan 18 1989 ypbind.sun3.Z
-rwxr-xr-x 1 38 22 9237 Jan 18 1989 ypbind.sun4.Z
226 Transfer complete.
1694 bytes received in 0.39 seconds (4.2 Kbytes/s)
ftp> quit
_2_2_1 _G_o_o_d_b_y_e.
%
The file _R_E_A_D_M_E contains a brief description of what each file in
this directory contains, and what is required to install the fix.
4.1.2 Berkeley Fixes
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily to the
current release of BSD UNIX (currently release 4.3). However,
even if you are not running their software, these fixes are still
important, since many vendors (Sun, DEC, Sequent , etc.) base
their software on the Berkeley releases.
The Berkeley fixes are available for anonymous FTP from the
host _u_c_b_a_r_p_a._b_e_r_k_e_l_e_y._e_d_u in the directory _4._3/_u_c_b-_f_i_x_e_s. The
file _I_N_D_E_X in this directory describes what each file contains.
Berkeley also distributes new versions of _s_e_n_d_m_a_i_l and _n_a_m_e_d
[Sun88a, 1758-1760, 1691-1692] from this machine. New versions
46
of these commands are stored in the _4._3 directory, usually in the
files _s_e_n_d_m_a_i_l._t_a_r._Z and _b_i_n_d._t_a_r._Z, respectively.
4.1.3 Simtel-20 and UUNET
The two largest general-purpose software repositories on the
Internet are the hosts _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l and _f_t_p._u_u._n_e_t.
_w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l is a TOPS-20 machine operated by the
U. S. Army at White Sands Missile Range, New Mexico. The direc-
tory _p_d_2:<_u_n_i_x-_c> contains a large amount of UNIX software, pri-
marily taken from the _c_o_m_p._s_o_u_r_c_e_s newsgroups. The file _0_0_0-
_m_a_s_t_e_r-_i_n_d_e_x._t_x_t contains a master list and description of each
piece of software available in the repository. The file _0_0_0-
_i_n_t_r_o-_u_n_i_x-_s_w._t_x_t contains information on the mailing list used
to announce new software, and describes the procedures used for
transferring files from the archive with FTP.
_f_t_p._u_u._n_e_t is operated by UUNET Communications Services,
Inc. in Falls Church, Virginia. This company sells Internet and
USENET access to sites all over the country (and internation-
ally). The software posted to the following USENET source news-
groups is stored here, in directories of the same name:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
Numerous other distributions, such as all the freely distribut-
able Berkeley UNIX source code, Internet Request for Comments
(RFCs), and so on are also stored on this machine.
4.1.4 Vendors
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous FTP.
You should contact your vendor to find out if they offer this
service, and if so, how to access it. Some vendors that offer
these services include Sun Microsystems (see above), Digital
Equipment Corp., the University of California at Berkeley (see
above), and Apple Computer.
47
4.2 THE NPASSWD COMMAND
The _n_p_a_s_s_w_d command, developed by Clyde Hoover at the
University of Texas at Austin, is intended to be a replacement
for the standard UNIX _p_a_s_s_w_d command [Sun88a, 379], as well as
the Sun _y_p_p_a_s_s_w_d command [Sun88a, 611]. _n_p_a_s_s_w_d makes passwords
more secure by refusing to allow users to select insecure pass-
words. The following capabilities are provided by _n_p_a_s_s_w_d:
+o Configurable minimum password length
+o Configurable to force users to use mixed case or digits
and punctuation
+o Checking for ``simple'' passwords such as a repeated
letter
+o Checking against the host name and other host-specific
information
+o Checking against the login name, first and last names,
and so on
+o Checking for words in various dictionaries, including
the system dictionary.
The _n_p_a_s_s_w_d distribution is available for anonymous FTP from
_e_m_x._u_t_e_x_a_s._e_d_u in the directory _p_u_b/_n_p_a_s_s_w_d.
4.3 THE COPS PACKAGE
COPS is a security tool for system administrators that
checks for numerous common security problems on UNIX systems,
including many of the things described in this document. COPS is
a collection of shell scripts and C programs that can easily be
run on almost any UNIX variant. Among other things, it checks
the following items and sends the results to the system adminis-
trator:
+o Checks /_d_e_v/_k_m_e_m and other devices for world
read/writability.
+o Checks special/important files and directories for
``bad'' modes (world writable, etc.).
+o Checks for easily guessed passwords.
48
+o Checks for duplicate user ids, invalid fields in the
password file, etc.
+o Checks for duplicate group ids, invalid fields in the
group file, etc.
+o Checks all users' home directories and their ._c_s_h_r_c,
._l_o_g_i_n, ._p_r_o_f_i_l_e, and ._r_h_o_s_t_s files for security prob-
lems.
+o Checks all commands in the /_e_t_c/_r_c files [Sun88a,
1724-1725] and _c_r_o_n files [Sun88a, 1606-1607] for world
writability.
+o Checks for bad ``root'' paths, NFS file system exported
to the world, etc.
+o Includes an expert system that checks to see if a given
user (usually ``root'') can be compromised, given that
certain rules are true.
+o Checks for _c_h_a_n_g_e_s in the setuid status of programs on
the system.
The COPS package is available from the _c_o_m_p._s_o_u_r_c_e_s._u_n_i_x
archive on _f_t_p._u_u._n_e_t, and also from the repository on _w_s_m_r-
_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l.
4.4 SUN C2 SECURITY FEATURES
With the release of SunOS 4.0, Sun has included security
features that allow the system to operate at a higher level of
security, patterned after the C2* classification. These features
can be installed as one of the options when installing the system
from the distribution tapes. The security features added by this
option include
+o Audit trails that record all login and logout times,
the execution of administrative commands, and the exe-
cution of privileged (setuid) operations.
+o A more secure password file mechanism (``shadow pass-
word file'') that prevents crackers from obtaining a
list of the encrypted passwords.
_________________________
* C2 is one of several security classifications defined by the
National Computer Security Center, and is described in [NCSC85],
the ``orange book.''
49
+o DES encryption capability.
+o A (more) secure NFS implementation that uses public-key
encryption to authenticate the users of the system and
the hosts on the network, to be sure they really are
who they claim to be.
These security features are described in detail in [Sun88c].
4.5 KERBEROS
Kerberos [Stei88] is an authentication system developed by
the Athena Project at the Massachusetts Institute of Technology.
Kerberos is a third-party authentication service, which is
trusted by other network services. When a user logs in, Kerberos
authenticates that user (using a password), and provides the user
with a way to prove her identity to other servers and hosts scat-
tered around the network.
This authentication is then used by programs such as _r_l_o_g_i_n
[Sun88a, 418-419] to allow the user to log in to other hosts
without a password (in place of the ._r_h_o_s_t_s file). The authenti-
cation is also used by the mail system in order to guarantee that
mail is delivered to the correct person, as well as to guarantee
that the sender is who he claims to be. NFS has also been modi-
fied by M.I.T. to work with Kerberos, thereby making the system
much more secure.
The overall effect of installing Kerberos and the numerous
other programs that go with it is to virtually eliminate the
ability of users to ``spoof'' the system into believing they are
someone else. Unfortunately, installing Kerberos is very
intrusive, requiring the modification or replacement of numerous
standard programs. For this reason, a source license is usually
necessary. There are plans to make Kerberos a part of 4.4BSD, to
be released by the University of California at Berkeley sometime
in 1990.
50
SECTION 5
KEEPING ABREAST OF THE BUGS
One of the hardest things about keeping a system secure is
finding out about the security holes before a cracker does. To
combat this, there are several sources of information you can and
should make use of on a regular basis.
5.1 THE COMPUTER EMERGENCY RESPONSE TEAM
The Computer Emergency Response Team (CERT) was established
in December 1988 by the Defense Advanced Research Projects Agency
to address computer security concerns of research users of the
Internet. It is operated by the Software Engineering Institute
at Carnegie-Mellon University. The CERT serves as a focal point
for the reporting of security violations, and the dissemination
of security advisories to the Internet community. In addition,
the team works with vendors of various systems in order to coor-
dinate the fixes for security problems.
The CERT sends out security advisories to the _c_e_r_t-_a_d_v_i_s_o_r_y
mailing list whenever appropriate. They also operate a 24-hour
hotline that can be called to report security problems (e.g.,
someone breaking into your system), as well as to obtain current
(and accurate) information about rumored security problems.
To join the _c_e_r_t-_a_d_v_i_s_o_r_y mailing list, send a message to
_c_e_r_t@_c_e_r_t._s_e_i._c_m_u._e_d_u and ask to be added to the mailing list.
Past advisories are available for anonymous FTP from the host
_c_e_r_t._s_e_i._c_m_u._e_d_u. The 24-hour hotline number is (412) 268-7090.
5.2 DDN MANAGEMENT BULLETINS
The _D_D_N _M_a_n_a_g_e_m_e_n_t _B_u_l_l_e_t_i_n is distributed electronically by
the Defense Data Network (DDN) Network Information Center under
contract to the Defense Communications Agency. It is a means of
communicating official policy, procedures, and other information
of concern to management personnel at DDN facilities.
The _D_D_N _S_e_c_u_r_i_t_y _B_u_l_l_e_t_i_n is distributed electronically by
the DDN SCC (Security Coordination Center), also under contract
to DCA, as a means of communicating information on network and
51
host security exposures, fixes, and concerns to security and
management personnel at DDN facilities.
Anyone may join the mailing lists for these two bulletins by
sending a message to _n_i_c@_n_i_c._d_d_n._m_i_l and asking to be placed on
the mailing lists.
5.3 SECURITY-RELATED MAILING LISTS
There are several other mailing lists operated on the Inter-
net that pertain directly or indirectly to various security
issues. Some of the more useful ones are described below.
5.3.1 Security
The UNIX Security mailing list exists to notify system
administrators of security problems _b_e_f_o_r_e they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be veri-
fied as being principal systems people at a site. Requests to
join the list must be sent by either the site contact listed in
the Network Information Center's WHOIS database, or from the
``root'' account on one of the major site machines. You must
include the destination address you want on the list, an indica-
tion of whether you want to be on the mail reflector list or
receive weekly digests, the electronic mail address and voice
telephone number of the site contact if it isn't you, and the
name, address, and telephone number of your organization. This
information should be sent to _s_e_c_u_r_i_t_y-_r_e_q_u_e_s_t@_c_p_d._c_o_m.
5.3.2 RISKS
The RISKS digest is a component of the ACM Committee on Com-
puters and Public Policy, moderated by Peter G. Neumann. It is a
discussion forum on risks to the public in computers and related
systems, and along with discussing computer security and privacy
issues, has discussed such subjects as the Stark incident, the
shooting down of the Iranian airliner in the Persian Gulf (as it
relates to the computerized weapons systems), problems in air and
railroad traffic control systems, software engineering, and so
on. To join the mailing list, send a message to _r_i_s_k_s-
_r_e_q_u_e_s_t@_c_s_l._s_r_i._c_o_m. This list is also available in the USENET
newsgroup _c_o_m_p._r_i_s_k_s.
52
5.3.3 TCP-IP
The TCP-IP list is intended to act as a discussion forum for
developers and maintainers of implementations of the TCP/IP pro-
tocol suite. It also discusses network-related security problems
when they involve programs providing network services, such as
_s_e_n_d_m_a_i_l. To join the TCP-IP list, send a message to _t_c_p-_i_p-
_r_e_q_u_e_s_t@_n_i_c._d_d_n._m_i_l. This list is also available in the USENET
newsgroup _c_o_m_p._p_r_o_t_o_c_o_l_s._t_c_p-_i_p.
5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS
The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all dis-
cussion groups for users and administrators of systems supplied
by Sun Microsystems. SUN-SPOTS is a fairly general list, dis-
cussing everything from hardware configurations to simple UNIX
questions. To subscribe, send a message to _s_u_n-_s_p_o_t_s-
_r_e_q_u_e_s_t@_r_i_c_e._e_d_u. This list is also available in the USENET
newsgroup _c_o_m_p._s_y_s._s_u_n.
SUN-NETS is a discussion list for items pertaining to net-
working on Sun systems. Much of the discussion is related to
NFS, Yellow Pages, and name servers. To subscribe, send a mes-
sage to _s_u_n-_n_e_t_s-_r_e_q_u_e_s_t@_u_m_i_a_c_s._u_m_d._e_d_u.
SUN-MANAGERS is a discussion list for Sun system administra-
tors and covers all aspects of Sun system administration. To
subscribe, send a message to _s_u_n-_m_a_n_a_g_e_r_s-_r_e_q_u_e_s_t@_e_e_c_s._n_w_u._e_d_u.
5.3.5 VIRUS-L
The VIRUS-L list is a forum for the discussion of computer
virus experiences, protection software, and related topics. The
list is open to the public, and is implemented as a mail reflec-
tor, not a digest. Most of the information is related to per-
sonal computers, although some of it may be applicable to larger
systems. To subscribe, send the line
SUB VIRUS-L _y_o_u_r _f_u_l_l _n_a_m_e
to the address _l_i_s_t_s_e_r_v%_l_e_h_i_i_b_m_1._b_i_t_n_e_t@_m_i_t_v_m_a._m_i_t._e_d_u.
53
54
SECTION 6
SUGGESTED READING
This section suggests some alternate sources of information
pertaining to the security and administration of the UNIX operat-
ing system.
_U_N_I_X _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _H_a_n_d_b_o_o_k
Evi Nemeth, Garth Snyder, Scott Seebass
Prentice Hall, 1989, $26.95
This is perhaps the best general-purpose book on UNIX system
administration currently on the market. It covers Berkeley
UNIX, SunOS, and System V. The 26 chapters and 17 appen-
dices cover numerous topics, including booting and shutting
down the system, the file system, configuring the kernel,
adding a disk, the line printer spooling system, Berkeley
networking, _s_e_n_d_m_a_i_l, and _u_u_c_p. Of particular interest are
the chapters on running as the super-user, backups, and
security.
_U_N_I_X _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m _S_e_c_u_r_i_t_y
F. T. Grammp and R. H. Morris
AT&T Bell Laboratories Technical Journal
October 1984
This is an excellent discussion of some of the more common
security problems in UNIX and how to avoid them, written by
two of Bell Labs' most prominent security experts.
_P_a_s_s_w_o_r_d _S_e_c_u_r_i_t_y: _A _C_a_s_e _H_i_s_t_o_r_y
Robert Morris and Ken Thompson
Communications of the ACM
November 1979
An excellent discussion on the problem of password security,
and some interesting information on how easy it is to crack
passwords and why. This document is usually reprinted in
most vendors' UNIX documentation.
_O_n _t_h_e _S_e_c_u_r_i_t_y _o_f _U_N_I_X
Dennis M. Ritchie
May 1975
A discussion on UNIX security from one of the original crea-
tors of the system. This document is usually reprinted in
most vendors' UNIX documentation.
_T_h_e _C_u_c_k_o_o'_s _E_g_g
55
Clifford Stoll
Doubleday, 1989, $19.95
An excellent story of Stoll's experiences tracking down the
German crackers who were breaking into his systems and sel-
ling the data they found to the KGB. Written at a level
that nontechnical users can easily understand.
_S_y_s_t_e_m _a_n_d _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n
Sun Microsystems
May, 1988
Part of the SunOS documentation, this manual covers most
aspects of Sun system administration, including security
issues. A must for anyone operating a Sun system, and a
pretty good reference for other UNIX systems as well.
_S_e_c_u_r_i_t_y _P_r_o_b_l_e_m_s _i_n _t_h_e _T_C_P/_I_P _P_r_o_t_o_c_o_l _S_u_i_t_e
S. M. Bellovin
ACM Computer Communications Review
April, 1989
An interesting discussion of some of the security problems
with the protocols in use on the Internet and elsewhere.
Most of these problems are far beyond the capabilities of
the average cracker, but it is still important to be aware
of them. This article is technical in nature, and assumes
familiarity with the protocols.
_A _W_e_a_k_n_e_s_s _i_n _t_h_e _4._2_B_S_D _U_N_I_X _T_C_P/_I_P _S_o_f_t_w_a_r_e
Robert T. Morris
AT&T Bell Labs Computer Science Technical Report 117
February, 1985
An interesting article from the author of the Internet worm,
which describes a method that allows remote hosts to
``spoof'' a host into believing they are trusted. Again,
this article is technical in nature, and assumes familiarity
with the protocols.
_C_o_m_p_u_t_e_r _V_i_r_u_s_e_s _a_n_d _R_e_l_a_t_e_d _T_h_r_e_a_t_s: _A _M_a_n_a_g_e_m_e_n_t _G_u_i_d_e
John P. Wack and Lisa J. Carnahan
National Institute of Standards and Technology
Special Publication 500-166
This document provides a good introduction to viruses,
worms, trojan horses, and so on, and explains how they work
and how they are used to attack computer systems. Written
for the nontechnical user, this is a good starting point for
learning about these security problems. This document can
be ordered for $2.50 from the U. S. Government Printing
Office, document number 003-003-02955-6.
56
SECTION 7
CONCLUSIONS
Computer security is playing an increasingly important role
in our lives as more and more operations become computerized, and
as computer networks become more widespread. In order to protect
your systems from snooping and vandalism by unauthorized crack-
ers, it is necessary to enable the numerous security features
provided by the UNIX system.
In this document, we have covered the major areas that can
be made more secure:
+o Account security
+o Network security
+o File system security.
Additionally, we have discussed how to monitor for security vio-
lations, where to obtain security-related software and bug fixes,
and numerous mailing lists for finding out about security prob-
lems that have been discovered.
Many crackers are not interested in breaking into specific
systems, but rather will break into any system that is vulnerable
to the attacks they know. Eliminating these well-known holes and
monitoring the system for other security problems will usually
serve as adequate defense against all but the most determined
crackers. By using the procedures and sources described in this
document, you _c_a_n make your system more secure.
57
58
REFERENCES
[Eich89] Eichin, Mark W., and Jon A. Rochlis. _W_i_t_h _M_i_c_r_o_s_c_o_p_e
_a_n_d _T_w_e_e_z_e_r_s: _A_n _A_n_a_l_y_s_i_s _o_f _t_h_e _I_n_t_e_r_n_e_t _V_i_r_u_s _o_f
_N_o_v_e_m_b_e_r _1_9_8_8. Massachusetts Institute of Technology.
February 1989.
[Elme88] Elmer-DeWitt, Philip. `` `The Kid Put Us Out of
Action.' '' _T_i_m_e, 132 (20): 76, November 14, 1988.
[Gram84] Grammp, F. T., and R. H. Morris. ``UNIX Operating Sys-
tem Security.'' _A_T&_T _B_e_l_l _L_a_b_o_r_a_t_o_r_i_e_s _T_e_c_h_n_i_c_a_l _J_o_u_r_-
_n_a_l, 63 (8): 1649-1672, October 1984.
[Hind83] Hinden, R., J. Haverty, and A. Sheltzer. ``The DARPA
Internet: Interconnecting Heterogeneous Computer Net-
works with Gateways.'' _I_E_E_E _C_o_m_p_u_t_e_r _M_a_g_a_z_i_n_e, 16 (9):
33-48, September 1983.
[McLe87] McLellan, Vin. ``NASA Hackers: There's More to the
Story.'' _D_i_g_i_t_a_l _R_e_v_i_e_w, November 23, 1987, p. 80.
[Morr78] Morris, Robert, and Ken Thompson. ``Password Security:
A Case History.'' _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 22 (11):
594-597, November 1979. Reprinted in _U_N_I_X _S_y_s_t_e_m
_M_a_n_a_g_e_r'_s _M_a_n_u_a_l, 4.3 Berkeley Software Distribution.
University of California, Berkeley. April 1986.
[NCSC85] National Computer Security Center. _D_e_p_a_r_t_m_e_n_t _o_f
_D_e_f_e_n_s_e _T_r_u_s_t_e_d _C_o_m_p_u_t_e_r _S_y_s_t_e_m _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a,
Department of Defense Standard DOD 5200.28-STD,
December, 1985.
[Quar86] Quarterman, J. S., and J. C. Hoskins. ``Notable Com-
puter Networks.'' _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 29 (10):
932-971, October 1986.
[Reed84] Reeds, J. A., and P. J. Weinberger. ``File Security
and the UNIX System Crypt Command.'' _A_T&_T _B_e_l_l _L_a_b_o_r_a_-
_t_o_r_i_e_s _T_e_c_h_n_i_c_a_l _J_o_u_r_n_a_l, 63 (8): 1673-1683, October
1984.
[Risk87] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s _a_n_d _R_e_l_a_t_e_d
_S_y_s_t_e_m_s. ACM Committee on Computers and Public Policy,
Peter G. Neumann, Moderator. Internet mailing list.
Issue 5.73, December 13, 1987.
[Risk88] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s _a_n_d _R_e_l_a_t_e_d
_S_y_s_t_e_m_s. ACM Committee on Computers and Public Policy,
Peter G. Neumann, Moderator. Internet mailing list.
59
Issue 7.85, December 1, 1988.
[Risk89a] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s _a_n_d _R_e_l_a_t_e_d
_S_y_s_t_e_m_s. ACM Committee on Computers and Public Policy,
Peter G. Neumann, Moderator. Internet mailing list.
Issue 8.2, January 4, 1989.
[Risk89b] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s _a_n_d _R_e_l_a_t_e_d
_S_y_s_t_e_m_s. ACM Committee on Computers and Public Policy,
Peter G. Neumann, Moderator. Internet mailing list.
Issue 8.9, January 17, 1989.
[Risk90] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s _a_n_d _R_e_l_a_t_e_d
_S_y_s_t_e_m_s. ACM Committee on Computers and Public Policy,
Peter G. Neumann, Moderator. Internet mailing list.
Issue 9.69, February 20, 1990.
[Ritc75] Ritchie, Dennis M. ``On the Security of UNIX.'' May
1975. Reprinted in _U_N_I_X _S_y_s_t_e_m _M_a_n_a_g_e_r'_s _M_a_n_u_a_l, 4.3
Berkeley Software Distribution. University of Califor-
nia, Berkeley. April 1986.
[Schu90] Schuman, Evan. ``Bid to Unhook Worm.'' _U_N_I_X _T_o_d_a_y!,
February 5, 1990, p. 1.
[Seel88] Seeley, Donn. _A _T_o_u_r _o_f _t_h_e _W_o_r_m. Department of Com-
puter Science, University of Utah. December 1988.
[Spaf88] Spafford, Eugene H. _T_h_e _I_n_t_e_r_n_e_t _W_o_r_m _P_r_o_g_r_a_m: _A_n
_A_n_a_l_y_s_i_s. Technical Report CSD-TR-823. Department of
Computer Science, Purdue University. November 1988.
[Stee88] Steele, Guy L. Jr., Donald R. Woods, Raphael A. Finkel,
Mark R. Crispin, Richard M. Stallman, and Geoffrey S.
Goodfellow. _T_h_e _H_a_c_k_e_r'_s _D_i_c_t_i_o_n_a_r_y. New York: Harper
and Row, 1988.
[Stei88] Stein, Jennifer G., Clifford Neuman, and Jeffrey L.
Schiller. ``Kerberos: An Authentication Service for
Open Network Systems.'' _U_S_E_N_I_X _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s,
Dallas, Texas, Winter 1988, pp. 203-211.
[Stol88] Stoll, Clifford. ``Stalking the Wily Hacker.'' _C_o_m_-
_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 31 (5): 484-497, May 1988.
[Stol89] Stoll, Clifford. _T_h_e _C_u_c_k_o_o'_s _E_g_g. New York: Double-
day, 1989.
[Sun88a] Sun Microsystems. _S_u_n_O_S _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, Part Number
800-1751-10, May 1988.
[Sun88b] Sun Microsystems. _S_y_s_t_e_m _a_n_d _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n,
60
Part Number 800-1733-10, May 1988.
[Sun88c] Sun Microsystems. _S_e_c_u_r_i_t_y _F_e_a_t_u_r_e_s _G_u_i_d_e, Part Number
800-1735-10, May 1988.
[Sun88d] Sun Microsystems. ``Network File System: Version 2
Protocol Specification.'' _N_e_t_w_o_r_k _P_r_o_g_r_a_m_m_i_n_g, Part
Number 800-1779-10, May 1988, pp. 165-185.
61
62
APPENDIX A - SECURITY CHECKLIST
This checklist summarizes the information presented in this
paper, and can be used to verify that you have implemented every-
thing described.
_A_c_c_o_u_n_t _S_e_c_u_r_i_t_y
[] Password policy developed and distributed to all users
[] All passwords checked against obvious choices
[] Expiration dates on all accounts
[] No ``idle'' guest accounts
[] All accounts have passwords or ``*'' in the password field
[] No group accounts
[] ``+'' lines in _p_a_s_s_w_d and _g_r_o_u_p checked if running Yellow Pages
_N_e_t_w_o_r_k _S_e_c_u_r_i_t_y
[] _h_o_s_t_s._e_q_u_i_v contains only local hosts, and no ``+''
[] No ._r_h_o_s_t_s files in users' home directories
[] Only local hosts in ``root'' ._r_h_o_s_t_s file, if any
[] Only ``console'' labeled as ``secure'' in _t_t_y_t_a_b (servers only)
[] No terminals labeled as ``secure'' in _t_t_y_t_a_b (clients only)
[] No NFS file systems exported to the world
[] _f_t_p_d version later than December, 1988
[] No ``decode'' alias in the aliases file
[] No ``wizard'' password in _s_e_n_d_m_a_i_l._c_f
[] No ``debug'' command in _s_e_n_d_m_a_i_l
[] _f_i_n_g_e_r_d version later than November 5, 1988
[] Modems and terminal servers handle hangups correctly
_F_i_l_e _S_y_s_t_e_m _S_e_c_u_r_i_t_y
[] No setuid or setgid shell scripts
[] Check all ``nonstandard'' setuid and setgid programs for security
[] Setuid bit removed from /_u_s_r/_e_t_c/_r_e_s_t_o_r_e
[] Sticky bits set on world-writable directories
[] Proper umask value on ``root'' account
[] Proper modes on devices in /_d_e_v
_B_a_c_k_u_p_s
[] Level 0 dumps at least monthly
[] Incremental dumps at least bi-weekly
63