Article

UNIX Security in a Networked Environment

Laurie Sefton

In any networked environment -- even a "secure" network which may not have access to an external network such as Internet -- users should be trained to maintain a reasonable level of security, and system administrators should install customized security tweaks and audits. What follows is a list of common security "holes" on networks, along with fixes that can be used to close these holes. None of these fixes requires access to source code or the ability to manipulate the kernel, so they are easily installable by either system administrators or the user base.

Hole #1: /etc/passwd

The most easily breached security mechanism is an easy-to-guess password, such as:

a login name or a user's first or last name

a company, department, or project name

•:a "historical" password, including a word used since college or the name or nickname of a spouse, child, or pet

an identifying characteristic, such as a favorite sports team or automobile

a word currently in /usr/dict/words or a word less than six characters (on systems that still allow this)

any word that is in standard English or non-English dictionaries

a common word surrounded by numbers or non-alphabetic characters -- these permutations are now in common search mechanisms

A good password should:

be easily remembered. A word that will be forgotten during vacation will add to the workload, rather than be effective, and could cause a greater security breach if you have to write it down to remember it.

contain more than six characters, including non-alphanumeric characters such as "$,%,.,&,@,!"

be easy to type, preferably with both hands (this reduces the chance that someone will guess your password by watching you log into the computer).

The system administrator should run periodic checks to make sure that no accounts without passwords or with easily guessed passwords are available. These lapses tend to occur when a new version of the operating system has been released, or a third-party product has been installed. Many of the third party login names and passwords have become generally known and are used to break into systems. Since these accounts typically have root or daemon access and privileges on the system, they represent a particularly dangerous threat.

The system administrator should also perform periodic checks for system use. Such a check can be accomplished by crosschecking information obtained by the finger command with file dates inside the user's account (since finger does not always pick up a user who is connecting via an X-window system). Users who have not logged into the system over a specified time frame should first be warned and then, if their account shows no activity over a second specified period, be deactivated. The login shell should reflect this status and should provide the user information on whom to contact to regain use of the account. Generally, you should use a standard group name such as "operations" or "MIS" in such a message, so that you don't wind up providing a systems cracker with more personal account information.

Hole #2: /etc/hosts.equiv

/etc/hosts.equiv allows a user to rsh/rcmsh onto a system without being prompted for a password. This capability is useful in an environment where users need to be able to send remote shell commands without being denied because of permission. However, much of the functionality of this command was transferred to the /etc/hosts.lpd file, which lists those systems which are allowed to use the host system as a remote print server. A "+" for the other entry in this file means that you are allowing users from any system with an account on your system to gain access without a password. It also means that anyone who has cracked the password on one of the other systems can gain access to your system. It's a good idea to restrict access here to the systems in your own project group or subnet.

Hole #3: .rhosts

The .rhosts file is kept in login account. Its purpose is to allow a specific user or users from another system to log in without being prompted for a password. It is most commonly used by system administrators who need to work on multiple systems and need to be able to do their work without being prompted for a password. For example, the /etc/rdump and /etc/rrestore commands are usually used by root in conjunction with the .rhosts file found in the root login directory. The possibility for abuse arises when a user allows others access to his/her account in order to share files. If there is a legitimate need to share files, the systems administrator can accommodate it either by allowing group access to a project's files or through a combination of group access and NFS-mounted filesystems. The .rhosts file has also been used by a number of systems crackers to move from system to another -- even across multiple university campuses.

Hole #4: tftpd

tftpd allows the use of the trivial file transfer protocol (tftp), which enables the user to access files across systems without being prompted for a password. The user must be able to specify the files, as tftp doesn't allow the user to traverse the filesystem. A knowledgeable user, however, will be able to transfer such key files as /etc/passwd, /.rhosts, /etc/hosts, and /etc/hosts.equiv, to his/her own system. There are two easy ways to make sure this doesn't happen: one is to turn off tftp by removing the tftp entry from /etc/inetd.conf; the other is to move the tftpd file, usually found in /usr/etc/tftpd, to tftp.old. An alternative method is to limit the ability to use tftp solely to root; in this case, though, you should be aware that some diskless clients may need tftp to boot across the network.

Hole #5: /etc/exports

The /etc/exports file lists the filesystems that can be mounted from a specific host system and shows which systems can do the mounting. A line in the file that looks like this:

/usr/games

indicates that any system on the network may mount the directory /usr/games. Never leave a filesystem mountable by the world. A better alternative would be:

/usr/games	 -access=bigsol.cadcam.com

which allows only the system bigsol to access the /usr/games directory. For a directory such as /usr/man the system administrator may want to restrict access to read-only:

/usr/man -access=thrud.cadcam.com,ro

Hole #6: /var/adm/messages, /var/adm/wtmp, /var/adm/pacct

Many system administrators turn off system accounting because they don't want to have to deal with an ever-growing set of files. Often, however, these files provide the only clue that a break-in has occurred -- either by having been altered or by disappearing altogether. If space is at a premium on the system, it's better to solve the problem through regular backup and cleaning of the administrative files, rather than by turning them off.

Hole #7: setuid and setgid

A number of files on any system will have a setuid (set user ID) to root. This allows any user to execute these files with owner or group owner privileges. For example, /usr/ucb/rlogin has setuid to root. If the system administrator were to remove all setuid and setgid files from the system, users would suddenly find themselves unable to do a remote login to other systems or to send print jobs by a remote printer. Instead, the system administrator should keep a list of the setuid and setgid files normally found on the system and should search regularly for any new files of this type. The find command provides an easy means of searching for setuid scripts:

find / -perm 4755 -print &

find / -perm 4755 -print >
/home/myacct/sysadm_file &

The former will print out on the screen any files that have a setuid; the latter will print the same information to a file -- in this case, a file in the system administrator's account.

To search for a setgid file, use:

find / -perm 6755 -print &

find / -perm 4755 -print >
/home/myacct/sysadm_file &

Finally, a suite of programs useful for security purposes is available from CERT (Computer Emergency Response Team) under the name "COPS" (Computer Oracle and Password System). If you are on Internet, you can obtain this package by using the anonymous ftp server at cert.sei.cmu.edu (192.88.209.5). The COPS package will check and report on

permissions on user and administrative files, including world writeability

poorly chosen passwords, and contents of the /etc/passwd and /etc/group files

unrestricted tftp

shell scripts in /etc/inetd.conf

as well as many other factors. COPS will also notify the system administrator via electronic mail when it finds a security breach. While COPS isn't a substitute for good system administrative packages, it's an excellent tool for the security-conscious system administrator.

While these suggestions for keeping your system safe may seem self-evident, a quick perusal of the "cracking" magazines shows that most of the systems broken into haven't provided even a minimal level of security. By providing a reasonable level of security, you can protect your system against unwanted incursion, lost time, and lost work.

About the Author

Laurie Sefton is CAD System Support Manager at Apple Computer, Inc. She earned a degree in Industrial Psychology from Purdue University and has been involved in system administration for 10 years. She is currently working towards an MBA degree at San Jose State University. She may be contacted at lsefton@apple.com .