Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
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.


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.


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.


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.


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.


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.


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.


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.

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.


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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020