Applies To:

Show Versions Show Versions

Release Note: BIG-IP ASM 11.3.0
Release Note

Original Publication Date: 01/02/2014

Summary:

This release note documents the version 11.3.0 release of BIG-IP Application Security Manager.

Contents:

- User documentation for this release
- Supported platforms
- Configuration utility browser support
- Installation overview
     - Installation checklist
     - Installing the software
     - Post-installation tasks
- Upgrading from earlier versions
     - Additional upgrade information
     - Changing the Resource Provisioning level of the Application Security Manager
- Additional configuration information
- New items and fixes in this release
     - New in this release
     - Fixes in this release
- Features and fixes introduced in prior releases
     - New features introduced in 11.2.1
     - Fixes introduced in version 11.2.1
     - New features introduced in 11.2.0
     - Fixes introduced in version 11.2.0
     - New features introduced in 11.1.0
     - Fixes introduced in version 11.1.0
     - New features introduced in 11.0.0
     - Fixes introduced in version 11.0.0
- Known issues
- Workarounds for known issues
- Legal notices

User documentation for this release

To view a complete list of documentation relevant to this release, see BIG-IP ASM 11.3.0 Documentation.

[ Top ]

Supported platforms

For a list of supported platforms, see SOL9412: The BIG-IP release matrix. SOL9412: BIG-IP software and platform support matrix. For information about which platforms support which module combinations, see SOL10288: BIG-IP software and platform support matrix.

Note: The BIG-IP 4100 (D46) platform is no longer supported.

Important: We no longer support the provisioning of three or more modules on all platforms with less than 6.5 GB of memory because there is not enough RAM to support all three modules running at once. This includes the 1600 platform, the 3600 platform, and VCMP guests. Here are examples of module combinations no longer supported on low-end platforms:

  • LTM + ASM + AVR
  • LTM + ASM + APM
  • LTM + ASM + GTM
  • LTM + ASM + WOM
  • LTM + ASM + WBA

In addition, platforms with less than 6.5 GB memory cannot be upgraded to v.11.3.0 if three or more modules are provisioned. Note that upgrades from 10.0.x display only an "upgrade failed" message as a software status. All other versions show a clear error message, guiding the users to SOL13988. Before upgrading a BIG-IP system with less than 6.5 GB of memory, make sure you have only one or two modules provisioned.

If you are unsure which platform you have, refer to the sticker on the back of the chassis to locate the platform number.

[ Top ]

Configuration utility browser support

The BIG-IP system Configuration utility supports the following browsers and versions:

  • Microsoft Internet Explorer 8.x, 9.x
  • Mozilla Firefox 15.0.x
  • Google Chrome 21.x
[ Top ]

Installation overview

The following instructions explain how to install Application Security Manager (ASM) version 11.3.0. This section lists only the very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP System: Upgrading Active/Standby Systems and BIG-IP System: Upgrading Active-Active Systems, and we strongly recommend that you reference these documents to ensure successful completion of the installation process.

Installation checklist

Before you begin, ensure that you have completed the following:

  • You made a backup or archive of the system and saved it outside of the system in order to perform a rollback if needed.
  • The license and service contract are already updated for this release, if applicable.
  • You downloaded the .iso file from F5 Downloads to /shared/images on the source for the operation.
    Note: You might need to create this directory. If so, use this exact name, including capitalization.
    Note: This step is only needed if you will run the tmsh or bigpipe commands to install (performing a live install). This is not needed if you will run the image2disk command to install.
  • There is at least minimal partitioning on the system drives.
  • You have already configured a management port.
  • You are logged on to the management port of the system you want to upgrade.

    Note: If you are upgrading from version 10.2.x you must install on the non-active partition. If you are upgrading from version 9.4.3, you can install on the active partition.

  • You logged on using an account with administrative rights.
  • You have saved the user configuration set (UCS) in the /var/local/ucs directory on the source installation location, if applicable.
  • You are logged on to the standby unit in a redundant system, if applicable, and that you will synchronize the configuration to the active unit.
  • You turned off mirroring, if applicable.
  • If you are upgrading from 9.4.3 and later, you ran im <downloaded_filename.iso> to copy over the new installation utility.

Installing the software

To install the software, use one of the following methods:

  • Run the command tmsh install sys software image BIGIP-11.3.0.XXXX.0.iso volume HD1.X. If the volume does not exist, add to the end of this command: [create-volume].
  • Use the Software Management screens in the browser-based Configuration utility.

 

Post-installation tasks

After the installation finishes, you must complete the following steps before the system can pass traffic. You can find complete, step-by-step installation and upgrade instructions in BIG-IP System: Upgrading Active/Standby Systems and BIG-IP System: Upgrading Active-Active Systems, and we strongly recommend that you reference these documents to ensure successful completion of the installation process.

  1. Reboot to the new installation location.
    Note: This is not necessary if you are upgrading from version 9.4.3 or earlier because in this case the system automatically reboots to the newly installed location.
  2. Log on to the browser-based Configuration utility as a user with administrator rights.
  3. Run the Setup utility.
  4. Provision the module.

Upgrading from earlier versions

You may install Application Security Manager (ASM) version 11.3.0 onto existing systems running version 9.4.3 or later.

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

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.

Your upgrade process differs depending on the software version installed and whether the BIG-IP system uses the partitions or volumes disk-formatting scheme.

The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three to 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 (recommended), type yes, otherwise, type no.

Upgrading from version 11.x

If you are currently running version 11.x, use one of the following upgrade methods:

  • Run the command tmsh install sys software image BIGIP-11.3.0.XXXX.0.iso volume HD1.X. If the volume does not exist, add to the end of this command: [create-volume].
  • Use the Software Management screens in the browser-based Configuration utility.

Upgrading from version 10.2.x if the BIG-IP system uses volumes

If you are currently running version 10.2.x and the BIG-IP system uses the volumes disk-formatting scheme, use one of the following upgrade methods:

  • Run the command bigpipe software desired HD<volume_number>version 11.3.0 build <nnnn.n> product BIG-IP
  • Run the command tmsh install sys software image BIGIP-11.3.0.XXXX.0.iso volume HD1.X

    Note: The [create-volume] option is not supported on 10.2.x. If the volume does not exist, the system automatically creates the missing volume.

  • Use the Software Management screens in the browser-based Configuration utility.

You can check the status of an active installation operation by running the command bigpipe software status or tmsh show sys software. If the installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.

Upgrading from version 10.0.x or 10.1.x if the BIG-IP system uses volumes

If you are currently running version 10.0.x or 10.1.x and the BIG-IP system uses the volumes disk-formatting scheme, use one of the following upgrade methods:

  • Run the command bigpipe software desired HD<volume_number> version 11.3.0 build <nnnn.n> product BIG-IP
  • Use the Software Management screens in the browser-based Configuration utility.

You can check the status of an active installation operation by running the command bigpipe software status. If the installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.

Upgrading from version 9.4.3 or later 9.x versions

If you are currently running version 9.4.3 or later 9.x versions, you must perform a one-time upgrade procedure to make your system ready for the new installation process. When you update from software version 9.4.3 or later 9.x versions to version 11.x, you cannot use the Software Management screens in the Configuration utility. Instead, you must run the command line.

Important: You cannot install version 11.x to a partitioned system. This means that, for example, you cannot have both 9.x and 11.x products coexisting on the same system.

Installation consists of the following steps:

  1. Run the command bigpipe config save <your .ucs file> to save the .ucs file.
  2. Since version 9.x uses the partitions disk-formatting scheme and version 11.x uses the volumes disk-formatting scheme, you must use the image2disk utility to install the <downloaded_filename.iso> as follows:

    image2disk - - format=volumes [OPTIONS] full_path_to_the_downloaded_filename.iso

    Tip: Type image2disk --help to view the available options.

  3. Wait for the system to automatically reboot to the newly installed location.
  4. If you are notified to relicense, do it now.
  5. Run the command tmsh load sys ucs <path/to/.ucs file>
    In this command <path/to/.ucs file> refers to the full path of the .ucs file with the configuration you want to install.

Upgrading from versions earlier than 9.4.3

If you are currently running the Application Security Manager versions 9.2.x, 9.3.x, 9.4, 9.4.1 or 9.4.2, you cannot upgrade directly to version 11.x. You must first upgrade to version 9.4.3 or later, and then upgrade again to this version. For details about upgrading to those versions, see the release notes for the associated release.

Additional upgrade information

Preserved data

When upgrading to this version of the Application Security Manager, the system does not preserve reporting information (such as Requests and Charts) and manual traffic learning suggestions.

Upgrading to version 11.3.0

Web Scraping
Previously, there was a check box for enabling web-scraping, and in version 11.3.0 there is not.

  • 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 version 11.3.0, under these circumstances. However, in version 11.3.0 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 version 11.3.0, 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 to version 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 to version 11.3.0, 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 version 11.3.0, logging profiles are assigned to virtual servers. Previously, they were assigned to security policies. Upon pgrading logging profiles from versions prior to 11.3.0 to version 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.

Changes the system makes if you upgrade to version 11.2.1 or later

If you upgrade to version 11.2.1 or later, note the following:

  • IP Address Whitelist: In version 11.2 the 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).
  • Ignored Entities: We store ignored file types, URLs, and flows with security policies created in version 11.2. Previously, they were associated with the Application Security Manager’s web application (known as the HTTP Class in version 11.1).
    • Upon upgrade, ignored entities and URLs are automatically transferred to the active security policy, but ignored flows are not upgraded.
    • You can import and export ignored entities configured in version 11.2.1 by importing and exporting the security policy to which they belong. However, since ignored entities created before version 11.2 are not stored with their security policies, they cannot be exported or imported.

Changes the system makes if you upgrade from version 10.x to version 11.x

If you upgrade from version 10.x to version 11.x, note the following:

  • Web Applications: Web Applications have a folder prefix added to their name, corresponding to their HTTP Profile.

    Note: The term "web application" in the context of ASM was removed in version 11.1.0.

  • Denial of Service (DoS) Attack Prevention Settings:
    • The URL Detection Criteria: Minimum TPS Threshold setting is populated with the value of the internal parameter dos_min_detection_object_threshold previously set in the Options > Advanced Configuration screen.
    • The IP Detection Criteria: Minimum TPS Threshold setting is populated with the value of the internal parameter dos_min_detection_ip_threshold previously set in the Options > Advanced Configuration screen.
  • Active/standby pair: When upgrading an active/standby pair running Application Security Manager from version 10.x to version 11.0, the Application Security Manager does not require specific preparation, and no additional configuration is required after completing the upgrade to version 11.0. If you update two redundant systems that are running as an active/standby pair with ASM and LTM® provisioned, the system maintains the active/standby status and automatically creates a fail over device group and a traffic group containing both systems. The device group is ASM-enabled (because both systems have ASM provisioned). You can manually push or pull the updates (including LTM and ASM configurations and policies) from one system to the other (Device Management > Device Groups, then click Config Sync and choose Synchronize TO/FROM Group).

Changes the system makes if you upgrade or import a security policy from version 10.x to version 11.x

If you upgrade from version 10.x to version 11.x, or import a security policy from version 10.x to version 11.x, note the following:

  • URL Settings:
    • URLs that were associated with an XML profile (without a specified Content-Type) will have that XML profile used as default handling.
    • URLs that were associated with an XML profile for a specific Content-Type will have that XML profile used as an additional handling. The default handling for the URL will be HTTP.
    • URLs that previously had Check AMF enforced will have an additional handling, with Request Header Name set to Content-Type and Request Header Value set to *[aA][mM][fF]*. The default handling for the URL will be HTTP.
    • All other URLs will simply have default handling set as HTTP.
  • Vulnerability Assessment (WhiteHat Sentinel) Settings: A user who used previous versions of ASM-Sentinel integration and now upgrades to this version will continue to get opened vulnerabilities (Sentinel status: Open, ASM status: Pending) for those URLs and parameters that were already handled in the previous version. The resolution of this problem is to resolve again those vulnerabilities that appear to be open.
  • Policy Builder Changes:
    • The Dynamic Parameters: Using Statistics - Form parameters check box is enabled while the Dynamic Parameters: Using statistics - Link parameters check box is not enabled.
    • The Learn from responses check box is enabled.
    • The Collapse to one entity check box is enabled if it used to have a value of 0. The Collapse to one entity check box is enabled if it used to have a value greater than 0, and the value is preserved.
  • Cookies Settings:
    • The Cookies Settings is set to By adding allowed cookies, and the system enforces cookies as it did in versions prior to version 11.0.0.
    • All allowed cookies are upgraded as Allow cookies.
    • Tightening is upgraded as Add allowed cookies.
    • Wildcard order: Longer and more specific wildcards are first in the list, and * and less specific wildcards are last.
  • Web Applications: Web Applications will have a folder prefix added to their name, corresponding to their HTTP Profile.

    Note: The term "web application" in the context of ASM was removed in version 11.1.0.

  • Denial of Service (DoS) Attack Prevention Settings:
    • The URL Detection Criteria: Minimum TPS Threshold setting is populated with the value of the internal parameter dos_min_detection_object_threshold previously set in the Options > Advanced Configuration screen.
    • The IP Detection Criteria: Minimum TPS Threshold setting is populated with the value of the internal parameter dos_min_detection_ip_threshold previously set in the Options > Advanced Configuration screen.
  • CSRF, Web Scraping, and Data Guard Settings: In version 11.x there are new checkboxes on each of these features’ configuration settings screens that need to be selected in order to enable these features. After upgrade or import, CSRF, Web Scraping, and Data Guard will be enabled if the corresponding violations had any of the Learn, Alarm, or Block check boxes enabled in the Policy > Blocking > Settings screen.

Changes the system makes after you upgrade from version 9.4.3 to version 10.x, or later

The system automatically makes the following changes after you upgrade from version 9.4.3 to version 10.x, or later.

  • The system saves all allowed response codes you previously configured using the http_ error_ filter_ list parameter on the Advanced Configuration screen, and copies them to the Allowed Response Codes setting on the Security Policy Properties screen. Please note that while in previous versions you configured allowed response codes per unit, in this version you configure them per security policy.
  • The system enables the appropriate HTTP validations on the HTTP Protocol Compliance screen if you had previously configured the parameter non_rfc_bitmask (found on the Advanced Configuration screen in earlier versions). Please note that while in previous versions you configured HTTP protocol validation per unit, in this version you configure it per security policy.
  • The system enables the Null in request HTTP validation found on the HTTP Protocol Compliance screen if you had enabled the Learn, Alarm, or Block flag of the Forbidden Null in request violation on the Blocking Policy Screen.
    The Learn, Alarm, and Block settings for the Null in request HTTP validation are dependent on how you specify the Learn, Alarm, and Block settings for the HTTP protocol compliance failed violation on the Blocking Policy screen.
  • The system enables the Unparsable request content HTTP validation found on the HTTP Protocol Compliance screen if you had enabled the Learn, Alarm, or Block flag of the Illegal HTTP format violation on the Blocking Policy Screen.
    The Learn, Alarm, and Block settings for the Unparsable request content HTTP validation are dependent on how you specify the Learn, Alarm, and Block settings for the HTTP protocol compliance failed violation on the Blocking Policy screen.

From version 9.4.4 and later we do not support nor enforce the violation LF line separator, which was part of the non_rfc_bitmask Advanced Configuration parameter in previous versions.

Additional information if you upgrade or import a security policy from version 9.4.3, or later to version 10.x, or later

If you upgrade from version 9.4.3, or later, to version 10.x, or later, or import a security policy from version 9.4.3, or later, to version 10.x, or later, note the following:

  • In version 10.0.0 we created a new XML engine that contains wide coverage for various XML attacks. We upgraded the XML signatures so that they are now part of the general attack signature pool.
    • If you upgrade from version 9.4.3, or later, to version 10.x, or later, the system carries over all XML defense settings and validation files to the new XML engine. However, the signatures themselves are not automatically upgraded, and the system uses the old signatures which do not have support for XML enforcement unless you manually update the signatures. To update the signatures, go to the Attack Signature Update screen and click the Update Signatures button to add XML signature support.
    • If you import a security policy from version 9.4.3, or later, to version 10.x, or later, the imported policy uses the updated signatures, including those that support XML enforcement.
    Note: Signatures with changed enforcement are placed in Staging, if you enabled Staging.
  • In version 10.0.0 we moved a number of SQL injection attack signatures from the General Database system to new systems that we created (PostgreSQL, IBM DB2, and Sybase/ASE) and to already existing systems (MySQL and Microsoft SQL Server). As a result, the General Database system, and any signature set that contains the General Database system (such as the Generic Detection Signatures set) contain less signatures in version 10.x, or later, than in previous versions. If you upgrade or import a security policy that includes a signature set with the General Database system assigned to it, the system keeps all signatures in the General Database system that were included in it before version 10.x as long as you do not update the attack signatures file. However, once you update the attack signatures file, the system replaces the General Database system signature list with the new, smaller list. Therefore, if you want the system to continue enforcing SQL injection attack signatures that were removed from the General Database system, you must reassign them to the security policy. You can do this either by assigning the systems that contain the signatures you want enforced, or by creating a user-signature set that includes these signatures.
  • The system adds denial of service (DoS) default settings automatically to all existing policies regardless whether you upgrade or import a security policy from version 9.4.3, or later, to version 10.x, or later.
  • In version 10.0.0 we moved Dynamic session ID in URL from the web application level to the security policy level.
    • If you upgrade from version 9.4.3, or later, to version 10.x, or later, the dynamic session ID in URL attributes are moved from each account to the account’s security policies.
    • If you import a security policy from 9.4.3, or later, the system sets the Dynamic Session ID in URL option to Disabled.
  • The order of the Reporting Server logging fields in Application Security Manager version 10.0.0 is different from that in earlier versions. If you upgraded from a previous version of the Application Security Manager, logging profiles created before the upgrade appear with fields in the previous order. Newly created logging profiles have the new field order, however.

Additional information if you upgrade or import a security policy to version 10.1.0, or later

If you upgrade from version 9.4.3, or later to version 10.1.0, or later, or import a security policy to version 10.1.0, or later, note the following:

  • Internal parameters remain set to the previous settings, except for MaxJobs, max_filtered_html_length, and PRXRateLimit parameters. These internal parameters change to the default values that are set in version 10.1.0, or later.
  • Preferences, found on the Overview > Preferences screen, are not saved in the UCS file. So, if you upgrade to version 10.1.0, or later or export and import a security policy to version 10.1.0, or later, the preferences configuration is not saved.

Security policy status after UCS installation

After you install a .ucs (user configuration set) file that was exported from version 9.4.3 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.

[ Top ]

Changing the Resource Provisioning level of the Application Security Manager

Important: This section is not relevant if you are using the standalone version 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 made before this process is completed. The system informs you when the process is not completed by displaying, in the Configuration utility, the following message: ASM is not ready. The system informs you when the process completed by indicating in the Application Security Manager log (/var/log/asm) the following message: ASM started successfully.

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

Open the command-line interface utility, and run the following commands:
      tmsh modify sys provision asm level nominal
      tmsh save sys config

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

  1. Using the Configuration utility, on the Main tab of the navigation pane, expand System, and click 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.
[ Top ]

Additional configuration information

Preventing traffic from bypassing the Application Security Manager
We recommend you read Solution 8018 (SOL8018) and Solution 12268 (SOL12268) on the AskF5 web site. These solutions contain important configuration information needed to prevent traffic from bypassing the Application Security Manager.

[ Top ]

New items and fixes in this release

This release includes the following new items and fixes.

New in this release

This release includes the following new items.

Configuration Utility Menu
Application Security (ASM) is now one of a few modules that are a part of F5 Networks Security solution. The other modules that are part of the BIG-IP Security suite are Protocol Security (PSM), and Advanced Firewall (AFM). As a result, you will find Application Security under the Security menu in the Main navigational pane.

The Configuration utility is organized differently than in previous versions. The configuration and reporting of different Security modules are now consolidated under the Security menu. Here are some examples:

  • Under Security > Event Logs you will find logs for all Security modules purchased and provisioned.
  • Under Security > Reporting you will find graphic charts for all Security modules purchased and provisioned.
  • Under Security > Options you will find advanced configuration options for all Security modules purchased and provisioned.

Overview screen
This version includes an Overview screen (Security > Overview > Summary) where you can create and personalize widgets that display statistical information about traffic logged by the BIG-IP system for all modules licensed and provisioned under the Security tab, in graphs. These modules include: Application Security (ASM), Protocol Security (PSM), and Advanced Firewall (AFM).

DoS Protection
DoS protection is no longer specific to Application Security. F5 Networks now offers DoS protection for Layers 2-4 in addition to the Application Layer (Layer 7). DoS Application protection comes with ASM, and DoS Network protection comes with Advanced Firewall Manager (AFM). You will find DoS Protection configuration under the Security menu.

In order to log DoS events, you must configure a logging profile, now found under the Security menu (click Security > Event Logs > Logging Profiles).

Logging Profiles
You can configure separate logging profiles, or one logging profile for Application Security, Protocol Security, Advanced Firewall, and DoS protection for applications (Layer 7) and Layers 2-4. Each part can be enabled or disabled by creating or deleting the corresponding sub-profile. Consequently, the logging profiles configuration screen has been removed from the Application Security menu (and from the Security Policy Properties screen), and placed under the Security menu on the Main tab (Security > Event Logs > Logging Profiles).

A logging profile is used to record requests to the virtual server. You now assign logging profiles to virtual servers, not to security policies.

Important: Since logging profiles are now assigned to virtual servers (not security policies), if you want the system to use a specific logging profile, you must assign it to a virtual server. To do this, perform the following steps:

  1. On the Main tab, click Local Traffic > Virtual Servers > Virtual Servers List.
  2. Click a virtual server to which you want to assign a logging profile.
    The virtual server properties screen opens.
  3. From the Security menu choose Policies.
    The Policy Settings screen opens
  4. Set Log Profile to Enabled.
  5. In the Profile setting, select the logging profile you want the system to use, and move it from the Available list to the Selected list. (The Deployment wizard automatically assigns the profile Log illegal requests in the Selected list.)

Selective Learning
In previous versions you used wildcard entities temporarily as a means for the system to learn all entities that matched the wildcard. (This process was called Tightening and is now called Learn Explict Entities.) Once all explicit entities were added to the security policy, the wildcard entity was removed, either by the system when the security policy was considered stable according to the Automated Policy Builder, or manually when the Staging-Tightening period ended and you were manually building the security policy. This method of using wildcard entities is still available in version 11.3.0.

