The release of the SPARC Enterprise M-class Servers includes a new generation of Service Processor (aka XSCF). As the M-Class Service Processor is new existing security-related Service Processors BluePrints and their security recommendations don't apply. The purpose of this blog is to provide additional background on the security capabilities of the M-Class Service Processor as well as suggestions on how it can be configured.
This first blog entry will provide some background on the design concepts and implementation of XSCF. Future blog entries will discuss other security capabilities and how they can be used.
Service Processors have typically been deployed on highly protected management networks. These management networks have been widely recommended as essential for a number of reasons. These include restricting access to management access points (aka service processors), segmenting network traffic, as well as allowing for the deployment of other network devices to provide capabilities which the management access points cannot provide. While there are valid arguments for organizations to deploy management networks those arguments should not be based on limitations in management access points or service processors capabilities.
Historically, the Service Processors included in Sun products have had their security capabilities and default configurations evolve significantly from initial release to end of life.
The Service Processor of the M-class Server changes this model by integrating Secure by Default and Secure in Operation capabilities into the architecture, design, and implementation of XSCP.
The simplistic view of Secure by Default implementation of XSCP can be illustrated through an nmap port scan. The output is as follows:
# nmap -p 1-65535 192.168.0.2
Starting nmap ( http://www.insecure.org/nmap/ ) at 2007-07-23 16:45 EDT
Interesting ports on 192.168.0.2:(The 65535 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
[no open ports found]
As this port scan illustrates no ports are enabled by default, not even those supporting encryption.
How to securely allow initial login to a device through a default account and password is always a challenge. Specifically, it is a Secure in Operation as well as a Secure by Default challenge. A default account and fixed password may be misused if not disabled explicitly by an administrator. Not only can these default accounts be readily guessed by malicious individuals their use makes it impossible to enforce accountability of system activities.
XSCP takes a different approach by not providing a fixed default password at all. In addition the initial setup process ensures that an administrator create accounts which should be uniquely with administrators.
Instead of a fixed password XSCP requires that the keyswitch on the system be physically moved several times within a certain time limit while pressing certain keyboard keys. This is in addition to only allowing this initial login to occur over the serial connection on the Service Processor. If this is possible then the individual attempting to login has physical access to the device and can be safely allowed to login. For example, after entering "default" during initial login the keyswitch will have to be moved from the Locked position to Service, the return key pressed, wait 5 seconds, move the keyswitch back to Locked, and then press the return key again.
The goal of this process is to provide our customers with a system that cannot be subverted if left connected to a network and/or serial concentrator prior to being fully configured.
During the initial configuration process of the XSCP the administrator will be asked questions regarding which services should be enabled. It is strongly recommended on that only encrypted services such as SSH and HTTPS be enabled. XSCP does support non-encrypted protocols such as telnet, SNMPv1, and others. As always, decisions on which services to enable should be considered very carefully.
In the next article I'll discuss the more of the security-related initial configuration options as well as other Secure by Default and Secure in Operation capabilities.
Comments/suggestions welcome!
Alex: do you by any chance have the Service Manual on the M5000, as you may be aware no pdfs are available from dlc.com
Any help in this regard would be much appreciated.
Posted by Faraz on February 04, 2008 at 04:26 PM EST #