Securing the Sun Fire 12K and 15K System Controllers

Like this article? We recommend

Securing Systems with the Solaris Toolkit

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Securing Systems with the Solaris Toolkit

Learn More Buy

Securing the System Controller

In order to effectively secure SCs, changes are required to both the Solaris OE software running on the SCs and the configuration of the Sun Fire 12K or 15K platform. We added customized modules to versions 0.3.11 and newer of the Solaris Security Toolkit software to simplify the Solaris OE installation and deployment of these recommendations. These modules automate the implementation of the security recommendations.

The primary function of the Solaris Security Toolkit software is to automate and simplify building secured Solaris OE systems based on the recommendations contained in this and other security-related Sun BluePrints OnLine articles.

The Sun Fire 12K and 15K SC module sunfire_15k_sc-secure.driver exclusively performs hardening tasks. No minimization of the Solaris OE is performed.

You can use the Sun Fire 12K and 15K SC module of the Solaris Security Toolkit in either standalone or JumpStart_ mode to secure SCs.

To harden the SCs, refer to the following sections:

• "Adding Security Software" on page 20

• "Customizing the Solaris Security Toolkit Driver" on page 26 (optional)

• "Overriding Solaris Security Toolkit Defaults" on page 40 (optional)

• "Installing Downloaded Software and Implementing Modifications" on page 40

Adding Security Software

The next stage in hardening the SCs requires downloading and installing additional software security packages. This section covers the following tasks:

• "Install Solaris Security Toolkit Software" on page 20

• "Download Recommended Patch Cluster Software" on page 21

• "Download FixModes Software" on page 23

• "Download OpenSSH Software" on page 24

• "Download the MD5 Software" on page 25

Install Solaris Security Toolkit Software

The Solaris Security Toolkit software must be downloaded first, then installed on the SCs. Later, you'll use the Solaris Security Toolkit software to automate installing other security software and implementing the Solaris OE modifications for hardening the SCs.

The primary function of the Solaris Security Toolkit software is to automate and simplify building secured Solaris OE systems based on the recommendations contained in this and other security-related Sun BluePrints OnLine articles.

To Download Solaris Security Toolkit Software

1. Download the latest version of the source file from:

http://www.sun.com/security/jass

2. Extract the source file into a directory on the server by using the uncompress command:

# uncompress SUNWjass-0.3.11.pkg.Z

Where SUNWjass-0.3.11.pkg.Z is the file name of the most current release.

3. Install the Solaris Security Toolkit software onto the server using the pkgadd command:

# pkgadd -d SUNWjass-0.3.11.pkg SUNWjass

Where SUNWjass-0.3.11.pkg is the file name of the most current release.

Executing this command creates the SUNWjass subdirectory in /opt. This subdirectory contains all Solaris Security Toolkit directories and associated files. The script make-jass-pkg—included in Solaris Security Toolkit software releases since version 0.3—allows administrators to create custom packages using a different installation directory.

Download Recommended Patch Cluster Software

Patches are regularly released by Sun to provide Solaris OE fixes for performance, stability, functionality, and security. It is critical to the security of a system that the most up-to-date patch is installed. Ensure that the latest Solaris OE Recommended and Security Patch Cluster is installed on the SCs. This section describes how to download the latest patch cluster.

Downloading the latest patch cluster does not require a SunSolve OnLine^SM program support contract.

To Download Recommended Patch Cluster Software

1. Download the latest patch from the SunSolve OnLine Web site at:

http://sunsolve.sun.com

2. Click on the Patches link at the top of the left navigation bar.

3. Click on Recommended and Security Patches in the Download box.

4. Select the download option for the appropriate Solaris OE version, either HTTP or FTP, by clicking on the appropriate link.

In our example, we selected Solaris 9 OE using HTTP download.

The Save As dialog box is displayed in your browser window.

5. Move the file securely to the SCs with the scp command, or ftp if Secure Shell is not available.

