Top 10 UNIX System Administration Practices for a Secure Computing Environment
IT Security Office, San Diego State University
July 19, 2004
This document provides a baseline standard for the installation, hardening and auditing of a secure UNIX system. This is not intended to be a complete list of practices and many of the implementation details are left to the reader, but it does provide a good, minimum set of essential system administration techniques when running a secure UNIX server on the SDSU network. Proper security must always be done in layers and in addition to firewalls and other basic network protection, proper system administration practices are an essential part of the overall security plan. No one security layer by itself is sufficient to properly protect our critical campus systems.
It is important to realize that some of the practices described in this guideline can have significant start-up and implementation costs, most notably, system administrator time. But, in the long run, these practices provide a framework that will actually save time and money as it provides for a robust and secure operating environment that can be more easily managed by some of the tools described below.
1. Minimal, secure installation of the (UNIX, Linux, Solaris) Operating System
To maximize security, the Operating System should be installed with the minimum packages needed to serve its intended function. The full OS includes many obsolete and unneeded software packages, some of which pose significant security risks. (UUCP, for example)
Once installed, the system needs to be hardened. At a minimum, this includes:
. Shutting down unneeded services
· Installing latest patch cluster
· Installing TCP Wrappers, Logdaemon, rpcbind and other security software
· Establish centralized logging
· Installing system integrity checking software (Tripwire)
· Enable process accounting
Services such as NFS, sendmail, RPC services, SNMP, NTP server, DNS server and dtlogin should be avoided unless absolutely necessary. Consider using system hardening scripts such as JASS, YASSP, Titan, and FixModes.
Mount filesystems with the ‘nosuid’ option where appropriate to help protect against inappropriate SUID and SGID programs from being installed outside of appropriate system areas.
Many UNIX operating systems offer some protection against buffer overflow attacks. Where possible, this should be enabled. (Under Solaris, this is the ‘noexec_user_stack’ option in /etc/system)
In general, do not multi-home systems to multiple networks. This is especially true in firewalled environments. Outside of firewalls where multi-homing is required, make sure that your system cannot be used as a router between the two network segments. Additionally, protect against TCP session hijacking by generating network sequence numbers securely (TCP_STRONG_ISS=2).
All servers containing confidential data should have managed firewall protection.
2. Secure patching methodology
Security patches should be installed within one week of release. This is where installing a minimal OS can be a big help as if the software isn’t installed, there is no reason to patch it. (I.e. UUCP) All patches are not created equal. Most are simply changes to a few system binaries. As such, no significant system changes are made and a reboot is often not needed. Typically, only patches that update the kernel or critical system libraries require a reboot or any significant testing. Consult the patch documentation for details. Patches other than security patches can be installed as needed or on a quarterly/biannually basis as appropriate.
3. Establish a centralized logging program
In addition to retaining a local copy of all logs, key system logs should also be forwarded to a highly secure central logging server. This provides a centralized audit point for all system activity and protects the logs from modification by hackers. The logging server needs to be highly protected with no server trust relationships. All passwords should be unique to the logging server. Use automated auditing tools like swatch or logwatch to send e-mail or pager alerts when security events occur. All root events (su to root, succeeded or failed) should generate alerts.
4. Establish a system auditing program
In addition to the automated system auditing provided by swatch or logwatch, critical systems should be monitored daily. At a minimum:
· Examine the process list for any unusual processes (ps)
· Examine the network connection table for unusual connections (netstat)
· Install ‘lsof’ and ‘top’ and monitor for unusual system activity
· Ensure backups complete successfully
· Examine system logs for unusual activity
· Examine the system integrity report for unauthorized system changes
On a quarterly or semester basis:
· Run nmap to ensure only authorized services are open
· Audit all system accounts
· Run detailed integrity checks (root kit checks)
· Install patch clusters (security patches should already be applied)
· Attempt to crack all user passwords
Audit firewall rules on a yearly basis.
Use NTP on each system to synchronize system clocks to ensure that all logging is based on accurate times. Use ‘ntp1.sdsu.edu’ and ‘ntp2.sdsu.edu’ as the authoritative campus time servers.
5. Install system integrity software
Detecting any unauthorized changes to the system is critical in identifying a potential system compromise and minimizing the damage to the system and data. It can also be quite useful as a general practice to help debug system changes and changes made by patches. System integrity software such as Tripwire, AIDE, or Samhain, do a cryptographic checksum of all system files and can immediately detect any additions, deletions or changes to critical system files.
6. Observe proper account and root access practices
User accounts and passwords tend to be one of the weakest links in system security. As such, all access, especially root access needs to be tightly controlled.
· Access to the root password should be strictly on a need to know basis.
· There should be no direct root logins. All root access should be via ‘su’ using the root password. This includes all console access except in single user mode. The root user should not run a windowing environment or compile software. Root access should be used only as required for the task at hand, not as a default.
· Consoles in the computer room should not stay logged in to the system unless an automatic locking screensaver is used.
· Sudo or RBAC use should be limited to a few safe, individual commands that need to run with root privilege as required by regular users. Using sudo for unlimited root access is strictly prohibited.
· Install the logdaemon package which provides versions of the ‘su’ and ‘login’ commands that typically offer much better logging than the standard UNIX commands.
· Consider installing a custom root shell that logs every command done as root. This is an excellent practice that provides an audit trail for all changes made to the system.
· Consider using a full system auditing package. (BSM under Solaris, for example) These can be configured to provide a full audit trail for all users, but for the root user in particular.
· All user accounts must be unique. No account sharing unless absolutely required by the application.
· Password cracking software should be run at least on a semester basis. Better yet, install ‘npasswd’ which will enforce secure password choices.
· Passwords should be changed every 3-6 months and must be 8 characters in length. (Longer if the OS supports it.)
· Inactive login sessions should be logged out after an appropriate time period. Automatic locking screensavers should be used where appropriate.
· All system access (especially system administrators) should be through secure means such as SSH, scp, sftp, or SSL encrypted web access. Use port forwarding, especially X-Windows forwarding only when absolutely necessary and only between fully trusted hosts. Always forward X through SSH and never through setting the $DISPLAY variable. Under no circumstances should X-Windows forwarding be enabled when connecting to a less secure server outside of your primary security zone.
· Ensure that umask settings are appropriate so that all files created by users (including root) are not publicly readable by default. This prevents confidential data and sensitive information from being inappropriately accessible to other users of the system.
7. Enforce limited system trust relationships
Not all systems are created equal. Systems such as rohan and mail (or any other open system serving many users) are inherently less secure and introduce additional risk to the network than more closed systems that are behind firewalls, run limited and restricted applications, and have fewer users with restricted access.
As such, there should be absolutely no system trust relationships (logins, sharing system resources, etc.) established from a less secure system to a higher security system. This includes access to system administrator desktop systems that have privileged access to the Oracle systems. No passwords should be common to both systems. At a minimum, gold zone system passwords should be different from silver zone which should be different again from bronze zone which should be different yet again from systems outside the firewall such as mail. Consider a slightly different (but un-guessable) password for each and every system if at all possible.
Even among systems in the same zone, unless there is a specific need to log in directly from one system to another, you should block the connection. This greatly limits the exposure to other systems should one become compromised
Some security vulnerabilities can exist even when logging in from a high security server to a low security server (i.e. SSH with X-forwarding enabled) so it is best to avoid mixing access to different security levels as much as possible.
All remote access needs to be strictly limited and audited.
Systems used for security purposes (backup server, logging server) should be highly restricted with no passwords in common with other systems. Consider eliminating default routes to further limit access.
Since system administrators exchange sensitive information in e-mail, the use of less secure mail servers (i.e. rohan, off campus, etc) should be avoided.
8. Treat desktop systems as you would your servers
In order for a system administrator to do his job, he needs to have secure access to the systems he manages. This provides an opportunity to attack the servers though the privileged desktops. Desktop systems that routinely access secured servers should be protected by a managed firewall. System administrators should treat their desktops as an “administrative console” and severely limit personal use as much as possible. This includes:
· Non-work related web browsing should be avoided
· Non-work related software should not be installed
· Making sure all patches are installed
· Making sure anti-virus and spyware software is installed and up to date
· Systems should not be run as “root” or “administrator”
· No instant messaging software should be installed
· Access to the desktop system should be restricted as much as possible, preferably in a separate managed firewall zone, but TCP wrappers, personal firewalls, etc. may also be appropriate on a limited basis.
9. Monitor security mailing lists and other resources
Security is a rapidly evolving field and new alerts come out almost daily. To maintain proper system security, it is essential to closely monitor for security alerts that may affect your operating system or applications. This would include:
· Unix, Linux and Sun security and patch alerts
· Oracle security alerts
· Bugtraq (a good all-around security mailing list)
· Sdsu-cert and NAC-Security
· Microsoft Security bulletins
10. Utilize ITSO as a security resource
Part of the ITSO mission is to provide security consulting, auditing and training to the campus community. Both John Denune and Felecia Vlahos have many years of experience and can be an excellent resource to provide assistance, answer questions and provide auditing to help ensure campus systems are secure. We’re here to help and we encourage you to participate in campus security forums. We are happy to assist anyone wanting to implement any of the baseline standards discussed in this guideline.