Installing and securing Solaris 2.6 servers <http://www.cert.org/security-improvement/implementations/i027.02.html>

[Terrence Miao <t.miao@xxxxxxxxxxxxxxxxxx>]

Title: Installing and securing Solaris 2.6 servers

Home | What's New | FAQ | Site Contents | Contact Us | SEARCH

	About Us | Alerts | Events | Improving Security | Other Resources | Reports | Survivability Research | Training and Education

Implementation Details	Installing and securing Solaris 2.6 servers
	Applies to the practices:  "Keep operating systems and applications software up to date." "Offer only essential network services and operating system services on the server host machine." "Configure computer operating systems with appropriate object,device, and file access controls." "Identify and enable system and network logging mechanisms." "Configure computers for secure remote administration."  "Develop a computer deployment plan that includes security issues."  Applicable technologies: Solaris 2.6  Applicable scripts: saferm, safeinstallf
	This implementation contains the recommended procedure for installing and securing (i.e. hardening) a Sun Sparc server running Solaris Version 2.6. Section 2 contains the procedure for installing the operating system. Section 3 contains the procedure for hardening the OS. If the OS is already installed on the system to be hardened, skip to the hardening section.  We recommend that you install only the minimum essential operating system configuration, meaning only those packages containing files and directories that you need to operate your server. Sun provides many diverse packages to meet the functional needs of most organizations. Using these requires little or no additional effort beyond installing the operating system. This approach does not generally serve the needs of the security-conscious systems administrator. Even with the "Core System Support," which is the minimum configuration by default, there are many additional security changes that are desireable.  Our general approach to security is:  Remove all privilege and access and then only grant (add back in) privilege and access as needed. Enable as much system logging as possible.  When you perform these tasks, you will gain a much better understanding of how your system operates, and what constitutes abnormal operation. Using this knowledge and some additional tools, you can reduce the time required to administer your system. The more you know about your systems, the more able you are to detect problems and protect your organization's assets.  We provide time estimates when the amount of time needed to complete a task can be reasonably estimated or when the time is greater than five minutes. Our estimate does not include the time required for you to make decisions based on site-specific issues such as disk partition layout.  We've also written and included two scripts to keep the Solaris software installation database (/var/sadm/install/contents) consistent with the changes you make to your system. The first of these is saferm. We recommend that you use saferm instead of rm when you need to remove files and directories. Saferm uses removef to keep the installation database current.  The second tool is safeinstallf. It is a simple front-end for the installf program. We recommend that you use safeinstallf after making any file and directory changes, such as when you use chmod, chown, or change a configuration file.  References to the SANS Guide are taken from: Solaris Security Step By Step: A Survival Guide for Solaris Security, Version 1.0, The SANS Institute, 1999. Refer to http://www.sans.org for more information.