If you use the scp command, it should be similar to the following example:

% scp 9_Recommended.zip sun15-sc0:/var/tmp

6. Move the file to the /opt/SUNWjass/Patches directory and uncompress it as follows:

# cd /opt/SUNWjass/Patches
# mv /var/tmp/9_Recommended.zip .
# unzip 9_Recommended.zip
Archive:   9_Recommended.zip
  creating: 9_Recommended/
 inflating: 9_Recommended/CLUSTER_README 
 inflating: 9_Recommended/copyright 
 inflating: 9_Recommended/install_cluster 
[. . .]

Later, using the Solaris Security Toolkit software, you will install the patch after downloading all the other security packages.

NOTE

If you do not place the Recommended and Security Patches software into the /opt/SUNWjass/Patches directory, a warning message displays when you execute the Solaris Security Toolkit software.

Download FixModes Software

FixModes is a software package that tightens the default Solaris OE directory and file permissions. Tightening these permissions can significantly improve overall security of the SCs. More restrictive permissions make it even more difficult for malicious users to gain privileges on a system.

To Download FixModes Software

Download the FixModes pre-compiled binaries from:

http://www.sun.com/blueprints/tools/FixModes_license.html

The FixModes software is distributed as a precompiled and compressed tar file formatted for systems based on SPARC™ technology. The file name is FixModes.tar.Z.

1. Once downloaded, move the file securely to the SCs with the scp command, or ftp if scp is not available.

The scp command used should be similar to the following command:

% scp FixModes.tar.Z sun15-sc0:/var/tmp

2. Save the file, FixModes.tar.Z, in the Solaris Security Toolkit Packages directory in /opt/SUNWjass/Packages, with the following commands:

# cd /opt/SUNWjass/Packages
# mv /var/tmp/FixModes.tar.Z .

CAUTION

Leave the file in its compressed state.

Later, using the Solaris Security Toolkit software, you'll install the FixModes software after downloading all the other security packages.

Download OpenSSH Software

In any secured environment, the use of encryption in combination with strong authentication is required to protect user-interactive sessions. At a minimum, network access to the SCs must be encrypted.

The tool most commonly used to implement encryption is Secure Shell software, whether a version bundled with Solaris, a third-party commercial, or open source (freeware) version. To implement all the security modifications performed by the Solaris Security Toolkit software and recommended in this article, you must implement a Secure Shell software product.

Information on where to obtain commercial versions of Secure Shell is provided in "Related Resources" on page 47.

The Solaris Security Toolkit software disables all non-encrypted user-interactive services and daemons on the system, in particular daemons such as in.telnetd and in.ftpd.

Access to the system can be gained with Secure Shell similarly to what is provided by Telnet and ftp.

To Download OpenSSH Software

1. Obtain the following Sun BluePrints online article and use the instructions in the article for downloading the software.

A Sun BluePrints OnLine article about how to compile and deploy OpenSSH titled "Building and Deploying OpenSSH on the Solaris Operating Environment" is available at:

http://www.sun.com/blueprints/0701/openSSH.pdf

CAUTION

Do not compile OpenSSH on the SCs, and do not install the compilers on the SCs. Use a separate Solaris OE system—running the same Solaris OE version, architecture, and mode (for example, Solaris 8 OE, Sun4U, and 64 bit)—to compile OpenSSH. If you implement a commercial version of Secure Shell, then no compiling is required. Understand, however, that omitting compilers does not provide significant protection against the determined attacker as they could use previously compiled tools.

Download the MD5 Software

The MD5 software validates MD5 digital fingerprints on the SCs. Validating the integrity of Solaris OE binaries provides a robust mechanism to detect system binaries that are altered or trojaned (hidden inside something that appears safe) by unauthorized users. By modifying system binaries, attackers provide themselves with backdoor access onto a system; they hide their presence and cause systems to operate in unstable manners.

