Home > Articles > Operating Systems, Server > Solaris

Securing the Sun Cluster 3.x Software

  • Aug 8, 2003
To provide a robust environment where Sun Cluster 3.x software can be deployed, very specific requirements are placed on the configuration of the Solaris Operating Environment (Solaris OE). This article describes how to secure the Solaris OE and the Sun Cluster 3.x software. Before the release of Sun Cluster 3.0 (12/01) software, no secured configurations were supported. This article includes updates for Sun Cluster 3.1 software.
Like this article? We recommend

Like this article? We recommend

Securing Systems with the Solaris ToolkitSecuring Systems with the Solaris Toolkit

Learn More Buy

Like this article? We recommend

Like this article? We recommend

Securing Systems with the Solaris ToolkitSecuring Systems with the Solaris Toolkit

Learn More Buy
This article describes how to secure the Solaris_ Operating Environment (Solaris OE) and the Sun_ Cluster 3 - Title Page

This article describes how to secure the Solaris_ Operating Environment (Solaris OE) and the Sun_ Cluster 3.x software. To provide a robust environment where Sun Cluster 3.x software can be deployed, very specific requirements are placed on the configuration of the Solaris OE. Before the release of Sun Cluster 3.0 (12/01) software, no secured configurations were supported.

By implementing the recommendations for the supported agents, you can increase the reliability, availability, serviceability, and security (RASS) of systems running the Sun Cluster 3.x software. These objectives are accomplished by securing the servers so that they are not as susceptible to attacks.

This article contains the following topics:

  • "Background Information" on page 2
  • "Securing Sun Cluster 3.x Nodes" on page 12
  • "Maintaining a Secure System" on page 25
  • "About the Author" on page 26
  • "Acknowledgements" on page 26
  • "Related Resources" on page 27

Background Information

This section contains the following topics:

  • "Assumptions and Limitations" on page 2
  • "Qualified Software Components" on page 3
  • "Support" on page 6
  • "Using the Solaris Security Toolkit Software" on page 6
  • "Solaris OE Defaults and Modifications" on page 6
  • "Sun Cluster Software Daemons and Services" on page 9
  • "Terminal Server Requirements" on page 10
  • "Node Authentication Options" on page 10

Assumptions and Limitations

In this article, our recommendations are based on several assumptions and limitations as to what can be done to secure Sun Cluster 3.x nodes using a Sun supported configuration. Our recommendations assume a platform based on Solaris OE version 8 or 9 and the Sun Cluster 3.x software. We use the Sun Cluster 3.1 software version in this article.

NOTE

Before the release of Sun Cluster 3.0 (12/01) software, no secured configurations were supported.

Solaris OE hardening can be interpreted in a variety of ways. For the purposes of developing a hardened server configuration, the recommendations in this article represent all of the possible Solaris OE hardening. That is, anything that can be hardened, is hardened. Things that are not hardened are not modified for the reasons described in this article.

Be aware that hardening Solaris OE configurations to the level described in this article might 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.

Minimizing the Solaris OE or removing Solaris OE packages to minimize security exposure is not a supported option on Sun Cluster 3.x nodes at this time. Only the hardening tasks described in this article are supported for Solaris OE systems with Sun Cluster 3.x software running supported agents.

NOTE

Standard security rules apply to hardening cluster nodes: That which is not specifically permitted is denied.

Qualified Software Components

The configurations described in this article have the following minimum software requirements:

  • Solaris 8 OE (2/02) software
  • Solaris OE packages and installation
  • Sun Cluster 3.1 software
  • Supported agents
  • ORACLE RAC and r* service limitations
  • Cluster interconnect links
  • Solstice DiskSuite_ software

The following subsections describe each of these components.

Solaris 8 OE

The use of Solaris 9 OE as the core OE for secured Sun Cluster 3.x nodes is supported.

However, this article is based on Solaris 8 OE (2/02). All of the hardening results presented in this article were produced on this version of the Solaris OE. Using versions other than Solaris 8 OE might produce results that are slightly different than those presented in this article.

Solaris OE Packages and Installation

Sun Cluster 3.x software requires only the Solaris OE End User cluster. It is strongly recommended that this Solaris OE cluster be used instead of the Entire Distribution.

Minimizing the number of Solaris OE packages installed directly reduces the number of services to disable, the quantity of patches to install, and the number of potential vulnerabilities on the system.

NOTE

This article neither addresses how to install the Solaris OE and Sun Cluster 3.x software, nor how to configure the cluster nodes.

