| Sun Fire Midrange Systems Platform Administration Manual |    
|
| Sun Fire Midrange Systems Platform Administration Manual |
|
| 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 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.
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:
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:
http://www.sun.com/security/jass
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. |
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.
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.
|
Same SSH server implementation as the Solaris 9 Operating Environment |
||
|
Same SSH server implementation as the Solaris 9 Operating Environment |
If you use SSH as your remote access type, you can make as many as five simultaneous SSH connections to the SC.
You are prompted to enter the network configuration and connection parameters. For example:
For detailed information on the setupplatform parameters, refer to the command description in the Sun Fire Midrange System Controller Command Reference Manual.
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
generates the following messages:
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. |
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.
Simple Network Management Protocol (SNMP) is commonly used to monitor and manage networked devices and systems. By default, SNMP is disabled.
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.
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.
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.
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.
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.
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.
The SC needs to be rebooted if a console message similar to the following is displayed:
Type 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.
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.
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.
|
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:
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.
schostname:A> setupdomain -p loghost Loghosts -------- Loghost [ ]: 192.168.100.10 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.
Use the showdomain command to display the Loghost and Log Facility for the domain:
schostname:A> showdomain -p loghost Loghost for Domain A: 192.168.100.10 Log Facility for Domain A: local1 |
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.
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:
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.
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:
http://www.sun.com/security/blueprints
For information on securing the Solaris operating environment, refer to the following books and articles:
http://www.sun.com/security/blueprints
http://www.sun.com/security/jass
| Sun Fire Midrange Systems Platform Administration Manual | 817-5243-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
Prom (OBP)
To Enable SSH