Using Midframe Servers to Build Secure Sun Fire Link Interconnect Networks

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 Midframe Sun Fire Link Cluster

To configure the Sun Fire Link, the first step is to build a private subnet and configure the midframe service processor (MSP). This step is detailed in the "Securing the Sun Fire Midframe System Controller" blueprint article. All steps in that article must be followed to secure the midframe SC. For direct connect topologies (Sun Fire Link clusters that do not use a switch) you can ignore the Sun Fire Link switch-specific instructions. The MSP, private SC, and switch SC subnet provide a containment of the insecure elements. This containment is critical to protect these insecure components.

Figure 5 shows how the MSP, the switch SC, and midframe SC interrelate.

FIGURE 5 Sample SC Network Topology

After the MSP and the private subnet are set up, the following procedures are required:

1. Creating the keystores

2. Securing the FM proxies

3. Securing the FM

4. Securing the switch

5. Securing the RSM driver

6. Configuring the fabric

Creating the Keystores

This article uses keytool to administer the keystores. Keytool is a key and certificate management utility. You can choose other tools to create the keystores and keys, but the tool must create a single keystore that contains public and private keys.

The keytool command is part of the Java 1.2 environment. For additional information on keytool go to: \http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/keytool.html

You must create two keystores. The two keystores are FMKeyStore and ProxyKeyStore. The FMKeyStore is the keystore that is used by the FM. This keystore contains the Private key that the FM uses. The ProxyKeyStore is the keystore used by the FM Proxy. This contains the private key that the FM proxy uses and the public key for the FM.

FIGURE 6 shows where the certificate (public key) and private key will be distributed.

FIGURE 6 Public and Private Key Locations

To Create the Keystore and Generate the Key Pair

1. Type the following command on the MSP in a safe private directory. Press return for the fmKey password.

# /usr/bin/keytool -genkey -dname "cn=JohnSmith, ou=Purchasing, o=ABCSystems
 s="CA c=US" -alias fmKey -keystore fmKeyStore -validity 180
Enter keystore password: YourPassword
Enter key password for <fmKey>
    (RETURN if same as keystore password): 

NOTE

This command must be typed on the MSP as a single line. Multiple lines are used in the examples for legibility purposes.)

All of the italicized items represent values. X.500 Distinguished Names are used to identify entities, such as those that are named by the subject and issuer.

TABLE 1 lists the keywords, X.500 distinguished names, and examples.

TABLE 1 Keywords, X.500 Distinguished Names, and Examples

KeyWord	X.500 Distinguished Names	Example
CN	Common name (Name of person)	John Smith
OU	Organization unit (department)	Purchasing
O	Organization name (company)	ABCSystems
l=	Locality name (city name)	Burlington
S	State name (state)	MA
C	Country	US




This command creates the keystore named fmKeyStore in the working directory, and assigns it the password YourPassword. Substitute a password for YourPassword which must be kept secret. This password is referred to as the keystore password. You must remember this password because it is used in other steps. Keytool generates a public/private key pair for the entity named fmKey. The generated key expires in 180 days. Every 180 days you must generate a new private/public key. You must then replace the private key on the proxy and public key on the FM.

2. Verify that the keystore was created correctly and the key entry is contained in the keystore. Substitute YourPassword for the keystore password you specified in the previous command.

# keytool -list -keystore fmKeyStore
Enter keystore password: YourPassword

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

fmkey, Fri Apr 12 12:11:44 EDT 2002, keyEntry,
Certificate fingerprint (MD5): F1:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36

NOTE

The message digest 5 (MDF) fingerprint and date will be different than that shown in the example. MD5 is an algorithm for computing digital signatures.

3. Generate the keystore for the FM Proxy node. Select a password for this keystore that is different than the fmKeyStore password.

# /usr/bin/keytool -genkey -dname "cn=JohnSmith, ou=Purchasing,
o=ABCSystems, s="MA, c=US" -alias proxyKey -keystore proxyKeyStore -validity 180
Enter keystore password: YourPassword
Enter key password for <fmKey>
    (RETURN if same as keystore password): 

# keytool -list -keystore proxyKeyStore
Enter keystore password: YourPassword

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

