University of California, Riverside

Security



Unix


The Unix Operating System

We refer to all servers as UNIX servers whether they are purchased operating systems with vendor support such as Solaris, Red Hat or HP; or one of the Open Source varieties such as Debian, FreeBSD or the free Red Hat. Each of these operating systems has their own unique security vulnerabilities from an assortment of differing implementations as well as a multitude of applications and services. Before embarking on any of the following suggested steps, be sure a system backup or as a very minimum, a backup of key configuration files has been performed.

Hardening the Operating System

Common to all UNIX operating systems is the need to harden the system. This should be one of the first steps taken to ensure the safety and integrity of the system and data. These duties become even more critical should the server(s) contain protected data (http://cnc.ucr.edu/files/sec_bre2.pdf).

Solaris administrators can use the Solaris Security Toolkit to simplify and automate the process of securing Solaris Operating Systems. This toolkit is based on proven security best practices with practical experience and can be used to secure SPARC-based and x86/x64-based systems. Security downloads can be found at www.sun.com/download/index.jsp?cat=Security&tab=3.

Administrators of Red Hat (Fedora Core, Enterprise, and Numbered/Classic), SUSE, Debian, Gentoo, and Mandrake distributions, along with HP-UX can use the Bastille Hardening program. Bastille can also assess a system's current state of hardening, granularly reporting on each of the security settings with which it works. Bastille "locks down" an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise (http://www.bastille-linux.org/).

Hardening the operating system should include all of the following.

Patching

Patching is the most important thing to keep the server secure. Verify the system has all the latest vendor supplied security patches applied. Periodically review the system to ensure everything is up to date, and perform any necessary updates. Many OS vendors send e-mail to security mailing lists when new code is available or a new vulnerability is exploited - subscribe to those lists. Vendors make security related patches easily available over the web. Below are a few common UNIX OS sites:

Checklists are available for no charge at http://www.cisecurity.org/ for a variety of operating systems to assist in performing an audit on the server(s).

Services and Applications

One method to reduce the vulnerability footprint is to turn off unused and insecure services. If the server is new, carefully review all services enabled by default before connecting to the network. It is crucial to disable or remove services that are not used. Many times, there are similar but more secure methods to achieve the same functionality, like ssh instead of telnet. Limit the number of login attempts to exposed services. Below are some of the recommended services to disable or replace:

  • review inetd daemons - disable all services that are not in use and turn on inetd tracing.
  • telnetd (use ssh)
  • ftpd (use scp or sftpd)
  • shell/rsh (use ssh)
  • login/rlogin (use ssh)
  • rcp (use ssh)
  • tftp (if remote booting is not required)
  • finger
  • talk
  • rstatd
  • sadmind
  • nfs (if required use unpriviledged port range)

Adjust login banners to suppress system data and warn intruders. A review of vulnerabilities for operating systems, services and applications is available at the below web locations:

Accounts/Passwords

Good passwords are another one of those “can’t live without” security necessities. If an intruder manages to obtain a valid username/password, especially for a privileged account, the system is severely compromised. Most exploits’ primary goal is to gain access to the system to wreak havoc locally or in cyberspace. Monitor and review failed login attempts. Good password habits are a key ingredient in the server security mix. For Best Practices, Tips, and Techniques for passwords see http://cnc.ucr.edu/passwords/index.php?content=password/index.html. Whenever possible check for password's strength (e.g. PAM modules). Never use default passwords on the system.

The password file on the UNIX system also requires protection with proper user and file permissions. Use password file shadowing if available, as well as only storing MD5 encrypted passwords when possible. Every account should be traceable to an authorized user, have a good password or is locked and have an authorized shell including a valid home directory. Set specific permissions depending on how the account will be used. Periodic review of accounts verifying the account is still active should be performed. Disable anonymous accounts and allow only limited access to the root account. This could include disabling the root or other privileged accounts from incoming internet access.

Strong authentication and authorization are other ingredients for a secure system. Access Control Lists (ACLs) and/or Role Based Access Control (RBAC) should be used where applicable to manage role and permission relationships to server resources (object, role, permitted operations). Use of sudo or op to selectively enable root privileges for specific operations can also be incorporated to enhance security. Consider chroot jails or zones to allow very granular access to server files/devices/processes on supported operating systems. Servers should never use unencrypted authentication, provide unauthenticated email relays or unauthenticated proxy services. Servers found to be providing email relays may end up on an email black-list like CBL (http://cbl.abuseat.org/). Many systems worldwide subscribe to these types of lists, rejecting all email from those servers IPs reported to be providing email relays or SPAM.

Host and Network Firewalls

Firewalls are either host-based and reside that on the server, or are network based and reside between an organizational resources and the Internet. Host-based firewalls are included with most UNIX operating systems. Host-based firewalls can be very granular, allowing only authorized traffic to flow to/from the server. A network firewall can pass all network traffic originating from the protected department “Inside” network while blocking all traffic originating from the “Outside”. Both types of firewalls can “hide” the server from view. Network firewalls can not protect servers from attacks from within the protected area.

Firewalls cannot prevent every type of attack and can be difficult to configure. Determining which ports to leave open to allow traffic that IS wanted and which ports to block to filter traffic that IS NOT wanted can be a lengthy and tedious process. Be sure a periodic review of the firewall logs is performed as part of the server’s frequent administration duties. Use "nestat -an" or nmap to check for unknown open ports. If an organization does not have the resources to provide this protection, please see http://cnc.ucr.edu/security/firewalls.html for firewall assistance.

TCP wrappers can be controls to be wrapped around standard TCP services to provide additional security that is otherwise not available (clear text passwords in Telnet). It is primarily used to restrict inbound connections to a list of allowed IP addresses, providing very granular access to specific services.

Physical Security

Servers should be behind a locked door with access given only to authorized individuals. When there is no one working at the server console, the console session should be either logged out or locked so that a password is required to gain access. The server room should be arranged in a way that people outside the room cannot see the keyboard, thus seeing usernames and passwords. If an attacker gains physical access to the system’s console, then security is compromised.

System Logging

Logging mechanisms are another of the features included with UNIX as well as most add-on application packages. Enable logging for both failures and successes. The most common logging that should be enabled is:

  • inetd tracing
  • messages sent to syslog AUTH facility
  • /var/adm/loginlog
  • cron logging
  • system accounting (Consider enabling Process accounting at boot time)
  • alarms on critical system log files

Track changes to executable and system configuration files (check sums of important files) for unexplainable differences. Monitor executing processes for abnormal or suspicious behavior. Lastly, the most important step of system logging is frequent periodic review and/or automated analysis scripts generating alarms. Remember if a system is unfortunate enough to get broken into, good logs can be very helpful with the forensic investigation.

Backups

Backups can be the life-line back to an uncompromised system, recovering lost data or a baseline of the last working system before that a system upgrade or patch went bad. Servers with critical data should be backed up daily with incremental backups and weekly with full image backups. Depending on the criticality of the data and business impact if this data is not recovered should be evaluated (Disaster Recovery Plan), so steps can be taken to keep backups off-site and periodically rotated back into the schedule. Don’t forget to create the recovery CD and perform testing of the servers backup procedures booting from the recovery media.

More Information 

General Campus Information

University of California, Riverside
900 University Ave.
Riverside, CA 92521
Tel: (951) 827-1012

Department Information

Computing & Communications
Computing & Communications Bldg.

Tel: (951) 827-4741
Fax: (951) 827-4541
E-mail: helpdesk@ucr.edu

Footer