Release Notes : BIG-IP ASM 13.0.0 Release Notes

Applies To:

Show Versions Show Versions


  • 13.0.0
Release Notes
Original Publication Date: 07/17/2017 Updated Date: 04/18/2019


These release notes document the version 13.0.0 release of BIG-IP Application Security Manager (ASM). You can apply the software upgrade to systems running software versions 11.x or 12.x.


Platform support

This version of the software is supported on the following platforms:

Platform name Platform ID
BIG-IP 6900 FIPS D104
BIG-IP 11000 E101
BIG-IP 11050, 11050 NEBS E102
BIG-IP 2000 Series (2000s, 2200s) C112
BIG-IP 4000 Series (4000s, 4200v) C113
BIG-IP 5000 Series (5000s, 5050s, 5200v, 5250v) C109
BIG-IP 7000 Series (7000s, 7050s, 7055, 7200v, 7250v, 7255) D110
BIG-IP 10050 Series (10150s-NEBS, 10350v (AC), 10350v-NEBS, 10350v-FIPS) D112
BIG-IP 10000 Series (10000s, 10050s, 10055, 10200v, 10250v, 10255) D113
BIG-IP 12000 Series (12250v) D111
BIG-IP i2000 Series (i2600, i2800) C117
BIG-IP i4000 Series (i4600, i4800) C115
BIG-IP i5000 Series (i5600, i5800) C119
BIG-IP i7000 Series (i7600, i7800) C118
BIG-IP i10000 Series (i10600, i10800) C116
VIPRION B2100 Blade A109
VIPRION B2150 Blade A113
VIPRION B2250 Blade A112
VIPRION B4300, B4340N Blade A108, A110
VIPRION B4450 Blade A114
VIPRION C2200 Chassis D114
VIPRION C2400 Chassis F100
VIPRION C4480, C4480N Chassis J102, J103
VIPRION C4800, C4800N Chassis S100, S101
Virtual Edition (VE) Z100
vCMP Guest Z101

These platforms support various licensable combinations of product modules. This section provides general guidelines for module support.

Most of the support guidelines relate to memory. The following list applies for all memory levels:

  • vCMP supported platforms
    • VIPRION B2100, B2150, B2250, B4200
    • VIPRION B4300 blade in the C4480(J102) and the C4800(S100)
    • VIPRION B4450 blade in the C4480(J102) and C4800(S100)
    • BIG-IP 5200v, 5250v, 7200v, 7250v, 10200v, 10250v, 10350v, 12250v
    • BIG-IP i5800, i7800, i10800

Memory: 12 GB or more

All licensable module-combinations may be run on platforms with 12 GB or more of memory, and on VE and vCMP guests provisioned with 12 GB or more of memory. Note that this does not mean that all modules may be simultaneously provisioned on all platforms with 12 GB or more of memory. The BIG-IP license for the platform determines which combination of modules are available for provisioning.

Memory: 8 GB

The following guidelines apply to the BIG-IP 2000s, 2200s, 6900 platforms and to VE guests configured with 8 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus does not fit in this category.)

  • No more than three modules should be provisioned together.
  • On the 2000s and 2200s, Application Acceleration Manager (AAM) can be provisioned with only one other module.
  • To use Access Policy Manager (APM) and Secure Web Gateway (SWG) modules together on platforms with exactly 8 GB of memory, Local Traffic Manager (LTM) provisioning must be set to None.

Memory: Less than 8 GB and more than 4 GB

The following guidelines apply to platforms, and to VE and vCMP guests provisioned with less than 8 GB and more than 4 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus fits in this category.)

  • No more than three modules (not including AAM) should be provisioned together.
  • Application Acceleration Manager (AAM) cannot be provisioned with any other module; AAM can only be provisioned standalone.
  • Analytics (AVR) counts towards the two module-combination limit (for platforms with less than 6.25 GB of memory).

Memory: 4 GB or less (VE only)

The following guidelines apply to VE instances provisioned with 4 GB or less of memory.

  • No more than two modules may be configured together.
  • AAM should not be provisioned, except as Dedicated.
  • ASM can be provisioned with this amount of memory, but a sizing exercise should be performed to ensure that it does not hit capacity issues.

vCMP memory provisioning calculations

The amount of memory provisioned to a vCMP guest is calculated using the following formula: (platform_memory- 3 GB) x (cpus_assigned_to_guest / total_cpus).

As an example, for the B2100 with two guests, provisioned memory calculates as: (16-3) x (2/4) ~= 6.5 GB.

For certain platforms, the vCMP host can allocate a single core to a vCMP guest. However, because a single-core guest has relatively small amounts of CPU resources and allocated memory, F5 supports only the following products or product combinations for a single-core guest:
  • BIG-IP LTM standalone only
  • BIG-IP GTM standalone only
  • BIG-IP LTM and GTM combination only

Configuration utility browser support