proxykey, Fri Apr 12 12:15:44 EDT 2002, keyEntry,
Certificate fingerprint (MD5): F2:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36

The date and fingerprint of the key will be different then it was before.

4. Using your favorite text editor, generate a file that contains the certificate (public key) for the fmKey pair. This public key will be installed in the proxyKeyStore.

# /usr/bin/keytool -export -alias fmKey -keystore fmKeyStore > fmCert
Enter keystore password: YourPassword

5. Verify that the public key was created. The strings for the CommonName and so forth are what you entered in the keytool -genkey step (Step1).

# /usr/bin/keytool -printcert -file fmCert
Owner: CN=JohnSmith, OU=Purchasing, O=ABCSystems, ST="MA c=US"
Issuer: CN=CommonName, -OU=OrganizationName, O=CompanyName, ST="CA c=US"
Serial number: 3cb70740
Valid from: Fri Apr 12 12:11:44 EDT 2002 until: Wed Oct 09 12:11:44 EDT 2002
Certificate s:
MD5: F1:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36
SHA1: 6C:76:5D:E9:64:84:08:E2:95:0B:64:95:70:6D:3F:E9:F5:D5:87:7E

The fingerprints and date should be the same as those displayed when the fmKeyStore was listed in Step 3.

6. Generate a file that contains the certificate (public key) for the proxyKey. This public key will be installed in the keystore fmKeyStore.

# /usr/bin/keytool -export -alias proxyKey -keystore proxyKeyStore > proxyCert
Enter keystore password: YourPassword

7. Verify that the public key was created. The values for the CommonName and so forth are what you entered in the keytool -genkey step (Step 1).

# /usr/bin/keytool -printcert -file proxyCert
Owner: CN=JohnSmith, OU=Purchasing, O=ABCSystems, ST="CA c=US"
Issuer: CN=JohnSmith, OU=Purchasing, O=ACBCSystems, ST="CA c=US"
Serial number: 3d98d307
Valid from: Fri Apr 12 12:15:44 EDT 2002 until: Wed Oct 09 12:11:44 EDT 2002
Certificate fingerprints:
MD5: F2:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36
SHA1: 6C:76:5D:E9:64:84:08:E2:95:0B:64:95:70:6D:3F:E9:F5:D5:87:7E

8. Import the FM's public key into the proxyKeyStore.

# /usr/bin/keytool -import -alias fmKey -file fmCert -keystore proxyKeyStore

Enter keystore password: YourPassword
Owner: CN=JohnSmith, OU=Purchasing, O=ABCSystems, ST="CA c=US"
Serial number: 3cb70740
Issuer: CN=JohnSmith, OU=Purchasing, O=ACBCSystems, ST="CA c=US"
Valid from: Fri Apr 12 12:11:44 EDT 2002 until: Wed Oct 09 12:11:44 EDT 2002
Certificate fingerprints:
MD5: F1:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36 SHA1:6C:76:5D:E9:64:84:08:E2:95:0B:64:95:70:6D:3F:E9:F5:D5:87:7

Trust this certificate? [no]: yes

Certificate was added to keystore

9. Validate that the proxyKeyStore contains the private key for the proxyKey and public key for the FM.

# /usr/bin/keytool -list -keystore proxyKeyStore

keystore password: YourPassword

Keystore type: jks

Keystore provider: SUN

Your keystore contains2 entries:
proxyKey, Fri Apr 12 12:15:44 EDT 2002 
Certificate fingerprints(MD5) F2:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36
fmkey, Fri Apr 12 12:11:44 EDT 2002 trustedCertEntry,
Certificate fingerprint (MD5):
F1:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36

10. Import the proxy public key into the fmKeyStore.

# /usr/bin/keytool -import -alias fmKey -file proxyCert -keystore fmKeyStore

Enter keystore password: YourPassword
Owner: CN=JohnSmith, OU=Purchasing, O=ABCSystems, ST="CA c=US"
Serial number: 3d98d307
Issuer: CN=JohnSmith, OU=Purchasing, O=ACBCSystems, ST="CA c=US"
Valid from: Fri Apr 12 12:15:44 EDT 2002 until: Wed Oct 09 12:11:44 EDT 2002
Certificate fingerprints:
MD5: F2:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36 SHA1:6C:76:5D:E9:64:84:08:E2:95:0B:64:95:70:6D:3F:E9:F5:D5:87:7

