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:
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.
|