Securing Sun Solaris

Introduction
When configuring a Solaris system for production, a balance must exist between system manageability and security. It is necessary to determine the role the system will play in order to determine what services it needs to run. The objective is to keep things simple. By dedicating separate machines for different tasks, it is expected that only one or two services will run on a host. This methodology makes it easier to isolate applications, harden, and troubleshoot. This type of minimalist approach runs only what is absolutely necessary. Keeping a Solaris system secure is a daily task. This includes keeping up on exploits, patches, and reviewing log files. The following suggestions are the baselines to securing your Solaris system.

Secure System at Installation
Pre-Installation
Securing a Solaris system starts with the installation. This consists of an "initial" install of the latest version of the Solaris operating system. With every new release, Sun incorporates improvements and additional features to enhance system security.
Building a secure Solaris Operating Environment system involves installing a new system with the latest version of the Solaris Operating Environment and applying the latest patches.

�Always use the latest version of the Solaris Operating Environment that your applications will support.
�Do not perform an upgrade to an existing Solaris system. Since previous installation may have some inherited bugs or improper configuration or Trojans installed, etc which could lead to security flaws. Therefore it must be avoided if possible. Also, install the system from an original Sun Solaris Operating Environment CD to ensure a secure installation.
�Do not attach the system to a ?public? network until the modifications have been made. The machine should not be dependent upon resources from other machines (which could be compromised).

Partitions
Carefully select your partition sizes. The auto-layout tool typically doesn?t allocate enough space to critical partitions, particularly /var. A secure machine will have extensive system log capabilities enabled, so you need lots of log space. Before installing the Solaris operating environment, determine your disk space needs. Consider the following items:
�Solaris software group/cluster.
�Co-packaged software
See the co-packaged software documentation for estimated space required. Also, if you run Admintool to add the software to your Solaris system, the Add Software screen displays estimated package sizes if available.
�Vendor or third-party software
See the vendor or third party software documentation.
�Space for home directories
Home directories may store user files such as mail, text or data files, or application files.
�Allocate adequate disk space for system directories, log files, and applications.
Certain server applications or services may require extra disk space or separate partitions to operate effectively without impacting other services. Typically, there should be separate partitions for the root file system (/), /usr, /var, and /opt.

The Solaris Operating Environment /var file system contains system log files, patch data, print, mail, and files for other services. The disk space required for these files will vary over time. Most systems should maintain /var as a separate partition from the root file system. Mail servers should maintain a large, separate /var/mail partition to contain user mail files. These extra partitions will help prevent a full /var or /var/mail file system from affecting the operation of the system. Provide extra space in /var if you intend to store large log files. Most applications install themselves in /opt or /usr/local. Check the application installation directory location before allocating space.

Ensure Minimal Installation
The Solaris Operating Environment installation process requires the selection of one of four installation clusters:
�Core
�End User
�Developer
�Entire Distribution

Each installation cluster represents a specific group of packages (operating system modules) to be installed. This grouping together of packages into large clusters is done to simplify the installation of the OS for the mass market. Because each of these installation clusters contains support for a variety of hardware platforms (Solaris Operating Environment (Intel Platform Edition), microSPARC, UltraSPARC, UltraSPARC II, and so on) and software requirements (NIS, NIS+, DNS, OpenWindows, Common Desktop Environment (CDE), Development, CAD, and more), far more packages are installed than will actually ever be used on a single Solaris Operating Environment.
The Core cluster installs the smallest Solaris Operating Environment image. Only packages that may be required for any SPARC or Solaris Operating Environment (Intel Platform Edition) system are installed. The End User cluster builds on the Core cluster by also installing the window managers included with the Solaris Operating Environment (OpenWindows and CDE). The Developer and Entire Distribution clusters include additional libraries, header files, and software packages that may be needed on systems used as compile and development servers.

Installing unnecessary services, packages, and applications can severely compromise system security. One well-known example of this is the rpc.cmsd daemon, which is unnecessary on many data center systems. This daemon is installed and started by default when the End User, Developer, orEntire Distribution cluster is chosen during the installation process.
There have been many bugs filed against the rpc.cmsd subsystem of OpenWindows/CDE in the last few years and at least two CERT advisories (CA-99-08, CA-96.09). To make matters even worse, scanners for rpc.cmsd are included in the most common Internet scanning tools available on the Internet. The best protection against rpc.cmsd vulnerabilities is to not install the daemon.