Trust this certificate? [no]: yes

Certificate was added to keystore

11. Validate that the fmKeyStore contains the private key for the FM and public key for the Proxy.

# /usr/bin/keytool -list -keystore fmKeyStore

keystore password: YourPassword

Keystore type: jks

Keystore provider: SUN

Your keystore contains 2 entries:
fmKey, Fri Apr 12 12:11:44 EDT 2002 
Certificate fingerprints (MD5): F1:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36
proxyKey, Fri Apr 12 12:15:44 EDT 2002 trustedCertEntry,
Certificate fingerprint (MD5):
F2:11:FF:90:B0:D8:C6:DE:23:CE:36:3F:81:B2:30:36

These two keystores will be used in other steps. If desired, you could generate a unique public/private key for each domain. You would then install each public key in the fmKeyStore. This article explains how to create a single keystore, which is then copied to each domain.

Securing the FM Proxy

These steps must be performed on every Solaris domain where the FM Proxy is running. Failure to do so will leave your system susceptible to attack. The required procedures are:

1. Configuring the proxy to use SSL

2. Installing the keystore

3. Creating the file ssl.info

4. Stopping and restarting the proxy.

To Configure the Proxy to Use SSL

1. Download JSSE 1.0.2.

You can download the file anywhere on your local disk. Note that JSSE 1.0.2 requires that you have Java 1.2.1 or greater already installed. you can download the file from HTTP://java.sun.com/products. You should get the file jsse-1_0_2-do.zip.

2. Uncompress and extract the downloaded file. The following command unzips the download.

# unzip jsse-1_0_2-do.zip
Archive: jsse-1_0_2-do.zip
 inflating: jsse1.0.2/BUGS.html   
 inflating: jsse1.0.2/CHANGES.txt  
 inflating: jsse1.0.2/COPYRIGHT.ht
... Many more files are listed

This creates a directory named jsse1.0.2, with two subdirectories named doc and lib.

3. Install the JSSE .jar files. in your extension directory. The JSSE Lib subdirectory contains the extension files jsse.jar, jcert.jar and jnet.jar. Determine which JVM the proxy is using by typing the following command.

# grep -v "#" /opt/SUNWwrsmp/jre_home.cfg
JAVA_BIN=/usr/java1.2/jre/bin/

The result of this command is that the directory contains the version of Java that the proxy is using. To get the Java JRE directory, remove the /bin. In the preceding example the directory is /usr/java1.2/jre. For this article substitute your Java directory for the string $JRE in the commands.

4. Copy the following files to the $JRE/lib/ext (installed extension) directory.

# cp lib/jsse.jar $JRE/lib/ext/jsse.jar
# cp lib/jcert.jar $JRE/lib/ext/jcert.jar
# cp lib/jnet.jar $JRE/lib/ext/jnet.jar

5. Verify that the files exist and they are owned by root.

# ls -l $JRE/lib/ext
-rw-r--r--  1 root   root 7637 Feb 20 10:17 jcert.jar
-rw-r--r--  1 root   root 3098 Feb 20 10:17 jnet.jar
-rw-r--r--  1 root   root 463471 Feb 20 10:17 jsse.jar

6. Register Sun JSSE provider.

JSSE comes standard with a cryptographic service provider, or provider for short, named SunJSSE. Although the SunJSSE provider must be configured explicitly, this provider should be registered statically. Static registration is done by editing the security Properties file located at $JRE/lib/security/java.security. One of the types of properties contained in the java.security files is of the following form:\.

security.provider.n=providerClassName

This line declares security provider and its preference. You should add a new line to that section and install the standard provider shipped with the JRE. The entries should look like the following:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider

To Install the proxyKeyStore

You must now distribute the keystore that was created previously, proxyKeyStore, to the RSM domain.

1. To move the key, use the secure copy scp command to copy the file onto your system. Execute the following command, substituting the machine name of $MSP for the server that is acting as your $MSP.

# scp $MSP:/privatedir/proxyKeyStore /opt/SUNWwrsmp/proxyKeyStore

2. Verify that this file is root read only. It is important that the private key is protected. The size of your file might be different.

