User documentation for this release

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

---

Supported platforms

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

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

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

---

Configuration utility browser support

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

• Microsoft Internet Explorer 7.x, 8.x, 9.x
• Firefox 3.6.x and 9.0.x
• Chrome 16.x

---

Installation overview

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

Installation checklist

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

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

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

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

Installing the software

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

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

Post-installation tasks

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

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

Upgrading from earlier versions

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

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

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

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

• If you are upgrading from version 11.0 or 11.1, see Upgrading from version 11.0 or 11.1.
• If you are upgrading from version 10.2.x and the BIG-IP system uses the volumes disk-formatting scheme, see Upgrading from version 10.2.x if the BIG-IP system uses volumes.
• If you are upgrading from version 10.0.x or 10.1.x and the BIG-IP system uses the volumes disk-formatting scheme, see Upgrading from version 10.0.x or 10.1.x if the BIG-IP system uses volumes.
• If you are upgrading from version 10.x and the BIG-IP system uses the partitions disk-formatting scheme, see Upgrading from version 9.4.3 or later.
• If you are upgrading from version 9.4.3 or later, see Upgrading from version 9.4.3 or later.
• If you are upgrading from versions earlier than 9.4.3, see Upgrading from versions earlier than 9.4.3.

The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three to seven minutes. During the upgrade process, you see messages posted on the screen. For example, you might see a prompt asking whether to upgrade the End User Diagnostics (EUD), depending on the version you have installed. To upgrade the EUD (recommended), type yes, otherwise, type no.

Upgrading from version 11.0 or 11.1

If you are currently running version 11.0 or 11.1, use one of the following upgrade methods:

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

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

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

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

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

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

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

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

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

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

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

Upgrading from version 9.4.3 or later 9.x versions

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

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

Installation consists of the following steps:

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

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

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

Upgrading from versions earlier than 9.4.3

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

Additional upgrade information

Preserved data

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

Changes the system makes if you upgrade to version 11.2.1

If you upgrade to version 11.2.1, note the following:

• IP Address Whitelist: In version 11.2 the we unified various whitelists for Policy Builder trusted IP addresses, and anomaly whitelists (DoS Attack Prevention, Brute Force Attack Prevention, and Web Scraping Detection) into a single list. When you upgrade, these separate lists are unified to a single whitelist (called the IP Address Exceptions List).
• Ignored Entities: We store ignored file types, URLs, and flows with security policies created in version 11.2. Previously, they were associated with the Application Security Manager’s web application (known as the HTTP Class in version 11.1).
  • Upon upgrade, ignored entities and URLs are automatically transferred to the active security policy, but ignored flows are not upgraded.
  • You can import and export ignored entities configured in version 11.2.1 by importing and exporting the security policy to which they belong. However, since ignored entities created before version 11.2 are not stored with their security policies, they cannot be exported or imported.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Security policy status after UCS installation

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

Running Application Security Manager on a vCMP system

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

---

Changing the Resource Provisioning level of the Application Security Manager

Important: This section is not relevant if you are using the standalone version of the Application Security Manager.

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

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

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

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

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

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

---

Additional configuration information

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

---

New items and fixes in this release

This release includes the following new items and fixes.

New in this release

There are no new features in this release.

Fixes in this release

This release includes the following fixes.

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	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.
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 391845	The internal daemon for downloading the IP Intelligence database (iprepd) was fixed in order to avoid core dumps of other daemons (like merged) that read its status table in the shared memory segment (tmstat).
ID 392240	We fixed an issue that sometimes caused the Enforcer to core.
ID 393721	We fixed a bug in the chunked request parser.
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 11.2.0 HF 1 and then perform a signature update.

Features and fixes introduced in prior releases

New features introduced in 11.2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

This feature does not decrease system performance.

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

The following actions are available from the Configuration utility:

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

The following actions are available from the command line:

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

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

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

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

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

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

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

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

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

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

You can configure the system to:

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

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

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

Note: This release does not support IPv6.

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

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

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

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

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

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

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

Fixes introduced in version 11.2.0

This release includes the following fixes from version 11.2.0.

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

New features introduced in 11.1.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We removed the following System Variables:

• MysqlBindAddressChangeNeeded
• OverviewEnabled

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

Fixes introduced in version 11.1.0

This release includes the following fixes from version 11.1.0.

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

---

New features introduced in 11.0.0

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

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

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

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

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

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

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

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

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

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

Along with this new feature are two new violations:

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

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

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

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

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

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

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

1. Enable at least one of the Alarm or Block check boxes of the Virus Detected violation setting, found on the Blocking Policy screen (navigate to Application Security > Policy > Blocking > Settings).
2. Configure an anti-virus protection server by configuring ASM to act as an Internet Content Adaptation Protocol (ICAP) client. Navigate to Application Security > Options > Anti-Virus Protection.
3. Navigate to Application Security > Options > Advanced Configuration > System Variables and ensure that the values of the internal parameters icap_uri and virus_header_name correspond to the ICAP server’s settings.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

These are the new parameters:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The following parameters are available in the Configuration utility:

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

  Note: When enabling bypass_upon_asm_down, we recommend you set running to disabled in the "daemon-ha bd" section of /config/daemon.conf and then load the configuration using tmsh.

• 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 add and change the default value of this parameter, open the command line, and use the add_del_internal script, in the following format:
/usr/share/ts/bin/add_del_internal add <param_name> <param_value>.

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

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

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

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

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

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

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

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

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

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

