Manual Chapter : Additional Information about BIG-IQ Centralized Management

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0

BIG-IP LTM

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0

BIG-IP AFM

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0

BIG-IP DNS

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0

BIG-IP ASM

  • 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
Manual Chapter

Additional Information about BIG-IQ Centralized Management

Creating a backup of the nShield RFS

Before you back up the RFS, make sure that the nShield Remote File System (RFS) server is installed on your network.
You back up the
/shared/nfast/kmdata/local/
directory of the RFS to a secure location, so that you can recover the RFS state, if needed. The RFS contains all of the nShield keys.
  1. If the RFS is not installed on the BIG-IP system, rename the
    /shared/nfast
    directory to
    /shared/nfast.org
    .
    This directory can be used to recover old data, if necessary.
  2. Follow the nShield best practices for backing up the RFS server.

Upgrading the BIG-IP software when using the nShield HSM

After a BIG-IP system software or hotfix upgrade, you must run the nShield client setup script to restore your default nShield configuration. Any local keys and certificates you loaded into the BIG-IP system before upgrading (using the command
tmsh install sys crypto
) appear in the upgrade partition, but they are usable only after you run the nShield client setup script. If you are restoring the nShield client on a VIPRION system, you run the configuration script only on the primary blade, and then the system propagates the configuration to the additional active blades.
If you will need CSRs, keys, or certs that were not loaded into the BIG-IP system, before you upgrade, copy the files into the
/shared
directory. After the upgrade, copy them back to their appropriate directories in the new partition:
/config/ssl/ssl.key/
,
/config/ssl/ssl.crt
, or
/config/ssl/ssl.csr
.
  1. Log in to the command-line interface of the BIG-IP system using an account with administrator privileges.
  2. Run one of these scripts, using the arguments that are appropriate for your configuration:
    • If the BIG-IP is an RFS server in addition to being a nShield client, use:
      nethsm-thales-rfs-install.sh
      and
      nethsm-thales-install.sh
    • If the BIG-IP is only a nShield client use:
      nethsm-thales-install.sh
The protected keys, which are stored in
/opt/nfast/kmdata/
, are available in the new partition, regardless of whether the keys and certs were loaded into the BIG-IP system.

Uninstalling nShield components from the BIG-IP system

If you no longer need to use the nShield on a BIG-IP system, you should uninstall the files.
  1. Log in to the command-line interface of the system using an account with administrator privileges.
  2. Uninstall the client and clean up.
    nethsm-thales-install.sh -u [-v]

Replacing a broken nShield HSM without breaking existing keys

You can replace a broken nShield HSM without destroying existing keys.
  1. Turn on the new HSM, and give it an IP address, netmask, and default route.
    nethsm-thales-install.sh -u [-v]
  2. Reconfigure the RFS, so that you can point the HSM to it. If the RFS is a BIG-IP system, use
    nethsm-thales-rfs-install.sh --hsm_ip_addr=<new HSM IP>
    . When the script asks if you want to uninstall, type
    yes
    . When the script asks if you want to overwrite the config, type
    yes
    . When the script asks if you want to use the existing Security World, type
    yes
    .
  3. Using the front panel on the HSM, configure the HSM to know its RFS. Once this is done, using the front panel again, add at least the BIG-IP system and the RFS to the HSM as clients.
  4. Using the front panel of the HSM and a quorum of the ACS, load the Security World onto the HSM.
  5. On the RFS, unenroll the old HSM, because otherwise it will still show up in enquiry results.
    nethsmenroll --force -r <old HSM IP> <old HSM ESM> <old HSM hash>
    Note that this requires the ESM and HSM hash from the broken machine. The command
    anonkneti
    will not work because the old HSM is broken or already removed from the network. This needs to be done even if the RFS is a BIG-IP system and the
    nethsm-thales-rfs-install.sh
    command was used.
  6. Rerun the install script on any BIG-IP systems that use the HSM. When that script asks if you want to uninstall, type
    yes
    . When that script asks if you want to backup, type whichever you prefer.
  7. On each BIG-IP system, unenroll the old HSM, because it will still show up in enquiry results.
    nethsmenroll --force -r <old HSM IP> <old HSM ESM> <old HSM hash>
    Note that this requires the ESM and HSM hash from the broken machine. The command
    anonkneti
    will not work, since the old HSM is broken or already removed from the network.

nethsm-thales-install.sh utility options

The
nethsm-thales-install.sh
utility includes these options:
Option
Description
-h
Displays help.
-u
Uninstalls and cleans-up the nShield software.
-v
Prints verbose output about operations.
--hsm_ip_addr=<ip_addr>
nShield HSM IP address(es). For multiple HSMs, use a double-quoted value with space-separated IP addresses (such as
--hsm_ip_addr="10.10.10.100.10.10.10.101"
).
--hsm_partition_name=<partition name>
nShield HSM partition name. For a single partition, use a double-quoted value. For example:
--hsm_partition_name="loadshared accelerator"
. For multiple partitions, use a double-quoted value with a colon-separated partition name. For example:
--hsm_partition_name="softcard1:softcard2:loadshared accelerator"
. To receive a partition name, use the nShield utility
"ckinfo"
to get the partition name after
"label"
under the
"CK_TOKEN_INFO"
section. You can ignore the trailing spaces of the label name.
--hsm_partition_pwd=<password>
The nShield HSM partition password. This must be the same for all HSMs being used in a High Availability (HA) configuration. For multiple partitions, use a double-quoted value with a space-separated partition password.The passwords should be in the same order as the partition. For example:
--hsm_partition_pwd="abc xyz uvw"
.
--rfs_interface=<interface_name>
Interface identifier for the local Remote File System (RFS) server. Default is the management interface (eth0).
--protection=<protection_type>
Indicates which type of key protection to use. Valid options are [m]odule, [o]cs, or [s]oftcard. When this option is not used, the protection defaults to module protection.
--verbose=<level>
Indicates message verbosity level. The default value is zero, and all levels greater than zero indicate verbose output.

nethsm-thales-rfs-install.sh utility options

The
nethsm-thales-rfs-install.sh
utility includes these options:
Option
Description
-h
Displays help.
--u
Uninstalls nShield software and cleans up nShield directories.
-v
Prints verbose output about the executing operations.
--hsm_ip_addr=<ip_addr>
nShield HSM IP address(es). For multiple HSMs, use a double-quoted value with space-separated IP addresses (such as
--hsm_ip_addr="10.10.10.100.10.10.10.101"
).
--interface=<interface_name>
Interface identifier of BIG-IP to be used as nShield HSM Client (eth0). The default is the management interface.
--num_threads=<threads>
Indicates the number of threads pkcs11d will use. The default is 20.
--rfs_interface=<interface_name>
Local Remote File System (RFS) server interface name (eth0).
--rfs_ip_addr=<ip_addr>
Remote RFS server IP address.
--rfs_username=<ssh_username>
Remote RFS server username for SSH login.
--protection=<protection_type>
Indicates which type of key protection to use. Valid options are [m]odule, [o]cs, or [s]oftcard. When this option is not used, the protection defaults to module protection.
--verbose=<level>
Indicates message verbosity level. The default value is zero, and all levels greater than zero indicate verbose output.