Страница:
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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
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).
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 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.
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
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
# chmod g+s directory
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.
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.
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.
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:
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.''
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.
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.
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.
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.
The file /etc/utmp [Sun88a, 1485] is used to record who is
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)
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.
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
of CPU time used by the command (in seconds), and the date and
time the process started.
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.
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
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.
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.
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 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.
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.
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
/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
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
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.
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:
# find / -nouser -o -nogroup -print
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.
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
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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
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).
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 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.
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
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
# chmod g+s directory
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.
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.
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.
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:
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.''
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.
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.
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.
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.
The file /etc/utmp [Sun88a, 1485] is used to record who is
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)
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.
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
of CPU time used by the command (in seconds), and the date and
time the process started.
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.
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
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.
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.
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 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.
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.
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
/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
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
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.
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:
# find / -nouser -o -nogroup -print
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.
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
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.
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.