The BIG-IP Configuration Utility supports these browsers and versions:

  • Microsoft Internet Explorer 11.x
  • Mozilla Firefox v40, or later
  • Google Chrome v44, or later

Compatibility of BIG-IQ products with BIG-IP releases

K14592: Compatibility of BIG-IQ products with BIG-IP releases provides a summary of version compatibility for specific features between the BIG-IQ system and BIG-IP releases.

User documentation for this release

For a comprehensive list of documentation that is relevant to this release, refer to the BIG-IP ASM / VE 13.0.0 Documentation page.

Release fixes, behavior changes, and known issues

For a comprehensive list of fixes, behavior changes, and known issues for this release, refer to the BIG-IP 13.0.0 Release Information page.

New in 13.0.0

This release includes the following new items.

Layered Policies

Security policies can now be created in a hierarchical manner with a parent and child policies. This allows for quicker policy creation and learning. A security policy can be created in two ways:
  1. Security Policy: This is similar to previous releases of an ASM security policy which can be applied to any relevant virtual server.
  2. Parent Policy: This is a new type of policy which enables the user to create a higher level policy to act as a template for its attached child policies.
Using a parent policy, the administrator can perform several tasks:
  • Change a single parent policy and simultaneously propagate the changes to the attached child policies.
  • Endow specific security properties to child policies by setting the properties as Mandatory inheritance in the parent policy.
  • Allow the user to accept or decline parent security properties set as Optional.
  • Leave the inheritance option open for the lower level administrator to configure as desired.
  • Disconnect a child policy from its parent.

Layered policies are not meant to prevent a user from bypassing a parent-level policy but, rather, to make it easier to enforce policies from a single point. When a parent policy marks a feature as optional, each child security policy has the option of accepting the setting or setting their own child value to the feature. By accepting the parent feature setting, the feature becomes Mandatory for the child policy. A user with the role of Application Security Editor will not be able to create or edit parent security policies.

Learning suggestions which are derived from a Mandatory inheritance are propagated back to the parent policy.

The following features are not inheritable from a parent to a child security policy.
  • Bot Detection
  • Content Profiles
  • Cookies (collection)
  • CSRF Protection
  • Data Guard
  • Parameters (collection)
  • Policy Information
  • Redirection Domain
  • Session and Logins
  • URLs
  • Vulnerability Assessment

Proactive Bot Defense Logging and Reporting Enhancements

Logging and reporting improvements were made to provide better monitoring of behavior and effectiveness of Proactive Bot Defense. This includes:
  • A dedicated Bot Defense Request Log that displays each HTTP request along with its attributes.
  • A Bot Defense Logging Profile to provide basic filtering capabilities in the Request Log and Remote Log.
  • Additional info and Blocking Page configuration in iRule.
  • Transaction Outcome charts with filtering and drill-down capabilities.
These allow administrators to:
  • Monitor the Proactive Bot Defense behavior and effectiveness.
  • Troubleshoot false-positive cases.
  • Drill-down on specific cases to better understand the behavior.
This monitoring and drill-down can provide answers regarding:
  • Which transactions are being blocked and why.
  • The violation root-cause.
  • Trends in blocked versus non-blocked transactions.
  • The main source of blocked transactions, be it by IP address, country, application or URL.

Client Reputation Use in Policy Builder

Client reputation contributes to an enhanced security policy enforcement and the prevention of false positive alerts. An integrated client reputation mechanism was added to help the ASM administrator better decide on when to accept a suggestion. Knowing who to trust speeds up the learning process and reduces false positives from the policy while also avoiding erroneously learning from true attackers.

The client reputation mechanism identifies bad sources, e.g. source IPs or device IDs, using a variety of algorithms which include:
  • Violation rating per transaction and per session
  • User session flow anomaly detection
  • Explicitly trusted sources defined by the user

The Client Reputation score is used to prevent learning from malicious sources, e.g. vulnerability scanners, and improve the learning speed from benign sources. By using Client Reputation, Policy Builder generate more reliable suggestions and a safer policy.

Compact Mode Learning Optimization

Compact mode is a new policy learning mode, in addition to Always, Selective and Never modes. Compact mode provides the following benefits:
  • Enhanced policy stability: Policy changes and the number of new suggestions drop to a minimum within a few days of policy lifetime.
  • Enhanced security:
    • Shorter time to enforcement: staging is removed from most of the entities within the first week.
    • Policy is hardened by learning Disallowed File Types.
  • Less false positives and improved TCO
    • Amount of false positives is significantly reduced compared to Always and Selective modes.
    • Less entities and less suggestions are generated.
    • Less user involvement is needed.

A policy includes a list of the most frequent entities and includes a wildcard entity (*) to represent infrequent entities. This results in a smaller policy with up to 50 files types, 100 parameters and 100 URLs.

