BIG-IP platform considerations

These platforms support various licensable combinations of product modules.

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

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

• PEM and CGNAT supported platforms
  • VIPRION B2150, B2250, B4300, B4340N, B4450N
  • BIG-IP 5x00v(s), 7x00v(s), 10x00v(s)
  • PEM for BIG-IP iSeries: i5800, i7800, i10800, i11800, i15800
  • CGNAT for BIG-IP iSeries: i2x00, i4x00, i5x00, i7x00, i10x00, i11x00, i15x00
  • BIG-IP Virtual Edition (VE) (Not including Amazon Web Service Virtual Edition) (3 GB, 10 GB production and combination lab models)
  • PEM is not supported on vCMP guests.
  • PEM is not supported on 8 GB platforms.

• BIG-IP i850 platform support
  • The BIG-IP i850 platform supports Local Traffic Manager (LTM) only, and no other modules.

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 and 2200s 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) and Application Visibility and Reporting (AVR) 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.) Beginning in v14.x, 8 GB of memory is the very bare minimum to get three modules provisioned, suitable for a lab environment or very light production traffic, especially with a memory-intensive module such as AVR.

• No more than three modules (not including AAM or AVR) 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 and vCMP only)

The following guidelines apply to VE and vCMP guests provisioned with 4 GB or less of memory.

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

VIPRION and vCMP caching and deduplication requirements

Application Acceleration Manager (AAM) supports the following functionality when configuring vCMP and VIPRION platforms.

• AAM does not support disk-based caching functionality on vCMP platforms. AAM requires memory-based caching when configuring it to run on vCMP platforms.
• AAM supports disk-based caching functionality on VIPRION chassis or blades.
• AAM does not support deduplication functionality on vCMP platforms, or VIPRION chassis or blades.

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.

Software Support Lifecycle change to 4 years on Long-Term Supported versions (x.1 releases)

F5 is changing the standard support phase of the BIG-IP software lifecycle for Long-Term Stability (LTS) releases from five (5) years to four (4) years effective with the release of BIG-IP v16.1.0. This means that EoSD and EoTS dates will now be reached 4 years after individual versions are released, with this change remaining in effect for all subsequent BIG-IP LTS releases. As F5 shifts to deliver more software-based solutions this change is intended to maintain alignment with the industry, while also helping facilitate migration of customers BIG-IP's to newer versions.

You can find more information about the updated software lifecycle here:

K8986: F5 software lifecycle policy

K5903: BIG-IP software support policy

Message Router Rate Limiting

The Message Router (MR) rate limiting helps service providers to mitigate the congestion. The rate limiting is an enhancement to the Message Routing Framework (MRF) allowing actions to be taken on a message-by-message basis to mitigate congestion.

Actions are taken on the Ingress and Egress based on the protocol agnostic profile attached to virtual and transport configurations. The rate limiting profile will set the Ingress and Egress thresholds of messages per second and/or bytes per second that can pass through the attached virtual or transport configuration on a connection-by-connection basis.

The message routing filter accompanying the profile will monitor connections for when 50%, 75%, 90%, or 100% of the threshold is reached and performs one of four user configurable actions. The actions are none, drop, return, and delay that can be performed on 25%, 50%, or 100% of messages.

Transaction Data Record (TDR)

The Transaction Data Record (TDR) is used to record the Diameter, SIP, or HTTP protocol message field values configured or provisioned by the customer. This feature uses the BIG-IP High Speed Logging (HSL) framework to log the TDR.

This release also includes Diameter Dictionary enhancement for Diameter protocol. This enhancement allows customers to provision the diameter avp-names in BIG-IP diameter specific configurations, for example, Diameter Session profile and TDR-Diameter.

IPOther TTL options

This release includes a new feature to support TTL options on IPOther profile. This feature provides more flexible deployment options. This is available on both the modes IPv4 and IPv6.

Self IP address for L2 virtual wire VLAN groups

Currently self IP address can be associated with VLANs, VLAN groups, or tunnels, but not supported for virtual wire VLANs or VLAN groups.