To Download the MD5 Software

1. Download the MD5 binaries from the following web site:

http://www.sun.com/blueprints/tools/md5_license.html

The MD5 programs are distributed as a compressed tar file.

2. Move the file md5.tar.Z securely to the SCs with the scp command, or ftp if scp is not available.

The scp command used should be similar to the following:

% scp md5.tar.Z sun15-sc0:/var/tmp

3. Copy the file, md5.tar.Z, to the Solaris Security Toolkit Packages directory in /opt/SUNWjass/Packages.

CAUTION

Do not uncompress the tar archive.

After the MD5 software is saved to the /opt/SUNWjass/Packages directory, the execution of the Solaris Security Toolkit installs the software.

After the MD5 binaries are installed, you can use them to verify the integrity of executables on the system through the Solaris Fingerprint Database. More information on the Solaris fingerprint database is available in the Sun BluePrints OnLine article titled "The Solaris_ Fingerprint Database - A Security Tool for Solaris Software and Files."

4. (Optional) Download and install Solaris Fingerprint Database Companion and Solaris Fingerprint Database Sidekick software from the SunSolve Online web site at:

http://sunsolve.sun.com

We strongly recommend that you install these optional tools and use them with the MD5 software. These tools simplify the process of validating system binaries against the database of MD5 checksums. Use these tools frequently to validate the integrity of the Solaris OE binaries and files on the cluster nodes.

These tools are described in the "The Solaris_ Fingerprint Database - A Security Tool for Solaris Software and Files" article.

Customizing the Solaris Security Toolkit Driver

If you determine that your system requires some of the services and daemons disabled by the Solaris Security Toolkit, or you want to enable any of the inactive scripts available in the Solaris Security Toolkit, do so before executing the Solaris Security Toolkit.

As described earlier in this article, the SMS 1.3 software provides capabilities for securing the MAN network:

• Disable ARP on the MAN network.

• Disable all I1 IP traffic between the SCs and specific domains.

With SMS 1.2, either an .rhosts or .shosts file was required. For SMS 1.3, it changed to a .remotesc file.

Beginning with SMS 1.2 and patch 112481-05, and continuing with SMS 1.3, you can use Secure Shell as an alternative transport mechanism for fomd, removing the requirement for in.rshd, in.rlogind, in.rexecd, and /.rhosts on the SCs. Using this alternative transport is strongly recommended. You can use any Secure Shell implementation, although the examples in this article are based on the use of Solaris Secure Shell running on Solaris 9 OE.

We strongly recommend that you disable ARP on the MAN network. For multi-domain system configurations where domain separation is of critical concern, we also recommend disabling IP connectivity between the SCs and those domains that require separation.

Disabling ARP on the MAN network can only be done for an entire chassis. It is not possible to make this change only for certain domains. It must be done on all domains having IP connectivity to the I1 network.

Implementing any of these modifications to the SCs requires modifying the files included with the Solaris Security Toolkit, as well as domain side modifications when disabling ARP on the MAN network. In addition, if you are implementing Secure Shell as an alternative transport for fomd, then additional manual steps are required.

The following sections provide instructions for using each of these options. The instructions include the required modifications to the Solaris Security Toolkit driver in addition to any manual modifications required. The modifications described are cumulative; if you want to use all three options, perform all the steps described in each of the three sections.

To Disable ARP

1. To add the necessary features or customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..

# cd /opt/SUNWjass/Drivers
# vi sunfire_15k_sc-hardening.driver

CAUTION

To preserve your changes for future updates and prevent the Solaris Security Toolkit from overriding your changes, modify only a copy of the driver. Keep the original Solaris Security Toolkit driver as a master.

2. If static ARP configuration is required for this SC, uncomment s15k-static-arp.fin from the driver by removing the # symbol in front of the script.

After editing the line, it should appear as follows in the JASS_SCRIPTS definition:

s15k-static-arp.fin