Solaris 2.6 installation	We strongly recommend that when you install Solaris 2.6 on a machine, you disconnect that machine from the network. Generally, the distribution CD contains packages that have vulnerabilities which are fixed by subsequent patches. If the machine being built is connected to the network during installation, it is possible for an attacker to exploit these vulnerabilities before you've had time to patch them.  Furthermore, we recommend that if you download any files from the internet, such as OS patches, you should use another machine which you know to be secure. The changes that you download should then be transported via tape (or some other secure manner) to the target machine.  Note: You need the following information before you begin the installation process:  IP Name  IP Address  Subnet Mask  Default Gateway  DNS Server  Domain Name  Time Zone  Boot Time Configuration Perform SANS Guide steps 1.1.1 to 1.1.8, Basic OS Installation.  With the exception of step 1.1.5, select "other".  Estimated time required: 10 minutes  Minimal OS Installation Perform SANS Guide steps 1.2.1 to 1.2.7, Minimal OS Installation.  With the exception of 1.2.4, also select "System Accounting"  Estimated time required: 30 minutes  File System Layouts  There is considerable debate about file system layout. Some choose to have one large file system mounted as /; others prefer the more traditional layout as suggested in the SANS Guide. There are arguments that support both; choose the layout that is best for your application.  Installed Packages Install only those packages needed target machine. Each additional package potentially introduces another vulnerability to the system.  System Accounting System accounting provides a log of all processes that run on the system. Unfortunately it does not log all available information (such as the pathname to the program executed) and is not as useful as it could be. However, it can be used to correlate events with other system logs. System accounting also gives you a better understanding of what processes run, when they run, and how long they run. You can use this information to determine if something abnormal is occurring on your system.
Solaris 2.6 hardening	We recommend that you install the system from scratch. We recognize that you may need to harden an existing system (and the following steps may be followed in either case); however hardening an existing system is a more difficult task.    If you are hardening a machine on which you have already installed Solaris, first remove all packages not needed for the operation of your server. The presence of any package not required for the services provided by the system reduces the security of the system. Estimated time required: > 1 hour, depending on how many packages are installed.  Note: Files and directories to be removed should be removed with saferm. You should run safeinstallf after changing any attribute of a file. Links to both scripts are found at the top of this implementation.     Verify that the file /etc/hostname.<interface> contains only the hostname of the machine in the appendix to this implementation. This is to verify the information that was given during the installation.    Verify that the file /etc/inet/hosts contains:           127.0.0.1             localhost           <IP address>     <hostname>            <IP address>   loghost If you have a central logging host, add an entry for it as well. See Configuring and using syslogd to collect logging messages on systems running Solaris 2.x". In this case, the file /var/inet/hosts should contain: 127.0.0.1                    localhost <IP address>              <hostname> loghost The /etc/inet/hosts file may contain other hosts on your network. For instance, the file /etc/nsswitch.conf contains:             hosts:   files dns.  This configuration prevents some DNS attacks on your system. The disadvantage of this approach is that for every host configured this way, you must make changes to keep the information consistent.      Verify that the file /etc/inet/netmasks conains:          <Network Number>     <Subnet Mask>  This step is performed to verify the accuracy of information that was given during the installation.      Perform SANS Guide steps 1.3.1 to 1.3.5, Post Install/Networking Configuration. Set a very secure password for the root account. Npasswd is a tool that can be installed and used to help set secure passwords. See "Installing, configuring, and using npasswd to improve password quality on systems running Solaris 2.x".  Estimated time required: 5 minutes      Perform SANS Guide steps 1.4.2 to 1.4.7, Installing Patches. Note: We have not had a problem with the unmodified patchadd script for Solaris 2.6 Hardware 3/98  Installing the latest patches from Sun protects the system from many vulnerabilities that have been discovered since the distribution CD was produced. If you fail to do this, the system that you have just installed is unnecessarily vulnerable to attack. There are many automated tools on the Internet that probe systems looking for known vulnerabilites.  Estimated time required: > 1 hour, depending on the number of patches to install.      Install Tripwire (See "Installing, configuring, and using Tripwire to verify the integrity of directories and files on systems running Solaris 2.x"). You can use Tripwire (for accounting purposes) to keep track of changes you make during this installation. With it, you can monitor the changes you make to files on the system during normal operation. This can give you more insight about how your system works. You can use this information to determine if something unexpected happened, meriting further investigation. Build Tripwire on a development machine that has a C compiler and transfer it securely to the target machine. We recommend that service machines not have compilers installed.      Install SSH (See "Installing, configuring, and operating the secure shell (SSH) on systems running Solaris 2.x"). SSH provides a more secure way of connecting and copying files to a machine. SSH should be built on a development machine that has a C compiler and transferred securely to the target machine. Service machines should not have compilers installed.      Perform SANS Guide step 2.1.1, Purging Boot Directories of Unecessary Services. Other run levels should not be used; remove them using saferm.     Perform SANS Guide steps 2.1.2 to 2.1.5 and 2.1.7, but remove the files with saferm instead of renaming them. For example: saferm S80PRESERVE  instead of:  mv S90PRESERVE . NOS80PRESERVE  Verify that these settings will not interfere with the normal operation of the machine. NFS and RPC services should be avoided because they have many vulnerabilities. Enabling these services opens the target system to attacks on well-known vulnerabilities of these services. Step 2.1.6 can be done if sendmail is invoked from cron; see also step 2.5.3.      Perform SANS Guide step 2.1.8 and 2.1.9. We recommend that the umask in step 2.1.8 be set to 027 and the system run for a time to determine if this change is practical in your environment. This change makes any file created by normal system operation not world-readable by default. If problems result, you should consider creating a group that contains a list of users who may need to read files created by system daemons.  Estimated time required: 10 minutes      Perform SANS Guide step 2.1.10. If you need DHCP or multicast support, do not replace the /etc/init.d/inetsvc file. Servers should not use DHCP. Attacks on DHCP servers may allow the host information for the service machines to be compromised.  If inetd services are needed, uncomment the inetd line at the end of the /etc/init.d/inetsvc file.  Remove all inetd services.    sed -e 's/^\([^#]\)/#\1/' < /etc/inetd.conf > /etc/inetd.new       mv /etc/inetd.new /etc/inetd.conf  Enable only the services that are required.  Estimated time required: If no inetd services are needed, < 5 minutes. If inetd services are needed, 10 minutes.      Perform SANS Guide steps 2.2.1 to 2.2.5, Cleaning House. If you need printing support, do not remove the lp user and related crontab entries. The printing subsystem may have vulnerabilities and should not be used on service machines.  If performance statistics are being collected using sar, do not remove the sys crontab entry. If inetd services are needed, skip 2.2.3.  Estimated time required: 10 minutes      Install TCP wrappers. See "Installing, configuring, and using tcp wrapper to log unauthorized connection attempts on systems running Solaris 2.x". If you are not installing any services in /etc/inetd.conf to be started by inetd, the TCP wrappers do not need to be installed.      If possible, perform SANS Guide steps 2.3.1 to 2.3.3, File System Configuration. Mounting the file systems as read only and nosuid preclude changes to files and programs that could result from unauthorized access or attempts to corrupt data. All file systems should be configured in this manner, if possible.  Estimated time required: 10 minutes      Set enhanced syslog logging: The end of the file /etc/syslog.conf should contain:  kern.debug              /var/log/all/kern.log  user.debug              /var/log/all/user.log  mail.debug              /var/log/all/mail.log  daemon.debug        /var/log/all/daemon.log  auth.debug              /var/log/all/auth.log  syslog.debug           /var/log/all/syslog.log  lpr.debug                /var/log/all/lpr.log  news.debug            /var/log/all/news.log  uucp.debug             /var/log/all/uucp.log  cron.debug             /var/log/all/cron.log  local0.debug           /var/log/all/local0.log  local1.debug           /var/log/all/local1.log  local2.debug           /var/log/all/local2.log  local3.debug           /var/log/all/local3.log  local4.debug           /var/log/all/local4.log  local5.debug           /var/log/all/local5.log  local6.debug           /var/log/all/local6.log  local7.debug           /var/log/all/local7.log  Note: The whitespace between the type and action must be created by using tabs only (for example, between lpr.debug and /var/log/all/lpr.log). The files listed as recipients of logging information (for example var/log/all/lpr.log) must exist before syslogd will write log information to them.  Configuring syslogd in this way allows the system administrator to examine the activities of each daemon that writes to that log level. The logs give you insight about how the system is working, and you can use them to determine if something unexpected is happening on the machine. This configuration generates a lot of information in the log files. Newsyslog should be modified to rotate the log files on a regular basis. (Refer to "Using newsyslog to rotate files containing logging messages on systems running Solaris 2.x") All logging information should be archived for later analysis.  See also "Configuring and using syslogd to collect logging messages on systems running Solaris 2.x ","Installing, configuring, and using swatch 2.2 to analyze log messages on systems running Solaris 2.x " and "Installing, configuring, and using logsurfer 1.41 on systems running Solaris 2.x".  Estimated time required: 10 minutes      Perform SANS Guide steps 2.4.3 and 2.4.4, Additional Logging. This log shows if someone is repeatedly trying to log into the system. Regularly examine this file, as well as the other log files. You can add these files to the /usr/lib/newsyslog to rotate this logfile.      Perform SANS Guide steps 2.5.1 to 2.5.3, Sendmail. If you do not want to replace the vendor-supplied version of sendmail, follow steps 2.5.2 and 2.5.3. Another option is to remove the -bd option to the daemon from the file /etc/init.d/sendmail. This denies incoming mail and protects the system from some possible vulnerabilities in the sendmail package. Some vulnerabilities may exist in the vendor-supplied sendmail package. These could be exploited.  Estimated time required: 10 minutes, if the Open Source package is already compiled.      Perform SANS Guide steps 2.6.1 to 2.6.5, Fix-modes script. Fix-modes is a script that tries to make the filesystem modes more secure. It does this by removing the group and world write permissions of all files, devices, and directories listed in /var/sadm/install/contents (with the exception of those listed in exceptions.h that come with the source distribution). Additionally fix-modes changes the ownership of most files to root and removes all write permission from non-root owned executables. Use the PGP utilities to verify the contents of the package after downloading from the Internet.      Perform the following steps in addition to (or in lieu of) the steps in the SANS Guide. Examine all file ownership and protections. There should be no world-writeable files on the system. Check for world-writeable files with the following:  find  /  -local  !  -type  l  -perm -0002 -ls >  /var/log/world-writeable-files  Examine setUID, setGID, and group-writeable to determine what files need to have these set.  find  /  -local  !  -type  l  -perm  -4000  -ls >  /var/log/suid-files  find  /  -local  !  -type  l  -perm  -2000  -ls >  /var/log/sgid-files  find  /  -local  !  -type  l  -perm  -0020  -ls >  /var/log/group-writeable-files  find  /  -local  !  -type  l  -perm  -0001  -ls >  /var/log/world-executable-files  Examine these results and restict file permissions as much as possible. Only programs that need to be setUID/setGID should be and all others should not be. Only programs that need to be group/world-executable should be, and all others should not be, etc. Document each change (or decision not to change) each file's permission and record your rationale. Tripwire can be used to track the changes made to the files. This task is time-intensive but necessary. Any changes that you make should be recorded in /var/sadm/install/contents with safeinstallf.      Perform SANS Guide steps 2.7.1 to 2.7.9, Miscellaneous. The EEPROM change is for physical security. No one can boot the machine with alternate media to get information from the machine.  The ftpusers file restricts the users listed in the file from using ftp to connect to the system. The scp command from the SSH package should be used as a secure way in which to transfer files instead.  If rlogin or rsh are needed, removing the entry from the pam.conf file causes rlogin and rsh to ignore the .rhosts and hosts.equiv files. Rlogin and rsh will then always require a password. Where possible, use SSH instead.  Estimated time required: 10 minutes      If possible, disable all remote commands with the following: saferm   /usr/bin/rcp saferm   /usr/bin/rdate saferm   /usr/bin/rdist saferm   /usr/bin/remsh saferm   /usr/bin/rlogin saferm   /usr/bin/rpcinfo saferm   /usr/bin/rsh saferm   /usr/bin/rksh saferm   /usr/bin/rup saferm   /usr/bin/ruptime saferm   /usr/bin/rusers saferm   /usr/bin/rwho  Removing all remote commands will protect the system from vulnerabilities in these programs.      Perform SANS Guide steps 4.1.1 to 4.3.3, Make a Backup, Physically Secure the Machine, and Provide Adequate Network Security Infrastructure. The physical security of the system is just as important (if not more so) as the security of the network. If an attacker has access to the physical machine, no amount of hardening will protect the data of the machine or its state.