This feature will allow configuration of self IP for virtual wire VLAN groups. This is allowed for untagged or VLAN specific tag interfaces.

This feature will allow customers to communicate with BIG-IP over virtual wire interfaces and support both IPv4 and IPv6 addresses.

DAG using TEID hashing for GTP tunnels in Hardware

A new DAG is added to take GTP-U tunnel IDs (TEID) into account for calculating the hash value and distributing the packets on different TMMs. Due to this, various packets from the same UDP flow will be mapped onto different TMMs and will have TEID to TMM affinity.

Dynamic end points for IPsec tunnel

The dynamic end points for IP Security (IPsec) tunnel feature enables BIG-IP to establish an IPsec tunnel with trusted unknown dynamic IP addresses or devices, without configuring remote IP addresses statically in BIG-IP configuration. The BIG-IP can establish IPsec IKEv2 tunnels with unknown or dynamic endpoints with or without NAT environment.

DNS over HTTPS

The DNS over HTTPS (DoH) feature enables BIG-IP to receive and respond to DNS queries over HTTP using HTTPS URIs. The BIG-IP supports both Server and Proxy modes.

Host TTL for DNS resolver

Currently, unbound uses default host-ttl (900) and it cannot be customized. A new attribute, nameserver-ttl is added to net.dns-resolver and ltm.dns.cache.resolver and can be configured through TMSH. The default value for nameserver-ttl is 900 seconds.

SNI support when using HTTPs monitor in GTM

With this release, the GTM HTTPS monitors allow specification of the SNI value to use when monitoring a resource.

Support to stop monitoring disabled GSLB Pool members

The GSLB will not monitor disabled pool members when the pool member configuration includes a monitor and the Monitor Disabled Objects option is set to No.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

Policy Layout User Experience Improvements

GraphQL Support

Advanced WAF license is required. GraphQL is a new API technology which is gaining traction in the market and, like any other API, there are attack vectors to exploit it. The new header-based content profile and policy template intercept and protect GraphQL queries, mutations and subscriptions without having to specify a GraphQL schema. Advanced WAF provides support for GraphQL traffic by supporting the ingestion of GraphQL queries over HTTP traffic, parsing the query values and applying attack signatures accordingly. Advanced WAF is able to parse a request and understand what is the actual GraphQL query data. Without correct parsing, the full request would be examined, leading to false positives.

You can configure a GraphQL Profile and new Content Profile violations were added:

You can select a dedicated GraphQL security policy template and configure a GraphQL endpoint using GUI, REST, and declarative interfaces. The security policy can be exported and imported in declarative format.

As with other violations, traffic learning is supported on GraphQL violations.

You can configure the GraphQL blocking response page to display when a GraphQL violation is raised.

Minimal Security Template

Declarative API

The size of a declarative policy is set by the system variable max_json_policy_size. The default allowed size of a declarative policy is 1000 KB (1 MB) including all the externally referenced files in it. The maximum allowed value is 100 MB. The policy size is checked during an upload of a JSON policy file. If, at any stage, the size of the policy uploaded is greater than the value for system variable max_json_policy_size we will throw an error and the error is also visible in the log /var/log/ts/asm_config_server.pl. If the JSON policy file or other references within have any JSON errors, it displays the error Failed to parse JSON + the exact error.

Support External Reference Basic Authentication

Example: Username and password in the URI

You can specify username and password as part of URI. If the password contains special characters which are not supported in URI, we need to pass them as url encoded values as:

'@' => %40

'%' => %25

If the password is pass@123 then user has to pass it as pass%40123.

Example: Passing token in the query string

In this method you can specify the token obtained to access a repository as query parameter as token=tokenobtained. In this sample JSON policy we specified a token to access a file on repo.

Example: Specifying credentials as separate fields in the declarative policy

In this method, you have to specify credentials as separate fields and supply a password as a base64 encoded value instead of a plain password. In this example, you specify the username and password as separate fields in the declarative policy.

You can specify external references using $ref. This is applicable for all three ways of authentication.

Use External References for Base Template