It is important to reduce the Solaris Operating Environment installation down to the minimum number of packages necessary to support the application to be hosted. This reduction in services, libraries, and applications helps increase security by reducing the number of subsystems that must be disabled, patched, and maintained.

The initial installation should only include the Core Solaris Operating Environment cluster and a few other packages which contain critical functionality.

Note: However, the core system install will limit you to command-line administration because the graphical user interface (X Windows) is not installed with this option. There may also be other applications that will not work when only installing core system support. But if you should choose to install the Developers System Support, you should remove all packages that are unnecessary, such as UUCP.

Once the Solaris Operating Environment has been installed and patched, unneeded packages must be removed. The package removal process includes uninstalling/deleting of all packages not explicitly required by either the OS or the software package being installed.

Example: These are the final Solaris 7 Operating Environment package listing for an iPlanet Enterprise Servers operation after removing unnecessary packages
�system SUNWcar Core Architecture, (Root)
�system SUNWcsd Core Solaris Devices
�system SUNWcsl Core Solaris, (Shared Libs)
�system SUNWcsr Core Solaris, (Root)
�system SUNWcsu Core Solaris, (Usr)
�system SUNWesu Extended System Utilities
�system SUNWkvm Core Architecture, (Kvm)
�system SUNWlibC Sun Workshop Compilers Bundled libC
�system SUNWlibms Sun WorkShop Bundled shared libm
�system SUNWntpr NTP, (Root)
�system SUNWntpu NTP, (User)
�system SUNWswmt Install and Patch Utilities

The total disk space used for these twelve packages was less then 40 MBytes.

Note: This may not be appropriate for all installations. Different hardware architectures, environments, and software packages may require other packages.

Apply latest OS patches
Immediately after installation, install the recommended patch cluster. The patch cluster may contain kernel upgrades that require a system reboot. Upgrading the kernel early on will save you a reboot down the road (which may be an issue on mission-critical servers). You can ftp patches and patch clusters from ftp://sunsolve.sun.com/pub/patches. The recommended patch cluster will have a name similar to <OS Release>_Recommended. (tar.Z or zip)

Note: If you installed core system support only, your patch-installation script will try using an application that was not installed, resulting in a patch installation failure. You can fix this by running the following commands:
mkdir /usr/xpg4
mkdir /usr/xpg4/bin
ln -s /bin/grep /usr/xpg4/bin/grep

This will allow the patch installation script to use the default grep application. Sun has been notified of this problem, so it may be fixed in later versions.
Once downloaded, extract the cluster by issuing the following:

For .zip extension (Solaris 7 & 8):
#unzip 7_Recommended.zip

For .Z extension:
#uncompress <OS Release>_Recommended.tar.Z
#tar xvpf <OS Release>_Recommended.tar

Once extracted, you must cd to the created directory (which will be named <OS Release>_Recommended?) and run the patch installation script:

./install_cluster nosave

Note: That using the nosave option will prevent these patches from being "backed out" of the system this may be undesirable if you are unsure of the impact of the patch cluster on your system or the applications which run on it. You may omit this option, but installing the patch cluster without nosave may consume 20-30MB of space in the /var partition. Be careful not to fill up your /var partition, because this is where most of the system log data is written.

Patch cluster installation errors
You may see installation errors while installing patches or patch clusters this is not always a bad thing. Failure code 8 indicates the application to which the patch relates is not installed. Ignore these. Failure code 2 indicates the patch has already been installed. In both cases, there is little reason for concern.
However, if you receive any other failure codes indicating the patch was not successfully installed, your networks security status may still be vulnerable. In this event, read the patchs included README file (this should be reviewed regardless) for system requirements and consult Suns patch primer.

Note: Care must be taken when applying patches to a system. Some patches modify the system initialization scripts and may change the configuration of a system. Scripts that were deleted from the init run level directories to disable services should be replaced, enabling the service once more. Be sure to examine all system init scripts and test all patches on non-production systems to discover any such configuration changes.

Stand-alone security patches
Unfortunately, Sun does not put all security-related patches in the recommended patch cluster, so reviewing the available patches and being aware of security-related issues is still necessary.
Frequently view the PatchReport for your OS version release. Its available via ftp from: sunsolve.sun.com/pub/patches/Solaris<OS Release>.PatchReport. This report contains a section entitled Patches Containing Security Fixes.Review every patch listed to see if its applicable to your installation. When in doubt, download and attempt to install all of the listed security patches.
Accomplish package installation by using the patchadd command. When you install a patch, a copy of the old (vulnerable) binaries are saved in the /var directory. We recommend you use the -d switch to keep patchadd from making copies of the vulnerable binary. However, by the using -d option you lose the ability to uninstall the patches.