3. Review the domain hostname to MAC address mapping in the sms_sc_arp file.

This file is in the /opt/SUNWjass/Files/etc directory. The Solaris Security Toolkit uses the following initial values (sun15-a through sun15-r) in this file:

sun15-a     08:00:20:d5:c6:09
sun15-b     08:00:20:fc:7e:4e
sun15-c     08:00:20:b2:a8:c7
sun15-d     08:00:20:cf:ad:7d
sun15-e     08:00:20:ce:de:e5
sun15-f     08:00:20:cc:c9:b7
sun15-g     08:00:20:9d:02:e1
sun15-h     08:00:20:2a:7f:f6
sun15-i     08:00:20:f4:39:37
sun15-j     08:00:20:6e:aa:31
sun15-k     08:00:20:90:67:88
sun15-l     08:00:20:ce:e6:5e
sun15-m     08:00:20:5a:27:7f
sun15-n     08:00:20:55:e5:36
sun15-o     08:00:20:67:78:73
sun15-p     08:00:20:c6:84:b5
sun15-q     08:00:20:c0:37:cb
sun15-r     08:00:20:41:9d:68

a.	If your site configuration for the MAN network uses different domain hostnames, replace the sun15-a through sun15-r values with your hostnames.




The domain hostname and MAC address mapping can be obtained on the main SC by using the showplatform -v command, as in the following example:

Domain Ethernet Addresses:
==============================
   Domain ID  Domain Tag    Ethernet Address
   A      newA       8:0:20:b8:79:e4
   B      engB       8:0:20:b4:30:8c
   C      domainC      8:0:20:b7:30:b0
   D        -       8:0:20:b8:2d:b0
   E      eng1       8:0:20:f1:b7:0
   F      domainF      8:0:20:be:f8:a4
   G      dmnG       8:0:20:b8:29:c8
   H        -       8:0:20:f3:5f:14
   I        -       8:0:20:be:f5:d0
   J      dmnJ       8:0:20:67:78:73
   K        -       8:0:20:f1:ae:88
   L        -       8:0:20:b7:5d:30
   M        -       8:0:20:f1:b8:8
   N        -       8:0:20:f3:5f:74
   O        -       8:0:20:f1:b8:8
   P        -       8:0:20:b8:58:64
   Q        -       8:0:20:f1:b7:ec
   R      dmnR       8:0:20:f1:b7:10

b.	If your site configuration requires different MAC addresses, replace them with MAC addresses that match your domain hostnames in this file for both SCs.




Use either the default MAC addresses provided with the Solaris Security Toolkit or the ones that you determined are required for your site. You can customize the MAC addresses, as long as you meet the following conditions:

• Specify sufficiently random numbers for the last three octets (for example, use the 08:00:20 prefix and use random numbers for the rest).

• Place the addresses in the /etc/sms_arp_* files and match the contents of these files on both SCs and all domains.

CAUTION

Do not put the factory-provided sequential MAC addresses in these files.

4. Review the IP Address for the I1 MAN interface of the main SC and matching MAC address in the sms_domain_arp file.

This file is in the /opt/SUNWjass/Files/etc directory. The Solaris Security Toolkit uses the following initial values in this file:

192.168.103.1      08:00:20:63:49:1e

a.	If your site configuration for the MAN network uses a different IP Address for the I1 MAN interface, replace the 192.168.103.1 value with the IP address of the I1 MAN interface used in your environment.
b.	To obtain the floating IP address and MAC address on the main SC, execute the ifconfig scman0 command as the root user.




The floating IP address and MAC address can be obtained on the main SC by running the ifconfig scman0 command as the root user, as in the following example:

sc0# ifconfig scman0
scman0: flags=1008843 mtu 1500 index 4
    inet 192.168.10.1 netmask ffffffe0 broadcast 192.168.10.31
    ether 8:0:20:fa:34:f8