Sun Cluster 3.x software allows you to automate the installation of the cluster and Solaris OE software through JumpStart_ software. Correspondingly, you can include the hardening steps performed by the Solaris Security Toolkit software in the JumpStart installation process. This article does not describe methods for integrating the hardening process documented in this article with JumpStart software. For information about this topic, refer to the Sun Cluster 3.x and Solaris_ Security Toolkit documentation.

Sun Cluster 3.x Software

All Sun Cluster 3.x versions support the hardened configurations described in this article.

Sun Cluster 3.x software provides mission-critical capabilities to an organization. While the Sun Cluster 3.x software addresses issues such as fault tolerance, failover, and performance, it is very important that the systems running Sun Cluster 3.x software are protected against malicious misuse and other attacks such as denial of service. The most effective mechanism for doing this is to configure the nodes in a cluster so that they protect themselves against attack.

Supported Agents

The most current listing of agents, and their corresponding software product versions, supported in a hardened configuration, is available in the Release Notes distributed with the Sun Cluster 3.x software. When determining the versions of supported software, refer to the Release Notes for the version of Sun Cluster 3.x software being used.

ORACLE RAC and r* Service Limitations

During ORACLE RAC installation, if an option is chosen to install RAC on all the cluster nodes, then ORACLE Installer uses rsh and rcp to copy files to other cluster nodes. Also, other ORACLE configuration tools (for example, netca) use rsh to modify configuration files on other cluster nodes.

NOTE

When using the Solaris Security Toolkit Sun Cluster 3.x driver, both rsh and rcp are disabled by default. These services are insecure and should not be left enabled on a secured cluster.

It is possible to install a cluster on each node and set up configuration files manually on each node, if an administrator does not want to change security settings.

In sites where the availability of rsh and rcp is critical, a secure mechanism provides the same functionality (equivalent to rsh, rcp: ssh, and scp) through the Secure Shell (SSH), if configured properly. These commands provide an encrypted and authenticated mechanism for ORACLE software to perform tasks on remote machines.

Configure SSH to permit remote login without passwords, then replace the system-provided rsh and rcp binaries with links to the SSH commands. In this way, you can provide secure rsh and rcp link functionality. This approach simplifies the installation and configuration of ORACLE RAC while still maintaining a secure posture.

Cluster Interconnect Links

It is critical to the overall security of the cluster that cluster interconnect links are kept private and are not exposed to a public network. Sensitive information about the health of the cluster and information about the file system is shared over this link.

We strongly recommend that these interconnects be implemented using separate and dedicated network equipment. From a security and availability perspective, we discourage the use of VLANs because they typically restrict packets based only on tags added by the switch. Minimal, if any, assurance is provided for validating these tags, and no additional protection against directed Address Resolution Protocol (ARP) attacks is gained.

Solstice DiskSuite Software

The configuration in this article assumes the use of Solstice DiskSuite software instead of VERITAS Volume Manager. If VERITAS Volume Manager is used, then the entries added by VERITAS to the /etc/inetd.conf file should be left enabled and the Solstice DiskSuite software entries disabled.

Support

The secured Sun Cluster 3.x software configuration implemented by the Solaris Security Toolkit suncluster3x-secure.driver is a Sun Microsystems-supported configuration for agents described in this document. Only Sun Cluster 3.x software implementations using the agents explicitly described in this article and referenced in the Sun Cluster 3.x Release Notes are supported in hardened configurations.

NOTE

Hardening Sun Cluster 2.x is not supported. Only agents listed in the Sun Cluster 3.x Release Notes are supported in hardened configurations when the hardening is performed based on the recommendations contained in this article.

For information on the supportability of the Solaris Security Toolkit, refer to its documentation.

NOTE

Sun Microsystems supports hardening Sun Cluster 3.x clusters whether security modifications are performed manually or through the use of the Solaris Security Toolkit software.

Using the Solaris Security Toolkit Software

The drivers described in this article are included in version 0.3.10 of the Solaris Security Toolkit software. We use this software to implement the hardening. Use this version, or newer versions, of the software when implementing the recommendations of this article. The Solaris Security Toolkit provides an error-free, standardized mechanism for performing the hardening process. Additionally, because it allows you to undo changes after they are made, we highly recommended that you use this software to perform the hardening process.

Solaris OE Defaults and Modifications

The Solaris OE configuration of a cluster node has many of the same issues as other default Solaris OE configurations. For example, too many daemons are used and other insecure daemons are enabled by default. Some insecure daemons include: in.telnetd, in.ftpd, fingered, and sadmind. For a complete list of default Solaris OE daemons and security issues associated with them, refer to the "Solaris Operating Environment Security: Updated for Solaris 9 OE" Sun BluePrints_ OnLine article.

