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:

Securing the System Controller

Selecting a Remote Connection Type

Enabling Secure Shell

Solaris Operating System Security

Securing the System Controller

The SC runs independently of the host domain. The SC does not share any compute resources, such as RAM memory or persistent storage, with the host domain. The SC communicates to the host domain through dedicated hardware. The SC will never log in to the host domain. However, the SC 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:

Ensure that all passwords comply with security guidelines. For example, the host domain and the SC should have unique passwords.

Change your passwords for the platform and the host domain on a regular basis.

Scrutinize log files on a regular basis for any irregularities.

The following are configuration steps that contribute to hardening your system:

Implement security modifications immediately after updating the SC application firmware, and before configuring or installing the host domain.

Restrict access to the SC command shell.

Assign SC users specific permissions based on responsibilities.

Expect to reboot after certain configuration changes.

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 platform 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.

TABLE 2-1 Platform Security Configuration Checklist
Setting or Task	Recommendation
Remote connection type	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 SSH to access the terminal server, ensuring that all communications with the server are encrypted.
Set the SC password	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.
Set SC user permissions	Ensure that 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.
Limit access to serial ports	Limit physical access to serial ports.
Set idle session time-out	Set a time-out for an interaction session established over a serial connection or network connection (Telnet or SSH). See sc_clitimeout.
Reboot, if necessary	Changing certain configuration variables requires that a reset be done before they are effective. Ensure that a reboot is done, if necessary.

Selecting a Remote Connection Type

The SC defaults to DHCP enabled with the SSH protocol for remote connections. To establish an SSH session requires the admin password or a default, system-specific password based on chassis serial number. See Default DHCP Connection. 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.

Enabling Secure Shell

If the SC is on a general-purpose network, you can ensure secure remote access to the SC by using Secure Shell rather than Telnet. SSH encrypts data flowing between host and client. SSH 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 or Telnet protocols. FTP is used to download new ALOM CMT images. 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 2-2 identifies the various SSH server attributes and describes how the attributes are handled in this subset. These attribute settings are not configurable.

TABLE 2-2 SSH Server Attributes
Attribute	Value	Comment
Protocol	`2`	SSH v2 support only
Port	`22`	Listening port
ListenAddress	`0.0.0.0`	Support multiple IP addresses
AllowTcpForwarding	`no`	Port forwarding not supported
RSAAuthentication	`no`	Public key authentication disabled
PubkeyAuthentication	`no`	Public key authentication disabled
PermitEmptyPasswords	`yes`	Password authentication controlled by the SC
MACs	`hmac-sha1,hmac-md5`	Same SSH server implementation as the Solaris 9 Operating System
Ciphers	`aes128-cbc, blowfish-cbc, 3des-cbc`	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 eight simultaneous SSH connections to the SC.

Instructions to Enable SSH

See To Configure the Network Interface Variables.

Features Not Supported by SSH

The SSH server on ALOM CMT does not support the following features:

Remote command-line execution

scp command (secure copy program)

sftp command (secure file transfer program)

Port forwarding

Key-based user authentication

SSHv1 clients

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 messages:

On the SSH client:

Connection to SCHOST closed by remote host.

On the SC console:

[0x89d1e0] sshdSessionServerCreate: no server registered 
           for showboards
[0x89d1e0] sshd: Failed to create sshdSession

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 ssh-keygen and restartssh.

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

Solaris Operating System Security

For information on securing the Solaris Operating System, refer to the following books and articles:

Solaris Security Best Practices, available online at:

http://www.sun.com/security/blueprints

Solaris Security Toolkit, available online at:

http://www.sun.com/software/security/jass

Solaris System Administration Guide: Security Services in the Solaris System Administrator Collection for the Solaris OS you are using.