A policy template to be referenced and shared between multiple policies. For example, the template can reside on a remote server as can be seen in the following example. The template itself can be a user-defined JSON policy or any other XML/Binary templates.

The template link in the policy above can be changed to the following templates (XML/Binary):

The import will fail if the referenced template is referencing another template, as in the following example:

Export Policy to Declarative JSON Format

In the UI, when exporting the security policy as a declarative (JSON) policy file, you can further choose to export as a Template-Base policy or a Full policy. If you choose Template-Based, you can select the new base template from the drop-down menu. The template-based exported JSON file contains only the delta between the original and selected new base template. A full export file contains the full configuration of the policy. If a policy has Learning Suggestions which have not been accepted, you can choose to export them with the policy.

Note: If you select Include Learning Suggestions for either export option, the learning suggestions will be considered as Accepted when the policy is imported, even if they are not accepted in the original policy before Export.

The tmsh options when exporting a declarative policy:

• Full Export to JSON - F5 Template - (without different base template): tmsh save asm policy policy_name min-json-file policy_file_name
• Compact Export to JSON - F5 Template: tmsh save asm policy policy_name min-json-file policy_file_name
• Compact Export to JSON - user selected template: tmsh save asm policy policy_name min-json-file policy_file_name policy-template POLICY_TEMPLATE_FUNDAMENTAL
• Export to JSON - include suggestions: tmsh save asm policy policy_name json-file policy_file_name include-suggestions or tmsh save asm policy policy_name min-json-file policy_file_name include-suggestions

The REST options when exporting a declarative policy:

Compact Export to JSON - F5 Template

• Minimum without template: restcurl -u admin:admin /mgmt/tm/asm/tasks/export-policy -X POST -d '{"format": "json", "filename":"asm_policy.json", "policyReference": {"link": "https://localhost/mgmt/tm/asm/policies/t2TxxpOjj4AjQWOcEVyBaA"}, "minimal": true}'
• Minimum with selected template: restcurl -u admin:admin /mgmt/tm/asm/tasks/export-policy -X POST -d '{"format": "json", "filename":"asm_policy.json", "policyReference": {"link": "https://localhost/mgmt/tm/asm/policies/t2TxxpOjj4AjQWOcEVyBaA"}, "minimal": true, "policyTemplateReference": {"link": "https://localhost/mgmt/tm/asm/policy-templates/_pS_k4kzqmIqI3Zua6y4-w"}}'

Compact Export to JSON - export suggestions

restcurl -u admin:admin /mgmt/tm/asm/tasks/export-policy -X POST -d '{"format": "json", "filename":"asm_policy.json", "policyReference": {"link": "https://localhost/mgmt/tm/asm/policies/t2TxxpOjj4AjQWOcEVyBaA"}, "minimal": true, "exportSuggestions": true}'

API Protection: Multi- Type Serialization Support

To support Open API 3.0, the following API support has been added.

Array

Path parameters

Parameter Serialization

Path parameters

Note: style=simple, explode=false is the default method, meaning that it will be assumed if no serialization is specified.

F5 Leaked Credential Check

F5 Leaked Credential Check is an add-on threat intelligence subscription for F5 Advanced WAF. It prevents credential-based attacks and abuse by delivering an automated detection and mitigation of leaked/breached/fraudulent credentials. Customers can also take several actions if a suspicious login is used, including alerts, blocking, redirection, and responding.

HTTP Multipart Batched Request Parsing Support

BIG-IP ASM/Advanced WAF can parse HTTP multipart batched requests to apply the signatures to the right part of batched requests.

Mitigating Server-Side Request Forgery

In Server-Side Request Forgery (SSRF) attack, the attacker takes advantage of parameters that contain dynamic IP addresses or domain names which the server application invokes. Rather than letting the server access the legitimate destination, the attacker crafts a request that populates the parameter with an address of a server or file in the server that it is not allowed to access.

To mitigate SSRF attack, the parameter which carries the IP addresses or host names must be configured as a parameter of datatype URI.

The F5 Application Security Manager (ASM) allows the user to configure the disallowed domain names and IP addresses such that if any of such URI parameter contains configured entries, then the ASM will block the traffic and raise a violation.