To install a patch, uncompress/unzip the patch in a temporary directory, and then run:

patchadd (-d) <patch directory>

For example:
patchadd -d 106944-02

Remove patch cluster from the tmp directory

#rm -rf ~/tmp/2.x_Recommended*

Note: Older Solaris releases (pre-2.6) use ?installpatch? instead of patchadd Be aware that installing patches can inadvertently turn on services that were previously disabled. Also, if you have replaced a standard Sun program with an open source version (such as Sendmail), it may be overwritten. Ideally you want to test the patch on a non-production unit without using the -d option. After successful testing, apply the patch using -d to the production servers.

Maintenance Updates (MU) are also available to service contract customers. They should be applied before the Recommended Patch Clusters.

Disable Unnecessary Network Services started at Boot-time
Ideally, each network service should be on a dedicated, single-purpose host. Many computers are configured by default to provide a wider set of services and applications than required to provide a particular network service, so you may need to configure the server to eliminate or disable them.
Offering only the essential network services on a particular host can enhance your network security in several ways:
� Other services cannot be used to attack the host and impair or remove desired network services. Each additional service added to a host increases the risk of compromise for all services on that host or for any computer trusting that host.
� Different services may be administered by different individuals. By isolating services so each host and service has a single administrator, you will minimize the possibility of conflicts between the administrators (also known as separation of duties).
� The host can be configured to better suit the requirements of the particular service. Different services might require different hardware and software configurations, which could lead to needless vulnerabilities or service restrictions.
� By reducing services, the number of logs and log entries is reduced, so detecting unexpected behavior becomes easier.

We strongly recommend that you use the configuration principle �deny first, then allow.� That is, turn off as many services and applications as possible and then selectively turn on only those which are absolutely essential.

Note: Consider the services, which are explicitly required for your environment. Because stopping a required service may lead to abnormal behavior of the system.

By default, Solaris installs and activates a wide range of frequently unneeded services. By disabling unneeded or unused services, you greatly reduce your system�s potential vulnerabilities. The system should always start with the least amount of necessary services possible. Service initialization is controlled by the scripts found in the �/etc/rc*.d� directories.
In the /etc/rc2.d directory you�ll see various scripts that begin with the letters �K� or �S�. Each script controls its service counterpart (i.e. S74syslog controls syslogd). All scripts beginning with the letter S are started at this run-level, while all scripts starting with the letter K are stopped (�K�illed). The number after the initial S or K specifies the order in which the scripts will be called.
Disabling scripts is as simple as renaming the specific �S� entries to �NOS� entries.

Note: However, that while renaming the script stops the service from starting at boot, if the service was already running it continues running until the system is rebooted.
You can stop services by calling the script with the �stop� parameter before you rename it, for example:
#/etc/rc2.d/S80sendmail stop

Note: This may not be appropriate for all installations. Different hardware architectures, environments, and software packages may require other boot time services.

Turn off services which are not commonly used
Disable the services which are not commonly required an are installed during a default installation.

cd /etc/rc2.d
for file in S30sysid.net S71sysid.sys S72autoinstall \
S73cachefs.daemon S93cacheos.finish S40llc2 \
S47asppp S70uucp S72slpd S75flashprom S80PRESERVE \
S85power S89bdconfig S90wbem S91afbinit S91ifbinit \
S94ncalogd S95ncad
do
[ -s $file ] && mv $file .NO$file
done

and

cd /etc/rc3.d
for file in S77dmi S80mipagent
do
[ -s $file ] && mv $file .NO$file
done

Renaming these scripts in the system boot directories will effectively disable a wide variety of infrequently used subsystems. The scripts are merely renamed (rather than removed outright) so that the local administrator can easily "restore" any of these files if they discover a mission-critical need for one of these services. Note that not all of the scripts listed above will exist on all systems (some are only valid for certain releases, others only exist if certain OEM vendor software is installed).

