Memory: 12 GB or more

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

Memory: 8 GB

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

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

Memory: Less than 8 GB and more than 4 GB

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

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

Memory: 4 GB or less (VE only)

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

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

vCMP memory provisioning calculations

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

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

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

Layered Policies

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

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

Proactive Bot Defense Logging and Reporting Enhancements

Client Reputation Use in Policy Builder

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

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

Compact Mode Learning Optimization

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

ASM Policy Setting Usability Improvements

JSON Support and Granularity Improvements

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

Classification of Request Content for URLs

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

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

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

Fingerprinting Improvements

Overlapping Staging for Updated Signatures

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

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

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

Automatic Server Technology Detection

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

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

Following an upgrade, Server Technologies detection is disabled.

AVR DoS Visibility and Scheduled Reports

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

ASM Proxy Log GUI Improvement

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

Advanced Exception Handling

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

Policy Enhancements

BADoS Unified Server Health Check Mechanism Based on L7 Analysis

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

BADoS DDoS Mitigation Based on Behavior Analysis and Integration with Whitelist

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

BADoS Logging and Reporting Improvement

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

BADoS Automatic Generation of Attack Request Signatures

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

ASM DoS Add Automatic Threshold Tuning to ASM DoS Protection

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

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

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

ASM DoS Heavy URL Improvements

Upgrading from version 11.x or later

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

Upgrading from versions earlier than 11.x

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

Automatic firmware upgrades

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

Upgrade warnings and notes

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

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

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

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

Exporting Logs

HTTP protocol compliance failed sub-violations

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

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

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

Layer 7

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

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

ASM cookie security

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

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

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

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

Cookie signature validation

After upgrading, the system performs the following:

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

Web scraping

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

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

Brute Force

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

DoS profiles

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

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

Logging Profiles

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

XFF configuration (ID 405312)

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

IP address whitelist

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

Security policy status after UCS installation

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

Running Application Security Manager on a vCMP system

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