c.	If your site configuration requires a different MAC address than the initial 08:00:20:63:49:1e value, replace it with the MAC address that matches the IP Address for the I1 MAN interface on all domains and both SCs.




All the domains must use the same /etc/sms_domain_arp file.

If you want to force the MAC addresses to be the same, retrieve the MAC address from the sc0's I1 interface (scman0), and use this MAC address in the sms_domain_arp file on both sc0 and sc1.

CAUTION

The IP Address of the main SC in this file must match the IP address chosen as the IP Address of the SC on the I1 MAN network. Any mismatches cause MAN network failures. These failures can adversely affect the reliability, availability, serviceability, and security of the platform.

The /etc/init.d/sms_arpconfig script (installed by the Solaris Security Toolkit) overrides the default I1 MAC addresses on both the sc0 and sc1. Even though the two system controllers have different MAC addresses by default, it is imperative that the MAC addresses be set identically for the static ARP to work.

d.	Be sure that you keep the sms_sc_arp file contents matched on both of the SCs, the sms_domain_arp file contents matched on both of the SCs, and the sms_domain_arp file contents matched on all domains.




NOTE

If a domain is configured to have both s15k-exclude-domains.fin and s15k-static-arp.fin applied to it, the result is equivalent to s15k-exclude-domains.fin. It is possible, however, to have some domains excluded while others use static ARPs. We strongly recommend that you disable ARP on the I1 MAN network to protect against ARP-spoofing attacks. Note that disabling ARP on the I1 MAN network is a modification that affects the entire chassis and all the domains in the chassis. It is not possible to disable ARP only between certain domains and the SCs.

To Disable I1 Traffic

1. To add the necessary features or customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..

# cd /opt/SUNWjass/Drivers
# vi sunfire_15k_sc-hardening.driver

CAUTION

To preserve your changes for future updates and prevent the Solaris Security Toolkit from overriding your changes, modify only a copy of the driver. Keep the original Solaris Security Toolkit driver as a master.

2. If domain exclusion is required for this SC, uncomment s15k-exclude-domains.fin from the driver by removing the # symbol in front of the script.

After editing the line, it should appear as follows in the JASS_SCRIPTS definition:

s15k-exclude-domains.fin

The default configuration of the s15k-exclude-domains.fin script is to disable I1 IP connectivity for all possible domains on the system.

3. If you do not want the default configuration, then edit the s15k-exclude-domains.fin script.

The s15k-exclude-domains.fin script is in the /opt/SUNWjass/Files directory and includes a variable, domain_RE, which specifies the domains to have their I1 IP connectivity disabled. To modify the domains that are impacted by this script, the definition of domain_RE must be changed. For example, if the following regular expression were used, then all domains would have their IP I1 MAN connectivity disabled except for domain D:

domain_RE='D[A-CE-R]-I1'

NOTE

If a domain is configured to have both s15k-exclude-domains.fin and s15k-static-arp.fin applied to it, the result is equivalent to s15k-exclude-domains.fin. It is possible, however, to have some domains excluded while others use static ARPs. We strongly recommend that you disable ARP on the I1 MAN network to protect against ARP-spoofing attacks. Note that disabling ARP on the I1 MAN network is a modification that affects the entire chassis and all the domains in the chassis. It is not possible to disable ARP only between certain domains and the SCs.

To Use fomd With Secure Shell Instead of r*

Using fomd with Secure Shell involves performing the following setup procedures:

• "Verify Installation of Secure Shell Software" on page 33

• "Configure Secure Shell" on page 33

• "Reboot the SCs and Verify Secure Shell Configurations" on page 37

• "Add Features and Customize the Hardening" on page 39

Verify Installation of Secure Shell SoftwareTo Verify Installation of Secure Shell Software

1. Verify that a Secure Shell version is installed, configured, and running appropriately.

NOTE

For fomd to work properly over Secure Shell, it must be possible for root to ssh from one SC to the other SC without requiring a password or command line options.