In version 11.3.0 we introduce a different way of using wildcards to build a security policy. This option is only applicable for the * wildcard, which remains in the security policy. When false positives occur, the system will adds/suggests you add an explicit entity with relaxed settings that avoid the false positive. The wildcard entity is never removed from the security policy, but it is removed from staging mode when no more exceptions need to be added.

Using selective learning:

  • Whenever the Automated Policy Builder is running, it adds explicit entities that do not match the attributes of the * wildcard. The Policy Builder does not remove the * wildcard entity from the security policy.
  • When the Automated Policy Builder is not running (and you are building the security policy manually), with learning suggestions, the system suggests that you add explicit entities that match the * wildcard entity if the explicit entity does not match the attributes of the * wildcard entity.

To configure whether the Automatic Policy Builder should add, and the Manual Traffic Learning should suggest, all explicit entities that match a wildcard (Add All Entities), never add explicit entities (Never: wildcard only), or learn in the new selective learning mode (Selective), navigate to the Security > Application Security > Policy Building > Settings screen.

Policy Diff
The Policy Diff enhancement allows you to easily view differences between two security policies, and to merge configured elements (such as URLs and Login Pages) from one security policy to another.

There are different granularity levels of merging security policies. You can have the system automatically merge two security policies, you can manually review each security policy entity, or manually review every attribute for each security policy entity.

Users can import a security policy (which is then placed in the Inactive Policies list) and then compare it with another security policy. Users can compare security policies in the Active Policies list and the Inactive Policies list with each other, and users can compare security policies with Policy Builder enabled or disabled.

This feature is especially useful for customers who want to compare a security policy in staging with one in production, and customers who want to compare different vulnerability scanning results of the same web application.

Users with a role of Administrator, Resource Administrator, Application Security Editor, and Application Security Administrator may use this feature.

To perform a Policy Diff, navigate to the Security > Application Security > Security Policies > Policy Diff screen.

Generic scanner support

In the previous version, ASM provided an interface that represented vulnerabilities found by specific scanners. In this version, we provide a general schema XSD file, available on the machine (/var/ts/share/generic_scanner.xsd), that any trusted vendor can use to write a vulnerability scanning results XML file, which is then uploaded into ASM.

Using the system's schema file, Application Security Manager can automatically resolve the following vulnerabilities:

  • SQL-Injection
  • Information Leakage - Credit Card
  • Information Leakage - SSN
  • HTTP Response Splitting
  • Cross-site Request Forgery
  • Command Execution
  • Cross Site Scripting (XSS)
  • XPath Injection
  • Predictable Resource Location
  • Path Traversal
  • Path Traversal Apache Relative Path
  • Path Traversal Unix Relative Path
  • Path Traversal Windows Relative Path

Application Security Manager supports other vulnerabilities, but does not resolve them automatically.

After the user uploads the XML vulnerabilities scanning results file, ASM enables you to resolve, ignore, or disable the Ignore option for the vulnerabilities found. The system tracks all changes to the security policy in the Policy Log. To use this feature while creating the security policy, run the Deployment wizard using the Create a policy using third party vulnerability assessment tool output scenario, and in the Vulnerability Assessment Tool setting, select Generic Scanner. To use this feature after a security policy has already been created, navigate to the Security > Application Security > Vulnerability Assessments > Settings screen, and for the Vulnerability Assessment Tool setting, select Generic Scanner.

Protocol Independent URLs
You can now configure the security policy to configure URLs without their protocol, that is, the security policy does not differentiate between HTTP and HTTPS URLs. This is useful when dealing with web applications that behave the same way for HTTP and HTTPS, and saves you from having to configure the same URL twice.

When you configure the settings of the security policy for the first time using the Deployment wizard, you decide whether the security policy configures URLs with or without their protocols. After the security policy is configured, you can remove the differentiation and unify the protocols by changing this setting from the Security Policy Properties screen, if appropriate. You cannot change this setting if the security policy has two identical URLs with different protocols.

Note: The option not to differentiate between URL protocols is not available from the Deployment wizard using the scenario Create a policy manually or use templates when using an Application-Ready Security Policy template.

If you configure the security policy not to differentiate between protocols, the system does not display the URL protocol in the Configuration utility, except for in the logging and reporting screens.

Google Web Toolkit
Version 11.3.0 of ASM includes Google Web Toolkit (GWT) support, parsing and protection. You must create a GWT profile that defines what the security policy enforces and considers legal when it detects traffic that contains GWT data. Some of the settings you configure are the maximum total length of the entire payload, and the maximum value length of each section in the payload. ASM performs value meta-character checks and attack signature checks on the payload. To create a GWT profile, navigate to the Security > Application Security > Content Profiles > GWT Profiles screen, and click Create.

After creating a GWT profile, you must assign it to a URL (using the URL properties screen).

The system offers learning suggestions for GWT violations if the security policy is configured to learn GWT violations. There are two GWT learning violations:

  • Malformed GWT data: The system verifies that the payload data is formatted and structured correctly.
  • GWT does not comply with format settings: The system checks whether the size of each section of the payload, and the overall size, comply with the settings configured in the GWT profile.

Base64 Decoding
You can set the security policy to check whether user input parameter values that contain a Base64 encoded string actually use a valid string. If the value is indeed Base64 encoded, the system decodes this value and continues with its security checks on the decoded value. In case the value is not Base64 encoded, the system continues its checks on the actual value without decoding it. This enables the system to expose a potential attack that might be hidden in the request.

This option is available for user input alpha-numeric parameters and file upload parameters. To enable this option, perform the following steps:

  1. Navigate to the Security > Application Security > Parameters screen.
  2. Click Create.
  3. Set the Parameter Value Type to User-input value.
  4. Set the Data Type to either Alpha-Numeric parameters or File Upload.
  5. Select the Base64 Decoding check box.

We added the violation, Illegal base64 parameter value. This violation is triggered if a parameter in the security policy is configured to contain a Base64 encoded string value, but is determined by the system that the value is not encoded as Base64. From this violation’s Learning screen you can stop the security policy from decoding Base64 encoded values for the parameter in question.

Cookie Attributes: HttpOnly and Secure
You can direct the system to add the HttpOnly attribute to the domain cookie’s response header. This is done to expose the cookie to only HTTP and HTTPS entities. This prevents the cookie from being modified, or intercepted, even if it is not modified, by unwanted third parties that run scripts on the web page. Since this is a request that the server asks the browser to perform, on the browser's environment, the system cannot verify that the cookie has not been modified or intercepted. The default setting is disabled.

You can direct the system to add the Secure attribute to the domain cookie’s response header. This is done to ensure that the cookies are returned to the server only over SSL (by using the HTTPS protocol). This prevents the cookie from being intercepted, but does not guarantee its integrity. Since this is a request that the server asks the browser to perform, on the browser's environment, the system cannot verify that the cookie was received over SSL. The default setting is disabled.

Note: These features cover all security policy cookies, both enforced and allowed, explicit and wildcard. The feature does not apply to ASM (TS) cookies.

To enable these settings, navigate to the Security > Application Security > Headers > Cookies screen and either add or edit a cookie.

Clickjacking Protection
You can protect your web application against clickjacking by directing the system to add the X-Frame-Options header to the domain cookie’s response header. Clickjacking occurs when attacker lures a user to click illegitimate frames or iFrames because the attacker hid them on legitimate visible website buttons.

After you enable clickjacking protection for a specific URL, you specify the conditions that determine whether the browser should allow this URL to be rendered in a frame or iframe.

To enable these settings, navigate to the Security > Application Security > URLs screen and either add or edit a URL. The default is disabled.

Reporting Enhancements
The ASM reports now have the same style as those of the Analytics (AVR) module. This was done to provide the following functionality to the reports:

  • A unified look and feel for statistics across modules
  • An improved look for the reports
  • The ability to export reports in CSV or PDF format as a file on your computer or send it to a specific email address.

To view the new ASM reporting screens, navigate to the Security > Reporting > Application screen.

Web scraping Enhancements
In addition to bot detection, in this version we added protection against two anomalies (both disabled by default):

  • Session opening anomalies are detected when a large number of sessions are opened from a specific IP address, and a large increase of sessions are opened from a specific IP address.
  • Session transactions anomalies are detected when the system notices a large number of requests per session, and a large increase of requests per session compared to a total average of requests from all sessions.

To enable these checks, navigate to the Security > Application Security > Anomaly Detection > Web Scraping, and set Session Opening Anomaly and Session Transactions Anomaly either to Alarm, or Alarm and Block.

DoS protection Enhancements
This version provides the following enhancements to the DoS feature:

  • An added Overview screen (Security > Overview > DoS) where you can create and personalize widgets that display statistical information about DoS traffic logged by the BIG-IP system, in graphs.
  • The TPS-Based and Latency-Based detection methods now work concurrently. Until now they were mutual exclusive.
  • The collected statistics for detection are now per virtual server, rather than per security policy.
  • Added protection for layers 2-4, available if you purchase the Advanced Firewall Module (AFM).

Policy Builder Enhancements
We enhanced the behavior of the Automatic Policy Builder and Manual Learning when the security policy is configured to contain a wildcard entity and never learn explicit entities. The Policy Builder now changes, or suggests you change, the attributes of the wildcard, even if it is configured not to learn explicit entities.

  • When the Automated Policy Builder is running, it now changes the attributes of the matched wildcard in the security policy according to the properties of explicit entities discovered during real traffic.
  • When the Automated Policy Builder is not running, the system now suggests that you change the attributes of any matched wildcard entity in the security policy. As with previous releases, the system does not suggest you add explicit entities that match the wildcard entity.

Extended Enterprise Management support: Centralized Management
With this release, ASM devices are more manageable by Enterprise Manager (EM).

There is improved usability of security policy deployment in EM, and you can now perform the following ASM tasks within the EM environment:

  • Manage the deployment of IP exceptions.
  • Manage the deployment of logging profile.

For more information about Enterprise Manager, see the Enterprise Manager documentation on support.f5.com.

Configuration utility changes
We made the following changes to the ASM Configuration utility:

  • Changed the sequence of ASM sub-menus for easier navigation. The features are now placed in a more logical order, with fewer submenus.
  • Removed the IP enforcer feature, because the Session Awareness feature can block users according to IP Address Threshold which has the same ability as the IP enforcer feature.
  • Added an enhanced filter on Event Correlation screen.
  • Added CSRF as an Element Type in the Policy Log screen.
  • On the Requests screen, added Auto Refresh option.
    Enable this for the system to automatically refresh the data displayed on the screen. This is useful in order to track live traffic. Select from the list how many seconds should be counted before the system refreshes the data. The default is Disabled.
  • Added Every 1 Month option to the charts scheduler frequency.
  • Added an Add button on the Brute Force Protection Configuration screen which opens a popup screen and enables you to add a login page without leaving the brute force configuration.
  • Added the Disable button to the Policy Attack Signatures screen (click Security > Application Security > Attack Signatures > Attack Signature List) so that you can stop the system from enforcing many attack signatures at once without needing to disable each signature individually by viewing its properties.
  • Added a new ASM system variable, reporting_search_timeout, which specifies the amount of time the system should wait to return filter results in the Security > Event Logs > Application > Requests screen before the system performs a timeout of the filter request. The default value is 60 seconds.
  • Added the string X-Infection-Found to the value of the system variable virus_header_name.
  • On the Brute Force Properties screen, edited the names of the Dynamic Brute Force Protection Operation Mode settings from Transparent to Alarm, and from Blocking to Alarm and Block.
  • Edited the IP address range of the system variable WhiteHatIP1 from 209.10.217.224/27 to 63.128.163.0/27.
  • Removed learning for the web scraping detected violation.
  • Removed the internal parameters rapid_surf_max_time_duration and rapid_surf_max_page_changes because they are now configurable from the Configuration utility.
    To configure rapid surfing protection, navigate to Security > Application Security > Anomaly Detection > Web scraping, and set Bot Detection to Alarm or Alarm and Block.
  • Due to the improvements made to the ASM reports, removed the ASM Dashboard.
  • Due to the removal of the term "web application" from the Configuration utility, renamed the following user roles:
    • From Web Application Security Administrator to Application Security Administrator.
    • From Web Application Security Editor to Application Security Administrator.

Minimal export format
In addition to exporting the security policy in XML or Binary format, in this release you can export a security policy in minimal XML format. This means that the exported security policy does NOT include the following information:

  • The staging state of attack signatures.
  • The following entities, unless their values are different from the system's default settings:
    • Meta-Character sets
    • Blocking page settings (Learn, Alarm, and Block)
    • Response Pages
    • IP Reputation Categories

We advise you to perform a minimal export if you want to limit the size of the exported security policy. One use case for this is if you want to manage the security policy using tmsh commands, which can only be done for security policies smaller than 64K.

Extended tmsh support
This version has expanded tmsh command support that enables you to display and modify certain parts of security policies.

The new tmsh commands include the following:

  • list asm policy: Displays the properties of a security policy.
  • load asm policy: Imports a security policy from XML or binary format. The command supports a file name or XML string (used for iApp scripts).
  • save asm policy: Exports a security policy into XML or binary format, to /var/tmp.
  • publish asm policy: Applies a security policy (This command should be run after the load asm policy command). If the security policy is offline, an enabled httpclass-profile should be specified.
  • create asm policy: Creates a new security policy with all possible properties from the list asm policy command, except read-only virtual-servers.
  • modify asm policy: Modifies an existing security policy.
  • delete asm policy: Removes an offline security policy, or reconfigure an active security policy.

Updating a security policy using tmsh is possible only by importing and exporting the security policy. Since managing security policies by tmsh commands is limited to security policies smaller than 64K characters, we added a new option to export a security policy in “minimal” format. An exported security policy in minimal format does not include the following information:

  • The staging state of attack signatures.
  • The following entities, unless they are different from how they were when created:
    • Meta-Character sets
    • Blocking Flags (learn/alarm/block)
    • Response Pages
    • IP Reputation Categories

Note: After importing the exported security policy, the system overwrites the security policy’s settings with the system’s default settings.

To export a security policy using this option, either use the save asm policy command with the minimal variable, or navigate to the Security > Application Security > Security Policies > Policies List screen, click Export, and select the Minimal export check box.

Using the Cenzic service to mitigate web application vulnerabilities
In addition to connecting with Cenzic using the Cenzic Cloud service, with this version you can also connect with Cenzic using a local Cenzic ARC server. These two options are mutually exclusive: If a Cenzic ARC server address is configured then it is used; otherwise, the system uses the Cenzic Cloud service.

To configure the Cenzic ARC server, navigate to Security > Options > Application Security > Preferences, and in the External Services area of the screen, add your local Cenzic ARC server address.

Fixes in this release

This release includes the following fixes.

ID Number Description
ID 223149, ID 309642, ID 338657 With the introduction of Policy Diff, the Policy Merge known issues are fixed and are no longer relevant.
ID 225123 Non-latin characters in requests that were always presented correctly in the Configuration utility are now also presented correctly in the exported requests PDF document.
ID 305865 There is now unified date and time format for all security policy export file names and log names: YYYY-MM-DD_HH-MM.
ID 305935 We added the Auto Refresh option to the Security > Event Logs > Application > Requests screen to enable a live trace on a specific IP address or user. Note the following details about the auto refresh:
  • Changing the filter settings or opening request details disables the auto refresh.
  • Most of the other actions (like paging and sorting) just stop the auto refresh.
