Reduce susceptibility to attacks and increase the reliability, availability, and serviceability of systems that run Sun Cluster 3.0 software by implementing the recommendations for configuring the Solaris Operating Environment and supported agents detailed in this article.

Like this article? We recommend

Like this article? We recommend

Introduction

This article describes how to secure the Solaris_ Operating Environment
(Solaris OE) and the Sun_ Cluster 3.0 software. To provide a robust environment
where Sun Cluster 3.0 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, and serviceability (RAS) of systems
running the Sun Cluster 3.0 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"

"Securing Sun Cluster 3.0 Nodes"

"Verifying Node Hardening"

"Sample Results"

"Maintaining a Secure System"

"About the Author"

"Acknowledgements"

Background Information

This section contains the following topics:

"Assumptions and Limitations"

"Qualified System Configuration"

"Support"

"Using the Solaris Security Toolkit Software"

"Solaris OE Defaults and Modifications"

"Additional Daemons and Services"

"Terminal Server Requirements"

"Node Authentication Options"

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.0 nodes using a Sun
supported configuration. Our recommendations assume a platform based on Solaris
8 OE (2/02) and the Sun Cluster 3.0 (12/01) or 5/02) software. We use the Sun
Cluster 3.0 (5/02) 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.0 nodes at this
time. Only the hardening tasks discussed in this article are supported for
Solaris OE systems with Sun Cluster 3.0 software running supported agents.

NOTE

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

Qualified System Configuration

The configuration described in this article has the following
characteristics:

Solaris 8 OE (2/02) software

Solaris OE packages and installation

Sun Cluster 3.0 (5/02) software

Supported agents

ORACLE RAC limitations

Cluster interconnect links

Solstice DiskSuite_ software

The following subsections describe each of these characteristics.

Solaris 8 OE

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.0 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.0 software, nor how to configure the cluster nodes.

Sun Cluster 3.0 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 discuss
methods for integrating the hardening process documented in this article with
JumpStart software. For information about this topic, refer to the Sun Cluster
3.0 and Solaris Security Toolkit documentation.

Sun Cluster 3.0 Software

Only Sun Cluster 3.0 (5/02 and 12/01) software support the hardened
configurations described in this article. Versions prior to 12/01 do not support
the hardened configurations described in this article and should not be used to
deploy these configurations.

Sun Cluster 3.0 software provides mission-critical capabilities to an
organization. While the Sun Cluster 3.0 software addresses issues such as fault
tolerance, failover, and performance, it is very important that the systems
running Sun Cluster 3.0 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 security recommendations in this article are limited to the following Sun
Cluster 3.0 agents, supported in secured environments:

Sun ONE Web Server

Apache Web Server

Sun ONE Messaging Server

Sun ONE Directory Server

Domain Name Server (DNS) Server

Network File System (NFS) Server

VERITAS NetBackup

HA ORACLE 8.1.7 and 9i (32- and 64-bit)

HA Sybase ASE 12.0 (32-bit)

ORACLE OPS/RAC 8.1.7 and 9i (32- and 64-bit)

SAP 4.6D (32- and 64-bit)

ORACLE RAC 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.0 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.0 software configuration implemented by the Solaris
Security Toolkit suncluster30u3-secure.driver is a Sun
Microsystems-supported configuration for agents described in this document. Only
Sun Cluster 3.0 (5/02 or 12/01) software implementations using the agents
explicitly described in this article and referenced in the Sun Cluster 3.0 (5/02
or 12/01) release notes are supported in hardened configurations.

NOTE

Hardening Sun Cluster 2.x, 3.0, and 3.0 (7/01) software is not supported.
Only agents described in this article and listed in either the Sun Cluster 3.0
(5/02 or 12/01) release notes are supported in hardened configurations.

The Solaris Security Toolkit is not a supported Sun product; only the
end-configuration created by the Solaris Security Toolkit is supported. Solaris
Security Toolkit support is available through the Sun_ SupportForum discussion
group at
http://www.sun.com/security/jass

NOTE

Sun Microsystems supports a hardened Sun Cluster 3.0 (5/02 or 12/01) cluster,
using the agents specified in this document, 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.6 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 8 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.0 node, there are over 80 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.0 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.0 software installs additional RPC- based services. These RPC
services include the rpc.pmfd and rpc.fed.

Implementing these modifications is automated when you use the driver script
suncluster30u3-secure.driver available in version 0.3.6 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.0 node functionality. Be
aware that these modifications may not be appropriate for every node. In fact,
it is likely that some of the services disabled by the default
suncluster30u3-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.

NOTE