Configure Secure Shell

Perform the following steps to configure Secure Shell properly between the two SCs. The steps include instructions for both Solaris Secure Shell and OpenSSH. If another Secure Shell variant, or a customized OpenSSH build, is being used, then these instructions may require modifications for those products.

For fomd to work properly over Secure Shell, it must be possible for root to ssh from one SC to the other SC without requiring a password or command line arguments.

We recommend creating 2048-bit keys using RSA for Secure Shell protocol version 2. Be aware that using 2048-bit keys may introduce slight performance reductions.

In the following steps, we use the filename /.ssh/id_rsa for the Secure Shell keys and the default I2 MAN hostnames, sun15-sc0-i2 and sun15-sc1-i2, for the SCs.

To Configure Secure Shell

1. If using Solaris 9 OE, change the default Secure Shell configuration to allow root log in on both SCs:

a.	On both SC0 and SC1, edit the file /etc/ssh/sshd_config to allow root log-in.
	SC failover does not work if this step is omitted.
b.	Change the PermitRootLogin parameter from no to yes.
c.	Reboot each of the SCs by entering the following command from the platform shell:




# reboot -y

NOTE

You can reboot the SCs while the domains are running.

On the main SC (SC0) in a terminal window command line, perform the following steps:

We recommend that you display terminal windows side by side for both SCs (main and spare) throughout this procedure. Doing so makes it easier to enter the data and perform sequential steps on each SC.

a.	Generate a user key by entering the following command in the appropriate Secure Shell directory.




For our Solaris 9 OE example, we enter the command at the /usr/bin directory:

# /usr/bin/ssh-keygen -b 2048 -t rsa

The defaults for OpenSSH are 1024-bit keys with RSA for protocol version 1, that is, -t rsa1. You must specify -t rsa to get RSA for protocol version 2.

b.	Accept the default filename without entering a pass phrase.
c.	Transfer the public key file to a temporary file on SC1 using either scp (if available) or rcp:




# scp /.ssh/id_rsa.pub sun15-sc1-i2:/.ssh/id_rsa.pub-sc0

or

# rcp /.ssh/id_rsa.pub sun15-sc1-i2:/.ssh/id_rsa.pub-sc0

CAUTION

Do not omit the remote filename or use /.ssh/id_rsa.pub as the filename on SC1. If there is already a public key file on SC1, it may be overwritten and invalidate SC1's private key.

2. On the spare SC (SC1) in a terminal window command line, perform the following steps:

a.	Generate a user key by entering the following command:




# /usr/bin/ssh-keygen -b 2048 -t rsa

b.	Accept the default filename without entering a pass phrase.
c.	Transfer the public key file to a temporary file on SC0 using either scp (if available) or rcp:




# scp /.ssh/id_rsa.pub sun15-sc0-i2:/.ssh/id_rsa.pub-sc1

or

# rcp /.ssh/id_rsa.pub sun15-sc0-i2:/.ssh/id_rsa.pub-sc1

CAUTION

Do not omit the remote filename or use /.ssh/id_rsa.pub as the filename on SC0. If there is already a public key file on SC0, it may be overwritten and invalidate SC0's private key.

3. Return to the main SC and perform the following steps:

a.	Append SC1's public key to the /.ssh/authorized_keys2 or /.ssh/authorized_keys file.




NOTE

If you are using OpenSSH, the file to use is /.ssh/authorized_keys2. If you are using Solaris Secure Shell on Solaris 9 OE, the file to use is /.ssh/authorized_keys. This command creates the file if it does not exist.

# cat /.ssh/id_rsa.pub-sc1 >> /.ssh/authorized_keys2

or

# cat /.ssh/id_rsa.pub-sc1 >> /.ssh/authorized_keys

b.	Remove the temporary file.




# rm /.ssh/id_rsa.pub-sc1

4. Return to the spare SC and perform the following steps:

