C H A P T E R  6

Security Guidelines

This chapter provides important information about securing the system controller, explains security recommendations for the platform and the domains, discusses domain separation requirements and domain minimization, and provides references to Solaris operating environment security.

The topics in this chapter are organized in these sections:

Securing the System Controller

Securing the system controller involves domain separation and hardening.

However, communication paths must exist between each domain and the SC so that the SC can provide

These communication paths have been constructed to enforce the separation of the domains and the SC, and to ensure that information cannot be leaked between domains and the SC or from one domain to another through the SC.

This chapter provides recommendations for hardening the platform and domains of midrange systems within the structure of domain separation.

Guidelines for Securing the SC

FIGURE 6-1 illustrates domain separation. In this illustration, a domain user is a person who is using the Solaris operating environment and does not have access to the system controller. The domain administrator is responsible for:

The domain administrator has access to the domain console and domain shell for the domain the administrator is responsible for. Also note in FIGURE 6-1 that the platform administrator has access to the platform shell and the platform console. If the platform administrator knows the domain passwords, the platform administrator also has access to domain shells and consoles. You should always set the domain shell passwords for each domain.

The following are security practices to consider:

 FIGURE 6-1 System With Domain Separation

Diagram that shows the different access controls for platform and domain administrators.

There are several configuration steps that can contribute to hardening your system. These steps are guidelines for system configuration:

For information about using the Sun Security Toolkit to create secure configurations for systems running the Solaris operating environment, refer to the following web site:


Securing the System Platform

This section describes the security features that you can implement at the platform level. Most of the platform administrator security settings are configured through the setupplatform command, which prompts you for your platform configuration. You can also run the setupplatform command in a mode that prompts you for specific subsets (parts) of the platform configuration, when you specify the -p option and the subset (part) required. The setupplatform command examples in this chapter use the -p option.

The platform security configuration checklist (see TABLE 6-1) identifies the setupplatform parameters and other tasks for securing the system platform. For detailed information on the setupplatform parameters involving system controller security, refer to the command description in the Sun Fire Midrange System Controller Command Reference Manual.

Note - As a precaution, after you complete the tasks identified in the platform security configuration checklist (TABLE 6-1) and also the domain security configuration checklist (TABLE 6-3), save your configuration with the dumpconfig command so that you can restore the platform and domain configurations.

TABLE 6-1 Platform Security Configuration Checklist

Setting or Task


Remote connection type

Select ssh as the connection type in the setupplatform command.

Note: If you use a network-based terminal server, use SSH to access the terminal server, ensuring that all communications with the server are encrypted.

See Selecting a Remote Connection Type.

Loghost configuration

Use different syslog facilities in the setupplatform command to distinguish between messages originating from the platform and from each domain.

See Configuring the Platform Loghost.


Use the default setting (SNMP disabled) in the setupplatform command, unless you need to use Sun Management Center software.

Note: If you use Sun Management Center software, keep the entire network from the SC to the Sun Management Center server physically isolated from other networks.

See Using the SNMP Protocol Default Configuration.


If the SC is configured for failover, use the SNTP parameter in the setupplatform command to synchronize system clocks.

See Setting the SNTP Protocol Configuration.

Set the platform password

Use a minimum password length of 16 characters (this can be a pass-phrase). Passwords should contain a mixture of uppercase, lowercase, numeric and punctuation characters.

See Defining the Platform Password.

Set hardware access ACLs

Use the platform administrator account only when initially assigning hardware components to the appropriate domains. After hardware assignments are complete, log into each domain shell account (as appropriate) to manage the hardware assigned to that domain.

See Defining Hardware Access Control Lists (ACLs).

Limit access to serial ports

Limit physical access to serial ports.

Reboot (if necessary)

See Rebooting the SC to Implement Settings.

Selecting a Remote Connection Type

The SSH and TELNET services on the SC are disabled by default. You can define the session idle timeout period that applies to all network connections to the SC. The default is no session idle timeout period. The SSH and TELNET configurations do not affect the operation of the platform console.

Refer to the setupplatform command description in the Sun Fire Midrange System Controller Command Reference Manual for details on how to configure timeouts.

Enabling SSH

If the SC is on a general purpose network, you can ensure secure remote access to the SC by using SSH rather than TELNET. SSH encrypts data flowing between host and client. It provides authentication mechanisms that identify both hosts and users, enabling secure connections between known systems. TELNET is fundamentally insecure because the TELNET protocol transmits information (including passwords) unencrypted.