Automap support in FWNAT

This release includes new functionality enhancements with Firewall Network Address Translation (FWNAT). Users can select Automap as one of the options for source translation, which will pick the available self IP as the translated source IP.

Download and process IPv6 address database from Brightcloud

The IPREP daemon periodically pulls data from WebRoot or BrightCloud (a third-party IP reputation service) using the libIsisSdk.so SDK and posts this data as a binary file in /var/IpRep directory.

The daemon ensures that the file is updated atomically by creating a temporary file and renaming the temporary file to override the main file. The IPREP daemon then notifies the clients (TMM) about the status of the binary file through MCP. The TMM reads the binary file using libIpRep.so IPREP library.

Currently, the BIG-IP daemon (IPREPD) responsible for this download can connect to Brightcloud only over the IPV4 management network. From this release, the BIG-IP daemon supports IPv6 addresses in the Brightcloud database to perform IP reputation.

Access Guided Configuration Updates

Access Guided Configuration for BIG-IP Access Policy Manager provides simple, workflow-driven configuration templates for common use case scenarios. Using the templates, you can configure policies to implement complex scenarios such as Zero Trust-Identity Aware Proxy, API Protection, Microsoft Integration, and Federation Single Sign On more easily.

API protection and automation

Access Guided Configuration 8.0 includes enhancements for BIG-IP release 16.1. It introduces Guided Configuration API v1.0, giving you the ability to use REST APIs to deploy and manage template-driven configurations on the BIG-IP system easily. You can create, update, or delete configurations and their associated objects for API Protection and Azure AD Application templates.

In the API Protection Proxy template, you have the flexibility to update your configuration by reimporting the OpenAPI Swagger file (2.0 or 3.0 file) multiple times as required.

Azure AD Application enhancements

The Azure AD Application now creates a per-request policy on configuration deployment, enabling authentication and access checks on an ongoing basis. The template now has support for Oracle EBS and JD Edwards applications. You can also select Azure Conditional Access policies applied to Cloud apps to apply them to your application.

Microsoft Identity Platform v2.0 and Azure B2C endpoints support

Access Guided Configurations now support Microsoft Identity Platform 2.0 and Azure B2C endpoints.

Refer to the Release Notes for Guided Configuration 8.0 for additional enhancements details.

AES-GCM encryption protocol support

BIG-IP APM as SAML Service Provider can now successfully decrypt an assertion that is encrypted using the AES GCM protocol family: AES 128 GCM, AES 192 GCM, and AES 256 GCM.

Azure B2C Endpoints Support

Microsoft has depreciated the login.microsoftonline.com redirect URL in Azure AD B2C. As new tenants will not accept requests from login.microsoftonline, the Azure B2C template in Access > Federation > OAuth Client / Resource Server > Provider now supports the new b2clogin.com redirect URL.

Duo MFA support using iRule

Duo has recently added support for Universal Prompt that uses Open ID Connect (OIDC) protocol to provide two-factor authentication. For integration with APM, Duo requires a custom payload to be sent in the JWT. The APM iRules create this payload to address this challenge and saves them in session variables for authorization and token request. This integration procedure is supported on BIG-IP versions 13.1, 14.1x, 15.1x, and 16.x. Refer to the APM Configuration to Support Duo MFA using iRule guide for details on the configuration steps required on APM to enable Duo MFA.

Dynamic OAuth client agent based on session variable

BIG-IP APM enhances scalability and ease of OAuth deployments by supporting the creation of dynamic agents based on session variables. The OAuth client now enables you to use session variables to select the OAuth server dynamically to which the client directs requests. Using the dynamic server feature, you can provision a single authorization server to multiple clients in a user group or multiple authorization servers to various clients using the same session variable.

Dynamic split tunneling using address space

BIG-IP APM now provides the ability to create dynamic address space that contains IPv4, IPv6, and DNS names for Zoom and Office 365 applications by using their auto-discovery URL. You can also create custom address space objects by manually adding a static list of addresses for SaaS applications such as WebEx. This feature allows associating the address space to exclude traffic in the network access tunnels automatically. The traffic passes directly to the public internet instead of being routed over the tunnel.

