BIG-IP ASM 11.6.0

Release Notes : BIG-IP ASM 11.6.0

Applies To:

Show Versions

BIG-IP ASM

11.6.0

Original Publication Date: 04/26/2016 Updated Date: 04/18/2019

Summary:

This release note documents the version 11.6 release of BIG-IP Application Security Manager. You can apply the software upgrade to systems running software versions 10.1.0 (or later), or 11.x.

User documentation for this release

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

[ Top ]

Supported platforms

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

Platform name	Platform ID
BIG-IP 1600	C102
BIG-IP 3600	C103
BIG-IP 3900	C106
BIG-IP 6900	D104
BIG-IP 8900	D106
BIG-IP 8950	D107
BIG-IP 11000	E101
BIG-IP 11050	E102
BIG-IP 2000s, BIG-IP 2200s	C112
BIG-IP 4000s, BIG-IP 4200v	C113
BIG-IP 5000s, 5050s, 5200v, 5250v	C109
BIG-IP 7000s, 7050s, 7200v, 7250v	D110
BIG-IP 12250v (requires 11.6.0 HF2)	D111
BIG-IP 10350N (requires 11.6.0 HF2)	D112
BIG-IP 10000s, 10050s, 10200v, 10250v	D113
VIPRION B2100 Blade	A109
VIPRION B2150 Blade	A113
VIPRION B2250 Blade	A112
VIPRION B4100, B4100N Blade	A100, A105
VIPRION B4200, B4200N Blade	A107, A111
VIPRION B4300, B4340N Blade	A108, A110
VIPRION C2200 Chassis	D114
VIPRION C2400 Chassis	F100
VIPRION C4400, C4400N Chassis	J100, J101
VIPRION C4480, C4480N Chassis	J102, J103
VIPRION C4800, C4800N Chassis	S100, S101
Virtual Edition (VE)	Z100
vCMP Guest	Z101

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

Most of the support guidelines relate to memory on the platform or provisioned guest. For vCMP support and for Policy Enforcement Module (PEM), Carrier-Grade NAT (CGNAT), and the Local Traffic Manager (LTM), the following list applies for all memory levels:

vCMP supported platforms
- VIPRION B2100, B2150, B2250, B4200, B4300, B4340N
- BIG-IP 5200v, 5250, 7200v, 7250v, 10200v, 10250v
PEM and CGNAT supported platforms
- VIPRION B2150, B2250, B4300, B4340N
- BIG-IP 5x00v(s), 7x00v(s), 10x00v(s)
- BIG-IP Virtual Edition (VE) (Not including Amazon Web Service Virtual Edition) (3 GB, 10 GB production and combination lab models)
- PEM and CGNAT may be provisioned on the VIPRION B4200 but it is not recommended for production, only for evaluation. PEM may be provisioned on the VIPRION B2100, but it is not recommended for production, only for evaluation. Use the B4300 or B4340N instead.

Memory: 12 GB or more

All licensable module-combinations may be run on platforms with 12 GB or more of memory, and on BIG-IP Virtual Edition (VE) and vCMP guests provisioned with 12 GB or more of memory. The BIG-IP system license for the platform determines which combination of modules are available for provisioning.

Memory: 8 GB

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

No more than three modules should be provisioned together.
On the 2000s and 2200s, Application Acceleration Manager (AAM) can be provisioned with only one other module.

Memory: Less than 8 GB and more than 4 GB

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

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

Memory: 4 GB or less

The following guidelines apply to the BIG-IP 1600 and 3600 platforms, and to VE and vCMP guests provisioned with 4 GB or less of memory.

No more than two modules may be configured together.
AAM should not be provisioned, except as Dedicated.

ASM can be provisioned with this amount of memory, but a sizing exercise should be performed to ensure that it does not hit capacity issues.

vCMP memory provisioning calculations

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

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

[ Top ]

Configuration utility browser support

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

Microsoft Internet Explorer 8.x, 11.x
Mozilla Firefox 27.0.x
Google Chrome 32.x

[ Top ]

Installation overview

This section covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in Upgrading Active-Standby Systems and 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:

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

Installing the software

You can install the software at the command line using the Traffic Management shell, tmsh, or in the browser-based Configuration utility using the Software Management screens, available in the System menu. Use one of the following methods:

Run the command tmsh install sys software image [image name] volume [volume name]. If the volume does not exist, add to the end of this command: [create-volume].
Use the Software Management screens in a web browser.

Sample installation command

The following command installs version 11.2.0 to volume 3 of the main hard drive:
tmsh install sys software image BIGIP-11.2.0.2446.0.iso volume HD1.3

Post-installation tasks

After the installation finishes, you must complete the following steps before the system can pass traffic:

Ensure the system rebooted to the new installation location.
Use BIG-IP iHealth to verify your configuration file. For more information, see SOL12878: Generating BIG-IP diagnostic data using the qkview utility (10.x - 11.x)
Log on to the browser-based Configuration utility as a user with administrator rights.
Run the Setup utility.
Provision the module.
Convert any bigpipe scripts to tmsh. (Version 11.x does not support the bigpipe utility.)

You can find complete, step-by-step installation and upgrade instructions in Creating an Active-Standby Configuration Using the Setup Utility and Creating an Active-Active Configuration Using the Setup Utility, and we strongly recommend that you reference these documents to ensure successful completion of the installation process.

Installation tips

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.

You can check the status of an active installation operation by running the command tmsh show sys software.

If installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.

[ Top ]

Upgrading from earlier versions

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

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

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

Warning: Do not use the 10.x installation methods (the Software Management screens, the b software or tmsh sys software commands, or the image2disk utility) to install/downgrade to 9.x software or operate on partitions. Depending on the operations you perform, doing so might render the system unusable. If you need to downgrade from version 10.x to version 9.x, use the image2disk utility to format the system for partitions, and then use a version 9.x installation method described in the version 9.x release notes to install the version 9.x software.

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

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

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

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.

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.6.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 you are currently running version 10.2.x, and the BIG-IP system uses the logical volumes disk-formatting scheme (not physical partitions), use one of the following upgrade methods:

Run the command bigpipe software desired HD<volume_number>version 11.6.0 build <nnnn.n> product BIG-IP
Run the command tmsh install sys software image BIGIP-11.6.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.1.x

If you are currently running version 10.1.x, and the BIG-IP system uses the logical volumes disk-formatting scheme (not physical partitions), use one of the following upgrade methods:

Run the command bigpipe software desired HD<volume_number> version 11.6.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 versions earlier than 10.1.0

You cannot roll forward a configuration directly to this version from BIG-IP versions 9.0.x through 9.6.x. You must be running version 10.1.0 software. For details about upgrading to those versions, see the release notes for the associated release.

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.4.0 or later

If you upgrade to version 11.4.0 or later, note the following.

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

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

ASM Cookie Security

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

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

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

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

Cookie Signature Validation
After upgrading, the system performs the following:

Turns on staging for all Allowed cookies
Applies signature checks on existing Allowed cookies
Adds a * wildcard Allowed cookie even if the user did not have on previously

Upgrading to version 11.3.0 or later

If you upgrade to version 11.3.0 or later, note the following.

Web Scraping
Previously, there was a check box for enabling web-scraping, and in versions 11.3.0 or later, 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 versions 11.3.0 or later, under these circumstances. However, in versions 11.3.0 and later, the functionality changed so that if the security policy’s Enforcement Mode is Transparent, so the system does not block brute force attacks even if the Dynamic Brute Force Protection Operation Mode setting is Alarm and Block (previously Blocking).

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

Upon upgrading DoS Profiles from versions prior to 11.3.0 to version 11.3.0 and later, 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 versions 11.3.0 or later, after the upgrade the system automatically assigns the DoS profile to a virtual server. As a result, even though the system does not perform DoS protection, it still collects statistics, which impacts the system’s performance. To work around this issue, if you have a disabled DoS profile assigned to a virtual server, to improve system performance you should remove its association from the virtual server. (ID 405211)
We do not support exporting and importing DoS profiles.

Logging Profiles
In versions 11.3.0 and later, logging profiles are assigned to virtual servers. Previously, they were assigned to security policies. Upon upgrading logging profiles from versions prior to 11.3.0 to versions 11.3.0 and later, 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 if you upgrade or import a security policy from a version prior to 11.6.0

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

Bad HTTP version
Null in request
Unparsable request content

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

Security policy status after UCS installation

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

Running Application Security Manager on a vCMP system

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