Consider the role of a secured configuration in the context of the
applications and services that the Sun Cluster 3.0 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.0
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.0 software.

Recommendations and Exceptions

Our recommendations for securing the server configuration consist of
modifying recommendations made in the Solaris Operating Environment
Security: Updated for Solaris 8 Operating Environment Sun BluePrints
OnLine article. 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.0 nodes. This improvement is made by dramatically reducing access
points to the Sun Cluster 3.0 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.0 software and support constraints:

RPC system startup script is notdisabled, because RPC is
used by volume management software.

Solaris_ Basic Security Module (BSM) is notenabled. 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.

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

Using Scripts to Perform Modifications

Each of the modifications performed by the Solaris Security Toolkit
suncluster30u3-secure.driver are organized into one of the following
categories:

Disable

Enable

Install

Remove

Set

Update

The following paragraphs briefly describe each of these categories and the
modifications the scripts within the driver perform. For a complete listing of
the scripts included in the suncluster30u3-secure.driver, refer to the
Solaris Security Toolkit Drivers directory.

For detailed information about what each of the scripts do, refer to the
BluePrint OnLine article titled The Solaris Security Toolkit - Internals:
Updated for version 0.3.

In addition, the Solaris Security Toolkit copies files from the distribution
directory to increase the security of the system. These system configuration
files change the default behavior of syslogd, system network
parameters, and other system configurations.

Disable Scripts

These scripts disable services on the system. Disabled services include the
NFS client and server, the automounter, the DHCP server, printing services, and
the window manager. The goal of these scripts is to disable all of the services
that are not required by the system.

A total of 30 disable scripts are included with the Sun Cluster 3.0
software-hardening driver. These scripts impose modifications to disable all, or
part, of the following services and configuration files:

apache

aspppd

automountd

core generation

dhcp

snmpXdmid

dtlogin

IPv6

keyservd

ldap_cachemgr

lpsched

mipagent

mountd

nfsd

nscd

picld

pmconfig

pam.conf

sendmail

slp

snmpdx

printd

syslogd

smcboot

Enable Scripts

These scripts enable the security features that are disabled by default on
Solaris OE. These modifications include:

Enabling optional logging for syslogd and
inetd

Requiring NFS client requests to use privileged ports for all
requests

Enabling process accounting

Enabling improved sequence number generation according to RFC
1948

Enabling optional stack protection and logging to protect against most
buffer overflow attacks

While some of these services are disabled, their optional security features
remain enabled so that they are used securely if enabled in the future.

Install Scripts

These scripts create new files to enhance system security. In the Sun Cluster
3.0 driver, the following Solaris OE files are created to enhance the security
of the system:

An empty /etc/cron.d/at.allow to restrict access to at
commands

An updated /etc/ftpusers file with all system accounts to
restrict system FTP access

An empty /var/adm/loginlog to log unsuccessful login
attempts

An updated /etc/shells file to limit which shells can be used by
system users

An empty /var/adm/sulog to log su attempts

In addition to creating the preceding files, some install scripts add
software to the system. For the Sun Cluster 3.0 nodes, the following software is
installed:

Recommended and Security Patch Clusters

MD5 software

FixModes software

Remove Scripts

Only one remove script is distributed with the Sun Cluster 3.0 driver, and it
used to remove unused Solaris OE system accounts. The following accounts that
are removed are no longer used by the Solaris OE and can safely be removed:

smtp

nuucp

listen

nobody4

Set Scripts

These scripts configure the security features of the Solaris OE that are not
defined by default. A total of 14 scripts are distributed with the Sun Cluster
3.0 driver, and they configure the following Solaris OE security features not
enabled by default:

root password

ftpd banner

telnetd banner

ftpdUMASK

login RETRIES

power restrictions

System suspend options

TMPFS size

User password requirements

User UMASK

Update Scripts

These scripts update the configuration files that are shipped with the
Solaris OE and that do not have all of their security settings properly set. The
following configuration files are modified:

at.deny

cron.allow

cron.deny

logchecker

inetd.conf

Additional Daemons and Services

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

Terminal Server Requirements

Sun Cluster 3.0 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). Terminal servers that support SSH are currently available from both
Cisco (http://www.cisco.com) and
Perle
(http://www.perle.com).

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.0 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 and provides recommendations on which level of node authentication
to use.

The available node authentication options in Sun Cluster 3.0 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 under option
6Newnodes:

*** 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
?) 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
scsetup 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 is used
to connect the nodes and the scconf command was used to restrict new
nodes from joining, this approach is probably adequate.

In environments where other systems may attempt to join into 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.