- Background Information
- Security Recommendations
- Securing the System Controller
- Verifying SC Hardening
- About the Authors
- Related Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security Recommendations
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 SCs and installing secure access mechanisms.
The recommendations for securing the SCs follow closely with the hardening recommendations described in the Sun BluePrints OnLine article titled "Solaris Operating Environment Security - Updated for Solaris 9 Operating Environment."
To improve the overall security posture of Sun Fire 12K or 15K SCs, 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 9 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 SCs 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) may require them.
For fomd to 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 an SC, as root, without requiring a password.
With SMS 1.2, either a .rhosts or .shosts file was required. For SMS 1.3, it changed to .remotesc file.
Beginning with SMS 1.2 and patch 112481-05, and continuing with SMS 1.3, 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 SCs. 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 the use of Solaris_ Secure Shell running on Solaris 9 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 SCs is not described in this article.
The SCs 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 SCs 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.3 Administrator Guide for instruction on how to define user access to the SMS software.