F5 Logo MyF5
Search
  1. MyF5 Home
  2. F5 Platforms: FIPS Administration
  3. About Platform FIPS
Manual Chapter : About Platform FIPS

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3

BIG-IP LTM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3

BIG-IP AFM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3

BIG-IP DNS

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3

BIG-IP ASM

  • 17.1.0, 17.0.0, 16.1.4, 16.1.3
Manual Chapter

About Platform FIPS

About Platform FIPS BIG-IP systems

The FIPS BIG-IP Platform Module solution, also known as Platform FIPS, is a FIPS validated BIG-IP system. The platform FIPS requires a F5 Full-Box FIPS add-on license and allows for FIPS 140-3 validation at level 2 while using the full performance capabilities of the BIG-IP system.
The platform FIPS provides device-level FIPS validation at level 2 for specific BIG-IP platforms with the Full-Box FIPS add-on license installed. Introduced in BIG-IP 13.1.0, the Full-Box FIPS license includes a FIPS installation kit that contains tamper-evident stickers that you must apply to the hardware device in order to be FIPS validated products.
BIG-IP systems with the Full-Box FIPS add-on license installed enter a FIPS-enabled mode during the boot process. When the BIG-IP system enters FIPS-enabled mode, the system changes the SSL cipher suites to be FIPS-compliant and enables the FIPS required self-tests to validate the integrity and operation of the system. If the system fails any of the self-tests during the boot process the BIG-IP system halts.
The Full-Box add-on license can be installed on any BIG-IP hardware platforms running the BIG-IP software version 13.1.0 or later for FIPS compliance, but only specific BIG-IP platforms and versions have been validated for FIPS. For more information about FIPS validated platforms and versions, see the security policy and certificates for your platform at F5 Certifications.

About FIPS module information

The FIPS module information is displayed in the TMOS Shell (
tmsh
) and Configuration utility when the system is in FIPS-enabled mode.
Use one of these to verify the FIPS-enabled mode:
  • Use the database (db) variable
    security.fips140.compliance
     to check if the system is in FIPS-enabled mode.
  • Use the Linux command cat on the
    /config/f5_public/fips.conf
     file. If the response is
    1
    , then the FIPS-enabled mode is enabled. If the response is
    0
    , an empty file, or no file is available, then the FIPS-enabled mode is disabled.
These are the FIPS module names:
  • Cryptographic Module for BIG-IP
  • F5 Device Cryptographic Module
  • F5 vCMP Cryptographic Module
In the Configuration utility, the FIPS module information is displayed in the
Version
 field at
Systems
Configuration
Device
General
.
Use
tmsh show sys version
 to display the FIPS module information, along with other system information.

About FIPS service indicator

The FIPS service indicator is used to indicate whether sessions are established using FIPS approved or non-approved crypto algorithms. The service indicator session information is collected and logged only when FIPS 140-3 license is installed on the BIG-IP.
If the key is in the internal FIPS card, then the Service Indicator in data plane displays
Not Approved
 although an approved algorithm is used.
With FIPS 140-3 license, management plane GUI and SSH session are created in FIPS and it will only allow usage of FIPS 140-3 supported ciphers. Refer to About FIPS supported ciphers.
The following are supported SSH ciphers:
Ciphers
MACS
Kex Algorithms
aes128-ctr
hmac-sha1
ecdh-sha2-nistp256
aes256-ctr
hmac-sha2-256
ecdh-sha2-nistp384
aes128-cbc
aes256-cbc
A service indicator is logged in
/var/log/audit
 logs, whenever any approved service is established using TMSH or GUI interface.

Configure service indicator logs

