- Updates
- Background Information
- Securing the System Controller
- Building a Secure MSP
- Backing Up, Restoring, and Updating the SC
- Resetting a Platform Administrator's Lost Password
- Verifying Hardening Results
- Related Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Backing Up, Restoring, and Updating the SC
This section provides information and recommendations for securely backing up and restoring the SC. In this section, the MSP is used as the dumpconfig, restoreconfig and flashupdate server.
Backing Up and Restoring Configurations
The dumpconfig command uses the FTP protocol to save the current platform and domain configurations to the MSP server. The restoreconfig command uses either the FTP or HTTP protocol to restore a previously saved configuration to the SC from the MSP server.
For complete descriptions and usage of the dumpconfig and restoreconfig commands, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual.
All stored platform and domain configuration information is included in the dump file. This information includes the MD5 hash of the platform and domain administrator passwords, the OBP password, and the SNMP community strings.
The dump file is not encrypted. Hence the MD5 hash of the platform and domain administrator passwords and the non-encrypted OBP password and SNMP community strings are transmitted in clear text during the dumpconfig operation. For this reason, the dump files are saved on the MSP, thus ensuring that the insecure transmission of information is restricted to the private SC network, thus minimizing exposure to network snooping.
When a restoreconfig operation is carried out, the entire saved configuration is restored. This includes the platform administrator and domain administrator passwords. It is essential to ensure that the passwords are known before this operation is carried out. Refer to "Configuring Platform Administrator Settings" on page 14 and "Configuring Domain Administrator Settings" on page 25.
The Apache Web Server on the MSP is configured such that the /msp directory is made available to the SC. All backup and restore operations to the MSP must be contained in this directory. Because the backup files created during a dumpconfig are not differentiated by name or date, it is important that separate directories be created for each backup for version control and tracking. The recommended solution is to create a directory for each dumpconfig using the year, month, day, and hour. For example: the dumpconfig performed on July 16th, 2001 at 7 p.m. would be stored in a directory called 2001071619.
Backing Up Platform and Domain Configurations
Although the MSP is configured to respond to HTTP, it does not normally respond to FTP because the FTP service is disabled during MSP setup. To perform a dumpconfig, the FTP service needs to be enabled on the MSP.
After saving configurations, disable the FTP service again on the MSP. The MSP is configured such that a user ID and password are required for this operation, and the user ID should be used only for dumpconfig and restoreconfig operations.
To Back Up Configurations on the MSP
To enable the FTP service on the MSP, log in to the MSP using Secure Shell, then su to root.
Edit the file /etc/inetd.conf, and uncomment the following FTP entry:
#ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l
Send the inetd daemon a SIGHUP signal with the following commands:
# ps -ef | grep inetd root 221 1 0 Jun 08 ? 0:00 /usr/sbin/inetd -s -t # kill -HUP 221
Create a directory with the appropriate time and date stamp on the MSP.
Before the actual dumpconfig command can be run, a directory on the MSP must be created with the appropriate time and date stamp. Based on the example (July 16th, 2001 at 7 p.m. would be stored in a directory called 2001071619), the following directory would be created:
# mkdir /msp/2001071619 # chown msphttp:mspstaff /msp/2001071619 # chmod 770 /msp/2001071619
At the SC, dump the configuration using FTP with a user name and password.
NOTE
The following example assumes a user name "blueprints" and password "t00lk1t" on the MSP.
The command and results should be similar to the following:
ds7-sc0:SC> dumpconfig -f ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619
Created: ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619/ds7-sc0.nvci
Created: ftp://blueprints:t00lk1t@192.168.100.10/msp/2001071619/ds7-sc0.todWhen the dump is complete, conclude the process by disabling the FTP entry in the /etc/inetd.conf by commenting out the following line in the /etc/inetd.conf:
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l
Send the inetd daemon a SIGHUP signal in the following manner:
# ps -ef | grep inetd root 221 1 0 Jun 08 ? 0:00 /usr/sbin/inetd -s -t # kill -HUP 221
Confirm that the FTP service is disabled by executing the following commands:
# ftp localhost ftp: connect: Connection refused ftp> quit
Restoring Platform and Domain Configurations
When it is necessary to restore configuration settings, first ensure that at least the platform administration password contained in the chosen dump file is known by the platform administrators. With the release of 5.13, it is possible for a platform administrator to reset the domain passwords without knowing the old ones. Ideally, of course, both the domain and platform passwords contained in the dump file should be known.
To avoid the necessity of enabling the FTP service on the MSP for this operation, we recommend that you use restoreconfig operation using HTTP. As with the dumpconfig operation, a user ID and password are required for this operation, and the user ID should only be used for dumpconfig and restoreconfig operations.
Restoring configuration settings using HTTP is documented in Sun Fire 6800/4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller Command Reference Manual. The only considerations are ensuring that the appropriate backup directory is available through the web server and that the passwords used for the domain and platform administrators, in the configuration being restored, are known.
Updating the SC
The flashupdate feature updates the firmware running on the SC, the CPU/Memory boards, and the I/O assemblies. The update is initiated by using the flashupdate command on the SC. The source flash image can be on a server or another board of the same type. This section describes updates executed from an image on a server. The MSP is used as the server for flashupdate images.
To avoid the necessity of enabling FTP on the MSP for this operation, we recommend that you carry out the flashupdate operation using HTTP.
The MSP is configured such that a user ID and password are required for this operation, and the user ID should only be used for flashupdate operations.
CAUTION
It is important to be sure of the authenticity and integrity of the flash images before they are loaded from the server using the flashupdate command. Loading a corrupted or malicious image can cause damage to hardware, and may compromise security.
It is recommended that the RTOS be updated whenever SCapp is updated. When a new firmware is released, SCapp is normally only tested with the RTOS included with the firmware update. If an RTOS flash fails, then a service call to Sun is required to replace or repair the SC. In order to establish whether a RTOS flash is necessary, refer to the product release notes accompanying the image and the flashupdate command documentation in the Sun Fire 6800/4810/4800/3800 Platform Administration Manual.
To Update the SC
Download the latest flashupdate for the SC from the Product Patches section of the SUNSOLVE ONLINE Web site at:
Make a note of the checksum listed for the patch in the Patch Checksums section of the SUNSOLVE ONLINE Web site, similar to the following:
111346-02.zip MD5: 5e84f09ebf5743eb5426b5be6c6a777f SysV Sum: 7075 13729 Sum: 43381 13729
- Confirm that the checksum of the file matches the checksum listed on
the SUNSOLVE ONLINE Web site, using the following commands:
# sum 111346-02.zip 7075 13729 111346-02.zip # sum -r 111346-02.zip 43381 13729 111346-02.zip
A more robust file integrity check is to use the MD5 hash value listed for the patch. For more information about downloading and using MD5 hashes to verify patch integrity, refer to the Sun BluePrints OnLine article titled The Solaris™ Fingerprint Database - A Security Tool for Solaris Software and Files.
Unpack the files containing the patch and place them in a subdirectory under the Apache Web Server document root directory /msp as follows:
# cd /msp # unzip 111346-02.zip Archive: 111346-02.zip creating: 111346-02/ inflating: 111346-02/Install.info inflating: 111346-02/VERSION.INFO inflating: 111346-02/copyright inflating: 111346-02/sgcpu.flash inflating: 111346-02/sgpci.flash inflating: 111346-02/sgrtos.flash inflating: 111346-02/sgsc.flash inflating: 111346-02/README.111346-02
Follow the instructions in the Install.info file.
In our example, sc-app, SB0, SB2, IB7, and IB9 are to be updated from version 5.11.6 to 5.11.7. The RTOS will be updated from release 17 to 17B. Not all system boards are powered up, so the all option cannot be used.
The following example downloads and installs the flashupdate file from the MSP:
ds7-sc0:SC> flashupdate -f http://blueprints:t00lk1t@192.168.100.10/111346-02 SB0 SB2 IB7 IB9 scapp rtos
The RTOS flash image will be upgraded automatically during the next boot. The ScApp flash image will be upgraded automatically during the next boot. After this update you must reboot each active domain that you have upgraded. After this update, the system controller will automatically reboot itself. Do you want to continue? [no] y
Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgcpu.flash Validating ............ Done Programming PROM 0 on /N0/SB0 Erasing ............ Done Programming ............ Done Verifying ............ Done Programming PROM 1 on /N0/SB0 Erasing ............ Done Programming ............ Done Verifying ............ Done Programming PROM 0 on /N0/SB2 Erasing ............ Done Programming ............ Done Verifying ............ Done Programming PROM 1 on /N0/SB2 Erasing ............ Done Programming ............ Done Verifying ............ Done Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgpci.flash Validating .... Done Programming PROM 0 on /N0/IB7 Erasing .... Done Programming .... Done Verifying .... Done Programming PROM 0 on /N0/IB9 Erasing .... Done Programming .... Done Verifying .... Done Rebooting the SC to automatically update flash image.
The SC reboots, and the flashupdate proceeds as follows:
Copyright 2001 Sun Microsystems, Inc. All rights reserved. RTOS version: 17 ScApp version: 5.11.6 SC POST diag level: off Auto Flashupdate Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgrtos.flash Retrieving: http://blueprints:t00lk1t@192.168.100.10/111346-02/sgsc.flash Validating .................................................... Done Updating: RTOS Erasing ........... Done Programming ........... Done Verifying ........... Done Updating: ScApp from version 5.11.6 to version 5.11.7 Erasing .................................................... Done Programming .................................................... Done Verifying .................................................... Done Flashupdate completed successfully. The SC is being rebooted to use the new images.
The SC then reboots with the new image.
Halt the Solaris OE image running in each domain gracefully by using the shutdown command.
You must perform this step before issuing the setkeyswitch off command.
For each domain affected by the updates, set the keyswitch to the off position by issuing the setkeyswitch off command from the domain shell.
In the following example, domain-a is affected:
ds7-sc0:A> setkeyswitch off This will abruptly terminate Solaris in domain A. Do you want to continue? [no] y
Set the domain keyswitch to the on position using the following setkeyswitch on command:
ds7-sc0:A> setkeyswitch on
The flashupdate operation is now complete. At this point, the domain boots itself either to the OBP prompt or Solaris OE. In either case, the flashupdate operation is now complete.