The recommendations made in other Sun BluePrint OnLine articles apply to the Solaris OE configuration of the Sun Fire SCs. This article uses these recommendations and SC-specific security recommendations to improve the overall security posture of Sun Fire SCs by dramatically reducing potential access points to the SC and installing secure access mechanisms.
The recommendations for securing the SC follow closely with the hardening described in the "Solaris Operating Environment Security - Updated for Solaris 8 Operating Environment" Sun BluePrints OnLine article.
To improve the overall security posture of a Sun Fire 12K or 15K SC, we strongly recommend that you install all required patches for Solaris OE and SMS software. Refer to the "Solaris Operating Environment Security - Updated for Solaris 8 Operating Environment" article for instructions on how to incorporate patch installation with the Solaris Security Toolkit.
We made the following exceptions to the recommendations provided in the previously mentioned article, due to functionality that is required by the SC and supportability constraints:
The in.rshd, in.rlogind, and in.rexecd daemon entries listed in the /etc/inetd.conf are not disabled because the failover management daemon (fomd) requires them.
For fomd to effectively use the in.rshd, in.rlogind, and in.rexecd daemons, a /.rhosts file must be present on both SCs. This file contains the scman1 network hostname of the other SC and allows fomd to access the SC, as root, without requiring a password.
Beginning with SMS 1.2 and patch 112481-05, you can use Secure Shell as an alternative transport mechanism for fomd, removing the requirement for in.rshd, in.rlogind, in.rexecd, and /.rhosts on the SC. Using this alternative transport is strongly recommended. The use of any Secure Shell implementation is possible, although the examples in this article are based on OpenSSH running on Solaris 8 OE.
The remote procedure call (RPC) system startup script is not disabled because RPC is used by fomd.
The Solaris Basic Security Module (Solaris BSM) is not enabled. The Solaris BSM subsystem is difficult to optimize for appropriate logging levels, and its logs are difficult to interpret. This subsystem should only be enabled in those sites that have the expertise and resources to manage the generation and data reconciliation tasks required to use Solaris BSM effectively.
Solaris OE minimization of the SC is not described in this article.
The SC cannot be configured as a network time protocol (NTP) client.
The creation of user accounts and their associated privileges are not addressed in this article. Adding new users to an SC requires that the users be provided with privileges not only in the Solaris OE but also with SMS domain and platform privileges. Refer to the System Management Services (SMS) 1.2 Administrator Guide for instruction on how to define user access to the SMS software.