2.2.7 Modems and Terminal Servers
Modems and terminal servers (terminal switches, Annex
boxes, etc.) present still another potential security problem.
The main problem with these devices is one of configuration -
misconfigured hardware can allow security breaches. Explaining
how to configure every brand of modem and terminal server would
require volumes. However, the following items should be
checked for on any modems or terminal servers installed at your
site:
1. If a user dialed up to a modem hangs up the phone,
the system should log him out. If it doesn't, check
the hardware connections and the kernel configuration
of the serial ports.
2. If a user logs off, the system should force the modem
to hang up. Again, check the hardware connections if
this doesn't work.
3. If the connection from a terminal server to the sys-
tem is broken, the system should log the user off.
4. If the terminal server is connected to modems, and
the user hangs up, the terminal server should inform
the system that the user has hung up.
Most modem and terminal server manuals cover in detail how
to properly connect these devices to your system. In particu-
lar you should pay close attention to the ``Carrier Detect,''
``Clear to Send,'' and ``Request to Send'' connections.
2.2.8 Firewalls
One of the newer ideas in network security is that of a
_f_i_r_e_w_a_l_l. Basically, a firewall is a special host that sits
between your outside-world network connection(s) and your
internal network(s). This host does not send out routing
information about your internal network, and thus the internal
network is ``invisible'' from the outside. In order to config-
ure a firewall machine, the following considerations need to be
taken:
1. The firewall does not advertise routes. This means
that users on the internal network must log in to the
firewall in order to access hosts on remote networks.
Likewise, in order to log in to a host on the
internal network from the outside, a user must first
log in to the firewall machine. This is incon-
venient, but more secure.
2. All electronic mail sent by your users must be for-
warded to the firewall machine if it is to be
delivered outside your internal network. The
firewall must receive all incoming electronic mail,
and then redistribute it. This can be done either
with aliases for each user or by using name server MX
records.
3. The firewall machine should not mount any file sys-
tems via NFS, or make any of its file systems avail-
able to be mounted.
4. Password security on the firewall must be rigidly
enforced.
5. The firewall host should not trust any other hosts
regardless of where they are. Furthermore, the
firewall should not be trusted by any other host.
6. Anonymous FTP and other similar services should only
be provided by the firewall host, if they are pro-
vided at all.
The purpose of the firewall is to prevent crackers from
accessing other hosts on your network. This means, in general,
that you must maintain strict and rigidly enforced security on
the firewall, but the other hosts are less vulnerable, and
hence security may be somewhat lax. But it is important to
remember that the firewall is not a complete cure against
crackers - if a cracker can break into the firewall machine, he
can then try to break into any other host on your network.
2.3 FILE SYSTEM SECURITY
The last defense against system crackers are the permis-
sions offered by the file system. Each file or directory has
three sets of permission bits associated with it: one set for
the user who owns the file, one set for the users in the group
with which the file is associated, and one set for all other
users (the ``world'' permissions). Each set contains three
identical permission bits, which control the following:
_r_e_a_d If set, the file or directory may be read. In
the case of a directory, read access allows a
user to see the contents of a directory (the
names of the files contained therein), but not to
access them.
_w_r_i_t_e If set, the file or directory may be written
(modified). In the case of a directory, write
permission implies the ability to create, delete,
and rename files. Note that the ability to
remove a file is _n_o_t controlled by the permis-
sions on the file, but rather the permissions on
the directory containing the file.
_e_x_e_c_u_t_e If set, the file or directory may be executed
(searched). In the case of a directory, execute
permission implies the ability to access files
contained in that directory.
In addition, a fourth permission bit is available in each
set of permissions. This bit has a different meaning in each
set of permission bits:
_s_e_t_u_i_d If set in the owner permissions, this bit controls
the ``set user id'' (setuid) status of a file.
Setuid status means that when a program is exe-
cuted, it executes with the permissions of the
user owning the program, in addition to the per-
missions of the user executing the program. For
example, _s_e_n_d_m_a_i_l is setuid ``root,'' allowing it
to write files in the mail queue area, which nor-
mal users are not allowed to do. This bit is
meaningless on nonexecutable files.
_s_e_t_g_i_d If set in the group permissions, this bit controls
the ``set group id'' (setgid) status of a file.
This behaves in exactly the same way as the setuid
bit, except that the group id is affected instead.
This bit is meaningless on non-executable files
(but see below).
_s_t_i_c_k_y If set in the world permissions, the ``sticky''
bit tells the operating system to do special
things with the text image of an executable file.
It is mostly a holdover from older versions of
UNIX, and has little if any use today. This bit
is also meaningless on nonexecutable files (but
see below).
2.3.1 Setuid Shell Scripts
Shell scripts that have the setuid or setgid bits set on
them are _n_o_t secure, regardless of how many safeguards are taken
when writing them. There are numerous software packages avail-
able that claim to make shell scripts secure, but every one
released so far has not managed to solve all the problems.
Setuid and setgid shell scripts should never be allowed on
any UNIX system.
2.3.2 The Sticky Bit on Directories
Newer versions of UNIX have attached a new meaning to the
sticky bit. When this bit is set on a directory, it means that
users may not delete or rename other users' files in this direc-
tory. This is typically useful for the /_t_m_p directory. Nor-
mally, /_t_m_p is world-writable, enabling any user to delete
another user's files. By setting the sticky bit on /_t_m_p, users
may only delete their own files from this directory.
To set the sticky bit on a directory, use the command
# chmod o+t _d_i_r_e_c_t_o_r_y
2.3.3 The Setgid Bit on Directories
In SunOS 4.0, the setgid bit was also given a new meaning.
Two rules can be used for assigning group ownership to a file in
SunOS:
1. The System V mechanism, which says that a user's pri-
mary group id (the one listed in the password file) is
assigned to any file he creates.
2. The Berkeley mechanism, which says that the group id of
a file is set to the group id of the directory in which
it is created.
If the setgid bit is set on a directory, the Berkeley
mechanism is enabled. Otherwise, the System V mechanism is
enabled. Normally, the Berkeley mechanism is used; this mechan-
ism must be used if creating directories for use by more than one
member of a group (see Section 2.1.5).
To set the setgid bit on a directory, use the command
# chmod g+s _d_i_r_e_c_t_o_r_y
2.3.4 The umask Value
When a file is created by a program, say a text editor or a
compiler, it is typically created with all permissions enabled.
Since this is rarely desirable (you don't want other users to be
able to write your files), the _u_m_a_s_k value is used to modify the
set of permissions a file is created with. Simply put, while the
_c_h_m_o_d command [Sun88a, 65-66] specifies what bits should be
turned _o_n, the umask value specifies what bits should be turned
_o_f_f.
For example, the default umask on most systems is 022. This
means that write permission for the group and world should be
turned off whenever a file is created. If instead you wanted to
turn off all group and world permission bits, such that any file
you created would not be readable, writable, or executable by
anyone except yourself, you would set your umask to 077.
The umask value is specified in the ._c_s_h_r_c or ._p_r_o_f_i_l_e files
read by the shell using the _u_m_a_s_k command [Sun88a, 108, 459].
The ``root'' account should have the line
umask 022
in its /._c_s_h_r_c file, in order to prevent the accidental creation
of world-writable files owned by the super-user.
2.3.5 Encrypting Files
The standard UNIX _c_r_y_p_t command [Sun88a, 95] is not at all
secure. Although it is reasonable to expect that _c_r_y_p_t will keep
the casual ``browser'' from reading a file, it will present noth-
ing more than a minor inconvenience to a determined cracker.
_C_r_y_p_t implements a one-rotor machine along the lines of the Ger-
man Enigma (broken in World War II). The methods of attack on
such a machine are well known, and a sufficiently large file can
usually be decrypted in a few hours even without knowledge of
what the file contains [Reed84]. In fact, publicly available
packages of programs designed to ``break'' files encrypted with
_c_r_y_p_t have been around for several years.
There are software implementations of another algorithm, the
Data Encryption Standard (DES), available on some systems.
Although this algorithm is much more secure than _c_r_y_p_t, it has
never been proven that it is totally secure, and many doubts
about its security have been raised in recent years.
Perhaps the best thing to say about encrypting files on a
computer system is this: if you think you have a file whose con-
tents are important enough to encrypt, then that file should not
be stored on the computer in the first place. This is especially
true of systems with limited security, such as UNIX systems and
personal computers.
It is important to note that UNIX passwords are _n_o_t
encrypted with the _c_r_y_p_t program. Instead, they are encrypted
with a modified version of the DES that generates one-way encryp-
tions (that is, the password cannot be decrypted). When you log
in, the system does not decrypt your password. Instead, it
encrypts your attempted password, and if this comes out to the
same result as encrypting your real password, you are allowed to
log in.
2.3.6 Devices
The security of devices is an important issue in UNIX. Dev-
ice files (usually residing in /_d_e_v) are used by various programs
to access the data on the disk drives or in memory. If these
device files are not properly protected, your system is wide open
to a cracker. The entire list of devices is too long to go into
here, since it varies widely from system to system. However, the
following guidelines apply to all systems:
1. The files /_d_e_v/_k_m_e_m, /_d_e_v/_m_e_m, and /_d_e_v/_d_r_u_m should
never be readable by the world. If your system sup-
ports the notion of the ``kmem'' group (most newer sys-
tems do) and utilities such as _p_s are setgid ``kmem,''
then these files should be owned by user ``root'' and
group ``kmem,'' and should be mode 640. If your system
does not support the notion of the ``kmem'' group, and
utilities such as _p_s are setuid ``root,'' then these
files should be owned by user ``root'' and mode 600.
2. The disk devices, such as /_d_e_v/_s_d_0_a, /_d_e_v/_r_x_y_1_b, etc.,
should be owned by user ``root'' and group ``opera-
tor,'' and should be mode 640. Note that each disk has
eight partitions and two device files for each parti-
tion. Thus, the disk ``sd0'' would have the following
device files associated with it in /_d_e_v:
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.
SECTION 3
MONITORING SECURITY
One of the most important tasks in keeping any computer sys-
tem secure is monitoring the security of the system. This
involves examining system log files for unauthorized accesses of
the system, as well as monitoring the system itself for security
holes. This section describes the procedures for doing this. An
additional part of monitoring security involves keeping abreast
of security problems found by others; this is described in Sec-
tion 5.
3.1 ACCOUNT SECURITY
Account security should be monitored periodically in order
to check for two things: users logged in when they ``shouldn't''
be (e.g., late at night, when they're on vacation, etc.), and
users executing commands they wouldn't normally be expected to
use. The commands described in this section can be used to
obtain this information from the system.
3.1.1 The lastlog File
The file /_u_s_r/_a_d_m/_l_a_s_t_l_o_g [Sun88a, 1485] records the most
recent login time for each user of the system. The message
printed each time you log in, e.g.,
Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c
uses the time stored in the _l_a_s_t_l_o_g file. Additionally, the last
login time reported by the _f_i_n_g_e_r command uses this time. Users
should be told to carefully examine this time whenever they log
in, and to report unusual login times to the system administra-
tor. This is an easy way to detect account break-ins, since each
user should remember the last time she logged into the system.
3.1.2 The utmp and wtmp Files
The file /_e_t_c/_u_t_m_p [Sun88a, 1485] is used to record who is
currently logged into the system. This file can be displayed
using the _w_h_o command [Sun88a, 597]:
% who
hendra tty0c Mar 13 12:31
heidari tty14 Mar 13 13:54
welgem tty36 Mar 13 12:15
reagin ttyp0 Mar 13 08:54 (aaifs.itstd.sri.)
ghg ttyp1 Mar 9 07:03 (hydra.riacs.edu)
compion ttyp2 Mar 1 03:01 (ei.ecn.purdue.ed)
For each user, the login name, terminal being used, login time,
and remote host (if the user is logged in via the network) are
displayed.
The file /_u_s_r/_a_d_m/_w_t_m_p [Sun88a, 1485] records each login and
logout time for every user. This file can also be displayed
using the _w_h_o command:
% who /usr/adm/wtmp
davy ttyp4 Jan 7 12:42 (annex01.riacs.ed)
ttyp4 Jan 7 15:33
davy ttyp4 Jan 7 15:33 (annex01.riacs.ed)
ttyp4 Jan 7 15:35
hyder ttyp3 Jan 8 09:07 (triceratops.itst)
ttyp3 Jan 8 11:43
A line that contains a login name indicates the time the user
logged in; a line with no login name indicates the time that the
terminal was logged off. Unfortunately, the output from this
command is rarely as simple as in the example above; if several
users log in at once, the login and logout times are all mixed
together and must be matched up by hand using the terminal name.
The _w_t_m_p file may also be examined using the _l_a_s_t command
[Sun88a, 248]. This command sorts out the entries in the file,
matching up login and logout times. With no arguments, _l_a_s_t
displays all information in the file. By giving the name of a
user or terminal, the output can be restricted to the information
about the user or terminal in question. Sample output from the
_l_a_s_t command is shown below.
% last
davy ttyp3 intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00)
hyder ttyp3 clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04)
reboot ~ Mon Mar 12 15:16
shutdown ~ Mon Mar 12 15:16
arms ttyp3 clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04)
hyder ttyp3 spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04)
reboot ~ Sat Mar 10 20:05
davy ftp hydra.riacs.edu Sat Mar 10 13:23 - 13:30 (00:07)
For each login session, the user name, terminal used, remote host
(if the user logged in via the network), login and logout times,
and session duration are shown. Additionally, the times of all
system shutdowns and reboots (generated by the _s_h_u_t_d_o_w_n and
_r_e_b_o_o_t commands [Sun88a, 1727, 1765]) are recorded. Unfor-
tunately, system crashes are not recorded. In newer versions of
the operating system, pseudo logins such as those via the _f_t_p
command are also recorded; an example of this is shown in the
last line of the sample output, above.
3.1.3 The acct File
The file /_u_s_r/_a_d_m/_a_c_c_t [Sun88a, 1344-1345] records each exe-
cution of a command on the system, who executed it, when, and how
long it took. This information is logged each time a command
completes, but only if your kernel was compiled with the SYSACCT
option enabled (the option is enabled in some GENERIC kernels,
but is usually disabled by default).
The _a_c_c_t file can be displayed using the _l_a_s_t_c_o_m_m command
[Sun88a, 249]. With no arguments, all the information in the
file is displayed. However, by giving a command name, user name,
or terminal name as an argument, the output can be restricted to
information about the given command, user, or terminal. Sample
output from _l_a_s_t_c_o_m_m is shown below.
% lastcomm
sh S root 0.67 secs Tue Mar 13 12:45
atrun root 0.23 secs Tue Mar 13 12:45
lpd F root 1.06 secs Tue Mar 13 12:44
lpr S burwell tty09 1.23 secs Tue Mar 13 12:44
troff burwell tty09 12.83 secs Tue Mar 13 12:44
eqn burwell tty09 1.44 secs Tue Mar 13 12:44
df kindred ttyq7 0.78 secs Tue Mar 13 12:44
ls kindred ttyq7 0.28 secs Tue Mar 13 12:44
cat kindred ttyq7 0.05 secs Tue Mar 13 12:44
stty kindred ttyq7 0.05 secs Tue Mar 13 12:44
tbl burwell tty09 1.08 secs Tue Mar 13 12:44
rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38
rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41
stty kindred ttyq7 0.05 secs Tue Mar 13 12:44
The first column indicates the name of the command. The next
column displays certain flags on the command: an ``F'' means the
process spawned a child process, ``S'' means the process ran with
the set-user-id bit set, ``D'' means the process exited with a
core dump, and ``X'' means the process was killed abnormally.
The remaining columns show the name of the user who ran the
program, the terminal he ran it from (if applicable), the amount
of CPU time used by the command (in seconds), and the date and
time the process started.
3.2 NETWORK SECURITY
Monitoring network security is more difficult, because there
are so many ways for a cracker to attempt to break in. However,
there are some programs available to aid you in this task. These
are described in this section.
3.2.1 The syslog Facility
The _s_y_s_l_o_g facility [Sun88a, 1773] is a mechanism that
enables any command to log error messages and informational mes-
sages to the system console, as well as to a log file. Typi-
cally, error messages are logged in the file /_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s
along with the date, time, name of the program sending the mes-
sage, and (usually) the process id of the program. A sample seg-
ment of the _m_e_s_s_a_g_e_s file is shown below.
Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri
Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries
Mar 13 06:01:18 sparkyfs vmunix: /: file system full
Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3
Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding
Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM
intrepid.itstd.s, daemon
Of particular interest in this sample are the messages from the
_l_o_g_i_n and _s_u programs. Whenever someone logs in as ``root,''
_l_o_g_i_n logs this information. Generally, logging in as ``root''
directly, rather than using the _s_u command, should be
discouraged, as it is hard to track which person is actually
using the account. Once this ability has been disabled, as
described in Section 2.2.2, detecting a security violation
becomes a simple matter of searching the _m_e_s_s_a_g_e_s file for lines
of this type.
_L_o_g_i_n also logs any case of someone repeatedly trying to log
in to an account and failing. After three attempts, _l_o_g_i_n will
refuse to let the person try anymore. Searching for these
messages in the _m_e_s_s_a_g_e_s file can alert you to a cracker
attempting to guess someone's password.
Finally, when someone uses the _s_u command, either to become
``root'' or someone else, _s_u logs the success or failure of this
operation. These messages can be used to check for users sharing
their passwords, as well as for a cracker who has penetrated one
account and is trying to penetrate others.
3.2.2 The showmount Command
The _s_h_o_w_m_o_u_n_t command [Sun88a, 1764] can be used on an NFS
file server to display the names of all hosts that currently have
something mounted from the server. With no options, the program
simply displays a list of all the hosts. With the -_a and -_d
options, the output is somewhat more useful. The first option,
-_a, causes _s_h_o_w_m_o_u_n_t to list all the host and directory combina-
tions. For example,
bronto.itstd.sri.com:/usr/share
bronto.itstd.sri.com:/usr/local.new
bronto.itstd.sri.com:/usr/share/lib
bronto.itstd.sri.com:/var/spool/mail
cascades.itstd.sri.com:/sparky/a
clyde.itstd.sri.com:/laser_dumps
cm1.itstd.sri.com:/sparky/a
coco0.itstd.sri.com:/sparky/a
There will be one line of output for each directory mounted by a
host. With the -_d option, _s_h_o_w_m_o_u_n_t displays a list of all
directories that are presently mounted by some host.
The output from _s_h_o_w_m_o_u_n_t should be checked for two things.
First, only machines local to your organization should appear
there. If you have set up proper netgroups as described in Sec-
tion 2.2.3, this should not be a problem. Second, only ``nor-
mal'' directories should be mounted. If you find unusual direc-
tories being mounted, you should find out who is mounting them
and why - although it is probably innocent, it may indicate some-
one trying to get around your security mechanisms.
3.3 FILE SYSTEM SECURITY
Checking for security holes in the file system is another
important part of making your system secure. Primarily, you need
to check for files that can be modified by unauthorized users,
files that can inadvertently grant users too many permissions,
and files that can inadvertently grant access to crackers. It is
also important to be able to detect unauthorized modifications to
the file system, and to recover from these modifications when
they are made.
3.3.1 The find Command
The _f_i_n_d command [Sun88a, 183-185] is a general-purpose com-
mand for searching the file system. Using various arguments,
complex matching patterns based on a file's name, type, mode,
owner, modification time, and other characteristics, can be con-
structed. The names of files that are found using these patterns
can then be printed out, or given as arguments to other UNIX com-
mands. The general format of a _f_i_n_d command is
% find _d_i_r_e_c_t_o_r_i_e_s _o_p_t_i_o_n_s
where _d_i_r_e_c_t_o_r_i_e_s is a list of directory names to search (e.g.,
/_u_s_r), and _o_p_t_i_o_n_s contains the options to control what is being
searched for. In general, for the examples in this section, you
will always want to search from the root of the file system (/),
in order to find all files matching the patterns presented.
This section describes how to use _f_i_n_d to search for four
possible security problems that were described in Section 2.
3.3.1.1 Finding Setuid and Setgid Files
It is important to check the system often for unauthorized
setuid and setgid programs. Because these programs grant special
privileges to the user who is executing them, it is necessary to
ensure that insecure programs are not installed. Setuid ``root''
programs should be closely guarded - a favorite trick of many
crackers is to break into ``root'' once, and leave a setuid pro-
gram hidden somewhere that will enable them to regain super-user
powers even if the original hole is plugged.
The command to search for setuid and setgid files is
# find / -type f -a \( -perm -4000 -o -perm -2000 \) -print
The options to this command have the following meanings:
/ The name of the directory to be searched. In this
case, we want to search the entire file system, so we
specify /. You might instead restrict the search to
/_u_s_r or /_h_o_m_e.
-type f
Only examine files whose type is ``f,'' regular file.
Other options include ``d'' for directory, ``l'' for
symbolic link, ``c'' for character-special devices, and
``b'' for block-special devices.
-a This specifies ``and.'' Thus, we want to know about
files whose type is ``regular file,'' _a_n_d whose permis-
sions bits match the other part of this expression.
\( -perm -4000 -o -perm -2000 \)
The parentheses in this part of the command are used
for grouping. Thus, everything in this part of the
command matches a single pattern, and is treated as the
other half of the ``and'' clause described above.
-perm -4000
This specifies a match if the ``4000'' bit (speci-
fied as an octal number) is set in the file's per-
mission modes. This is the set-user-id bit.
-o This specifies ``or.'' Thus, we want to match if
the file has the set-user-id bit _o_r the set-
group-id bit set.
-perm -2000
This specifies a match if the ``2000'' bit (speci-
fied as an octal number) is set in the file's per-
mission modes. This is the set-group-id bit.
-printThis indicates that for any file that matches the
specified expression (is a regular file _a_n_d has the
setuid _o_r setgid bits set in its permissions), print
its name on the screen.
After executing this command (depending on how much disk
space you have, it can take anywhere from 15 minutes to a couple
of hours to complete), you will have a list of files that have
setuid or setgid bits set on them. You should then examine each
of these programs, and determine whether they should actually
have these permissions. You should be especially suspicious of
programs that are _n_o_t in one of the directories (or a subdirec-
tory) shown below.
/bin
/etc
/usr/bin
/usr/ucb
/usr/etc
One file distributed with SunOS, /_u_s_r/_e_t_c/_r_e_s_t_o_r_e, is dis-
tributed with the setuid bit set on it, and should not be,
because of a security hole. You should be sure to remove the
setuid bit from this program by executing the command
# chmod u-s /usr/etc/restore
3.3.1.2 Finding World-Writable Files
World-writable files, particularly system files, can be a
security hole if a cracker gains access to your system and modi-
fies them. Additionally, world-writable directories are
dangerous, since they allow a cracker to add or delete files as
he wishes. The _f_i_n_d command to find all world-writable files is
# find / -perm -2 -print
In this case, we do not use the -_t_y_p_e option to restrict the
search, since we are interested in directories and devices as
well as files. The -_2 specifies the world write bit (in octal).
This list of files will be fairly long, and will include
some files that _s_h_o_u_l_d be world writable. You should not be con-
cerned if terminal devices in /_d_e_v are world writable. You
should also not be concerned about line printer error log files
being world writable. Finally, symbolic links may be world writ-
able - the permissions on a symbolic link, although they exist,
have no meaning.
3.3.1.3 Finding Unowned Files
Finding files that are owned by nonexistent users can often
be a clue that a cracker has gained access to your system. Even
if this is not the case, searching for these files gives you an
opportunity to clean up files that should have been deleted at
the same time the user herself was deleted. The command to find
unowned files is
# find / -nouser -print
The -_n_o_u_s_e_r option matches files that are owned by a user id not
contained in the /_e_t_c/_p_a_s_s_w_d database. A similar option,
-_n_o_g_r_o_u_p, matches files owned by nonexistent groups. To find all
files owned by nonexistent users _o_r groups, you would use the -_o
option as follows:
# find / -nouser -o -nogroup -print
3.3.1.4 Finding .rhosts Files
As mentioned in Section 2.2.1.2, users should be prohibited
from having ._r_h_o_s_t_s files in their accounts. To search for this,
it is only necessary to search the parts of the file system that
contain home directories (i.e., you can skip / and /_u_s_r):
# find /home -name .rhosts -print
The -_n_a_m_e option indicates that the complete name of any file
whose name matches ._r_h_o_s_t_s should be printed on the screen.
3.3.2 Checklists
Checklists can be a useful tool for discovering unauthorized
changes made to system directories. They aren't practical on
file systems that contain users' home directories since these
change all the time. A checklist is a listing of all the files
contained in a group of directories: their sizes, owners, modif-
ication dates, and so on. Periodically, this information is col-
lected and compared with the information in the master checklist.
Files that do not match in all attributes can be suspected of
having been changed.
There are several utilities that implement checklists avail-
able from public software sites (see Section 4). However, a sim-
ple utility can be constructed using only the standard UNIX _l_s
and _d_i_f_f commands.
First, use the _l_s command [Sun88a, 285] to generate a master
list. This is best done immediately after installing the operat-
ing system, but can be done at any time provided you're confident
about the correctness of the files on the disk. A sample command
is shown below.
# ls -aslgR /bin /etc /usr > MasterChecklist
The file _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t now contains a complete list of all the
files in these directories. You will probably want to edit it
and delete the lines for files you know will be changing often
(e.g., /_e_t_c/_u_t_m_p, /_u_s_r/_a_d_m/_a_c_c_t).
The _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t file
should be stored somewhere safe where a cracker is unlikely to
find it (since he could otherwise just change the data in it):
either on a different computer system, or on magnetic tape.
To search for changes in the file system, run the above _l_s
command again, saving the output in some other file, say
_C_u_r_r_e_n_t_L_i_s_t. Now use the _d_i_f_f command [Sun88a, 150] to compare
the two files:
# diff MasterChecklist CurrentList
Lines that are only in the master checklist will be printed pre-
ceded by a ``<,'' and lines that are only in the current list
will be preceded by a ``>.'' If there is one line for a file,
preceded by a ``<,'' this means that the file has been deleted
since the master checklist was created. If there is one line for
a file, preceded by a ``>,'' this means that the file has been
created since the master checklist was created. If there are two
lines for a single file, one preceded by ``<'' and the other by
``>,'' this indicates that some attribute of the file has changed
since the master checklist was created.
By carefully constructing the master checklist, and by
remembering to update it periodically (you can replace it with a
copy of _C_u_r_r_e_n_t_L_i_s_t, once you're sure the differences between the
lists are harmless), you can easily monitor your system for unau-
thorized changes. The software packages available from the pub-
lic software distribution sites implement basically the same
scheme as the one here, but offer many more options for control-
ling what is examined and reported.
3.3.3 Backups
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the even
of hardware failure or accidental deletions, but they also pro-
tect you against unauthorized file system changes made by a
cracker.
A good backup strategy will dump the entire system at level
zero (a ``full'' dump) at least once a month. Partial (or
``incremental'') dumps should be done at least twice a week, and
ideally they should be done daily. The _d_u_m_p command [Sun88a,
1612-1614] is recommended over other programs such as _t_a_r and
_c_p_i_o. This is because only _d_u_m_p is capable of creating a backup
that can be used to restore a disk to the exact state it was in
when it was dumped. The other programs do not take into account
files deleted or renamed between dumps, and do not handle some
specialized database files properly.
3.4 KNOW YOUR SYSTEM
Aside from running large monitoring programs such as those
described in the previous sections, simple everyday UNIX commands
can also be useful for spotting security violations. By running
these commands often, whenever you have a free minute (for exam-
ple, while waiting for someone to answer the phone), you will
become used to seeing a specific pattern of output. By being
familiar with the processes normally running on your system, the
times different users typically log in, and so on, you can easily
detect when something is out of the ordinary.
3.4.1 The ps Command
The _p_s command [Sun88a, 399-402] displays a list of the
processes running on your system. _P_s has numerous options, too
many to list here. Generally, however, for the purpose of moni-
toring, the option string -_a_l_x_w_w is the most useful.* On a Sun
system running SunOS 4.0, you should expect to see at least the
following:
_s_w_a_p_p_e_r, _p_a_g_e_d_a_e_m_o_n
System programs that help the virtual memory system.
/_s_b_i_n/_i_n_i_t
The _i_n_i_t process, which is responsible for numerous
tasks, including bringing up login processes on termi-
nals.
_p_o_r_t_m_a_p, _y_p_b_i_n_d, _y_p_s_e_r_v
Parts of the Yellow Pages system.
_b_i_o_d, _n_f_s_d, _r_p_c._m_o_u_n_t_d, _r_p_c._q_u_o_t_a_d, _r_p_c._l_o_c_k_d
Parts of the Network File System (NFS). If the system
you are looking at is not a file server, the _n_f_s_d
processes probably won't exist.
_r_a_r_p_d, _r_p_c._b_o_o_t_p_a_r_a_m_d
Part of the system that allows diskless clients to
boot.
Other commands you should expect to see are _u_p_d_a_t_e (file
system updater); _g_e_t_t_y (one per terminal and one for the
console); _l_p_d (line printer daemon); _i_n_e_t_d (Internet daemon, for
starting other network servers); _s_h and _c_s_h (the Bourne shell and
C shell, one or more per logged in user). In addition, if there
are users logged in, you'll probably see invocations of various
compilers, text editors, and word processing programs.
3.4.2 The who and w Commands
The _w_h_o command, as mentioned previously, displays the list
of users currently logged in on the system. By running this
periodically, you can learn at what times during the day various
users log in. Then, when you see someone logged in at a dif-
ferent time, you can investigate and make sure that it's legiti-
mate.
The _w command [Sun88a, 588] is somewhat of a cross between
_w_h_o and _p_s. Not only does it show a list of who is presently
logged in, but it also displays how long they have been idle
(gone without typing anything), and what command they are
currently running.
3.4.3 The ls Command
Simple as its function is, _l_s is actually very useful for
detecting file system problems. Periodically, you should use _l_s
on the various system directories, checking for files that
shouldn't be there. Most of the time, these files will have just
``landed'' somewhere by accident. However, by keeping a close
watch on things, you will be able to detect a cracker long before
you might have otherwise.
When using _l_s to check for oddities, be sure to use the -_a
option, which lists files whose names begin with a period (.).
Be particularly alert for files or directories named ``...'', or
``..(space)'', which many crackers like to use. (Of course,
remember that ``.'' and ``..'' are supposed to be there.)
3.5 KEEP YOUR EYES OPEN
Monitoring for security breaches is every bit as important
as preventing them in the first place. Because it's virtually
impossible to make a system totally secure, there is always the
chance, no matter how small, that a cracker will be able to gain
access. Only by monitoring can this be detected and remedied.
SECTION 4
SOFTWARE FOR IMPROVING SECURITY
Because security is of great concern to many sites, a wealth
of software has been developed for improving the security of UNIX
systems. Much of this software has been developed at universi-
ties and other public institutions, and is available free for the
asking. This section describes how this software can be
obtained, and mentions some of the more important programs avail-
able.
4.1 OBTAINING FIXES AND NEW VERSIONS
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes
some of the larger repositories.
4.1.1 Sun Fixes on UUNET
Sun Microsystems has contracted with UUNET Communications
Services, Inc. to make fixes for bugs in Sun software available
via anonymous FTP. You can access these fixes by using the _f_t_p
command [Sun88a, 195-201] to connect to the host _f_t_p._u_u._n_e_t.
Then change into the directory _s_u_n-_f_i_x_e_s, and obtain a directory
listing, as shown in the example on the following page.
% ftp ftp.uu.net
Connected to uunet.UU.NET.
220 uunet FTP server (Version 5.93 Mar 20 11:01:52 EST 1990) ready
Name (ftp.uu.net:davy): anonymous
331 Guest login ok, send ident as password.
Password:
_e_n_t_e_r _y_o_u_r _m_a_i_l _a_d_d_r_e_s_s
_y_o_u_r_n_a_m_e@_y_o_u_r_h_o_s_t _h_e_r_e
230 Guest login ok, access restrictions apply.
ftp> cd sun-fixes
_2_5_0 _C_W_D _c_o_m_m_a_n_d _s_u_c_c_e_s_s_f_u_l.
_f_t_p> _d_i_r
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 2258
-rw-r--r-- 1 38 22 4558 Aug 31 1989 README
-rw-r--r-- 1 38 22 484687 Dec 14 1988 ddn.tar.Z
-rw-r--r-- 1 38 22 140124 Jan 13 1989 gated.sun3.Z
-rwxr-xr-x 1 38 22 22646 Dec 14 1988 in.ftpd.sun3.Z
.....
.....
-rw-r--r-- 1 38 22 72119 Aug 31 1989 sendmail.sun3.Z
-rwxr-xr-x 1 38 22 99147 Aug 31 1989 sendmail.sun4.Z
-rw-r--r-- 1 38 22 3673 Jul 11 1989 wall.sun3.Z
-rw-r--r-- 1 38 22 4099 Jul 11 1989 wall.sun4.Z
-rwxr-xr-x 1 38 22 7955 Jan 18 1989 ypbind.sun3.Z
-rwxr-xr-x 1 38 22 9237 Jan 18 1989 ypbind.sun4.Z
226 Transfer complete.
1694 bytes received in 0.39 seconds (4.2 Kbytes/s)
ftp> quit
_2_2_1 _G_o_o_d_b_y_e.
%
The file _R_E_A_D_M_E contains a brief description of what each file in
this directory contains, and what is required to install the fix.
4.1.2 Berkeley Fixes
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily to the
current release of BSD UNIX (currently release 4.3). However,
even if you are not running their software, these fixes are still
important, since many vendors (Sun, DEC, Sequent , etc.) base
their software on the Berkeley releases.
The Berkeley fixes are available for anonymous FTP from the
host _u_c_b_a_r_p_a._b_e_r_k_e_l_e_y._e_d_u in the directory _4._3/_u_c_b-_f_i_x_e_s.
The file _I_N_D_E_X in this directory describes what each file contains.
Berkeley also distributes new versions of _s_e_n_d_m_a_i_l and _n_a_m_e_d
[Sun88a, 1758-1760, 1691-1692] from this machine. New versions
of these commands are stored in the _4._3 directory, usually in the
files _s_e_n_d_m_a_i_l._t_a_r._Z and _b_i_n_d._t_a_r._Z, respectively.
4.1.3 Simtel-20 and UUNET
The two largest general-purpose software repositories on the
Internet are the hosts _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l and _f_t_p._u_u._n_e_t.
_w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l is a TOPS-20 machine operated by the
U. S. Army at White Sands Missile Range, New Mexico. The direc-
tory _p_d_2:<_u_n_i_x-_c> contains a large amount of UNIX software, pri-
marily taken from the _c_o_m_p._s_o_u_r_c_e_s newsgroups. The file _0_0_0-
_m_a_s_t_e_r-_i_n_d_e_x._t_x_t contains a master list and description of each
piece of software available in the repository. The file _0_0_0-
_i_n_t_r_o-_u_n_i_x-_s_w._t_x_t contains information on the mailing list used
to announce new software, and describes the procedures used for
transferring files from the archive with FTP.
_f_t_p._u_u._n_e_t is operated by UUNET Communications Services,
Inc. in Falls Church, Virginia. This company sells Internet and
USENET access to sites all over the country (and internation-
ally). The software posted to the following USENET source news-
groups is stored here, in directories of the same name:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
Numerous other distributions, such as all the freely distribut-
able Berkeley UNIX source code, Internet Request for Comments
(RFCs), and so on are also stored on this machine.
4.1.4 Vendors
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous FTP.
You should contact your vendor to find out if they offer this
service, and if so, how to access it. Some vendors that offer
these services include Sun Microsystems (see above), Digital
Equipment Corp., the University of California at Berkeley (see
above), and Apple Computer.
4.2 THE NPASSWD COMMAND
The _n_p_a_s_s_w_d command, developed by Clyde Hoover at the
University of Texas at Austin, is intended to be a replacement
for the standard UNIX _p_a_s_s_w_d command [Sun88a, 379], as well as
the Sun _y_p_p_a_s_s_w_d command [Sun88a, 611]. _n_p_a_s_s_w_d makes passwords
more secure by refusing to allow users to select insecure pass-
words. The following capabilities are provided by _n_p_a_s_s_w_d:
+o Configurable minimum password length
+o Configurable to force users to use mixed case or digits
and punctuation
+o Checking for ``simple'' passwords such as a repeated
letter
+o Checking against the host name and other host-specific
information
+o Checking against the login name, first and last names,
and so on
+o Checking for words in various dictionaries, including
the system dictionary.
The _n_p_a_s_s_w_d distribution is available for anonymous FTP from
_e_m_x._u_t_e_x_a_s._e_d_u in the directory _p_u_b/_n_p_a_s_s_w_d.
4.3 THE COPS PACKAGE
COPS is a security tool for system administrators that
checks for numerous common security problems on UNIX systems,
including many of the things described in this document. COPS is
a collection of shell scripts and C programs that can easily be
run on almost any UNIX variant. Among other things, it checks
the following items and sends the results to the system adminis-
trator:
+o Checks /_d_e_v/_k_m_e_m and other devices for world
read/writability.
+o Checks special/important files and directories for
``bad'' modes (world writable, etc.).
+o Checks for easily guessed passwords.
+o Checks for duplicate user ids, invalid fields in the
password file, etc.
+o Checks for duplicate group ids, invalid fields in the
group file, etc.
+o Checks all users' home directories and their ._c_s_h_r_c,
._l_o_g_i_n, ._p_r_o_f_i_l_e, and ._r_h_o_s_t_s files for security prob-
lems.
+o Checks all commands in the /_e_t_c/_r_c files [Sun88a,
1724-1725] and _c_r_o_n files [Sun88a, 1606-1607] for world
writability.
+o Checks for bad ``root'' paths, NFS file system exported
to the world, etc.
+o Includes an expert system that checks to see if a given
user (usually ``root'') can be compromised, given that
certain rules are true.
+o Checks for _c_h_a_n_g_e_s in the setuid status of programs on
the system.
The COPS package is available from the _c_o_m_p._s_o_u_r_c_e_s._u_n_i_x
archive on _f_t_p._u_u._n_e_t, and also from the repository on _w_s_m_r-
_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l.
4.4 SUN C2 SECURITY FEATURES
With the release of SunOS 4.0, Sun has included security
features that allow the system to operate at a higher level of
security, patterned after the C2* classification. These features
can be installed as one of the options when installing the system
from the distribution tapes. The security features added by this
option include
+o Audit trails that record all login and logout times,
the execution of administrative commands, and the exe-
cution of privileged (setuid) operations.
+o A more secure password file mechanism (``shadow pass-
word file'') that prevents crackers from obtaining a
list of the encrypted passwords.
+o DES encryption capability.
+o A (more) secure NFS implementation that uses public-key
encryption to authenticate the users of the system and
the hosts on the network, to be sure they really are
who they claim to be.
These security features are described in detail in [Sun88c].
4.5 KERBEROS
Kerberos [Stei88] is an authentication system developed by
the Athena Project at the Massachusetts Institute of Technology.
Kerberos is a third-party authentication service, which is
trusted by other network services. When a user logs in, Kerberos
authenticates that user (using a password), and provides the user
with a way to prove her identity to other servers and hosts scat-
tered around the network.
This authentication is then used by programs such as _r_l_o_g_i_n
[Sun88a, 418-419] to allow the user to log in to other hosts
without a password (in place of the ._r_h_o_s_t_s file). The authenti-
cation is also used by the mail system in order to guarantee that
mail is delivered to the correct person, as well as to guarantee
that the sender is who he claims to be. NFS has also been modi-
fied by M.I.T. to work with Kerberos, thereby making the system
much more secure.
The overall effect of installing Kerberos and the numerous
other programs that go with it is to virtually eliminate the
ability of users to ``spoof'' the system into believing they are
someone else. Unfortunately, installing Kerberos is very
intrusive, requiring the modification or replacement of numerous
standard programs. For this reason, a source license is usually
necessary. There are plans to make Kerberos a part of 4.4BSD, to
be released by the University of California at Berkeley sometime
in 1990.
SECTION 5
KEEPING ABREAST OF THE BUGS
One of the hardest things about keeping a system secure is
finding out about the security holes before a cracker does. To
combat this, there are several sources of information you can and
should make use of on a regular basis.
5.1 THE COMPUTER EMERGENCY RESPONSE TEAM
The Computer Emergency Response Team (CERT) was established
in December 1988 by the Defense Advanced Research Projects Agency
to address computer security concerns of research users of the
Internet. It is operated by the Software Engineering Institute
at Carnegie-Mellon University. The CERT serves as a focal point
for the reporting of security violations, and the dissemination
of security advisories to the Internet community. In addition,
the team works with vendors of various systems in order to coor-
dinate the fixes for security problems.
The CERT sends out security advisories to the _c_e_r_t-_a_d_v_i_s_o_r_y mailing
list whenever appropriate.
They also operate a 24-hour hotline that can be called to report security problems (e.g.,
someone breaking into your system), as well as to obtain current
(and accurate) information about rumored security problems.
To join the _c_e_r_t-_a_d_v_i_s_o_r_y mailing list, send a message to
_c_e_r_t@_c_e_r_t._s_e_i._c_m_u._e_d_u and ask to be added to the mailing list.
Past advisories are available for anonymous FTP from the host _c_e_r_t._s_e_i._c_m_u._e_d_u.
The 24-hour hotline number is (412) 268-7090.
5.2 DDN MANAGEMENT BULLETINS
The _D_D_N _M_a_n_a_g_e_m_e_n_t _B_u_l_l_e_t_i_n is distributed electronically by the
Defense Data Network (DDN) Network Information Center under contract to the Defense Communications Agency.
It is a means of communicating official policy, procedures, and other information
of concern to management personnel at DDN facilities.
The _D_D_N _S_e_c_u_r_i_t_y _B_u_l_l_e_t_i_n is distributed electronically by the
DDN SCC (Security Coordination Center), also under contract to DCA, as a means of communicating information
on network and host security exposures, fixes, and concerns to security and
management personnel at DDN facilities.
Anyone may join the mailing lists for these two bulletins by
sending a message to _n_i_c@_n_i_c._d_d_n._m_i_l and asking to be placed on the mailing lists.
5.3 SECURITY-RELATED MAILING LISTS
There are several other mailing lists operated on the Inter-
net that pertain directly or indirectly to various security
issues. Some of the more useful ones are described below.
5.3.1 Security
The UNIX Security mailing list exists to notify system
administrators of security problems _b_e_f_o_r_e they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be veri-
fied as being principal systems people at a site. Requests to
join the list must be sent by either the site contact listed in
the Network Information Center's WHOIS database, or from the
``root'' account on one of the major site machines. You must
include the destination address you want on the list, an indica-
tion of whether you want to be on the mail reflector list or
receive weekly digests, the electronic mail address and voice
telephone number of the site contact if it isn't you, and the
name, address, and telephone number of your organization. This
information should be sent to _s_e_c_u_r_i_t_y-_r_e_q_u_e_s_t@_c_p_d._c_o_m.
5.3.2 RISKS
The RISKS digest is a component of the ACM Committee on Com-
puters and Public Policy, moderated by Peter G. Neumann. It is a
discussion forum on risks to the public in computers and related
systems, and along with discussing computer security and privacy
issues, has discussed such subjects as the Stark incident, the
shooting down of the Iranian airliner in the Persian Gulf (as it
relates to the computerized weapons systems), problems in air and
railroad traffic control systems, software engineering, and so
on. To join the mailing list, send a message to _r_i_s_k_s-
_r_e_q_u_e_s_t@_c_s_l._s_r_i._c_o_m. This list is also available in the USENET newsgroup
Credits
-- UnKnown --
|