EcmaScript 6/7 supported in Portal Access

BIG-IP APM Portal Access now supports ES6/ES7.

Extracting group membership from Kerberos tickets

BIG-IP APM Visual Policy Editor (VPE) now has the capability in Kerberos Auth agent to pull user group membership SIDs from Kerberos authentication tickets. VPE also has a new AD Group SID Resolver agent that allows building Active Directory group cache and resolving group SIDs to group names. This feature would negate the need to query multiple active directory domains for an exhaustive user group membership list.

Microsoft identity platform v2.0 support

BIG-IP APM now supports Microsoft Identity Platform 2.0 endpoints. You can use the Microsoft Identity Platform 2.0 custom template in Access > Federation > OAuth Client / Resource Server > Provider to configure and discover Azure 2.0 endpoints as an Identity Provider.

If you are configuring an Azure provider configuration, F5 recommends using Microsoft Identity Platform 2.0 to configure your provider configuration. Refer to the Microsoft documentation to know the main differences between the endpoints and the existing limitations for the Microsoft identity platform.

Okta MFA using Factors API for Standard customization

BIG-IP APM now integrates with the Okta Factors API to enroll and verify factors for multifactor authentication (MFA) for both modern and standard customization. With this support, you can add the Okta MFA agent to an existing policy with standard customization. You can manage authorization and access to applications and resources using Okta Verify (TOTP/Push) and YubiKey OTP factors. End-users have the option to enroll additional supported factors after successful authentication. For details on configuration and factor enrollment, refer to BIG-IP APM: Implementing Zero Trust with Per-Request Policies.

Swagger 3.0 Support

API Protection now supports importing OpenAPI 3.0 specifications. You have the flexibility to create your API Protection profile by uploading an OpenAPI specification 2.0 or an OpenAPI specification 3.0 file.

VMWare Horizon View 7.13 and 8.0 Support

BIG-IP APM is tested and is compatible with VMWare Horizon View 7.13 and 8.0. Other BIG-IP versions tested for VMware support are 11.6.5, 12.1.6, 13.1.3, 14.1.4, 15.1.2, and 16.0.1.

Important: We only test the latest maintenance releases of BIG-IP and update their corresponding compatibility matrices. To find the latest maintenance release of BIG-IP, refer to the https://support.f5.com/csp/article/K5903 article. You should then refer to the compatibility matrix of that version for an updated list of supported software.

No new features

There are no new features specific to this product area.

No new features

There are no new features specific to this product area.

Video Traffic Management - ECN detection

When congestion is experienced in the network, the ECN bits are set to value three (0b11) in the IP header. With this feature enabled and if flow has ECN bits set to three, then BIG-IP applies the actions associated with the PEM policy.

Enhancements to PEM HSL logs

No new features

There are no new features specific to this product area.

Sample installation command

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

tmsh install sys software image BIGIP-13.0.0.0.0.1645.iso volume HD1.3

Notes

The upgrade process does not update Tcl scripts (such as iRules) in the configuration. This might cause issues when iRule syntax changes between releases. After upgrading, you might need to modify iRules to reflect any changes in iRule syntax.

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 K14381: 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 K14409: 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

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

In version 13.1 the session-based and dynamic brute force protections are discontinued and replaced with source-based brute force protection. When upgrading:

• Source-based mitigation will be set to Alarm and CAPTCHA for Username, Device IP and Source ID.
• Dynamic mitigation will be set to Alarm and CAPTCHA.
• Client Side Integrity Bypass Mitigation will be set to Alarm and CAPTCHA.
• CAPTCHA Bypass Mitigation will be set to Alarm and CAPTCHA.
• Detection and prevention duration will be derived from previous values.
• Enforcement of both the source-based and distributed brute force protections depends on the Blocking settings of the Brute Force: Maximum login attempts are exceeded violation.
• The Learning flag for Brute Force: Maximum login attempts are exceeded violation is discontinued.
• The Unlimited value for Prevention Duration is discontinued.

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.