# ls -l /opt/SUNWwrsmp/proxyKeyStore
-rw-------  1 root   root 7637 Feb 20 10:17

The proxy has a java.policy file. It is located in /opt/SUNWwrsmp/java.policy. This file should be edited so that the proxy has access to the file proxyKeyStore.

3. Add the following line above the }; in the file /opt/SUNWwrsmp:

# vi /opt/SUNWwrsmp/java.policy
add the following line
permission java.io.FilePermission "/opt/SUNWwrsmp/proxyKeyStore", "read"; 

To Create the File ssl.info

This file is the configuration data that the FM proxies needs to use the private key.

1. Create a file called ssl.info containing the following lines, but substitute the keystore password for YourPassword.

KEY_STORE_PASSPHRASE=YourPassword
KEY_STORE_LOCATION=/opt/SUNWwrsmp/proxyKeyStore

This information is sensitive so verify that the file is root read only by entering the following command to verify the file access.

# ls -l /opt/SUNWwrsmp/ssl.info
-rw-------  1 root   root 7637 Feb 20 10:17 

To Stop and Restart the Proxy

1. To have the proxy use SSL and the enhanced security settings, you must restart the proxy. The following command will stop the proxy.

# /etc/init.d/wrsm_proxy stop

2. To start the proxy type the following command.

# /etc/init.d/wrsm_proxy start

3. Verify that the proxy started with enhanced security. This example only lists the critical lines of output. For readability, the rest of the lines are ignored.

# tail /var/opt/SUNWwrsmp/log/wrmsp_nohup.out 
...
using SSL.
...
RP Bound To Registry

4. Repeat all of the preceding steps for each domain.

Securing the FM

The FM should be installed on the MSP. For the Sun Fire Link to be secure the appropriate action in the "MSP Security" blueprints must have been followed. If you have not done so, follow those instructions before you proceed. After the FM is installed correctly the following procedures are required:

1. Setting up the FM password file

2. Using RBAC on the FM

3. Setting up the FM's JVM to use SSL

4. Setting up the keystore for the FM

5. Securing the account sfluser

6. Copying wcrmp.jar

Setting Up the FM Password File

The FM can delete and reconfigure RSM clusters, so access to the FM RMI interface must be protected. A shared secret controls access to the FM. This shared secret is known to valid FM client programs and the FM. The shared secret is contained in a file whose access is restricted to root. If validation of the shared secret fails, the FM rejects the client request. The file must be located in the FM installed directory. This article assumes that you installed the FM using the default data directory, /var/opt/SUNWwcfm. If you did not use the default directory, you must modify the commands to reflect the directory in which the FM was installed.

To Set Up the FM Password File

1. Execute the following commands.

# echo "PASSWORD=YourPassword >> /var/opt/SUNWwcfm/config/
security.info
# echo "KEY_STORE_PASSPHRASE=KeyStorePassword >> /var/opt/
SUNWwcfm/config/security.info
# echo "KEY_STORE_LOCATION=/opt/SUNWwcfm/classes/fmKeyStore >> /
var/opt/SUNWwcfm/config/security.info

These commands create a file and set YourPassword as the password that the FM uses. The keyStorePassword should be the password that you specified for the FM keystore. These commands also specify the keystore location.

2. Check that the file was created correctly.

# more /var/opt/SUNWwcfm/config/security.info
PASSWORD=yourpasswod
KEY_STORE_PASSPHRASE=KeyStorePassword
KEY_STORE_LOCATION=/opt/SUNWwcfm/classes/fmKeyStore

3. Set the access on the file. Execute the following command to only allow access by root.

# chmod 400 /var/opt/SUNWwcfm/security.info 

4. Verify that the access is restricted on the file.

# ls -lst /var/opt/SUNWwcfm/security.info
-r--------  1 root   other     21 Apr 10 11:58 /opt/SUNWwcfm/classes/security.info 

The password file is now set up.

Using RBAC on the FM

RBAC is an alternative to the all-or-nothing superuser model. RBAC is in keeping with the security principle of least privilege, which states that no user should be given more privilege than required for preforming the job. RBAC enables roles for assignment to specific individuals according to their job needs. This enables a variety of security policies. This section provides the steps to create a special purpose role 'fmadmin' and then configure the FM commands so that this role can access it. RBAC is available on the Solaris 8 OE and above. If the MSP is running an earlier version of the Solaris OE, RBAC should not be used.

