Security Tips for System Administrators

You can do many things as an administrator to help secure your system against unauthorized access and the damage that can result. In addition to securing your local machine, there are a number of methods to “armor” your system against network attacks. We discuss the network security issues and methods of guarding against intruders in greater depth in Chapter 12 and Chapter 17.

What follows is a list of security tips for administrators for local machines.

Use Only Authorized Commands   Make sure the authorized versions of commands that allow system access are used. These commands include

su	Used to change permissions to those of another user
cu	Used to call other UNIX systems
ttymon (formerly getty)	Used to listen to terminal ports and allow login requests
login	Used to log in as a different user

If someone is able to replace these commands with his own versions, change their ownership permissions, or move his own versions of these commands ahead of the real ones in a user’s $PATH, that person may be able to secure other people’s passwords or complete information about how to access remote systems.

Protect Your Superusers   Passwords, particularly root passwords, should not be given over the phone, written down, or told to users who do not need to know them. Change privileged passwords frequently, and use different passwords for different machines, to limit the amount of access if a password is discovered. Close off permissions to superuser login directories so that nobody can write to their bin or change their .profile. Limit the number of setuid programs (those that give one user the permissions of another) to those that are necessary Don’t make setuid programs world-readable. Remove unnecessary setuid programs from the system. The following command will mail a list of all setuid root files to sysadmin.

 # /usr/bin/find / -user root -perm -4000 -print        /usr/ucb/mail -s "setuid root files" sysadmin

If you need to perform superuser tasks while logged in as a normal user, use the sudo command to allow you to temporarily perform the superuser task you need to. This will return you to normal user privileges upon completion of the task, and avoid involuntarily leaving a user with root privileges. Specific users can also be granted access to specific limited root-level commands used for system administration functions (which are logged for security purposes) using sudo.

Provide Accountability   Set up your system in a way that will provide accountability Each user should have his or her own login and user ID so that the user is solely responsible for the use of that login. If you do want to provide a special-purpose login that many people can use for a specific task, such as reading company news, you should not allow that login to access the UNIX system shell. Use commands like useradd and passwd or the menu interface provided with your system to add users and change passwords. This will ensure that the /etc/passwd and /etc/shadow are kept in sync.

Protect Administrative Files   Administrative files should be carefully protected. If log files such as sulog, which tracks superuser activity, are modified, someone could attempt to break in as superuser could be hidden. If files in the crontab directory, especially those owned by root, sys, and other administrative logins, are modified, someone could start up processes with the owner’s privileges at given times. If startup files, such as inittab and rc.Xd, are modified, commands could start up when your system changes states that would allow unauthorized access to your system.

A secure system requires that you set it up in a secure way and then continually monitor the system to be sure that no one has compromised that security Some of the techniques you can use are discussed in the following sections.

Use Password Aging   Use password aging to make your users change their passwords at set intervals. Here is an example of how to set password aging:

 # passwd -x 40 -n 5 abc

In this example, the maximum amount of time that user abc can go without changing her password is 40 days. The next time abc logs in after 40 days, she will be told to enter a new password. After the password is changed, it cannot be changed again for at least five days (this will prevent a user from immediately changing back to the old password).

Limit setuid Programs   Check for setuid and setgid programs. These are programs that give a user, or group, the access permissions of another user or group. These files should be limited to only those that are necessary, and they should never be writable. Here are some examples of standard setuid programs that reside in /bin:

 # ls -1 /bin   -r-sr-xr-x   1 root    bin      36488 Oct 11 20:20 /bin/at   -r-sr-xr-x   1 root    bin      17300 Oct 11 20:21 /bin/crontab   ---s-x-x     1 uucp    uucp     66780 Oct 11 07:58 /bin/cu   -r-sr-xr-x   1 root    root     38472 Oct 11 11:34 /bin/su

In each case, the command provides that user’s privileges to any user who runs the command. Make sure the commands are not writable and that they are owned by administrative logins.

Use Full Pathnames   When accessing commands that ask you for password information, use full pathnames, such as /bin/su. Use these commands only on trusted terminals, preferably only from the console.

Analyze Log Files   You should analyze log files for attempts to misuse your system. Here are two important log files:

/var/adm/sulog	Logs each time the su command is used to change the user’s privileges to those of another.
/var/cron/log	Contains a history of processes started by cron.
/var/log/secure	Logs network services such as ftp and telnet attempts.
/var/log/authlog	Traces Authentication Server activity.