Fixes introduced in version 11.0.0

This release includes the following fixes from version 11.0.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Known issues

The following items are known issues in the current release.

Installation may create a UCS file without database configuration (ID 207422, ID 211521, formerly CR120190, formerly CR127965)
If you try to install this version by running the command image2disk --nomoveconfig, or liveinstall with the database variable LiveInstall.MoveConfig set to disabled, and you have WebAccelerator, Application Security Manager, or Protocol Security Module 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 Module 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.

Merging and logon page configuration (ID 223149, formerly CR127912)
When you are merging two security policies, the logon page settings you configured are not merged into the new security policy.

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.

Getting the self IP address to connect to the active unit in a redundant system (ID 249420, formerly CR48941)
When you configure the Application Security Manager as a redundant system, replication does not work if you have multiple self IP addresses configured on the failover address network. To work around this issue, see Getting the self IP address to connect to the active unit in a redundant system in the Workarounds for known issues section of this release note.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XML profile properties in merged security policies (ID 309642, formerly CR108844)
When merging two security policies where each security policy has its own XML profile, the merged security policy has the XML profile configuration of only the first security policy.

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

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

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

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

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

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

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.

User roles and iControl (ID 332396, formerly CR90671)
iControl^® does not support any user roles other than Administrator.

Merging security policies with different case sensitivity settings (ID 338657)
If you merge two security policies, one configured as case-sensitive and the other as not case-sensitive, the merged security policy inherits the characteristics of the primary security policy. As a result, you can have a merged security policy, configured as not case-sensitive, that includes uppercase and lowercase entities.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From the Configuration utility:

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

From the command line:

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

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

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

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

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

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

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

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

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

Logging of the Illegal meta character violation (ID 341789)
For all entities which are subject to meta character checks, the system incorrectly logs the Illegal meta character violation when the meta character is explicitly allowed in the security policy.

Viewing ASM Dashboard from secondary slot (ID 350798)
In the VIPRION platform, sometimes it is possible to view the ASM Dashboard screen from the Configuration utility of the secondary slot, and sometimes an error window will popup.

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

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

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

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

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

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

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

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

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

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

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

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

Content profiles and policy merge. (ID 377298)
Content profiles are not supported by policy merge.

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

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

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

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

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

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.

Chinese gb18030 encoding language (ID 381386)
If you set the Application Language to Chinese gb18030, the Unknown encoding gb18030 error message appears in the httpd_errors log, and the system does not correctly display the characters in the Application Security Manager Configuration utility, where there is a long string.

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

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

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

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

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

Enabling the IP Intelligence feature on a multiblade system (ID 384142)
After initially updating the IP Intelligence database, the database is available on the primary blade but it might take a few seconds for the database to be copied to the secondary blade. During these seconds, since the database does not exist on the secondary blade, the system may log error messages in the LTM log.

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.

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

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

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

Upgrading devices in an ASM device group (ID 393468)
You cannot perform configuration synchronization between two devices within the same device group if the devices have different BIG-IP versions. Therefore, if you upgrade one of the devices to a newer version, you must upgrade the remaining devices in that device group.

Standalone ASM: Deleting HTTP Class associated with active security policy (ID 392719)
If you are running standalone ASM: If you delete the HTTP Class associated with an active security policy, the security policy is not moved to Recycle Bin, and the deleted HTTP Class is displayed in the ASM Configuration utility as existing.

Changing the level of a wildcard parameter (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, causes subsequent Apply Policy attempts to fail. To work around this issue, after changing the wildcard order, navigate to Parameters > Wildcards Order and click Save.

Scanner vulnerability file with non-ASCII (UTF-8) parameter (ID 395613)
A scanner vulnerability file with a non-ASCII parameter name cannot be imported. Instead, the following error message is reported: "Could not import list of VULNS_LIST_LINK; Error: Vulnerability XML file is invalid (Wide character in subroutine entry)".

Invalidating Web Acceleration cache (ID 395946)
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, the WebAccelerator cache is not automatically invalidated. Note that the Web Acceleration profile must have a WebAccelerator application enabled. To work around this issue, you must apply the ASM security policy.

BIG-IP ASM Configuration Guide error (ID 397605)
Throughout Appendix G, Remote Logging Formats, web_application_name="%s" should be http_class_name="%s", web_application_name should be http_class_name, and Name of the web application should be Name of the HTTP Class.

---

Workarounds for known issues

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

Getting the self IP address to connect to the active unit in a redundant system (ID 249420, formerly CR48941)

When configuring a redundant system, and a particular VLAN has a static IP address and one or more floating IP addresses, use the static IP address when configuring the redundancy settings.

If you have several static IP addresses configured on several VLANs, one per VLAN, configure a static route to the peer IP address, and specify that the static route uses a VLAN as its resource. In the Resource setting for the static route, select the VLAN that contains the self-IP address that you have configured as the primary failover address.

If you have several static IP addresses configured on the same VLAN, replication does not work with this configuration, and no known workaround currently exists.

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

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

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

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

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

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

To manually synchronize the virtual server configuration to the device group, perform the following actions:

1. Go to Device Management > Device Group.
2. Click the required Device group name.
3. Click the ConfigSync tab.
4. Click the Synchronize to group button.

---

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.

---

Copyright  2012, F5 Networks, Inc., Seattle, Washington. All rights reserved. 

For a current list of F5’s trademarks and service marks, click here. All other product and company names herein may be trademarks of their respective owners.