C H A P T E R 2 |
Security Guidelines |
This chapter provides important security guidelines. The practice of configuring a system to limit unauthorized access is called hardening. This chapter contains the following information:
The SC runs independently of the host domain. It does not share any compute resources, such as random-access memory (RAM) memory or persistent storage, with the host domain, except for the SCC. The SC communicates to the host domain through a hardware private serial bus for control data and another private serial bus for console traffic. The SC will never log in to the host domain; however, it does provide access to the host serial console port for user login, and it does log all console traffic.
The following are security practices to consider:
The following are configuration steps that contribute to hardening your system:
For information about using the Solaris Security Toolkit to create secure configurations for systems running the Solaris Operating System, refer to the following web site:
http://www.sun.com/software/security/jass
The server security configuration checklist in TABLE 2-1 identifies the setsc and setupsc command parameters and other tasks for securing the SC and host. For detailed information on the setsc and setupsc command parameters involving system controller security, see the command descriptions insetsc and setupsc.
Select ssh as the connection type in the setupsc command or setsc if_connection ssh. Note: If you use a network-based terminal server, use the Solaris Secure Shell (SSH) to access the terminal server, ensuring that all communications with the server are encrypted. |
|
Use a password length of 8 characters. Passwords should contain a mixture of uppercase, lowercase, numeric, and punctuation characters. See the Password Restrictions in password. |
|
Ensure SC user account permissions are aligned with the role of the user. A user account can be granted 4 permission levels. See Permission Levels in userperm. |
|
Set a time-out for an interaction session established over a serial connection or network connection (Telnet or SSH). See sc_clitimeout. |
|
Changing certain configuration variables requires that a reset be done before they are effective. Ensure that a reboot is done, if necessary. |
The SC is secure by default. All network services are disabled on all SC servers except for DHCP on Sun Fire V215, V245, and V445 servers. On servers where DHCP is enabled, the default remote connection type is ssh. To establish an SSH session requires the admin password or a default, system-specific password based on chassis serial number. See Default DHCP Connection (Sun Fire V215, V245, and V445 Servers). You can define the session idle time-out period that applies to all network connections to the SC. The default is no session idle time-out period.
If the SC is on a general purpose network, you can ensure secure remote access to the SC by using Solaris Secure Shell (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.
The SC provides limited SSH functionality, supporting only SSH version 2 (SSH v2) client requests. TABLE 2-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 System |
||
Same SSH server implementation as the Solaris 9 Operating System |
If you use SSH as your remote access type, you can make as many as four simultaneous SSH connections to the SC.
See To Configure the Network Interface Variables.
The SSH server on ALOM 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 showplatform |
generates the following message on the SSH client:
Connection to SCHOST closed by remote host. |
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 ssh-keygen and restartssh.
Note - You can also use the ssh-keygen command to display the host key fingerprint on the SC. |
For information on securing the Solaris Operating System, refer to the following books and articles:
http://www.sun.com/security/blueprints
http://www.sun.com/software/security/jass
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.