a.	Append SC0's public key to the /.ssh/authorized_keys2 or /.ssh/authorized_keys file.

# cat /.ssh/id_rsa.pub-sc0 >> /.ssh/authorized_keys2

or

# cat /.ssh/id_rsa.pub-sc0 >> /.ssh/authorized_keys

b.	Remove the temporary file.




# rm /.ssh/id_rsa.pub-sc0

Due to a known incompatibility between the SMS 1.2 software and Secure Shell startup script, if you upgrade the configuration from SMS 1.2 to SMS 1.3, you may need to move the SMS 1.2 startup script from UNIX run-level 2 to run-level 3 on both the main and spare SC.

5. If /etc/rc2.d/S99sms exists, perform the following:

# mv /etc/rc2.d/S99sms /etc/rc3.d

In addition to verifying the location of /etc/rc3.d/S99sms, also verify the location of the Secure Shell startup. It must be listed prior to /etc/rc3.d/S99sms. If you upgrade the SC's from SMS 1.2 to SMS 1.3, then you may need to move the Secure Shell software startup script to /etc/rc2.d.

6. If the Secure Shell software is listed, alphabetically, after the SMS software in /etc/rc3.d then move the Secure Shell software startup script to /etc/rc2.d as follows:

# mv /etc/rc3.d/*ssh* /etc/rc2.d/.

Reboot the SCs and Verify Secure Shell Configurations

To Reboot the SCs and Verify Secure Shell Configurations

1. Reboot each of the SCs by entering the following command from the platform shell:

# reboot -y

NOTE

You can reboot the SCs while the domains are running.

2. Verify that the configuration on SC0 works properly.

a.	Log into SC1 from SC0 as root using ssh:




# ssh sun15-sc1-i2

b.	When prompted to add this host to the list of known hosts, answer yes.
c.	Log out of SC1 with exit.
d.	Log into SC1 from SC0 again with ssh, and verify that no prompts are generated and that the login without a password is successful.




3. Verify the configuration on SC1 works properly.

a.	Log into SC0 from SC1 using ssh:

# ssh sun15-sc0-i2

b.	When prompted to add this host to the list of known hosts, answer yes.
c.	Log out of SC0 with exit.
d.	Log into SC0 from SC1 again with ssh, and verify that no prompts are generated and that the login without a password is successful.

Configure SMS to Use Secure Shell

After Secure Shell is installed and configured, you must instruct SMS to use Secure Shell instead of the r* services to copy files.

To Configure SMS to Use Secure Shell

1. Verify that links to both the ssh and scp executables are present in /usr/bin.

2. Execute the following smsconfig command to create softlinks from /usr/bin/ssh and scp to /opt/SUNWSMS/bin.

# smsconfig -s ssh

NOTE

If the Secure Shell version being used does not have its executables, or links to its executables, present in /usr/bin, this command will fail.

Add Features and Customize the HardeningTo Add Features and Customize the Hardening

1. To add necessary features and customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..

# cd /opt/SUNWjass/Drivers
# vi sunfire_15k_sc-hardening.driver

CAUTION

To preserve your changes for future updates and prevent the Solaris Security Toolkit from overriding your changes, modify only a copy of the driver. Keep the original Solaris Security Toolkit driver as a master.

2. Uncomment the s15k-sms-secure-failover.fin from the driver by removing the # symbol in front of the script.

After editing the line, it should appear as follows in the JASS_SCRIPTS definition:

 s15k-sms-secure-failover.fin

This script disables the r* services in the /etc/inetd.conf file automatically and performs the following, based upon the SMS version you are using:

• For SMS 1.2, this script copies the /.rhosts file to /.shosts.

• For SMS 1.3, this script removes the /.rhosts file, because it is no longer needed.

The five services disabled are as follows:

#shell stream tcp nowait root /usr/sbin/in.rshd    in.rshd
#shell stream tcp6 nowait root /usr/sbin/in.rshd    in.rshd
#login stream tcp6 nowait root /usr/sbin/in.rlogind  in.rlogind
#exec stream tcp nowait root /usr/sbin/in.rexecd   in.rexecd
#exec stream tcp6 nowait root /usr/sbin/in.rexecd   in.rexecd

Overriding Solaris Security Toolkit Defaults

If there are some services that must remain enabled, and the Solaris Security Toolkit automatically disables them, you can override the defaults before executing the driver.

To prevent the toolkit from disabling a service, comment out the call to the appropriate finish script in the driver.

For example, if your environment requires Network File System (NFS)-based services, you can leave them enabled. Comment out the disable-nfs-server.fin and disable-rpc.fin scripts by appending a # sign before them in the copy of the sunfire_15k_domain-hardening.driver script.

For more information about editing and creating driver scripts, refer to the Solaris Security Toolkit documentation.

Installing Downloaded Software and Implementing Modifications

The Solaris Security Toolkit version 0.3.11 and newer provides a driver (sunfire_15k_sc-secure.driver) for automating the installation of security software and Solaris OE modifications. The driver performs the following tasks:

• Installs and executes the FixModes software to tighten file system permission

• Installs the MD5 software

• Installs the Recommended and Security Patch Cluster software

• Implements over 100 Solaris OE security modifications

To Install Downloaded Software and Implement Changes

1. Execute the sunfire_15k_sc-secure.driver script as follows:

# cd /opt/SUNWjass
# ./jass-execute -d sunfire_15k_sc-secure.driver
./jass-execute: NOTICE: Executing driver, 
sunfire_15k_sc-secure.driver

============================================================
sunfire_15k_sc-secure.driver: Driver started.
============================================================
[...]

NOTE

The hardening described in this article is performed in standalone mode, not JumpStart mode, because the SCs were built using an interactive Solaris OE installation. For details on the differences between standalone mode and JumpStart mode, refer to the Solaris Security Toolkit documentation.

2. Restart the SMS software as follows:

# /etc/init.d/sms stop
[...]
# /etc/init.d/sms start

After you restart the SMS software, modifications to the I1 domain network take affect and fomd uses Secure Shell.

3. Reboot each of the SCs by entering the following command from the platform shell:

# reboot -y

NOTE

You can reboot the SCs while the domains are running.

You must reboot the SCs for the changes to be implemented.

To View the Contents of the Driver File

1. To view the contents of the driver file and obtain information about the Solaris OE modifications, refer to the Solaris Security Toolkit documentation available either in the /opt/SUNWjass/Documentation directory or through the web at:

http://www.sun.com/security/jass

To Undo a Solaris Security Toolkit Run

Each Solaris Security Toolkit run creates a run directory in /var/opt/SUNWjass/run. The names of these directories are based on the date and time the run is initiated. In addition to displaying the output to the console, the Solaris Security Toolkit software creates a log file in the /var/opt/SUNWjass/run directory.

The files stored in the /var/opt/SUNWjass/run directory track modifications performed on the system and enable the jass-execute undo feature.

1. To undo a run or series of runs, use the jass-execute -u command.

For example, on a system where two separate Solaris Security Toolkit runs are performed, you could undo them by using the following command and options:

# pwd
/opt/SUNWjass
# ./jass-execute -u
Please select from one of these backups to restore to
1. September 25, 2002 at 06:28:12 (/var/opt/SUNWjass/run/20020925062812)
2. December 10, 2002 at 19:04:36 (/var/opt/SUNWjass/run/20021210190436)
3. Restore from all of them
Choice? 3
./jass-execute: NOTICE: Restoring to previous run 
//var/opt/SUNWjass/run/20021210190436

============================================================
undo.driver: Driver started.
============================================================
[...]

Refer to the Solaris Security Toolkit documentation for details on the capabilities and options available in the jass-execute command.