You can configure the BIG-IP system to enable service indicator logs for dataplane services in High-Speed Logging (HSL).
Follow the below steps to enable service indicator logs:
  • Configure a remote syslog server, for example Splunk, rsyslog, ipfix, or ArcSight.
  • Use the following tasks to configure a high-speed remote logging:
    • Create a node.
    • Create a pool of remote logging servers.
    • Create a remote high-speed log destination.
    • Create a formatted remote high-speed log destination.
    • Create a publisher.
  • Verify if the log level is set to
    Notice
     or higher in
    SSL
     field at
    System
    Logs
    Configuration
    Options
    .
  • Verify if the configured log publisher is selected in client SSL and server SSL profiles at
    Local Traffic
    Profiles
    SSL
    .

Create a node

Local traffic pools use nodes as target resources for load balancing. A node is an IP address or a fully-qualified domain name (FQDN) that represents a server resource that hosts applications.
An alternate way to create a node is to create a pool member. When you create a pool member, the BIG-IP system creates the corresponding node for you.
  1. On the Main tab, expand
    Local Traffic
    , and click
    Nodes
    .
    The Node List screen opens.
  2. Click the
    Create
     button.
    The New Node screen opens.
  3. For the
    Address
     field:
    1. If you want to specify the node by its IP address, click
      Nodes
       and type an IP address.
    2. If you want to specify the node by a fully-qualifed domain name (FQDN), click
      FQDN
       and type the node's FQDN.
  4. In the Configuration area of the screen, configure the settings as needed or retain the default values.
  5. If you chose
    FQDN
     for the
    Address
     setting, then in the FQDN area of the screen, configure the settings as needed or retain the default values.
  6. Click
    Finished
    .
    The screen refreshes, and the new node appears in the node list.

Create a pool of remote logging servers

Before creating a pool of log servers, gather the IP addresses of the servers that you want to include in the pool. Ensure that the remote log servers are configured to listen to and receive log messages from the BIG-IP system.
Create a pool of remote log servers to which the BIG-IP system can send log messages.
  1. At the top of the screen, click
    Configuration
    .
  2. On the Main tab, click
    Local Traffic
    Pools
    .
    The Pool List screen opens.
  3. Click
    Create
    .
    The New Pool screen opens.
  4. In the
    Name
     field, type a unique name for the pool.
  5. Using the
    New Members
     setting, add the IP address for each remote logging server that you want to include in the pool:
    1. Type an IP address in the
      Address
       field, or select a node address from the
      Node List
      .
    2. Type a service number in the
      Service Port
       field, or select a service name from the list.
      Typical remote logging servers require port
      514
      .
    3. Click
      Add
      .
  6. Click
    Finished
    .

Create a remote high-speed log destination

Before creating a remote high-speed log destination, ensure that at least one pool of remote log servers exists on the BIG-IP system.
Create a log destination of the
Remote High-Speed Log
 type to specify that log messages are sent to a pool of remote log servers.
  1. On the Main tab, click
    System
    Logs
    Configuration
    Log Destinations
    .
    The Log Destinations screen opens.
  2. Click
    Create
    .
  3. In the
    Name
     field, type a unique, identifiable name for this destination.
  4. From the
    Type
     list, select
    Remote High-Speed Log
    .
    If you use log servers such as Remote Syslog, Splunk, or ArcSight, which require data be sent to the servers in a specific format, you must create an additional log destination of the required type, and associate it with a log destination of the
    Remote High-Speed Log
     type. With this configuration, the BIG-IP system can send data to the servers in the required format.
    The BIG-IP system is configured to send an unformatted string of text to the log servers.
  5. From the
    Pool Name
     list, select the pool of remote log servers to which you want the BIG-IP system to send log messages.
  6. From the
    Protocol
     list, select the protocol used by the high-speed logging pool members.
  7. Click
    Finished
    .

Create a formatted remote high-speed log destination