Note - SSH does not help with FTP, HTTP, SYSLOG, or SNMPv1 protocols. These protocols are insecure and should be used cautiously on general purpose networks.

The SC provides limited SSH functionality, supporting only SSH version 2 (SSHv2) client requests. TABLE 6-2 identifies the various SSH server attributes and describes how the attributes are handled in this subset. These attribute settings are not configurable.

TABLE 6-2 SSH Server Attributes






SSH v2 support only



Listening port


Support multiple IP addresses



Port forwarding not supported



Public key authentication disabled



Public key authentication disabled



Password authentication controlled by the SC



Same SSH server implementation as the Solaris 9 Operating Environment



Same SSH server implementation as the Solaris 9 Operating Environment

procedure icon  To Enable SSH

If you use SSH as your remote access type, you can make as many as five simultaneous SSH connections to the SC.

1. To enable SSH, type:

schostname:SC> setupplatform -p network

You are prompted to enter the network configuration and connection parameters. For example:

schostname:SC> setupplatform -p network
Network Configuration
Is the system controller on a network? [yes]:
Use DHCP or static network settings? [static]:
Hostname [hostname]:
IP Address [xx.x.xx.xx]:
Netmask [xxx.xxx.xxx.x]:
Gateway [xx.x.xx.x]:
DNS Domain [xxxx.xxx.xxx]:
Primary DNS Server [xxx.xxx.xxx.xx]:
Secondary DNS Server [xxx.xxx.xx.x]:
To enable remote access to the system controller, select "ssh" or "telnet."
Connection type (ssh, telnet, none) [none]: ssh
Rebooting the SC is required for changes in the above network settings to take effect.
Idle connection timeout (in minutes; 0 means no timeout) [0]:

For detailed information on the setupplatform parameters, refer to the command description in the Sun Fire Midrange System Controller Command Reference Manual.

Features Not Supported by SSH

The SSH server on Sun Fire midrange systems does not support the following features:

If you try to use any of the above features, an error message is generated. For example, running the command

# ssh SCHOST showboards

generates the following messages:

Changing SSH Host Keys

It is good security practice for well-managed machines to get new host keys periodically. If you suspect that the host key might be compromised, you can use the ssh-keygen command to regenerate system host keys.

Host keys, once generated, can only be replaced and not deleted without resorting to the setdefaults command. For newly generated host keys to be activated, the SSH server must be restarted either by running the restartssh command or through a reboot. For further information on the ssh-keygen and restartssh commands (with examples), see the Sun Fire Midrange System Controller Command Reference Manual.

Note - You can also use the ssh-keygen command to display the host key fingerprint on the SC.

Configuring the Platform Loghost

You can monitor the SC by configuring the platform loghost to which all SYSLOG messages are forwarded. Starting with the 5.16.0 release, the firmware supports an enhanced-memory SC that offers some persistent storage for certain SC-generated message logs. However, it is strongly recommended that the SYSLOG messages be forwarded to a central location (off the platform) for storage, reconciliation, and review (for unusual activity) of all log messages. Due to the importance of the messages stored on the loghost, secure the loghost carefully and backup loghost message data regularly.

If DNS is not being used, define the loghost through its IP addresses.

In addition to specifying the name/IP address of the loghost, you can specify the facility level included in the SYSLOG messages. The SYSLOG protocol provides eight user-defined facility levels: local0 through local7, in addition to the 18 system-defined facilities. However, only the user-defined facility levels can be used while customizing the SYSLOG behavior of the SCs.

Because all SC-generated SYSLOG messages come from the same IP address--that of the SC, you can use the different SYSLOG facilities to distinguish between messages originating from the platform and each domain. For example, the platform could use the SYSLOG facility local0, while domain a could use the SYSLOG facility local1, and so on.

Using the SNMP Protocol Default Configuration

Simple Network Management Protocol (SNMP) is commonly used to monitor and manage networked devices and systems. By default, SNMP is disabled.

Note - The use of Sun Management Center software requires SNMP. However, since the SC does not support a secure version of the SNMP protocol, do not enable SNMP unless you must use Sun Management Center software.

Setting the SNTP Protocol Configuration