This article recommends that all unused services be disabled. Based on the Solaris OE installation cluster (SUNWCall) typically used for a Sun Cluster 3.x node, there are over 100 recommended Solaris OE configuration changes to improve the security configuration of the Solaris OE image running on each node. While the SUNWCall Solaris OE cluster is typically used for cluster installations, only the SUNWuser cluster is required. It is strongly recommended that you limit the number of Solaris OE services and daemons installed by using the Solaris OE cluster that contains the fewest number of packages.

The typical hardening of a Solaris OE system involves commenting out all of the services in the /etc/inetd.conf file and disabling unneeded system daemons. All of the interactive services normally started from inetd are then replaced by Secure Shell (SSH). This approach cannot be used with Sun Cluster 3.x software.

The primary reason for this limitation is that volume management software requires several remote procedure call (RPC) services to be available. And, the Sun Cluster 3.x software installs additional RPC-based services.

Implementing these modifications is automated when you use the driver script suncluster3x-secure.driver available in version 0.3.10 of the Solaris Security Toolkit software.

Disabling Unused Services

The security recommendations in this article include all Solaris OE modifications that do not affect required Sun Cluster 3.x node functionality. Be aware that these modifications may not be appropriate for every Sun Cluster environment. In fact, it is possible that some of the services disabled by the default suncluster3x-secure.driver script will affect some applications. Because applications and their service requirements vary, it is unusual for one configuration to work for all applications. Therefore, the security modifications of each Sun Cluster environment may vary slightly based on the applications being run in that environment.

NOTE

Consider the role of a secured configuration in the context of the applications and services that the Sun Cluster 3.x software supports. The security configuration presented in this article is a high watermark for system security, because every service that is not required by the Sun Cluster 3.x software is disabled. This information should provide you with a clear idea of which services can and cannot be disabled without affecting the behavior of the Sun Cluster 3.x software.

Recommendations and Exceptions

Our recommendations for securing the server configuration consist of modifying recommendations made in the Sun BluePrints OnLine article "Solaris Operating Environment Security: Updated for Solaris 9 Operating Environment." We customize the recommendations to provide a configuration specifically for the supported agents.

The recommendations in this article improve the overall security posture of Sun Cluster 3.x nodes. This improvement is made by dramatically reducing access points to the Sun Cluster 3.x nodes and by installing secure access mechanisms. To streamline the implementation of these recommendations, we provide the Solaris Security Toolkit software, which automates many of the changes.

We made the following exceptions to the recommendations provided in the previously mentioned article, due to functionality that is required by the Sun Cluster 3.x software and support constraints:

  • RPC system startup script is not disabled, because RPC is used by volume management software.

  • Solaris basic security module (BSM) is not enabled. The BSM subsystem is difficult to optimize for appropriate logging levels and produces log files that are difficult to interpret. This subsystem should only be enabled at sites where you have the expertise and resources to manage the generation and data reconciliation tasks required to use BSM effectively.

  • Solaris OE minimization (removing unnecessary Solaris OE packages from the system) is not supported with Sun Cluster 3.x software.

Mitigating Security Risks of Solaris OE Services

Detailed descriptions of Solaris OE services and recommendations on how to mitigate their security implications are available in the following Sun BluePrints OnLine articles:

  • "Solaris Operating Environment Security: Updated for the Solaris 9 Operating Environment"

  • "Solaris Operating Environment Network Settings for Security: Updated for Solaris 8 Operating Environment"

The recommendations are implemented by the Solaris Security Toolkit in either its standalone or JumpStart modes.

Sun Cluster Software Daemons and Services

The Sun Cluster 3.x software adds several daemons and services to a system. These include daemons running on the system and additional RPC services. The following daemons run on a default Sun Cluster 3.1 software installation:

# ps -ef | grep cluster
root 4  0  0 Oct 25 ? 0:03 cluster
root 416 1  0 Oct 25 ? 0:00 /usr/cluster/lib/sc/rpc.pmfd
root 82  1  0 Oct 25 ? 0:00 /usr/cluster/lib/sc/clexecd
root 83  82  0 Oct 25 ? 0:00 /usr/cluster/lib/sc/clexecd
root 453 1  0 Oct 25 ? 0:01 /usr/cluster/lib/sc/rgmd
root 426 1  0 Oct 25 ? 0:00 /usr/cluster/lib/sc/rpc.fed
root 439 1  0 Oct 25 ? 0:00 /usr/cluster/bin/pnmd
root 2260 1  0 Dec 12 ? 0:00 /usr/cluster/lib/sc/cl_eventd
root 2356 1  0 Dec 12 ? 0:23 /var/cluster/spm/bin/scguieventd

