BIG-IP platform considerations

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

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

• vCMP supported platforms
  • VIPRION B2100, 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 B2100, 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 may be provisioned on the VIPRION B2100, but it is not recommended for production, only for evaluation. Use the B4300/B4340N or another blade instead.
  • PEM is not supported on vCMP guests.
  • PEM is not supported on 8 GB platforms.

• BIG-IP 800 and i850 platform support
  • The BIG-IP 800 and i850 platforms support 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, 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) 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 and 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.

VE considerations

This version of the software is supported in the following configurations. For a list of VE hypervisor support, see the Virtual Edition and Supported Hypervisors Matrix.

Memory: 12 GB or more

All licensable module-combinations may be run on BIG-IP Virtual Edition (VE) guests provisioned with 12 GB or more of memory.

Memory: 8 GB

The following guidelines apply to VE guests configured with 8 GB of memory.

• No more than three modules should be provisioned together.

Memory: Less than 8 GB and more than 4 GB

The following guidelines apply to VE guests provisioned with less than 8 GB and more than 4 GB of memory.

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

Memory: 4 GB or less

The following guidelines apply to VE 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

Support for session persistence in HTTP/2 full-proxy deployments

This release supports additional session persistence types for HTTP/2 full-proxy deployments.

Diameter Dynamic Routing

This release include Diameter dynamic routing, a complementary solution to persistence, which you can use to forward messages to the same host.

Prioritization of ICMP health monitor traffic

You can now configure the BIG-IP system to prioritize ICMP and ICMP Gateway health-monitor traffic over all other types of traffic. This feature minimizes the chance that ICMP health-monitor traffic is dropped when traffic congestion occurs at a BIG-IP switch, at a high-speed bridge, or on a TMM instance.

HTTP chunked transfer encoding

The HTTP Request Chunking and Response Chunking profile settings have been enhanced to allow the profile and other internal functions to better control the chunking or unchunking of a payload as it transitions through the system. HTTP chunked transfer encoding is controlled within the HTTP profile. Chunking in the HTTP profile has a list of three options which directly inherits Unchunk and Rechunk, deprecating Preserve and Selective and replacing them with a new Sustain option. Sustain tries to preserve existing transfer encoding unless a hudfilter makes it irreversible.

Client Certificate Constrained Delegation Support (C3D)

Expanded functionality for Client Certificate Constrained Delegation Support (C3D).

Fallback pool for policies

You can now select 'fallback-pool' along with primary 'pool' using LTM policy. If primary pool present in the forward action is unavailable, then LTM policy will forward traffic to the fallback pool. LTM policy forwards traffic only if primary 'pool' within that action is not available. You must specify 'pool' along with 'fallback-pool' and both cannot have same pool name.

Message Routing Framework.

The Message Routing Framework (MRF) is an extension to that supports routing of messages between connections. MRF is a protocol-independent framework that is used to build protocol-specific routing systems. Currently three protocol implementation of MRF are supported by the BIG-IPsystem: DIAMETER, SIP and Generic Message.

The following five items are the enhancements of MRF in ths version:.

• Diameter Dynamic Routing: This release include Diameter dynamic routing, a complementary solution to persistence, which you can use to forward messages to the same host.
• Enhanced Diameter Statistics: This release includes Diameter statistics aggregated by peer and pool level.
• Diameter Loop Detection: This release includes Diameter loop detection to support proper routing of Diameter messages, ensuring that a message is not endlessly routed between two Diameter agents.
• MRF: Diameter support for Tcl Context per Message: This release includes a feature enhancement to MRF protocols by providing every ingress and egress message with its own private Tcl execution context, thus limiting the scope of iRule variables.
• MRF Per-Peer Statistics: This release supports MRF per-peer statistics. Service providers require the ability to monitor the health of clients and servers by observing the traffic between the BIG-IP system and other devices in the network. You can now observe traffic to and from a connected device using statistics.

CGNAT: Port Block Allocation periodic block refresh logs

This release includes a new logging option that logs Port Block Allocation (PBA) block periodically with a configurable refresh time.

CGNAT: Provide statistics to count numbers of subscribers and active translation addresses

This release includes new statistics to count the number of active subscribers, the peak active subscribers, number of translation addresses in use, and the number of active connections per translation prefix

Enhanced Diameter Statistics

This release includes Diameter statistics aggregated by peer and pool level.

