No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

Improved Role-Based Log Access

WebSocket Traffic Compression Support in WebSocket Preserve Mode

WAF inspection is provided for compressed WebSocket traffic while preserving end-to-end compression and without suppressing compression on the traffic handshake.

Enhance WAF declarative policy supports external reference configurations and file transfer to Continuous Integrations / Continuous Delivery (CI/CD) Servers for CI/CD Cycle Support

To enable management of a policy configuration in multiple policy files, support for external references was added to the declarative API.

When importing declarative policy in CMI cluster (device group), all supported references will be downloaded by the master node, for both "file" and "http(s)" links, and will be distributed to all peers, rather than downloaded on each peer.

OpenAPI Coverage Improvements

ASM uses a multipart/form-data media type understand that a URL might be configured to have a multipart payload. This ability already existed but it was part of the "form" content type and not a type of its own.

Support for multipart/form-data media type is done to distinguish between multipart file uploads and payload file uploads, which allows the parameters in the multipart (possibly several uploads) to be seen as an object or an array.

Another related addition is the upload type for the URL. This means the URL payload is a binary upload (such as a gif). For that data type, ASM looks for illegal uploads (exe files, etc.) just as it does in a binary file upload that is part of a multipart request.

Custom Signatures and Signature Sets

Support has been added for the creation of custom signatures and custom signature sets. The additional options in the WAF declarative policies improve policy coverage, readability, and life cycle maintenance.

HTTP Desync mitigation against repeated headers

To mitigate HTTP desync attacks using multiple headers with the same name, support for repeated occurrences header check configurable by header type was added. This is used to stop desync and similar attacks in which the request structure is interpreted in different ways on Advanced WAF and the target server, leading to request splitting where sneaking malicious requests can escape WAF inspection.

The feature is enabled by the Allow Repeated Occurrences field and is configurable under Security > Application Security > Headers > HTTP Headers .

Insertion of security headers for all internal HTTP responses

By default, it is possible to include all necessary security headers as a part of all HTTP responses of fictive, BIG-IP ASM pages, that are not a part of the original application, e.g. blocking page, CAPTCHA, and all other fictive URLs of ASM, including BOT Defence, and L7DOS.

By default:

To turn it off:

Signature filtering by CVE

A Signature CVE filter option was added in the REST API.

Automatic Transactions detection has been added to DataSafe

BIG-IP DataSafe now checks for automated manipulation of data in URL parameters and AJAX requests. Automatic transactions detection is particularly useful on web pages where money transfers are performed, which are popular targets of malware web robots. On a page like this, automatic transactions detection can check for data manipulation in the destination account number and/or the amount of money to be transferred, and send an alert if manipulation is detected.

No new features

There are no new features specific to this product area.

Additional Support for Privileged User Access

This release includes a native implementation supporting UI-based administrative configuration of Privileged User Access with Ephemeral Authentication (temporary passwords). Privileged User Access lets you add CAC authentication (Common Access Card), Personal Identity Verification (PIV), or other strong authentication method to provide secure access to network infrastructure. This solution integrates directly into DoD PKI systems and works cooperatively with existing RADIUS, TACACS, Active Directory, and a variety of third-party authentication databases.

Privileged user access deployment relies on three components: APM configured as an ephemeral authentication server, a WebSSH proxy for an interface between web clients and legacy systems, and an authentication server (LDAP/RADIUS). All configuration can now be done from the APM interface. For a detailed use case, refer to BIG-IP APM: Securing Privileged User Access.

Guided Configuration Updates

Guided Configuration for BIG-IP Access Policy Manager (APM) provides simple, workflow-driven configuration templates for common use case scenarios. Using the templates, you can configure policies to implement complex scenarios such as Zero Trust-Identity Aware Proxy, API Protection, Microsoft Integration, and Federation Single Sign On more easily.

Guided Configuration 7.0 includes enhancements for BIG-IP release 16.0. It now has a new Azure AD Application template that integrates with Microsoft Azure AD to provide secure and seamless access for modern and classic mission-critical applications. Also, the Identity Aware Proxy scenario now allows easier access to corporate applications through a webtop and Okta Factors API. Guided Configuration now includes modern customization features and the ability to select a previously configured virtual server. Refer to the Release Notes for Guided Configuration 7.0 for details on the enhancements.

Okta MFA using Factors API

APM now integrates with Okta Factors API to enroll and verify factors for multifactor authentication (MFA). You can manage authorization and access to applications and resources using Okta Verify (TOTP/Push) and YubiKey OTP factors. On APM, an Okta Connector defines Okta API parameters for the domain and API token. You implement second factor authentication in an APM per-request policy by adding an Okta MFA agent to a subroutine. For details on configuration, refer to BIG-IP APM: Implementing Zero Trust with Per-Request Policies.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