[ 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

Using the Configuration utility, on the Main tab of the navigation pane, expand System, and click Resource Provisioning.
The Resource Provisioning screen opens.
Set the Application Security (ASM) option to Nominal.
Click Submit.
The screen refreshes, and the resource provisioning level of the Application Security Manager is set to Nominal.

[ Top ]

Working with device groups

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

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

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

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

Note the following:

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

Synchronizing the device group

When adding a device to the trust-domain, or upgrading from a release prior to 11.6.0, this device group requires manual synchronization. This is performed as follows:

In the Configuration utility, navigate to Device Management > Overview.
Under Device Groups, click datasync-global-dg.
Under Devices, click the device which is chosen to have the "master" scripts and keys. They will be sent to the rest of the devices.
Under Sync Options, select Sync Device to Group.
Check Overwrite Configuration.
Click Sync.
When the warning message appears, click OK.

After performing these steps, the device that was chosen will continue to work seamlessly. However, the rest of the devices will become OFFLINE, and will not receive traffic for approximately 3 minutes. During this time, the new client-side scripts and keys will be synchronized and prepared. After about 3 minutes, all units should return to the ONLINE (Active) state, and units should be in sync.

[ Top ]

Supported ICAP Servers

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

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

[ Top ]

New items and fixes in this release

This release includes the following new items and fixes.

New in this release

Improved L7-DoS Visibility

For this release we improved how the system displays DoS attack and mitigation statistics.

The upgraded DoS Application Statistics screen displays reports data about DoS attacks in various graphic formats. It clearly displays the correlation between the system’s detection and prevention techniques.
On the DoS Application Statistics screen, you can click a link to view real-time reports, updated automatically every 10 seconds. You can view up to 10 distinct real-time reports.
The new Overview Summary screen indicates the impact of a DoS attack on your server’s performance and memory, or more than one DoS attack at the same time.
On the new Custom screen, you view widgets that display DoS statistics based on filters you configure.
The new DoS Application Attacks event log clearly indicates when each DoS attack starts and ends.

To view the DoS Application Statistics screen, navigate to Security > Reporting > DoS > Application > Statistics.
To view the DoS Application Custom screen, navigate to Security > Reporting > DoS > Application > Custom Page.
To view the Overview Summary screen, navigate to Security > Reporting > DoS > Overview Summary.

L7-DoS Prevention Methods

We introduce the following new features to Layer 7 DoS mitigation.

CAPTCHA challenge
We added the CAPTCHA challenge mitigation method. The system presents users with character recognition challenges to verify that the users are human.

You configure whether the system presents a CAPTCHA challenge after it detects one or more of the following issues:

A suspicious IP address
Requests from a suspicious country
An attacked URL
An attacked website

When upgrading from previous versions, all CAPTCHA mitigation options are disabled.

Drop all requests option
In addition to rate limiting, you can configure the system to drop all requests involving a suspicious IP address and/or country. It is exactly like the existing Rate Limit with 100% drop ratio, and is applied only to suspicious IP addresses and/or countries.

Previously, you could configure the Drop All option only as an internal parameter. In this version, it is available from the Configuration utility.

When upgrading from previous versions, the following conditions apply:

If IP-based rate limiting was previously disabled, then Source IP-Based Request Dropping is disabled.
If IP-based rate limiting was previously enabled in a version prior to 11.5, or it was enabled in version 11.5 and the Drop All internal parameter value is "false", then Source IP-Based Request Dropping is enabled, and the Drop Policy is set to Rate Limiting.
If source IP-based rate limiting was enabled in version 11.5, and the Drop All internal parameter value is true, then Source IP-Based Request Dropping is enabled, and the Drop Policy is set to Drop All.

Mitigation based on Geolocation
In addition to detecting suspicious IP addresses, attacked URLs, and attacked websites, this release helps you mitigate traffic from countries that send suspicious traffic. We have three new mitigation steps for each anomaly (latency-based and TPS-based).

Geo-location-based Client Side integrity: If traffic from countries matches the thresholds configured in the DoS profile, the system considers those countries suspicious, and sends a JavaScript challenge to each suspicious country.
Geo-location-based CAPTCHA challenge: If traffic from countries matches the thresholds configured in the DoS profile, the system considers those countries suspicious, and issues a CAPTCHA challenge to each suspicious country.
Geo-location-based request dropping: The system drops all, or some, requests from suspicious countries.

In addition, you can add countries to a whitelist (traffic from these countries are never blocked), and a blacklist (traffic from these countries are always blocked as soon as a DoS attack is detected).

When upgrading from previous versions, all Geolocation mitigation options are disabled.

Static URL mitigation
The system now automatically mitigates requests for static URLs (for example, non-HTML, JSON or XML URLs), as long as the following conditions are true:

The system has a DoS profile with Application Security enabled, and that DoS profile is associated with the virtual server.
The system has a Web Acceleration profile associated with the virtual server, and the RAM cache setting is enabled in the Web Acceleration profile. You can associate a Web Acceleration profile without having to purchase a WAM, or any other, license.

Since these requests are served from the BIG-IP system cache, they put the network resources at risk, and since they are non-HTML, they cannot respond to JavaScript challenges. The system randomly drops requests from static URLs that are deemed suspicious if they cross the thresholds configured in the DoS profile, until the traffic sent from those URLs reaches their historical threshold level.

The URL-Based Prevention Policy mitigation method does not have to be enabled in order for static URL mitigation to work, but static URL mitigation takes effect only if caching is enabled in the Web Acceleration profile. This feature does not appear in the Configuration utility, and is enabled by default.

When you upgrade from previous versions, static URL mitigation is disabled.

Proactive Bot Defense

We now provide a proactive defense against bot attacks. In addition to the mitigation methods available in past releases, Proactive bot defense is always running and prevents attacks from starting in the first place. Proactive bot defense is intended to complement, not replace, the current mitigation methods.

We recommend that after enabling this feature, you configure a list of domains and URLs that are part of your website, in order to proactively protect them.

If this feature is enabled, when clients access the web site for the first time, the system injects a JavaScript challenge instead of the original response in order to test whether the client is a legitimate browser or a bot. Legitimate browsers will resend the request to the server with a signed cookie, while bots will not resend the request to the server.

You can also configure how the system reacts to cross-domain requests. That is, if the system receives a request for non-HTML resources (images, CSS, XML, JavaScript, and Flash) without a valid cookie, and has a Referer header with a different domain than the host domain.

You configure proactive bot defense using the DoS Profile Properties screen on the Configuration utility.

Accept Request

With this release you can accept many violations at once for each request. You should accept request violations if you think that the request is legal, and that the violations are all false positives. The system edits the security policy by accepting the learning suggestions that were triggered by the request, so that these violations will not recur. We recommend that you do not automatically accept all requests with a low rating. You should first analyze the Manual Learning suggestions.

We added the Accept button to the Requests log, and the Accept this Request button from the Manual Learning screen (after you click an Occurrences number and then click a URL link). You can click either of these buttons to accept all violations triggered by a specific request, instead of clicking the Learn button, navigating to the Learning screen, and reviewing each learning suggestion.

Notes:

Accepting a request works only if Automatic Policy Building is enabled. Also, the violations that the Automatic Policy Builder learns are according to what was enabled in the automatic policy building settings.
If the same violation instance in the request triggered more than one suggestion, then the most specific violation is accepted.
If the security policy has changed so that some learning suggestions are no longer relevant, then those suggestions will not be learned.
Accepting a request does not change the staging state of the involved entities.
Accepting a request accepts one or many violations for one request. You cannot accept multiple requests in a single task.

The main use case for accepting all violations is for simple low-medium scale WAF deployments.

Extended CSHUI support

To improve our bot detection, we made the following system changes:

Mouse and Keyboard activity detection:
- We check the coordinates of the mouse location, and relate it to the amount of time it takes for the mouse to move.
- We check the time between the keydown and keyup keyboard actions.
- We calculate the variance and standard deviation of every keyboard event.
Rapid Surfing detection: We changed the configuration parameters. The system now considers the client a bot if a specific number of different URLs are accessed in a specific amount of time, or if one page is refreshed a specific number of times in a specific amount of time.

We also added event sequence enforcement. We track the sequence of events that the browser triggers, and detect irregular sequences. When an irregular sequence is detected, in order to prevent false positives, the client is NOT immediately marked as a bot. Instead, the client is prevented from being marked as human until the next page load. You can add a whitelist of URLs on which the system bypasses event sequence enforcement.

You can configure rapid surfing detection and the event sequence enforcement URL whitelist on the Security > Application Security > Anomaly Detection > Web Scraping screen.

We also improved our support of embedded iFrames, and lowered the amount of client-side memory consumed.

Scanner Manual Resolution

There are some vulnerabilities that the system does not automatically resolve because resolving those vulnerabilities might result in breaking the application. In previous releases, the system marked those vulnerabilities as Not Resolvable. In this release, the system marks those as Resolvable (Manually), and guides you to mitigate them manually using ASM and other BIG-IP modules, by providing step-by-step instructions with notifications warning you of the consequences to your web application. To manually resolve vulnerabilities, navigate to the Security > Application Security > Vulnerability Assessments > Vulnerabilities screen, filter the vulnerabilities by View: Resolvable (Manually), click a vulnerability row, and click the Show Resolution button.

Known Limitations

Any user who can initiate Automatic Resolve can manually mark Resolvable vulnerabilities as Mitigated, even if this user has no access to the Virtual Server settings or other settings outside ASM module.
Manually resolvable vulnerabilities that were marked as Mitigated will remain marked as Mitigated after exporting and importing a security policy.
LTM resources such as Virtual Servers, iRules, and SSL Profiles are not included in ASM policy export. Therefore, upon importing a security policy, additional administrator work is required to manually resolve the vulnerabilities.

Upgrade
Vulnerabilities imported into prior versions that have newly added automatic or manual mitigation will continue to be listed as Not Resolvable.

When an administrator upgrades the BIG-IP system, the administrator can reload a report to see which vulnerabilities can now be automatically or manually resolved, according to the configuration of that build.

If present in the imported policy from a prior version, vulnerabilities based on cookies are listed as Not Resolvable. If the scanner export file is re-imported in the current version, additional cookie vulnerabilities are added as Automatically Resolvable (in addition to the Not Resolvable vulnerabilities that are also listed).

Violation Rating

In this release, for each request that caused a violation, we now provide a rating between 1 and 5, where 1 is most likely a false positive, and 5 is most likely an attack on the web application. Rating requests help you decide which learning suggestions to accept.

Use Case 1: Reviewing the Request log
Instead of looking at thousands of request entries to find the ones that are actual attacks and not false positives, you can filter the request log by violation rating. If you see that most requests have a low rating, the security policy may be too strict and causing false positives. We recommend you look at the security policy’s Learning screens and see whether the requests are real violations or false positives. On the other hand, if you see that most requests have a high rating, then the security policy is fine, but your web application is under attack or displays vulnerable behavior (for example, uploading HTML, and sending SQL queries).

Use Case 2: Accepting Manual Learning Suggestions
In the past, it was common to accept all learning suggestions. However, this might have caused users to loosen the security policy too much, and accept actual attacks. In this release, when reviewing manual learning suggestions, you can look at the rating levels of the requests that produced the violations. If the rating is low, the violation is likely to be a false positive, and you can consider accepting the learning suggestion (thereby editing the security policy to allow this violation because it probably is not really a violation). However, if the rating is high, the violation is likely to be a real threat, and you should not edit the security policy to allow this violation by accepting the learning suggestion until you review the requests and determine that those requests are not actual attack attempts. If the violation is caused by many requests, the system displays a histogram showing the rating broken down by the number of requests.

We also added Violation Rating to the View by filter in the Application Charts screen.

Continue Parsing After Violations

Until this release, if there was a parsing error in a request triggering some of the HTTP compliance subviolations, or the Request Exceeds buffer size violation, then the system would not check for other violations in the request. With this release, the system continues to check for other violations in the request.

Note: When the Request Exceeds buffer size is triggered, then if the request was not blocked, the first 10KB of the payload are inspected for other violations, otherwise (if blocked), only the headers are inspected.

Behavioral Machine Learning Layer 7 DDoS Detection

The system can now detect DDoS attacks automatically, without any manual configuration. In version 11.6.0, the system collects statistics but does not mitigate attacks. This feature is available for early access customers by configuring an internal parameter and installing software on a machine in the user’s data center. If the feature is enabled, feedback and notifications are available in the directory: var/log/adm.

Contact Customer Service or the Pre-Sales department for information regarding installing the software.

REST API Enhancements

In this version, we expanded the ASM REST API, as follows:

Users can configure more aspects of the security policy using REST. REST support includes the following objects and features:
- XML Content Profiles (including schema import)
- JSON Content Profiles
- GWT Content Profiles
- Session Awareness
- IP Intelligence
- Data Guard
- Login Pages
- Brute Force
- Policy Building configuration
- CSRF
- Blocking Response Pages
- Geolocation Enforcement
- Sensitive parameters
  This does not include flow parameters and learning suggestions.
We expanded the ODATA compatibility, particularly to support complex queries on nested values in lists.
We implemented documentation support directly from the API (using /example).

For more information, see the iControl^® REST User Guide on http://support.f5.com.

System Variables

In the Security > Options > Application Security > Advanced Configuration > System Variables screen, we added the following internal parameters:

send_content_events: This parameter specifies whether the system logs security events in the ASM log (var/log/asm). The values are 1 (enabled) and 0 (disabled). The default value is 0 (disabled). In releases prior to version 11.6.0, the system always logged security events in the ASM log. In a lab environment, this option may be enabled. However, in a production environment, this option should be enabled only for debugging purposes, and then disabled again for the following reasons:
- Disabling this option provides a significant performance boost.
- Enabling this option will cause performance degradation and also potentially disrupt the correct functionality of the Brute Force and Web Scraping features.
long_request_mem_percentage: This parameter defines the memory percentage for long requests. The default is 10 percent.
max_raw_request_len: This parameter defines the default logging length of the request buffer (the raw request). This enables you to examine the entire request body on the device. The default is 5000 bytes. The minimum value is 128 bytes, and the maximum value is 10,000 bytes.

We removed from the system the system variable max_concurrent_long_request, and replaced it with long_request_mem_percentage.

ASM Control Plane daemon cleanup

In order to improve system performance, we cleaned up the system by making the following changes:

Security events are no longer logged by default in /var/log/asm. Using an internal variable, you can change the value to on, but we do not recommend it.
Most of the events that were logged in the DCC log are no longer logged.
We removed the TS log (/var/log/ts/ts.log). ASM started and stopped notices are now written in the ASM log (/var/log/asm).
There are no more binary configuration files saved in the following locations:
- /ts/bd/
- /ts/config/
- /ts/files/site_1/config/*
We retired the following tools: cleandb, fbloader, fbagent, cfg_converter, convert_cfg, recovery manager, nwd.pl, verify dcc, and the kill/exec scripts.

Note: The new daemon asm_start replaces the old daemons nwd and recovery manager.

Note: Since nwd.pl was removed, you cannot stop the watch dog as you could previously. For example, if you want to stop the policy builder daemon (pabnagd) but do not want the system to restart it, perform the following steps:

Edit the nwd.cfg file, and set MinimalNumThreads to 0 for pabnagd.
Run the command: bigstart restart asm.
Run the command: killall -9 pabnagd.

Fixes in this release

This release includes the following fixes.

ID Number	Description
ID 377305	Unescaped symbols in requests that trigger the Apache whitespace violation (an Evasion Techniques sub-violation) sent to a remote logging server no longer create an unexpected line break in the display of the remote log.
ID 397081	You can now search for a specific signature by entering a substring of a signature name, or a signature ID. When entering search string, all matching signatures are displayed.
ID 406064	We restricted invoking ASM iRule commands within the scope of WEBSECURITY.
ID 406521	You can now select multiple inactive security policies to be deleted at once.
ID 423541	We fixed an issue where the Enforcer incorrectly bypassed ASM upon detecting a non-RFC violation.
ID 427599	We fixed a memory leak that sometimes occurred.
ID 430136	Requests that are rejected by client-side prevention mitigation are no longer counted in the URL Latencies report (Security > Reporting > DoS > Application > URL Latencies).
ID 434461	We improved the system’s integration with Guardium.
ID 435520	We fixed an issue that sometimes stopped you from deleting an ASM security policy that was created using a template after you rolled-forward the policy’s configuration from a previous version.
ID 436924	We added the internal parameter dont_norm_high_ascii. If the value is set to 0 (the default value), the system removes high ASCII bytes as part of the normalization process. If the value is set to 1, the system leaves, and does not remove, high ASCII bytes.
ID 437683-3	We fixed web services signature verification for inclusive namespaces.
ID 438255	You can now upgrade HTTP security profiles from version 11.2.1 to version 11.5.0 and later.
ID 438703	A security policy configuration change no longer fails with a MySQL deadlock error message if you perform the change concurrently while an asynchronous REST task is still running.
ID 438833	Disabled signatures are returned to their default staging state if a security policy was created using the Create a security policy using third party vulnerability assessment tool output Deployment Scenario, and you perform an attack signature update.
ID 439169	The XML parser correctly parses XML documents that contain Unicode characters in the code-points range [0x2100 - 0x23FF].
ID 440057	We corrected how the system logs requested URLs that contain navigation parameters configured in the security policy.
ID 440254	For clarity, we changed the name of the Evasion technique detected sub-violation from Multiple decoding: «number» decoding passes to Multiple decoding: Considered an evasion after «number» decoding passes.
ID 440378	Added tmctl stats for dcc, bd_agent, and correlation daemons. This allows visibility into the internal state and processing of the daemons to provide external visibility into their internal state and processing to assist diagnostics and debugging.
ID 441075	Newly added or updated signatures are no longer erroneously added to Manual user-defined signature sets that were created by policy import.
ID 441495	When the payload is about to go to the anti-virus server for inspection, the Enforcer now tests whether the client is still connected, and if it is not, the Enforcer does not send the request to the anti-virus server, and it does not issue a virus found violation.
ID 441500	We fixed an issue where a unit occasionally fails-over upon receiving updates from the IP reputation database.
ID 441945	Events related to the Share Site Map with Vulnerability Assessment Tool are no longer logged into the Policy log.
ID 442153	Clicking the Accept button in the Redirection Domains section on Security > Application Security > Policy Building > Status (Automatic) screen now enforces redirection domains and deletes the pure wildcard (*) redirection domain name from the security policy.
ID 442908	When an attack signature is disabled on an entity (such as a parameter or a cookie) we no longer reset the attack signatures stability. This speeds up the policy stability. This behavior is configurable using the speed_up_signatures_stability entry in the pabnagd.cfg file.
ID 446664	We fixed an issue that sometimes might have incorrectly triggered an un-parseable request violation.
ID 446774	When the Explicit Entities Learning setting for Parameters is changed to Add All Entities, we changed the Parameter Value Type for the wildcard parameter from Ignore value to User-input value. This was done in order for signatures to trigger violations against the wildcard parameter.
ID 446589	We fixed a client side challenge parsing issue that rarely led to a crash.
ID 447305	Using the internal parameter cshui_excluded_urls you can define web scraping human detection white-listed URLs. These URLs are not injected with client-side JavaScript for mouse/keyboard movement. For example, to add the URLs index.php and index1.php as web scraping whitelisted URLs, open the command line and run the following command: /usr/share/ts/bin/add_del_internal add cshui_excluded_urls /index.php,/index1.php
ID 448344	The system no longer enforces the Host header contains IP address sub-violation of the HTTP protocol compliance failed violation if the IP address contains a known bot (search engine).
ID 448547	We now log the response of the request that triggered the violation Request exceeds predefined buffer size, and the request is no longer bypassed.
ID 451253	We fixed an issue where intermittently, the system highlighted the wrong characters of a request that was detected by an attack signature.
ID 451257	We fixed an issue where during stress, the Enforcer would intermittently crash on the secondary blade of a multi-blade unit.
ID 451420	Client username and IP address were added to auditing information on ASM configuration changes.
ID 451705	In the security policy, the system no longer accepts meta-character values outside the legal range.
ID 456120	After you perform a configuration sync, all policy version files persist correctly on both the sender and the receiver.
ID 459887	There are two new internal parameters. They are add bf_history_logins and bf_history_failed_logins. Their default values are 0. When the values of these parameters are greater than 0, these parameter values override the historical login values automatically learned by the system’s brute force engine. For example, to set these parameters values to 5, from the command line, type the following commands: /usr/share/ts/bin/add_del_internal add bf_history_logins 5 /usr/share/ts/bin/add_del_internal add bf_history_failed_logins 5
ID 465181	Even if BIG-IP system fails to connect to the IP reputation database server (either using a proxy or not), it will not cause a memory leak in one of the internal daemons.

[ Top ]

Features and fixes introduced in prior releases

New features introduced in 11.5.1

There were no new features introduced in version 11.5.1.

Fixes introduced in version 11.5.1

This release includes the following fixes from version 11.5.1.

ID 440900The Share Site Map with Vulnerability Assessment Tool feature now also takes into account the IP addresses specified in the Trusted IP Addresses area in the Site Mapping Settings tab of the Security > Application Security > Vulnerability Assessments > Settings screen. ID 441249We fixed a rare issue where requests were not processed correctly by the system when the session awareness feature was enabled. ID 445508We optimized the memory usage among long requests in conditioning to various platforms. We introduced a new internal parameter: long_request_mem_percentage. This parameter defines the memory percentage for long requests. The default is 10%. ID 445511The system no longer logs the irrelevant error message: "TCL error: bad option "above": must be require or preclude while executing" that was displayed in the LTM log (/var/log/ltm). ID 446989The Enforcer no longer crashes when it analyzes a long dynamic parameter. ID 448357Attack Signature Updates now show full readme contents. ID 448402We reduced the learning manager’s resource usage when it processes traffic with cookies and headers, in case there are no learning suggestions for cookies or headers. ID 448717The AVR_DIM_URL table size is now controlled and does not fill the /var/lib/mysql partition nor block /var/avr/loader files from being loaded.

New features introduced in 11.5.0

Layer 7 DoS improved detection and filtering
We added the following features to DoS Application Security protection. The settings available from the Configuration utility are found on the Security > DoS Protection > DoS Profiles > DoS Profile Properties screen.

Preventing DoS attacks on Heavy URLs: This is a new mitigation method intended to protect heavy URLs from DoS attacks. Heavy URLs are a small number of site URLs that might consume considerable server resources per request. This type of DoS attack is different from the existing URL mitigation because it takes only a low rate of requests to heavy URLs in order to cause DoS attacks. In addition to configuring heavy URLs, you can view latency information about web application URLs on the new URL Latencies screen (navigate to Security > Reporting > DoS > Application > URL Latencies).
Site-wide mitigation: This is a new mitigation method used to stop DoS attacks in either of the following cases:
- The web site is evidently under attack but ASM has failed to pinpoint either specific client IP addresses as suspicious attackers, and/or specific URLs that are being attacked.
- The web site is evidently under attack, and ASM has a list of suspicious IP addresses and/or URLs that were found suspicious, but mitigating them has failed to stop the attack.
In these cases, enabling site-wide mitigation applies the prevention methods on the entire site. The system uses this mitigation method as a last resort because using this mitigation method could cause the system to drop legitimate requests. However, the mitigation method maintains the availability of the web site, at least partially, even though the web site is under attack.
When upgrading from previous versions, the Site-wide Rate Limiting prevention policy is disabled.
Prevention Duration: In previous releases, the Prevention Duration setting on the DoS Profile Properties screen specified the total time to try mitigation steps. In this release, the user specifies an Escalation Period (which is the minimum time spent in each mitigation step before the system moves to the next mitigation step) and a De-escalation Period (which is the time spent in the final escalation step until retrying the mitigation steps). We removed the Unlimited option.
When upgrading from previous versions:
- Escalation time is set to the value that was in the Prevention Duration setting in the old version, divided by the number of selected prevention steps in the DoS profile. (This is how the escalation time was computed until this version.)
- De-escalation time is set to the Prevention Duration from the old version, or to 0 if it was Unlimited.
Layer 7 DoS: Drop all requests from suspicious IPs: You can now drop all requests from suspicious IP addresses using a new internal parameter dosl7d.drop_all_from_suspicious_ip that is only available from the command line using tmsh. A suspicious IP address is an IP address detected by the system as being an attacking IP address.
- If the value is 0 (disable), the system drops requests from a suspicious IP address until the system reaches a legitimate traffic rate. This is the default value.
- If the value is 1 (enable), then the system either drops all requests arriving from a suspicious IP address when the prevention policy is rate limiting, or the system sends a client-side challenge to all requests from this IP address when the prevention policy is client side integrity defense.
Record traffic during a DoS attack: You can now record traffic (perform a TCP dump) when a DoS attack is underway, in order to diagnose the attack vectors and attackers, observe whether and how the attack was mitigated, and draw conclusions for changing the DoS profile configuration. The feature records traffic during DoS attacks on the virtual server in which the attack was detected.
Although this is not the default, the TCP dump files can be collected into the QuickView file so that F5 Support can use it for solving customer cases.
The files are located in the system in the following file path: /shared/dosl7/tcpdumps, and have a pcap extension.
The name of the dump file is formatted as follows:
<YYYY_MM_DD_HH:mm:SS>-<attack_id>-<seq_num>.pcap
Where:
- <YYYY_MM_DD_HH:mm:SS> is the timestamp when the dump started.
- <attack_id> is the ID of the attack as it appears in the logs and reports.
- <seq_num> is the sequence number of the dump cycle, starting from 1 when the attack starts, and increasing.
To configure the system to perform a TCP dump after detecting DoS attacks, navigate to the Security > DoS Protection > DoS Profiles > DoS Profile Properties screen, and configure the Record Traffic During Attacks area. This feature is disabled by default.

REST API
The iControl^® REST service is a public API based on the Representational State Transfer (REST) architecture. You can use this interface to manage security policies. For more information, see the iControl^® REST User Guide on http://support.f5.com.

Enhance ASM/iRules integration
With this release you can create iRules that instruct the system to perform an action after requests are handled, even if the requests do not trigger a violation. (Previously, you could only create iRules that instructed the system to perform an action on handled requests that triggered violations.)

To configure the system to perform a specific action after handling requests that do not trigger violations, take these steps:

On the Security Policy Properties screen, for the ASM iRules Event Mode setting, select Normal mode instead of Compatibility mode. (The functionality of Compatibility mode was the only option available in versions prior to version 11.5).
Write iRules that perform specific actions based on the request within the new ASM_REQUEST_DONE event.

When upgrading to version 11.5, the configuration of the Trigger ASM iRule Events setting is copied from the old version. If it was enabled, the new ASM iRule Event Mode setting is set to Compatibility Mode.

You can also create custom violations in addition to the system-supplied violations. Custom violations are helpful in mitigating zero-day attacks and in protecting your web application against specific vulnerabilities not yet protected by ASM.

To have the system protect your web application using custom violations, take these steps:

Create a custom violation (violation name and severity). Navigate to the Security > Options > Application Security > Advanced Configuration > Violations List screen, click the User-Defined Violations tab, and click the Create button.
Write iRules that issue custom violations per request based on the conditions available. ASM blocks according to the violation’s blocking settings and operation mode (Blocking or Transparent), and logs details in the Requests log.

Vulnerability Assessment integration improvements
To improve our integration with vulnerability assessment tools, we added the following characteristics:

Policy Builder Learning: We now support the option of enabling the Automatic Real Traffic Policy Builder to run alongside a vulnerability assessment tool. Doing this further improves the security policy and prevents false positives.
Important: The Policy Builder can modify the policy settings and may override vulnerability assessment tool import settings.
There are different ways of running the Automatic Policy Builder on a security policy that is associated with a vulnerability assessment tool:
- If you create a security policy from the Deployment wizard using the scenario Create a policy using third party vulnerability assessment tool output, select the Real Traffic Policy Builder check box. (This option is enabled by default.)
- If you first create a security policy, then run the Policy Builder, and then associate the security policy with a vulnerability assessment tool, the system automatically changes the Policy Type to Vulnerability Assessment. (This setting is found on the Policy Building > Settings screen.)

HTML5 CORS Enforcement
CORS (Cross-Origin Resource Sharing) enables one website to access the resources of another website using JavaScript (that is, within the browser). You might want to do this because your web-application could require sharing resources with another website that is hosted on a different domain. Using ASM, you can enforce CORS access by specifying the conditions that define when a foreign web application is allowed to access your web application after it makes the cross-domain request using JavaScript.

To configure CORS enforcement, navigate to the Security >Application Security > URLs > Allowed URLs > Allowed URL Properties screen, select the HTML5 Cross-Domain Request Enforcement setting, and configure the settings of the HTML5 Cross-Domain Request Enforcement tab.

Bot detection improvement
In this release we added the following mechanisms to better mitigate web scraping attacks:

Fingerprinting: You can configure the system to detect browsers and malicious users by collecting browser attributes.
Suspicious clients: You can specify which web scraping extensions the system should consider illegal for browsers to have. If the system detects a browser with one of these extensions, the system determines that the client is suspicious, and it logs and blocks requests from this client to the web application. The allowed extensions are limited to the following Google Chrome plugins: Table Capture, Scraper, and UA Spoofer.

To enforce fingerprinting and session opening mitigation, perform the following steps:

Navigate to the Security > Application Security > Anomaly Detection > Web Scraping screen, and select the Fingerprinting Usage setting.
Set the Session Opening setting to Alarm and Block.
Enable the setting Persistent Client Identification.
Click the Session Opening tab, and configure Enabled by Fingerprinting Usage in the Cookie Deletion Detection setting in the Session Opening Thresholds (by Persistent Device Identification) area of the screen.

To enforce fingerprinting and bot detection mitigation, perform the following steps:

Navigate to the Security > Application Security > Anomaly Detection > Web Scraping screen, and select the Fingerprinting Usage setting.
Set the Bot Detection setting to Alarm and Block.
Enable the setting Persistent Client Identification.
Click the Bot Detection tab, and configure the settings.

To enforce suspicious clients, perform the following steps:

Navigate to the Security > Application Security > Anomaly Detection > Web Scraping screen, and select the Fingerprinting Usage setting.
Set the Suspicious Clients setting to Alarm and Block.
Click the Suspicious Clients tab, and configure the settings.

We also made the following internal improvements in the system:

JavaScript obfuscation: Protects the ASM client-side software delegate against tampering and reverse-engineering.
Client-side data: Data that is generated by ASM client-side software delegate, and transmitted to the ASM, is now protected against extraction and tampering using scrambling and authentication mechanisms.

Protection for Unvalidated Redirects
An open redirect is a vulnerability where the server tries to redirect the user to a target domain that is not defined in the security policy. The server redirects a user to a foreign web application, without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.

In this version, you can configure a list of target domains to which users may be redirected.

The feature is designed to automatically protect the application, meaning that by default the feature is enabled with a pure wildcard configured. If the Policy Builder is active and is set to Add All Entities, after the tightening period, it removes the wildcard. This same behavior occurs after you upgrade from a version prior to version 11.5.

To add allowed redirection domains to the security policy, navigate to the Security > Application Security > Headers > Redirection Protection screen. To change the way the policy builder learns explicit redirection domains, navigate to the Security > Application Security > Policy Building > Settings screen. There is a new learning violation, Illegal Redirection Attempt, and from the learning screen you can add a discovered domain name to the security policy as an allowed redirection domain name.

Improved Policy Versioning
We improved how security policies are identified by specifying the version of the policy. Versions of ASM security policies are now labeled from the time they were modified, not when they were applied. This means security policies are clearly identifiable when transferred between devices, either by exporting and importing a security policy, or by using BIG-IQ system policy deployment. Users can easily determine whether a source policy for deploy/import is newer or older than the target policy (that is about to be overwritten).

We also added the device name (hostname) as part of the policy version identifier, which is necessary when managing multiple devices from BIG-IQ system.

Notes:

A security policy is considered modified even if the changes have not been applied (the Apply Policy button was not yet clicked).
Clicking Apply Policy does not update the policy version.
Changes to device-wide configuration, such as attack signatures, do not affect the policy version. Therefore, it is possible that identical policy versions on different devices may have differing enforcement.
Importing a security policy within the same version is not considered a policy modification, and the version timestamp preserves the policy version embedded in the policy export file.
Importing a security policy from a previous version is considered a policy modification, and the version timestamp will be set to the time the security policy was imported.
The file name used when exporting a security policy is now based on the policy version, and not the time when the security policy was exported.
Secondary blades reflect the policy version based on configuration changes made on the primary blade.
Configuration changes propagated to other devices within a Device Group retain the modification timestamp and device name from the source device. Once synchronized (manual or automatic), policy version remains consistent across devices.

Excluded Headers and URLs
We added the following internal parameters so you can control to which headers or URLs the system does not send a client-side challenge:

cs_excluded_headers: The system does not send a client-side challenge to any headers that appear in this list.
cs_excluded_urls: The system does not send a client-side challenge to requests for any URLs that appear in this list, and these URLs are not qualified for client-side injection.

The default values for each of the two internal parameters is an empty string. Values inserted for either of these lists should be separated by commas.

Note: If the entire website is AJAX based, and the client-side challenge does not work on any of the pages, the system cannot support client side mitigation, and using these internal parameters will have no effect.

Wipe Dynamic Parameters Upon Logout
You can now configure the system to remove the dynamic parameter session cookie upon user logout, instead of only after the user closes the browser. We added the internal parameter remove_dyn_param_on_logout that is available only from the command line using tmsh.

If the value is 0 (disabled), and a user logs out of a website but leaves the browser open, and a different user logs in to the same website with his user ID, since the previous dynamic parameter is still valid, the second user will have website options that should be available to the previous user but not to him. This is the default value.
If the value is 1 (enabled), after a user logs out of the website, the system removes the internal dynamic parameter session cookie.

Extract only first attribute for dynamic parameters
When extracting dynamic parameters in an HTML file, you can control whether the system extracts the first or last attribute for a parameter. We added an internal parameter, extract_first_attribute, to control this behavior. The default is 1, meaning the first attribute is extracted. If you set this parameter to 0, the last attribute is extracted.

ASM logging filter for staged signatures
Previously, when customers wanted to see all the illegal requests they had in the logs, they would not have seen the staged signatures happening on their traffic because these requests are considered legal. Conversely, many customers do not want to turn on the log for all requests due to the number of requests they would see. Therefore we added a logging filter option (Illegal requests, and requests that include staged attack signatures) that includes transactions whether they were illegal or had signatures in staging.

Improvement of URL header based content "Parsed As" options
We changed the names of some of the Parsed As options in the Header Based Content Profiles area on the URL Properties screen (Security > Application Security > URLs > Allowed URLs > Allowed URL Properties).

We renamed the Parsed As URL setting to Request Body Handling.
We added the option Do Nothing which specifies that the system does not inspect nor parse content.
HTTP is now Form Data because the system parses content as posted form data in either URL-encoded or multi-part formats.
Apply Value Signatures is now Apply Value and Content Signatures because the system scans the content for both value and content attack signatures.
Don’t Check is now Apply Content Signatures because the system scans content for content attack signatures.

Note: If you are upgrading from a previous version, the system retains the settings of the upgraded security policy, and the old names are converted to their new names.

GUI Enhancements
We made the following enhancements to the Configuration utility:

For DoS Profiles, the default TPS-based Anomaly Operation Mode is Blocking instead of Off. However, if you upgrade from a version prior to 11.5.0, the default setting is Off.
The ASM Charts screen now displays all traffic, not only illegal traffic. We also added filter options to the ASM and PSM charts.
You can now view graphs of statistical information about brute force and web scraping anomaly attacks to your web application. Navigate to the screens: Security > Reporting > Application > Brute Force Attacks, and Security > Reporting > Application > Web Scraping Statistics.
In order to unify and simplify the Cenzic settings, we moved the Cenzic ARC Server address setting from two screens (the Security > Options > Application Security > Preferences screen, and the Security > Options > Application Security > Advanced Configuration > System-wide Cenzic Cloud Account Settings screen) into one screen, located here: Security > Options > Application Security > Integrated Services. We removed the System-wide Cenzic^® Cloud Account Settings from the Security > Application Security > Vulnerability Assessments > Settings screen.
We renamed the Apply to setting to be Signature Scope, and added to the Signature Scope filter the sub-filter options Header, URI, and Request/Response Content, on the following screens:
- Security > Application Security > Attack Signatures > Attack Signatures List
- Security > Options > Application Security > Attack Signatures > Attack Signature List
- Security > Options > Application Security > Attack Signatures > Attack Signature List > Attack Signature Properties
We added the following IP address intelligence categories (found on the Security > Application Security > IP Addresses > IP Address Intelligence screen):
- Illegal Websites: IP addresses that contain criminally obscene or potentially criminal internet copyright and intellectual property violations.
- Cloud-based Services: IP addresses and networks that are used by cloud providers.

Documentation Enhancements
As of this release, the BIG-IP Application Security Manager Configuration Guide now has a new name: the BIG-IP Application Security Manager: Implementations guide. The information is more task-oriented showing examples of how to configure the features of ASM.

Protocol Security Profiles moved from PSM to ASM and AFM
Protocol Security (PSM) is discontinued as a separate module. FTP and SMTP security are now available under ASM. HTTP security is now available under AFM (Advanced Firewall Module). Moving HTTP security from PSM to AFM, and moving FTP and SMTP security from PSM to ASM, enables richer AVR statistic reporting, per violation.

Upgrading to version 11.5: If you have an HTTP security profile in a previous version (created in PSM), and upgrade to version 11.5, note the following facts:

During upgrade, all user defined HTTP security profiles, and the system-defined http_security profile, are migrated from PSM to AFM. If AFM was not provisioned in the earlier version, then these profiles do not appear in the new version until the user provisions and licenses AFM, after which these profiles will be visible. AFM is not automatically provisioned as part of the upgrade process, unless it was already provisioned in the earlier version.
Any virtual server that had an HTTP profile with Protocol Security enabled will have the corresponding HTTP security profile assigned to it after the upgrade (according to the previous HTTP Security Profiles Assignment). However this happens only if AFM is provisioned in the earlier version, or after the user provisions AFM after upgrading.
If you had an HTTP profile as part of PSM, and upgrade to version 11.5, the system continues to enforce HTTP security profiles even if AFM is not provisioned, as long as AFM is licensed. However, you must provision AFM in order to view HTTP reports or change the HTTP security profiles settings.
If you do not have AFM licensed, you can add the AFM license at any time, even after the upgrade. All HTTP security profiles become effective immediately after licensing AFM, and become visible immediately after provisioning AFM.
Trust XFF header and custom XFF headers defined before the upgrade are migrated to override the XFF settings in HTTP profile (assigned to the same VS).
Stored statistics (AVR stats) are not migrated from previous versions, and are not saved for future versions to migrate.
The names of the migrated profiles end with the following suffix: _migrated_httpsecurity_profile. The default description of migrated profiles is: "This profile was created by upgrade migration process from the original HTTP Security Profile named: [<original_http_security_profile_name>]".
The default values of the HTTP default profile remain the same, except for the following cases:
- Null in request body was enabled by default in PSM, and is disabled by default in AFM.
- POST data length was 15728640 bytes by default in PSM, and its default is Any in AFM.
- Configuration of HTTP security is done from the Configuration utility or by using tmsh commands. You can no longer configure HTTP security using iControl.

After upgrading to version 11.5, any preexisting FTP and SMTP profiles that were created as part of PSM are now visible as part of ASM, and these profiles remain assigned to the same virtual servers as before the upgrade.

Maximized Enterprise Application Delivery Value
To make it easier and more affordable to get the Software Defined Application Services capabilities all organizations need, F5 introduces three new software bundle offerings: Good, Better, and Best. GOOD: Provides intelligent local traffic management for increased operational efficiency and peak network performance of applications. BETTER: Good plus enhanced network security, global server load balancing, and advanced application delivery optimization. BEST: Better plus advanced access management and total application security. Delivers the ultimate in security, performance, and availability for your applications and network. You can learn more about these new software bundles from your F5 Networks Sales Representative.

Fixes introduced in version 11.5.0

This release includes the following fixes from version 11.5.0.

ID Number	Description
ID 392895	Data logged in ASM_REQUEST_VIOLATION and ASM_REQUEST_BLOCKING events is now correct even when there are violations in both parts of a 100-continue request.
ID 414931	The Automatic Policy Builder no longer learns entities (like URLs and parameters) from an unparsable request. It does learn violations from the traffic event.
ID 415118	When a response is compressed, and the Learn from responses option is enabled for the Policy Builder, and JavaScript is injected into the response, then the system no longer replaces the original response with an unescaped compressed response.
ID 419650	Upgrading Application Security Manager from a version earlier than 11.3.0 to version 11.3.0 or later no longer fails if identically named entities exist as both wildcard and explicit. This applies to URLs, parameters, file types, and cookies.
ID 419902	After upgrading, the * wildcard cookie will keep its previous Learn Explicit Entities setting. Previously, if the Automatic Policy Builder was disabled, the * wildcard cookie would have its Learn Explicit Entities set to Selective upon upgrading, even if it had been set to Never before the upgrade.
ID 420291	When using Vulnerability Assessment integration with the HP WebInspect tool, all Information Leakage vulnerabilities are mitigated by automatic mitigation.
ID 420298	We improved the system’s integration with the HP WebInspect vulnerability assessment tool to correctly mitigate the Path Traversal vulnerability.
ID 420335	We fixed an issue that sometimes raised the error message "crit g_server_rpc_handler_async.pl[13807]: 01310027:2: ASM subsystem error asm_config_server.pl,F5::ASMConfig::Handler::log_error_and_rollback): Set active failed" in the /var/log/asm.log on VIPRION devices, or in a device group after synchronizing a failover device group.
ID 420528	The Enforcer no longer crashes during a specific memory exhaustion scenario.
ID 420544	The system now correctly displays the popup screen that appears after you perform the following steps: 1. Navigate to the Security > Application Security > Policy Building > Violations on Entities > Violations on Cookies screen. 2. Click a cookie name. The Attack Signature Detected (filtered by cookie) screen displays. 3. Click the Recent Incidents link next to the signature.
ID 420634	When using Vulnerability Assessment integration with HP WebInspect, all HTTP Response Splitting vulnerabilities are completely mitigated by automatic mitigation.
ID 420861	In the Configuration utility, we added validation to the creation and editing of XML profiles such that if Web Services Security is enabled, a server or client certificate must be specified. This was done to prevent an issue where ASM truncates XML requests internally, causing the Malformed XML data violation, when Web Services Security is enabled without certificates or WSDL files.
ID 420980	We fixed an issue that sometimes caused the Enforcer to crash when response logging is enabled.
ID 421250	Protocol Security: The Enforcer no longer crashes when the remote logger is enabled, and FTP or SMTP traffic has a security violation that should be logged, and the connection is then closed (on the server side or the client side).
ID 421452	We improved the Policy Builder’s performance of processing a long list of Extraction URLs.
ID 421748	Zombie processes of find-activate.pl no longer accumulate when there is no outbound network access from the device.
ID 423534	We fixed an issue that sometimes caused a DoS Layer 7 attack to be falsely detected during memory exhaustion scenarios, and reported as coming from the Aggregated URL.
ID 423803	Even if the configuration between devices in a device group is not fully synchronized, the association between Virtual Servers and HTTP Profiles are no longer lost.
ID 425411	The Application Security Manager part of qkview no longer hangs when trying to collect data from the system’s DoS layer 7 plugin.
ID 425412	Cluster synchronization no longer fails if an account has been deleted. This used to occur when Application Security Manager is disabled for an HTTP Class, or the HTTP Class is deleted.
ID 426034	On the Application DoS (Layer 7) Reporting Statistics screen, we added the measure Average dropped requests, and changed the display name of Dropped transactions to Dropped requests in order to be consistent with the rest of DoS report terminology.
ID 427147	We fixed an issue that sometimes caused the Enforcer’s XML parser to crash.
ID 427161	Enabling the URL Meta Characters Automatic Policy Building Policy Element setting, and running the Policy Builder no longer places explicit URLs in staging that were previously not in staging.
ID 427754	The system prevents a JSON profile from being deleted (even by the Automatic Policy Builder) if there are security policy parameters associated with that JSON profile.
ID 427769	Event Correlation: Heavy MySQL resources are no longer used when a potential incident is converted into an actual incident.
ID 428121	You can now export the Request List in CSV format from the Security > Event Logs > Application > Requests screen with a filter using the Severity field. Previously, the export failed and the system displayed an error message.
ID 428327	We fixed an issue that happened rarely, where the Enforcer crashed after connecting and disconnecting VIPRION blades due to memory corruption.
ID 428470	In the DoS Layer 7 remote log, we fixed the value of the field dos_attack_tps that appears during ongoing attack messages. Previously, this field always appeared as 0.
ID 428952	We fixed an issue, which rarely occurred, when the Enforcer would crash after a long POST request prematurely closed.
ID 429057	Additional user-defined values in the Application Security > Advanced Configuration > System Variables screen are now upgraded correctly.
ID 429434	If the DoS attack drop ratio (the percentage of requests that are dropped in order to reach the target outgoing TPS) is greater than 95%, the system considers it to be 100%. Previously, when the drop ratio was between 95% and 99%, the drop ratio would not increase all the way to 100%, leaving some traffic to pass through.
ID 430658	Layer 7 DoS: Previously, the system updated the drop factor only for changes that were at least +/- 5%. Now, the system updates the drop factor every 1 second if the change is +/-5% or more, and the system updates the drop factor every 10 seconds if the change is less than +/-5%. As a result, the system now updates the drop factor for 1% resolution every 10 seconds.
ID 430667	Remote Logging of DoS events: We changed the meaning of the dos_attack_tps field (in Splunk), and the detection_average field (in ArcSight) from being the average TPS when an attack was detected to the average incoming TPS during a DoS attack (the 60-second average TPS of each IP or URL).
ID 431619	Fixed an intermittent issue with the Application DoS initialization process that led to errors in DoS mitigation after the initialization.
ID 432207	The GWT parser no longer blocks legal requests with non-digit characters at the end of the request payload.
ID 433418	After updating the GeoIP database (see SOL11176) and restarting the ASM bd daemon, the bd daemon no longer fails to read the system’s GeoIP files (/shared/GeoIP/).
ID 433782	The system no longer sends multiple error messages in asm.log when client-side statistics are updated for a non-existent account.
ID 434313	We fixed a rare case when after a TMM core dump, Application DoS got stuck in a loop, consuming 100% of the CPU.
ID 435026	We fixed an issue where the system did not correctly extract dynamic parameters in forms that contain combo boxes with script attributes, and the Illegal dynamic parameter value violation was incorrectly produced.
ID 436381	The Configuration utility now quickly displays active security policies even when there are a large number of security policies assigned to a large number of virtual servers (over 100).
ID 437696	Application DoS: When Latency-based detection is set to Transparent, a latency-based attack is reported when there is at least one suspicious entity by TPS (or a heavy URL in version 11.5). This is consistent with Blocking mode. Previously, this type of attack was reported in Transparent mode as soon as the system detected high latency, even before the system detected a suspicious entity.
ID 438577	In order to better protect web applications, and to help prevent the Enforcer from crashing when the DNS server is not available, we made the following changes: - We changed the default in the DNS resolver retries internal parameter (bots_gethost_retry) from 5 to 2. - We added a new internal parameter: trust_search_engine_user_agent. The default is 0. If you turn this on (change this to 1), the user agent is trusted when the DNS server does not function or stops functioning. In this case, for requests identifying themselves as search engine bots, you will not have client-side challenge, and no web scraping mitigation. In addition, the Enforcer will not crash if the DNS server is not responsive.

New features introduced in 11.4.1

Fixes introduced in version 11.4.1

This release includes the following fixes from version 11.4.1.

ID Number	Description
ID 366861	We fixed an issue that sometimes caused the Enforcer’s XML parser to crash.
ID 415008	There is no longer a JavaScript error when there are multiple injections of AJAX or CSRF code in the response (for example, if the AJAX Blocking page or CSRF feature is enabled).
ID 418854	The system now enforces the RFC compliance, geolocation, and IP reputation violations of a request whose content-length is above the allowed buffer size. Request buffer size is configured using the internal parameter long_request_buffer_size, and the default is 10M.
ID 419781	We fixed an issue that sometimes caused the Enforcer to stall when sending logging information to an unavailable remote logger.
ID 419899	The online help was corrected, and now states that default value of the Check Signatures setting on the Security > Application Security > Headers > HTTP Headers > New HTTP Header screen is enabled.
ID 420108	Policy export in XML format now includes all attack signature settings, even if attack signatures were deleted from the system.
ID 420315	The system now reports brute force drops even from the last seconds of an attack.
ID 420374	If security policies exist on a partition on one system and those partitions do not exist on the other system, those folders will now be created, and the synchronization will succeed.
ID 420376	The Enforcer internal encoding table is no longer corrupted when all of these conditions are met: - A security policy has an encoding language that has many secondary encoding languages (such as the Chinese encoding). - The Enforcer receives transactions at a high rate with parameters or URLs in different secondary encoding languages. - At the same the user reconfigures the security policy and changes the encoding to one of the secondary encoding languages.
ID 420533	It is now correctly documented in the online help on the Security > Application Security > Geolocation Enforcement screen that the Disallowed Geolocations list displays countries that may not access the web application while the Allowed Geolocations list displays countries that may access the web application.
ID 420977	We improved the system’s placement of ASM JavaScript code.
ID 420981	The file asm_module.xml within the qkview file no longer contains illegal (non-UTF-8) characters that cannot be parsed by many XML tools.
ID 421438	Methods in WSDL files that contain non-alphanumeric characters (such as period) are now enforced correctly.
ID 421450	We fixed an issue that sometimes caused the Enforcer to incorrectly parse multipart data.
ID 421543	The Enforcer no longer crashes when illegal traffic is sent and remote logging is configured on one of two virtual servers assigned to the same security policy.
ID 421629	There is now a validation check that prevents users from deleting a DoS profile assigned to a virtual server. If a user tries to do this, an error message is presented, and the DoS profile is not deleted.
ID 422197	The AVR module no longer collects application security (Layer 7) DoS statistics in either of the following cases: - A DoS profile, with Application Security enabled, is unassigned from a virtual server. - A DoS profile remains assigned to the virtual server, but Application Security is disabled from the DoS profile.
ID 423009	The Enforcer no longer crashes upon startup if remote logging for ASM is assigned to hundreds of virtual servers.
ID 423529	DoS: To avoid wrong escalating from client side mitigation, we fixed the calculation of outgoing TPS in case the challenged requests count is higher than the successful requests count.
ID 423796	When deleting a DoS profile with Application Security enabled, and other DoS profiles with Application Security enabled are still assigned to a virtual server, attacks on these virtual servers are now detected and mitigated correctly.
ID 423797	We added the following internal parameters that you can add to headers and URLs in order to avoid requests receiving a client side challenge: - cs_excluded_headers: Contains one or more headers, separated by a comma [,]. When one of these headers is presented in the transaction, the client side challenge is not injected in the transaction. (The URL qualification will still work in this case, as it is expected that the same URL may appear with or without these headers). The default value is an empty string. - cs_excluded_urls: Contains one or more explicit URLs, separated by a comma [,]. These URLs will never be qualified for a client-side challenge. The default value is an empty string.
ID 423998	The online help explanation of the Ignore Value parameter value type was expanded.
ID 424264, 425171	The system now correctly closes the connection after the system generates a client-side integrity check response, and the original request had a Connection: close header. In this case, we also add the Connection: close header to the client-side challenged response.
ID 424591	We added a description in the online help on the Security > Application Security > Blocking > Settings screen regarding system logging if only the Block check box is enabled.
ID 424605	We improved the URL parser in order to better interpret a specific type of request.
ID 424854	The online help regarding Data Guard Masking in Transparent Mode was enhanced.
ID 425149	We fixed a memory leak that sometimes occurred during a DoS attack.
ID 425252	We fixed a cookie parsing issue that sometimes caused the Enforcer to crash.
ID 426401	We fixed an issue regarding DoS layer 7 client-side enforcement in cases where the responses are compressed.
ID 426406	The TE HTTP header with no value no longer generates a Header name with no header value error.
ID 426425	We fixed a scenario where, under certain circumstances, part of a request that is blocked by ASM appeared in the response to a subsequent non-blocked response.

New features introduced in 11.4.0

ASM HTTPClass replacement
In this version, HTTP Classes are replaced with local traffic policies. The concept HTTP Class no longer appears in ASM. ASM is now enabled and disabled by one Layer 7 local traffic policy that is associated with each virtual server.

After you create an ASM security policy, a Layer 7 local traffic policy is automatically created by the system with a default rule that enables ASM.

All local traffic policies, including those for Layer 7, are made up of rules, which were previously configured only by iRules. Within the ASM Configuration utility, Layer 7 local traffic policies are transparent, and do not have to be configured in order to have ASM security policies.

Policies can be viewed on the Local Traffic > Policies screen. Click a policy to view its properties, and change the policy’s rules. For more information about local traffic policies, see the LTM documentation on http://support.f5.com.

Free vulnerability assessment
In this version you can perform a free vulnerability assessment for your web application using WhiteHat. If you do not already have a WhiteHat API key, click the Get a free website security assessment from WhiteHat link on the Vulnerability Assessments Settings screen to open a popup screen where you can fill out a short form in order to get a free website security vulnerability assessment from WhiteHat. Once scan results are available on the WhiteHat Sentinel cloud solution, ASM automatically downloads the results into the security policy, allowing you to easily mitigate the vulnerabilities.

Integration with database security products
Application Security Manager is now integrated with third-party database firewalls, like IBM Guardium. You can configure the system to forward login request information to a third-party database and wait for its acknowledgement before the system forwards the request data to the server. The third-party can use the application-level information that ASM provides to improve their logging and reporting.

To configure a database firewall server, navigate to the Security > Options > Application Security > Integrated Services > Database Firewall screen. To enable the Database Firewall feature, navigate to the Security > Application Security > Integrated Services > Database Firewall screen.

Collapse URLs in Automatic Policy Building
The Automatic Policy Builder can now collapse a group of explicit URLs with similar settings into one wildcard URL. The Policy Builder will collapse only URLs in the same directory (with the same prefix path) and the same file extension.

To enable this feature, and specify the number of similar explicit URLs the Policy Builder must detect before collapsing them to one wildcard URL, navigate to the Security > Application Security > Policy Building > Settings screen and select the setting Collapse URLs found in the Collapse to one entity setting.

ASM Cookie Security
This release improves the way the security policy protects cookies. You can configure the security policy to perform the following actions:

Place cookies in and out of staging mode.
Check for attack signature matching, and then from the Learning screens disable an attack signature that matches a cookie.
Check whether cookie values contain a Base64 encoded string, and then from the Learning screens disable these checks.

From the Configuration utility you can view cookie violations discovered after running the Policy Builder. In addition, the Manual Learning violations Modified domain cookies and Cookies that can be enforced are now separate.

To view changes the system automatically makes to your security policy after upgrading from versions prior to BIG-IP version 11.4, see ASM Cookie Security in the Upgrading to version 11.4.0 or later section of this release note.

In the previous release there was the manual learning violation, Illegal Base64 Parameter Value. This release adds the violations Illegal Base64 Header Value and Illegal Base64 Cookie Value.

Web Scraping Enhancement: Persistent Storage
The enhanced web scraping detection feature now identifies persistent attempts to reset sessions, and introduces a sticky cookie that binds the client to requests across many sessions. This is to prevent attackers from scraping web applications by deleting their session cookies and scraping the web application within the configured grace interval.

In remote loggers, this type of attack’s anomaly_attack_type field value is Web Scraping Attack Session resets (by Persistent Storage).

This enhancement only works in Blocking mode, and it requires that JavaScript be enabled on the client side.

To enable this feature and configure inconsistency and session reset thresholds, navigate to Security > Application Security > Anomaly Detection > Web Scraping, enable the Persistent Storage check box, and configure all the settings in the Session Opening Thresholds (by Persistent Storage) area on the Session Opening tab.

Cookie Signature Validation
Version 11.4 improves the algorithm and key that determined how to sign ASM cookies stored on the client side. Using the Configuration utility, you can configure the type of algorithm: the default, or in Advanced Mode, the Scrambling and MAC algorithms for each cookie type. You can import an algorithm exported from another system. You can also configure the length of time that the system will use the old key and algorithm, and the length of time that the system will still accept the old key and algorithm while using the new key and algorithm.

To view changes the system automatically makes to your security policy after upgrading from versions prior to BIG-IP version 11.4, see Cookie Signature Validation in the Upgrading to version 11.4.0 or later section of this release note.

Mask Sensitive Information in Request Log
In addition to masking sensitive information in parameters, with this release the security policy can also mask credit card numbers that appear in any part of the request. The credit card numbers are not masked in the actual requests, but rather in various ASM logs within the ASM Configuration utility:

Credit card numbers appearing in entity names are only masked in the ASM Requests log.
Credit card numbers appearing in entity values are masked wherever request information can be viewed.

To set the security policy to mask credit card numbers in the Requests log, navigate to the Security > Application Security > Security Policies screen, click a security policy to view its properties, and enable the Mask Credit Card Numbers in Request Log check box. This setting is enabled by default.

When you are upgrading to version 11.4, or importing from older versions, the configuration of this feature is set to enabled. Logs generated by previous versions do not undergo offline credit card number masking.

Handling special characters in PHP parameter names
In some cases, attackers can evade URL-based enforcement by including the plus, a space, and a period characters (+ space .) inside a parameter’s name in a URL. Therefore, the system now takes parameters imported from the vulnerability files of any vulnerability assessment tool (scanner) that have the (+ .) and space characters in their names, and replaces those parameters with the wildcard group [_.+] because in PHP, the . character and spaces in variable names are converted to underscores.

When you are upgrading from previous versions, this feature is enabled by default. However, the system does not modify the configuration of preexisting parameters.

Handling multiple host headers
You can configure the security policy to block requests with multiple host headers. There is a new HTTP compliance sub-violation Multiple Host Headers, enabled by default. There is manual learning for this sub-violation as there already is for the other HTTP compliance sub-violations.

Handling Path Parameters
You can configure the way the security policy should handle path parameters that are attached to path segments in URIs. The options are:

To perform no normalization or enforcement because the security policy treats the path parameter as a URL instead of a parameter (As URL).
To normalize but not enforce the path parameter (Ignore).
To normalize and enforce the path parameter (As Parameter).

To configure this setting, navigate to the Security > Application Security > Security Policies screen, click a security policy name to view its properties, and select an option from the Handle Path Parameters list.

HTTP Header Normalization
In order to prevent evasion techniques, in this release the system performs HTTP header normalization before the header-based attack signature checks, and this is in addition to URL and parameter normalizations and signature checks that were added in previous releases. To add an HTTP header to the security policy, and configure normalization and signature checks, navigate to the Security > Application Security > Headers > HTTP Headers screen. We added manual learning for evasion techniques detected in headers.

Minor PB enhancements
The Automatic Policy Builder can now upgrade the security policy by performing checks for the following violations: Illegal Header Length, Illegal Cookie Length, and Failed to convert character. To perform these checks, enable these settings on the Security > Application Security > Policy Building > Settings screen.

HP WebInspect Vulnerability Scanner Support
With this release we now support the HP WebInspect vulnerability scanner. Select HP WebInspect from the Vulnerability Assessment Tool list.

Configuration utility changes
The ASM Configuration utility has these new changes:

From the Attack Signature List screen, you can enable and disable selected or filtered attack signatures, and place them in staging or remove them from staging.
All violations and sub-violations are consolidated on one screen. The sub-violation screens are now in the main Blocking screen (Security > Application Security > Blocking > Settings) as collapsible rows. The following screens were removed:
- Blocking > Evasion technique detected
- Blocking > HTTP protocol compliance failed
- Blocking > Web Services Security failure
The system now remembers, for one week, the last used security policy when a user first opens any security policy screen.
The Login URL Bypassed violation now has Manual learning.
A new list on the Security > Application Security > Vulnerability Assessments > Import Vulnerabilities screen enables you to show the last 3, 5, 10, or all scans per subscription. Note that if there are 3 or less scans per subscription, this list is not displayed.
The learning screen for Modified domain cookies/Cookies that can be enforced is now two separate learning screens.

Fixes introduced in version 11.4.0

This release includes the following fixes from version 11.4.0.

ID Number	Description
ID 224840	The maximum length of the logging profile’s storage format was increased from 512 to 1024 characters.
ID 305864	Redirect URLs handled by a customer’s blocking response page are requested with the response code 302 (rather than 301).
ID 336463	You can configure the Automatic Policy Builder to collapse many common explicit URLs into one wildcard URL with a common prefix and suffix. The Policy Builder collapses only URLs in the same directory (with the same prefix path), and if they have the same file extension. This functionality is set in the Options area of the Security > Application Security > Policy Building > Settings screen.
ID 347268	You can enable the security policy to check whether user input parameter values contain a Base64 encoded string. If the value is indeed Base64 encoded, the system decodes this value and continues with its security checks. This option is available for user input Alpha-Numeric parameters and File Upload parameters.
ID 362557	The system now ignores whitelisted IP addresses when calculating brute force statistics.
ID 375142	You can now change the active partition while viewing the Application Security or Protocol Security screens in the Configuration utility.
ID 376192	A request that contains the internal cookie TSxxxxxx_77 or TSxxxxxx_75 that was generated by another HTTP Class no longer causes the Enforcer to incorrectly trigger the "Modified ASM cookie" violation.
ID 378267	We added validation in the Configuration utility for the total length of all Data Guard Exception Patterns. The limit is 255 characters.
ID 378646	The Learn, Alarm, and Block configuration for all violations and sub-violations were consolidated to the Security > Application Security > Blocking > Settings screen.
ID 379705	Errors in bd.log no longer occur when Guaranteed Logging for responses is enabled and there are more than 1000 transactions per second.
ID 382136	The Reconfigure button on the Policy Properties screen now clears also event correlation data of this security policy.
ID 383015	The system no longer goes offline if you are running the Virtual Edition of Application Security Manager inside a XEN virtual machine, and de-provision Application Security Manager (by setting the Resource Provisioning to None).
ID 385096	The error message was improved when MySQL initialization fails if there is no sufficient disk space on the / partition. The new error message is: "There is not enough disk space free on the root directory disk partition -- cannot initialize MySQL".
ID 385365	Learning suggestions are no longer cleaned more quickly than necessary.
ID 386625	Starting from version 11.4, users should use a Layer 7 policy (and Web Security profile) to enable ASM on a virtual server. The HTTP Class entity was removed in version 11.4.
ID 387803	Users will no longer see the following message every minute in /var/log/audit (when config.auditing is enabled): notice tmsh[13814]: 01420002:5: AUDIT - pid=13814 user=root folder=/Common module=(tmos)# status=[Command OK] cmd_data=list sys db ucs.loadtime one-line
ID 388116	With the removal of HTTP Class, this issue is no longer relevant.
ID 390044	The Action Item Selective learning mode is enabled on Parameter set to Ignore Value was added when the parameter’s Explicit Entities Learning setting is Selective and you added to the security policy a pure wildcard parameter with a Parameter Value Type of Ignore value, or vice versa. To resolve this item, the user can either change the "Parameter Value Type", or leave the "Parameter Value Type" to "Ignore value" but change the parameter’s "Explicit Entities Learning" setting to "Add All Entities" or "Never".
ID 392050	We removed generic regions, like "Europe" from the Geolocation list.
ID 393078	XML profiles now handle Web Service Addressing defined in WSDL documents generated by .NET.
ID 393210	Learning suggestions are presented with full request data even in the case where one type of violation already exists in the Learning database and is then triggered repeatedly.
ID 394054	We fixed an issue that caused a TMM core dump.
ID 394357	Added Turkish character encoding (ISO-8859-9) support to ASM Policies.
ID 395644	Event Correlation is no longer a quick link, even in a clustered environment, because it was removed from the configuration utility.
ID 396104	ASM can integrate with a local installation of Cenzic ARC server.
ID 397551	We improved the way we implement the web scraping feature’s client-side challenge, so that when web scraping triggers a client-side challenge to a page of the web application, the user can click on a link in that page and click the "BACK" button on the browser without the browser displaying an error message.
ID 398858	The Automatic Policy Builder does not create an XML content profile in some cases when the URL content type is unknown.
ID 399576	We improved the accuracy of the Policy Builder progress bar. In previous releases, it was inaccurate under specific circumstances.
ID 399926	From the Attack Signature List screen, you can enable and disable selected or filtered attack signatures, and place them in staging or remove them from staging. Click the Change Properties button to open a popup screen where you can define the required actions.
ID 400522	Now the system variable iprep.intervalmin can be configured also with large values (more than 28 minutes, for example 10 hours - by specifying value 600) and it will be used correctly in the daemon responsible for IP Intelligence database updates.
ID 400666	Running the command tmsh load sys default-config now resets the ASM configuration in addition to the entire BIG-IP system configuration.
ID 401951	The Security > Event Logs > Application > Event Correlation screen now provides information about detected web scraping attacks.
ID 401957	We created a new internal parameter, "cs_embedded_script" whose value the Enforcer inserts into the client-side’s check challenge response. This was done to improve how Google analytics learns direct links.
ID 402117	The customer can now import vulnerabilities from a vulnerability file according to a specific domain in a list of domain names.
ID 402177	The Policy Builder correctly learns traffic in a multiple-blade environment even if the slot number of any blade was changed.
ID 402533	The Policy Diff screen now correctly displays non-printable characters.
ID 403255	Creating a security policy using the tmsh command: tmsh create asm policy <name> encoding utf-8 creates a security policy with the same default values as if you created a security policy using the Configuration utility.
ID 403615	The message "DOSL7 failed to prepare avr collector" was changed to "DOSL7: Detected ASM is not provisioned" to clearly present the problem.
ID 403652	The system correctly removes Content-Type and Referer headers in the reported request while parsing responses to client-side challenges containing a big cookie header. These headers are no longer reported twice instead of once, and with an incorrect value.
ID 403702	XML Schema processor now correctly processes empty complex type extensions with empty sequences.
ID 403864	We limited the various tmsh analytics commands so that only valid drill down combinations are allowed.
ID 403868	We removed the ability to migrate from a Protocol Security Profile to an Application Security Policy.
ID 403888	The system no longer displays a blank Policy Groups screen when one of the security policies in the group is inactive.
ID 403910	The system now disallows the following cases: 1. 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. 2. 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.
ID 404006	The blocking response page is now displayed correctly when the Enforcer injects JavaScript in the response and then decided to block it.
ID 404306	From BIG-IP version 11.4, you no longer create an HTTP class before creating a security policy.
ID 404332	When there are no virtual servers assigned with a DoS application profile, the DoS Layer 7 daemon does not process Analytics (AVR) statistics queries.
ID 404455	All scheduled reports are now upgraded correctly between versions.
ID 404476	Session Opening Anomaly prevention is now performed on secondary blades.
ID 404484	A user with a role of Application Security Editor can now calculate differences for identical security policies within the user’s own partition.
ID 404503	The system now saves the Extract From settings when creating or editing a parameter extraction (Security > Application Security > Parameters > Extractions) and you to add a file type and URL to extract from.
ID 404615	We fixed an issue that sometimes produced an incorrect display in the results of a Policy Diff and the Details popup.
ID 404619	Using tmsh commands, you can now delete a security policy created while being in another partition.
ID 404634	Session Transactions Anomaly: In a clustered environment, the system displays statistics of the number of violating requests for all slots.
ID 404637	The system now sends to the remote server correct information regarding the operation mode of attack for Session Transactions Anomaly attacks.
ID 404638	The Deployment wizard’s Configuration utility no longer times-out when more than 1000 virtual servers are configured in the system.
ID 404655	If a user logs in to the system, after that user logs out, then the security policy is no longer locked, and other users may make changes to the security policy.
ID 404732	When running traffic for multiple security policies, having an Overview widget that has filters on Virus, Username, or URL will now display the correct values.
ID 404733	When updating an Application Security Overview widget, filtering by violation, attack type or IP address intelligence will now work correctly and display the right values.
ID 404744	A user with the role of Application Security Editor with access to a specific partition can import security policies.
ID 404763	When an Application Security DoS profile is configured as follows: -The Trigger iRule option is enabled -The Operation Mode is set to Transparent -URL mitigation is configured and a high volume DoS attack occurs without suspicious IP addresses, the system no longer resets the connections to the suspicious URLs.
ID 404768	Tooltips are now displayed properly in the Configuration utility.
ID 405001	We fixed a crash that rarely occurred during regular-expression signature matching on excluded headers. Currently, we perform better verification on PCRE functionality.
ID 405004	Modifying an inactive security policy edits the correct security policy and no longer creates a new inactive security policy. In addition, inactive security policies created by a user with the Administrator role are now displayed using tmsh commands upon tab-completion by a user with the Application Security Editor role and a specific accessible partition.
ID 405013	The Enforcer no longer core dumps when a regular expression is defined on a parameter, a parameter value in the request is very long, and the security policy is configured to check for the "Parameter values does not comply with regular expression" violation.
ID 405039	The tmsh commands create/modify asm policy with the properties encoding and policy-template now succeed also for inactive policies (that is, without specifying the httpclass-profile property) when run by users with the Application Security Editor role and a specific accessible partition.
ID 405096	The system no longer collects DoS statistics in the following scenarios: - If you have a disabled DoS profile in a version prior to 11.3.0 and upgrade to version 11.3.0 or later, after the upgrade, the system automatically assigns it to a virtual server. - 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.
ID 405108	You can configure how the security policy handles path parameters that are attached to path segments in URIs. The options are: as parameters, as URLs, or to ignore them. The new Handle Path Parameters is found on the Policy Properties screen for each security policy.
ID 405211	If you have a policy with DoS protection disabled in a version prior to 11.3.0, and upgrade to version 11.3.0 or later, there will be no DoS profile assigned to that security policy’s virtual server. This was done in order to stop the system from collecting DoS statistics when there is a disabled DoS profile configured in the security policy.
ID 405313	Even if an Application Security DoS profile has a sub-folder in its name, you can add an IP address to the IP Address Whitelist of the DoS profile, and change the settings of the DoS profile if there is already an IP address present in IP Address Whitelist.
ID 405316	We introduced two internal parameters in order to enable users to control the time it takes for the remote logger to try and re-establish a connection to the external syslog server. This is in order to prevent the remote logger from delaying client requests if the external Syslog server is unreachable. The new parameters are the following: - remote_logging_reconnect_timeout (default is 5 seconds) - remote_logging_reconnect_max_failed_messages (default is 1 message)
ID 405677	The Security > Event Logs > Application > Requests screen now displays information about the slot number that processed the request even if this number is higher than 4.
ID 405679	On the Security > Event Logs > Application > Requests screen, you can filter for requests processed by slots 5 through 8, in addition to slots 1 through 4.
ID 405690	The concurrent long requests count is now synchronized. This was done so that when there is a high load of long requests on a platform with many CPUs, the system no longer exceeds the maximum concurrent long request configuration value (determined by "max_concurrent_long_requests").
ID 406178	We upgraded the version of MySQL from 5.1.63 to 5.1.67.
ID 406369	When an ASM security policy and a Web Acceleration (WA) profile or RAM cache are assigned to the same virtual server, a request for a web application object that was already cached by WA or RAM cache that is forwarded for re-validation to the server and triggers an ASM violation will no longer disable the caching in case the server returns the 304 "Not Modified" response code.
ID 406696	The Security > Event Logs > Logging Profiles > Create New Logging Profile > Protocol Security - DNS Security settings are now saved even if the Advanced Firewall Manager is not provisioned or available to that user role.
ID 406702	When "Explicit Entities Learning" for Parameters is set to "Never", the Policy Builder changes the value type of the "*" Parameter to "User Input", and the various attributes of this parameter (Value Meta Characters, Attack Signatures, and so on) are set to be checked according to the Policy Building settings.
ID 407064	If classification mode is enabled, the Automatic Policy Builder adds exception URLs in staging mode.
ID 407473	If a security policy’s login page is configured with HTTP basic authentication, and you configure a Guardium server, when the login page is requested the system sends the login information to the Guardium server for authorization only after user authentication. Previously, the information was sent before user authentication, and as a result, Guardium responded with an error message.
ID 407744	Connections are no longer reset when accessing a virtual server with an adapt profile and an ASM HTTP Class.
ID 407908	We fixed a scenario where some bad JSON requests sometimes caused the Enforcer to crash.
ID 407937	The system’s XML parser now recognizes "0" and "1" as valid xsi:nil boolean values, so that XML elements that contain the attribute xsi:nil="1" no longer incorrectly triggers an XML violation.
ID 408162	Changing the IP address, or port, of a virtual server no longer leads to a mismatch of statistics gathered on this virtual server and other virtual servers created afterward.
ID 408412	Configuration synchronization will now be sent asynchronously to prevent the relay listener from blocking on trying to send a second configuration to a device before the first configuration finished.
ID 408846	The JavaScript code that ASM inserts when the CSRF feature is enabled now conforms to the W3C standard.
ID 408864	The "Severity" and "Threat" columns are switched on WhiteHat vulnerabilities screen.
ID 409405	When a NULL character appears in a header or a request payload, the system now continues to enforce the rest of the request.
ID 409423	We fixed an issue where ASM sometimes injected client side JavaScript in responses when it should not have.
ID 409787	We fixed an issue where the Enforcer might crash if a malformed JSON request is sent.
ID 410199	If you are using the Cenzic vulnerability tool, you can limit the number of previous scans the system displays. There is a new list in the Import Method area of the Import Vulnerabilities screen that allows system to show the last 3, 5, 10, or all scans, per subscription.
ID 410800	Older learning suggestions are always removed before newer ones, even if ASM is restarted. This was sometimes an issue in previous releases.
ID 411699	Vulnerabilities mitigation now adds parameters correctly on HTTP and/or HTTPS protocols as specified by the imported vulnerability.
ID 411704	Security policy import tolerates missing references within a security policy exported as XML.
ID 412000	Upgrading does not fail anymore during the loading of the ASM configuration if a Security Logging profile contains user-defined HTTP methods.
ID 413726	We improved the Enforcer’s parsing of host headers to remove the false reporting of the Bad host header violation.
ID 414288	The Illegal parameter data type violation is now enabled by default if you create a security policy with the Rapid Deployment template and run the Policy Builder.
ID 414290	If the default DoS profile "/Common/dos" has Application Security enabled, then new DoS profiles created with Application Security disabled will be used correctly in TMM, and traffic will not be processed by the Layer 7 DoS plugin when such profiles are attached to virtual servers. In addition, from version 11.4.0, these profiles cannot be used for Layer 7 policies controlling Layer 7 DoS.
ID 414291	On the Policy Builder Settings screen, you can enable the Learn integer parameters check box for the Policy Builder to learn integer parameters (parameters with a Data Type of Integer).
ID 415175	The system now correctly updates the requests drop factor during an attack.
ID 416051	We removed the Application-Ready Security Policy option Rapid Deployment security policy with Policy Builder enabled that was available when creating a security policy using the Deployment wizard scenario Create a policy manually or use templates. This option is visible if you upgrade to version 11.4.0.
ID 416972	Now, a user can add new methods in an HTTP Security profile (in the Request Checks tab) to the Available, and then Allowed, lists. The methods are added correctly with the specified names and can be seen by the tmsh command list asm http-method, and then referenced in other places, such as an ASM security policy and Security Logging profile. Also subsequent re-loading of the configuration (by the tmsh commands save sys config and load sys config) does not fail anymore with the following error: Data Input Error:(at line: 5) a value must be provided for "default-act-as" attribute when creating "http-method".
ID 418511	If a URL’s Header-Based Content Profiles setting is set to be parsed as Don’t check or Apply Value Signatures, and there was a null in the payload, the Null in request sub violation is cancelled. In addition, if that was the only HTTP Protocol Compliance Failed sub-violation that was enabled, the HTTP Protocol Compliance Failed violation is also cancelled. This functionality can be disabled by setting the new internal parameter unset_null_in_request_when_not_parsing to 0.
ID 419261	The system no longer produces learning suggestions for the parameter UNNAMED. In the past it did, to the exclusion of other explicit parameters.
ID 419284	When logging an ongoing DoS layer 7 attack to an ArcSight or Splunk server, the system now suppresses the route domain field of the source IP address.
ID 419884	If the system performs an automatic attack signature update, it also now honors the Auto Apply New Signatures Configuration After Update setting when it is enabled.

New features introduced in 11.3.0

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:

On the Main tab, click Local Traffic > Virtual Servers > Virtual Servers List.
Click a virtual server to which you want to assign a logging profile.
The virtual server properties screen opens.
From the Security menu choose Policies.
The Policy Settings screen opens
Set Log Profile to Enabled.
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 Explicit 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:

Navigate to the Security > Application Security > Parameters screen.
Click Create.
Set the Parameter Value Type to User-input value.
Set the Data Type to either Alpha-Numeric parameters or File Upload.
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 introduced in version 11.3.0

This release includes the following fixes from version 11.3.0.

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 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, the ASM 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.

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 dump.
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 core dumps.
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 core dumps 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 dump.
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 core dumped 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 subsequent 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 core dumps 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:

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

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.

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 systems 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_under_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 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 core dumps 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 dump.

[ 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 or Application 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 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.

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.

Protocol Security requests displayed unescaped (ID 283364, formerly CR98148)
On the Protocol Security Statistics violation screens, the system displays escaped characters in requests as unescaped. For example, if a request contains the characters %3c the system displays them as <.

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.

Protocol Security: FTP logs and port numbers (ID 309659, formerly CR109905)
In the FTP Remote Logging and Statistics logs, the port numbers are represented as a combination of 2 bytes instead of the real port number. For example 108, 108 is displayed to represent port number 27756 since 108*256+108=27756.

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 or Application 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 security policies 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:

Reboot into the partition with the desired configuration.
Save a UCS file aside.
Reboot into the other partition.
Install desired version.
Reboot into newly installed partition.
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.

Errors generated when resetting ICAP server configuration (ID 343418, 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).

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:

Delete the virtual server.
Delete the HTTP Class.
Delete the ASM application object.
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.

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:

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

From the command line:

Determine the IP address that the NAT firewall or WhiteHat Satellite device assigns to requests going to the BIG-IP ASM device.
Log in to the command line on the BIG-IP system.
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.
Reboot Application Security Manager to implement the internal parameter change:
bigstart restart asm

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 Application Security or Protocol Security.

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.

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

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.

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.

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.

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.

Protocol Security: Sending remote log messages (ID 396364)
Protocol Security cannot send remote log messages to IPv6 pool members defined with route domains.

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.

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.

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.

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.

Cookie attribute learning from matched wildcard (ID 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.

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 or later, 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.

Extraneous URL Content Profile lists in Policy Log (ID 409118)
Extraneous Add and Delete entries appear in the Policy Log for URL Content Profile whenever a URL is added or deleted.

Masking encoded credit card numbers (ID 411933)
The system does not mask in the raw request credit card numbers that are encoded in the request using percent encoding, or Base64. The system masks them only in the violation details.

Security policy name is replaced by HTTP Class name upon upgrade (ID 415853)
After upgrading from a version prior to BIG-IP version 11.4 to version 11.4 or later, the name of the security policy is replaced with the name of the HTTP Class if these names were different.

Provisioning changes to AVR, ASM or AFM modules (ID 415883)
On rare occasions, provisioning changes that involve the AVR, ASM or AFM modules can cause TMM to continuously restart after the machine is reactivated. A reboot to the machine solves the problem (by running the command reboot).

Cookie Protection: Grace period after changing the security context (ID 418161)
After a change of the Security Context (due to manual Cookie Protection Reconfigure, UCS import, or Cookie Protection Import), not all the of the ASM cookies are refreshed (re-sent with the new Security Context) during the grace period. This may cause false-violations to be issued when the grace period is over. During the Cookie Accepting Grace Period new ASM cookies that are sent to the client are protected by the new ("active") Security Context, but requests coming in from the client with the old ("grace") Security Context are still accepted.

Security policy based on PeopleSoft Portal 9 (ID 418635)
Creating a new security policy based on the PeopleSoft Portal 9 template may take significantly longer than creating a security policy based on other templates, and it may delay the completion of the iApp implementation.

Failed to set database security server configuration error message in log (ID 419260)
On systems upgraded from 11.3.0, an error message "Failed to set database security server configuration" may appear in the file /var/log/asm upon ASM startup. This message is cosmetic and can be safely ignored.

Wildcard cookie staging state for Application-Ready policy templates (ID 419897)
Some Application-Ready security policy templates will have staging enabled for the "*" wildcard cookie.

Exporting a security policy in binary format and vulnerability assessment configuration (ID 420082)
If you export a security policy in binary format, Vulnerability Assessment configuration is included even if the Include Vulnerability Assessment configuration and data option is not selected.

Configuring DoS profile when system running out of memory (ID 423536)
The Application DoS daemon may crash if you change the configuration of a DoS profile while the system is running out of memory. This does not affect traffic.

Device management: Auto detect selected on source device (ID 428928)
A security policy is not configured on the target device if the Auto detect option is selected for this security policy on the source device.

ASM REST API: Supported user roles (ID 430681)
Only the Administrator role is supported at this time.

XML: Global attributes mustUnderstand and encodingStyle (ID 430762)
The internal XML schema processor does not support the global attributes mustUnderstand and encodingStyle on the Envelope element as being global, and it should. As a result, violations are incorrectly triggered.

Parameter name in koi8-r encoding (ID 432349)
The parameter name of a parameter in koi8-r encoding (Russian) is not displayed in the parameters list and manual traffic learning screens, but the parameter is enforced and the system detects violations on this parameter.

Security policy with invalid iApp name (ID 433146)
If you try to create a security policy with an invalid iApp name from the iApps > Application Services > New Application Service screen, there is an error message on the iApp screen in the Configuration utility and the security policy is created.

Remote storage request logging limit (ID 434109)
Only the first 5006 characters of a request are logged into remote storage, regardless of how you configure the Maximum Entry Length setting.

REST API: Updating a collection of headers (ID 437655)
You cannot update a collection of headers if there is a header among them that requires Base64 decoding and URL normalization.

Logging of bot attack when Bot Detection is disabled (ID 437683)
The system might log (on the Security > Event Logs > Application > Web Scraping Statistics screen) that a bot attack was detected even if the configuration of Bot Detection is disabled if some of the other web scraping features are enabled.

'href' attribute processed incorrectly in XML messages (ID 449349)
The system’s XML schema validator processes the href parameter in non-WSS XML messages, and it should not. As a result, if an XML schema has a defined attribute named href, the XML schema validation fails.

Logging when ASM bypassed by TMM when ASM is down (ID 453150)
It is not logged that ASM is in bypass mode when TMM bypasses ASM when ASM is do/p>

Application-level DoS reporting traffic running through a virtual server not assigned to DoS profile (ID 455027)
Application-level DoS reporting: If traffic runs through a virtual server that is not assigned to DoS profile, it is published as Aggregated instead of using a more descriptive value, as unknown or N/A.

White spaces after the HTTP version (ID 460072)
You cannot allow white spaces after the HTTP version. Currently white spaces at that location trigger the Bad HTTP version violation.

Deletion of XML profiles from Enforcer memory (ID 460076)
XML profiles may not get deleted from the Enforcer’s memory once they are deleted from the configuration. This might lead ASM to run out of memory for XML and JSON processing, recognizable by the error message XML is running out of memory.
There are two workarounds: 1) Add a custom provisioning table to increase the host and ASM memory allocation by 1Gb. 2) Set the value of the parameter total_xml_memory to around 2Gb by typing the following command from the command line:
/usr/share/ts/bin/add_del_internal add total_xml_memory 2000000000.

Traffic with malformed XFF when Accept/Trust XFF is enabled (ID 461234)
If the system processes HTTP requests with malformed XFF, and the security policy’s Accept XFF/Trust XFF Header option is enabled, the IP addresses that sent this traffic are identified as the IPv6 address "::".

Importing security policy using Internet Explorer v.11.x (ID 462575)
You cannot import a security policy using Internet Explorer version 11.x. To work around this issue, when importing a security policy, do not use Internet Explorer; use another browser.

monpd daemon crash (ID 467802)
The monpd daemon crashes and core dumps if it starts when the mysql daemon is down.

Enforcer core dumps after reconfiguring a web application (ID 468357)
The Enforcer core dumps rarely when reconfiguring a web application during traffic stress.

Memory leak in Export Policy operation (ID 470945)
Performing the Export Policy operation creates a memory leak. If a long-lived process exports many security policies, the device can run out of memory.

Ignoring null values for parameters with different content types (ID 471103)
You cannot configure the system to ignore a null value for parameters defined as file upload regardless of the content-type of the parameter in the request. Following the multipart null flow, the system first looks into the content type defined for the parameter in the request itself. If the parameter is defined as textual, the system does not allow a null to appear there, regardless of the policy configuration for that parameter.

Unresponsive DoS Overview screen (ID 471127)
The DoS Overview screen may become unresponsive if there are hundreds of ongoing DoS attacks.

The "show analytics report view-by profile" tmsh command (ID 471289)
After creating an Analytics profile, the show analytics report view-by profile tmsh command may not show any results if a DoS profile is not configured for, and attached to, a virtual server.

"Non existent sender’s email domain" violation details (ID 471748)
After you enable SMTP security in an SMTP profile associated with a virtual server, and enable Blocking, PSM may block mails due to the Non existent sender’s email domain violation. However, the system does not include in the log the actual non existing domain names.

Number of decoding passes configuration (ID 471766)
The decoding passes number selected in the Evasion technique detected sub-violation setting affects URI and parameter input. However, this setting does not affect the number of decoding passes that the system performs on headers, which is always two.

Analytics scheduled report: "predefinedReportName" and "multiLeveledReport" are mutually exclusive (ID 472117)
You create a non-loadable configuration by changing predefinedReportName to multiLeveledReport, or the reverse for an analytics application-security scheduled-report. To work around this issue, manually edit /config/bigip.conf so that predefinedReportName and multiLeveledReport do not appear together in the same Analytics scheduled report.

System offline after attaching datasync local-profiles to the application service and deleting the service (ID 472124)
The system goes offline if you attach datasync local-profiles to the application service and then delete the service. To work around this issue, from the command line, run the command: tmsh load sys config (with or without the tmsh save sys config command before).

Logging of the Attack signature detected violation (ID 472769)
In some circumstances, the Attack signature detected violation is not reported on the Security > Event Logs > Application > Requests screen, even when it is logged in the directory /var/log.

A filter from the requests page that contains a predicate for "Violation ratings" will not work on the reports page (ID 472782)
When a user configures a new filter on the Security > Event Logs > Application > Requests screen using the Violation Rating field (for example, Violation Rating: At least 3), that filter appears but does not work correctly on the Security > Reporting > Application > Charts screen, and it should.

The Learn/Alarm/Block status of Attack Signatures (ID 472960)
The system displays the incorrect status of the Learn/Alarm/Block settings for Attack Signatures in the Requests Details of the Requests screen and in the Attack Signature Detected Manual Learning screen if the Learn setting of the signature set is disabled.

CSRF script that does not iterate over the frames (ID 474256)
A CSRF script that does not iterate over the frame links causes a false positive CSRF violation. You can work around this issue by using the URL list in the CSRF protection configuration.

WSDL regular expression matching (ID 474331)
Intermittently, a WSDL regular expression might not match the actual string, when it should.

[ 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

Boot into the target installation slot.
Run the command tmsh save sys ucs <file location/filename.ucs>.
Save the UCS file in a safe, remote location.
Run the command tmsh reboot volume HD1.X to boot into the slot you want to install from.
Install your image on the target installation slot.
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:

Go to Device Management > Device Group.
Click the required Device group name.
Click the ConfigSync tab.
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.

The F5 Networks Technical Support web site: http://www.f5.com/support/
The AskF5 web site: http://support.f5.com/kb/en-us.html
The F5 DevCentral web site: http://devcentral.f5.com/
AskF5 TechNews

F5 Networks Technical Support

Free self-service tools give you 24 x 7 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.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IP ASM

Summary:

Contents:

User documentation for this release

Supported platforms

Memory: 12 GB or more

Memory: 8 GB

Memory: Less than 8 GB and more than 4 GB

Memory: 4 GB or less

vCMP memory provisioning calculations

Configuration utility browser support

Installation overview

Installation checklist

Installing the software

Sample installation command

Post-installation tasks

Installation tips

Upgrading from earlier versions

Upgrading from version 11.x

Upgrading from version 10.2.x

Upgrading from version 10.1.x

Upgrading from versions earlier than 10.1.0

Preserved data

Upgrading to version 11.4.0 or later

Upgrading to version 11.3.0 or later

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

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

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

Changes the system makes if you upgrade or import a security policy from a version prior to 11.6.0

Security policy status after UCS installation

Running Application Security Manager on a vCMP system

Changing the Resource Provisioning level of the Application Security Manager

Working with device groups

Synchronizing the device group

Supported ICAP Servers

New items and fixes in this release

New in this release

Improved L7-DoS Visibility

L7-DoS Prevention Methods

Proactive Bot Defense

Accept Request

Extended CSHUI support

Scanner Manual Resolution

Violation Rating

Continue Parsing After Violations

Behavioral Machine Learning Layer 7 DDoS Detection

REST API Enhancements

System Variables

ASM Control Plane daemon cleanup

Fixes in this release

Features and fixes introduced in prior releases

New features introduced in 11.5.1

Fixes introduced in version 11.5.1

New features introduced in 11.5.0

Fixes introduced in version 11.5.0

New features introduced in 11.4.1

Fixes introduced in version 11.4.1

New features introduced in 11.4.0

Fixes introduced in version 11.4.0

New features introduced in 11.3.0

Fixes introduced in version 11.3.0

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

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

To correctly install the current version and save your database configuration and installation

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