Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Background Information
The following sections provide helpful information for understanding the SC, MSP, hardware and software requirements, and other topics. This section contains the following topics:
- "Assumptions and Limitations"
- "Obtaining Support"
- "System Controller (SC)"
- "Midframe Service Processor (MSP)"
Assumptions and Limitations
In this article, our recommendations are based on several assumptions and limitations as to what can be done to secure a Sun Fire system controller (SC) using a midframe service processor (MSP) configuration.
Our recommendations assume a platform based on Solaris 8 Operating Environment (2/02), version 5.13.0 of the SC application, and version 23 of the SC Real Time Operating System (RTOS).
Solaris Operating Environment (Solaris OE) hardening can be interpreted in many ways. For purposes of developing a hardened MSP configuration, we address hardening all possible Solaris OE options. That is, anything that can be hardened is hardened. When there are good reasons for leaving services and daemons as they are, we do not harden or modify them.
NOTE
Be aware that hardening Solaris OE configurations to the level described in this article may not be appropriate for your environment. For some environments, you may want to perform fewer hardening operations than recommended. The configuration remains supported in these cases; however, additional hardening beyond what is recommended in this article is not supported.
The recommended Solaris OE cluster is End User. While it would be possible to install the MSP with significantly fewer Solaris OE packages, it is not a supported configuration. Only Solaris OE hardening tasks described in this article are supported configurations for the MSP.
NOTE
Standard security rules apply to hardening Sun Fire SCs and MSPs: That which is not specifically permitted is denied.
When addressing security of the MSPs, we focus on MSP functionality inherent in or required by MSP servers. We do not address security for non-MSP servers running Solaris 8 OE. For recommendations on generic Solaris OE security configuration, refer to other sources such as the security-related Sun BluePrints OnLine articles.
In this article, we omit additional software that you can install on the MSP, such as SunSM Remote Services Event Monitoring, Sun™ Remote Services Net Connect, and Sun™ Management Center software.
Qualified Software Versions
The configuration discussed in this article has the following software installed.
System Controller
SC application version 5.13.0
SC Real Time Operating System (RTOS) version 23
Midframe Service Processor
Solaris 8 OE (2/02) installed with the End User Cluster
Latest Security and Recommended Patch Cluster from SUNSOLVESM ONLINE Web site
OpenSSH
Solaris Security Toolkit version 0.3.6
FixModes software
MD5 software
NOTE
The use of Solaris 9 OE and its bundled version of Solaris™ Secure Shell is supported for use on the MSP.
Minimum MSP System Requirements
We cannot make specific recommendations of the hardware requirements because they depend extensively on the number of SCs supported by an MSP, in addition to the software being run on the MSP. For example, if the MSP is running only the software described in this article for several SCs, then a system such as the Netra™ T1 server would be recommended. Alternatively, if the MSP is running additional monitoring and management software for several hundred SCs, then a significantly larger server would be recommended.
The minimum hardware and software recommended for an MSP is as follows:
Sun4U™ architecture
8-GByte disk
128-MByte RAM
CD-ROM drive
SunSwift™ card or, ideally, a Sun Quad FastEthernet™ card
Solaris 8 OE
Performance and Storage Requirements
The performance and storage requirements for the MSP depend on many variables. Based on the configuration in this article, a low-end Sun4U system such as a Netra T1, Ultra 1, or Ultra 5 systems, has the required performance.
Obtaining Support
The Sun Fire SC and MSP configuration implemented by the Solaris Security Toolkit module (sunfire_mf_msp-secure.driver) is a Sun supported configuration. A hardened MSP is supported by Enterprise Services only if the security modifications are performed using the Solaris Security Toolkit. Support calls to Sun Enterprise Services are handled the same as other cases.
NOTE
The Solaris Security Toolkit itself is not a supported Sun product. Only configurations created with the Solaris Security Toolkit are supported.
To obtain Solaris Security Toolkit support, use the Solaris Security Forum link at the following web site:
System Controller (SC)
The Sun Fire system controller (SC) is an embedded device built into the Sun Fire midframe chassis which runs a Real Time Operating System (RTOS). This embedded device runs an application called SCapp. The device has limited processing and memory resources and no local non-volatile read/write storage such as hard drives, other than two erasable programmable read only memories (EPROMs). Of these two EPROMs, one stores the RTOS while the other contains the SC application.
Additional information about the SC is available in the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
Currently, the SC does not support encrypted or strongly authenticated access and management mechanisms. All management traffic to the SC uses non-encrypted transport mechanisms such as TELNET, FTP, HTTP, and SNMPv1. These are insecure protocols and should not be transmitted across general purpose intranets. In secured environments with strict security policies requiring encryption and strong authentication, these non-secured protocols cannot be used. If these security recommendations are not observed, the SC is an extremely easy target for network-based attacks such as DoS, session sniffing, and/or hijacking.
Because only one password, belonging to the platform administrator, is needed to control the machine, it is critical that insecure protocols required to manage the SC be limited to a private and highly-secured network; referred to as the private SC network throughout the rest of this document. To limit these protocols to one network segment, a gateway system is needed to provide an access and control point. This gateway system should have at least two network interfaces. One interface connects to the private SC network, and the other to the general access intranet or management network.
This gateway system, referred to as the midframe service processor (MSP), is a server on which encrypted and strongly-authenticated management services (for example, SSH, IPsec, and SNMPv2usec) can be installed. Administrators log into the MSP using the encrypted protocols. The insecure and non-encrypted protocols should only be used on the private SC network. If the private SC network is built on physically separate network devices (for example, no VLANs) there is little exposure to network sniffing or other network-based attacks. The recommendations for the placement are built on top of the recommendations made in the Sun BluePrints OnLine article titled Building Secure N-Tier Environments.
Domain and SC Isolation and Communication
The Sun Fire midframe hardware architecture was designed to enforce strict separation between domains and limited communication between the domains and SC. However, there must exist a communication path between each domain and the SC so that the SC can provide a virtual console for each domain, access to the OpenBoot™ Prom (OBP), and a mechanism for services and daemons to communicate from the SC to the domains and domains to the SC. This communication path was carefully constructed to enforce the separation of domains and SC, and to ensure that information cannot be leaked between domains or from one domain to another through the SC. The following paragraphs provide additional information on how this communication path was designed and implemented to provide separation between the domains and SC.
The SP communicates with a domain and the domain with the SC via reading and writing to the static random access memories (SRAM) located on the Input/Output (I/O) and CPU boards.
The I/O board SRAM is accessible to CPUs in the domain through a PCI interface. Access to the SRAM on the CPU boards is provided by a local interface on those boards. It is not possible for a domain to use either of these mechanisms to access SRAM located on hardware in other domains. The SC is able to access all SRAMs in the Sun Fire midframe chassis over a separate hardware path called the console bus.
An entire SRAM is not dedicated to this communication channel. The SC specifies which SRAM and location within that SRAM is to be used during domain startup. Specifically, the SP provides this information to domain during its power on self test (POST) sequence. POST then passes this information to the OpenBoot Prom (OBP) which then passes it on to Solaris OE. In this way the SC is able to define the SRAM to be used and the portion thereof.
Before passing SRAM information to OBP, the SC is responsible for initializing the data structures to be used. Different data structures are used for the portions of SRAM used to communicate between the SP and POST, the SP on OBP, and the SP and Solaris. These different memory structures are referred to as mailboxes. These mailboxes provide a bi-directional communication path between the different components on the domain and SP.
By implementing inter-chassis communications, strict separation is maintained between domains on a Sun Fire midframe. In addition, communication to the SP is strictly limited and does not provide a general purpose connection that could be used to either compromise the SP or leak information through the SP to another domain.
Failover
System controller failover is described in the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
The configuration and operation of the SC for failover is not within the scope of this article. However, if the SC is configured for failover, then we recommend that you use SNTP for synchronization of the system clocks. Refer to "Use the SNTP Default Configuration" on page 20.
Terminal Server Usage
We strongly recommend that you use a terminal server that supports the use of SSH to encrypt sessions. This recommendation is made because the terminal server is not on the private SC network, but on the general purpose intranet. If Telnet is used to access the terminal server, then all passwords are passed over the general purpose network, in clear text. This insecure transmission defeats many of the security measures designed into the architecture. Terminal servers supporting SSH are available from Cisco Systems, Perle, and other vendors.
Special Commands for RTOS Shell Access
Two special commands can be issued to the SC, over its serial connection, while it is booting. These two key sequences, Control-A and Control-X, have special capabilities if entered at the serial port within the first 30 seconds after an SC reboot.
The Control-A key sequence displays an RTOS prompt. The Control-X key sequence performs a soft reboot of the SC. This soft reboot is similar to resetting from the OpenBoot PROM on Sun™ Enterprise servers.
NOTE
The Control-A and Control-X sequences are only accessible over the SC's serial connection. These special control sequences do not work from any Telnet connections to the SC.
The special capabilities of these key sequences are automatically disabled 30 seconds after the Sun copyright message is displayed. Once the capability is disabled, Control-A and Control-X operate as normal control keys.
The security of the SC could be compromised by unauthorized access to the RTOS shell. Access to the serial ports of the SC must be carefully controlled.
Interactive SC Power On Self-Test Mode
If you press the space bar while connecting through the network terminal server to the serial port of the SC, during the SC power on self test (SCPOST) process, the system enters an interactive mode. In this mode, the user has access to a variety of commands and options. No password is required to enter this mode.
Two commands available in the interactive SCPOST mode are peek and poke. The peek command allows a user to inspect the contents of SC memory. The poke command can alter the contents of SC memory. Thus, if a malicious user (who is knowledgeable of SC memory addresses) accesses the interactive SCPOST facility, the user could modify the SC platform and/or domain passwords.
This mode is only supported for Sun engineering staff use. End-user access and use of this mode is not supported and is strongly discouraged, because Sun Fire system components can be damaged while in this mode.
Engineering Mode
The platform administration shell can be operated in a special restricted mode known as Engineering Mode. Prior to patch 111346-02, this was referred to as Expert Mode. Engineering Mode is for use under guidance from Sun internal engineering staff, and is not supported for use under any other circumstance.
Access to Engineering Mode is protected by a password. These passwords are only good for a period of time. Passwords are generated internally by Sun on an as needed basis, and as such are not generally available.
NOTE
Improper use of Engineering Mode can damage hardware, override or change any aspect of SC behavior, and lead to breaches of platform security.
Service Mode
The platform administration shell can be operated in a special restricted mode known as Service Mode. This mode was introduced with version 5.13.0 of the SC application. Service Mode is for use by Sun service staff, and is not supported for use under any other circumstance.
Access to Service Mode is protected by a password. It does not share the same password as Engineering Mode, but the password management is similar. The password is only good for a period of time. Passwords are generated internally by Sun on an as needed basis, and as such are not generally available.
NOTE
Improper use of Service Mode can damage hardware, override or change aspects of SC behavior, and lead to breaches of platform security.
Write-Protect Jumper
The SC contains several erasable programmable read only memories (EPROMs)—one of which contains the RTOS image. This EPROM is associated with a write-protect jumper (labeled J1303). The jumper has two positions, write-protect and write-enable. The factory setting for this jumper is the write-enable position. The jumper is bridged in the write-enable position.
In the write-enable position, the RTOS image can be updated using the flashupdate command.
Some organizations may have security policies that require a high degree of protection against the risk of improper access to the RTOS. Where such a requirement exists, you can use the write-protect jumper to provide protection.
In the write-protect position, the following features are disabled:
flashupdate
Control-A and Control-X commands
peek and poke commands in interactive SCPOST mode
Be aware of the following special considerations for using the write-protect jumper:
To change the position of the write-protect jumper, the SC must be removed from the chassis. Only trained personnel are allowed to perform this procedure.
When updates are required for the RTOS, it is necessary to power down and remove the SC to change the jumper configuration both before and after the RTOS update.
During an RTOS update, while the EPROM is not write-protected, appropriate measures must be taken to avoid unauthorized access to the console serial port.
It is recommended that the platform be configured with a redundant SC, using the SC failover feature to avoid Sun Fire frame downtime.
For instructions and additional information, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
Midframe Service Processor (MSP)
A midframe service processor (MSP) is a separate component that you can use to provide services to the Sun Fire SC. In addition to other services, these services include the following:
encrypted access point (for SSH, IPsec, or alternative)
SYSLOG server
flash update services
dumpconfig and restoreconfig services
secure choke point separating SC network traffic from general purpose intranet network traffic
We recommend that you configure the SC to use an external MSP server. For an example of the network topology of an SC and an MSP server, refer to FIGURE 1 on page 29.
){kind=link}
An SC can function without an external server such as the MSP, however, some SC functionality and monitoring capabilities are not available. These include flash updates to the SC EPROMs, SYSLOG message logging, and configuration backup through dumpconfig. These functions are critical to the ongoing maintenance and management of a Sun Fire platform.
Because the MSP is used as a secure access mechanism between general purpose networks and private SC networks, the MSP should not be used for any other tasks. For example, an MSP should not be given additional tasks as a general purpose NFS server.
NOTE
The MSP should be dedicated to the task of isolating and protecting the SCs from malicious network and user access.
The most secure MSP has the least software installed and the fewest services and administrator accounts. The more secure the MSP, the better the protection provided for the Sun Fire SC.
This recommendation does not mean that you cannot install additional software on the MSP. However, any additional software should be restricted to that which is required to monitor and/or manage the MSP. The MSP is a critical system because it controls access and the flow of information to and from the SC. The MSP should be managed based on the requirements of the organization. For example, in an enterprise where enterprise backup software is used to backup systems, it would be appropriate and prudent to install the required software on the MSP. Conversely, it is not a good practice to use the MSP as a general purpose web server. Evaluate the potential security impact of additional software to ensure that the overall security of the MSP is not adversely affected.
Mapping to Multiple SCs
Depending on the architecture of an environment, it may be desirable to support several SCs from one MSP. This configuration is recommended, from a security perspective, as long as all the systems (MSP and SCs) are within one administrative domain.
An administrative domain is a group of systems that are managed by the same or cooperating organizations, perform similar functions, and operate at similar security levels. For example, an administrative domain may include all the database servers in a data center. In this situation, one MSP, or a pair of MSPs, would be appropriate to manage as many of the Sun Fire database servers as needed. This administrative domain must not include the Internet-accessible web servers that access the database servers. Because the web servers are exposed to a significantly greater risk of misuse, they are in a different administrative domain and should be managed by a separate MSP.
Fault Tolerance
The MSP topology described in this article places the MSP as a single point of failure for accessing the SC over Telnet connections, storing SYSLOG files, and other functions of the MSP. Single points of failure adversely affect uptime and should be avoided wherever possible. Several options are available to mitigate some of the risks.
The simplest option is use IP multipathing (IPMP). This option provides link-level redundancy for failures in the network cables, network switch port failures, or a failure of the QFE card port. This option does not protect against more significant hardware failures on the MSP.
Additional redundancy can be obtained by having a cold spare available to replace the MSP if a serious failure occurs. This spare system would be fully configured as the MSP, or msp01 in this article; however, it would not be powered on. This configuration minimizes most of the downtime associated with fixing the primary system, because a replacement system is already configured and available; it just needs to be powered on when the failed system is powered off.
The most fault resistant configuration would be to cluster two MSPs. The clustering software could then automatically fail over the MSP services from one MSP server to the other in the event of a failure. To not lose access to log files, SYSLOG output, and other data files on the MSP, the two systems would have to share a disk subsystem. Obviously, while this system provides the highest availability, it is also the most complicated. Addressing how this type of a configuration could impact the security posture of the SC is beyond the scope of this article.