The Sun Cluster 3.1 software installation installs the following additional RPC services in the /etc/inetd.conf file:

# Start of lines added by SUNWscu
100145/1 tli rpc/circuit_v wait root /usr/cluster/lib/sc/rpc.scadmd rpc.scadmd
100151/1 tli rpc/circuit_v wait root /usr/cluster/lib/sc/rpc.sccheckd rpc.sccheckd -S
# End of lines added by SUNWscu

The following RPC services are required by the Sun Cluster 3.x software and must be present in the /etc/inetd.conf file:

# rpc.metad
100229/1 tli rpc/tcp wait root /usr/sbin/rpc.metad rpc.metad
# rpc.metamhd
100230/1 tli rpc/tcp wait root  /usr/sbin/rpc.metamhd rpc.metamhd

The qualified configuration uses Solstice DiskSuite software, which requires the following RPC services in the /etc/inetd.conf file:

# rpc.metamedd - DiskSuite mediator
100242/1 tli rpc/tcp wait root /usr/sbin/rpc.metamedd rpc.metamedd
# rpc.metacld - DiskSuite cluster control
100281/1 tli rpc/tcp wait root  /usr/sbin/rpc.metacld rpc.metacld

If you use VERITAS Volume Manager software instead of Solstice DiskSuite software, leave the appropriate VERITAS RPC entries in the /etc/inetd.conf file enabled and disable the unneeded Solstice DiskSuite software entries.

Terminal Server Requirements

Sun Cluster 3.x software does not require a specific terminal server as Sun Cluster 2.x software did. This change is a significant improvement from a security perspective. Terminal server connections frequently do not use encryption. Lack of encryption allows a malicious individual to sniff the network and "read" the commands being issued to the client. Frequently, these commands include an administrator logging in as root and providing the root password.

We strongly recommend that you use a terminal server that supports encryption. Specifically, we recommend a terminal server that implements Secure Shell (SSH).

If you cannot use a terminal server that supports encryption, then only connect terminal servers to a private management network. Although this helps isolate network traffic to the terminal servers, it is not as secure as a terminal server supporting SSH.

Node Authentication Options

Node authentication is how potential nodes must identify themselves before being allowed to join a cluster. Sun Cluster 3.x software provides several options for node authentication. Ensuring that all nodes are properly authenticated is a critical aspect of cluster security. This section describes the available node authentication options and provides recommendations on which level of node authentication to use.

The available node authentication options in Sun Cluster 3.x software are as follows:

  • None (for example, any system is permitted to join the cluster)

  • IP address

  • UNIX

  • Diffie-Hellman using DES

In addition, the scsetup command provides the following submenu under the New Nodes menu option::

*** New Nodes Menu ***

Please select from one of the following options:

1) Prevent any new machines from being added to the cluster
2) Permit any machine to add itself to the cluster
3) Specify the name of a machine which may add itself
4) Use standard UNIX authentication
5) Use Diffie-Hellman authentication
6) New nodes
?) Help
q) Return to the Main Menu

At a minimum, the node authentication should be set up to require that new cluster nodes be added manually rather than automatically. Select option 1 to restrict the ability of systems to add themselves, then use option 3 to specify the name of the new cluster node. These two options run scconf with the following commands, which you can run manually:

# scconf -a -T node=.
# scconf -a -T node=phys-sps-1

The next consideration is how to validate that a node is who it says it is. The two alternatives are standard UNIX or Diffie-Hellman authentication.

The default is to use UNIX authentication. If a private interconnect connects the nodes and the scconf command is used to restrict new nodes from joining, this approach is probably adequate.

In environments where other systems may attempt to join the cluster, or if the data on the cluster is particularly sensitive, then we recommend using the Diffie-Hellman authentication method.

Diffie-Hellman authentication uses Secure RPC to authenticate the nodes in the cluster. This authentication requires that the public and private keys be properly set up on each of the nodes. The most effective way to do this task is through NIS+, because it simplifies the management and maintenance of these key pairs. However, it is possible to use Secure RPC without NIS+.

For additional information on Secure RPC and Diffie-Hellman authentication, refer to the keyserv(1M), publickey(4), and nis+(1) man pages.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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