- Installing the Oracle Solaris OS on a Cluster Node
- Securing Your Solaris Operating System
- Solaris Cluster Software Installation
- Time Synchronization
- Cluster Management
- Cluster Monitoring
- Service-Level Management and Telemetry
- Patching and Upgrading Your Cluster
- Backing Up Your Cluster
- Creating New Resource Types
- Tuning and Troubleshooting
This chapter is from the book
This chapter is from the book
This chapter is from the book
Securing Your Solaris Operating System
The security of your Solaris Cluster system must be foremost in your mind. Without security measures in place, your system could be vulnerable to denial-of-service attacks or have its data stolen, compromised, or deleted. Any of these threats could lead to your service being unavailable. Therefore, you must put barriers in place to prevent such threats.
Although several methods for auditing security violations are available, this section focuses on how to reduce the number of targets that an unauthorized user can attack. Even when your cluster is in a physically secure location, you can still take the additional measures of operating system minimization and hardening.
Operating Environment Minimization
With operating system minimization, you install the fewest number of Solaris packages that are required to operate your cluster and the services it supports. The Solaris installation process allows you to choose which software groups you install. These groups are shown in Figure 4.1. Furthermore, you can customize the installation to the level of individual packages.
)
Figure 4.1 Solaris software groups for installation
Clearly, choosing the software group at the center of the diagram means installing the fewest packages and thus presents the smallest "attack profile" to potential intruders. However, this installation is insufficient for the Solaris Cluster 3.2 1/09 software, which requires at least the End User Solaris Software Group (SUNWCuser) [SCInstallGuide].
One problem you face when trying to minimize your Oracle Solaris OS is that of ongoing maintenance, particularly with new or changing application requirements. Though your initial system might well be served by just the SUNWCuser package group, you could find that a new service requires some additional packages. Not only does this mean that you need to install the missing packages, but you might also have to reapply certain patches that would have been applied to these packages had they been installed in the first place. This also assumes that the Solaris packages on which your applications are dependent are clearly documented.
For these reasons, you must take a pragmatic approach to minimization. If your systems are unlikely to change over time, and testing has confirmed that the SUNWCuser group is sufficient for your needs, then installing that group should pose no problems. Conversely, if the services hosted on your cluster are likely to change, then installing the Entire package group will better serve your needs.
Regardless of your starting point, any subsequent change to the Solaris package installation list must be performed under a strong change management control process. Such a process would require thorough testing of your services in the new environment and verifying that they can still switch over successfully. Because such testing is disruptive, any preparatory work must be performed in a test environment before final testing during a planned maintenance period.
Operating System Hardening
In contrast to operating system minimization, which reduces the number of packages installed on the system, operating system hardening disables or modifies the configuration of services that are installed on the system. An example is the disabling of the rlogin, rsh, and rcp commands in preference to their secure counterparts, ssh and scp.
As with Oracle Solaris OS minimization, there is clearly an almost unlimited scope for OS hardening. Unfortunately, not all changes are necessarily compatible with running the Solaris Cluster software. Furthermore, if you have made several custom changes to your system, it might prove tricky for Oracle's support services to determine whether any fault that might arise has a root cause in your hardening choices or in the Solaris Cluster software itself. Consequently, they might request that you reverse your hardening effort in order to facilitate their diagnosis. Doing so could be complicated if you do not have a well-documented change control process or an automated system for applying your hardening rules.
Fortunately, Sun has developed a supported system to help you harden your systems effectively. The package is known as the Solaris Security Toolkit (formally known as the JumpStart Architecture and Security Scripts, or JASS) [SSTAdminGuide]. This allows you to harden your Oracle Solaris OS in a supported and reversible manner, regardless of whether you are using the Solaris 9 OS or the Solaris 10 OS.
In addition, in the Solaris 10 OS 11/06 release comes the Secure by Default configuration [SBDBlog]. This configuration does not make the Solaris Security Toolkit obsolete, but it does subsume many of the settings that the toolkit previously changed as part of the hardening process. The latest version of the toolkit still provides fine-grained control of your hardening process and performs many other security-related tasks.
With Secure by Default configuration, you need to relax some of these settings in the Solaris 10 OS prior to installing the Solaris Cluster software. The commands you need to execute are provided in the following example [ThorstenBlog].
Example 4.2. Reversing Some of the Solaris 10 Secure by Default Settings for a Solaris Cluster Installation
Ensure that the local_only property of rpcbind is set to false.
# svcprop network/rpc/bind:default | grep local_only
If local_only is not set to false, run
# svccfg svc:> select network/rpc/bind svc:/network/rpc/bind> setprop config/local_only=false svc:/network/rpc/bind> quit # svcadm refresh network/rpc/bind:default
This value is needed for cluster communication between nodes.
Ensure that the tcp_listen property of webconsole is set to true.
# svcprop /system/webconsole:console | grep tcp_listen If tcp_listen is not true, run # svccfg svc:> select system/webconsole svc:/system/webconsole> setprop options/tcp_listen=true svc:/system/webconsole> quit # svcadm refresh svc:/system/webconsole:console # /usr/sbin/smcwebserver restart
This value is needed for Solaris Cluster Manager communication.
To verify that the port is listening to *.6789, run
# netstat -an | grep 6789
Securing Network Communications
To secure your cluster on the network, start from the position of denying access to everything. Then proceed to allow access to ports that are specifically required by your applications and ports that are required by your management and administration procedures.
To secure network communications, you can use external firewalls. Alternatively, if you are using the Solaris 10 OS, you can use the built-in ipfilter capabilities. If you plan to use scalable services with shared IP addresses, you must use an external firewall. This is because the ipfilter software (see the ipfilter(5) man page) cannot detect the connection state after the shared address migrates from one cluster node to another cluster node.
In addition, if the applications on your cluster transmit sensitive data over the network to client systems, consider using the IP Security Architecture (IPsec) to protect the communication traffic (see the IPsec(7P) man page).