RBAC applies the following concepts:

• Roles. These are persona that a specific user can take on. For example, users can be assigned the role fmadmin. They can then su to that role and execute those commands. They cannot execute other commands.

• Authorization. A permission can be assigned to a role to perform a specific class of actions.

• Profile. A package of rights can be assigned to a role or a user.

Configuring the FM commands to use RBAC requires the following:

1. Creating the role

2. Creating the profile

3. Adding the profile to the role

4. Verifying that the changes have been made in the /etc/user_attr file

5. Creating the user adding new role

6. Assigning commands to the profile

To Configure the FM Commands to Use RBAC

1. Create the role as follows.

This example uses a role named fmadmin and a sample UID. You must use a UID that is valid for your installation.

# roleadd -u 123456 -g 101 -d /export/home/fmadmin -m fmadmin 
6 blocks
# passwd fmadmin
New password:
Re-enter new password:
passwd (SYSTEM): passwd successfully changed for fmadmin
# pwconv

2. Verify that the role has been added correctly.

# grep -i fmadmin /etc/passwd
fmadmin:x:123456:101::/export/home/fmadmin:/bin/pfsh

The number UID of 123456 will be different on you system. Note that the shell is pfsh, which is the profile shell.

3. Create a profile with a comment for the fmadmin.

# echo "fm-profile:::Ability to issue fm commands:" >>
/etc/security/prof_attr

4. Verify that the profile was added.

# grep fm-profile /etc/security/prof_attr
fm-profile:::Ability to issue fm commands:

5. Add the profile to the fmadmin role. The All allows the fmadmin role to execute normal commands.

# rolemod -P fm-profile,All fmadmin

6. Verify the changes.

# grep fm-profile /etc/user_attr
fmadmin::::type=role;profiles=fm-profile,All
# profiles fmadmin
fm-profile
All
Basic Solaris User

7. Assign the role to a new or existing usermod -R account.

You can use any normal administrator account for this step. This procedure adds the role to the account sfluser. sfluser was created when you followed the normal FM installation notes.

# usermod -R fmadmin sfluser

8. Verify that the roles are assigned to the user

# roles sfluser
fmadmin

9. Assign commands to the profile. These commands assume that the FM was installed in /opt/SUNWwcfm.

# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
listfabrics:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
createfabric:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
deletefabric:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/
bin/killfabrics:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/
bin/startfabric:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
stopfabric:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
wcfmconf:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
wcfmstat:uid=0" >> /etc/security/exec_attr
# echo "fm-profile:suser:cmd:::/opt/SUNWwcfm/bin/
wcfmver:uid=0" >> /etc/security/exec_attr

To Set Up the FM's JVM to Use SSL

These instructions are very similar to those used when SSL was enabled in the proxy's JVM.

1. Obtain and unzip JSSE 1.0.3.

You can download the file anywhere on your local disk. Note that JSSE 1.0.3 requires that you have Java 1.2.1 or greater already installed. You can download the file from HTTP://java.sun.com/products. You should get the file jsse-1_0_3-do.zip.

2. Uncompress and extract the downloaded file.

This will create a directory named jsse1.0.3, with two subdirectories named doc and lib. The following command unzips the download.

# unzip jsse-1_0_3-do.zip
Archive: jsse-1_0_3-do.zip
 inflating: jsse1.0.3/BUGS.html   
 inflating: jsse1.0.3/CHANGES.txt  
 inflating: jsse1.0.3/COPYRIGHT.ht
... Many more files are listed

3. Install the JSSE .jar files in your extension directory.

The JSSE lib subdirectory contains the extension files jsse.jar, jcert.jar, and jnet.jar. Determine the Java VM that the FM is using and type the following command. If the FM is installed in a different location you must modify the command.

# grep -v "#" /opt/SUNWwcfm/config/jre_home.cfg
JAVA_BIN=/usr/java1.2/jre/bin/

The line that is output is the Java bin directory the FM uses. To get the Java $JRE directory remove the /bin. In the preceding example, the directory is /usr/java1.2/jre. For this article substitute your Java directory for the string $JRE in the commands.