Ensure that at least one remote high-speed log destination exists on the BIG-IP system.
Create a formatted logging destination to specify that log messages are sent to a pool of remote log servers, such as Remote Syslog, Splunk, or IPFIX servers.
  1. On the Main tab, click
    System
    Logs
    Configuration
    Log Destinations
    .
    The Log Destinations screen opens.
  2. Click
    Create
    .
  3. In the
    Name
     field, type a unique, identifiable name for this destination.
  4. From the
    Type
     list, select a formatted logging destination, such as
    Remote Syslog
    ,
    Splunk
    , or
    IPFIX
    .
    The Splunk format is a predefined format of key value pairs.
    The BIG-IP system is configured to send a formatted string of text to the log servers.
  5. If you selected
    Remote Syslog
    , then from the
    Syslog Format
     list select a format for the logs, and then from the
    High-Speed Log Destination
     list, select the destination that points to a pool of remote Syslog servers to which you want the BIG-IP system to send log messages.
    For logs coming from Access Policy Manager (APM), only the BSD Syslog format is supported.
  6. If you selected
    Splunk
     or
    IPFIX
    , then from the
    Forward To
     list, select the destination that points to a pool of high-speed log servers to which you want the BIG-IP system to send log messages.
  7. Click
    Finished
    .

Create a publisher

Ensure that at least one destination associated with a pool of remote log servers exists on the BIG-IP system.
Create a publisher to specify where the BIG-IP system sends log messages for specific resources.
  1. On the Main tab, click
    System
    Logs
    Configuration
    Log Publishers
    .
    The Log Publishers screen opens.
  2. Click
    Create
    .
  3. In the
    Name
     field, type a unique, identifiable name for this publisher.
  4. For the
    Destinations
     setting, select a destination from the
    Available
     list, and click
    <<
     to move the destination to the
    Selected
     list.
    If you are using a formatted destination, select the destination that matches your log servers, such as Remote Syslog, Splunk, or ArcSight.
  5. Click
    Finished
    .

About Platform FIPS installation kit overview

The Platform FIPS system includes the Full-Box FIPS add-on license, which includes tamper evidence seals that you must apply to the chassis for it to be FIPS-validated. For more information, see F5 Platforms: FIPS Kit Installation.

About Platform FIPS best practices

F5 recommends these best practices for working with your Platform FIPS system:
Backup partitions
To recover from a self-test failure, F5 recommends that you have at least two volumes configured and set up with the software version that you are using on the BIG-IP system. If possible, you should avoid installing the Platform FIPS add-on license on the backup volume. This provides recovery options from a failed self-test.
The BIG-IP system should have multiple volumes set up from the factory, but the software versions installed might not support the Platform FIPS license. Be sure to verify the versions before placing the BIG-IP system into production use.
The
sys-eicheck
 utility
Use the
sys-eicheck
 utility to determine, without rebooting and locking the volume, if anything has happened that might cause the integrity test to fail. Run this utility before and after any administrative actions to identify anything that might cause a self-test failure by typing this command sequence on the command line:
/usr/libexec/sys-eicheck.py
.
FIPS Validated vCMP Guests
On certain BIG-IP platforms and VIPRION platforms that are licensed with the Platform FIPS add-on license, any vCMP guests are also considered vCMP validated. Unless the platform is also an Embedded FIPS platform, no additional administration is needed. For more information, see the About FIPS multi-tenancy for vCMP guests section under Hardware HSM Setup and Administration.

About sys-eicheck utility

The
sys-eicheck
 utility is the FIPS version of the
sys-icheck
 utility. The
sys-eicheck
 utility scans the BIG-IP system for any unexpected changes to the system software.
The
sys-eicheck
 utility is installed with all BIG-IP systems, but it only runs automatically on systems that are licensed for the F5 Full-Box FIPS add-on. The system runs the
sys-eicheck
 utility for the power-on and daily self-tests required for FIPS validation.
You can also run it manually to determine if the device will pass or fail the tests. Log in to the command-line console as an administrator and use the command
/usr/libexec/sys-eicheck.py
 to manually run the