Diameter Loop Detection

This release includes Diameter loop detection to support proper routing of Diameter messages, ensuring that a message is not endlessly routed between two Diameter agents.

MRF: Diameter support for Tcl Context per Message

This release includes a feature enhancement to MRF protocols by providing every ingress and egress message with its own private Tcl execution context, thus limiting the scope of iRule variables.

iRule Session and Table support in HTTP/2

The iRule 'session' and 'table' commands can now be used in iRules assigned to Virtual Servers configured with the HTTP/2 and httprouter profiles (i.e., HTTP/2 full proxy mode). These commands previously did not work in BIG-IP version 14.1.0 when HTTP/2 full proxy mode was introduced. These iRule commands have already been documented on DevCentral.

Ramcache Support for HTTP/2

The 'webacceleration' profile can now be assigned to Virtual Servers configured with the HTTP/2 and httprouter profiles (i.e., HTTP/2 full proxy mode). In other words, RAM cache is now working with HTTP/2 full proxy virtual servers that use the MRF router. This is a phase 1 implementation that gets HTTP/1.1 semantics working, but the profile does not cache HTTP/2 PUSH responses.

Remote CA Certificate Generation CA API support

Support for RSA PSS Padding in Cavium HSM Cards

This feature updates our support of Cavium Nitrox III FIPS HSMs (N3FIPS) to allow generating RSA PSS signature using private keys stored in Cavium FIPS HSM. This is required for support of TLS 1.3 support.

MRF Per-Peer Statistics

