System configuration

SDSC's Administrator Guidelines for Maintaining Systems Privileged (root) access

• *NO* remote root logins. PERIOD. No excuses. Log in as a user and use sudo or su. You are a SysAdmin and you should be able to construct a way to get your job done without logging in directly to systems as root.

For SDSC Admins: At the time of this writing there is only one exception to this and it will not be documented here. Contact Security Technologies for information.

• If direct root login is required, then do it at the console. There should not be an excuse for remote root access. Sucks to be a SysAdmin sometimes. Always try to think of another, better way to do this. Inconvenience for you may mean reducing risk to your resources.

Do not give friends, vendors, contractors or others any root password or sudo. There should be a process for these type of people to gain privileged access. Construct and Fill out a privileged user form. Security concious system administrators should understand this.

• Do not su from root to a user account. Security Technologies monitors for this behavior and will contact the systems administrator to inquire about all such changes from privileged users to user accounts. This activity is not prohibited, but is strongly discouraged.

• Admin access should be from "secure" locations. Whatever that means. Don't go to a cybercafe machine or a public library workstation to login to your systems and do privileged work.

• Root password is changed whenever anyone who had it leaves the job or changes roles and no longer needs it.

• Do separate user login authentication from privileged access authentication. In other words, the user password MUST be different from the privileged access password (su or sudo password).

• Any activity that might inadvertently expose the root password, e.g. accidentally typing it in as a username, *must* be followed by a root password change. Immediately contact the Security Technologies staff if you suspect root password exposure or potential root compromise.

Files and File Systems

• Audit all setuid root binaries and remove the setuid bits from unnecessary programs. Unnecessary programs include ones that you do not know what they are or do.

     find / -mount -perm -004000 -user root -exec ls -lg {} \;

• All world writable directories should have the sticky bit set.

     drwxrwxrwt   4 root     sys          571 Apr 13 15:17 /tmp/

• In general, files owned by root should not be world writable, and usually not group writable.

• Most current day operating systems have this but, audit root's path, make sure dirs are owned and only writable by root. minimize as much as possible, e.g. /sbin:/usr/sbin:/bin:/usr/bin

• Use RCS, Revision Control System, to maintain important configuration files, such as, hosts.allow, inetd.conf, hosts, sshd_config, etc.

• DO NOT mount file systems with SETUID enabled. DO NOT export file systems with root user privileges. Export your NFS file systems to specific hosts, do not export to the world or use wildcards in the config files. READ Chapter 15 Network Filesystems, in the S. Garfinkel, G. Spafford and A. Schwartz, Practical Unix and Internet Security, 3rd Edition, O'Reilly and Associates, Feb 2003

Output from mount command:

     /usr/local on mynfs:/usr/local/generic remote/read only/nosuid/vers=3/bg/intr/xattr on Tue Apr 13 07:47:32 2004
                                                             ^^^^^^

Example entry for fstab file:

     mynfs:/usr/local/generic   - /usr/local nfs - yes rw,bg,intr,nosuid,quota

Other

• Machines should be installed off the network until they are fully and safely configured to be on the network.

• It is very important to keep up-to-date with security patches. Most systems are compromised by obtaining privileges through known exploits for which there already exists a patch.

• Log your syslog data to local disk and to your centralized log server. Your Security Technologies people can help monitor your system for known bad guys and signs of intrusion. Here is an example syslog entry:

     *.debug              /var/log/messages
     *.debug              @lager.sdsc.edu       (this is SDSC's central log host)

These log files should only be root readable. Owned by root with permissions of 600. If you must, allow the root group or some other group you create to read the log files and put only necessary users in this group.

• Do understand and use TCP Wrappers for access control to network services on your systems.

• Perform, maintain and audit your backups. You may need them to restore your system back to a known state.

• All Secure Shell daemons should only support protocol version 2 or higher. This is implemented by modifying the sshd_config file to specify protocol 2 only. The default protocol if not specified allows fallback to version 1.