4. Copy these files in the $JRE/lib/ext (installed extension) directory.

# cp lib/jsse.jar $JRE/lib/ext/jsse.jar
# cp lib/jcert.jar $JRE/lib/ext/jcert.jar
# cp lib/jnet.jar $JRE/lib/ext/jnet.jar

5. Verify that the files exist and that they are owned by root.

ls -l $JRE/lib/ext
-rw-r--r--  1 root   root 7637 Feb 20 10:17 jcert.jar
-rw-r--r--  1 root   root 3098 Feb 20 10:17 jnet.jar
-rw-r--r--  1 root   root 463471 Feb 20 10:17 jsse.jar

6. Register the Sun JSSE provider.

JSSE comes standard with a cryptographic service provider named SunJSSE. Although the SunJSSE provider must be configured explicitly, it should be registered statically. Static registration is done by editing the security properties file which is located at:

$JRE/lib/security/java.security

One of the types of properties contained in the java.security files is of the following form:

security.provider.n=providerClassName

This line declares security provider and its preference. You should add a new line to that section and install the standard provider shipped with the JRE, the entries should now look like:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider

To Set Up the Keystore for the FM

The FM keystore must be copied into the location specified earlier.

1. Copy the keystore to the location /opt/SUNWwcfm/classes/fmKeyStore and verify that it is owned by root and read-only to root.

2. Modify the FM policy file so it can access the keyStore. It is located in /var/opt/SUNWwcfm/config/YourFabricName/cfg/YourFabricName.policy, where YourFabricName is the fabric name that you supplied to the createfabric command.

3. Edit this file so that the proxy has access to the file fmKeyStore. Add the following line above the }; in the file /var/opt/SUNWwcfm/config/YourFabricName/cfg/YourFabricName.policy.

# vi /var/opt/SUNWwcfm/config/YourFabricName/cfg/YourFabricName.policy
add the following line
permission java.io.FilePermission "/opt/SUNWwfcm/classes/fmKeyStore", "read"; 

The string YourFabricName should be equal to the fabric name you created. If you have not created a fabric you should create a fabric using the following:

# /opt/SUNWwcfm/bin/createFabric your_fabric_name

Securing the Fire Link Switch

Placing the switch behind the private network protects the switch. Providing additional security requires the following:

1. Setting the switch password

2. Setting the RMI password

3. Using the MSP as the flash server

4. Installing the write protect jumper

To Set the Switch Password

The password for the switch must be set. The Switch SC interactively allows the user to set a password for console access. The user must provide the old password (if applicable) to be able to set a new password. The password is used to get to the CLI on the console. The switch uses a shared account. The password controls access to this account. The password will be prompted for when the switch is first powered on, after a reboot, or if the logout command has been issued. It can also be prompted for if the console timeout has been set and the console has timed out and closed. Setting a blank password clears the current password.

Set the password on the switch.

# password
Enter Password>OldPassword
Enter New Password>NewPassword
password was changed.

If you forget the password, the command resetpassword will reset the password. To use this command you need physical access to the switch to move a jumper. For instructions, consult the Sun Fire Link Installation manual.

There is also a command called logout that allows the user to log out

To Set the RMI Password

The RMI password is a string that is sent when the FM requests an operation of the switch. For example when the FM sends a configuration to the switch this password is sent to authorize the action.

Set the RMI password.

# rmi=password
No RMI password is assigned. Do you want to set one? (y/[n]) >y
Enter password>

To Use the MSP As the Flashserver

The flashupdate feature is used to update the firmware running on the switch. The update is initiated by using the flashupdate command on the switch. The source flash image may be on a server. This article refers to performing a flashupdate using the MSP as the flash server.

To set the Write Protect Jumper

The switch has a jumper called flash write enable jumper. This jumper has two positions, write-protect and write-enabled. The factory setting for this jumper is the write-enabled position. For details, refer to the Sun Fire Link Installation and Service manual.

Some organizations may have security policies that require a high degree of protection against the risk of improper access to the real time operating system (RTOS). When such a requirement exists, the write-protect jumper can be used to provide this protection.

Securing the RSM Driver

With the RSM driver all commands that modify the configuration are restricted to the superuser, including items like initial and replace. All other operations (dump config, info, topology, and so forth) are available to any user.