Simple Network Time Protocol (SNTP) is used to synchronize computer clocks. The default SC configuration for SNTP is off. In systems with redundant SCs, it is recommended that you configure it to on, so that time on the main SC and the spare SC can be synchronized.

If configured for SNTP, the SC sends a request to a designated SNTP or NTP unicast server and expects a reply from that server. The SC neither accepts remote administration commands via SNTP, nor does it accept any broadcast traffic.

For more information on SNTP, see Setting the Platform Date and Time.

Defining the Platform Password

The only restrictions on SC platform and domain passwords are the character set supported by ASCII and the terminal emulator in use. The SC uses the MD5 algorithm to generate a hash of the password entered. Correspondingly, all characters entered are significant.

A minimum password length of 16 characters promotes the use of pass-phrases instead of passwords. Passwords should be composed of a mixture of lowercase, uppercase, numeric, and punctuation characters. For information on how to set the platform password, see To Set a Password for the Platform.

Defining Hardware Access Control Lists (ACLs)

If your Sun Fire system has multiple domains and their resources are restricted in some way, you can benefit from implementing ACLs.

By default, all hardware present in the system is accessible to all domains. Use the platform administrator shell to assign the different CPU and I/O boards into the appropriate domains.

Note - ACLs only limit hardware assignments made while using the domain shells. Hardware assignments made while using the platform shell supersede all ACL definitions.

The capability of the platform shell to assign and reassign hardware components is not restricted by ACLs. You can use the platform administrator account initially only to assign hardware components to the appropriate domain. After you have assigned hardware components to each domain, the platform administrator should log into the appropriate domain shell account to manage the hardware assigned to that domain.

Hardware already assigned to a running domain is not removed if its ACL is modified to restrict it from being used in that domain. Therefore, it is important to assign hardware into domains as soon as it is available in the chassis and before domain administrators assign it.

procedure icon  To Define Hardware Access Control Lists

This procedure involves the showboards, showplatform, addboard, and setupplatform commands. For details on these commands, refer to their descriptions in the Sun Fire Midrange System Controller Command Reference Manual.

Note - Although a platform administrator can assign hardware into specific domains, it is up to domain administrators to use those resources appropriately and determine whether those resources are configured into a running domain.

1. Determine which boards are present in the system by running the showboards command from the platform shell on the main SC.

2. View the current set of ACLs defined on the system by running the showplatform -p acl command from the platform shell on the main SC.

3. For each board to be assigned to a specific domain, run the addboard -d domainID systemboard_name [...] command from the platform shell on the main SC.

For example:

schostname:SC> addboard -d a SB0 IB6
schostname:SC> addboard -d b SB2 IB8
schostname:SC> addboard -d a SB0 IB6

4. Review the board assignments by running the showboards command from the platform shell on the main SC.

The output should identify the boards assigned to the domains that you specified in Step 3.

5. Verify that the domains contain the assigned boards by running the setupplatform -p and showplatform -p acl commands from the platform shell on the main SC.

The output from these commands shows the ACLs defined for each domain in the system.

Rebooting the SC to Implement Settings

The SC needs to be rebooted if a console message similar to the following is displayed:

Rebooting the SC is required for changes in network settings to take effect. 

single-step bulletType reboot -y to reboot the SC

The SC can be rebooted while domains are up and running.

After rebooting the SC, use the showplatform -p command to validate that all the network modifications were implemented.

Securing the System Domains

This section describes the domain-specific security precautions that you can implement after making all the platform shell security configuration changes. The domain-specific security tasks include the following:

These modifications must be performed for each domain.

TABLE 6-3 identifies the setupdomain parameter settings and other tasks for securing system domains.

TABLE 6-3 Domain Security Configuration Checklist

Setting or Task


Set the domain password

Use unique passwords for each domain. Change passwords frequently.

See Defining Passwords for the Domains.

Loghost configuration

In the setupdomain command, provide separate Loghost definitions for each domain and platform shell to use separate SYSLOG servers for collecting information.

See Defining Domain Loghosts.

SNMP configuration

In the setupdomain command, specify different Public and Private Community Strings for each domain.

See Configuring Domain SNMP Information.

Set the virtual keyswitch

The recommended setkeyswitch setting for a running domain is secure.

See Configuring the Virtual Keyswitch for Each Domain.

Most of the recommended changes are performed using the platform shell. Only a few domain-specific changes require using domain shells. The examples in the following sections show the changes for domain a.

