| System Management Services (SMS) 1.6 Administrator Guide |    
|
| System Management Services (SMS) 1.6 Administrator Guide |
|
| C H A P T E R 2 |
|
SMS 1.6 Security |
This chapter provides an overview of security as it pertains to SMS 1.6 and the Sun Fire high-end (E20K/12K and E25K/15K) systems. Security options consist of securing the domains (optional suggestion) and system controllers (strongly suggested) of a given system, as well as overall system hardening. Hardening is the modification of Solaris OS configurations to improve the security of a system.
These suggestions apply to environments where security is a concern, particularly environments where the uptime requirements of the system controllers or the information on the Sun Fire server is critical to the organization.
The system controllers control the hardware components that make up a Sun Fire high-end system. Because they are a central control point for the entire frame, the SCs represent an attack point for intruders. To improve reliability, availability, serviceability, and security (RASS), the system controllers must be secured against malicious misuse and attack. Overviews of domain and system controller security issues follow.
This chapter contains the following sections:
The Sun Fire high-end system platform hardware can be partitioned into one or more environments capable of running separate images of the Solaris OS. These environments are called dynamic system domains (DSDs) or domains.
A domain is logically equivalent to a physically separate server. The Sun Fire high-end system hardware enforces strict separation of the domain environments. This means that, except for errors in hardware shared by multiple domains, no hardware error in one domain affects another. For domains to act like separate servers, Sun Fire software was designed and implemented to enforce strict domain separation.
SMS provides services to all domains. In providing those services, no data obtained from one client domain is leaked into data observable by another. This is particularly true for sensitive data such as buffers of console characters (including administrator passwords) or potentially sensitive data such as I/O buffers containing client domain-owned data.
SMS limits administrator privilege. This enables you to control the extent of damage that can occur due to administrator error, as well as to limit the exposure to damage caused by an external attack on a system password. See Chapter 3.
Securing the system controllers is the first priority in configuring Sun Fire high-end systems to be resistant to unauthorized access and to function properly in hostile environments. Before securing the system controllers, it is important to understand the services and daemons that are running on the system. This section describes the software, services, and daemons specific to the system controllers. The functionality is described at a high level, with references to other Sun documentation for more detailed information. This section provides administrators with a baseline of functionality required for the system controllers to perform properly.
The system controllers (SCs) are multifunction system boards within the Sun Fire frame. These SCs are dedicated to running the SMS software. The SMS software is used to configure dynamic domains, provide console access to each domain, control whether a domain is powered on or off, and provide other functions critical to operating and monitoring Sun Fire high-end systems.
The following list is an overview of the many services the system controllers provide for the Sun Fire high-end systems:
Sun Fire frames have two system controllers. Our security suggestions are the same for both system controllers. The SC that controls the platform is referred to as the main SC, while the other SC acts as a backup and is called the spare SC. The software running on the SC monitors the system controllers to determine when to perform an automatic failover.
|
Note - For our sample configuration, the main SC is sc0 and the spare SC is sc1. |
We suggest that the two system controllers have the same configuration. This duplication includes the Solaris OS, security modifications, patch installations, and all other system configurations, as well as the same version of SMS software.
The failover functionality between the system controllers is controlled by daemons running on the main and spare system controllers. These daemons communicate across private communication paths built into the Sun Fire frames. Other than the communication between these daemons, there is no special trust relationship between the two system controllers.
Several network interfaces are used on an SC to communicate with the platform, domains, and other system controllers. Most of these interfaces are defined as regular Ethernet network connections through /etc/hostname.* entries.
A typical main SC (sc0 in our sample) has two files in the /etc directory with contents similar to the following:
# more /etc/hostname.scman0 192.168.103.1 netmask + broadcast + private up # more /etc/hostname.scman1 192.168.103.33 netmask + private up |
In addition, a typical main SC has corresponding entries in /etc/netmasks:
The /etc/hostname.scman0 entry sets up the I1 or domain-to-SC SMS Management Network (MAN). The first IP address in our example, 192.168.103.1, is controlled by the SMS software to be always available only on the main SC.
From a security perspective, misuse of or attacks on the I1 MAN network between the domains and the system controllers might adversely impact domain separation. The hardware implementation of the I1 network within a Sun Fire high-end chassis addresses these concerns by permitting only SC-to-domain and domain-to-SC communication. The I1 MAN network is implemented as separate point-to-point physical network connections between the system controllers and each of the 9 domains supported by a Sun Fire E20K/12K server or 18 domains supported by a Sun Fire E25K/15K server. Each of these connections terminates at separate I/O boards on each domain and SC.
On the system controllers, these multiple separate networks are consolidated into one meta-interface to simplify administration and management. The I1 MAN driver software performs this consolidation and enforces domain separation and failovers to redundant communication paths.
Direct communication between domains over the I1 network is not permitted by the hardware implementation of the I1 network. By implementing the network in this manner, each SC-to-domain network connection is physically isolated from other connections.
The /etc/hostname.scman1 entry is used to configure the I2 or SC-to-SC MAN. This network connection, on which both system controllers have an IP address, is for the heartbeat connections between the two system controllers.
Both of the I1 and I2 MAN network connections are implemented internally in the Sun Fire high-end chassis. No external wiring is used.
The spare SC has the same physical network interfaces as the main SC. The scman0 network interface is plumbed by the Solaris OS through the
/etc/hostname.scman0 file on the spare SC in the same manner and with the same information as on the main SC. The difference between the main and spare system controllers is that the interface is inactive on the spare. The spare system controller's scman0 port on the I/O hubs is disabled and mand does not provide path information to scman0 on the spare.
The scman1 interface, which is for SC-to-SC communication, has the following configuration information for this interface:
In addition, the spare SC has the following corresponding /etc/netmasks information:
Use the following command to verify the status of the main SC:
Our network configuration sample appears as follows on the main SC (sc0):
Our sample network configuration appears as follows on the spare SC (sc1):
Solaris Security Toolkit 4.2 software works with either Solaris 9 OS or Solaris 10 OS, and provides an automated, extensible, and scalable mechanism to build and maintain secure Solaris OS systems. Using the Solaris Security Toolkit software, you can harden and audit the security of systems.
Security options for a system using SMS 1.6 depends on whether the software is to be installed fresh or as an upgrade.
If the SMS version is a fresh installation, the smsinstall command is used and then automatic hardening is accomplished as a function of the installation (secure by default). That is, the system is hardened as the system controllers are made secure. In this instance the domains can also be made secure manually with Solaris Security Toolkit (SST) 4.2.0 software, which is downloaded as a function of the installation. If you are going to install SMS 1.6 fresh, proceed to Initial or Fresh SMS Installation Using smsinstall Command (Secure by Default).
|
Note - The minimum supported version of SST on Solaris 10 OS is 4.2.0. The minimum supported version of SST on Solaris 8 and 9 OS is 4.1.1. |
If the installation is an upgrade, automatic system hardening does not occur. In this instance, the smsupgrade command is used, Solaris Security Toolkit software is installed as a function of the upgrade and can then be used to harden, undo hardening, and audit the security posture of a system (secure by choice). This includes the system controllers as well as domains. For an upgrade to SMS 1.6, as well as post-SMS hardening procedures proceed to SMS Upgrade Installation Using smsupgrade Command (Secure by Choice).
A list of major changes that have occurred for installing SMS 1.6, regardless of which installation method is used, follows:
The suggestions herein are based on several assumptions and limitations as to what can be done to secure Sun Fire system controllers, resulting in a supported configuration.
Solaris OS hardening can be interpreted in many ways. For purposes of developing a hardened SC configuration, we address hardening all possible Solaris OS options. That is, anything that can be hardened is hardened. When there are good reasons for leaving services and daemons as they are, we do not harden or modify them.
You can customize a copy of the Sun Fire high-end servers SC module of the Solaris Security Toolkit to disable certain hardening scripts. It is strongly suggested that any modifications to the default modules be made in copies of those files, which will simplify upgrades to newer Solaris Security Toolkit versions.
|
Note - Standard security rules apply to the hardening of system controllers: That which is not specifically permitted is denied. |
Additional software that you can install on the system controllers, such as Sun Remote Services Event Monitoring, Sun Remote Services Net Connect, and Sun Management Center software has been omitted from this document. We suggest that you carefully consider the security implications implicit with the installation of these types of software.
The SC configuration for Sun Fire high-end systems implemented by the Solaris Security Toolkit software (sunfire_15k_sc-secure.driver) is a Sun supported configuration. A hardened SC is supported only if the security modifications are performed using the Solaris Security Toolkit.
In this instance, the smsinstall command is used to install SMS 1.6 software. Automatic secure by default will occur wherein the system controllers of a system are automatically hardened and made secure as a function of the installation process.
The Sun Fire 15K and 12K SC module sunfire_15k_sc-secure.driver performs hardening tasks. This Solaris Security Toolkit driver is implemented by default and disables all those services which can be disabled without adversely affecting SMS. A user can enable as many services as required, but cannot disable more services than were disabled by the SMS installation software.
You might determine that your system requires some of the services and daemons disabled by the Solaris Security Toolkit. To customize the Solaris Security Toolkit software to meet your particular requirements, see Customizing the Solaris Security Toolkit Driver.
An option also exists to further harden a system by securing the system domains as indicated in the following Sun BluePrints
Online articles available at:
http://www.sun.com/security/blueprints
In this instance, the smsupgrade command is used to install SMS 1.6 software. Automatic hardening by default is not accomplished. However, Solaris Security Toolkit software is installed as a function of the upgrade and can be used to manually harden, undo hardening and audit the security posture of a system
The following security options are available:
For systems where domain separation is critical, we suggest disabling IP connectivity between the SC and specific domains that require separation.
To implement securing the system controllers, refer to Using Solaris Security Toolkit to Secure the System Controller. To implement the optional securing of domains refer to the following Sun BluePrints Online articles available at:
http://www.sun.com/security/blueprints
To effectively secure system controllers, changes are required to both the Solaris OS software running on the system controllers and the configuration of the Sun Fire high-end platform. Customized modules added to Solaris Security Toolkit software simplify the Solaris OS installation and deployment of these suggestions. These modules automate the implementation of the security suggestions.
Solaris Security Toolkit software is always being updated. Solaris Security Toolkit version 4.2 is downloaded as a function of the smsupgrade command. However, to ensure you have the latest version of Solaris Security Toolkit when you are installing SMS, see the following web site:
http://www.sun.com/security/jass
If you download a later version, install it to the Bundled_Products directory of the SMS zip file, replacing the old package with the same name. You must decompress the Solaris Security Toolkit packages after downloading them.
|
Note - For instructions on installing the Solaris Security Toolkit packages manually, refer to the Solaris Security Toolkit Installation Guide. |
|
Note - Disable failover before hardening either of the system controllers. Re-enable failover only after both system controllers are hardened and tested. |
|
Note - Configuration modifications for performance enhancements and software configuration are not addressed by the Solaris Security Toolkit. |
Version 4.2 of the Solaris Security Toolkit software is included as a part of the SMS zip file as a function of the smsupgrade command and installed on the system controllers. Informational messages show the progress of the installation of Solaris Security Toolkit, and advise users to use the Solaris Security Toolkit software to automate installing other security software and implementing the Solaris OS modifications for hardening the system controllers.
If the SC already has a version of Solaris Security Toolkit installed, smsupgrade will abort before installing SMS packages and ask users to save any Solaris Security Toolkit customizations, if any, and remove the old Solaris Security Toolkit package before reinvoking smsupgrade.
You might determine that your system requires some of the services and daemons disabled by the Solaris Security Toolkit, or you might want to enable any of the inactive scripts available in the Solaris Security Toolkit.
To enable various other services on the SC to customize the hardening, refer to Chapter 7 of the Solaris Security Toolkit Administrative Manual. If there are some services that must remain enabled, and the Solaris Security Toolkit automatically disables them, you can override the defaults.
To prevent the toolkit from disabling a service, comment out the call to the appropriate finish script in the driver. For example, if your environment requires Network File System (NFS)-based services, you can leave them enabled. Comment out the disable-nfs-server.fin and disable-rpc.fin scripts by appending a # sign before them in the copy of the sunfire_15k_domain-hardening.driver script.
For more information about Solaris Security Toolkit editing and creating driver scripts, refer to the Solaris Security Toolkit documentation.
Implementing any modifications to the system controllers requires modifying the files included with the Solaris Security Toolkit. The following procedures provide instructions for using some of these options.
|
Domain exclusion requires that you unconfigure domain network interfaces to be excluded from the I1 network configuration and then restart the mand daemon.
As user, specify NONE as the MAN hostname for the domain to be excluded.
#smsconfig -m I1 A Enter the MAN hostname for DA-I1 [ DA-I1 ]: NONE Network: I1 DA-I1 Hostname: NONE IP Address: NONE Do you want to accept these settings? [y,n]y #pkill -HUP mand |
|
|
Note - The Solaris Security Toolkit user.init file should be edited to contain any user-defined variables such as the following. |
For more information, refer to "Customizing the Hardening Configuration" in Chapter 7 of the Solaris Security Toolkit Administration Guide.
|
To view the contents of the driver file and obtain information about the Solaris OS modifications, refer to the Solaris Security Toolkit documentation available either in the /opt/SUNWjass/Documentation directory or through the web at:
http:/www.sun.com/security/jass
|
Each Solaris Security Toolkit run creates a run directory in /var/opt/SUNWjass/run. The names of these directories are based on the date and time the run is initiated. In addition to displaying the output to the console, the Solaris Security Toolkit software creates a log file in the /var/opt/SUNWjass/run directory.
The files stored in the /var/opt/SUNWjass/run directory track modifications performed on the system and enable the jass-execute undo feature.
To undo a single run or a series of runs, use the jass-execute -u command.
For example, on a system where two separate Solaris Security Toolkit runs are performed, you could undo the second run, as shown in the following example:
Refer to the Solaris Security Toolkit documentation for details on the capabilities and options available in the jass-execute command.
| System Management Services (SMS) 1.6 Administrator Guide | 819-4660-10 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.
To Disable I1 Traffic (Domain Exclusion)