To Restrict Access to the Information

1. Change the protection on the wci device.

# chmod 0700 /devices/wrsm*

Ongoing Security Efforts

After these security steps are done, the keys that are used by SSL will have to be replaced before they expire. Repeat the steps in "Creating the Keystores" and replace the keystores on the FM and the FM proxies.

Configuring the Fabric

The following is an example of configuring the fabric SFL with the FM command line tools. The fabric SFL was created in "To Set Up the Keystore for the FM". We will use a switch topology and two compute nodes and four switch nodes. The key step is the creation of the cluster1.xml file. The example file uses password for the string you should use to substitute the correct password. The names of the compute nodes are: Traviata and Lucia. The switch nodes are greatsandy, greatbasin, dryvalley, and saltflats. The following steps and configuration file create a single partition called part1.

Figure 7 shows the fabric cabling.

FIGURE 7 Fabric Cabling Diagram

To Configure the Fabric

1. On the MSP, su to the role fmadmin. If you are not using RBAC, ignore this command.

# su fmadmin

2. Create the cluster1.xml file.

CODE EXAMPLE 1 lists the contents of cluster1.xml file for this topology.

CODE EXAMPLE 1 cluster1.xml File

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fabric SYSTEM "fabric.dtd">
<fabric>
    <last_date_time>Mon Nov 12 14:21:11 EST 2001</last_date_time>
    <fname>fmdc</fname>
    <config_file>
    </config_file>
    <members>
        <switch_node>
            <node>
                <sc_name>greatsandy</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>WCIX_SWITCH</chassis_type>
            </node>
        </switch_node>
        <switch_node>
            <node>
                <sc_name>greatbasin</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>WCIX_SWITCH</chassis_type>
            </node>
        </switch_node>
        <switch_node>
            <node>
                <sc_name>dryvalley</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>WCIX_SWITCH</chassis_type>
            </node>
        </switch_node>
        <switch_node>
            <node>
                <sc_name>saltflats</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>WCIX_SWITCH</chassis_type>
            </node>
        </switch_node>
        <rsm_node>
            <node>
                <sc_name>traviata</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>S8</chassis_type>
            </node>
            <domain_name>a</domain_name>
            <hostname>traviata-a</hostname>
            <host_user>sfluser</host_user>
            <host_password>password<host_password>
        </rsm_node>
        <rsm_node>
            <node>
                <sc_name>brother</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>S8</chassis_type>
            </node>
            <domain_name>a</domain_name>
            <hostname>brother-a</hostname>
            <host_user>sfluser</host_user>
            <host_password>password<host_password>
        </rsm_node>
        <rsm_node>
            <node>
                <sc_name>lucia</sc_name>
                <sc_user_name>sfluser</sc_user_name>
                <sc_password>password<sc_password>
                <chassis_type>S8</chassis_type>
            </node>
            <domain_name>a</domain_name>
            <hostname>lucia-a</hostname>
            <host_user>sfluser</host_user>
            <host_password>password<host_password>
        </rsm_node>
    </members>
    <partitions>
        <partition type="RSM" topology="WcixSwitch">
            <pname>part1</pname>
            <stripping_level>4 </stripping_level>
            <partition_members>
                <node_partition_member>
                    <sc_name>lucia</sc_name>
                    <domain_name>a</domain_name>
                </node_partition_member>
                <node_partition_member>
                    <sc_name>traviata</sc_name>
                    <domain_name>a</domain_name>
                </node_partition_member>
                <switch_partition_member>
                    <sc_name>greatsandy</sc_name>
                </switch_partition_member>
                <switch_partition_member>
                    <sc_name>greatbasin</sc_name>
                </switch_partition_member>
                <switch_partition_member>
                    <sc_name>dryvalley</sc_name>
                </switch_partition_member>
                <switch_partition_member>
                    <sc_name>saltflats</sc_name>
                </switch_partition_member>
            </partition_members>
        </partition>
    </partitions>
</fabric>

The file cluster1.xml (which was created in the previous step) is used as an argument to the command line tools.

# startfabric sfl
# wcfmconf cluster1.xml
Found FM at [//localhost:1099/fmdc]
Configuration file processed successfully.