NFS server /client processes
A Solaris Operating Environment system can be an NFS server, NFS client, both, or neither. From a security perspective, the best option is to neither provide NFS services or accept them from any other systems. To disable all client and server NFS daemons the following startup scripts should be disabled on the system:
/etc/rc1.d/K65nfs.server
/etc/rc1.d/K80nfs.client
/etc/rc2.d/S73nfs.client
/etc/rc2.d/K60nfs.server
/etc/rc3.d/S15nfs.server
The Solaris Operating Environment uses a different set of startup files to enable NFS server or NFS client services.
There is no need to run the NFS server-related daemons on host that are not NFS servers. NFS is frequently exploited to gain unauthorized access to files and systems. Disable NFS scripts. Disabling these will prevent your system from exporting and mounting NFS shares.

mv /etc/rc3.d/S15nfs.server /etc/rc3.d/.NOS15nfs.server
mv /etc/rc2.d/S73nfs.client /etc/rc2.d/.NOS73nfs.client
mv /etc/rc2.d/S74autofs /etc/rc2.d/.NOS74autofs

RPC-based services
Remote Procedure Call (RPC) services are used in many UNIX services including: NFS, NIS, NIS+, and Kerberos. RPC services are also used by many applications such as Solstice Disk Suite software, SunCluster software, and others. All of these daemons and applications use the rpcbind daemon for converting RPC program numbers into universal addresses. When an RPC service is started, the service tells the rpcbind daemon the address where it is listening and the RPC program numbers it is prepared to serve. When a client wishes to make an RPC call to a given program number, it first contacts the rpcbind daemon on the server machine to determine the address where RPC requests should be sent. The rpcinfo command can be used to determine what RPC services are registered on a host.
RPC, by itself, can be used to provide an attacker with information about a system. While this may not be ideal, the real security problem is not the rpcbind daemon itself, but rather many of the services that use RPC. Many of these services do not make use of the stronger authentication mechanisms available to them and default to weak authentication. In particular, rpc.cmsd, sadmind (running without -S 2), and rpc.rexd use weak authentication by default. Network based attacks against these services pose a significant threat to the security of a server.
The RPC service is only required if,
� This machine is an NFS client or server
� This machine is an NIS (YP) or NIS+ client or server
� The Kerberos security system is in use at this site
� This machine runs a GUI
� The machine runs a third-party software application which is dependent on RPC support (examples: FlexLM License managers, Veritas, Sun Disksuite)

RPC-based services typically use very weak or non-existent authentication and yet may share very sensitive information. Unless one of the services listed above is required on this machine, best to disable RPC-based tools completely. If you are unsure whether or not a particular third-party application requires RPC services, consult with the application vendor.

mv /etc/rc2.d/S71rpc /etc/rc2.d/.NOS71rpc

The RPC daemons started in /etc/rc2.d and /etc/rc3.d are for rpcbind, keyserv, various naming services (i.e., NIS and NIS+), and are also used by both the client and server components of NFS. The keyserv daemon must be run when AUTH_DES is used for stronger host and user authentication. The use of NIS is not recommended due to its weak encryption and authentication models. NIS+ provides a much more robust security model.
The RPC protocol provides support for various authentication alternatives. These include:
� AUTH_NONE�No authentication.
� AUTH_SYS or AUTH_UNIX�Traditional UNIX-style authentication.
� AUTH_DES�DES encryption-based authentication.
� AUTH_KERB�Kerberos encryption-based authentication.

LDAP cache manager
If the local site is not currently using LDAP as a naming service, then there is no need to keep LDAP-related daemons running on the local machine.

mv /etc/rc2.d/S71ldap.client /etc/rc2.d/.NOS71ldap.client

Printer daemons
If users will never print files from this machine and the system will never be used as a print server by other hosts on the network, then it is safe to disable these services. The Unix print service has generally had a poor security record�be sure to keep up-to- date on vendor patches.

mv /etc/rc2.d/S80lp /etc/rc2.d/.NOS80lp
mv /etc/rc2.d/S80spc /etc/rc2.d/.NOS80spc

Volume manager
The Solaris volume manager automatically mounts CD-ROMs and floppy disks for users whenever a disk is inserted in the local system's drive (the mount command is normally a privileged command which can only be performed by the superuser). Be aware that allowing users to mount and access data from removable media drives makes it easier for malicious programs and data to be imported onto your network.

mv /etc/rc2.d/S92volmgt /etc/rc2.d/.NOS92volmgt