sys-eicheck
.
You can run the
sys-eicheck
 command on any system, but results return only for those systems licensed with the F5 Full-Box FIPS add-on.
Run
Actions
On power-on
On Pass: No action
On Fail: Logs details to the
/config/f5_public/fipserr
 file, stops the boot process, and reports a failure on the console
Daily
Logs the following result to the
/var/log/secure
 file:
Pass:
BIG-IP Integrity Check: [ PASS ]
Fail:
BIG-IP Integrity Check: [ FAIL ] -- Contact F5 Networks technical support
Manually
Displays results and details on the console
For QKView
Adds detailed results to the
QKview /fips_module.xml
 file
The
sys-eicheck
 output contains the following two sections and a summary:
  • Critical files missing
  • Critical files modified
If the
sys-eicheck
 utility displays a fail status, the system will not boot to the current volume the next time it restarts. Make sure to resolve any fail issues before you restart the BIG-IP system. For troubleshooting information, refer to Troubleshoot FIPS self-test failures.
The utility only considers missing or modified critical files as failures. The output contains non-critical files for informational purposes only.
The system shows
PASS
 or
FAIL
 messages with the output. The following is an example output:
 BIG-IP Integrity Check Report
 - Critical file modifications result in failure.
 =======================================================
 /usr/lib/python2.7/site-packages/rw_lib.py
 1 critical file(s) missing
 =======================================================
 0 critical file(s) modified
 =======================================================
 Integrity Check Result: [ FAIL ]
 Contact F5 Networks Technical Support.

About FIPS self tests

The FIPS validation requires the use of self tests to check the integrity and operation of the cryptographic module. If any of these tests fail during the boot process, the BIG-IP system halts. The
fips_monitor
 daemon is introduced in BIG-IP software version 13.1.0 and monitors the
/config/f5_public/fipserr
 file for any reported errors. The
fips_monitor
 daemon monitors the BIG-IP system and halts the system if FIPS-specified issues are found. This table explains the three basic categories of tests and the action taken when a test fails.
Type of self test
When the self test runs
Checks performed
Action on fail
System Integrity check (
sys-eicheck
)
  • On start
  • Daily using a cron job
  • Manually
Checks the system software on the BIG-IP system to detect unexpected changes to the system software, such as modified or missing critical and non-critical files.
If the test fails during the boot process, the details are logged to the
/config/f5_public/fipserr
 file, and the BIG-IP system immediately halts. If the test fails at any other time, this error message displays in the
var/log/secure
 file, and the system halts on the next restart:
<datetime> <pid> crit root: BIG-IP Integrity Check: [FAIL] -- Contact F5 technical support.
Crypto-Algorithm check
  • On start
Checks the SSL cryptographic libraries to ensure they are correctly performing cryptographic operations.
Details are logged to the
/config/f5_public/fipserr
 file, and the BIG-IP system immediately halts.
TMM check
  • On start
  • When TMM errors occur during normal operation
Checks the Traffic Management Microkernel (TMM) for problems.
Details are logged to the
/config/f5_public/fipserr
 file, and the BIG-IP system immediately halts.
