23.6 Preventing Attacks

No matter what the threat is called, how it enters your system, or what the motives of the person(s) who wrote it may be, the potential for damage is your main concern. Any of these problems can result in downtime and lost or damaged resources. Understanding the nature of a threat can't prevent it from occurring.

At the same time, remember that you do not need many special precautions or special software to protect against programmed threats. The same simple, effective measures you would take to protect your system against unauthorized entry or malicious damage from insiders will also protect your system against these other threats.

23.6.1 File Protections

Files, directories, and devices that are writable by any user on the system can be dangerous security holes. An attacker who gains access to your system can gain even more access by modifying these files, directories, and devices. Maintaining a vigilant watch over your file protections protects against intrusion and protects your system's legitimate users from each other's mistakes and antics. (Chapter 6 introduces file permissions and describes how you can change them.)

23.6.1.1 World-writable user files and directories

Many inexperienced users (and even careless experienced users) make themselves vulnerable to attack by improperly setting the permissions on files in their home directories.

The .login file is a particularly vulnerable file. For example, if a user has a .login file that is world-writable, an attacker can modify the file to do his bidding. Suppose that a malicious attacker inserts this line at the end of a user's .login file:

/bin/rm -rf ~

Whenever a user logs in, the C shell executes all of the commands in the .login file. A user whose .login file contains this nasty line will find all of his files deleted when he logs in!

Some shells (and other programs) will not execute startup files if the files are not owned by the user who is currently running the program, or if directories in which the startup files are housed are world- or group-writable. As different programs have different rules, you should not depend on this functionality.

Suppose that the attacker appends these lines to the user's .login file:

/bin/cp /bin/sh /usr/tmp/.$USER
/bin/chmod 4755 /usr/tmp/.$USER

When the user logs in, the system creates an SUID shell in the /usr/tmp directory that will allow the attacker to assume the identity of the user at some point in the future.

In addition to .login, many other files pose security risks when they are world-writable. For example, if an attacker modifies a world-writable .rhosts or .ssh/authorized_keys file, she can take over the user's account via the network.

In general, the home directories and the files in the home directories should have permissions set so that they are writable only by the owner. Many files in the home directory, such as .rhosts, should be readable only by the owner as well. This practice will hinder an intruder in searching for other avenues of attack.

23.6.1.2 Writable system files and directories

There is also a risk when system files and directories are world-writable. An attacker can replace system programs (such as /bin/ls) with new programs that do the attacker's bidding. This practice is discussed in Chapter 19.

If you have a server that exports filesystems containing system programs (such as the /bin and /usr/bin directories), you may wish to export those filesystems read-only. Exporting a filesystem read-only renders the client unable to modify the files in that directory. To export a filesystem read-only, you must specify the read-only option in the /etc/exports file on the server. For example, to export the /bin and /usr/bin filesystems read-only, specify the following in your /etc/dfs/dfstab file:

share -F nfs -o ro=client /bin
share -F nfs -o ro=client /usr/bin

On a Berkeley-based system, place these lines in your /etc/exports file:

/bin       -ro,access=client
/usr/bin   -ro,access=client

Alternatively, you may wish to equip your server with two sets of executables: one that the server uses for itself, and one that is used for file-sharing clients (e.g., the server's /usr partition would be for its own use, while /nfsusr is the version of /usr that is used by NFS clients).

23.6.1.3 Group-writable files

Sometimes, making a file group-writable is almost as risky as making it world-writable. If everybody on your system is a member of the group user, then making a file group-writable by the group user is the same as making the file world-writable.

You can use the find command to search for files that are group-writable by a particular group, and to print a list of these files. For example, to search for all files that are writable by the group user, you might specify a command in the following form:

# find / -perm -020 -group user \! ( -type l -o -type p -o -type s \) -ls

If you have NFS, be sure to use the longer version of the command:

# find / \( -local -o -prune \) -perm -020 -group user \! /   
   \( -type l -o -type p -o -type s \) -ls

Often, files are made group-writable so several people can work on the same project, and this may be appropriate for your system. However, some files, such as .cshrc and .profile, should never be made group-writable. In many cases, this rule can be generalized to the following:

Any file beginning with a period should not be world- or group-writable.

A more security-conscious site can further generalize this rule:

Files that begin with a period should not be readable or writable by anyone other than the file's owner (that is, they should be mode 600).

Use the following form of the find command to search for all files beginning with a period in the /u filesystem that are either group-writable or world-writable:

# find /u -perm -2 -o -perm -20 -name .\* -ls

As noted earlier, if you are running NFS, be sure to add the -local or -xdev option to each of the find commands above and run them on each of your NFS servers.

23.6.1.4 World-readable backup devices

Your tape drive should not be world-readable. Otherwise, it allows any user to read the contents of any tape that happens to be in the tape drive. This scenario can be a significant problem for sites that do backups overnight, and then leave the tape in the drive until morning. During the hours that the tape is awaiting removal, any user can read the contents of any file on the tape.

23.6.2 Shared Libraries

Programs that depend on shared libraries are vulnerable to a variety of attacks that involve switching the shared library that the program is running. If your system has dynamic libraries, they need to be protected at the same level as the most sensitive program on your system because modifying those shared libraries can alter the operation of every program.

On some systems, additional shared libraries may be specified through the use of environment variables. While this is a useful feature on some occasions, the system's shared libraries should not be superseded for the following kinds of programs:

• Programs executed by SUID programs

• User shells

• Network servers

• Security services

• Auditing and logging processes

On most versions of Unix, you can disable shared libraries by statically linking the executable program. On others, you can limit whether alternate shared libraries are referenced by setting additional mode bits inside the executable image. We advise you to take these precautions when available.