Sample installation command

The following command installs version 16.0.0 to volume 3 of the main hard drive.

tmsh install sys software image BIGIP-16.0.0.0.0.12.iso volume HD1.3 

Notes

The upgrade process does not update Tcl scripts (such as iRules) in the configuration. This might cause issues when iRule syntax changes between releases. After upgrading, you might need to modify iRules to reflect any changes in iRule syntax.

Upgrading from version 14.x or later

When you upgrade from version 14.x or later, you use the Software Management screens in the Configuration utility to complete these steps. To open the Software Management screens, in the navigation pane of the Configuration utility, expand System, and click Software Management. For information about using the Software Management screens, see the online help.

Upgrading from versions earlier than 14.x

You cannot roll forward a configuration directly to this version from BIG-IP version 13.x or earlier. You must be running version 14.x (or later) software. For details about upgrading from earlier versions, see the release notes for the associated release.

Automatic firmware upgrades

If this version includes new firmware for your specific hardware platform, after you install and activate this version, the system might reboot additional times to perform all necessary firmware upgrades.

Upgrade warnings and notes

The Application Security Manager supports .ucs files from versions 10.1.0 and later of the Application Security Manager. Additionally, you may import policies exported from versions 10.1.0 and later of the Application Security Manager.

Warning: With the introduction of the Local Traffic Policies feature in BIG-IP version 11.4.0, HTTP Class iRule events and commands are no longer available. If you plan to upgrade to 11.4.0 or later, and your configuration contains an iRule that uses an HTTP class iRule event or command, please read K14381: HTTP Class iRule events and commands are no longer available in BIG-IP 11.4.0 and later.

Warning: Local Traffic Policies do not support regular expressions for matching. While the upgrade process is able to migrate simple glob expressions, manual administrator intervention is required in order to ensure that the policies are properly configured. If you plan to upgrade to 11.4.0 or later, and your configuration contains regular expressions or glob expressions, please read K14409: The HTTP Class profile is no longer available in BIG-IP 11.4.0 and later.

Important: The system creates its internal cookie in versions 10.2.4 and later (including all versions of 11.x) differently than in versions prior to 10.2.4. As a result, while upgrading your system from a version prior to 10.2.4 to version 10.2.4 or later, the system will produce the Modified ASM Cookie violation for existing browser sessions. If the security policy has the Modified ASM Cookie violation enabled and set to block traffic when this violation occurs, after upgrading to version 10.2.4 or later, the system will block traffic to the web application. However, since the TS cookie is a session cookie, the system will block traffic only until the browser session ends (the end-user restarts the browser). To prevent the security policy from blocking traffic until the end-user’s browser is restarted, before upgrading to version 10.2.4 or later, we recommend you disable the security policy from blocking the Modified ASM Cookie violation, upgrade, and wait long enough to allow all users to restart their browsers (two weeks are expected to be enough). After enabling the violation, we recommend you monitor the logs. If the Modified ASM Cookie violation appears, consider disabling the violation again for a longer period of time, or communicate to the users to restart their browsers.

Exporting Logs

Layer 7

In version 11.4.0, local traffic policies replace HTTP Classes. When you create an ASM security policy, the system automatically creates a default Layer 7 local traffic policy. Note the following changes that occur to your system after upgrading from a version prior to 11.4.0:

• A Layer 7 local traffic policy is created and the HTTP class is removed. If the HTTP Class name is different than the name of the security policy, upon upgrade, the system changes the name of the security policy to the name of the HTTP Class.
• Security policies are now in folders (partitioned) like pools and virtual servers. Upon upgrade, the system places security policies in the folder to which the HTTP Class belonged. The system places security policies that were inactive in the /Common folder.
• iRules that use HTTP Class do not work here. Users must manually change the HTTP Class part of the iRule to Policy after the upgrade.

ASM cookie security

As a result of changes made to the signing of ASM cookies, performing a clean upgrade may result in cookie violations and blocked traffic. To prevent these, F5 recommends that you perform the following actions before upgrading:

• Disable the modified domain cookie violation, and re-enable it only after at least 24 hours have passed.
• If you do not have a wildcard cookie, before the upgrade add an ASM allowed cookie to the security policy, with the name TS*.
• Have all clients restart their browsers.

After upgrading, users must synchronize their Cookie Protection settings in the following cases:

• Systems that share traffic but are NOT in the same device group
• Systems from different versions that share traffic, even if they are in the same device group

Cookie signature validation

After upgrading, the system performs the following:

• Turns on staging for all Allowed cookies
• Applies signature checks on existing Allowed cookies
• Adds a * wildcard Allowed cookie even if the user did not have on previously Upgrading to version 11.3.0 or later