If the BIG-IP system halts during the boot process, this message appears on the console indicating the system halted due to a failure of one of the pre-operational self-tests:
*** FIPS or Common Criteria  pre-operational self-test failure.
*** This system has been placed in an error state.
*** To recover return to the grub menu and select another volume.
*** or reinstall the system.
***
*** On many devices pressing the escape key followed by the (
*** key will bring up a menu which allows the system to be restarted.
If the BIG-IP system halts during the boot process you must either boot to another volume or reinstall the system software to recover and reload the configuration. If your BIG-IP system failed a system integrity check and is still running, you should run the
sys-eicheck
 utility manually (
/usr/libexec/sys-eicheck.py
) and correct any problems before restarting the system. If you suspect your system is compromised, you should follow your organization's security policies for suspected compromised systems.
Power-up self-test failures:
<specific test failures>
If the FIPS enabled BIG-IP system is downgraded to an earlier version or running
big3d_install
 from a BIG-IP DNS configuration pointing to FIPS licensed BIG-IP LTM configuration, where BIG-IP DNS is running a higher software version than BIG-IP LTM, then the system fails during the boot-up process. The system integrity check reports a
libcrypto
 validation error, and the system halts. To avoid this issue, delete the
/shared/bin/big3d
 before downgrading the version.
If the system boots to a halted state, then refer the instructions in K25205233: BIG-IP System halted while booting. Halt at boot after FIPS Integrity Check Result FAIL, in addition to deleting
/shared/bin/big3d
.
For Platform FIPS systems, output from the
sys-eicheck
 utility is included by default in the
/fips_module.xml
 file when running the
qkview
 utility. Other systems can capture the output from the
sys-eicheck
 utility when running the
qkview
 utility by running the
qkview -c
 command.

About the Platform FIPS self-test requirement

The NIST 140-3 FIPS standards require that the system must pass a series of self tests during operation and at initial startup. If any of these self-tests fail, the BIG-IP system restarts and will not be able to boot into that volume at startup.
One of the self-tests that the system performs is a system integrity test. This test watches for unauthorized changes to the system. Making changes to the system using the F5 TMOS Shell (
tmsh
), the Configuration utility, and the F5 APIs does not cause this test to fail. Making any changes to the underlying operating system or any BIG-IP files directly, however, might cause the test to fail.

About FIPS error state mode

A cryptographic module performs power-up self-tests and conditional self-tests to ensure that the module is functioning properly. The module performs power-up self-tests when the cryptographic module is powered up and conditional self-tests when an applicable security function or operation is invoked, that is, the security functions for which self-tests are required.
If a cryptographic module fails a self-test, the module enters an error state mode and outputs an error indicator through the status output interface. The cryptographic module does not perform any cryptographic operations while in an error state mode. All data output through the data output interface is inhibited when an error state exists. If a self-test fails, make sure that no crypto operations are performed.
The BIG-IP system attempts to recover from error state mode by triggering a reboot. If the error state persists after multiple reboots, then the system falls back to the
brick the box
 state.

About determining whether a system is compromised

When determining whether your system is compromised, consider these factors:
  • F5 might not be able to make a final determination whether a device is compromised if it requires deeper forensic analysis than F5 support procedures allow. If this occurs, you should contact a trusted forensic security firm for a final determination of whether the device is compromised.
  • For integrity check issues, you should base your final determination on whether your BIG-IP system is compromised based on your organization's security policy. If you are unable to determine any known administrative changes that happened during the failure time window, you should review and follow your organization's policies and procedures for suspected compromised devices.
  • For cryptographic and Traffic Management Microkernel (TMM) self-test issues, you should base your final determination on whether your system is compromised based on your organization's security policy; however, these issues are less likely to happen due to your system being compromised than due to other issues. If this occurs, contact F5 Technical Support to determine whether the cause of the issue is due to a known issue or system bug.

About FIPS self-test failures

On BIG-IP systems that include the F5 Full-Box FIPS add-on license, you can manually perform FIPS integrity checks. The system automatically performs scheduled checks on a regular basis. Manual check results display on the console, and scheduled checks log to the /var/log/secure file. If an integrity check fails, the system fails to boot when restarted.
An integrity check failure indicates that some part of the BIG-IP software has unexpectedly changed. This might indicate that an attacker has gained access to your system and changed, installed, or removed something on the BIG-IP system. You should review your internal security policies prior to taking any further actions as they might require or prohibit specific troubleshooting procedures.

Troubleshoot FIPS self-test failures

You should consider running FIPS integrity checks when a BIG-IP system that is licensed for F5 Full-Box FIPS is operating and accessible, and these conditions occur:
  • A
    BIG-IP Integrity Check: [ FAIL ] -- Contact F5 Networks technical support
     error displays in the
    /var/log/secure
     file.
  • A manual integrity check fails.
If the FIPS integrity check displays a fail status, the BIG-IP system will not boot to the current volume the next time it restarts. Therefore, it is important that you resolve any issues before you restart your system to determine the root cause.
Do not restart your BIG-IP system during these troubleshooting steps. When the BIG-IP system starts, it performs an integrity test again, and if this test fails, the system stops the boot process and disables that volume, restricting further troubleshooting. If this occurs, you must perform a pre-operational self test. For more information, see Troubleshoot FIPS pre-operational self-test failures.
If your system fails an integrity check when you power it on and does not complete the boot procedure, see Troubleshoot FIPS pre-operational self-test failures.
  1. Back up your system configuration to a user configuration set (UCS) file.
    For more information, see K13132: Backing up and restoring BIG-IP configuration files (11.x - 13.x).
    Consider including the cause of the failure in your UCS file when you back up your system.
  2. Create a QKView file using the
    qkview
     utility and upload it to F5 Technical Support using BIG-IP iHealth.
  3. Run the
    sys-eicheck
     utility to locate the failed files.
    For more information, see About sys-eicheck utility.
  4. Determine the time window of the failure.
    BIG-IP systems licensed with the F5 FIPS Full-Box run the
    sys-eicheck
     utility daily and log to the
    /var/log/secure
     file. Note the time stamp on the first
    BIG-IP Integrity Check: [ FAIL ] -- Contact F5 Networks technical support
     message and the time stamp of the last successful check from the most recent
    BIG-IP Integrity Check: [ PASS ]
     message. The period between the two messages is the failure time window.
  5. Review administrative actions during the failure time window.
    1. Review the list of changed files to narrow the potential actions that might impact them.
      For example, if system files were removed or changed, administrative actions are unlikely to impact them.
    2. Review any known administrative actions that occurred within the time window. To determine this, use information from these sources:
      • Internal change control or trouble ticket documentation
      • The BIG-IP audit log file at
        /var/log/audit
      • Other BIG-IP logs, as appropriate
    Normal administrative actions performed using the Configuration utility or TMOS Shell (
    tmsh
    ) commands should not cause integrity checks to fail. The most likely causes of failure are actions to troubleshoot problems or actions that might impact the underlying Linux operating system, such as installing or modifying the Linux system software.
  6. Back out changes made during the failure time window.
    If any administrative actions occurred during the time window, consider backing out these changes and running the integrity check again. Depending on the actions, you might not be able to back out the changes. If you cannot back out these changes, you might need to reload the system configuration on a new partition using your UCS file.
    After backing out changes, run the
    sys-eicheck
     utility again to determine whether the problem is resolved.
  7. Reload your backup file on a new partition.
    Do not use your only remaining backup partition. Doing so might restore the problem along with the UCS on that partition, making it also unusable and potentially making it impossible to restart and boot the system. If this occurs, you need to re-image your system.
    If the problem is not resolved before booting into the new partition, you will not be able to access the current partition again. You should perform this action only as a last resort if you cannot otherwise resolve the issue.
    1. Create a new partition with the appropriate software version. For more information, see K34745165: Managing software images on the BIG-IP system using the tmsh utility.
    2. Restore your UCS backup to this partition. For more information, see K13132: Backing up and restoring BIG-IP configuration files (11.x - 13.x).
    Reloading your UCS file on a new partition might not solve the issue. If it does not, it is possible that the cause of the problem is included in your UCS file.
  8. Determine whether your system is compromised using your organization's security policy.
    If you are unable to determine any known administrative changes that occurred during the failure time window, review and follow your organization's policies for devices that are suspected of being compromised. You can then open a support ticket with F5 Technical Support. For more information, see About determining whether a system is compromised.

About pre-operational FIPS self-test failures

On BIG-IP systems that include the F5 Full-Box FIPS add-on license, you can manually perform FIPS integrity checks. The system automatically performs scheduled checks on a regular basis. Manual check results display on the console, and scheduled checks log to the /var/log/secure file. If an integrity check fails, the system fails to boot when restarted.
An integrity check failure indicates that some part of the BIG-IP software has unexpectedly changed. This might indicate that an attacker has gained access to your system and changed, installed, or removed something on the BIG-IP system. You should review your internal security policies prior to taking any further actions as they might require or prohibit specific troubleshooting procedures.

Troubleshoot FIPS pre-operational self-tests failures

When a BIG-IP system that is licensed for F5 Full-Box FIPS fails to boot due to failed self tests, you can recover the system. If any of these self-tests fail, the system halts. In addition, the system regularly performs some self-tests and might force an immediate restart, which results in a halted system. Because of this, you might encounter one or more of these symptoms:
  • The BIG-IP system fails to boot to the active partition
  • You observe an error similar to the this example on the console:
    The FIPS or Common Criteria power-up self-test failure. This system has been placed in an error state.
For longer errors, you might have to scroll up to see them.
If your BIG-IP system is operating and you see a log entry for an integrity check failure, see Troubleshoot FIPS self-test failures.
  1. Change the system boot location and boot to an alternate partition.
    1. Immediately after you start the system, a screen displays notifying to select a boot partition to use. Select any partition other than the currently-selected one.
    2. If you need to restore your system configuration from a backup, or if you intend to copy the configuration using the
      cpcfg
       command, make sure you have another available partition in case the issue is restored along with the backup configuration. For more information about the
      cpcfg
       command, see K14724: Using the cpcfg command to copy a configuration from one boot location to another.
    3. If necessary, perform a switchboot operation to make sure that the new partition becomes the default choice. For more information, see K5658: Overview of the switchboot utility.
  2. Perform a clean installation by re-imaging the BIG-IP system.
    Re-imaging the BIG-IP system overwrites the entire storage drive. After you re-image the system, you cannot perform any further troubleshooting to determine the cause of the issue.

About FIPS supported ciphers

In the FIPS-enabled mode, the system automatically reorganizes the Secure Sockets Layer (SSL) cipher suites so that the FIPS-approved cipher suites appear at the top of the list as the most preferred ciphers.
The FIPS 140-3 does not support generating new RSA 512-bit, RSA 1024-bit, EC 521-bit, DSA, and SM2 keys. These algorithms are restricted, do not use them to generate keys when upgraded from BIG-IP 16.1.2 or earlier versions to the latest BIG-IP version.
The following system daemons start in FIPS-enabled mode:
  • bigd
  • chmand
  • devmgmtd
  • fipscheck
  • httpd
  • mcpd
  • named
  • ntpd
  • openssl
  • raccoon
  • sshd
  • tamd
  • tmm
In the FIPS-enabled mode, the daemons use the following cipher list:
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-ECDSA-AES256-SHA384
In the FIPS-enabled mode, the Client SSL and Server SSL profiles continue to use the cipher keyword
DEFAULT
.
The BIG-IP system has the following two cipher string keywords:
  • FIPS
     : This cipher string keyword selects only FIPS-compliant cipher suites.
  • @FIPS
     : This keyword orders cipher suite preference to use FIPS-compliant cipher suites first.
To use only FIPS-compliant cipher suites, do the following:
  • In advanced configuration mode for the profile, change the cipher string from
    DEFAULT
    to
    FIPS
    .
To use only FIPS-compliant cipher suites and with the cipher suites sorted from the most to the least recommended, do the following:
  • In advanced configuration mode for the profile, use the
    FIPS:@FIPS
     cipher string in the profile.
The FIPS cipher string loads the FIPS-compliant ciphers, and the
@FIPS
 action keyword reorders the cipher suites to prefer the strongest FIPS-compliant ciphers first.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information