Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 4.0.1 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.
NOTE
We recommend that you disable failover before hardening either of the SCs. Re-enable failover only after both SCs are hardened and tested.
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 TM mode to secure SCs.
NOTE
Configuration modifications for performance enhancements and software configuration are not addressed by the Solaris Security Toolkit.
To harden the SCs, refer to the following sections:
"Adding Security Software"
"Customizing the Solaris Security Toolkit Driver"
"Overriding Solaris Security Toolkit Defaults"
"Installing Downloaded Software and Implementing Modifications"
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"
"Download FixModes Software"
"Download OpenSSH Software"
"Download the MD5 Software"
NOTE
Of the software described in this section, the Solaris Security Toolkit, Recommended and Security Patch Cluster, FixModes, and MD5 software are required. Instead of OpenSSH, you can substitute a commercial version of Secure Shell, available from a variety of vendors. You must install a Secure Shell product on the SCs.
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.
NOTE
The following instructions use filenames that are correct only for version 4.0.1 and newer of the Solaris Security Toolkit software.
To Download Solaris Security Toolkit Software
Download the latest version of the source file from:
Extract the source file into a directory on the server by using the uncompress command:
Install the Solaris Security Toolkit software onto the server using the pkgadd command:
http://www.sun.com/security/jass
NOTE
If you are using SMS 1.4 software, you must use Solaris Security Toolkit version 4.0.1 or newer.
# uncompress SUNWjass-4.0.1.pkg.Z
Where SUNWjass-4.0.1.pkg.Z is the file name of the most current release.
# pkgadd -d SUNWjass-4.0.1.pkg SUNWjass
Where SUNWjass-4.0.1.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 OnLineSM program support contract.
NOTE
Apply standard best practices to all patch installations. Before installing any patches, evaluate and test them on non-production systems or during scheduled maintenance windows.
To Download Recommended Patch Cluster Software
Download the latest patch from the SunSolve OnLine Web site at:
Click on the Patches link at the top of the left navigation bar.
Click on Recommended and Security Patches in the Download box.
Select the download option for the appropriate Solaris OE version, either HTTP or FTP, by clicking on the appropriate link.
Move the file securely to the SCs with the scp command, or ftp if Secure Shell is not available.
Move the file to the /opt/SUNWjass/Patches directory and uncompress it as follows:
http://sunsolve.sun.com
In our example, we selected Solaris 9 OE using HTTP download.
The Save As dialog box is displayed in your browser window.
If you use the scp command, it should be similar to the following example:
% scp 9_Recommended.zip sun15-sc0:/var/tmp
# 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:
Once downloaded, move the file securely to the SCs with the scp command, or ftp if scp is not available.
Save the file, SUNBEfixm.pkg.Z, in the Solaris Security Toolkit Packages directory in /opt/SUNWjass/Packages, with the following commands:
Uncompress the archive.
http://www.sun.com/security/jass
The FixModes software is distributed as a precompiled and compressed tar file formatted for systems based on SPARC® technology. The file name is SUNBEfixm.pkg.Z.
NOTE
Only certain versions of FixModes are supported for use on Sun Fire SCs. The correct FixModes version must have secure-modes.c version 1.41 and exempt-pkgs.h version 1.1. Newer versions of either file are acceptable. Earlier version of FixModes must not be used to secure Sun Fire SCs.
The scp command used should be similar to the following command:
% scp SUNBEfixm.pkg.Z sun15-sc0:/var/tmp
# cd /opt/SUNWjass/Packages # mv /var/tmp/SUNBEfixm.pkg.Z .
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.
NOTE
With the release of Solaris 9 OE, a version of Solaris Secure Shell is included. If using Solaris 9 OE, we strongly recommend using this Secure Shell version.
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.
NOTE
If you choose to use a Secure Shell product other than OpenSSH, install and configure it before or during the Solaris Security Toolkit software run.
To Download OpenSSH Software
NOTE
If the SCs are running Solaris 9 OE, you can use the Solaris Secure Shell software and skip the OpenSSH installation steps in this section.
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
Download the MD5 binaries from the following web site:
Move the file SUNBEmd5.pkg.Z securely to the SCs with the scp command, or ftp if scp is not available.
Copy the file, SUNBEmd5.pkg.Z, to the Solaris Security Toolkit Packages directory in /opt/SUNWjass/Packages.
(Optional) Download and install Solaris Fingerprint Database Companion and Solaris Fingerprint Database Sidekick software from the SunSolve Online web site at:
http://www.sun.com/security/jass
The MD5 programs are distributed as a compressed tar file.
The scp command used should be similar to the following:
% scp SUNBEmd5.pkg.Z sun15-sc0:/var/tmp
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 TM Fingerprint Database - A Security Tool for Solaris Software and Files."
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 TM 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 and 1.4, it changed to a .remotesc file. The .remotesc file is in /var/opt/SUNWSMS/SMS#.#/data/.remotesc, where #.# is the version number such as 1.4.
Beginning with SMS 1.2 and patch 112481-05, and continuing with SMS 1.3 and 1.4, 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.
CAUTION
When disabling ARP on a Sun Fire 12K or 15K system, it is critical that the necessary configuration changes be made to all domains and both SCs at the same time. Making the changes only on certain domains or SCs causes the system to malfunction.
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 Dynamic ARP
To add the necessary features or customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..
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.
Review the domain hostname to MAC address mapping in the sms_sc_arp file.
If your site configuration for the MAN network uses different domain hostnames, replace the sun15-a through sun15-r values with your hostnames.
If your site configuration requires different MAC addresses, replace them with MAC addresses that match your domain hostnames in this file for both SCs.
Review the IP Address for the I1 MAN interface of the main SC and matching MAC address in the sms_domain_arp file.
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.
To obtain the floating IP address and MAC address on the main SC, execute the ifconfig scman0 command as the root user.
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.
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.
# 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.
After editing the line, it should appear as follows in the JASS_SCRIPTS definition:
s15k-static-arp.fin
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
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
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.
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
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
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.
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
To add the necessary features or customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..
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.
If you do not want the default configuration, then edit the s15k-exclude-domains.fin script.
# 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.
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.
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*
NOTE
We recommend that you disable the failover mechanism before hardening the SCs. Re-enable failover only after you harden and test both SCs.
Using fomd with Secure Shell involves performing the following setup procedures:
"Verify Installation of Secure Shell Software"
"Configure Secure Shell"
"Reboot the SCs and Verify Secure Shell Configurations"
"Add Features and Customize the Hardening"
CAUTION
Although any version of Secure Shell may be used by fomd, the Secure Shell binaries scp and ssh must be available in /usr/bin. If the binaries, or links to the binaries, are not found in this location, then fomd attempts to revert back to r*. The fomd generates log messages when reverting to r*. If the r* services are disabled and fomd cannot fall back, then fomd generates file propagation errors for each file it cannot copy.
Verify Installation of Secure Shell SoftwareTo Verify Installation of Secure Shell Software
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.
NOTE
The following steps require that you have root access and know the correct hostnames for the SCs on the I2 MAN network. These are the hostnames that SC failover uses; therefore, Secure Shell must be configured properly for SC failover to work.
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
If using Solaris 9 OE, change the default Secure Shell configuration to allow root log in on both SCs:
On both SC0 and SC1, edit the file /etc/ssh/sshd_config to allow root log-in.
Change the PermitRootLogin parameter from no to yes.
Reboot each of the SCs by entering the following command from the platform shell:
On the main SC (SC0) in a terminal window command line, perform the following steps:
Generate a user key by entering the following command in the appropriate Secure Shell directory.
Accept the default filename without entering a pass phrase.
Transfer the public key file to a temporary file on SC1 using either scp (if available) or rcp:
On the spare SC (SC1) in a terminal window command line, perform the following steps:
Generate a user key by entering the following command:
Accept the default filename without entering a pass phrase.
Transfer the public key file to a temporary file on SC0 using either scp (if available) or rcp:
Return to the main SC and perform the following steps:
Append SC1's public key to the /.ssh/authorized_keys2 or /.ssh/authorized_keys file.
Remove the temporary file.
Return to the spare SC and perform the following steps:
Append SC0's public key to the /.ssh/authorized_keys2 or /.ssh/authorized_keys file.
Remove the temporary file.
If /etc/rc2.d/S99sms exists, perform the following:
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:
SC failover does not work if this step is omitted.
# reboot -y
NOTE
You can reboot the SCs while the domains are running.
NOTE
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.
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.
# 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.
# /usr/bin/ssh-keygen -b 2048 -t rsa
# 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.
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
# rm /.ssh/id_rsa.pub-sc1
# cat /.ssh/id_rsa.pub-sc0 >> /.ssh/authorized_keys2
or
# cat /.ssh/id_rsa.pub-sc0 >> /.ssh/authorized_keys
# 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.
NOTE
This step is not necessary for SMS 1.4
# 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.
# mv /etc/rc3.d/*ssh* /etc/rc2.d/.
Reboot the SCs and Verify Secure Shell ConfigurationsTo Reboot the SCs and Verify Secure Shell Configurations
Reboot each of the SCs by entering the following command from the platform shell:
Verify that the configuration on SC0 works properly.
Log into SC1 from SC0 as root using ssh:
When prompted to add this host to the list of known hosts, answer yes.
Log out of SC1 with exit.
Log into SC1 from SC0 again with ssh, and verify that no prompts are generated and that the login without a password is successful.
Verify the configuration on SC1 works properly.
Log into SC0 from SC1 using ssh:
When prompted to add this host to the list of known hosts, answer yes.
Log out of SC0 with exit.
Log into SC0 from SC1 again with ssh, and verify that no prompts are generated and that the login without a password is successful.
# reboot -y
NOTE
You can reboot the SCs while the domains are running.
# ssh sun15-sc1-i2
# ssh sun15-sc0-i2
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
Verify that links to both the ssh and scp executables are present in /usr/bin.
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.
With SMS 1.2, either an .rhosts or .shosts file was required. For SMS 1.3 and 1.4, it changed to a .remotesc file. The .remotesc file is in /var/opt/SUNWSMS/SMS#.#/data/.remotesc, where #.# is the version number such as 1.4.
Add Features and Customize the HardeningTo Add Features and Customize the Hardening
To add necessary features and customize the hardening required for your system, edit a copy of the sunfire_15k_sc-hardening.driver file..
To configure the SMS software to use Secure Shell for failover, set the following parameter (jassSMSSecureFailover) to 1.
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.
# 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.
After editing the line, it should appear as follows in the JASS_SCRIPTS definition:
# Set this parameter to 1 if you want to configure SMS to use # Secure Shell. jassSMSSecureFailover=1
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:
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 4.0.1 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
NOTE
The actions performed by each of the scripts is described in the Solaris Security Toolkit documentation.
During the installation and modifications implemented in this section, all non-encrypted access mechanisms to the SC—such as Telnet and FTP—are disabled. The hardening steps do not disable console serial access over SC serial ports.
To Install Downloaded Software and Implement Changes
NOTE
Even if no patches are installed by the Solaris Security Toolkit, it is critical that the sunfire_15k_sc-secure.driver be called. Calling either the -harden or -config drivers can result in an unsupported configuration.
Execute the sunfire_15k_sc-secure.driver script as follows:
Restart the SMS software as follows:
Reboot each of the SCs by entering the following command from the platform shell:
# 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.
# /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.
# 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
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:/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.
CAUTION
Do not modify the contents of the /var/opt/SUNWjass/run directories under any circumstances. Modifying the files can corrupt the contents and cause unexpected errors when you use Solaris Security Toolkit software features such as undo.
The files stored in the /var/opt/SUNWjass/run directory track modifications performed on the system and enable the jass-execute undo feature.
NOTE
By default, the Solaris Security Toolkit overwrites any files backed up during earlier runs being undone. In some cases, this action overwrites changes made to files since the run was performed. If you have concerns about overwriting changes, use the -n (no force) option to prevent modified files from being overwritten. Refer to the Solaris Security Toolkit documentation for more details about this option.
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 a JASS run to restore through:
1. September 25, 2003 at 06:28:12 (/var/opt/SUNWjass/run/20030925062812)
2. December 10, 2003 at 19:04:36 (/var/opt/SUNWjass/run/20031210190436)
3. Restore from all of them
Choice{'q' to exit)? 2
./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.