Automount service
The automount service manages automated NFS mounts. The automount utility installs autofs mount points and associates an automount map with each mount point. The autofs kernel module monitors attempts to access these mount points and notifies the automountd daemon. The daemon uses the map to locate a file system, which it then mounts at the point of reference within the autofs file system. You can assign a map to an autofs mount using an entry in the /etc/auto_master map or a direct map.
In Solaris 2.6 and 7 Operating Environment, the automount software is packaged separately. By removing these packages, all automount functionality is removed from the system. The two packages, which include all the automounter functionality, are SUNWatfsr and SUNWatfsu. The file /etc/auto_master determines the locations of all autofs mount points.

By default, this file contains four entries:
# Master map for automounter
#
+auto_master
/net -hosts -nosuid
/home auto_home
/xfn -xfn

Ideally, it should be disabled since, not only does it run as a privileged daemon, but it also uses NFS and RPC. The automounter can be disabled by renaming the /etc/rc2.d/S74autofs file.

mv /etc/rc2.d/ S74autofs /etc/rc2.d/.NO S74autofs

Note: There are situations where the automount service is needed for its ability to mount and unmount file systems automatically. In particular, both NIS and NIS+ environments make extensive use of auto_home and auto_master maps to mount user home directories. In these situations, the configuration of the auto_master map should be carefully constructed to be as restrictive as possible. This can be done by using the standard NFS mount options.

CDE GUI service
The X Windows-based CDE GUI on Solaris systems has had a history of security issues. Never run any GUI-oriented service or application on a system unless that machine is protected by a strong network security infrastructure.

mv /etc/rc2.d/S99dtlogin /etc/rc2.d/.NOS99dtlogin

Sendmail/email server
Sendmail is used on a Solaris Operating Environment system both to forward and receive mail from other systems. Centralized mail servers should be used to receive email and not local servers. These local systems should, however, be able to generate email and forward it to other servers.
Ideally, a more secure Mail Transport Agent (MTA) should be used instead of the MTA bundled with the Solaris Operating Environment. The sendmail daemon, bundled with the Solaris Operating Environment, has been subject to numerous denial of service, buffer overflow, and misconfiguration attacks. Alternative MTAs have been developed with smaller and more robust code. These other MTAs are more security conscious and, if configured properly, compromise the security of the server less than sendmail.
It is possible to run a Unix system with the Sendmail daemon disabled and still allow users on that system to send email out from that machine. Running Sendmail in "daemon mode" (with the �bd command-line option) is only required on machines that act as mail servers, receiving and processing email from other hosts on the network.

mv /etc/rc2.d/S80sendmail /etc/rc2.d/.NOS80sendmail
cd /var/spool/cron/crontabs
crontab �l >root.tmp
echo '0 ****/usr/lib/sendmail -q' >>root.tmp
crontab root.tmp
rm �f root.tmp

Web server
Even if this machine is a Web server, the local site may choose not to use the Web server provided with Solaris in favor of a locally developed and supported Web environment.

mv /etc/rc3.d/S50apache /etc/rc3.d/.NOS50apache

SNMP Service
An attacker can use SNMP (Simple Network Management Protocol) to gain valuable information about the machine (such as information on network devices, current open connections, etc.) when SNMP uses default words, such as public or private, for the community word. If no community is specified, then the SNMP server responds to queries from any machine.
If you are using SNMP to monitor the hosts on your network, we recommend changing the default community string used to access data via SNMP. On Solaris systems, this parameter can be changed by modifying the system-group-read-community parameter in /etc/snmp/conf/snmpd.conf

mv /etc/rc3.d/S76snmpdx /etc/rc3.d/.NOS76snmpdx

Disable login: prompts on serial ports
By disabling the login: prompt on the system serial devices we make it more difficult for unauthorized users to attach modems, terminals, and other remote access devices to these ports. Note that this action may safely be performed even if console access to the system is provided via the serial ports, because the login: prompt on the console device is provided through a different mechanism.

To disable a service, edit the /etc/inittab file and place a comment character (�#�) in front of the line:
co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T sun -d /dev/console -l console -m ldterm,ttcompat
Or
Configure the system to not to display the login prompt utilizing Admintool. When setting up serial port information, start Admintool, and select Serial Ports from the Browse menu. Select a serial port from the Serial Ports window and then choose Modify from the Edit menu to bring up the Modify Serial Port window. This window provides access to the port templates and provides information on the port in three levels of detail�Basic, More, and Expert. To modify login prompts, select the More or Expert option from the Detail menu.
Login Prompt Shows the prompt displayed to a user after a connection is made.
Default ttya login:

It is recommended to remove the ttya login prompt.

Note: Make sure that you change the comment field so that other users know that you have changed the default values.