Entity-specific features:
  • Disallowed File Types are learned based on factory list of potential disallowed file types.
  • Parameters are learned only at global level.
  • Top-level URL directories are learned, e.g., /abc/*.
Compact mode is used in the following templates:
  • Fundamental policy template: File Types
  • Comprehensive policy template: File Types, Parameters and HTTP URLs

ASM Policy Setting Usability Improvements

These usability improvements have been added:
  • The Enforcement Readiness screen now provides more information and allows better controls.
    • Learning progress and policy stability graphs: Display a 14 day history for the following policy statistics: number of suggestions per state, enforced entities and policy changes by user.
    • Suggestions triage summary: Provides suggestions counters and filtering options by the following criteria: Top Violations, Top Matched Signatures, Top Violating Meta Characters, and Suggestions to Add New Entity. These reports may be used to quickly find suggestions that are most interesting for the user.
  • Information about rule thresholds in Security > Application Security: Policy Building: Learning and Blocking Settings has been moved to the Policy Building Process section on that page. The Policy Building Process is visible in Advanced view.

JSON Support and Granularity Improvements

The JSON profile now includes a new flag: parse parameters. The flag is ON by default. The parameters will be extracted if the flag is set and a JSON profile is attached to the URL or parameter. Any sensitive data, attack signatures or meta character exclusions that are defined in the JSON profile are now enforced with any similar items defined in parameters. The entire JSON profile is parsed and tokenized to parameters. The enforcement moves to the parameters and is done according to the configuration of the wildcard or explicit entity that is matched.

Classification of Request Content for URLs

Prior to BIG-IP system version 13.0, Form Data content type was assumed for HTTP requests content by default. This resulted in wrong parsing of XML and JSON content. Policy Builder would generate parameters that look like fragments of XML or JSON. To solve this issue, the user had to configure content classification based on Content-Type header manually for all relevant URLs in application.

In 13.0, classification of request content works seamlessly for most common content types (Form Data, JSON and XML). Classification is done with predefined Header-Based Content Profiles.

A wildcard URL is defined with the Header-Based Content Profiles. Classification is supported both in Manual and Automatic Policy Builder modes.

Fingerprinting Improvements

Fingerprinting has been improved using JavaScript. Several methods for identification have been added as well as:
  • Increased fingerprinting granularity.
  • Coupled persistent client identification with fingerprinting.
  • Provided dynamic attribute evaluation by collecting the uniqueness and volatility of the fingerprint attributes without relying on pre-assigned values.
  • Provided support for mobile devices, including support for browsers and applications that use embedded browsers.

Overlapping Staging for Updated Signatures

ASM now has the ability to update signatures with testing but without having to take active policies back to staging.

In previous versions, you had two options when updating signatures: either set the updated signature back to staging, thus weakening the security of the policy, or enforce the updated signature without testing it in production.

With the new updating ability:
  1. The ASM administrator who updates the signatures receives a duplicate signature to the original instead of immediately overwriting the existing one.
  2. The existing signature remains with its previous enforcement status and the updated duplicate signature is added to the policy in Staging status. While in staging, the signatures behave as two separate signatures.
  3. After accepting the new signature into the policy, the original signature is phased out.
Removing the staging flag from the new policy starts the phase-out process for the old signature. Allow a few days for the old signature to be removed.

Single Page (URL) Application Protection via Enabling JavaScript-Based Challenges with AJAX Applications

ASM now supports single page (URL) application protection by:
  • Identifying the login page based on the Action Parameter.
  • Detecting Nameless Parameters.
  • Protecting Single Page Application Form submissions.
  • Identifying the Username.
  • Recognizing the JSON Content Profile better.

Automatic Server Technology Detection

ASM now includes the ability to automatically detect server technologies behind the BIG-IP system. During learning, ASM will detect used server technologies and suggest adding the detected server technologies to the user's security policy. Accepting the server technology suggestions tightens the ASM security policy by enabling specific technologies and their associated signatures to be added to the ASM policy.

When creating a new security policy using either the Comprehensive or Fundamental templates, the Server Technologies features is enabled by default. See Security > Application Security > Policy Building > Learning and Blocking Settings.

Following an upgrade, Server Technologies detection is disabled.

Note that, while most server technologies can be auto-detected, the following server technologies cannot be auto-detected. They must be added manually to a policy.
  1. Proxy Servers
  2. CGI
  3. Sybase/ASE
  4. IBMDB2
  5. PostgreSQL
  6. XML
  7. ApacheStruts
  8. Elasticsearch
  9. JBoss
  10. Citrix
  11. Node.js
  12. Django
  13. MongoDB
  14. Ruby
  15. JavaServerFaces(JSF)
  16. Joomla

AVR DoS Visibility and Scheduled Reports

The Analytics DoS Dashboard and Analysis pages provide the administrator with the option to drill down and filter the various attacks to better understand the source of the attacks and, therefore, take the appropriate action against the attacks. The administrator can view and filter both historic or real time updates.

ASM Proxy Log GUI Improvement

The ASM log configuration GUI was improved to make it more aligned with BIG-IQ.

Advanced Exception Handling

ASM now supports the ability to disable individual attack signatures on HTTP headers, wildcard URLs and wildcard headers (*). By adding this support, you do not have to disable the full signatures check and the open the application to attacks in order to avoid an attack signature check.

Policy Enhancements

Policy enhancements were made to address various defects. These enhancements include but are not limited to:
  • Add REST support for enforcing all signatures that are Ready to be Enforced.
  • Support Wildcard in Heavy URL Whitelist.
  • Include default values in Policy Export.
  • Create an easy way to block IP ranges.
  • Enhance GUI statistics per URL and per IP during L7 DoS attacks.
  • Add signature name in iRule events.
  • Provide additional logging information for remote logging of requests with staged signatures only.

BADoS Unified Server Health Check Mechanism Based on L7 Analysis

The same virtual server predictive latency is now used for BADoS and Layer 7 DoS. This allows them to have the same trigger for stress and attack detection.

BADoS DDoS Mitigation Based on Behavior Analysis and Integration with Whitelist

The BADoS whitelist/blacklist behavior is aligned now with the other Layer 7 protection modules. This provides administrators with the ability to exclude whitelist members from statistics collection, anomaly detection and mitigation. This feature also supports anomaly detection of X-Forwarded-For (XFF) HTTP headers

BADoS Logging and Reporting Improvement

BADos now displays information regarding why clients are declared bad actors. The reason is presented in human readable codes.

BADoS Automatic Generation of Attack Request Signatures

Attackers are now identified and marked as bad actors after their first appearance. This allows for better policy enforcement when an attacker reappears thus sparing the remitigation process from BADoS, as was previously the process.

ASM DoS Add Automatic Threshold Tuning to ASM DoS Protection

Automatic threshold tuning is now included in Layer 7 DoS TPS-based Detection and Stress-based Detection. The calculated thresholds are per virtual server and DoS profile. The algorithms used with manually configured DoS is unchanged.

In TPS-based Detection, a single global threshold is calculated for each of the following entity types:
  • Device ID
  • Source IP
  • URL
  • Site Wide
In Stress-based Detection, the following thresholds are calculated:
  • Device ID: Thresholds for up to the top 50 Device IDs are calculated and an additional threshold for all other Device IDs.
  • Source IP: Thresholds for up to the top 100 source IPs are calculated and an additional threshold for all other source IPs.
  • URLs: Thresholds for up to the top 500 source URLs are calculated and an additional threshold for all other URLs.
  • Site Wide: Single threshold

Thresholds for the top 20 geo-locations are calculated for each hour of the day, e.g. 00:00-01:00, 01:00-02:00. An additional threshold is calculated for other geo-locations for each hour of the day. This algorithm is used in both TPS-based Detection and Stress-based Detection.

All automatically tuned thresholds may be displayed using the tmctl command.

ASM DoS Heavy URL Improvements

The following changes were made in the functionality of heavy URLs:
  • A user can define a heavy URL and set a threshold manually for it.
  • A heavy URL is mitigated during an attack only if its respective detection threshold is violated.

Installation overview

This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference this information to ensure successful completion of the installation process.

Installation checklist

Before you begin:

  • Use BIG-IP iHealth to verify your configuration file. For more information, see K12878: Generating BIG-IP diagnostic data using the qkview utility.
  • Update/reactivate your system or vCMP host license, if needed, to ensure that you have a valid service check date. For more information, see K7727: License activation may be required prior to a software upgrade for the BIG-IP or Enterprise Manager system.
  • Ensure that your system is running version 11.x or later.
  • Download the .iso file (if needed) from F5 Downloads to /shared/images on the source for the operation. (If you need to create this directory, use the exact name /shared/images.)
  • Configure a management port.
  • Set the console and system baud rate to 19200, if it is not already.
  • Log on as an administrator using the management port of the system you want to upgrade.
  • Boot into an installation location other than the target for the installation.
  • Save the user configuration set (UCS) in the /var/local/ucs directory on the source installation location, and copy the UCS file to a safe place on another device.
  • Log on to the standby unit, and only upgrade the active unit after the standby upgrade is satisfactory.
  • Turn off mirroring.
  • If you are running Application Acceleration Manager, set provisioning to Minimum.
  • If you are running Policy Enforcement Manager, set provisioning to Nominal.
  • If you are running Advanced Firewall Manager, set provisioning to Nominal.

Installing the software

You can install the software at the command line using the Traffic Management shell, tmsh, or in the browser-based Configuration utility using the Software Management screens, available in the System menu. Choose the installation method that best suits your environment.
Installation method Command
Install to existing volume, migrate source configuration to destination tmsh install sys software image [image name] volume [volume name]
Install from the browser-based Configuration utility Use the Software Management screens in a web browser.

Sample installation command

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

tmsh install sys software image BIGIP- volume HD1.3

Post-installation tasks

This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference this information to ensure successful completion of the installation process.

After the installation finishes, you must complete the following steps before the system can pass traffic.
  1. Ensure the system rebooted to the new installation location.
  2. Use BIG-IP iHealth to verify your configuration file. For more information, see K12878: Generating diagnostic data using the qkview utility.
  3. Log on to the browser-based Configuration utility.
  4. Run the Setup utility.
  5. Provision the modules.
Note: You can find information about running the Setup utility and provisioning the modules in BIG-IP TMOS implementations Creating an Active-Standby Configuration Using the Setup Utility and Creating an Active-Active Configuration Using the Setup Utility.

Installation tips

  • The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three minutes and seven minutes. During the upgrade process, you see messages posted on the screen. For example, you might see a prompt asking whether to upgrade the End User Diagnostics (EUD), depending on the version you have installed. To upgrade the EUD, type yes, otherwise, type no.
  • You can check the status of an active installation operation by running the command watch tmsh show sys software, which runs the show sys software command every two seconds. Pressing Ctrl + C stops the watch feature.
  • If installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.

Upgrading from earlier versions

Your upgrade process differs depending on the version of software you are currently running.

Upgrading from version 11.x or later

When you upgrade from version 11.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 11.x

You cannot roll forward a configuration directly to this version from BIG-IP version 10.x or earlier. You must be running version 11.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.

Upgrading earlier configurations

When you upgrade from an earlier versions of the software, you might need to know about or take care of these configuration-specific issues.

ID Number Description
588946 You can install v11.5.4 on the 12250v platform, but are unable to license BIG-IP. This is because v11.5.4 is not supported on the 12250v platform. Install BIG-IP v11.5.4 on a 12250v platform. BIG-IP v11.5.4 is not supported on the 12250v platform. Even though installation succeeds, it is not possible to license BIG-IP system. Workaround: Install a supported version of BIG-IP on the 12250v. Supported versions are 11.6.0 HF2 or later and 12.0.0 or later.
223704 When you import a single configuration file (SCF file) that contain VLANs of the same name that exist in different administrative partitions, the operation fails with a unknown operation error. Upgrading configurations with VLANs of the same name in different administrative partitions. Upgrade operation fails with a unknown operation error. Workaround: Before installing an SCF file, run the command: tmsh load sys config default. This returns the system to the default configuration, so subsequent configuration import operations should succeed as expected.
513501 When upgrading from a version prior to 11.5.0 to 11.5.0 or newer, the configuration might fail to load with an error similar to the following: LSN pool is configured with a prefix address that overlaps with a prefix address on another LSN pool. "On versions prior to 11.5.0, tmsh allowed users to configure overlapping DNAT and NAPT pools, even though this configuration is invalid and non-functional. Version 11.5.0 and later contain validation to prohibit such configurations. However, when upgrading versions newer than 11.5.0, a configuration that contains overlapping DNAT and NAPT pools fails to load." Configuration fails to load on upgrade. Workaround: Edit bigip.conf and locate the overlapping LSN pools. Either remove one of the pools or change the mode on the DNAT pool to NAPT.
571333 When a VIP is configured with a fastl4 profile that enables full acceleration and offload state to embryonic, and if a flow is offloaded to be hardware accelerated, the connection idle timeout during the TCP handshake is set to the "idle timeout" value of the fastl4 profile, but it should be set to the "tcp handshake timeout" instead. "1. Configure fastl4 profile with ePVA=full, offload state=SYN, apply to network VS 2. Ensure ARP entry exists for server node (static arp, ping, etc.) to satisfy requirements for offloading initial SYN 3. Send over SYN packet from client to server via VS" The connection may remain in the half-open state longer than what is set in the TCP handshake timeout value. Workaround: Set the offload state to "established"
436075 Using syslog include field when the command 'syslog-ng -s' does not succeed before the upgrade. Using syslog include field. It is possible to roll forward an include field with invalid syntax. This will cause the configuration to fail to load. Workaround: When using the syslog include field, ensure that the command 'syslog-ng -s' succeeds before the upgrade.
581932 Upgrading to a newer version of the BIG-IP software removes the signatures that were installed using an IM signature package, and returns app signatures to the default version. "- New '.im' signature package installed manually using the BIG-IP GUI or tmsh. This adds extra applications and categories to the default signatures. - TMOS software upgraded to a newer version, for example installing a rollup hotfix or an engineering ho" "After rebooting into the new software volume, all the additional categories and applications are gone but the signature package is still showing as installed. This makes a simple re-installation of the new .im signature package impossible. The applications and categories are actually back to default settings for version 11.6.0." Workaround:

    "1. After rebooting into the new software volume, open the bigip.conf file with a text editor and remove all the configurations from the 'ltm classification signature-version' stanza:
            ltm classification signature-version {
      2. Manually remove the following files:
      3. Create the file /service/mcpd/forceload  to force a reload of the mcpd binary database after the reboot by running the command: touch /service/mcpd/forceload.
      4. Reboot the system.
      5. Re-install the .im signature package."

415961 The upgrade process does not migrate unassigned HTTP Class profiles to BIG-IP 11.4.0 and later When you upgrade a BIG-IP system to BIG-IP 11.4.0 or later, the upgrade process attempts to convert all assigned HTTP Class profiles to their equivalent local traffic policies. If an HTTP Class profile is not assigned to a virtual server, the upgrade process will not perform the conversion and the unassigned HTTP Class profile will no longer exist in the configuration of the upgraded BIG-IP system. Similarly, if you restore a UCS archive that contains unassigned HTTP Class profiles in BIG-IP 11.4.0 and later, the restoration process will not convert the unassigned HTTP Class profiles and these profiles will no longer exist. This behavior is by design. You might lose unused HTTP Class profiles in the configuration. Workaround: "When upgrading to BIG-IP 11.4.0 and later or saving a UCS archive from a pre-11.4.0 system, you should consider the following factor: Prior to upgrading or saving a UCS archive, ensure that all HTTP Class profiles are assigned to a virtual server."
401828 The following configurations are invalid for a SIP virtual server: a) TCP virtual server with a UDP profile and a SIP profile. b) UDP virtual server with a TCP profile and a SIP profile. TCP virtual server with a UDP profile and a SIP profile, or a UDP virtual server with a TCP profile and a SIP profile. If such a configuration exists in previous versions, it loads in 11.3.x but may cause a core. Workaround: "Fix the configuration manually, as follows: a) A SIP TCP virtual server must have TCP as one of its profile type. b) A SIP UDP virtual server must have UDP as one of its profile type."
490139 Loading iRules from the iRules file deletes last few comment lines immediately preceding the closing bracket. This occurs when loading an iRule file from versions prior to 11.5.1. Although the comments are removed, this does not affect iRule functionality. Workaround: Put comments in places other than immediately above the closing bracket.
496663 iRule object in non-Common partition referenced from another partition results in upgrade/configuration load failure in 11.x/12.x. This occurs when upgrading/loading a configuration containing an iRule in one non-Common partition that references an object in another non-Common partition. A configuration of this type can be saved only using pre-11.x versions of the software. The config upgrade fails, and the UCS/configuration files cannot be loaded. The system posts an error message similar to the following: 'myucs.ucs' failed with the following error message: 'Rule [/UNCOMMONPARTITION/RULEABC] error: Unable to find rule_object (...) referenced at line xyz: [element]'. Workaround: None.
532559 If the client-ssl profile is /Common/clientssl, its parent profile is supposed to be /Common/clientssl. But the configuration could potentially use 'defaults-from none'. "This condition could be caused by executing the following command when generating the configuration. 'tmsh modify ltm profile client-ssl clientssl defaults-from none'" The upgrade fails after booting into the new release, during the config loading phase. This occurs because the script extracts the line 'defaults-from none' and treats 'none' as its parent profile. Workaround: Edit the configuration prior to upgrading, changing the defaults-from value on the client-ssl profile to the name of that profile.
449617 If a configuration file includes a passphrase for an ssl-key file object, the object may fail to validate when loading the configuration. Passphrase present in ssl-key file object Configuration fails to load Workaround: Remove passphrase line from the file object.
586878 "During upgrade, configuration fails to load due to invalid clientssl profile cert/key configuration. The validation to verify whether at least one valid key/cert pair exists in clientssl profiles was enforced in software versions through 11.5.0. This validation was not in effect in versions 11.5.1, 11.5.2, and 11.5.3. The lack of validation resulted in invalid clientssl profiles (those containing empty key/certs or a cert/key of 'default'). When you upgrade such a configuration to 11.5.4 or later, you will receive a validation error, and the configuration will fail to load after upgrade." "The issue occurs when all the below conditions are met.

      1. You have a clientssl profile in a configuration from a version without validation (that is, 11.5.1, 11.5.2, or 11.5.3).
      2. The clientssl profile in the configuration has an empty cert/key, or a cert/key of 'default'.
      3. You upgrade to a version that has the cert/key validation (specifically, 11.5.4, 11.6.0, and versions 12.1.0 and later)." "Configuration fails to load. The system posts an error message that might appear similar to one of the following:
            -- 01070315:3: profile /Common/my_client_ssl requires a key Unexpected Error: Loading configuration process failed.
            -- 01071ac9:3: Unable to load the certificate file () - error:2006D080:BIO routines:BIO_new_file:no such file.
            Unexpected Error: Loading configuration process failed."
Workaround: "To workaround this situation, modify the configuration file before upgrading:
      1. Check the config file /config/bigip.conf.
      2. Identify the clientssl profile without a cert/key.
            For example, it might look similar to the following:
            ltm profile client-ssl /Common/cssl_no-cert-key2 {
            app-service none
            cert none
            cert-key-chain {
            """" { }
            chain none
            defaults-from /Common/clientssl
            inherit-certkeychain false
            key none
            passphrase none
            Note: The profile might have cert-key-chain name but not the cert/key.
            In other words, it could also appear similar to the following example:
            ltm profile client-ssl /Common/cssl_no-cert-key2 {
            app-service none
            cert none
            cert-key-chain {
            default { }
            chain none
            defaults-from /Common/clientssl
            inherit-certkeychain false
            key none
            passphrase none
      3. Remove the clientssl profile from /config/bigip.conf.
      4. Run the command: tmsh load sys conf.
      5. Re-create the clientssl profiles you need."

435482 "BIG-IP configuration object names that include a space may cause an upgrade or user configuration set (UCS) load to fail. As a result of this issue, you may encounter the following symptoms: Your attempts to upgrade the BIG-IP system or load a UCS fail. After loading a UCS file or upgrading from a configuration that has object names with spaces on BIG-IP 11.4.0 or a later version, the Configuration utility displays an error message similar to the following example: The configuration has not yet loaded. If this message persists, it may indicate a configuration problem. After loading a UCS file that has configuration object names that include spaces on BIG-IP 11.4.0 or a later version, a message appears similar to following example: Unexpected Error: Configuration cannot be saved unless mcpd is in the running phase. Save was canceled. See 'show sys mcp' and 'show sys service'. If 'show sys service' indicates that mcpd is in the run state, but 'show sys mcp' is not in phase running, issue the command 'load sys config' to further diagnose the problem." "This issue occurs when one of the following conditions is met: You attempt to upgrade a BIG-IP system from 11.3.0, or an earlier version, with a configuration that has configuration object names with spaces. You attempt to load a BIG-IP 11.3.0 or earlier UCS file, that has configuration object names with spaces, on BIG-IP 11.4.0 or a later version." The BIG-IP system upgrade or UCS load fails. Workaround: "To work around this issue, you can boot back to the previous BIG-IP 11.3.0 or earlier version and rename all affected configuration objects to exclude spaces before upgrading or saving a UCS file. Impact of workaround: Performing the suggested workaround should not have a negative impact on your system."
489015 An LTM request-log profile that references a non-existent pool can pass validation in 11.0.0 or 11.1.0, but fails in 11.2.0 or later, with an error similar to the following: 'The requested Pool (/Common/poolname) was not found.' "This issue occurs when all of the following conditions are met: The UCS file has a Request Logging profile configuration with at least one of the following conditions: A Request Logging profile references a non-existent pool. A Request Logging profile references a pool in a non-default administrative partition without specifying the path to the /<partition>/<pool>. You upgrade from 11.0.0 or 11.1.0 to 11.2.0 or later and roll forward the configuration. You attempt to load an affected UCS created on 11.0.0 or 11.1.0 to a system running 11.2.0 or later." This can cause a load failure when rolling forward the configuration. Workaround: Correct the request-log profile in the config either prior to upgrade or by editing the config after.

Issues when upgrading from earlier ASM versions

If you upgrade from an earlier version of ASM, note the following issues.

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 SOL14381: 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 SOL14409: 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

In version 13.0.0 the ability to export logs in binary and PDF file formats was removed. Log files are exported in HTML format only. The resultant HTML log file can be converted to a PDF by:
  • Printing the HTML page to PDF from the browser window.
  • Scripting the HTML to PDF conversion using CLI found here:

HTTP protocol compliance failed sub-violations

If you upgrade or import a security policy from a version prior to 11.6.0, the system automatically enables the following HTTP protocol compliance-failed sub-violations, even if they were previously disabled:

  • Bad HTTP version
  • Null in request
  • Unparsable request content

You can manually disable these violations after the upgrade or import.

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).

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.

About changing the resource provisioning level of the Application Security Manager

After upgrading or installing a new version, before you can use the Application Security Manager, you must set the Application Security Manager resource provisioning level to Nominal. You can do this from the command line, or using the Configuration utility.

Important: Wait 5 minutes after you set the resource provisioning level before making any configuration changes to the Application Security Manager. The system overrides all configuration changes that were made before this process is completed. When the process is not complete, the system informs you by displaying, in the Configuration utility, the following message: ASM is not ready. The system informs you when the process is completed by indicating in the log (/var/log/asm) the following message: ASM started successfully.

Setting the Application Security Manager resource provisioning level to Nominal from the command line

You can set the Application Security Manager resource provisioning level to Nominal from the command line.
  1. Open the command-line interface utility.
  2. Type the command: tmsh modify sys provision asm level nominal
  3. Type the command: tmsh save sys config.
The screen refreshes, and the resource provisioning level of the Application Security Manager is set to Nominal.

Setting the Application Security Manager resource provisioning level to Nominal using the Configuration utility

You can set the Application Security Manager resource provisioning level to Nominal using the Configuration utility.
  1. On the Main tab, click System > Resource Provisioning . The Resource Provisioning screen opens.
  2. Set the Application Security (ASM) option to Nominal.
  3. Click Submit.
The screen refreshes, and the resource provisioning level of the Application Security Manager is set to Nominal.

About working with device groups

Note: This section is relevant only if you are working with device groups.

When Application Security Manager (ASM) is provisioned, the datasync-global-dg device-group is automatically created (even if there are no device-groups on the unit) in any of the following scenarios:

  • First provisioning of ASM on a device that has version 11.6.0, or later, installed.
  • Adding a device (with version 11.6.0 or later) to a trust-domain that has another device which already has the datasync-global-dg device-group.
  • Upgrading to version 11.6.0, or later, when ASM is already provisioned.
  • Upgrading to version 11.6.0, or later, when the device is joined in a trust-domain that has another device which already has the datasync-global-dg device-group.

This device group is used to synchronize client-side scripts and cryptographic keys across all of the devices in the trust-domain.

Note the following:

  • The synchronization is performed across the entire trust-domain, regardless of the configured device groups.
  • The datasync-global-dg device group must not be removed; it is essential for consistency of client-side scripts and keys across the devices.
  • This device group is created upon provisioning, even if the BIG-IP system is working as a standalone.
  • All of the devices in the trust-domain are automatically added to this device group.
  • This device group is manually synchronized. Therefore, when working with device groups (multiple devices in a trust-domain), customers must choose which device will hold the master scripts and keys. The rest of the devices receive these scripts and keys from the chosen device.
  • This device group is also created on units that do not have ASM provisioned, but are in a trust-domain with other units which do have ASM provisioned.

Synchronizing the device group

When adding a device to the trust-domain, or upgrading from a release prior to version 11.6.0, you must manually synchronize this device group.
  1. In the Configuration utility, navigate to Device Management > Overview .
  2. In the Device Groups area, click datasync-global-dg.
  3. In the Devices area, click the device which is chosen to have the master scripts and keys. These scripts and keys will be sent to the rest of the devices.
  4. Under Sync Options, select Sync Device to Group.
  5. Check Overwrite Configuration.
  6. Click Sync.
  7. When the warning message appears, click OK.
The device that you selected continues to work seamlessly. The rest of the devices go OFFLINE, and will not receive traffic for approximately 3 minutes. During this time, the new client-side scripts and keys are synchronized and prepared. After about 3 minutes, all units should return to the ONLINE (Active) state, and the units should be in sync.

Supported ICAP servers

For BIG-IP version 11.6.0, F5 Networks tested the anti-virus feature on the following ICAP servers: McAfee®, Trend Micro™, Symantec™, and Kaspersky. The following table displays which version of each anti-virus vendor was tested, and the value of the virus_header_name variable that needs to be adjusted in ASM for each tool. (You can set the virus_header_name variable: Security > Options > Application Security > Advanced Configuration > System Variables .)

Anti-Virus Vendor Anti-Virus Version Value of virus_header_name
McAfee® VirusScan Enterprise 7.0 X-Infection-Found, X-Virus-Name
Trend Micro™ InterScan™ Web Security 5.0.1013 X-Virus-ID
Symantec™ Protection Engine X-Violations-Found
Kaspersky Anti-Virus 5.5 X-Virus-ID

Contacting F5 Networks

Phone - North America: 1-888-882-7535 or (206) 272-6500
Phone - Outside North America, Universal Toll-Free: +800 11 ASK 4 F5 or (800 11275 435)
Fax: See Regional Support for your area.

For additional information, please visit

Additional resources

You can find additional support resources and technical documentation through a variety of sources.

F5 Networks Technical Support

Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology.


AskF5 is your storehouse for thousands of knowledgebase articles that help you manage your F5 products more effectively. Whether you want to browse periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.

F5 DevCentral

The F5 DevCentral community helps you get more from F5 products and technologies. You can connect with user groups, learn about the latest F5 tools, and discuss F5 products and technology.

AskF5 Publication Preference Center

To subscribe, click AskF5 Publication Preference Center, enter your email address, select the publications you want, and click the Submit button. You will receive a confirmation email. You can unsubscribe at any time by clicking the Unsubscribe link at the bottom of the email, or on the AskF5 Publication Preference Center screen.

  • TechNews Weekly eNewsletters: Up-to-date information about product and hotfix releases, new and updated articles, and new feature notices.
  • TechNews Notifications: Periodic plain text TechNews, sent any time F5 releases a product or hotfix. (This information is always included in the next weekly HTML TechNews email.)
  • Security Alerts: Timely security updates and ASM attack signature updates from F5.

Legal notices