This release supports Message Routing Framework (MRF per-peer statistics. Service providers require the ability to monitor the health of clients and servers by observing the traffic between the BIG-IP system and other devices in the network. You can now observe traffic to and from a connected device using statistics.

tcpdump support for encrypted traffic

This release adds handling of encrypted traffic in tcpdump operations

Logging of Login Attempts

This release provides the ability to log login attempts.

OWASP Compliance Dashboard

AWAF feature. The OWASP Compliance Dashboard details the coverage of each security policy for the top 10 most critical web application security risks as well as the changes needed to meet OWASP compliance. Using the dashboard, you can quickly improve security risk coverage and perform security policy configuration changes.

Public APIs Protection

AWAF feature. Customer-specific OpenAPI files, in Swagger format, can be loaded to the platform to automatically create a security policy attached to a specified virtual server.

HTTP Header Sequence Behavioral Metric

Certain bots spoof legitimate browsers by attempting to copy browser requests. These copy attempts are inaccurate and give disorganized HTTP header sequences. The HTTP header sequence can be used as a signature metric in distinguishing between real browsers and Bad Actor bots that have inaccurately copied HTTP browser request headers.

DoS-L7 Traffic Passive Monitoring via Switched Port Analyzer

This feature is now production ready.

HTTP/2 Support

ASM Security Policies, DoS L7 and Bot Defense support HTTP/2 over SSL/TLS on both the client and server sides, without having to translate the client HTTP/2 traffic to HTTP/1.1 on the server-side. Server pushed requests are ignored, meaning that they are not inspected or enforced. Log data includes an HTTP Version field but server pushed requests are not logged or counted in suspicious traffic statistics.

Failed Challenge Logging

Challenge failures are now logged in the event logs for Application Security and Bot Defense. Remote logging is available for Bot Defense in the field challenge_failure_reason.

User JSON Schema

A JSON schema for user REST endpoints can be uploaded to a JSON profile. The schema is validated when uploaded and any violations are noted. After a JSON schema is selected, the Parse Parameters setting is disabled because the policy stops using any configured policy parameters and begins using the JSON parameters.

API Security

Guided Configuration. API calls originating from enterprise, partner, and consumer applications that access cloud and on-premise resources require strong authentication and identity mediation. You can use Guided Configuration in ASM to configure API Security to protect API calls.

The API Protection Dashboard displays API server health including security events that were flagged, such as web application attacks, bad source IP addresses, and malicious transactions. You can use the dashboard for troubleshooting API Security.

Guided Configuration

Guided Configuration 5.0 includes enhancements for BIG-IP release 15.0. Guided Configuration for BIG-IP Access Policy Manager (APM) provides simple, workflow-driven configuration templates for common use case scenarios. Using the templates, you can create per-session and per-request policies to implement complex scenarios such as Zero Trust (Identity Aware Proxy), API Protection, and Federation Single Sign On more easily. Later, you can edit the policies in the Guided Configuration interface or using the traditional BIG-IP interface. Refer to the Release Notes for Guided Configuration 5.0 for details on the enhancements and how to upgrade to the latest Use Case Packs.

API Protection

Access Policy Manager lets you configure an API protection proxy for securing API calls. In this release, you can configure rate limiting thresholds, control traffic spikes, and use a whitelist and blacklist to allow or restrict specific network traffic. Configuration is simplified using the Guided Configuration for API Protection. The API Protection Proxy template is provided in the Guided Configuration ( Access > Guided Configuration ). You can also use the Access menus to implement API protection use cases.

API Protection Dashboard

You can use the API protection dashboard for troubleshooting potential problems on your system. If using APM only, you can review the total number of requests, API server errors, rejections at the BIG-IP system (proxy errors), and determine the response time range for each API protection profile. If using AdvWAF (ASM provisioned) in addition, the dashboard also displays API server health including security events that were flagged, such as web application attacks, bad source IP addresses, and malicious transactions.

Enhancements for Step-Up Authentication and Zero Trust

To make it easier to trust no one, many agents previously available only in per-session policies are now available in per-request policies. These agents allow you to perform additional forms of step-up authentication on a per-request basis. A new Assign Credentials agent was also added to per-request policies. You use these agents in a subroutine in a per-request policy to protect each request.

Refer to BIG-IP APM: Implementing Zero Trust with Per-Request Policies on support.f5.com for per-request policy use cases.

Support for device posture checks

APM now supports device posture checks on macOS or Windows clients on a per-request basis. You implement device posture checks in a per-request policy by using a Client Information agent followed by a subroutine with one or more client check agents.

You can continuously check the state of the following:

• Antivirus
• Endpoint State
• Firewall
• Hard Disk Encryption
• Patch Management
• Public File Sharing
• System Health Check

Continuous client checks require F5 Access Guard and a browser extension.

Customizable remediation for failed device posture checks

APM now provides a customizable remediation page for requests denied as a result of a failed device posture check. The Reject Ending in a per-request policy can display messages or URLs that help to resolve the device posture issue. New error codes are also added.

F5 Access Guard

F5 Access Guard is a new set of client software tools designed to help administrators validate the security posture of incoming web connections from remote desktop clients. F5 Access Guard allows real-time posture information to be inspected with per-request policy subroutines on BIG-IP Access Policy Manager. F5 Access Guard generates posture information asynchronously and transparently transmits it to chosen APM server endpoints using special HTTP headers. Refer to the Release Notes for F5 Access Guard 1.0 for details.

Sharing of credentials across subroutines

Subroutines now include session variables, which are used to save authenticated credentials. When a user is authenticated in one subroutine, you can configure a subsequent subroutine to use the saved credentials for authentication. To share a saved credential between subroutines, configure the session variables in the subroutine to be the same as the session variables configured in the Assign Credential agent. Be sure to position the Assign Credential agent so it is located before the subroutine in the per-request policy.

SSLO authentication as transparent proxy

APM now supports authentication offload for SSL Orchestrator configured as a transparent forward proxy. Authentication is done through a captive portal or using user access profile scope (named and public) to offload authentication for proxy-chaining.

NTLM Authentication enhancement

Microsoft has deprecated SMBv1 due to security impacts. F5's NTLM authentication no longer uses SMBv1. We now implement MSRPC over TCP.

DoS/DDoS: Auto-Discovery of services

This release provides support for Auto-Discovery of services.

Zone based firewall rules

This release supports Zones, or lists of VLANs used for packet matching.

DoS/DDoS: Hardware Debug Registers

This release supports new hardware debug registers, providing information about how packets are handled in hardware.

DoS/DDoS: Add BGP FlowSpec actions

This release supports new BGP FlowSpec actions for scrubbing or redirecting IP addresses.

IP-Intelligence: Allow GEO locations.

This release supports the use of GEO locations in IP Intelligence categories.

IP-Intelligence: Allow Fully Qualified Domain Names (FQDN).

This release supports the use of FQDNs in IP Intelligence categories.

IPv6 Packet Filters

This release supports IPv6 Packet Filters, allowing inspection of IPv6 Extension Header types.

Protocol Inspection: SCTP support

This release supports SCTP protocol inspection.

Protocol Inspection: Diameter support

This release supports Diameter protocol inspection.

Traffic Intelligence: Classification over encrypted QUIC

This release supports Traffic Intelligence: Classification over encrypted QUIC.

DNS cache scalability and sizing enhancements

This release provides greater DNS cache scalability and sizing enhancements.

Use of DOM Signatures for Malware Detection

The Malicious Words feature has been improved and renamed as DOM Signatures. Use DOM Signatures to set the location in the webpage where the BIG-IP system searches for suspicious character strings (can be alphanumeric, non-alphanumeric, or a combination of both). If the BIG-IP detects a blacklisted string in the location you specify, an alert is sent to the FPS dashboard.

FPS Logging Profiles

In BIG-IP 15.0.0, you can create Fraud Protection logging profiles to log information on client attempts to login to your protected website, and to log information on FPS alerts sent by the BIG-IP system. Once the logging profile is properly configured, the BIG-IP system sends the logs to a third-party platform of your choice. The logging profile includes an option to create your own template to determine what information is included in the logs, or to use a default template.

GUI Enhancements

Various improvements have been made to the FPS GUI to provide a more logical and user-friendly presentation of FPS configuration.

Geo-location reporting in alerts

The Collect Geolocation Coordinates setting has been added to the advanced general profile settings. When this setting is enabled:

• For a standard web-application (not mobile), the web browser will ask the end-user if he approves revealing his location. If the end-user approves, geo-location coordinates will be included in alerts. If the end-user does not approve, alerts will indicate that the end-user did not approve revealing his location.
• For mobile apps, the software developer needs to provide the MobileSafe SDK with the location data so that geo-location coordinates will be included in alerts. See the F5 MobileSafe Deployment and Configuration Guide, ver. 7.0 for more details on how do this.

Improved client-side performance

General client-side performance and loading time has been improved for FPS-protected websites running on the latest web browsers.

Enhancements to PEM HSL logs

This release includes new functionality enhancements in HSL flow and session reporting. You can disable start and interim messages to save network bandwidth and add new reporting fields (dropped flows and flow duration) to provide more visibility about subscribers.

Enhanced iRule commands and events for subscriber creation

This release adds several new iRule events for PEM session creation, modification, and deletion.

Updated socket driver supporting up to 10Gbps throughput

This release provides an updated socket driver in BIG-IP Virtual Edition (VE) to enable improved performance (up to 10Gbps throughput) running in Microsoft Azure cloud and Hyper-V hypervisor.

Cloud-specific metadata added to default info sent by VE to PhoneHome service

This release adds cloud-specific metadata to default info sent by BIG-IP VE to the PhoneHome service.

No new features

There are no new cloud-specific features in this release.

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

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.

ASM Logging Profile behavior in 12.1.0 and later

In 12.1.0 ASM logging profiles have changed from a single profile that can support remote and/or local logging to multiple profile support for profiles that are either remote, or local logging. No functionality is lost, however what was previously a single profile now becomes two profiles. This occurs when you upgrade from a pre-12.1.0 release to 12.1.0 or later, and there is an ASM logging profile exists in the configuration. In this case, logging profiles have changed from a single profile that can support remote and/or local logging to multiple profile support for profiles that are either remote OR local logging. No functionality is lost, however what was previously a single profile now becomes two profiles.

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.

FPS 15.0.0 Upgrade and Compatibility Information

BIG-IQ Compatibility

FPS 15.0.0 is compatible with BIG-IQ 7.0 and later versions.

The following table lists the new dimension titles and the initial values displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed values for each dimension will appear as expected.

The following table lists the new metrics and the initial value displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed value will appear as expected in the metric field.

The following table lists the affected HTTP dimensions and the initial values displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed value will appear as expected for the dimension.

How to Contact F5 Support or the Anti-Fraud SOC

You can manage service requests and other web-based support online at F5 My Support (registration required). To register email CSP@F5.com with your F5 hardware serial numbers and contact information.

You can contact the Anti-Fraud SOC as follows:

• By phone in the U.S. (accessible 24x7): 866-329-4253 (Option #3 for Anti-Fraud)
• International contact numbers: https://f5.com/products/platforms/silverline/f5-silverline-ddos-protection

Additional resources

You can find additional support resources and technical documentation through a variety of sources.