Web scraping

There was a check box for enabling web scraping that was removed in version 11.3.0.

• When you upgrade from versions 11.0.0 through 11.2.x, if the check box is enabled, the new Bot Detection setting has the option Alarm and Block enabled. If the check box is not enabled, the value is Off.
• When you upgrade from versions prior to 11.0.0 (where there was no enable flag), the Bot Detection setting is based on the blocking check boxes for web scraping:
  • If the global Block check box is enabled, the value is Alarm and Block.
  • If the global Block check box is disabled, and the global Alarm check box is enabled, the value is Alarm.
  • If both Alarm and Block check boxes are disabled, the value is Off.

Brute Force

In versions prior to 11.3.0, if the Dynamic Brute Force Protection Operation Mode was Blocking, and the security policy’s Enforcement Mode was Transparent, the system blocked brute force attacks. In order to keep functionality after upgrading, the system continues to block brute force attacks if you upgrade to versions 11.3.0 or later, under these circumstances. However, in versions 11.3.0 and later, the functionality changed so that if the security policy’s Enforcement Mode is Transparent, so the system does not block brute force attacks even if the Dynamic Brute Force Protection Operation Mode setting is Alarm and Block (previously Blocking).

In version 13.1 the session-based and dynamic brute force protections are discontinued and replaced with source-based brute force protection. When upgrading:

• Source-based mitigation will be set to Alarm and CAPTCHA for Username, Device IP and Source ID.
• Dynamic mitigation will be set to Alarm and CAPTCHA.
• Client Side Integrity Bypass Mitigation will be set to Alarm and CAPTCHA.
• CAPTCHA Bypass Mitigation will be set to Alarm and CAPTCHA.
• Detection and prevention duration will be derived from previous values.
• Enforcement of both the source-based and distributed brute force protections depends on the Blocking settings of the Brute Force: Maximum login attempts are exceeded violation.
• The Learning flag for Brute Force: Maximum login attempts are exceeded violation is discontinued.
• The Unlimited value for Prevention Duration is discontinued.

DoS profiles

In versions 11.3.0 and later, DoS profiles are assigned to virtual servers. Previously, they were assigned to security policies.

• Upon upgrading DoS Profiles from versions prior to 11.3.0, all active security policies have their DoS settings migrated and assigned to the virtual server associated with the HTTP Class. If a virtual server had more than one HTTP Class assigned to it, it inherits the settings of the last in the list.
• If you have a disabled DoS profile in a version prior to 11.3.0, and upgrade, after the upgrade the system automatically assigns the DoS profile to a virtual server. As a result, even though the system does not perform DoS protection, it still collects statistics, which impacts the system’s performance. To work around this issue, if you have a disabled DoS profile assigned to a virtual server, to improve system performance you should remove its association from the virtual server. (ID 405211)
• We do not support exporting and importing DoS profiles.

Logging Profiles

In versions 11.3.0 and later, logging profiles are assigned to virtual servers. Previously, they were assigned to security policies. Upon upgrading logging profiles from versions prior to 11.3.0, all active security policies have their logging profile settings migrated and assigned to the virtual server associated with the HTTP Class. If a virtual server had more than one HTTP Class assigned to it, it inherits the settings of the last in the list.

XFF configuration (ID 405312)

In versions prior to 11.3.0, DoS profiles used the Trust XFF setting that was a security policy setting. The Trust XFF setting was renamed Accept XFF, and moved from a security policy property to a property of the HTTP profile. If you upgrade a DoS profile and a security policy with the Trust XFF setting enabled, after the upgrade, the new XFF configuration setting is disabled. If you want the DoS profile to continue trusting XFF, navigate to Local Traffic > Profiles > Services > HTTP > Properties screen, and enable the Accept XFF setting.

IP address whitelist

In version 11.2 we unified various whitelists for Policy Builder trusted IP addresses, and anomaly whitelists (DoS Attack Prevention, Brute Force Attack Prevention, and Web Scraping Detection) into a single list. When you upgrade, these separate lists are unified to a single whitelist (called the IP Address Exceptions List).

Security policy status after UCS installation

After you install a .ucs (user configuration set) file that was exported from version 10.1.0 or later, the system does not automatically apply changes that you made, but did not apply, to the security policies. The system enforces the web application according to the settings of the last set active security policy. However, the system preserves any changes to the current edited security policy, and marks the security policy as modified [M] if the changes have not been applied.

Running Application Security Manager on a vCMP system

If you are running Application Security Manager on a vCMP system: For best performance, F5 recommends configuring remote logging to store ASM logs remotely on Syslog servers rather than locally.