ID 332396 iControl now supports all user roles and granted partition accesses.
ID 354115 The system correctly displays IP address information in the Brute Force Anomaly Detection Statistics screen.
ID 360369 The Enforcer no longer performs a core dump if the system's DNS lookup for bots times-out.
ID 361187 You can now disable an attack signature on a Global parameter that matched the incident if you have a matching Global parameter defined in the security policy. You can also disable an attack signature on a URL parameter that matched the incident if you have a matching URL parameter defined in the security policy.
ID 366011 An empty Accept-Encoding header no longer triggers the HTTP Protocol Compliance sub-violation Header name with no header value. This complies with the RFC.
ID 366997 The system no longer presents empty DoS attack logs after incorrectly suspecting and declaring a DoS attack. Previously, this sometimes occurred if there was a sudden spike in traffic which stopped a couple of seconds later.
ID 368337 If a remote logging server is configured incorrectly (for example, with the wrong IP address or port), the Enforcer spends a long time unsuccessfully trying to connect to the server. As a result, the Enforcer sometimes used to hang and crash. This is no longer the case.
ID 374583 Users can now export statistics regarding dropped requests due to DoS attacks, brute force attacks, or web scraping. Previously, users could only export logged and blocked requests.
ID 376527 On the Event Correlation Incidents List screen, you can now filter incidents by severity and request count.
ID 376612 Performing the Apply Policy action no longer fails while there is a lot of traffic running on the VIPRION B4300 with two blades or on a VIPRION 2400 with 2 blades. Previously, it could take up to 40 seconds for the system to accept a configuration change on these machines under a high load (more than 1500 users), and the DoS and web scraping features were enabled.
ID 377298 Support for the merge of content profiles was added as part of the new Policy Diff feature.
ID 377726 We added the task ASM service restart is required on the Security > Overview > Application > Tasks screen when the user performs a system change, like editing the value of a system variable (internal parameter). This task informs the user that the user must run the command tmsh restart sys service asm for the system change to take effect. Note that if a user is using a device group, the user must run the command tmsh restart sys service asm on all members of the device group.
ID 380857 To prevent the logging of the Request length exceeds defined buffer size violation with incorrect values, we limited the content length header value to 20 digits.
ID 381386 The system now correctly handles the Application Language "Chinese gb18030".
ID 381524 If there is a quotation mark character (") in the middle of a cookie value, the malformed cookie violation is triggered if the internal parameter report_invalid_quote_in_cookie_value is set to 1. The parameter's default value is 0. To set the parameter's value to 1, from the command line, run the following command: add_del_internal add report_invalid_quote_in_cookie_value 1
ID 381687 SMTP configuration was added to the System > Configuration > Device > SMTP screen and it should be used for all modules. As a result, we removed the Application Security > Options >SMTP Configuration screen.
ID 381895 Performing the Apply Policy action on a security policy with identically named parameters on different levels (for example, global and URL) no longer incorrectly generates the error: "The following extracts do not have a matching parameter". Previously in specific circumstances, it used to occur.
ID 383506 For clarity, we changed the term Configure Application Security Device Group to Configure Application Security Synchronization.
ID 383612 Using the VIPRION® B4300 with the ASM and GTM modules provisioned as Nominal: The Enforcer no longer shrinks on the secondary blade after applying a security policy on the primary blade as it used to when traffic was running through the blades.
ID 383927 You can now delete a parameter with staging enabled from the Application Security > Parameters > Parameters List screen when the Enforcement Readiness (used to be called Staging-Tightening) filter option is set to Not enforced (used to be called Enabled).
ID 384142 Enabling the IP Intelligence feature on a multi-blade system: After initially updating the IP Intelligence database, the system no longer logs unnecessary error messages in the LTM log when copying the database to secondary blades.
ID 385363 On the logging profile screen, we changed the name of a remote storage format item from ip_reputation to ip_address_intelligence to correctly reflect the feature's name. As a result, the format of the logging message also changed.
ID 386019 We fixed an issue that caused the enforcer to perform a core dump when the system's plug-in was initialized or uninitialized repeatedly.
ID 387218 The system injects JavaScript to the client side for some configurations of the web scraping, brute force and DoS features. When these features are enabled, the system now tests browsers to see whether JavaScript is enabled or disabled in the browser. If JavaScript is enabled in the browser, these features work as expected. If JavaScript is disabled, then the system displays the following message in the browser: "Please enable JavaScript to view the page content." This prevents the system from blocking the web application not because of an attack, but because the browser does not allow JavaScript.
ID 387819 The Brute Force IP address whitelist is now relevant for both session-based brute force protection and dynamic brute force protection. Note that the Anomaly Detection features share the same IP address whitelist. Therefore, any change made to the Brute Force IP address whitelist also applies to the IP Address Whitelist of the Web Scraping Detection configuration.
ID 389002 When running the Deployment wizard using the scenario Create a policy for XML and web services manually, by default the system now assigns the XML attack signature system to the security policy in addition to the Default group of signatures.
ID 389577 The iControl SDK for the ASM::WebApplication::set_active_policy method explains that when using this method to activate an Inactive ASM security policy, the webapp_names parameter are the names of the HTTP Class profiles.
ID 391493 The system now detects touch screen browser events as human events. Previously, the system only considered mouse movements and pressing on the keyboard as human events.
ID 392087 The system now correctly handles a case where a security policy imported from a v10.2.x policy export file may contain a misconfigured Blocking Response Page that, in limited instances, prevented the policy from being applied.
ID 392451 The system now retains identification numbers for user-defined attack signatures that are exported and then imported.
ID 392719 If you are running standalone ASM and you delete the HTTP Class associated with an active security policy, the security policy is now correctly moved to Recycle Bin.
ID 393468 You can now perform configuration synchronization between a device with a lower BIG-IP version to a device with a higher BIG-IP version if the devices are within the same device group.
ID 394506 We optimized the Enforcer's memory allocation for large requests.
ID 394522 If you upgrade from a version that includes this fix, then after upgrading a member of a manual sync device group with ASM enabled, the device no longer requests a full sync from its peer upon start up.
ID 394525 Changing the parameter level of a wildcard parameter (such as from URL to Global), when the wildcard sequence position conflicts with that of another wildcard parameter, no longer causes subsequent Apply Policy attempts to fail.
ID 395601 The system now cleans files in /ts/var/cluster/temp that are more than 1 hour old to keep the /var disk partition from filling up.
ID 395613 The system now can import a scanner vulnerability file with a non-ASCII parameter name.
ID 395938 Now the system performs event correlation, and displays the incidents, even on a chassis with only one active blade.
ID 395946 The WebAccelerator cache is now automatically invalidated when you assign an HTTP class profile, with the Application Security setting enabled, to a virtual server that has a Web Acceleration profile assigned to it.
ID 398175 To improve the integration between ASM and Whitehat Sentinel vulnerability assessment, ASM's Whitehat IP address range was updated.
ID 398367 If modifications are made to the active security policy but those changes are not yet enforced, upon loading of the UCS file, the system ensures that it enforces the most recently activated version of the security policy.
ID 398690 If ASM is not provisioned when a UCS file is loaded, then the ASM configuration is moved aside to be installed later (delayed load), and the configuration files are now created with the correct permissions. In previous versions, they were not created with the correct permissions.
ID 398699 The Enforcer now correctly injects JavaScript when tags generated by JavaScript are split between quotation marks, like: 'ht' + 'ml'.
ID 399959 In a case where there is a change in the subnet to the self config-sync IP address, the ASM device group listener may not process incoming requests for an extended period of time, and then loads an old and invalid configuration. In this release, the listener no longer polls indefinitely on an IP address, and rejects configurations older than one day.
ID 400587 We added the internal parameter allowXSIRename that enables you to allow using a namespace prefix different from xsi for http://www.w3.org/2001/XMLSchema-instance. Set this parameter to 1 to allow different names for the xsi prefix. The default value is 0 (disallow). To set the parameter value to 1, run the command: /usr/share/ts/bin/add_del_internal add allowXSIRename 1 bigstart restart asm
ID 401501 The system now correctly populates parameter learning suggestions in the Illegal Parameter screen. Previously, if you clicked a parameter in the Application Security > Policy Building: Manual > Traffic Learning > Illegal Parameter screen, the parameter name was always displayed as UNNAMED, and it was not possible to enforce or delete the parameter.
ID 379693 If the /ts/var/license/current file is empty, then after a user renews an expired license, the Enforcer applies configuration changes.
ID 395340 We fixed the close element for sequences having the "anyType" child.
ID 387964 We have corrected an issue which could cause IP reputation to not work properly.

Features and fixes introduced in prior releases

New features introduced in 11.2.1

There were no new features introduced in version 11.2.1.

Fixes introduced in version 11.2.1

This release includes the following fixes from version 11.2.1.

ID Number Description
ID 381620 The system now adds Content-Type header data to the client side challenge response. In the past this was sometimes an issue when the system performed web scraping, brute force, and DoS attack prevention against clients that decided on the response type based on the requested file extension.
ID 385135 Learning suggestions for the violation Access from malicious IP address no longer disappear after a user navigates to a different ASM screen.
ID 385870 Fixed a scenario of the system's cookie parser mechanism. The system now correctly parses any cookie, even one that has no value but has an equal sign or a whitespace. In the previous version, this issue sometimes caused a false positive.
ID 386698 When a 401 response arrives instead the expected 100-continue message, and the client continues with the payload, the Enforcer no longer resets the connection.
ID 387834 If the internal parameter search_onload is enabled, then the Enforcer injects JavaScript code, which cancels the original onload function with the CSRF JavaScript. This solves the incidents when the customer's onload function runs before the CSRF JavaScript.
ID 387964 We have corrected an issue which could cause IP reputation to not work properly.
ID 388256 Regarding XML content profiles, the default namespace URI of a schema without a target namespace no longer changes when it is included in another schema with the target namespace.
ID 388678 Parameter names are now correctly displayed on the following screens:
-Application Security > URLs > Allowed URLs > URL Parameters
-Application Security > URLs > Allowed URLs > Advanced Extractions
-Application Security > URLs > Flows List > Flow Parameters
-Application Security > Parameters > Parameters List > Change Parameters Type
ID 389111 If you create an override to an attack signature in an XML profile in the security policy without applying this change, and then automatically apply attack signatures, the system now also applies the override.
ID 389565 We fixed an issue that, due to a memory leak, caused ASM security policies not to synchronize completely after performing an ASM configuration synchronization.
ID 390322 We improved the Traffic Overview screen to prevent an XSS vulnerability For more information, see SOL 13838.
ID 390372 When a user runs the command: asmqkview --include-traffic-data the PLC file plc_non_configsync_dump.sql is no longer truncated. In the previous version, the system truncated this file.
ID 390951 We increased the maximum parameter length (in KB) that the system can enforce.
ID 391092 We fixed how the system handles the all schema element children, and close handling, when processing an XML document and counting all elements. Previously, this issue sometimes led to the system incorrectly logging an XML violation.
ID 392240 We fixed an issue with the IP Intelligence feature that sometimes caused the Enforcer to core.
ID 394201 Attack Signature Update now completes successfully even if you upgrade from a version prior to 11.2.0 to version 11.2.0 or later and then perform a signature update.

New features introduced in 11.2.0

Action Items
New in this release, in the Configuration utility you can see a list of outstanding system-wide configuration tasks (such as whether a signature update is available), and a list of how many outstanding security policy configuration tasks remain for each security policy.

Each security policy has its own summary screen that displays the Policy Builder status for that security policy, tasks that the system recommends you take care of in the security policy, and quick links to further configure the security policy. Examples of security policy quick links are Configure DoS Protection and Configure Web Scraping. Click each link to go to the screen where you can configure that item.

As in previous versions, the Configuration utility still displays the status of the Policy Builder for each active security policy, and statistical information regarding attacks, attack types, and traffic that the system detected to the web application.

To view tasks and quick links for your web applications, go to Application Security > Overview > Summary.

Scanner support for existing security policies
In previous releases, you could use a vulnerability scanner only to help build a new security policy (from the Deployment wizard’s Create a policy using third party vulnerability assessment tool output scenario). In this release, you can also use a vulnerability scanner to further build an existing security policy even after its basic configuration is done. In this case, when resolving vulnerabilities, the system displays a pop-up screen informing you, and requesting confirmation, of actions that it must perform in order to resolve the vulnerabilities. Some examples are adding a signature set to the security policy, and disabling staging mode for a parameter.

Scanner integration with Cenzic
In this release, Application Security Manager’s vulnerability assessment feature is integrated with Cenzic’s Cloud. Application Security Manager can connect with Cenzic’s Cloud and perform the following actions.

  • If you are already registered with Cenzic: redirect to Cenzic’s login page to log in, and either download existing scan results from a specific subscription, or request a new scan and automatically load the scan results when the scan is finished.
  • If you are not registered with Cenzic: redirect to Cenzic’s registration page to enter basic information about the web application, request a basic free scan, download the scan results, and automatically load the scan results when the scan is finished.
  • Mitigate the vulnerabilities using Application Security Manager.

 

IP Address Intelligence
With this release, we now provide the option to view the reputation of an IP address. If a specific IP address is found in the IP Intelligence database, you can view the specific matched category of that IP address, and you can configure the system to block requests from this IP address.

The IP Address Intelligence database checks every source IP address against a dynamic blacklist. The database is continuously updated every 5 minutes. It can identify IP addresses associated with high risk, such as anonymous proxies, Tor exits, phishing proxies, botnets, and scanners.

Important: To use this feature, you need internet access from the BIG-IP system, and an add-on license on top of the Application Security Manager license. If you have this feature licensed, then by default this feature is enabled in Application Security Manager. We provide you with a 30-day evaluation license to preview the functionality. When the license expires, if you do not renew it, the trial feature functionality ceases, but other ASM functionality remains. The 30 day trial license can be downloaded here. To purchase a permanent license, contact F5 Sales.

Important: After installing version 11.2.0, you must install version 11.2.0 HF1 and above in order to be able to download updates from the IP Intelligence database.

The possible categories that IP addresses can match are as follows:

  • Windows Exploits: IP addresses that have exercised various exploits against Windows resources through browsers, programs, downloaded files, scripts, or operating system vulnerabilities.
  • Web Attacks: These IP addresses have launched web attacks of various forms.
  • Botnets: These IP addresses represent machines that have been compromised on the Internet and are now part of a Botnet. Botnets may be exploited by their controllers to send spam messages, launch various attacks, or behave in other unpredictable ways.
  • Scanners: IP addresses that have been observed to perform port scans or network scans, typically to identify vulnerabilities for later exploits.
  • Denial of Service: IP addresses that have launched Denial of Service (DoS) attacks. These attacks are usually requests for legitimate services, but occur at such a fast rate and with a large amount of requests, that targeted systems cannot respond and become bogged down or unable to service legitimate clients.
  • Reputation: IP addresses that issue HTTP requests with a below average reputation, or which only request known malware sites.
  • Phishing Proxy: IP addresses associated with phishing websites.
  • Anonymous Proxy: IP addresses associated with web proxies.

This feature does not decrease system performance.

Note: This release supports only IPv4-formatted IP addresses.

The following actions are available from the Configuration utility:

  • To configure the system to log and block IP addresses that match an IP address from the IP Intelligence database, navigate to Application Security > IP Addresses > IP Address Intelligence.
  • To receive learning suggestions whenever an IP address matches one in the IP Intelligence database, navigate to Application Security > Policy > Blocking > Settings and enable the Learn check box of the new violation Access from malicious IP address.
  • To add the IP reputation to a remote logging profile, navigate to the remote logging profile and select the item ip_reputation.
  • On the charts screen, you can filter illegal requests according to IP reputation categories.
  • To view the last time the server was contacted for updates, the last time an update was received, the total number of IP addresses in the database, and the number of IP Addresses added in the last update, click the IP Address Intelligence last updated link. To view this link, either navigate to Application Security > IP Addresses > IP Address Intelligence screen, or on the Requests screen click on a request row, and you will find the link in the General Details area next to the Source IP Address row.

The following actions are available from the command line:

  • To enable this feature, run the command: tmsh modify sys db iprep.autoupdate value enable.
  • To disable this feature, run the command: tmsh modify sys db iprep.autoupdate value disable.
  • To look up the reputation of a specific IP address, run the command: iprep_lookup <IP address>.

Manual Learning Exception Mode
In this release, you can set the Manual Policy Building to display (and then you can accept) learning suggestions based on real traffic that the system detected. As in previous releases, you can also set the Manual Policy Building to display (and then you can accept) learning suggestions based on the settings of entities that already exist in the security policy.

For example, if the security policy contains a wildcard Global parameter and the system detects a request for an explicit parameter whose name contains an illegal meta character:

  • Using the old mode, the system will suggest you add the explicitly requested parameter to the security policy as a Global parameter because the wildcard parameter was defined as a Global parameter.
  • Using the new mode, the system will suggest you to add the explicitly requested parameter to the security policy on the parameter level that the system detected in the request. So, the system might suggest you add the parameter as a URL parameter. In addition, the system might suggest you also add the URL on which the parameter was sent.

Note: This mode is currently only applicable for the violations: Attack signature detected, Illegal meta character in value, and Illegal meta character in parameter name.

To set the Manual Policy Building mode, go to Application Security > Policy Building > Manual > Advanced Settings.

IP Address Exceptions
On one screen you can now configure IP addresses that the system should consider safe, and allow traffic sent from these IP addresses, regardless of the configuration of the security policy. These addresses are called IP address exceptions. For granularity, from the Configuration utility you can set whether the system considers or ignores specific IP addresses, or a range of IP addresses, when performing the following specific tasks:

  • Running of the Policy Builder
  • Anomaly detection checks (DoS, brute force, and web scraping)
  • Creating learning suggestions
  • Blocking traffic
  • Logging traffic
  • Comparing IP addresses to those found in the IP intelligence database (those with a questionable reputation)

To add an IP address exception to the security policy, navigate to Application Security > IP Addresses > IP Address Exceptions > and click Create.

In addition, in the Deployment wizard running the Vulnerability Assessment scenario, you can add the scanner IP address as an exception IP address.

You can configure the system to:

  • Ignore learning suggestions from traffic sent from the scanner’s IP address. This way, attacks sent by the scanner will not be offered as learning suggestions.
  • Never log requests from the scanner’s IP address. This way, your logs will not be contaminated with attacks the scanner generated.
  • Never block traffic sent from the scanner’s IP address. Use this option if you would like to test the application for vulnerabilities without the protection of Application Security Manager.

Note: Application Security Manager, as a global behavior, does not generate learning suggestions for requests that do not get blocked and result in the web server returning HTTP responses with 400 or 404 status codes. This behavior also applies to this new feature.

Check maximum number of parameters
In this release, you can have the system check whether the number of parameters in requests matches a specific number you set in the security policy. A request that contains more parameters than allowed by the security policy should be considered a possible attack on the server. To set the legal maximum number of parameters allowed in requests, navigate to Application Security > Blocking > HTTP Protocol Compliance, and set the HTTP Validation option Check maximum number of parameters. The default is enabled, and set to a maximum of 500 parameters.

Note: This release does not support IPv6.

Default route domain
Application Security Manager now supports the Local Traffic Manager route domain feature. This means that ASM accepts and displays route domains that are configured in Local Traffic Manager. ASM does not display a route domain if it is the same as the default route domain.

Virtual Server configuration
You can now use the Deployment wizard to configure a new virtual server regardless of the type of license you have. In the previous release, only users with a standalone license had the option to configure a new virtual server in the Deployment wizard.

Policy Builder enhancements
We have made the following enhancements to the Policy Builder:

  • The Policy Builder checks allowed URLs, and checks for meta characters on URLs in the Comprehensive Policy Type instead of the Enhanced Policy Type. This behavior in version 11.2.0 is the same way that the Policy Builder worked in version 10.2.x (but is different than versions 11.0.0 and 11.1.0).
  • We enhanced the entity collapse mechanism.
  • The Policy Builder automatically considers a parameter as being sensitive if it detects type="password" in the response.
  • ASM now enables the HTTP protocol compliance sub-violation Bad HTTP version by default for any security policy that runs the Policy Builder.

Attack Signature Checks on Responses enhancement
In previous releases, in order to configure the security policy to enforce signatures on responses for file types, you had to open the Allowed File Type Properties for each file type and enable the Check Response check box. In this version, you can accomplish the same thing by performing one action (enabling the Apply Response Signatures check box when running the Deployment wizard using the Create a policy manually or use templates scenario, or on the Application Security > Attack Signatures > Attack Signatures Configuration screen).

User Interface changes
We made the following changes to the user interface:

  • We divided the Overview screen into two screens: Summary and Traffic.
    • The Traffic screen displays statistical information regarding attacks, anomaly statistics, and Application Security Manager traffic and network statistics, which were shown on the Overview screen in previous versions.
    • The Summary screen displays the following information that was located on the Overview screen in previous versions:
      • The progress of the Policy Builder, when it is running, for each active security policy
      • The number of security policy elements the Policy Builder added to each active security policy
    • In addition, in this version, the Summary screen displays the following new information:
      • Outstanding system tasks that the system recommends you take care of, and links to specific outstanding tasks for each active security policy.
      • Quick links to common configuration screens and reporting screens, such as Policies Summary, Statistics, Requests, and Event correlation.
  • We made the following changes involving the Attack Signatures screens:
    • We renamed the Policy Attack Signature Sets screen to Attack Signatures Configuration.
    • We removed the Signature Matching Configuration screen, and moved the Excluded Headers area that was on the Signature Matching Configuration screen to the Attack Signatures Configuration screen.
    • We renamed the Policy Attack Signatures screen to Attack Signatures List.
    • When importing the latest attack signatures, you can now instruct the system to automatically place updated signatures in staging. Navigate to the Options > Attack Signatures > Attack Signatures List screen, click Import, and enable the Place updated signatures in staging check box.
    • We changed the Microsoft® related templates so that they are no longer case sensitive because Microsoft products are usually not case sensitive.
  • To enhance usability, we improved the layout of the filters in the Configuration utility.
  • We removed the Classes menu from Application Security. You create an HTTP Class automatically by running the Deployment wizard. To view the list of HTTP Classes, navigate to Local Traffic > Profiles > Protocol > HTTP Class.
  • We renamed the Security Policies Recycle Bin screen to Inactive Security Policies.
  • You can now use multiple strings for the value of the Advanced Configuration System Variable (internal parameter) virus_header_name by using the comma character (,) as a delimiter. The parameter’s default value is X-Infection-Found.

Fixes introduced in version 11.2.0

This release includes the following fixes from version 11.2.0.

ID Number Description
ID 223660 We added the internal parameter data_guard_exception_boundary_len that enables you to extend the buffer size for exception regular expression patterns beyond the matched buffer. This parameter defines the number of bytes, on each side of the match, that are also matched for the exception pattern by the Enforcer beyond the matched buffer itself. By default, this parameter’s value is 0 bytes, meaning the Data Guard exception regexp is applied only on the matched buffer. This parameter is available only from the command line by running the command add_del_internal.
ID 339666, 339679, 340111, 341745, 341747, 341750, 341752, 351041 Attack signatures with the following identification numbers no longer reach the maximum recursion limit: 200001140, 200002147, 200002149, 200002171, 200002172, 200002190, 200002302, 200002430, 200002298, 200002299, 200002358, 200002420, 200002429, 200002458, and 200002459. In the previous release, under certain circumstances, when the system matched traffic against these attack signatures, the system logged false positives when the maximum number of allowed recursions was exceeded.
ID 341862 We added the internal parameter is_ramcache_ignored that enables you to configure whether the system ignores the RAM cache, regarding ASM behavior. By default, the system does not ignore the RAM cache. To ignore RAM cache, set the value of this parameter to 1.
ID 348775 We changed the ASM cookie handling to prevent Enforcer cores.
ID 352230 We have improved the system memory allocation in cases where you provision ASM with LTM and APM.
ID 357731 There is more memory provisioned for ASM.
ID 363901 We improved the stability of the Enforcer to prevent system crashes due to memory corruption.
ID 368014 The system now masks sensitive data in gzip responses when the Data Guard feature is in blocking mode, and the Session Awareness feature has Delay Blocking enabled, and the Data Guard violation is part of the Delay Blocking violations list.
ID 370224 Due to system changes, in a chassis environment if you stop running MySQL, you no longer see the following error message in the LTM log: "Updates to the configuration are not allowed on a secondary (only on the primary)."
ID 370764 With the introduction of the IP Address Exceptions feature in version 11.2.0, the following issue is no longer relevant: In the previous version, if you activate a security policy from the recycle bin, and both the currently active security policy and the security policy that used to be active are assigned to the same HTTP Class, the system saved and displayed Ignored IP addresses and Ignored Entities information of the security policy that used to be active under the currently active security policy.
ID 370923 We removed the By User field on the Inactive Security Policies screen (Application Security > Security Policies > Policies List > Inactive Policies).
ID 371371 We fixed an issue regarding the extraction of base URLs from responses that sometimes led to coring of the Enforcer.
ID 371925 After a user runs the Deployment wizard using any scenario that runs the Policy Builder, the blocking settings of attack signature sets now work correctly.
ID 372009 The session awareness feature now handles non case-sensitive user names and passwords.
ID 372014 In the Web Services Security feature, we changed the system’s default canonicalization method to prevent the incorrect logging of the "Verification error, wrong element digest" violation.
ID 372169 We changed the directory where the BIG-IP system stores imported vulnerability files from / to /shared/tmp so that there is no longer a storage issue.
ID 372176 Requests that only trigger the Attack Signature Detected violation are now tracked by the Event Correlation feature, and correlated on the Event Correlation screen.
ID 372646 The Overview screen is now available even when the signature update server cannot be reached.
ID 373119 We made a number of fixes to possible memory corruption issues and NULL de-referencing.
ID 373124 When associating a new policy with an existing HTTP Class, and the Associate existing statistics option is not selected, ongoing anomaly events continue to accumulate. However, the system clears past events.
ID 373128 The Enforcer daemon no longer cores under certain conditions when web scraping is enabled.
ID 373150 We fixed an issue where no logging on a transaction to the Requests log, combined with the running of the Policy Builder and a lack of memory resources, could cause a memory leak.
ID 373680 We fixed a problem with the shift-jis character set. Previously, sending a request with illegal meta-characters to a security policy with shift-jis encoding may have caused the system to core.
ID 373753 When a parameter is meant to be added by the process of vulnerability resolving, but the parameter already exists in the security policy with a different data type, the vulnerability does not resolve. The parameter remains with the original data type. For example if the resolving of an XSS vulnerability added a parameter with a data type alpha-numeric, then if another vulnerability of Potential File Upload exists on the same parameter, the system does not change its type. In this example, the parameter’s data-type remains alpha-numeric and is not changed to file-upload. In the previous release, the system resolved the vulnerability by changing the parameter’s data type.
ID 374466 The GUI no longer hangs when you navigate to Policy Building > Manual > Traffic Learning > Attack Signatures, and click the arrow next to a parameter-related signature to view the signature details.
ID 374845 The bd_agent log format is now similar to other ASM logs, and no longer creates unnecessary debug messages.
ID 374880 We fixed an issue where the XML parser cored in some cases where nested cdata exists and the schema is not compiled.
ID 375006 We renamed the Enforcer core files so that new core files do not override the old core files.
ID 375012 ASM now supports SOAP and JSON response logging.
ID 375016 We fixed an issue where no logging on a transaction to the Requests log, combined with the running of the Policy Builder and a lack of memory resources, could cause a memory leak.
ID 375118 We fixed a memory leak that could occur during session enforcer prevention, or brute force attack prevention, when there are several prevented IP addresses.
ID 375446 The Event Correlation feature has been enhanced, so that violations on URL/Parameter-based incidents are displayed more accurately.
ID 375564 The system now issues the event Session tracking failed: Session db out of bounds in var/log/asm when the session database exceeds its limit of one of the session tables.
ID 375762 We modified the way requests are processed by the database to improve Manual Learning response time for the Web Scraping violation.
ID 375975 Using the CSRF feature, the Enforcer now correctly parses the CSRT parameter when it appears in the middle of a request. In the past, parameters sent to the server were corrupted (for example, an extra character was added to the last parameter).
ID 377622 By default, ASM now enables the HTTP protocol compliance sub-violation Bad HTTP version for any security policy that runs the Policy Builder, and the Policy Builder does not turn off this sub-violation.
ID 379693 If the /ts/var/license/current file is empty, then after a user renews an expired license, the Enforcer applies configuration changes.
ID 380354 We eliminated a memory leak in the DCC process.
ID 380731 When challenging the client side (for Web Scraping or DoS mitigation), The challenging JavaScript no longer sets a challenge answer cookie from the browser (TSxxxxxx_75 cookie), instead, it puts the challenge answer in a new POST parameter of the POST request it creates. This change adds iFrame support for the client side challenge.
ID 381283 Due to a change made by MacAfee, we changed the default value for the virus_header_name internal parameter from X-Virus-Name to X-Infection-Found.
ID 383495 We lowered the memory consumption generated by the ASM Overview screen. This used to be an issue if the security policy had a large number of signatures in staging mode.
ID 385366 You can now provision Local Traffic Manager (LTM) with Application Security Manager (ASM) and Analytics (AVR) when a vCMP (Virtual Clustered Multiprocessing) guest is deployed on a multi-blade platform with 3G of memory if you set the provisioning levels of all three modules to Minimum.
ID 386379 You can now provision Local Traffic Manager (LTM) with Application Security Manager (ASM) and Analytics (AVR) on the 1600 platform if you set the provisioning levels of all three modules to Minimum.

New features introduced in 11.1.0

Single policy support
In order to make it easier to manage ASM, we changed the system so that you can configure only one active security policy per HTTP Class. The term "web application" in the context of ASM no longer exists. A repository of other security policies that are not active are put in a recycle bin that is available and managed separately. This change resulted in many changes to the Configuration utility. Here are some examples:

  • The Web Application menu was replaced with the Security Policies menu.
  • All web application screens have been removed (for example, the Web Application List screen and the Web Application Groups screen), and security policy screens were added (for example, the Active Security Policies screen and the Policy Groups screen).
  • The Editing Context toolbar, found at the top of each Policy screen was simplified to display only the current edited policy, and the Apply Policy button.
  • You now configure the web application settings, such as language and logging profile, on the Security Policy Properties screen.
  • From the Active Security Policies screen, you can import a security policy either to the security policy recycle bin, or to replace your current active security policy.

Note: If you upgrade from previous versions, all non-active security policies are automatically placed in the Policy recycle bin.

To view active security policies, navigate to Application Security > Security Policies > Policies List > Active Policies. To view security policies in the recycle bin, navigate to Application Security > Security Policies > Policies List > Recycle Bin.

 

Local Traffic Settings wizard
When creating a security policy from the Application Security menu, we now have a wizard that combines the tasks of creating the HTTP class and assigning it to an existing virtual server. You no longer have to navigate to the Local Traffic Manager screens to configure these settings. This quick wizard automatically leads you to the Deployment wizard.

Note: The Local Traffic Settings wizard does not provide a way to set any HTTP class filters or to set the order of multiple HTTP classes on the same virtual server. It also does not allow you to add a security policy to a virtual server that already has a security policy configured.

What you configure on these screens depends whether you are running the ASM standalone, or ASM with LTM.

 

  • If you are running ASM standalone on these additional screens you can configure basic network settings for secured applications. As a result, you can avoid viewing all of the virtual server settings.
  • If you have both LTM and ASM provisioned and enabled, and you have virtual servers with an HTTP Profile associated with them but do not have HTTP Class Profiles associated with them, you can select which protocol your application uses, and the existing virtual server that you want to protect with Application Security.

To run the wizard, navigate to Application Security > Security Policies and click Create.

Geolocation Enforcement
You can configure which counties may and may not access your web application. This is useful if you expect your web application to be accessed from specific countries, or do not want it accessed from specific countries. To allow a geolocation, navigate to Application Security > Policy > Geolocation Enforcement. You can set the allowed countries from the Geolocation Enforcement screen, and you can disallow countries from the Requests screen. From the Requests screen, click a request row to open the request details, and click the Disallow this Geolocation button.

There is a new violation, Access from disallowed Geolocation, which produces learning suggestions. Like other learning screens, you can allow an illegal geolocation from the Learning screen.

Session Tracking
New in this release, session tracking provides enhanced reporting and enforcement capabilities that take into account HTTP user sessions and application user names within the application. This provides the administrator with more information about suspicious application activity (such as who was the user behind an attack) and more flexibility enforcing the security policy (such as blocking a certain user from using the application).

You configure whether the system tracks sessions based on user names, IP addresses, or session identification numbers. If you are tracking sessions based on user names, you decide whether the system obtains user names from security policy login pages, or from the APM module (if it is provisioned and enabled).

After you determine how the system tracks sessions, you then configure how the security policy reacts to suspicious users/sessions/IP addresses. You can configure the security policy to log all activity from suspicious users/sessions/IP addresses, block all requests from suspicious users/sessions/IP addresses, or begin to block illegal requests from suspicious users/sessions/IP addresses after a specific threshold has been reached, for specified violations. If you configure the system to log suspicious activity, the violation is called Access from disallowed User/Session/IP. For this release, there are no learning suggestions available for this violation.

To configure session tracking, navigate to Application Security > Sessions and Logins > Session Tracking.

As a part of this feature, we added the ability to filter requests, on the Requests screen, by source IP address, username, and session ID, and included these details in the general details for each request. While viewing the username, session ID, and IP address request details, you can click a link (Show Session Tracking details) to view the current state of each possible action the system could have taken when this illegal request was detected, and from the request details you can configure what action the system will take if this request is repeated. We also included the username, source IP address, and session ID details on the Charts screen. On the Application Security > Reporting > Session Tracking Status screen you can view and manage the action the system takes when a specific user, session, and IP address crosses an illegal threshold and are tracked by the system.

Login pages enhancement
The login pages functionality was separated into a central configuration screen in which all of the login URL functionality resides. In the Configuration utility, we created a Sessions and Logins menu under Application Security. From the Sessions and Logins menu, you can add to the security policy a login URL, an authenticated URL (a restricted URL that you want users to access only after passing through the login URL), and a logout URL. Configured login URLs are automatically available on the Brute Force Protection Configuration screen. In previous versions, the security policy’s login page was used by ASM in the Logging Enforcement feature to restrict parts of the web application by forcing users to pass through the login page, and in the Brute Force Attack Prevention feature as a way to prevent brute force attacks. In this release, the login page is also used in the Session Tracking feature as a way to track user sessions.

Integration with Additional Vulnerability Assessment Tools
In this release we added support for additional vulnerability assessment tools. Support has been added for IBM AppScan, Cenzic Hailstorm, and Qualys QualysGuard.

Event Correlation
In order to present a high-level view of recent activity, we added an Event Correlation screen, where you can view aggregated events (incidents) rather than individual transactions (that are displayed on the Requests screen). Incidents are suspected attacks on the web application. Events become incidents when at least two illegal requests are sent to the web application within 15 minutes, and the system correlates them according to one of the following criteria: illegal requests for a specific URL, illegal requests for a specific parameter, or illegal requests from a specific source IP address. For example, the system aggregates into a single event if a single user causes multiple violations over time, or if there are multiple illegal transactions on the same application from different IP addresses.

You can click an individual incident to view the requests that caused that incident. To view incidents, navigate to Application Security > Reporting > Event Correlation.

Response Logging
You can now configure the system to log responses. When you enable this feature, responses are displayed on the Requests screen. While analyzing responses is especially useful when logging response-related security events, such as Data Guard or response signatures, it is also be useful in analyzing request violations, to determine whether they represent an actual attack or a false positive (when ASM is configured in Transparent mode).

To configure response logging, navigate to Application Security > Options > Logging Profiles, click Create or Edit to view the logging profile properties, and set the Response Logging setting to one of the following options:

  • For Illegal Requests Only for the system to log responses to illegal requests.
  • For All Requests for the system to log all responses.

Using the internal parameter response_log_rate_limit not available from the Configuration utility you can configure how many responses are logged per second. The default value is 10 responses per second.

To add and change the default value of this parameter, open the command line, and use the add_del_internal script, in the following format:
/usr/share/ts/bin/add_del_internal add <param_name> <param_value>.

To delete an internal parameter from your configuration, from the command line, type the following command:
/usr/share/ts/bin/add_del_internal del <param_name>.

After adding or deleting an internal parameter, you must type and run the command bigstart restart asm in order for the changes to take effect.

Detect File Upload Contents
ASM can now detect and block users from uploading binary executable content in a parameter’s value.

The default for this option is ON for newly created "File Upload" parameters, and this option is OFF for upgraded and imported security policies from previous versions. To change the configuration of this option, navigate to the Parameter Properties screen, set Parameter Value Type to User-input value and Data Type to File Upload, and then enable or disable the Disallow File Upload of Executables setting.

The User-input parameter Data Type that was called Binary (Length checks only) is renamed to File Upload.

We added a violation, Disallowed File Upload Content Detected that is generated when the system detects a file upload of an executable. From this violation’s learning screen you can allow file uploads of executables for each parameter the system detected.

IPv6 Support
ASM now supports IPv6 addresses for application traffic management where you can configure an IP address. Any place where IP addresses are supported, whether in the GUI or in internal/external logging capabilities, both IPv4 and IPv6 addresses are shown in their normal string representations.

Note: ASM does not support IPv6 addresses for the following configurations:

  • ICAP server
  • SMTP server
  • Remote logging server
  • DNS
  • WhiteHat IP addresses
  • Search engines/bot domains

Other Configuration utility enhancements
Besides the changes made to the Configuration utility described with each major feature, we made the following changes to the Configuration utility:

  • In order to view attack signature learning suggestions on one screen, we removed the Attack Signature Staging violation and learning screen. We incorporated its details into the Attack Signature Detected learning screen which now displays whether signatures with learning suggestions are in staging or not.
    Note: You can no longer enforce a signature (remove it from staging) from the Learning screens.
  • In the Deployment wizard, on the Configure Attack Signatures screen where you decide which systems to assign to the security policy:
    • The screen now dynamically shows how many signatures will be assigned to the security policy based on the systems you assign. This better explains the implications of selecting signature sets.
    • The General Database, System Independent, and Various systems are automatically assigned to a new group called Default.
  • The Policy Builder configuration screen was enhanced. The settings order was rearranged in a more logical order, and the Rules setting was replaced with two sliders that make the rule behavior description more intuitive.
  • In the Policy Builder log, in the description area, we added details of a sample URL that the Policy Builder detected in the traffic and is one of the URLs that caused the Policy Builder to add that file type.
  • You can now configure whether updated attack signatures are placed in staging or not (after performing a signature update). Navigate to the Application Security > Options > Attack Signatures > Attack Signatures Update and enable or disable the Place updated signatures in staging check box. The default setting is disabled. In the previous releases, after updating signatures, the system automatically placed the updated signatures in staging.
    Note: Newly added signatures are always placed in staging regardless of this setting.
  • The PCI Compliance screen now displays in the requirement’s description the action you need to take in order for your security policy to meet each requirement. The descriptions include links to other security policy screens where the required configuration is done.
  • On the Application Security > Security Policies > Policies List > Active Policies screen, the virtual server displayed is now a link to the virtual server properties screen.
  • The system default is to hide the tooltip icons and display tooltips on title mouse over. The default can be changed from the Application Security > Options > Preferences screen.
  • From the Application Security > Options > Preferences screen it is now possible to turn off the confirmation pop-up whenever you click Apply Policy.
  • From the Application Security > Policy > Blocking > Settings screen you can search for a specific violation instead of scrolling and looking for it on the screen.
  • You can now filter the Policy Log by the name of the originating device. This is relevant if you are using more than one device.
  • In the Charts filter, you can configure the number of top entries displayed on the Charts screen, up to 100 entities.
  • The Charts screen was improved to have a look-and-feel consistent with the AVR charts.
  • On the Application Security > Reporting > Charts > Charts Scheduler > Chart Schedule Properties screen it is now possible to configure customized report using a dynamic drilldown. For example, if you want to generate a scheduled report that displays violations for the most accessed URL, you cannot save a filter for a certain URL because it can change from day to day. Using the new customized drilldown filter, the system generates a report for the entity with the most occurrences when the schedule is due.
  • User defined filters on the Requests screen are now displayed, and can be used, on the Charts screen.
  • On the Requests screen:
    • In the filter, you can search for requests that matched a specific signature ID.
    • In the filter, Search in was fixed to search in the last 100K results.
    • In the filter, Request, Response and IP address now have the not equals to option.
    • The columns displayed, and the number of entries shown on a single page, are now configurable on the Application Security > Options > Preferences screen.
    • Country flags are displayed.
    • Displays different colors for each severity level.
    • You can export the Requests (proxy) log in CSV format. This format is supported by mysqldump.

Route Domain Support
In the Configuration utility, on the following screens, where an IP address can be entered, we now support the following syntax: IP_address%route_domain_id, where the IP address can (optionally) be followed by a percent sign (%) and the numeric ID of a route domain configured in the system (Network > Route Domains).

  • Filters in Reporting/Requests pages by IP address
  • Web scraping IP address whitelist
  • DoS Attack prevention IP address whitelist
  • Brute Force Protection IP address whitelist
  • Policy Building Ignored IP addresses
  • Policy Builder Trusted IP addresses

We also added the storage format item route_domain available when configuring a remote storage logging profile.

Note: If not specified, the route domain of an IP address entered in the configuration will default to the default route domain for the partition/path that is selected or current in the Configuration utility (and displayed in the drop-down list at the upper right-hand corner of any screen). The default route domain of the selected or current partition/path is not shown in the configuration screens.

Changes Made to Advanced Configuration: System Variables
We added the following system variables:

  • max_slow_transactions: Specifies the maximum number of slow transactions per CPU or plug-in before the system drops the slow transactions (such as when mitigating slow HTTP post DDoS attacks). Slow transactions are defined in slow_transaction_timeout. The default value is 25 transactions
  • sa_login_expiration_timeout: If a user is inactive for this period of time, then the system stops tracking this username. The default value is 1200 seconds
  • slow_transaction_timeout: Specifies the number of seconds after which a transaction is considered slow (such as when mitigating slow HTTP post DDoS attacks). The system tracks the number of slow transactions that have occurred and drops slow transactions after the max_slow_transactions is reached. The default value is 10 seconds
  • WhiteHatIP1, WhiteHatIP2, WhiteHatIP3, WhiteHatIP4: Specifies WhiteHat IP addresses. If Application Security Manager is behind a NAT or if you are using a WhiteHat Satellite box, you can change these to redirected source IP addresses.

We removed the following System Variables:

  • MysqlBindAddressChangeNeeded
  • OverviewEnabled

For information regarding individual system variables, see the Application Security Manager Configuration Manual.

Fixes introduced in version 11.1.0

This release includes the following fixes from version 11.1.0.

ID Number Description
ID 224737 The device is now in the offline state until ASM has successfully initialized. In the previous release after ASM was installed and booted, the device was online while ASM was temporarily offline as it upgraded its configuration. This discrepancy of status between the device and ASM led to some confusion on the status of ASM.
ID 305885 You can now filter the Reports screen for specific attack signatures according to the signature ID. Navigate to the Requests screen, and in the "Search String" part of the filter select "Signature ID". In addition, you can add attack signature name and ID as output items to the storage format for remote logging profiles. Navigate to the Logging Profile Properties screen and in the Storage Format area, move the items "sig_ids" and "sig_names" from the Available Items list to the Selected Items list.
ID 305889 The Configuration utility display after clicking on an Occurrences number from Lengths learning screens is now consistent with other learning screens. Clicking on an Occurrences number link opens a pop-up that displays a list of all relevant URLs and IP addresses.
ID 305940 You can now create a scheduled chart based on custom filter settings. Navigate to the Chart Schedule Properties screen, and in the Chart area of the screen select "Multi-leveled report".
ID 332380 A message is now added to /var/log/asm after you clear all events in the Charts screen.
ID 337302 In DoS configuration, the system was updated so that it now accepts a TPS reached value greater than 10000, and in this case, displays this information in the Configuration utility by means of a confirmation box. In previous releases, the system did not accept a TPS reached value of greater than 10000.
ID 337971 Some areas (such as the Details area) of the Reporting > Charts screen now correctly displays URLs with Hebrew characters. However, some areas (such as the pie chart) of this screen does not, even though the web application language encoding is defined as Hebrew.
ID 340212 When the system detects the "Illegal meta character in parameter value" violation in a request with more than one illegal meta character, the system now learns every illegal meta character. In the previous version, the system only learned the first illegal meta character per request.
ID 340737 Application Security Manager now sends the request’s X-Forwarded-For (XFF) value to a remote logger when a custom XFF header is also configured in the security policy, instead of displaying "N/A".
ID 341709 If the Policy Builder is analyzing parameters in Classification Mode (meaning, the Policy Builder is collecting statistics but has not yet finalized the characteristics of these parameters), and the Policy Builder is disabled or restarted, these parameters are now given a parameter value type of "User-input". In the previous version, they were given a parameter value type of "Ignore value".
ID 346865 If the security policy contains a parameter configured as sensitive, and a request is sent containing this parameter, and an attack signature was detected close or within that parameter the system will not display the violation details for the attack signature detected. Instead, the system displays a note that the matched buffer may include sensitive data.
ID 346983 We improved the cleaning mechanism of the Request log tables.
ID 350169 The Configuration utility now displays, in the top message bar, when the Policy Builder determines that the security policy is stable.
ID 351678 After installing a UCS file that does not include a certain security policy on a machine that used to have that security policy, the Requests screen no longer displays requests for that web application.
ID 351968 If the web application language is Japanese, the Policy Builder now correctly sets the security policy language even when it is running in auto-detect language mode.
ID 353402 We removed "N/A" as an option for "Security Policy" from all filters.
ID 353559 You can now change the Policy Builder configuration while the Policy Builder is in the middle of detecting the security policy language. This is relevant when the Deployment wizard language option is set to "auto detect".
ID 353788 An alert pops up with a warning message now appears when ASM is selected to be un-provisioned but has an HTTP Class, with Application Security enabled, assigned to the virtual server.
ID 353808 Files infected with viruses uploaded in sensitive parameters are now detected by the ICAP server.
ID 353870 The Policy Builder no longer places disabled attack signatures in staging mode.
ID 356235 We improved the note that appears on the Requests screen when the screen’s filter query returns more than 100K results.
ID 356890 We changed the Configuration utility limit for the size of XML and JSON sensitive namespaces, elements, and attributes from 1024 characters to 512 characters in order to match the Enforcer’s size limit of XML and JSON sensitive namespaces, elements, and attributes.
ID 357245 Deleted user-defined allowed methods are now removed from the system’s configured list of methods (the method pool).
ID 357876 We improved the CSRF feature to reduce false positives in the case when the CSRF feature is enabled and web pages return the "Redirect 302" response code.
ID 358127 When the Enforcer restarts, all ongoing anomaly attacks are logged as ended. In the previous version, when the Enforcer was restarted, the system logged that anomaly attacks were still taking place even after they really ended.
ID 358143 A new template with Policy Builder enabled, that can be used from iApp, is now available. This Application-Ready Security Policy template, available from the Deployment wizard, is called "Rapid Deployment security policy with Policy Builder enabled".
ID 358367 Running the Deployment wizard using the XML/web services scenario now turns on the HTTP Protocol Compliance sub violations, the Evasion Technique Detected sub violations, the Web Services Security sub violations, and the "Request Length Exceeds Defined Buffer Size" violation.
ID 359445 The system now displays in the attack signature details area if an attack signature applies to a parameter, to XML, and to JSON.
ID 359461 We improved the accuracy of the graphs on the Overview screen. Note: When ASM first starts you might see the following error message in the logs: "Previous data will be lost". There is no data loss and you can ignore this message.
ID 359794 The system performs WSS signature verification and WSS encryption in the response even in the case when only a client certificate is assigned to an XML profile.
ID 362323 If you change one WSDL to another in an XML profile and delete the URL which applied to the profile according to the first WSDL, then after saving the XML profile all URLs will be updated, but the URL which applied to the first (and deleted) WSDL is no longer created.
ID 363103 The system now trims the space character from sensitive element names and namespaces before saving them.
ID 363274 If you use iControl to define a remote logging storage format, we added validation so that the system now displays an error message informing you if you exceeded the 512 character limit, and you are no longer able to enter more than 512 characters.
ID 363901 We improved the stability of the Enforcer to prevent system crashes due to memory corruption.
ID 363902 "To stop the remote logging profile from creating too many TCP connections, three internal parameters were added that enable administrators to control the remote logger socket keep alive settings. They are: - remote_logging_tcp_keepalive_time: The interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe. After the connection is marked to need keepalive, this counter is not used any further. The system default value is 0 seconds. - remote_logging_tcp_keepalive_intvl: The interval between subsequential keepalive probes, regardless of what the connection has exchanged in the meantime. The system default value is 0 seconds. - remote_logging_tcp_keepalive_probes: The number of unacknowledged probes to send before considering the connection dead and notifying the application layer. The system default value is 0 times. To change the default value of an internal parameter, from the command line type the following commands: /usr/share/ts/bin/add_del_internal add «parameter_name» «parameter_value» bigstart restart asm"
ID 363989 We corrected the paging mechanism so that if you delete learning suggestions while the Recent Incidents information is loading, the Configuration utility now correctly displays all requests.
ID 364184 The error message displayed in the Configuration utility informing you when a security policy is locked, because it is being used by another user, was changed so that it is displayed only on the policy related screens. In previous versions it was also displayed on the Overview screen.
ID 364252 The system no longer sends empty messages after you configure a remote storage logging profile using iControl.
ID 364363 The system sends the chart schedule report at the time set by the user even after there was a temporary failure to send the email (for example, if there was no connection to the SMTP server).
ID 364639 The CSRF feature no longer causes JavaScript errors in IE8 when browsing web pages with X-UA-Compatible meta headers.
ID 364795 For dynamic URL parameters (parameters with a "Parameter Value Type" of "Dynamic Content Value"), the "Allow Empty Value" setting on the Application Security > URLs > Allowed URLs > URL Parameters screen is now set to "N/A". This is because the "Allow Empty Value" option is not applicable when configuring dynamic parameters.
ID 364884 When configuring a signature set, the system no longer displays attack types that are not associated with at least one signature.
ID 365143 In clustered environments, the spurious error message "updates to the configuration are not allowed on a secondary" no longer appears on secondary units when a security policy is applied.
ID 365402 In the previous version, in rare cases, you were not able to save your configuration on the Application Security > Options: SMTP Configuration screen. This issue no longer occurs.
ID 365544 The Enforcer no longer cores if you disable the Data Guard feature while the system is processing a lot of traffic.
ID 365590 Ignored IP addresses now support netmasks.
ID 365630 Fixed an issue where connections would be reset in client configurations when the configuration has only Data Guard with masking (not blocking), and there is CSRF or web scraping enabled.
ID 365730 If you are using the Vulnerability Assessment feature, the system provides a warning before you attempt to delete a URL or parameter that was added by the system when mitigating a vulnerability. In addition, if you delete that URL or parameter, the system changes the ASM Status of any related vulnerability from "Resolved" to "Pending".
ID 365859 In the Charts screen we changed the default filter from "Top alerted policies" to "All". We did this because when the filter is set to "Top alerted policies", the Charts screen appears empty if all security policies are in blocking mode, or if only blocked requests are logged.
ID 365896 To prevent unnecessary reverse DNS lookups, the Search Engine Ask.com default User-Agent string has been changed from "ask" to "teoma".
ID 366032 We fixed memory leaks that sometimes led to core dumps of an internal daemon.
ID 366516 To maximize the amount of data stored in the traffic data (proxy log) export file while not exceeding the system’s 75 MB limit we now store the exported proxy log as a CSV file rather than an SQL dump, and we truncate the data so that the most recent data is kept.
ID 367123 We improved the stability of the IP Enforcer to prevent system crashes due to memory corruption.
ID 367361 The system no longer produces false positives in the CSRF feature when the client side uses Microsoft Internet Explorer in Compatibility mode.
ID 368560 The multipart parser inside the Enforcer was fixed to detect the end of the boundary value when a trailer/suffix appends after the boundary value.
ID 368938 Violations on the Application Security > Policy > Blocking > Settings screen with only the Learn flag enabled are not logged, as they were in previous releases.
[ Top ]

New features introduced in 11.0.0

Device Management
Device management is a mechanism used to maintain a synchronized configuration, between a group of Application Security Manager (ASM) enabled BIG-IP devices in a given network, called a device group. For ASM purposes, a device group comprises one or more BIG-IP devices, using the same ASM configuration. All devices must run the same version of ASM. Using device management, all new security policies, and any configuration changes made to a security policy on one device, can be manually pushed to all other devices within the device group, even if you do not apply the security policy. However, we recommend you apply the security policy in order to ensure consistent enforcement among all devices.

If device management is used within different data centers, the logging profiles will also be synchronized, meaning that the Syslog server destination will be synchronized as well, even though it probably resides on a different address.

The Real Traffic Policy Builder® may be run on only one device for any given policy. Activating Policy Builder on any device will automatically disable Policy Builder for that policy on all other devices within the device group. All security policy configuration changes made by Policy Builder will be relayed and performed by all devices within the group.

If Attack Signature Update is configured for scheduled automatic updates, each device in the device group will update itself independently according to each device’s configured schedule. This update is not relayed to other devices.

You can select whether a preconfigured ASM device group’s devices are to be synchronized, and if so, which device group. Navigate to Application Security > Synchronization > Application Security Device Group.

Virtual machine support
With this release, you can run Application Security Manager as a virtual machine called BIG-IP® Application Security Module Virtual Edition (VE). This is a version of the BIG-IP system that runs as a virtual machine, packaged to run in a VMware® hypervisor environment. BIG-IP Application Security Module VE includes all features of BIG-IP Application Security Module, running on standard BIG-IP TMOS.

For more information about BIG-IP Virtual Edition, go to the AskF5 web site and read the following guides: BIG-IP Virtual Edition VMware Setup Guide, BIG-IP Virtual Edition XenServer Setup Guide, and BIG-IP Virtual Edition Hyper-V Setup Guide.

JSON Support
Application Security Manager can protect AJAX-enabled applications including those that use JSON for data transfer between the client and the server.

Similar to previous versions of ASM where you configured an XML profile for the system to identify and parse XML requests, with this version you can additionally configure a JSON profile for the system to identify and parse JSON requests. The security policy requires that the JSON profile be associated with a URL or a parameter.

To have the Real Traffic Policy Builder® automatically create a security policy that is tailored to secure a web application that uses JSON payloads, run the Deployment wizard using the scenario Create a policy automatically. Then, on the Deployment wizard’s Configure Automatic Policy Building screen, enable the Enable JSON/XML payload detection check box to instruct the Policy Builder to examine traffic and automatically create an appropriate JSON or XML profile (or profiles) associated with URLs or parameters.

Along with this new feature are two new violations:

  • JSON data does not comply with format settings: The system checks that the JSON content complies with the various request limits within the defense configuration in the security policy’s JSON profile. This protects the server from JSON parser attacks. This violation is generated when the system detects a problem in a JSON request, generally checking the message according to boundaries such as the message’s size nested structure depth.
  • Malformed JSON data: The system checks that the request contains JSON content that is well-formed. This enforces parsable JSON requests. This violation is generated when the system detects that a request contains JSON content that is not well-formed.

AJAX Blocking Response Page
With this release you can set up AJAX blocking response behavior for applications that use AJAX, so that if a violation occurs on an AJAX request, the system displays a message or redirects the application user to another location. Unlike the system’s other blocking response pages, the AJAX blocking response page is specially handled on the client-side in order to display it to the end-user. This feature supports the following well-known JavaScript frameworks: ASP.net AJAX, jQuery, Prototype, and MooTools. In order to enable the AJAX blocking response page, you must first allow the system to inject JavaScript code into responses. To set up an AJAX blocking response page, navigate to Application Security > Policy > Response Page, and click the AJAX Response Page tab.

ASM Dashboard
In this release there is a dashboard for the ASM. The ASM dashboard displays anomaly statistics (the number of anomaly type attacks, dropped requests, and total anomaly type violations detected), a summary of ASM traffic (throughput, TPS, and requests per second), and attack types detected by the system. You can filter all statistics according to web application or time (last hour, day, and week). To view the ASM dashboard, navigate to Overview > Dashboard, and change the view to standard > Application Security Manager.

Slow HTTP POST DoS Attack Mitigation
To mitigate slow HTTP POST DoS attacks, the following parameters are available from the Configuration utility. (Navigate to Application Security > Options > Advanced Configuration > System Variables):

  • max_slow_transactions: Specifies the maximum number of slow transactions per core before the system drops slow transactions. Slow transactions are defined in slow_transaction_timeout. The default value is 25 transactions.
  • slow_transaction_timeout: Specifies the number of seconds after which a transaction is considered slow. The system tracks the number of slow transactions that have occurred and drops slow transactions after max_slow_transactions is reached. The default value is 10 seconds.

Note: If using both Application Security Manager (ASM) and Access Policy Manager (APM) and configuring mitigation for slow HTTP post DoS attacks, you need to create two virtual servers rather than one. Setting up BIG-IP ASM and BIG-IP APM for securing traffic and authenticating application users is described in the BIG-IP Module Interoperability: Implementations guide.

Anti-virus enhancements
With this release, the system can inspect file uploads for viruses within HTTP requests and SOAP attachments before releasing the content to the web server. To enable these features, perform the following steps:

  1. Enable at least one of the Alarm or Block check boxes of the Virus Detected violation setting, found on the Blocking Policy screen (navigate to Application Security > Policy > Blocking > Settings).
  2. Configure an anti-virus protection server by configuring ASM to act as an Internet Content Adaptation Protocol (ICAP) client. Navigate to Application Security > Options > Anti-Virus Protection.
  3. Navigate to Application Security > Options > Advanced Configuration > System Variables and ensure that the values of the internal parameters icap_uri and virus_header_name correspond to the ICAP server’s settings.
  4. Note: The system’s default value of the parameters icap_uri and virus_header_name are correct for the McAfee® ICAP server. If you are using a different ICAP server, change these parameters’ values to the appropriate values used by that ICAP server.

    Note: F5 Networks® tested the anti-virus feature on the following ICAP servers: McAfee®, Trend Micro InterScan Web Security, and Kaspersky.

  5. Perform one or both of the following:
    • For the system to perform virus checking on HTTP file uploads, enable the Inspect file uploads within HTTP requests option on the Anti-Virus Protection screen (navigate to Application Security > Policy > Anti-Virus Protection).
    • For the system to perform virus checking on SOAP attachments, after creating an XML profile, you should either enable the Inspect SOAP Attachments option in the XML profile on the XML Profile Properties screen (Application Security > Policy > Content Profiles > XML Profiles), or navigate to the Anti-Virus Protection screen (Application Security > Policy > Anti-Virus Protection) and move a preconfigured XML profile from the Antivirus Protection Disabled list to the Antivirus Protection Enabled list.

Vulnerability Assessments
In the previous version of ASM, WhiteHat Sentinel discovered vulnerabilities on the web site and configured ASM to resolve those vulnerabilities. In this release, ASM was enhanced to provide an interface to represent and mitigate vulnerabilities found by the WhiteHat Sentinel.

To enable this feature, run the Deployment wizard using the scenario Create a policy using third party vulnerability assessment tool output. You are prompted to enter your WhiteHat Web API Key, and then either upload the WhiteHat Sentinel verified vulnerabilities report (after being downloaded from WhiteHat Sentinel) or have ASM download it directly from WhiteHat Sentinel.

After you imported the WhiteHat Sentinel verified vulnerabilities report, navigate to Application Security > Policy > Vulnerability Assessments > Vulnerabilities to perform the following tasks:

  • View vulnerabilities.
  • Resolve vulnerabilities: Instruct the Application Security Manager to add or edit the properties of security policy entities in order to mitigate the risk of a successful exploit of this vulnerability.
  • Resolve and Stage vulnerabilities: Instruct the Application Security Manager to resolve vulnerabilities, and if any of those security policy entities are parameters, place those parameters in staging mode. Entities in staging are not blocked, and this allows you to fine-tune their settings without causing false positives.
  • Retest vulnerabilities: Instruct the WhiteHat Sentinel service to verify that the selected vulnerability is being mitigated by ASM.
  • Ignore vulnerabilities if you do not intend to resolve the selected vulnerability anytime soon.

Important: When integrating with WhiteHat Security, the BIG-IP system running Application Security Manager (ASM) has to recognize whether a request is coming from WhiteHat to be able to return header information so that WhiteHat can mark the vulnerability as Mitigated by WAF. Application Security Manager does not see the original source IP if ASM is behind a NAT or if you are using a WhiteHat Satellite box. To resolve this issue, set the parameter WhiteHatIP1, WhiteHatIP2, or WhiteHatIP3 to the redirected source IP. These parameters are available from the Application Security > Options > Advanced Configuration > System Variables screen.

Evaluate requests for URLs based on their headers
You can determine how the system parses and enforces URL request content according to their headers by configuring a Header-Based Content Profile. In a Header-Based Content Profile, you enter the request header name and value, and then select whether requests that match these header names and values are to be parsed as Apply Value Signatures, Disallow, Don’t Check, HTTP, JSON, or XML. If you want the system to parse for XML or JSON data, you must associate this URL with an XML or a JSON profile.

You can allow more than one request content type to each URL. In this case, the system parses the URL’s request content according to the order shown in the Header-Based Content Profile’s settings from the top down.

The system supplies a default header-based content profile where, unless specified differently, request content is parsed by the system as standard HTTP requests.

To configure a Header-Based Content Profile, navigate to Application Security > URLs, click Create, and view advanced URL properties.

Along with this new feature is a new violation, Illegal request content type. This violation is triggered when the system detects a request for a URL which contains header names and values that are configured to be disallowed by the security policy.

Case Sensitivity
In this release you can configure whether the security policy treats file types, URLs, and parameters as case sensitive or not. To do this, on the Configure Web Application Properties screen of the Deployment wizard, enable or disable the Security Policy is case sensitive check box.

Web Application Summary
In this release you can view data about web applications and security policies on the Web Application Summary screen. This screen displays the number of web applications, the number of active security policies and their Policy Builder state, and how many security policy entities are configured in each active security policy. To view the Web Application Summary screen, navigate to Application Security > Web Applications > Web Application Summary.

Multiple Host Names and Sub-domains
To prevent false positives, you can add a list of host names to the security policy. Host names are domain names that the system considers legitimate internal links to the protected web application. You can also specify whether all sub-domains of the specified host name are used to access the web application (for example, www.secure.site.com might be a legitimate sub-domain of www.site.com).

The system’s Policy Builder and CSRF (Cross-site Request Forgery) protection use the list of host names. The Policy Builder learns security policy entities from internal (not external) links and forms. The CSRF feature uses the list in order to insert the CSRF token to requests for internal links and forms in order to avoid external leakage of data.

To add a host name to the security policy, navigate to Application Security > Headers > Host Names, and click Create.

Policy Builder enhancements
This release includes the following enhancements to the Real Traffic Policy Builder®:

  • Security Policy Elements: The Policy Builder can now automatically learn the following things by enabling each of these check boxes on the Policy Builder Configuration screen.
    • Content profiles: The Policy Builder constructs the security policy to validate XML and JSON request data based on legitimate web application traffic. If the Policy Builder detects legitimate XML or JSON data, it edits the XML or JSON attributes to existing XML and JSON profiles in the security policy according to the data it detects. In addition, enable the Automatically detect advanced protocols check box for the Policy Builder to add XML or JSON profiles to the security policy and configure their attributes according to the data it detects if it detects legitimate XML or JSON data to URLs or parameters configured in the security policy.
    • Host names: The Policy Builder automatically adds domain names used in the web application to the security policy’s list of host names. This allows the Policy Builder and the Cross-site Request Forgery (CSRF) featured to distinguish between internal and external links and forms.
    • CSRF URLs: The Policy Builder verifies URLs against Cross-site Request Forgery (CSRF) based on legitimate web application traffic. If the Policy Builder detects that a URL, that the system previously considered unsafe, was added by the user, it removes the URL from the security policy’s list of unsafe CSRF URLs.
  • Dynamic parameters: In this release, for adding parameters to the security policy as dynamic there are separate check boxes for if they are found in forms, or found in links.
  • Entity collapse: In the previous release, you could set the Policy Builder to collapse parameters and signatures. In this release, the Policy Builder also collapses content profiles and cookies.
  • Track Site changes configuration: In the previous release, if you configured the Policy Builder to learn track site changes, it was for both trusted and untrusted traffic. In this release, you can select whether you want the Policy Builder to track site changes from both trusted and untrusted traffic, or only from trusted traffic.
  • Loosen or tighten Rules based on the number of IP addresses: In the previous release, the rules that determined when the Policy Builder tightened or loosened the security policy were based on user sessions, and time. In this release, you can additionally set the number of different IP addresses that the Policy Builder must detect in order for each rule to be valid. Using IP addresses instead of user sessions significantly increases the resistance of the Policy Builder from being tricked to learn malicious traffic as legitimate.
  • Double smart collapse on parameters: The Policy Builder now performs, if needed, double smart collapse on parameters.

Web scraping enhancements
In this release we added two internal parameters (available from the command line but not from the Configuration utility) that together create a criteria to protect your web application against rapid surfing. These parameters measure the amount of time it takes to change a web page against the amount of web pages requested. Requested includes requesting a different web page and reloading the current web page. Requested does not include changing the content of the current web page and refreshing the current web page.

These are the new parameters:

  • rapid_surf_max_time_duration: The maximum amount of time that it takes to change a web page in order for the system to suspect that a non-human user requested the page. The default value is 1000 milliseconds (1 second).
  • rapid_surf_max_page_changes: The maximum number of web pages that are allowed to be changed (within the amount of time set in the rapid_surf_max_time_duration parameter) before the system considers the client source as not being human. The default value is 5 pages.

The system issues a violation if the number of changed pages is greater than rapid_surf_max_page_changes within the amount of time set in rapid_surf_max_time_duration. For example, when rapid_surf_max_page_changes is set to 5 pages and rapid_surf_max_time_duration is set to 1 second, then if more than 5 web pages were changed within 1 second, the system considers the user as being a bot. These pages do not have to be changed consecutively.

The default settings of these parameters are changed by resetting the following internal parameters, not found in the Configuration Utility.

To change the default settings of these parameters, open the command line, and use the add_del_internal script, in the following format:
/usr/share/ts/bin/add_del_internal add <param_name> <param_value>.

To delete an internal parameter from your configuration, from the command line, enter the following command:
/usr/share/ts/bin/add_del_internal del <param_name>.

After adding and changing the values of internal parameters, you must type and run the command bigstart restart asm in order for the changes to take effect.

Cookie enhancements
With this release we added a new method of enforcing cookies. The new method is the system’s default if you perform a clean install of version 11.0.0. Using this method, the system does not check all cookies for modification; it only checks those cookies that appear in the security policy and configured to be enforced. Enforced cookies are cookies that you want the security policy to track for modification and manipulation. Enforced cookies must be session cookies set by the application on the server side and are unmodified by the client. A request that sends a modified/unsigned cookie that matches an enforced cookie in the security policy produces a violation as long as the enforced cookie is not in staging mode. When enforced cookies that do not cause false positives reach the end of their staging period, the system suggests they be taken out of staging mode. With enforced cookies that cause false positives, the system suggests they be changed to allowed cookies.

You can still enforce cookies as the system did in previous releases. This method is the system’s default only if you imported a security policy, or upgraded your system, from a BIG-IP system prior to version 11.0. Using this method, the system enforces all modified cookies, except for those that appear in the security policy configured as being allowed. Allowed cookies (known as allowed modified cookies in previous releases) are cookies that the security policy allows to be modified or unsigned. Allowed cookies are typically either session cookies set by the application but legitimately change by the client, persistent cookies, or unknown cookies that were set outside the server, either by the client or by proxies (and the like). A request that sends a modified/unsigned cookie that matches an allowed cookie in the security policy does not produce a violation. There is no staging for allowed cookies, but there is tightening (for "*" wildcard cookie).

To change the default method of cookie enforcement from enforcing cookies to allowing cookies (which was the default in previous versions), navigate to Application Security > Headers > Cookies > Cookies Settings and change the mode from By adding enforced cookies to By adding allowed cookies. We recommend the new mode By adding enforced cookies because using the mode By allowing cookies may cause false positives on cookies that the system does not recognize. This will cause some challenges in environments that include many cookies, or even in cases where some proxies or Single Sign-On (SSO) solutions add their own cookies.

To view, add, delete, and enforce cookies, navigate to Application Security > Headers > Cookies > Cookies.

You can also set the order in which the system enforces wildcard cookies that exist in the security policy. To do this, navigate to Application Security > Headers > Cookies > Wildcards Order.

Overview screen enhancements
The following data was added to the Overview screen:

  • The signature staging status (how many are ready to be enforced and how many signatures are in staging) for each active security policy
  • Whether the most recent attack signature file is already installed or if there is an update available. If there is an update available, there is a link to download the updated file
  • The number of "alarmed" requests (illegal requests not blocked or dropped), in addition to blocked, dropped, and all requests

Multiple Remote Logging
With this release you can create one logging profile to log ASM messages to multiple remote servers. To configure multiple remote logging, navigate to Application Security > Options > Logging Profiles, click Create and in the Server Addresses area of the screen add different IP addresses.

Data Guard enhancement
In previous releases, the system’s Data Guard feature checked responses for credit cards, U.S. social security numbers, and custom patterns. With this release you can additionally configure the system to consider specific file content as sensitive data. This protects the server from delivering file content that you do not want returned to users. To enable this feature, navigate to Application Security > Data Guard. In the File Content Detection area of the screen, check the Check File Content check box, and select which of the available content types the system should consider sensitive.

VIPRION support for session enforcer and brute force
We now support IP enforcer and brute force protection on the VIPRION® platform.

Search engines (Bots)
The Application Security Manager does not perform web scraping detection on traffic from search engines (bots) that the system recognizes as being legitimate. In this release you can customize the system’s default list of recognized search engines, and add your own site’s search engine to the system’s list of legitimate search engines. View, add, and remove a search engine from the system’s list by navigating to Application Security > Options > Advanced Configuration > Search Engines.

User defined policy templates
With this release you can create a security policy template that can be used as a basis for future security policies. You can also save an existing security policy as a security policy template.

To create, delete, and export a security policy template, navigate to Application Security > Options > Advanced Configuration > Policy Templates.

To save an existing security policy as a template, navigate to Application Security > Policies List, select the security policy, and click the Save as Template button.

To create a security policy based on a security policy template, start the Deployment Wizard, and select the scenario Create a policy manually or use templates (advanced). When you do this, the system automatically configures the new security policy according to the conditions of the template (for example, adding predefined security policy entities).

Note: Depending on your system resources, you may not be able to define a large security policy as a security policy template.

Learning suggestions for violations
In this version the system provides learning suggestions for four input violations not handled in previous versions. They are the following violations:

  • Illegal dynamic parameter value: This learning screen displays a list of parameters configured in the security policy as dynamic parameters, but the system detected traffic that does not comply with these parameters’ configurations. The learning screen allows you to change these parameters from being dynamic parameters to non-dynamic parameters.
  • Parameter value doesn’t comply with regular expression: This learning screen displays parameters whose value does not match a regular expression, although it should according to the configuration of this parameter in the security policy. The learning screen allows you to stop the system from checking that the parameter’s values match regular expressions.
  • Malformed XML data: This learning screen displays two lists:
    • One list displays URLs configured in the security policy to be parsed as XML, but the system detected that the request contains XML data that is not well-formed. From the learning screen you can change how the system parses requests for these URLs.
    • The other list displays parameters configured in the security policy, each allowed to contain XML in its value, but the system detected a request for this parameter with a value containing XML data that is not well-formed. From the learning screen you can change the value type of these parameters.
  • XML data does not comply with schema or WSDL document: This learning screen displays XML profiles configured in the security policy when their validation files (WSDL documents and/or XML schema files) do not match XML data contained in requests. The learning screen allows you to remove all validation files and SOAP methods from those XML profiles.

DoS minimum detection TPS limit configurable from Configuration utility
You can now set from the Configuration utility the following DoS settings:

  • The minimum TPS threshold before the system treats an IP address as suspicious (latency-based) or considers an IP address to be an attacker IP address (TPS-based)
  • The minimum TPS threshold before the system treats a URL as suspicious (latency-based) or to be under attack (TPS-based)

To configure these settings, we added in the DoS configuration screen the settings Minimum TPS Threshold for detection. In version 10.2.2, these settings were configurable from the command line by changing the values of the internal parameters dos_min_detection_ip_threshold and dos_min_detection_object_threshold.

Bypass ASM
With this version, you can now configure whether or not web application traffic should bypass Application Security Manager, and if so, under which circumstances.

Warning: When you enable bypass, you permit users to continue accessing the web application even during extreme loads and failover. However, web application traffic is directed to the web server without passing through ASM. As a result, the ASM security policies you set up will not protect your web application. This puts your web application at risk of security threats and may cause false positives for a period of time after ASM returns from being bypassed. To avoid these false positives you should disable the following violations from the security policy: CSRF attack detected, CSRF authentication expired, Illegal entry point, Illegal flow to URL, Illegal session ID in URL, Login URL bypassed, Login URL expired, illegal dynamic parameter value, Maximum login attempts are exceeded, Web scraping detected, Expired timestamp, and Modified domain cookie(s).

There are three new internal parameters used to configure bypassing ASM; two are available from the Configuration utility, and one from the command line only.

The following parameters are available in the Configuration utility:

  • bypass_upon_asm_down: Specifies whether traffic bypasses ASM when ASM is stopped. The possible values are 1 (bypass enabled) or 0 (bypass disabled). The default value is 0 (bypass disabled). If you set this parameter value to 1, web traffic bypasses ASM if any of the following occur:
    • If you stop running ASM.
    • If you restart ASM, traffic bypasses ASM from the time ASM is stopped until the Security Enforcer reloads.
    • If the Security Enforcer performs a core dump, traffic bypasses ASM until the Enforcer reloads.

    Note: When enabling bypass_upon_asm_down, we recommend you run the command: tmsh modify sys daemon-ha bd running disabled.

  • bypass_upon_load: Specifies whether traffic bypasses ASM when there are not enough system resources for the Enforcer. The possible values are 1 (bypass enabled), and 0 (bypass disabled). The default value is 0 (bypass disabled). If you set this parameter value to 1, web traffic bypasses ASM if there is not enough memory for the Security Enforcer, or not enough system resources.

To change these parameters’ default values, from the Configuration utility, navigate to Application Security > Options > Advanced Configuration.

The internal parameter that is available from the command line but not from the Configuration utility is bypass_upon_high_cpu. This parameter’s value specifies whether traffic bypasses ASM when your system is consuming a large amount of CPU, indicated by the small amount of idle CPU available. The default is 90 percent, meaning that if the system’s idle CPU is 10 percent, traffic bypasses ASM.

To add and change the default value of this parameter, open the command line, and use the add_del_internal script, in the following format:
/usr/share/ts/bin/add_del_internal add <param_name> <param_value>.

To delete an internal parameter from your configuration, from the command line, type the following command:
/usr/share/ts/bin/add_del_internal del <param_name>.

After adding or deleting an internal parameter, you must type and run the command bigstart restart asm in order for the changes to take effect.

Improvement of SharePoint application-ready security policy template (ID 343436, ID 343438)
The SharePoint application-ready security policy template changes include the following improvements:

  • New signatures added to the template.
  • Removal of tightening from wildcard URLs. Tightening on wildcard URLs caused excessive suggestions and complicated the deployment process.

Recording full violation details to external Syslogs (ID 224046)
You can now record full violation details of all violations generated by blocked requests to external Syslogs (like Splunk). In previous versions, you could only record basic violation details to external Syslogs.

Enhancements to attack signature update readme file (ID 342904)
The attack signature update readme file now contains all history from the base release, and not only the latest update information. Also, the update information is displayed from the latest to the oldest, instead of the reverse.

User interface enhancements
In this release we made the following user interface enhancements.

  • Reporting page optimization: We made the following changes on the Requests screen:
    • The Requests screen now displays staging information. If you click a legal request’s row where the system detected a violation on a staged entity, the system displays the Violations Found for Staged Entities table with information about the violations detected on staged entities.
    • The option of filtering requests by matching a string of the support ID now filters according to matching the support ID’s last 4 digits.
    • The Clear button now shows as the buttons Clear Selected, and Clear by Filter, and Clear All, where the Clear All button deletes all entries.
  • Deployment wizard changes: We made the following changes to the Deployment wizard:
    • Unification of the Production Site and QA Lab scenarios. We combined these scenarios into one scenario, called Create a policy automatically (recommended).
    • We changed the names of the scenarios. The Production Site/QA Lab scenarios are now called Create a policy automatically (recommended). The Web Services (XML+WSDL/User Schema) scenario is now Create a policy for XML and web services manually. The Manual Deployment scenario is now Create a policy manually or use templates (advanced).
    • We added the scenario Create a policy using third party vulnerability assessment tool output. Use this scenario if you have a vulnerability assessment tool like WhiteHat Sentinel and would like to build a security policy automatically based on the vulnerabilities found by that tool.
    • Attack Signatures systems are now grouped into the following categories for ease of search: Operating Systems, Web Servers, Languages Frameworks and Applications, Database Servers, and Other.
  • For the Data Guard configuration, we changed the options Enforce All URLs and Enforce URLs from the list to Ignore URLs in List and Enforce URLs in list, respectively. This allows you to fine-tune the Data Guard operation.
  • Items in drop-down menus are now alphabetically sorted to ease search.
  • You can export the Policy Log and the Policy Builder Log in PDF format by clicking the Export button on the Policy Log screen.
  • The Manual and Automatic Policy Building menus are unified into one menu, called Policy Building.
  • In previous versions you enabled or disabled, and placed in staging or removed from staging security policy attack signatures using the Policy Attack Signatures screen. In this version, to perform these actions you must click an individual signature and view its properties.
  • In previous releases, in order to enable the CSRF Protection, Data Guard, and Web Scraping protection you had to enable their violations on the Blocking screen. In this release, to enable these features, you no longer have to go to the Blocking screen because these violations are automatically enabled by default. Instead, we added on each of these feature’s configuration screens an Enable check box that must be checked in order to enable these features.
  • Some icons have changed. Refer to the online Help or to the icon legends found in the Configuration utility describing the meaning of each icon.
  • We moved the location of a couple of screens in order to promote those screens that are most commonly used:
    • The Flows List screen is now under the Policy > URLs menu and not directly under the Policy menu.
    • The Login Pages screen is now directly under the Policy menu and not under the Policy > Flows menu.
    • The Methods screen is now under the Policy > Headers menu and not directly under the Policy menu.
  • There are new parameters available in the Configuration utility:
    • icap_uri: The URI of an ICAP request, whose default is /reqmod.
    • max_slow_transactions: Specifies the maximum number of slow transactions per CPU or plug-in before the system drops slow transactions. Slow transactions are defined in slow_transaction_timeout. The default value is 25 transactions.
    • slow_transaction_timeout: Specifies the number of seconds after which a transaction is considered slow. The system tracks the number of slow transactions that have occurred and drops slow transactions after max_slow_transactions is reached. The default value is 10 seconds.
    • WhiteHatIP1, WhiteHatIP2, and WhiteHatIP3: Specifies the WhiteHat Sentinel scanner source IP Addresses. When integrating with WhiteHat Security, the BIG-IP system running Application Security Manager has to recognize whether a request is coming from WhiteHat to be able to return header information so WhiteHat can mark the vulnerability as Mitigated by WAF. Application Security Manager does not see the original source IP if ASM is behind a NAT or if you are using a WhiteHat Satellite box. To resolve this issue, set these internal parameters to the redirected source IP address.
  • For clarity and accuracy, the names of the following violations changed:
    • Maximum login attempts are exceeded was changed to Brute Force: Maximum login attempts are exceeded.
    • Information leakage detected was changed to Data Guard: Information leakage detected. (PSM too)
    • Illegal meta character in parameter value was changed to Illegal meta character in value.
  • There are two new check boxes in XML Profile Properties screen:
    • Check element value characters: Specifies when checked (enabled) that the system enforces the security policy settings of meta characters on XML element values. The default for a new XML profile is enabled. If you import a security policy from a version earlier than 11.0.0, the default is disabled.
    • Check attribute value characters: Specifies when checked (enabled) that the system enforces the security policy settings of meta characters on XML attribute values. The default is disabled.

    Note: After you enable either of these check boxes, the system displays a list of meta characters common to both settings.

  • On the XML Profile Properties screen, in the Defense Configuration settings, to configure no limit, select Any. In previous releases, Any was not an option, and you had to set the number to 0.
  • If on any screen with a filter, you set the filter to view specific items and then navigate to a different screen and return to the original screen, the system displays the items on the screen according to the system’s default filter and not according to how you set the filter. In previous releases, the system displayed the original screen according to how you last set the filter.

Fixes introduced in version 11.0.0

This release includes the following fixes from version 11.0.0.

No_ext file type (ID 205290)
The system now validates, and displays an error if you try to create a wildcard file type with the name no_ext.

Responses with compressed content and response-changing features (ID 222401, formerly CR119163)
The following features now support compressed (gzip) content in responses: Data Guard (when the Mask Data option is enabled), Web Scraping Detection, CSRF Protection, and Web Services Security.

Displaying that the security policy was modified when using iControl (ID 222417)
The modified icon is now correctly displayed after a security policy is altered by using iControl® methods.

iControl enhancements
This version includes the following Application Security Manager iControl® enhancements:

  • Import_policy returns name of imported policy (ID 222422): Importing a security policy using the iControl command import_policy now returns the name of imported policy.
  • Support for VIOLATION_REPEATED_PARAMETER_NAME (ID 224891): iControl now supports the violation VIOLATION_REPEATED_PARAMETER_NAME.
  • Support for DoS and Logging (ID 361501): iControl now supports the Denial of Service (DoS) and Logging Profile settings.
  • Support for new violations: iControl now supports all of the new violations added in this release (for example: AJAX violations).

Underscore character in a web application group name (ID 222618, formerly CR122166)
The system now supports you using the underscore character (_) when naming a web application group.

Logging of security policy actions performed using iControl (ID 222649)
Although they were not logged in the previous releases, the following actions done using iControl are now logged to the folder /var/log/asm:

  • Creating a security policy
  • Exporting a security policy
  • Importing a security policy
  • Deleting a security policy
  • Switching the blocking mode

Ctrl+C does not stop recovery program (ID 222670, formerly CR122942)
Pressing the control and C keys simultaneously on the keyboard now correctly stops the recovery program recover_db.pl. In previous releases, it did not.

GUI Preferences saved upon upgrade (ID 222710)
Graphical user interface preferences (configured on the Options > Preferences screen) are now saved in the UCS file. As a result, if you upgrade your system, these settings are now saved on your new system.

Signature staging suggestions shown on signature disabled on parameter (ID 222898)
If you disable a signature on a parameter and a request is sent that matches the signature, the system no longer displays signature staging suggestions on that parameter. In the previous version, the system displayed signature staging suggestions on that parameter.

XML data does not comply with schema or WSDL document violation false positive (ID 223095)
To reduce false positives of the XML data does not comply with schema or WSDL document violation, we improved the system’s detection of namespaces in the xsi:type value.

Attack signature 200001140 (ID 223103)
We tuned attack signature number 200001140 to reduce false positives.

Violation details enhancement (ID 223119)
Violation details are available for HTTP Protocol Compliance sub-violations.

Increase size limit of response page (ID 223185, formerly CR128136)
The maximum size limit of the security policy response page was increased from 10K bytes to 50k bytes.

Masking of sensitive XML parameter that matches an attack signature (ID 223371)
The system now masks detected keywords in the Attack Signature violation details screen when an attack signature is detected on a sensitive XML parameter.

Parsing of requests based on their content (ID 223503)
With the addition in this version of the feature Enforcing requests for URLs based on their headers, the system now parses requests according to their content, including XML and JSON. For more information regarding this feature, see New in this release.

CSRF authentication revalidation (ID 224297)
To improve the Enforcer’s behavior after it detects the CSRF Authentication Expired violation, we improved the authentication revalidation of the CSRF token.

URL file type length after uploading WSDL file (ID 224348, formerly CR135634)
After adding a URL to the security policy as a result of uploading a WSDL file to an XML profile, the system now displays the URL’s correct file type lengths.

Change default of Write all changes to Syslog setting (ID 224383)
The Write all changes to Syslog setting, found on the Preferences screen, is now enabled by default. As a result, the system records by default in the Syslog (in /var/log/asm) all changes made to all security policies, in addition to logging system data. An example of a change made to a security policy is a change in the security policy’s Enforcement Mode.

DoS Prevention Policy enforcement (ID 224445)
When using the Denial of Service (DoS) attack prevention feature in TPS-based detection mode, the system now switches from Source IP-based rate limiting to URL based rate limiting when there are no more suspicious IP addresses but there are suspicious URLs.

Attack signature readme file (ID 224451)
We added a separate attack signature readme file. You can now obtain the attack signature update readme file prior to installing the update.

Security policy validation with disallowed entities (ID 224454)
If allowed file types and URLs are not configured in the security policy, the system now displays relevant security policy validation errors in the Configuration utility even if disallowed file types and disallowed URLs are configured in the security policy. In previous releases, the existence of disallowed file types and URLs would prevent the system from displaying relevant validation errors.

Removing individual attack signatures from staging (ID 224481)
You can now remove individual attack signatures from staging mode. In previous releases, you could only remove all attack signatures from staging mode at once.

Time required for Policy Builder to apply changes to security policy (ID 224482)
The Policy Builder now performs the Apply Policy action within 30 seconds from the time it changes the configuration of the security policy. In previous releases, this time interval could reach up to 5 minutes.

Viewing dropped requests statistics (ID 224545, ID 225277)
You can now view, on the Overview screen in the ASM Traffic Statistics chart, statistics regarding requests dropped by the system due to Layer 7 denial of service or brute force attacks on the web application.

Queries that are not optimized no longer block display of Learning screens (ID 224573)
Queries that are not optimized and display the Illegal Query String Length or the Illegal POST Data Length learning violation no longer block the display of the Learning pages.

Configuration utility allows dash character in XPath (ID 224606)
Using the Web Services Security feature, the Configuration utility now allows you to enter the dash (-) character in the XPath settings. In the previous version the system did not allow you to do this, and displayed an error message.

Sending escaped URI to Syslog server (ID 224618)
The Enforcer now escapes the logged %uri% value before to sending it to remote Syslog server.

WSS violation learning suggestion (ID 224707)
You can now learn the Web Services Security (WSS) violation Web Services Security failure.

Policy Builder support for configured ignored IP addresses (ID 224771)
The Policy Builder now ignores IP addresses configured as Ignored IP Addresses in the security policy.

Note: The Policy Builder does not yet support (ignore) file types and URLs configured in the security policy as Ignored Entities.

Exporting requests as PDF (IDs 224824, 224825, 224826)
We improved the format of exporting requests as a PDF file.

Different display of HTTP and HTTPS elements on Tree View screen (ID 224873)
On the Tree View screen the system now differentiates between HTTP and HTTPS elements with the same name. HTTPS elements now have a "lock" icon next to them.

Lengthy storing of old session files (ID 224913)
To improve system performance, the PHP session files (in the /shared/tmp folder) are now aged out more quickly than before.

Legend in exported charts (ID 224918)
We enhanced exported charts so that each exported chart now includes a description of the X-axis and Y-axis.

Policy Log (ID 224934)
Improvements were made to the Policy Log and Policy Builder Log. Examples: Records are reported clearer than previously, and many log records are now being reported that were not previously recorded.

Message displaying limitation of exporting more than 500 requests to a PDF file (ID 224965)
You can export to a PDF file, by email, up to 500 requests for each PDF file. The system now displays the following error message if you try to export more than 500 requests: "The system can export only the first 500 selected entries". In previous releases, there was no indication why exporting more than 500 requests failed.

Deleting sensitive parameter properties instead of deleting the sensitive parameter (ID 224969)
If you add a sensitive parameter to the security policy from the Parameters screen, and then from the Sensitive Parameters screen delete the parameter with the same name, the system does not delete the parameter from the security policy, like in previous releases. Now, the system disables the Sensitive Parameter setting from that parameter’s properties.

Learning Information Leakage Detected suggestions from request details (ID 225085)
The Learn button is no longer disabled on the Full Request Information tab when viewing the request details of the Information Leakage Detected violation. As a result, you can now learn suggestions for this violation from the Requests screen.

Learning suggests wildcard instead of unnamed parameter (ID 225086)
When there is a wildcard (*) parameter configured in the security policy, and there is a request for an unnamed parameter that matches the wildcard, the Configuration utility Learning screens now display UNNAMED as the requested parameter name. In the previous version, the system displayed in the Learning screens the parameter name as the wildcard parameter instead.

Indication when maximum number of elements reached (ID 225137)
The system now displays in the Policy Builder Log and Policy Log a message when the security policy reaches the maximum number of security policy elements configured in the policy builder configuration screen. In this case, the Event Type is Information.

Policy Builder support for Maximum number of headers (ID 225138)
The Policy Builder now configures the maximum number of headers according to the value set in the HTTP Protocol Compliance screen.

Web Services Security improvement (ID 225164)
We improved the Web Services Security feature so that it now correctly verifies Issuer Names containing email addresses.

Sending traffic to a blade with ASM disabled (ID 225205)
Using the VIPRION® platform, the aggregator no longer sends traffic to a blade when ASM is offline (either because the system is disabled or crashed). In such scenarios, the aggregator now redirects traffic to the primary blade. Note that the Enforcer must run at least once for this to work.

VIPRION and sending requests to a PDF file (ID 225337)
Using the BIG-IP VIPRION system, it is now possible to send requests to a PDF file by email.

Anomaly Detection enhancement on the VIPRION platform (ID 225345)
We improved the qualification statistics for client side integrity test of the Anomaly Detection features on the VIPRION platform.

Creating a large number of classes and virtual servers (ID 225395)
Using the VIPRION platform, the system no longer cores even after you add 100 security classes and 100 virtual servers. The new limit is 200 security classes and virtual servers.

Policy Building coring (ID 225404)
In rare cases, the Policy Builder daemon stopped running when it was running but not enabled, and when the ASM was restarted. This issue was fixed in this version.

Uncompressing GZIP data in responses (ID 225545)
There are no longer issues when the Enforcer fails to uncompress gzip data in responses.

Number of occurrences and values displayed in Learning (ID 225571)
The system now displays the same number of Occurrences and Values in the Learning’s Illegal Parameter Support ID screen. In the previous release, the system sometimes listed more values than the number of occurrences shown.

Cluster IP address reporting (ID 225674)
In a clustered environment when remote logging is configured, the system now reports the cluster IP address as the management IP address, instead of the active slot IP address.

Logging of active security policy name using VIPRION platform (ID 225675)
The system now reports the correct name of the active security policy to the remote logger when using a BIG-IP® VIPRION® platform.

CSRF improvements (IDs 225712, 226657, 225836, 225845)
We made improvements to the CSRF feature.

Deleting and adding same dynamic parameter (ID 225831)
If you delete a dynamic parameter without deleting its extraction properties, then add again a dynamic parameter with the same name, the system no longer incorrectly displays the error message "This dynamic parameter name with such extract from object already exists in database!".

Importing security policy with dynamic parameter (ID 225832)
If you import a security policy, with a dynamic parameter name, from a previous version, and click Update, the system now properly enforces the dynamic parameter.

Indication of Learning suggestions are also in staging (ID 225841)
We added a Staging column to various Learning screens to indicate which entities with learning suggestions are in staging mode.

IP enforcer and Brute Force protection on VIPRION platform (ID 225886, ID 227018)
The system now supports the IP session enforcer and Brute Force attack prevention features on a VIPRION® platform.

Fixed False positive iRule event on attack signature in staging mode (ID 226055)
Using iRules®, if a request produces a violation and matched a security policy attack signature in staging mode, the system no longer raises the ASM_REQUEST_VIOLATION event.

Displaying of the Modified icon after a parameter signature override an attack signature update (ID 226290)
After creating an override to a parameter attack signature in a security policy without applying this change (by clicking Apply Policy), if you then automatically apply attack signatures, the system now displays the Modified icon. In the previous release, the system did not display the Modified icon.

Upgrading with duplicate signature systems (ID 226639)
After upgrading, Application Security Manager now removes duplicates in the same signature system into a single value so that signature systems included in the signature set remain the same before and after the upgrade.

Deleting a large number of parameters at once (ID 226758)
You can now delete all security policy parameters at once even if more than 10000 parameters are returned by the filter on the Parameters List screen.

Incorrect message in log upon upload of large file (ID 227039)
After a large request is sent that exceeds the Enforcer’s buffer limit of 10M (for example, uploading a 13M file), the system no longer sends an incorrect error message to /ts/log/bd.log.

Default configuration of Bad multipart/form-data request parsing sub-violation (ID 306114)
The HTTP Protocol Compliance sub-violation Bad multipart/form-data request parsing is now enabled in two instances:

  • If you create a security policy using the deployment scenario Create a policy manually or use templates.
  • If you run the Policy Builder after you create a security policy.

If you create a security policy using the deployment scenario Create a policy automatically, this sub-violation is disabled by default.

Correct detection of the Host header contains IP address violation (ID 319749)
The system no longer detects the HTTP Protocol Compliance sub-violation Host header contains IP address when the request’s Host header contains a number value, or the request’s Host header is empty, or illegal. The system only detects this violation when the request’s host header value is an IP address.

Errors when performing multiple UCS operations simultaneously (ID 332374)
The system prevents errors from occurring if you unintentionally run two or more UCS operations simultaneously.

Display of XML Profile name in violation details after upgrade from version 9.4.8 (ID 332376)
After upgrading from version 9.4.8, the system correctly displays the name of the XML Profile in the violation details screens of XML violations. In the past, the system used to display N/A until you applied the security policy.

ArcSight date and time field (ID 336660)
When Remote Logging Profile is configured for an ArcSight® server, the system now correctly logs the date and time when the event occurred. In previous releases there was a formatting error in the rt field.

Enforcer cores (ID 337262)
We added sanity checks to avoid possible core dumps when reporting violation data.

Missing methods schema definitions when compiling schema from WSDL document (ID 338021)

When the system compiles a schema file from a WSDL document, there are several schema files created by the system’s schema processor, which have different target namespaces and import each other. If the main WSDL also imports external schema files with the same target namespace, they are no longer skipped by the schema processor. In previous versions they were skipped, and this used to lead to both an incorrectly compiled schema which was too permissive when methods were checked, and the system produced an error message.

Improved performance of the attack signature engine (ID 338671)
To improve the performance of the attack signature engine, it now matches regular expressions only for signatures that are assigned to the security policy. The attack signature engine no longer matches regular expressions for signatures that are not assigned to the security policy.

Improved message when security policy imported from system with different signature file (ID 338853)
When importing a security policy that originates from a system with a different attack signature file, the warning message displayed by the system is improved so it displays both the current signature file version and the signature file version used at the time the security policy was exported.

Logical grouping of attack signature systems (ID 340935)
To ease the search and selection of attack signature systems, they are now grouped according to the following categories: Operating Systems, Web Servers, Languages, Frameworks and Applications, Database Servers, and Other.

Policy Builder and web application language (ID 341428)
The Policy Builder now only uses responses that return a response code of 200 to determine the web application language. In previous releases, the Policy Builder used redirection responses (302) which caused it to incorrectly configure the web application language.

Charts schedule: Hyphens in emails (ID 342101)
When creating a Charts Schedule (by navigating to Reporting > Charts > Charts Scheduler and clicking Create), the hyphen characters in e-mail addresses is no longer considered illegal by the system, and can be entered in the Send To (E-Mails) setting of the Chart Schedule Properties screen.

Parameter false positives and Policy Building (ID 345479)
The Policy Builder now predefines specific parameters as Ignore Value instead of Dynamic to reduce the likelihood of an attack signature flagging the parameter value as a false positive. For more information, see Solution 9255.

Rapid Deployment Policy (ID 345481)
We fine-tuned the Rapid Deployment security policy template to avoid false positives.

Request storage improvement (ID 345505)
To improve the performance of storing requests, we changed the temporary storage location of requests from /var/ts/dms/uploaded_files to /shared/tmp. This is an internal enhancement made to increase system efficiency. In the past, when the /var folder was full, you were unable to export more than 100,000 requests.

WhiteHat Sentinel and wildcard URL parameters (ID 345857)
WhiteHat Sentinel XSS/SQLi/OS command Injection/Xpath injection vulnerability resolution can now add wildcard URL parameters (wildcard parameters on the URL if the vulnerability was found on the parameter name).

Logging fractional DoS attack values (ID 348861)
When logging the number of legitimate and detected average values of dropped IP addresses and URLs, the system now rounds up fractional values. In previous releases, the system rounded down fractional values. This sometimes caused misleading reports. For example, if the actual value was 0.7, the system rounded it down to 0.

DoS attacks against non-existent URLs (ID 349279)
The system now provides protection against DoS attacks that target URLs that are not found (those that return a response code of 404).

Reaping process changed (ID 351291 and ID 353526)
The Enforcer does not accept new transactions when they reach the Enforcer’s memory limit. The Enforcer does also not accept more transactions than the configured number of the new internal parameter max_allowed_trans is reached. The internal parameter number_jobs_to_abort was removed since it is no longer relevant.
When the value of max_allowed_trans is reached, if ASM bypass is disabled, the system logs the message: trans_open: Not enough UMU memory to start a new trans. If ASM bypass is enabled, the system logs the message: trans_open: Not enough UMU memory to start a new trans --> Bypassing ASM .

Apply Policy action and user-defined attack signature with bad escaped content (ID 352243)
A user-defined attack signature with poorly formatted escaped content no longer causes the Apply Policy action to fail.

Chart Scheduler email address improvement (ID 357570)
The Chart Scheduler screen no longer rejects valid email addresses that include .edu.

Brute Force configuration changes after importing security policy (ID 359689)
Exporting and then importing a security policy as XML no longer changes the security policy’s Brute Force configuration. In the previous version, under rare conditions, the system used to add the extra URLs HTTPS /* and HTTPS *.

Charts sent from standby unit (ID 359704)
In a redundant pair environment, scheduled charts are sent (by email) only from the active unit and are no longer sent from the standby unit.

XML Schema without namespace with custom SimpleType (ID 360264)
An imported XML schema with no namespace (neither specified in the import tag nor in the imported schema) using a custom simpleType element no longer fails to compile. As a result, you can now update an XML profile with a WSDL that contains XML schema without a target namespace.

WSDL with no namespace fails to load into XML Profile (ID 360377)
A WSDL with no namespace and a WSDL with an empty string as a target namespace, no longer fail to load into an XML Profile.

Enforcer allocating memory (ID 360593)
There are additional tests at the beginning of each transaction to reduce the chances of the Enforcer allocating more memory resources that it has, and possibly producing a core dump.

Extractions with the apostrophe character (ID 360617)
The Configuration utility now allows you to enter the apostrophe (’) character in the RegExp fields in the Search in Response Body area of the Parameter Extractions screen.

Web Scraping feature improvement (ID 360825)
We improved the web scraping feature to prevent an XSS vulnerability.

Validation of XML improvements (ID 361168)
We improved the Enforcer’s validation of XML to eliminate the incorrect display of Element is not defined in schema errors and the system from incorrectly detecting the XML data does not comply with schema or WSDL document violation.

Schema processor improvement (ID 361700)
The schema processor was improved so that it can now parse schemas that import schemas without a target namespace.

JavaScript error in FF4 when navigating between specific screens (ID 362792)
Using Firefox version 4, a JavaScript error no longer occurs when you navigate from one of the following screens to one of these screens : Blocking Settings, Evasion Techniques, HTTP Protocol Compliance, and Web Services Security.

Normalizing large requests (ID 356032)
The system’s buffer overflow was enlarged so that a request that passes the 10k size limit after it is normalized no longer causes the Enforcer to core.

[ Top ]

Known issues

The following items are known issues in the current release.

No support for triplet module combinations on low-end platforms (ID 403592)
Platforms with less than 6.5 GB memory cannot be upgraded to version 11.3.0 if three or more modules are provisioned. Note that upgrades from version 10.0.x display only an "upgrade failed" message as a software status. All other versions show a clear error message that guides them to SOL13988. Before upgrading, make sure you have only one or two modules provisioned if the BIG-IP system has less than 6.5 GB of memory.

Installation may create a UCS file without database configuration (ID 207422, ID 211521, formerly CR120190, formerly CR127965)
If you try to install this version by running the command image2disk --nomoveconfig, or liveinstall with the database variable LiveInstall.MoveConfig set to disabled, and you have WebAccelerator, Application Security Manager, or Protocol Security Manager provisioned or enabled in the target install slot, the system does not save the database configuration in the UCS file. To correctly install the current version and save your database configuration and installation, see Installing the current version and saving the database configuration and installation in the Workarounds for known issues section of this release note.

Sensitive values displayed in violation details (ID 207777, formerly CR120922)
When the system detects the Request length exceeds defined buffer size violation, if it has found any sensitive parameter values in the request, the system displays them in the violation details section of the Requests screen.

Sensitive parameters: static or numeric (ID 208666, formerly CR110139)
If a sensitive parameter is defined as either static or user-input numeric, the learning suggestions to these values may be problematic. The system does not display the whole parameter value, but:

  • For static parameters, it is impossible to learn their values.
  • For user-input-numeric parameters, one can deduce from the learning suggestion limit the actual given value.

We recommend that to avoid this issue you define sensitive parameters type as User-input Alpha-Numeric, or as Ignore value.

Deployment wizard and logging profile (ID 210045, formerly CR125309)
If you run the Deployment wizard using the Production Site or QA Lab scenario and then configure a remote logging profile, the Policy Builder does not start. You must run the Deployment wizard, let the Policy Builder run, and only then configure a remote logging profile.

Migration and attack signature staging (ID 218563, formerly CR109904)
After migrating a Protocol Security Manager security profile to an Application Security Manager security policy, the system automatically places all attack signatures in staging.

Wildcard URLs that do not begin with the asterisk character (ID 218792, formerly CR110362)
If you add to the security policy a wildcard URL that does not begin with the asterisk (*) character (for example a*b), the system does not automatically add the slash (/) character before it. You must manually add the slash (/) character before this type of URL in order for the system to enforce it.

User-defined and system-supplied attack signatures with the same name (ID 218947, formerly CR110668)
If you try to update the attack signatures in your system, but the updated signatures include a signature with exactly the same name as a user-defined attack signature you had already assigned to the security policy, the update fails due to the name conflict. To work around this issue, you must rename that user-defined attack signature, and then perform the attack signature update procedure again.

Violation severity level changes (ID 219161, formerly CR111118)
If you change the severity level of a violation, the system automatically changes the severity level of that violation for requests already logged.

Null characters in HTTP request headers (ID 219763, formerly CR112823)
If a virtual server running both the Application Security Manager and the WebAccelerator system receives an HTTP request that contains a null character, the WebAccelerator system replaces the null character with a space. The null character is removed from the HTTP request header, so this request does not trigger the HTTP Protocol Compliance violation Null in request. This behavior has no other effect on how the request is processed.

Learning suggestions for a wildcard URL without tightening (ID 224155, formerly CR134360)
If you have an extension wildcard URL in the security policy, for example: *.[Gg][Ii][Ff], with tightening disabled, after running the Policy Builder, the Learning manager suggests URLs that match the wildcard URL, and it should not.

Web services security and FIPS (ID 223169, formerly CR128034)
The Web Services Security feature does not support Federal Information Processing Standards (FIPS). This may impact the feature’s performance.

Display of UTF-16 encoding (ID 225082)
The Configuration utility does not support UTF-16 encoding. Therefore, in the details section of any XML violations, the system incorrectly displays XML traffic details encoded using UTF-16.

Using ASM and Web Accelerator on Enterprise Manager (ID 225665)
If you are using ASM and Web Accelerator together on Enterprise Manager, the script purge_mysql may erroneously identify them as being enabled, when they are not.

Upgrading results in false positives reported by WhiteHat Sentinel (ID 225967)
If you built a security policy in previous version using WhiteHat Sentinel, and if WhiteHat Sentinel added a parameter, then if you upgrade to version 11.0, after the web application is scanned, this parameter will be reported by WhiteHat Sentinel as vulnerable. This is because the Enforcer does not know that the parameter was added by WhiteHat Sentinel.

To work around this issue, click the Resolve button for these vulnerabilities, even though they are already configured in the security policy, and WhiteHat Sentinel will not report these parameters as vulnerable in the future.

Number of Illegal Meta Character in Header occurrences in Learning (ID 226591)
The system might display the incorrect number of occurrences in the Illegal Meta Character in Header learning screen.

Parameter collapsing limitations (ID 226992)
The Policy Builder collapses similar parameters to one wildcard parameter that matches all of the similar parameters only if the parameters meet specific conditions. The following are the limitations of the parameter collapsing feature:

  • The collapse takes place only on parameters that have already been added to the security policy.
  • The Policy Builder examines global parameters and URL parameters separately, and so the Policy Builder does not collapse similar global and URL parameters to one wildcard parameter.
  • The Policy Builder does not collapse parameters that have the * character defined as explicit.
  • The Policy Builder must detect a group of a minimum number of similar parameters. This number is determined by the Collapse to Global setting found on the Policy Builder Configuration page (the default is 10).
  • The parameter names must share a common prefix of at least a minimum number of characters (the default is 5).
  • The parameter’s suffix must be shorter than the allowed number of characters (the default is 512).
  • The parameter names have a maximum amount of variance between them (the default is 5). The variance between the parameters is concentrated in one area of the parameter name, determined by the length of the prefix.

Web Services Security and compressed responses (ID 227184)
When the Web Services Security (WSS) is enabled, sometimes responses are not returned as compressed GZIP data, when they should be. When WSS is disabled, these responses are returned as compressed GZIP data.

User-input string encoding and web application encoding (ID 233054, formerly CR57176)
The user interface assumes that the character encoding of user-input strings is the same as the language encoding (defined when the security policy is configured). If this is not the case, you are not notified, and the settings are not handled correctly by the Application Security Manager. Therefore, after you add any text in the user interface, verify that the input is displayed correctly.

Policy Builder limitations (ID 241431, formerly CR122063-1)
The Policy Builder can build security policies that contain the security policy elements it supports. To view a list of security policy elements that the Policy Builder supports, from the Configuration utility, navigate to Application Security > Automatic Policy Building > Configuration and select Advanced. For a complete list of the security policy elements that the Policy Builder does not support, see the associated Solution in the AskF5 web site.

Traffic Learning and illegal meta characters in very long parameter values (ID 249416, formerly CR48576)
The Traffic Learning user interface displays the first 267 characters of the value of the parameter that triggered an illegal meta character in parameter value violation. Therefore, if you have a parameter value with an illegal meta character as character 268 or greater, the system does not display the illegal meta character. If you allow the illegal meta character, the system adds the meta character to the security policy, as expected.

File extension no_ext (ID 249474, formerly CR51421)
The Application Security Manager does not support the file type file extension named no_ext, because it is a reserved name. If you add a file type named no_ext, the Application Security Manager considers it a file type with no file extension (for example, like the URL /, which has no file extension).

Blocking requests due only to response violations (ID 249484, formerly CR52050)
If the system blocks a response due only to response violations, the Blocked Request icon (hand) does not appear near the blocked response in the Requests or the Security Alerts screens.

Two security events are logged for a single request plus response (ID 249497, formerly CR52751)
Whenever violations occur on both the request and the response, the system logs two security events: one for the request and one for the response. In this case, the system should log only one security event.

Using Microsoft Internet Explorer and viewing UTF-8-encoded characters (ID 249524, formerly CR53801)
If a web application is configured with an encoding other than UTF-8, you might get unreadable characters in the Learning and Requests screens in the Configuration utility. The reason for the unreadable characters is that the web browser always sends query strings encoded in UTF-8, but the Configuration utility uses the character encoding that you specify for the web application to display the data on the security policy and Learning screens. To work around this issue, manually change the web page’s encoding in the web browser to UTF-8.

No header violations if no file types exist (ID 249562, formerly CR55324)
If there are no file types defined in the security policy, the system does not generate any header length violations.

Apostrophe character in dynamic parameters (ID 250025, formerly CR65835)
The system correctly extracts dynamic parameter values if they are extracted globally. The system does not correctly extract dynamic parameter values for a specific URL if the value includes the apostrophe character and the extraction method is Search Within Form. Similarly, the system does not correctly extract dynamic parameter names (found on flows) if the value contains the apostrophe character and the extraction method is Search Within Form.

Some encodings are not supported (ID 250026, formerly CR65838)
The system cannot extract some dynamic parameter names and dynamic parameters since the system does not support all encodings.

Parameters with parameter value violations (ID 250071, formerly CR66394)
If a parameter generates the violation Null in multi-part parameter value, it does not generate the violation Illegal meta character in parameter value, even if it should.

Traffic Learning and static parameter values of 1024 bytes or more (ID 250087, formerly CR66609)
When accepting an illegal static parameter that is 1024 bytes or longer from the Traffic Learning screen, the system truncates the value. If the same parameter is resent with the original value, the system generates another Illegal Static Parameter Value violation.

Extra security policy displayed in log after upgrade and ConfigSync (ID 250199, formerly CR68446)
After upgrading from a version of the Application Security Manager earlier than 9.4, if you then perform a ConfigSync from peer on the active machine, the Application Security log may display an extra security policy named «security policy name»_restore_for_set_active_«a number». You can ignore this log entry.

Parameter with a regular expression that includes a comma (ID 250487, formerly CR71929)
If you define a parameter with a regular expression that includes a comma, and a request is sent with that parameter, the system might send the violation Parameter value does not comply with regular expression, even though the request is legal.

Multiple port types support in one WSDL document (ID 250657, formerly CR73383)
When there are multiple port types in a single WSDL document, the system extracts and enforces only the methods of the first port type.

Request with an empty Host header (ID 280212, formerly CR66890-1)
If a request is sent with an empty Host header, the system does not enforce the HTTP protocol compliance failed violation, even when it should.

Learning and meta characters applied on sensitive parameter values (ID 280215, formerly CR72912)
If the system learns a number of requests for one sensitive parameter, and each request contains a different illegal meta character, the system displays only the first meta character of the first request for that sensitive parameter when you view the illegal meta character by parameter value. If you subsequently allow the meta character, the system accepts all the illegal meta characters that apply to the sensitive parameter.
To work around this issue, go to the Illegal meta character in parameter value screen, select View by Meta Character, and accept all meta characters that you want the security policy to permit.

Attack signature displayed as in staging (ID 280219, formerly CR75574)
The system displays attack signatures on the View Full Request Information screen as being in staging even if they are not, as long as the attack signature is configured with its Learn flag enabled and its Alarm and Block flags disabled.

Attack signature keyword interpretation (ID 280261, formerly CR84498)
The Application Security Manager attack signature mechanism interprets the rule options depth and within as how many bytes to search for after the original starting point, and not how many additional bytes to search for after their respective offset or distance keywords.

Parameter being both sensitive and navigation (ID 280318, formerly CR85565)
If you define a parameter as both a sensitive parameter and as a navigation parameter, the system reveals the sensitive parameter value on the view Full Request Information screen.

Method not in the system’s method pool (ID 280584, formerly CR91563)
If a request is sent using a method that is not in the security policy’s method pool (found on the New Allowed Method screen), the system enforces this illegal request as an Unparsable request content violation (a sub-violation of the HTTP Protocol Compliance failed violation) instead of as an Illegal method violation. In addition, the system does not produce a learning suggestion to accept the method.

Using Internet Explorer and non-ASCII characters in the URL (ID 309326, formerly CR51175)
Internet Explorer does not escape non-ASCII characters entered in a URL in the Address bar. Therefore, using Internet Explorer, if you enter a URL with non-ASCII characters in the address bar, the Security Enforcer issues a non-RFC request violation.

History statistics after a failover (ID 309839, formerly CR134826)
In a clustered environment, upon failover, the system deletes the history statistics it collected on entities used by the anomaly detection features (Denial of Service attack protection, Brute Force attack protection, and Web Scraping mitigation). As a result, after each failover the system begins to collect, and use, new history statistics for those entities.

Policy Builder limitations with detecting dynamic parameters (ID 309855, ID 309856)
The Policy Builder cannot add a dynamic parameter to the security policy if an ampersand (&) or quotation marks (") appear in the parameter’s value.

mysql database volume and deprovisioning (ID 317562, formerly CR120943)
If you deprovision the WebAccelerator system, Application Security Manager, or Protocol Security Manager, the system retains the mysql database volume. Because the database might contain important configuration data for the deprovisioned modules, you must determine whether or not to retain the mysql database volume. For information on locating and removing an unneeded mysql database volume, see the associated Solution in the AskF5 web site.

Enter character in the logging profile’s predefined items (ID 319428, formerly CR98238)
When configuring a logging profile using the TCP protocol, do not type the Enter character in the Storage Format setting. If you do, the system does not log any field after the Enter character in the log.

Editing web applications and multiple browser sessions ((ID 321872, formerly CR52545)
The Configuration utility for the Application Security Manager uses two separate browser sessions that share the same session cookie. Therefore, you can only edit one security policy at a time. Do not try to edit two different security policies simultaneously by using multiple browser windows sessions.

Dynamic Session ID in URL feature requires a referrer URL (ID 321875, formerly CR52764)
The dynamic session information is only extracted from the response and saved by the Security Enforcer if the requested URL is marked as a referrer URL in the security policy. Therefore, you must make sure that the URLs from which the dynamic session information is to be extracted are referrer URLs.

Moving configuration (ID 332361)
ASM does not support moveconfig (liveinstall.moveconfig enabled) when saveconfig is not used (liveinstall.saveconfig disabled).
To work around this issue, perform the following steps:

  1. Reboot into the partition with the desired configuration.
  2. Save a UCS file aside.
  3. Reboot into the other partition.
  4. Install desired version.
  5. Reboot into newly installed partition.
  6. Apply saved UCS file.

Policy history after a failover (ID 332363, formerly CR129102)
In a clustered environment, after a failover occurs, the primary blade does not display the security policy history of the last active security policy.

Changing web application language by tmsh (ID 339697)
If you change the web application language using tmsh, you are not warned that this action reconfigures the web application.

Violation logging of illegal meta character found in legal entities (ID 341789)
The system logs the Illegal meta character violation if it detects a request containing a meta character configured as disallowed in the security policy even though the security policy also contains an allowed explicit entity with that meta character.

Entities accepted from Manual Learning are added differently than when added by Policy Builder that automatically detects content profiles (ID 342226)
Manually accepting URLs and parameters from the Learning screens performs the following actions:

  • Adds URLs as Header-Based Content Profiles parsed as HTTP.
  • Adds parameters as User-Input type.

The Policy Builder configured to auto-detect content profiles performs the following actions:

  • Adds URLs as Header-Based Content Profiles parsed as Don’t Check.
  • Adds parameters as Ignore Value type.

Inexact Error Message in Configuration utility (ID 342594)
When importing a security policy that includes an illegal XML element such as <perform_tightening>0</perform_tightening> (instead of <perform_tightening>false</perform_tightening>), the configuration displays the error message Error: Field 'parameterperform_tightening' may not contain the value '0'. While the Configuration utility message correctly identifies the incorrect value (0), this message might be confusing, since the parameter’s name is perform_tightening, and not parameterperform_tightening. If you search the XML document for parameterperform_tightening, you will not find it because it does not exist.

Configuration utility username mistake when copying security policy using Enterprise Manager (ID 344749)
Using Enterprise Manager, if you copy a security policy from one device to another, the Configuration utility incorrectly displays that the security policy was applied by the user set_active, instead of the correct user name, such as admin.

SOAP requests with attachments (ID 344978)
The system’s Web Scraping Detection engine cannot decrypt and verify SOAP requests with attachments.

File type extensions in non-ASCII encoding (ID 345431)
The system does not correctly insert file types to the security policy if the file types have extensions in non-ASCII encoding.

Virus detection if ASM out of memory (ID 346498)
If the system runs out of memory resources, the system does not perform virus inspection even when it should. To inform you of this issue, the system logs in the BD log (/var/log/ts/bd.log) the error message ASM out of memory error.

Evasion Technique Detected violation details (ID 346523, 347005)
Under certain circumstances, the system displays incomplete violation details in the Configuration utility when an evasion technique detected violation is detected.

Remote Reporting Server: The sig_names field displays only 3 values (ID 346852)
The sig_names storage format field in the Remote and Reporting Server remote storage type displays the names of signatures detected in requests. However, there is a limitation for this field: it only displays three values. Therefore, if a request matched more than three signatures, the log displays the first three matched signatures, and then displays "..." instead of the remaining matched signatures.

Deleting an application template with Application Security enabled (ID 347077)
When you create an application template that has Application Security enabled, the system also creates an ASM application object. However, if you delete this application template, the system does not delete the ASM application object.

To correctly delete an application template that has Application Security enabled, perform the following actions in the following order:

  1. Delete the virtual server.
  2. Delete the HTTP Class.
  3. Delete the ASM application object.
  4. Delete the application template that has Application Security enabled.

URL POST data in Classification Mode (ID 347182)
The Policy Builder processes URL POST data when the URL is in Classification Mode (meaning, the Policy Builder is collecting statistics but has not yet finalized the characteristics of the URL), and it should not.

xsd:restriction restrictions in the XML schema (ID 348433)
The system applies attack signatures and meta characters on string types that have xsd:restriction restrictions on them in the XML schema. Therefore, the Enforcer may detect the violations Illegal meta character in value and Attack Signature Detected on XML elements that an xsd restriction allows.

Manually editing URL in Classification Mode (ID 348545)
If the Real Traffic Policy Builder® is analyzing URLs in Classification Mode (meaning, the Policy Builder is collecting statistics but has not yet finalized the characteristics of these URLs), and you make any manual changes to the URL, including changing the URL’s description, the Policy Builder stops examining that URL and sets it as Parsed As: Don’t Check. This means that for every request for this URL, the system will not perform any checks on the request body (beyond minimal checks that the system runs on the entire request).

Display of sensitive data in Attack Signature Detected violation details screen (ID 350393)
If a response is returned with attack signature data configured to be masked by the Data Guard feature, the data is masked. However the system does not mask this content in the violation details of the Attack signature detected violation, displayed in the Configuration utility.

Web applications with overriding scripts (ID 351276)
Web applications with scripts that override the system’s JavaScript cause the system to incorrectly log a CSRF attack detected violation.

Logging of 100-continue requests (ID 352578)
The system does not display information about TPS and throughput for blocked requests that return a response code of 100 (continue) in the Overview screen and ASM Dashboard screen.

Detected TPS logging (ID 352884)
When using the Denial of Service (DoS) feature with URL-Based Rate Limiting, the system displays on the DoS Attacks Anomaly Statistics screen Detected TPS = 0 for the dropped IP addresses.

False positive of "Illegal parameter" violation (ID 355764)
The system may produce false positives of the "Illegal parameter" violation on a URL associated with an XML profile when all XML violations are disabled in the security policy and the parameters list is empty.

Policy Sharing error message display (ID 355874)
Using policy sharing, the system displays the message "The security policy applied successfully with several validation errors. Click here to see the errors" at the top of the Configuration utility only on the BIG-IP system where the user activates the policy, but not on the screen of other BIG-IP system’s (sync group members).

Enforcing POST 100-continue requests using ASM iRules (ID 356031)
If you have written iRules® that process ASM iRule events, and enable the Trigger ASM iRule Events check box on the Application Security > Policy > Policy > Properties screen, the system resets POST requests that return a response code of 100 (continue) and displays the following error messages in the Local Traffic Manager log (System > Logs > Local Traffic): "iRule execution error", and "TCL error".

Partition/Path display (ID 356520)
There is a slight inconsistency in the way the Partial/Path is displayed by the Local Traffic Manager (LTM) and Application Security Manager (ASM). The Partial/Path is the partition and path to which the virtual server/web application belongs. The LTM® displays the path without the leading slash character (/), and the ASM displays the path with the leading slash character.

Large security policy as a template (ID 356884)
Depending on your system resources, you may not be able to define a large security policy as a security policy template.

Specifying WhiteHat source IPs (ID 357945)
When integrating ASM with WhiteHat Security, the BIG-IP system running Application Security Manager (ASM) has to recognize whether a request is coming from WhiteHat. This is because if the security policy is adjusted so that it protects against vulnerabilities found by WhiteHat and you retest specific vulnerabilities, ASM sends info to WhiteHat so that White Hat can mark the vulnerability as Mitigated by WAF (meaning that ASM addresses the problem).

Application Security Manager does not see the original source IP if ASM is located in the network configuration behind a NAT (for example, a firewall) or if you are using a WhiteHat Satellite box (an appliance used internal to the network). In these cases, ASM does not send information that the vulnerabilities are mitigated.

You can resolve this by setting the internal parameters WhiteHatIP<n> to the redirected source IP, either from the Configuration utility, or from the command line.

From the Configuration utility:

  1. Determine the IP address that the NAT firewall or WhiteHat Satellite device assigns to requests going to the BIG-IP ASM device.
  2. Navigate to Application Security > Options > Advanced Configuration > System Variables.
  3. Edit the IP Addresses of parameters WhiteHatIP1, WhiteHatIP2, WhiteHatIP3, or WhiteHatIP4.
  4. Click the Save button.

From the command line:

  1. Determine the IP address that the NAT firewall or WhiteHat Satellite device assigns to requests going to the BIG-IP ASM device.
  2. Log in to the command line on the BIG-IP system.
  3. Run the following command:
    /usr/share/ts/bin/add_del_internal add WhiteHatIP<n> <IP_address>
    Where <n> is a number from 1 to 4 (so that the internal parameter name can be either WhiteHatIP1, WhiteHatIP2, WhiteHatIP3, or WhiteHatIP4), and <IP_address> is the IP address assigned to requests after going through the NAT or the IP address of the internal WhiteHat Satellite device.
  4. Reboot Application Security Manager to implement the internal parameter change:
    bigstart restart asm

Errors generated when resetting ICAP server configuration (ID 358256)
If you reset the ICAP server configuration while the system is processing traffic (by clicking Reset and Save on the Application Security > Options > Anti-Virus Protection screen), the system deletes the ICAP server configuration, but the system does not end the ICAP connections. As a result, the system logs errors in the BD log (/var/log/ts/bd.log).

Support limitations for IPv6 (ID 359405)
While ASM supports IPv6 addresses for application traffic management, ASM does not support IPv6 addresses for the following configurations: ICAP server, SMTP server, Remote logging server, DNS server, WhiteHat server, and Search engines/bot domains.

Synchronized SMTP settings between peer units (ID 361721)
Using the Policy Sharing feature, the system synchronizes advanced SMTP configuration settings between peer units. As a result, the system produces identical Charts (PDF reports) from all peer units as if traffic on each unit is identical. However, this is an issue because actual traffic is different on each peer unit.

Slow POST DoS protection when APM and ASM on one virtual server (ID 364256)
When using Application Security Manager (ASM) and Access Policy Manager (APM) together to secure application traffic and check user credentials, you need to create two virtual servers (one for ASM and another for APM) in all cases rather than one. In previous releases, you only needed two virtual servers if configuring DoS and brute force attack prevention.

You can work around this issue by using a specific iRule that mitigates against slow POST DoS attacks and enables you to use ASM and APM on one virtual server. See Mitigating Slow HTTP Post DDoS Attacks With iRules on the F5 Networks DevCentral website.

Setting up BIG-IP ASM and BIG-IP APM for securing traffic and authenticating application users is described in the BIG-IP Module Interoperability: Implementations guide.

Supported frameworks (ID 364179)
Application Security Manager supports the following frameworks: jQuery version 1.4 and later, Mootools version 1.2.4 and later, and Prototype version 1.5.0 and later.

Inconsistent logged number of requests (ID 367154)
The number of requests reported on the Requests screen (proxy log) and the number of requests reported on the Event Correlation screen may be different, especially at high rates of logging. One reason for this is that the Guarantee Local Logging option of the logging profile only affects logging on the Requests screen and does not guarantee logging to the Incidents correlation and aggregation engine.

Virtual machine CPU minimum requirement (ID 368121)
On a virtual machine, you need at least 2 CPUs to configure ASM.

IPv6 and the CSRF feature (ID 368637)
The CSRF feature does not support absolute links where the host name is written in IPv6 format.

System’s CPU statistics on the 6900 platform (ID 370106)
On the 6900 platform, if you enable ASM on a virtual server while traffic is passing through it, the system’s CPU statistics might be shown as greater than 100 percent.

Blocking response page and Opera browser (ID 370757)
We do not support the blocking response page feature when a user browses a protected web application with the Opera browser. To work around this issue, use another browser like Internet Explorer®, Mozilla Firefox® or Google Chrome.

Correlation event error messages after unlicensing ASM (ID 371370)
After unlicensing ASM, you might see critical messages of correlation events in the ASM log. You can safely ignore these messages.

Attack Signature Detected violation details for requests with threshold limitations (ID 374882)
The Configuration utility displays incorrect Attack Signature Detected violation details for requests with configured threshold limitations.

Parsing CDATA with a missing opening square bracket character (ID 374936)
False positives are possible when the system parses an XML document containing CDATA that contains the closing bracket character ( ] ) without an opening bracket character ( [ ).

Parsing an HERF link in the response (ID 376088)
When the Enforcer parses an href link in the response, it parses the semi-colon ( ; ) character as a delimiter and all other characters after it are treated as parameter, although they might be part of the URL.

Request with internal TS cookie may cause false positive (ID 376192)
A request that contains the internal cookie TSxxxxxx_77 that was generated by another HTTP Class may cause the Enforcer to incorrectly trigger the Modified ASM cookie violation.

Attack signature threshold (ID 377197)
Even after a user configures an attack signature threshold (done when setting a user-defined signature), the signature may generate a Learn or Alarm event more than once per the number of seconds specified by the threshold, and the signature may not block all requests (if the policy is configured to block requests for the signature).

Unescaped symbols that trigger the Apache Whitespace violation (ID 377305)
Unescaped symbols in requests that trigger the Apache whitespace violation (an Evasion Techniques sub-violation) sent to a remote logging server may create an unexpected line break in the display of the remote log.

Blocking response redirect URL should not contain disallowed element (ID 377316)
It is possible to create a loop after the first blocking request if you configure a blocking response page with a redirect URL that includes an element disallowed in the security policy. To work around this issue, ensure that the request caused by the redirect is not blocked by the security policy.

Remote log display of Check maximum number of headers sub-violation details (ID 377323)
There is a difference in the information displayed between the Configuration utility and the remote log (violation details field) when the Check maximum number of headers sub-violation of the HTTP protocol compliance failed violation is triggered (because the number of headers exceeded the maximum allowed). The Configuration utility displays number of headers exceeded maximum limit of <n> while the remote log displays N/A. Use the Configuration utility to view the correct data.

Defining login URL as a wildcard (ID 377597)
The system issues the Login URL bypassed violation even after a valid login if the Login URL is configured to be a wildcard and the object that has the login is defined explicitly in the policy. To work around this issue, define the explicit URL as a login page if it is defined explicitly in the policy.

TPS value displayed during an IP Enforcer attack (ID 378382)
When an IP Enforcer attack is in progress, on the Traffic Overview screen, the TPS value displayed in the Top Requested URLs and Top Requesting IP Addresses tables is different than the TPS value displayed on the ASM Network Statistics and ASM Traffic Statistics graphs (which is the correct one).

Many transactions with Guaranteed Logging enabled (ID 379705)
Logging errors may occur when Guaranteed Logging for responses is enabled and there are more than 1000 transactions per second.

XML profile violation details on a secondary blade (ID 381233)
On systems with multiple active policies, some violation details for XML Profiles may be unavailable for requests handled by a secondary blade.

Encrypted domain cookies (ID 381284)
ASM marks domain cookies configured to be encrypted in the HTTP profile as modified domain cookies. To work around this issue, configure encrypted domain cookies as allowed cookies.

Synchronizing virtual server to a device group (ID 381406)
If you are using device management to synchronize ASM policies and configurations, and you create a new security policy using the Deployment wizard and create a new virtual server, on the peer device the new security policy is synchronized but not automatically assigned to the new virtual server. To work around this issue, you must manually synchronize the virtual server configuration to the device group. For instructions, see Manually synchronizing the virtual server configuration to the device group in the Workarounds for known issues section of this release note.

Deleting event correlation data (ID 382136)
The clear buttons on the Event Correlation screen do not clear event correlation data. To delete event correlation data, you can restart the correlation daemon from the command line by running the command: /usr/share/ts/bin/kill_correlation.pl

Clustered environment: Some tasks displayed on devices not running Policy Builder (ID 382122)
In a clustered environment, if the Policy Builder is running on one device, the following "Tasks to do" are displayed on the other devices not running the Policy Builder: Apply the Security Policy, and Signatures/File types/URLs/Cookies/Parameters are ready to be enforced. These tasks should not be displayed at all as long as the Policy Builder is running on any device in a clustered environment.

Deprovisioning ASM on Virtual Edition (ID 383015)
If you are running the Virtual Edition of Application Security Manager inside a XEN virtual machine, after de-provisioning Application Security Manager (setting the Resource Provisioning to None), the system goes offline until you run the command bigstart restart or reboot. The Configuration utility does not instruct you to run these commands.

Misleading Guarantee Local Response Logging heading names (ID 383359)
On the Logging Profile Properties screen enabling the setting Guarantee Local Response Logging means that the system guarantees the collection of all response data. This data is sent either to the local logger, or a remote logger, depending on the configuration of the logging profile. When this setting is enabled, the system guarantees that it sends all responses to the local logger, or to the local and remote logger together, but never only to the remote logger.

Session Awareness: Display of user names longer than 50 characters (ID 384783)
When using the Session Awareness feature, if a user name is longer than 50 characters, the Configuration utility displays only the first 50 characters. However, the system correctly enforces the entire user name.

Learning suggestions cleaning (ID 385365)
Learning suggestions may be cleaned more quickly than necessary, due to unnecessary data rotation.

Security policies inactive on corresponding HTTP Class after correcting failed upgrade (ID 388116)
If the system’s configuration file cannot be loaded correctly and fails the upgrade process, the existing active security policies are considered inactive. In addition, when the configuration is corrected and HTTP Classes are subsequently created, the system associates new default security policies to the HTTP Classes instead of the previously associated active security policies (which are now inactive).

Exporting policy with nearly identical names in XML format (ID 390645)
A security policy that contains entities with nearly identical names, but differ only in unprintable characters, cannot be exported in XML format and then imported. This issue does not occur if you export the security policy in binary format.

"Europe" appears as a country in Geolocation list (ID 392050)
Europe appears in the Geolocation list, but if you disallow it then it is not enforced, as there are no IP addresses to match it. As a workaround, to disallow countries found in Europe, select those specific countries.

Incorrect data logging (ID 392895)
Data logged in ASM_REQUEST_VIOLATION and ASM_REQUEST_BLOCKING events is incorrect when there are violations in both parts of a 100-continue request.

Learning suggestions without request data (ID 393210)
Learning suggestions may be presented without full request data if one type of violation already exists in the Learning database, and is then triggered repeatedly.

Restarting a bigstart daemon (ID 397064)
If you stop and restart a bigstart daemon (for example, if you run the command bigstart restart mysql) afterward, you must also run the command bigstart start to restart dependent daemons.

XML content profile created by Automatic Policy Builder (ID 398858)
The Policy Builder creates an XML profile with the name auto_none_profile_N (where N is a number), and does not associate it with any URL.

Reduced memory allocation (ID 399554)
In version 11.3.0, the maximum memory allocated to the Enforcer on low end platforms (with 4 GB RAM or less) was reduced from 1.5 GB to a lower number (around 700MB). Although the memory usage was optimized, the reduced memory allocation could lower the ASM performance. For more information, see SOLl10288: BIG-IP software and platform support matrix.

Accuracy of Policy Builder progress bar (ID 399576)
In some cases, after running the Policy Builder for a few minutes, the Policy builder progress bar may shows that its job is almost complete even though no security policy entities were added yet to the security policy.

Total Entries Chart statistic (ID 399722)
When viewing violation charts (on the Security > Reporting > Application > Charts screen) on chassis-based platforms and Enterprise Management, the "Total Entries" value at the bottom of the page may be incorrect for some of the "View By" entities.

Manually changing the security policy while the Automatic Policy Builder is running (ID 400913)
When using the Automatic Policy Builder to learn new parameters, if you change the configuration so that the Policy Builder does not learn new parameters anymore, the wildcard parameter stays in its last state, which can be a temporary state in terms of the automatic Policy Builder, such as "staging=on" and "value type=ignore value". We recommend you do not make manual changes while the Automatic Policy Builder is running.

Adding a cookie with a long name (ID 401500)
In order to add a cookie with a long name to the security policy, the first 500 bytes of the cookie name must be unique.

Parameter level learning (ID 401510)
Running the Deployment wizard using the scenario Create a policy automatically with the Policy Type Comprehensive, configures the Automatic Policy Builder to learn explicit parameters at the URL level. However, the Manual learning provides suggestions for illegal parameters at the Global level.

Web scraping attack event correlation (ID 401951)
The Security > Event Logs > Application > Event Correlation screen does not provide information about detected web scraping attacks.

Displaying non-printable characters on the Policy Diff screen (ID 402533)
The Policy Diff screen does not display non-printable characters even though the Hex value of the non-printable character appears in the security policy. Therefore, after you calculate differences between two security policies, it is possible that two security policies have different entities (one with a non-printable character and one without), but these entities look identical on the Policy Diff screen.

Security policy created from tmsh (ID 403255)
Creating a security policy using the tmsh command: tmsh create asm policy <name> encoding utf-8 creates a security policy without a pure file type wildcard, without a pure parameter wildcard. In addition, it configures the Policy Builder to learn all file types but to never learn explicit URLs and parameters.

Deploying on ASM on EM with no target devices (ID 403570)
ASM and EM: The Deploy button is available even if there are no target devices on the Security > Application Security > Policies > Policy Deploy screen. Clicking the Deploy button does not deploy the security policy, but it does cause the system to display an error message.

Innocuous error message in TMM log (ID 403615)
The occurrence of the message "DOSL7 failed to prepare avr collector" in the TMM log files is innocuous and only indicates that Application Security Manager (ASM) is not provisioned.

Reporting Content-Type headers (ID 403652)
The Enforcer incorrectly removes headers in the reported request while parsing responses to client-side checks containing a big cookie header. As a result, the Content-Type header is reported twice instead of once, and with an incorrect value.

Migrating from PSM to ASM (ID 403868)
When Application Security (ASM) is provisioned and Protocol Security (PSM) is not, the Configuration utility does not display the migration screen that enables you to migrate Protocol Security profiles to Application Security policies. Previously, you only needed to provision ASM.

Missing system validation (ID 403910)
System validation is missing in both of the following cases:

  • When enabling Application Security on an HTTP class assigned to the virtual server which already has an HTTP profile with enabled Protocol Security assigned to it.
  • When enabling Protocol Security on an HTTP profile assigned to the virtual server that already has an HTTP class with enabled Application Security assigned to it.

Creating a policy using tmsh (ID 404306)
You are unable to create a security policy using tmsh commands immediately after creating its HTTP class, as a sequence of the two tmsh commands in a bash script. To work around this issue, in your bash script, first create an HTTP class and then its active security policy. If you do not want to change the order, you should add a time delay of at least 3 seconds between these two commands.

Cookie attribute learning from matched wildcard (404335)
If the Insert HttpOnly attribute and Insert Secure attribute cookie attributes are manually enabled for the cookie wildcard entity (these attributes are disabled by default), security policy cookies created based on a match with this wildcard and accepted from Manual Traffic Learning suggestions are supposed to inherit the Secure and HttpOnly attribute settings from the wildcard cookie, but they do not.

Scheduled report migration limitations (ID 404455)
While upgrading, all or some of the ASM scheduled reports are not migrated when either of the following is true:

  1. One or more of the scheduled reports is configured to use the "All" filter (All policies - both alarmed and blocked).
  2. One or more of the scheduled reports that is a custom multi-leveled report which has only one selected entity in chart path.

To work around this issue, delete or modify these two types of scheduled reports before upgrading to a higher version.

Preventing session opening anomaly on secondary blades (ID 404476)
Session opening anomaly is not prevented on secondary blades.

Parameter Extractions (ID 404503)
When creating or editing a parameter extraction (Security > Application Security > Parameters > Extractions screen), the system allows you to add a file type and URL to extract from and save/update the screen. However, upon returning to the Extraction Properties screen you will see that the system did not really save the Extract From settings.

Deleting a policy using tmsh (ID 404619)
Using tmsh commands, you cannot delete a security policy created while being in another partition, and the system presents a meaningless error message.

Displaying session transactions anomaly statistics (ID 404634)
Session Transactions Anomaly: In a clustered environment, the system displays statistics of the number of violating requests only of the primary slot.

Remote server logging of session transactions anomaly (ID 404637)
The system sends to the remote server incorrect information regarding the operation mode of attack for Session Transactions Anomaly attacks. For example, the system might log that the operation_mode is Transparent instead of Blocking.

Locking out other users (ID 404655)
If a user logs into the system, after that user logs out then the security policy is locked, and no other users may make changes to the security policy for around 15 minutes.

Overview widget display (ID 404732)
When running traffic for multiple security policies, if you have an Overview widget that has filters on Virus, Username, or URL, it may display wrong values.

Overview widget display (ID 404733)
When updating an Application Security Overview widget, filtering by violation, attack type or IP address intelligence may cause wrong values to be displayed for the widget.

Application Security Editor importing security policies (ID 404744)
A user with the role of Application Security Editor with access to a specific partition cannot import security policies. The Import option is available to that user, but after attempting the import process, the system displays an error message.
To work around this issue, grant Application Security Editors access to all partitions.

Disabled DoS Profile assigned to a virtual server (ID 405096)
If you have a disabled DoS profile in a version prior to 11.3.0 and upgrade to version 11.3.0, after the upgrade, the system automatically assigns the DoS profile to a virtual server and the system does not perform DoS protection, yet it still collects statistics. Additionally, if you create a new DoS profile with Application Security enabled but with the TPS-based Anomaly and Latency-based Anomaly settings disabled and assign it to a virtual server, the system does not perform DoS protection, yet it still collects statistics. Collecting statistics 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.

DoS Trigger iRule event enabled after upgrade (ID 405320)
If you have a DoS profile in a version prior to 11.3.0 and the Trigger ASM iRule Events option is enabled in the security policy, and you upgrade to version 11.3.0, after the upgrade, the system automatically enables the DoS event Trigger iRule option even if you have no configured DoS iRule. As a work around, disable the Trigger iRule check box.

Changing IP address of virtual server (ID 408162)
Changing the IP address, or port, of a virtual server can lead to a mismatch of statistics gathered on this virtual server and other virtual servers created afterward. This issue affects both AVR Analytics and Application Security DOS decisions.
To work around this issue, avoid changing the IP address of a virtual server. Instead, delete the virtual server and create a new one. If you do change the virtual server’s IP address, you must restart TMM by performing the command: bigstart restart tmm.

 

[ Top ]

Workarounds for known issues

The following sections describe workarounds for the corresponding known issues listed in the previous section.

Installing the current version and saving the database configuration and installation (ID 207422, ID 211521, formerly CR120190, formerly CR127965)

This workaround describes how to correctly install the current version and save your database configuration and installation. For information about the known issue, see Installation may create a UCS file without database configuration.

To correctly install the current version and save your database configuration and installation
  1. Boot into the target installation slot.
  2. Run the command tmsh save sys ucs <file location/filename.ucs>.
  3. Save the UCS file in a safe, remote location.
  4. Run the command tmsh reboot volume HD1.X to boot into the slot you want to install from.
  5. Install your image on the target installation slot.
  6. Run the command tmsh load sys ucs <filename.ucs> to restore the UCS file in the target installation slot.

Manually synchronizing the virtual server configuration to the device group (ID 381406)

This workaround describes how to manually synchronize the virtual server configuration to the device group. For information about the known issue, see Synchronizing virtual server to a device group.

To manually synchronize the virtual server configuration to the device group, perform the following actions:
  1. Go to Device Management > Device Group.
  2. Click the required Device group name.
  3. Click the ConfigSync tab.
  4. Click the Synchronize to group button.
[ Top ]

Contacting F5 Networks

Phone: (206) 272-6888
Fax: (206) 272-6802
Web: http://support.f5.com
Email: support@f5.com

For additional information, please visit http://www.f5.com.

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

AskF5 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news on 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 TechNews

Weekly HTML TechNews
The weekly TechNews HTML email includes timely information about known issues, product releases, hotfix releases, updated and new solutions, and new feature notices. To subscribe, click TechNews Subscription, fill out the required fields, and click the Subscribe button. You will receive a confirmation. Unsubscribe at any time by clicking the Unsubscribe link at the bottom of the TechNews email.
Periodic plain text TechNews
F5 Networks sends a timely TechNews email any time a product or hotfix is released. (This information is always included in the next weekly HTML TechNews email). To subscribe, send a blank email to technews-subscribe@lists.f5.com from the email address you would like to subscribe with. Unsubscribe by sending a blank email to technews-unsubscribe@lists.f5.com.

Legal notices

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)