vice. This is how file servers and other machines with disks should be set up. The most secure configuration is to remove the ``secure'' designation from all terminals, including the console device. This requires that those users with super-user authority first log in as themselves, and then become the super-user via the su _________________________ | Under non-Sun versions of Berkeley UNIX, this file is called /etc/ttys. command. It also requires the ``root'' password to be entered when rebooting in single-user mode, in order to prevent users from rebooting their desktop workstations and obtaining super- user access. This is how all diskless client machines should be set up. 2.2.3 The Network File System The Network File System (NFS) [Sun88d] is designed to allow several hosts to share files over the network. One of the most common uses of NFS is to allow diskless workstations to be installed in offices, while keeping all disk storage in a central location. As distributed by Sun, NFS has no security features enabled. This means that any host on the Internet may access your files via NFS, regardless of whether you trust them or not. Fortunately, there are several easy ways to make NFS more secure. The more commonly used methods are described in this section, and these can be used to make your files quite secure from unauthorized access via NFS. Secure NFS, introduced in SunOS Release 4.0, takes security one step further, using public-key encryption techniques to ensure authorized access. Discussion of secure NFS is deferred until Section 4. 2.2.3.1 The exports File The file /etc/exports [Sun88a, 1377] is perhaps one of the most important parts of NFS configuration. This file lists which file systems are exported (made available for mounting) to other systems. A typical exports file as installed by the Sun installation procedure looks something like this: /usr /home /var/spool/mail # /export/root/client1 -access=client1,root=client1 /export/swap/client1 -access=client1,root=client1 # /export/root/client2 -access=client2,root=client2 /export/swap/client2 -access=client2,root=client2 The root= keyword specifies the list of hosts that are allowed to have super-user access to the files in the named file system. This keyword is discussed in detail in Section 2.2.3.3. The access= keyword specifies the list of hosts (separated by colons) that are allowed to mount the named file system. If no access= keyword is specified for a file system, any host anywhere on the network may mount that file system via NFS. Obviously, this presents a major security problem, since anyone who can mount your file systems via NFS can then peruse them at her leisure. Thus, it is important that all file sys- tems listed in exports have an access= keyword associated with them. If you have only a few hosts which must mount a file system, you can list them individually in the file: /usr -access=host1:host2:host3:host4:host5 However, because the maximum number of hosts that can be listed this way is ten, the access= keyword will also allow netgroups to be specified. Netgroups are described in the next section. After making any changes to the exports file, you should run the command # exportfs -a in order to make the changes take effect. 2.2.3.2 The netgroup File The file /etc/netgroup [Sun88a, 1407] is used to define netgroups. This file is controlled by Yellow Pages, and must be rebuilt in the Yellow Pages maps whenever it is modified. Consider the following sample netgroup file: A_Group (servera,,) (clienta1,,) (clienta2,,) B_Group (serverb,,) (clientb1,,) (clientb2,,) AdminStaff (clienta1,mary,) (clientb3,joan,) AllSuns A_Group B_Group This file defines four netgroups, called A_Group, B_Group, AdminStaff, and AllSuns. The AllSuns netgroup is actually a ``super group'' containing all the members of the A_Group and B_Group netgroups. Each member of a netgroup is defined as a triple: (host, user, domain). Typically, the domain field is never used, and is simply left blank. If either the host or user field is left blank, then any host or user is considered to match. Thus the triple (host,,) matches any user on the named host, while the triple (,user,) matches the named user on any host. Netgroups are useful when restricting access to NFS file systems via the exports file. For example, consider this modi- fied version of the file from the previous section: /usr -access=A_Group /home -access=A_Group:B_Group /var/spool/mail -access=AllSuns # /export/root/client1 -access=client1,root=client1 /export/swap/client1 -access=client1,root=client1 # /export/root/client2 -access=client2,root=client2 /export/swap/client2 -access=client2,root=client2 The /usr file system may now only be mounted by the hosts in the A_Group netgroup, that is, servera, clienta1, and clienta2. Any other host that tries to mount this file system will receive an ``access denied'' error. The /home file system may be mounted by any of the hosts in either the A_Group or B_Group netgroups. The /var/spool/mail file system is also restricted to these hosts, but in this example we used the ``super group'' called AllSuns. Generally, the best way to configure the netgroup file is to make a single netgroup for each file server and its clients, and then to make other super groups, such as AllSuns. This allows you the flexibility to specify the smallest possible group of hosts for each file system in /etc/exports. Netgroups can also be used in the password file to allow access to a given host to be restricted to the members of that group, and they can be used in the hosts.equiv file to central- ize maintenance of the list of trusted hosts. The procedures for doing this are defined in more detail in the Sun manual. 2.2.3.3 Restricting Super-User Access Normally, NFS translates the super-user id to a special id called ``nobody'' in order to prevent a user with ``root'' on a remote workstation from accessing other people's files. This is good for security, but sometimes a nuisance for system administration, since you cannot make changes to files as ``root'' through NFS. The exports file also allows you to grant super-user access to certain file systems for certain hosts by using the root= keyword. Following this keyword a colon-separated list of up to ten hosts may be specified; these hosts will be allowed to access the file system as ``root'' without having the user id converted to ``nobody.'' Netgroups may not be specified to the root= keyword. Granting ``root'' access to a host should not be done lightly. If a host has ``root'' access to a file system, then the super-user on that host will have complete access to the file system, just as if you had given him the ``root'' password on the server. Untrusted hosts should never be given ``root'' access to NFS file systems. 2.2.4 FTP The File Transfer Protocol, implemented by the ftp and ftpd programs [Sun88a, 195-201, 1632-1634], allows users to connect to remote systems and transfer files back and forth. Unfortunately, older versions of these programs also had several bugs in them that allowed crackers to break into a sys- tem. These bugs have been fixed by Berkeley, and new versions are available. If your ftpd* was obtained before December 1988, you should get a newer version (see Section 4). One of the more useful features of FTP is the ``anonymous'' login. This special login allows users who do not have an account on your machine to have restricted access in order to transfer files from a specific directory. This is useful if you wish to distribute software to the public at large without giving each person who wants the software an account on your machine. In order to securely set up anonymous FTP you should follow the specific instructions below: 1. Create an account called ``ftp.'' Disable the account by placing an asterisk (*) in the password field. Give the account a special home directory, such as /usr/ftp or /usr/spool/ftp. 2. Make the home directory owned by ``ftp'' and unwrit- able by anyone: # chown ftp ~ftp # chmod 555 ~ftp _________________________ * On Sun systems, ftpd is stored in the file /usr/etc/in.ftpd. On most other systems, it is called /etc/ftpd. 3. Make the directory ~ftp/bin, owned by the super-user and unwritable by anyone. Place a copy of the ls program in this directory: # mkdir ~ftp/bin # chown root ~ftp/bin # chmod 555 ~ftp/bin # cp -p /bin/ls ~ftp/bin # chmod 111 ~ftp/bin/ls 4. Make the directory ~ftp/etc, owned by the super-user and unwritable by anyone. Place copies of the pass- word and group files in this directory, with all the password fields changed to asterisks (*). You may wish to delete all but a few of the accounts and groups from these files; the only account that must be present is ``ftp.'' # mkdir ~ftp/etc # chown root ~ftp/etc # chmod 555 ~ftp/etc # cp -p /etc/passwd /etc/group ~ftp/etc # chmod 444 ~ftp/etc/passwd ~ftp/etc/group 5. Make the directory ~ftp/pub, owned by ``ftp'' and world-writable. Users may then place files that are to be accessible via anonymous FTP in this directory: # mkdir ~ftp/pub # chown ftp ~ftp/pub # chmod 777 ~ftp/pub Because the anonymous FTP feature allows anyone to access your system (albeit in a very limited way), it should not be made available on every host on the network. Instead, you should choose one machine (preferably a server or standalone host) on which to allow this service. This makes monitoring for security violations much easier. If you allow people to transfer files to your machine (using the world-writable pub directory, described above), you should check often the con- tents of the directories into which they are allowed to write. Any suspicious files you find should be deleted. 2.2.4.1 Trivial FTP The Trivial File Transfer Protocol, TFTP, is used on Sun workstations (and others) to allow diskless hosts to boot from the network. Basically, TFTP is a stripped-down version of FTP - there is no user authentication, and the connection is based on the User Datagram Protocol instead of the Transmission Con- trol Protocol. Because they are so stripped-down, many imple- mentations of TFTP have security holes. You should check your hosts by executing the command sequence shown below. % tftp tftp> connect yourhost tftp> get /etc/motd tmp Error code 1: File not found tftp> quit % If your version does not respond with ``File not found,'' and instead transfers the file, you should replace your version of tftpd* with a newer one. In particular, versions of SunOS prior to release 4.0 are known to have this problem. 2.2.5 Mail Electronic mail is one of the main reasons for connecting to outside networks. On most versions of Berkeley-derived UNIX systems, including those from Sun, the sendmail program [Sun88a, 1758-1760; Sun88b, 441-488] is used to enable the receipt and delivery of mail. As with the FTP software, older versions of sendmail have several bugs that allow security vio- lations. One of these bugs was used with great success by the Internet worm [Seel88, Spaf88]. The current version of send- mail from Berkeley is version 5.61, of January 1989. Sun is, as of this writing, still shipping version 5.59, which has a known security problem. They have, however, made a fixed ver- sion available. Section 4 details how to obtain these newer versions. Generally, with the exception of the security holes men- tioned above, sendmail is reasonably secure when installed by most vendors' installation procedures. There are, however, a few precautions that should be taken to ensure secure opera- tion: 1. Remove the ``decode'' alias from the aliases file (/etc/aliases or /usr/lib/aliases). _________________________ * On Sun systems, tftpd is stored in the file /usr/etc/in.tftpd. On most other systems, it is called /etc/tftpd. 2. If you create aliases that allow messages to be sent to programs, be absolutely sure that there is no way to obtain a shell or send commands to a shell from these programs. 3. Make sure the ``wizard'' password is disabled in the configuration file, sendmail.cf. (Unless you modify the distributed configuration files, this shouldn't be a problem.) 4. Make sure your sendmail does not support the ``debug'' command. This can be done with the follow- ing commands: % telnet localhost 25 220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST debug 500 Command unrecognized quit % If your sendmail responds to the ``debug'' command with ``200 Debug set,'' then you are vulnerable to attack and should replace your sendmail with a newer version. By following the procedures above, you can be sure that your mail system is secure. 2.2.6 Finger The ``finger'' service, provided by the finger program [Sun88a, 186-187], allows you to obtain information about a user such as her full name, home directory, last login time, and in some cases when she last received mail and/or read her mail. The fingerd program [Sun88a, 1625] allows users on remote hosts to obtain this information. A bug in fingerd was also exercised with success by the Internet worm [Seel88, Spaf88]. If your version of fingerd* is older than November 5, 1988, it should be replaced with a newer version. New versions are available from several of the sources described in Section 4. _________________________ * On Sun systems, fingerd is stored in /usr/etc/in.fingerd. On most other systems, it is called /etc/fingerd. 2.2.7 Modems and Terminal Servers Modems and terminal servers (terminal switches, Annex boxes, etc.) present still another potential security problem. The main problem with these devices is one of configuration - misconfigured hardware can allow security breaches. Explaining how to configure every brand of modem and terminal server would require volumes. However, the following items should be checked for on any modems or terminal servers installed at your site: 1. If a user dialed up to a modem hangs up the phone, the system should log him out. If it doesn't, check the hardware connections and the kernel configuration of the serial ports. 2. If a user logs off, the system should force the modem to hang up. Again, check the hardware connections if this doesn't work. 3. If the connection from a terminal server to the sys- tem is broken, the system should log the user off. 4. If the terminal server is connected to modems, and the user hangs up, the terminal server should inform the system that the user has hung up. Most modem and terminal server manuals cover in detail how to properly connect these devices to your system. In particu- lar you should pay close attention to the ``Carrier Detect,'' ``Clear to Send,'' and ``Request to Send'' connections. 2.2.8 Firewalls One of the newer ideas in network security is that of a firewall. Basically, a firewall is a special host that sits between your outside-world network connection(s) and your internal network(s). This host does not send out routing information about your internal network, and thus the internal network is ``invisible'' from the outside. In order to config- ure a firewall machine, the following considerations need to be taken: 1. The firewall does not advertise routes. This means that users on the internal network must log in to the firewall in order to access hosts on remote networks. Likewise, in order to log in to a host on the internal network from the outside, a user must first log in to the firewall machine. This is incon- venient, but more secure. 2. All electronic mail sent by your users must be for- warded to the firewall machine if it is to be delivered outside your internal network. The firewall must receive all incoming electronic mail, and then redistribute it. This can be done either with aliases for each user or by using name server MX records. 3. The firewall machine should not mount any file sys- tems via NFS, or make any of its file systems avail- able to be mounted. 4. Password security on the firewall must be rigidly enforced. 5. The firewall host should not trust any other hosts regardless of where they are. Furthermore, the firewall should not be trusted by any other host. 6. Anonymous FTP and other similar services should only be provided by the firewall host, if they are pro- vided at all. The purpose of the firewall is to prevent crackers from accessing other hosts on your network. This means, in general, that you must maintain strict and rigidly enforced security on the firewall, but the other hosts are less vulnerable, and hence security may be somewhat lax. But it is important to remember that the firewall is not a complete cure against crackers - if a cracker can break into the firewall machine, he can then try to break into any other host on your network. 2.3 FILE SYSTEM SECURITY The last defense against system crackers are the permis- sions offered by the file system. Each file or directory has three sets of permission bits associated with it: one set for the user who owns the file, one set for the users in the group with which the file is associated, and one set for all other users (the ``world'' permissions). Each set contains three identical permission bits, which control the following: read If set, the file or directory may be read. In the case of a directory, read access allows a user to see the contents of a directory (the names of the files contained therein), but not to access them. write If set, the file or directory may be written (modified). In the case of a directory, write permission implies the ability to create, delete, and rename files. Note that the ability to remove a file is not controlled by the permis- sions on the file, but rather the permissions on the directory containing the file. execute If set, the file or directory may be executed (searched). In the case of a directory, execute permission implies the ability to access files contained in that directory. In addition, a fourth permission bit is available in each set of permissions. This bit has a different meaning in each set of permission bits: setuid If set in the owner permissions, this bit controls the ``set user id'' (setuid) status of a file. Setuid status means that when a program is exe- cuted, it executes with the permissions of the user owning the program, in addition to the per- missions of the user executing the program. For example, sendmail is setuid ``root,'' allowing it to write files in the mail queue area, which nor- mal users are not allowed to do. This bit is meaningless on nonexecutable files. setgid If set in the group permissions, this bit controls the ``set group id'' (setgid) status of a file. This behaves in exactly the same way as the setuid bit, except that the group id is affected instead. This bit is meaningless on non-executable files (but see below). sticky If set in the world permissions, the ``sticky'' bit tells the operating system to do special things with the text image of an executable file. It is mostly a holdover from older versions of UNIX, and has little if any use today. This bit is also meaningless on nonexecutable files (but see below). 2.3.1 Setuid Shell Scripts Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of how many safeguards are taken when writing them. There are numerous software packages avail- able that claim to make shell scripts secure, but every one released so far has not managed to solve all the problems. Setuid and setgid shell scripts should never be allowed on any UNIX system. 2.3.2 The Sticky Bit on Directories Newer versions of UNIX have attached a new meaning to the sticky bit. When this bit is set on a directory, it means that users may not delete or rename other users' files in this direc- tory. This is typically useful for the /tmp directory. Nor- mally, /tmp is world-writable, enabling any user to delete another user's files. By setting the sticky bit on /tmp, users may only delete their own files from this directory. To set the sticky bit on a directory, use the command # chmod o+t directory 2.3.3 The Setgid Bit on Directories In SunOS 4.0, the setgid bit was also given a new meaning. Two rules can be used for assigning group ownership to a file in SunOS: 1. The System V mechanism, which says that a user's pri- mary group id (the one listed in the password file) is assigned to any file he creates. 2. The Berkeley mechanism, which says that the group id of a file is set to the group id of the directory in which it is created. If the setgid bit is set on a directory, the Berkeley mechanism is enabled. Otherwise, the System V mechanism is enabled. Normally, the Berkeley mechanism is used; this mechan- ism must be used if creating directories for use by more than one member of a group (see Section 2.1.5). To set the setgid bit on a directory, use the command # chmod g+s directory 2.3.4 The umask Value When a file is created by a program, say a text editor or a compiler, it is typically created with all permissions enabled. Since this is rarely desirable (you don't want other users to be able to write your files), the umask value is used to modify the set of permissions a file is created with. Simply put, while the chmod command [Sun88a, 65-66] specifies what bits should be turned on, the umask value specifies what bits should be turned off. For example, the default umask on most systems is 022. This means that write permission for the group and world should be turned off whenever a file is created. If instead you wanted to turn off all group and world permission bits, such that any file you created would not be readable, writable, or executable by anyone except yourself, you would set your umask to 077. The umask value is specified in the .cshrc or .profile files read by the shell using the umask command [Sun88a, 108, 459]. The ``root'' account should have the line umask 022 in its /.cshrc file, in order to prevent the accidental creation of world-writable files owned by the super-user. 2.3.5 Encrypting Files The standard UNIX crypt command [Sun88a, 95] is not at all secure. Although it is reasonable to expect that crypt will keep the casual ``browser'' from reading a file, it will present noth- ing more than a minor inconvenience to a determined cracker. Crypt implements a one-rotor machine along the lines of the Ger- man Enigma (broken in World War II). The methods of attack on such a machine are well known, and a sufficiently large file can usually be decrypted in a few hours even without knowledge of what the file contains [Reed84]. In fact, publicly available packages of programs designed to ``break'' files encrypted with crypt have been around for several years. There are software implementations of another algorithm, the Data Encryption Standard (DES), available on some systems. Although this algorithm is much more secure than crypt, it has never been proven that it is totally secure, and many doubts about its security have been raised in recent years. Perhaps the best thing to say about encrypting files on a computer system is this: if you think you have a file whose con- tents are important enough to encrypt, then that file should not be stored on the computer in the first place. This is especially true of systems with limited security, such as UNIX systems and personal computers. It is important to note that UNIX passwords are not encrypted with the crypt program. Instead, they are encrypted with a modified version of the DES that generates one-way encryp- tions (that is, the password cannot be decrypted). When you log in, the system does not decrypt your password. Instead, it encrypts your attempted password, and if this comes out to the same result as encrypting your real password, you are allowed to log in. 2.3.6 Devices The security of devices is an important issue in UNIX. Dev- ice files (usually residing in /dev) are used by various programs to access the data on the disk drives or in memory. If these device files are not properly protected, your system is wide open to a cracker. The entire list of devices is too long to go into here, since it varies widely from system to system. However, the following guidelines apply to all systems: 1. The files /dev/kmem, /dev/mem, and /dev/drum should never be readable by the world. If your system sup- ports the notion of the ``kmem'' group (most newer sys- tems do) and utilities such as ps are setgid ``kmem,'' then these files should be owned by user ``root'' and group ``kmem,'' and should be mode 640. If your system does not support the notion of the ``kmem'' group, and utilities such as ps are setuid ``root,'' then these files should be owned by user ``root'' and mode 600. 2. The disk devices, such as /dev/sd0a, /dev/rxy1b, etc., should be owned by user ``root'' and group ``opera- tor,'' and should be mode 640. Note that each disk has eight partitions and two device files for each parti- tion. Thus, the disk ``sd0'' would have the following device files associated with it in /dev: 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 /usr/adm/lastlog [Sun88a, 1485] records the most recent login time for each user of the system. The message printed each time you log in, e.g., Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c uses the time stored in the lastlog file. Additionally, the last login time reported by the finger command uses this time. Users should be told to carefully examine this time whenever they log in, and to report unusual login times to the system administra- tor. This is an easy way to detect account break-ins, since each user should remember the last time she logged into the system. 3.1.2 The utmp and wtmp Files The file /etc/utmp [Sun88a, 1485] is used to record who is 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. 3.1.3 The acct File The file /usr/adm/acct [Sun88a, 1344-1345] records each exe- cution of a command on the system, who executed it, when, and how long it took. This information is logged each time a command completes, but only if your kernel was compiled with the SYSACCT option enabled (the option is enabled in some GENERIC kernels, but is usually disabled by default). The acct file can be displayed using the lastcomm command [Sun88a, 249]. With no arguments, all the information in the file is displayed. However, by giving a command name, user name, or terminal name as an argument, the output can be restricted to information about the given command, user, or terminal. Sample output from lastcomm is shown below. % lastcomm sh S root __ 0.67 secs Tue Mar 13 12:45 atrun root __ 0.23 secs Tue Mar 13 12:45 lpd F root __ 1.06 secs Tue Mar 13 12:44 lpr S burwell tty09 1.23 secs Tue Mar 13 12:44 troff burwell tty09 12.83 secs Tue Mar 13 12:44 eqn burwell tty09 1.44 secs Tue Mar 13 12:44 df kindred ttyq7 0.78 secs Tue Mar 13 12:44 ls kindred ttyq7 0.28 secs Tue Mar 13 12:44 cat kindred ttyq7 0.05 secs Tue Mar 13 12:44 stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 tbl burwell tty09 1.08 secs Tue Mar 13 12:44 rlogin S jones ttyp3 5.66 secs Tue Mar 13 12:38 rlogin F jones ttyp3 2.53 secs Tue Mar 13 12:41 stty kindred ttyq7 0.05 secs Tue Mar 13 12:44 The first column indicates the name of the command. The next column displays certain flags on the command: an ``F'' means the process spawned a child process, ``S'' means the process ran with the set-user-id bit set, ``D'' means the process exited with a core dump, and ``X'' means the process was killed abnormally. The remaining columns show the name of the user who ran the program, the terminal he ran it from (if applicable), the amount of CPU time used by the command (in seconds), and the date and time the process started. 3.2 NETWORK SECURITY Monitoring network security is more difficult, because there are so many ways for a cracker to attempt to break in. However, there are some programs available to aid you in this task. These are described in this section. 3.2.1 The syslog Facility The syslog facility [Sun88a, 1773] is a mechanism that enables any command to log error messages and informational mes- sages to the system console, as well as to a log file. Typi- cally, error messages are logged in the file /usr/adm/messages along with the date, time, name of the program sending the mes- sage, and (usually) the process id of the program. A sample seg- ment of the messages file is shown below. Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri Mar 12 16:52:20 sparkyfs vmunix: sd2c: read failed, no retries Mar 13 06:01:18 sparkyfs vmunix: /: file system full Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3 Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM intrepid.itstd.s, daemon Of particular interest in this sample are the messages from the login and su programs. Whenever someone logs in as ``root,'' login logs this information. Generally, logging in as ``root'' directly, rather than using the su command, should be discouraged, as it is hard to track which person is actually using the account. Once this ability has been disabled, as described in Section 2.2.2, detecting a security violation becomes a simple matter of searching the messages file for lines of this type. Login also logs any case of someone repeatedly trying to log in to an account and failing. After three attempts, login will refuse to let the person try anymore. Searching for these messages in the messages file can alert you to a cracker attempting to guess someone's password. Finally, when someone uses the su command, either to become ``root'' or someone else, su logs the success or failure of this operation. These messages can be used to check for users sharing their passwords, as well as for a cracker who has penetrated one account and is trying to penetrate others. 3.2.2 The showmount Command The showmount command [Sun88a, 1764] can be used on an NFS file server to display the names of all hosts that currently have something mounted from the server. With no options, the program simply displays a list of all the hosts. With the -a and -d options, the output is somewhat more useful. The first option, -a, causes showmount to list all the host and directory combina- tions. For example, bronto.itstd.sri.com:/usr/share bronto.itstd.sri.com:/usr/local.new bronto.itstd.sri.com:/usr/share/lib bronto.itstd.sri.com:/var/spool/mail cascades.itstd.sri.com:/sparky/a clyde.itstd.sri.com:/laser_dumps cm1.itstd.sri.com:/sparky/a coco0.itstd.sri.com:/sparky/a There will be one line of output for each directory mounted by a host. With the -d option, showmount displays a list of all directories that are presently mounted by some host. The output from showmount should be checked for two things. First, only machines local to your organization should appear there. If you have set up proper netgroups as described in Sec- tion 2.2.3, this should not be a problem. Second, only ``nor- mal'' directories should be mounted. If you find unusual direc- tories being mounted, you should find out who is mounting them and why - although it is probably innocent, it may indicate some- one trying to get around your security mechanisms. 3.3 FILE SYSTEM SECURITY Checking for security holes in the file system is another important part of making your system secure. Primarily, you need to check for files that can be modified by unauthorized users, files that can inadvertently grant users too many permissions, and files that can inadvertently grant access to crackers. It is also important to be able to detect unauthorized modifications to the file system, and to recover from these modifications when they are made. 3.3.1 The find Command The find command [Sun88a, 183-185] is a general-purpose com- mand for searching the file system. Using various arguments, complex matching patterns based on a file's name, type, mode, owner, modification time, and other characteristics, can be con- structed. The names of files that are found using these patterns can then be printed out, or given as arguments to other UNIX com- mands. The general format of a find command is % find directories options where directories is a list of directory names to search (e.g., /usr), and options contains the options to control what is being searched for. In general, for the examples in this section, you will always want to search from the root of the file system (/), in order to find all files matching the patterns presented. This section describes how to use find to search for four possible security problems that were described in Section 2. 3.3.1.1 Finding Setuid and Setgid Files It is important to check the system often for unauthorized setuid and setgid programs. Because these programs grant special privileges to the user who is executing them, it is necessary to ensure that insecure programs are not installed. Setuid ``root'' programs should be closely gu