Defining Passwords for the Domains

Note - Make sure that you know who has access to the system controller. Anyone who has such access can control the system.

When you set up your system for the first time:

A domain shell is always present for a domain, whether any hardware is assigned to that domain. To prevent potential unauthorized reallocation of hardware to an unused domain, do the following:

You can set a domain password from either the shell of the domain or the platform shell with the password command.

For example, the following command sets the password of domain a from the platform shell:

schostname:SC> password -d a
Enter new password: xxxxxxxxxxxxxxxx
Enter new password again: xxxxxxxxxxxxxxxx

Note - All domain shells should have passwords set--regardless of whether they are used and have hardware assigned.

The same command, with the appropriate domain name, sets the passwords for domains b through d.

If a password was defined for either a platform or domain shell, the password command requires its entry before allowing a new password to be entered. The only exception is that the platform administrator can change a domain password without knowing the old password as follows:

schostname:SC> password -d d
Enter new password: 
Enter new password again: 

Note - You can reset domain passwords by doing a restore of a previously saved SC configuration, using the restoreconfig command. You can also reset domain passwords using the setdefaults -d domainID command (this resets all other configuration parameters to their default values).

Defining Domain Loghosts

To employ the Loghost facility, you must define a loghost for each of the domains individually. The configuration is similar to that described in the Configuring the Platform Loghost. By having separate definitions of loghost for each domain and platform shell, you can use separate SYSLOG servers to collect information. In the following example, only one system collects and parses the SYSLOG data. The facility option helps differentiate SYSLOG messages coming from the four different domains and platform shells.

Note - Unless you configure the Loghost facility properly, you will not have all of the data required for effective troubleshooting.

Before using the setupdomain command to define the loghost for each domain, log into the appropriate domain shell.

For example:

schostname:A> setupdomain -p loghost
Loghost [ ]:
Log Facility for Domain A: local1

In our example, the Loghost definition defines a facility of local1. Previously, the platform shell used local0. This example is specific to domain-a. Correspondingly, domain-b uses local2, domain-c uses local3, and domain-d uses local4.

Note - The domain shell definition of the Loghost does not affect where the SYSLOG messages generated by the Solaris operating environment for that domain are forwarded. Define the Solaris SYSLOG server in the /etc/syslog.conf file of the Solaris operating environment.

Use the showdomain command to display the Loghost and Log Facility for the domain:

schostname:A> showdomain -p loghost
Loghost for Domain A:
Log Facility for Domain A: local1

Configuring Domain SNMP Information

Each domain has unique SNMP configurations that must be configured separately. Some of the domain SNMP information can be the same (for example, domain contact and trap host); however, the public and private community strings must be different for the platform and for each domain. The platform and domain community strings also must be different from each other. Different public and private community strings are required so that each domain can be accessed separately. The two community strings provide the mechanism by which individual domains are accessed.

Note - For the purpose of security, you should select non-default values for SNMP community strings.

If you use SNMP management or monitoring, then you must select non-default SNMP community strings.

Configuring the Virtual Keyswitch for Each Domain

The Sun Fire midrange systems do not have a physical keyswitch. You set the virtual keyswitch in each domain shell with the setkeyswitch command. To secure a running domain, set the domain keyswitch to the secure setting. With the keyswitch set to secure, the following restrictions occur:

Use the setkeyswitch command to set the virtual keyswitch for a domain:

schostname:A> setkeyswitch secure

Additional Security Considerations

This section discusses

Special Key Sequences Allow RTOS Shell Access

Special key sequences can be issued to the SC, over its serial connection, while it is booting. These key sequences have special capabilities if entered at the serial port within the first 30 seconds after an SC reboot.

The special capabilities of these key sequences are automatically disabled 30 seconds after the Sun copyright message is displayed. Once the capability is disabled, the key sequences operate as normal control keys.

Because of the risk that the security of the SC could be compromised by unauthorized access to the RTOS shell, you should control access to the serial ports of the SC.

Domain Minimization

One way to contribute to the security of a Sun Fire midrange system is to tailor the installation of software to an essential minimum. By limiting the number of software components installed on each domain (called domain minimization), you can reduce the risks of security holes that can be exploited by potential intruders.

For a detailed discussion of minimization, with examples, see Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems (two-part article) available online at:


Solaris Operating Environment Security

For information on securing the Solaris operating environment, refer to the following books and articles: