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

• No more than three modules (not including AAM or AVR) should be provisioned together. On 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.
• 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

Default change: Secure Password Policy now enabled by default

Beginning in v14.0.0, Secure Password Policy is enabled by default. On new installations, the passwords for root and admin accounts are expired and must be changed upon initial login. This does not apply to upgrades or UCS load. For more information, see Secure Password Policy is enabled by default :: https://support.f5.com/csp/article/K10612010 or the BIG-IP System: Secure Password Policy guide.

UltraFast L4 CPS Profile

On certain F5 hardware platforms (namely B4450 blade models and TurboFlex-enabled iSeries platforms), you can deploy a load-balancing optimization feature known as an Ultra Fast Layer 4 CPS profile. This profile enables specific hardware-acceleration features for high-performance load balancing, when you need the BIG-IP system to do mostly basic Round Robin load balancing only. For more information, see F5 Platforms: TurboFlex Profiles.

Support for IPv6 management IP addresses

This version of the BIG-IP software allows you to configure IPv6 management IP addresses. On appliance models, if you enable the Dynamic Host Configuration Protocol (DHCP), the system assigns a management address in IPv4 format, but also allows you to manually specify an IPv6 address as an alternate address. If you disable DHCP, you can specify either a single management address (in IPv4 or IPv6 format) or an IPv4 address and an alternate IPv6 address. On VIPRION platforms, the BIG-IP system supports floating cluster IP addresses in both IPv4 and IPv6 formats, as well as static IPv4 and IPv6 addresses for each slot in the cluster.

Support for TLS v1.3 (Internet-Draft 26 only)

The BIG-IP system now supports IETF Internet-Draft 26 for Transport Layer Security (TLS) Protocol version 1.3. Because the BIG-IP system supports Internet-Draft 26 only, this support for TLS version 1.3 is considered to be in beta phase and is not meant to be deployed in production environments. A list of major differences from TLS version 1.2 is included in Internet-Draft 26, here: https://tools.ietf.org/html/draft-ietf-tls-tls13-26.

BIG-IP supports importing existing NetHSM keys

For this release, you can now import existing Network HSM keys to the BIG-IP system. Multi-slots are not yet supported. For more information, see the implementation guides for Thales and SafeNet.

Local Attestation for TPM Chain of Custody

The BIG-IP iSeries and VIPRION B4450 platforms include a Trusted Platform Module (TPM) that comes with functionality to aid in attestation and confirming chain of custody for the device locally without the need for doing it manually. TPM Chain of Custody provides assurance that the software loaded on your platform at startup time has the same signature as the software that is loaded by F5 when the system is manufactured. For more information, see BIG-IP System: Essentials.

Removal of cipher keyword COMPAT

In this release of the BIG-IP system, the cipher keyword COMPAT and any subset keywords such as SSLV2 and RC2 have been removed, due to increased support for ciphers formerly supported in the OpenSSL cipher stack only. Due to the removal of the COMPAT keywords, the keyword NATIVE is now equivalent to All.

Support for ECC curve25519

The BIG-IP system now supports Elliptic Curve Cryptography (ECC) curve25519, for use with cipher strings that specify Elliptic Curve Diffie-Hellman (ECDH) key agreement. Support for curve25519 appears in the BIG-IP cipher groups feature as Diffie-Hellman (DH) group X25519 and is used when building a cipher string on the BIG-IP system for SSL negotiation.

Support for ECDSA key management on CAVIUM NITROX III FIPS HSMs (10350F, 7820F, 5820F)

On F5 platforms containing a CAVIUM NITROX III hardware security module (HSM), you can now manage Elliptic Curve Digital Signature Algorithm (ECDSA) keys. Note that the supported key exchange method for ECDSA keys on these platforms is Elliptic Curve Diffie-Hellman Ephemeral (ECDHE).

Support for ECDSA key management for SafeNet and Thales HSM

For this release, you can now create, list, and delete Elliptic Curve Digital Signature Algorithm (ECDSA) keys for Thales and SafeNet using TMSH, iControl, or the GUI. The Network HSM client must still be installed and configured beforehand. For more information see the implementation guides for Thales and SafeNet.

MQTT is using MRF

For this release, in a Message Queuing Telemetry Transport (MQTT) configuration, MQTT switched to using a Message Routing Framework (MRF) proxy while supporting the existing behavior of connection based load balancing.

iRule for allowing cloning of messages

For this release, there is a new iRule command that lets users clone incoming messages and identify for routing. This feature is part of the Message Routing Framework (MRF) and works for all protocols.

Support for insertion of header options into server-side SYN

You can now use the iRule TCP:option commands to insert header options into a server-side SYN during the initial three-way handshake, instead of after the handshake is complete.

Dashboard at the top level of the Statistics menu

This release includes a Dashboard with a new look and feel (the old one was removed) based on web technologies and open source visualization and charting tools. All of the elements from the old Dashboard have been migrated to the new one.

UDP Bandwidth Control

This release of the BIG-IP system includes performance enhancements with respect to UDP bandwidth control. Specifically, you can control bandwidth for egress UDP traffic flows by specifying an upper limit for the UDP packet flow rate. When the flow rate exceeds a certain value, the BIG-IP system queues the packets in a buffer up to a configured threshold. When the upper limit is reached, the system drops packets intelligently, according to a defined queue dropping strategy.

Web Threat Campaigns

A Threat Campaign is an attack associated with a specific malicious actor, attack vector, technique or intent. F5 discovers and investigates these attacks. The Web Threat Campaign is implemented as a new ASM policy entity. Threat Campaigns are inherited from parent policies to child policies. Threat Campaigns are accessed from Security :: Options : Application Security : Threat Campaigns.

The Web Threat Campaign feature requires a separate license. Licensed machines receive dynamic updates, in the form of a binary image file. Users can decide if a Threat Campaign is added in staging after an update. The default is no staging. When upgrading, existing Threat Campaigns are preserved. If a Web Threat Campaign license expires, all campaigns on a device are inactivated.

Layered Policy Enhancements

URL Positional Parameters Support

URL positional parameters are supported as part of global parameters. The URL with positional parameters is a non-pure wildcard, e.g. /p/* or */cart/*/item/php. When creating a New Allowed URL, enable Positional Parameters to use this feature. It is possible to modify or delete URL segments before the URL is created but note that global parameters used as positional parameters cannot be deleted once created. Both the URL and the parameter names are immutable after creation. Positional parameters are not supported for WebSocket URLs.

Increased Sensitive Data Masking

Sensitive data values disclosing personal details about users and credit cards can be masked in:

The field Sensitive Data was renamed to Mask in logs. These data values are masked in the ASM, local and remote request logs. If at least one of the entities marked for masking is present in a violation, the violation details snippet will not be shown, even if the violation did not occur within the masked entity.

Sensitive data values are not masked in:

Cookie Modifications

The ASM policy and Device ID cookie names can be modified. This can be used to mask ASM cookies or to allow users to rename ASM cookies to fit in-house cookie conventions. The maximum cookie size is increased from 8 KB to 16 KB to accommodate user applications which block 8 KB cookies. The new database variable Strip ASM cookies from request is enabled by default.

The system must be restarted for cookie name modifications to take effect.

Support for Wildcards in Disallowed HTTP, HTTPS and WebSocket URLs

Wildcards are supported in disallowed URLs, though a pure wildcard is only supported in allowed URLs. Both allowed and disallowed wildcards are listed in the Wildcards Order table and their rule application is by order in the list. For example: when the rules allow /a/*/b and disallow /a/c/* are configured, to allow or disallow /a/c/b.html is decided by which rule, allow or disallow, is first in the Wildcards Order table. Adding a new wildcard places it first in the wildcard order. Allowed and disallowed wildcards can be subsets of each other.

Expanded Health Monitoring

The scope of resource utilization is expanded to include request queue sizes with threshold alerts triggered and sent over local log, SNMP or SMTP. In this way, users can spot capacity issues in real time. Reported values are the averages of the last 1 minute.

Subcommands of asm health-alerts are used to set the global alerts.

Cross Origin Requests with Single Page Applications

The system database, tmsh list sys db dosl7.allowed_origins, allows the addition of a list of domains allowed to send out AJAX requests with custom headers. When configured with single page application support, BIG-IP adds additional CORS headers to AJAX responses generated by BIG-IP. This prevents browsers from blocking cross domain AJAX requests while still enforcing a CORS policy with single page applications.

Policy Properties Information Restructuring

The Policy Properties page has been removed and the information previously contained in the Policy Properties screen has been integrated into the Policy Summary which is renamed to Policy Properties. The Signature Staging field appears in the Learning and Blocking Settings screen. The Enforcement Readiness Period field has moved to the Learning and Blocking Settings screen..

Exporting Incidents

Incidents can be exported, individually or in multiples, to HTML format. The export includes all details of the incident record(s).

Exporting Learning Suggestions

Learning Suggestions can be exported, individually or in multiples, to HTML format. The export includes all details of the Learning Suggestions record(s).

Improved Application Request Filtering

Several filtering options have been added for application requests. The default filter now shows all requests, legal and illegal, and not just 5 as previously. A single log can be refreshed and the Refresh option includes no refresh. After configuring the requests filters, the filter settings can be flagged to be remembered for the logged in user.

Improved Violation Details

The state of each entity, either blocked or staged, is displayed. This applies for attack signature, wildcard parameter name, cookie, URL and threat campaign entities.

MySQL Database Replacement

The Oracle MySQL database has been replaced with the open source MariaDB database across the BIG-IP product.

Pane Expand and Collapse Functionality

Policy Toolbar Improvements

The Policy toolbar includes details of the selected policy's Learning Mode, Auto-Apply setting and Parent policy. The Policy toolbar also includes clickable icons to the Policy Properties and Learning and Blocking Settings of the selected policy.

One-Click Apply Multiple Policies

After modifying one or more policies, a new Apply Policies button on the Policies List page enables the user to apply all changes to all selected modified policies with a single click.

Brute Force Attacks Filter for Login Stress

The Login Stress table on the Brute Force Attacks page includes a filter to display all brute force attacks for a corresponding login page.

Requests and Triggered Violations Table Improvements

The Triggered Violations are now presented in a table with links to further details.

Security Log Profile Rewritten with Angular over REST

The Security Log Profile was rewritten with Angular over REST. Users will see inline validations in red as the graphic manifestation of this infrastructure improvement.

Scheduled ASM and DoS Data Obfuscation

The daily start times of system obfuscation can be scheduled from the Background Tasks screen via Security :: Options. This allows the tasks to begin during less active website hours.

Hardware enhancements to DoS protection

This release includes three compatibility levels that enable different levels of DoS protection and several types of whitelists, depending on the hardware platform of your system.

• Compatibility level 0 provides basic hardware DoS capabilities with device protection and rich whitelists.
• Compatibility level 1 applies to either a VE system with no hardware offload or a system with hardware DoS and sPVA capabilities. In addition to level 0 features, provides hardware DoS protection per protected object, whitelist address list, IP intelligence, and bad actor/attacked destination discovery.
• Comnpatibility level 2 applies to a system with hardware DoS, sPVA, and Neuron capabilities (in addition to level 1 features provides extended whitelist).

Simplified user interface

The 14.0.0 release has a new, simplified user interface that is easy to use. Terminology has been simplified for DoS Protection. You now configure protected objects (instead of virtual servers) and protection profiles (instead of DoS profiles).

Visual network configuration

Network quick configuration includes visual aids to help determine the appropriate way to configure DoS protection your network. You can select different methods for inline and out-of-band deployments, and are prompted for information needed for the quick configuration of common network topologies.

DoS protection enhancements

Several enhancements improve DoS protection in the network firewall. New vectors protect against attacks for NXdomain, SSL (renegotiation, flood, and incomplete handshake), non-TCP connection rate limit, and listener mismatch. You can associate a DNS profile with a protection profile.

Protocol Inspection improvements

Protocol inspection functionality now includes additional compliance checks for DNS, FTP, and HTTP protocols. The system provides learning and staging suggestions as a result of examining protocol to detect real attack attempts and reduce false positives. Protocol inspection analytics, charts and event logs allow users to filter information for events of interest, identify top inspections, attacking IP addresses, and applications under attack. Enhancements to the SSH profile support the SSH proxy including setting the LANG variable, event type in the log, the public key is derived from the supplied private key making it optional.

Netflow changes

You can now define Netflow Protected Server objects that represent subsets of traffic for use in developing distinct scrubbing policies.

Dynamic Signature support

Dynamic signature creation is supported in this release.

Advertisement of Flowspec routes

The system allows for advertisement of flowspec routes using flowspec route injector profiles. The flowspec route injector profile lets you deploy filtering rules among BGP peer routers to mitigate DDoS attacks.

Dual stack management support

You can configure both firewall rules with IPv4 source and destination addresses and firewall rules with IPv6 source/destination addresses in the management port context. The system selects appropriate rules from the configuration and applies them to the incoming traffic based on the address family of the management port IP addresses.

APM Dashboard refresh

The APM Dashboard, which displays statistics about APM connections, has been redesigned with a new look. It no longer requires the Adobe Flash plugin. Click Access > Overview > Dashboard to see it.

SAML inline SSO support

APM and LTM support configurations where customers use the BIG-IP system as a SAML Identity Provider. You can implement WebSSO-like functionality for SAML Service Providers that are located behind the BIG-IP system, such as when the Service Provider is not directly reachable by the clients.

Authorization server support for OpenID Connect

APM includes OpenID Connect support in the APM Authorization Server Framework for ID token and UserInfo generation.

OpenID Connect metadata discovery

APM can retrieve OpenID Connect metadata periodically and automatically update the configuration, including JSON Web Key configuration, without administrator intervention. Set this up with the Use Auto JWT and discovery task settings when creating an OAuth provider.

VMware Blast Extreme Adaptive Transport (BEAT) protocol support

APM now supports Blast Extreme Adaptive Transport (BEAT), an enhanced version of VMware’s Blast Extreme protocol. By dynamically adapting to network conditions, BEAT provides improved user experience in LAN as well as in high-latency, low-bandwidth WAN, and mobile networks.

VMware Workspace ONE integration

APM now supports VMware deployments wherein users first authenticate with VMware vIDM (vIDM can be on-premises or in cloud as part of the Workspace ONE suite); when users access resources protected by APM, they are redirected to APM. In this scenario, vIDM acts as an Identity Provider (IdP) and APM as a Service Provider (SP).

Multi-factor Authentication and device posture check for Office clients

APM now supports multi-factor authentication and a device posture check for native Microsoft Office clients (Word, Excel, PowerPoint, OneNote, OneDrive, and Skype for Business) accessing documents on Office 365 with on-premises SharePoint. APM uses f5epi helper applications for the device posture check.

Authorization support for Access policy with SSLO

APM access policies can provide authorization for HTTP and non-HTTP traffic in conjunction with SSL Orchestrator (SSLO). The session check agent in the SSLO per-request policy can identify whether a main access session is present or not and take actions based on that.

Additional data for SSLO per-request policies

SSLO per-request policies now have access to the following information for use with branching:

• TCP/IP address/port
• SSL SNI and SAN
• IP Intelligence data
• IP Geolocation data

Enhanced viewing options for DoS Visibility data with real time

In this release, the BIG-IP system can present within the tables and charts of DoS Visibility screens with real time data. The DoS Dashboard and DoS Analysis screens allow you to activate the a time view option that updates data over 10 second intervals. When activated, both charts and tables display data in real time. Charts display a one-hour summary of data that was collected over real time, while data presented in the tables displays data in real time. Real time does not extend to dimension data, which is presented as a one-hour summary and refreshed over a 5 minute interval.

Extended traffic capturing filters for URLs

Traffic capturing for URLs now allows for configuration of white list or black list filters in the HTTP Analytics profile. You can configure your profile to exclude or include traffic information from up to 10 specific URLs. You can modify traffic capturing filters via the BIG-IP GUI or Traffic Management Shell (tmsh) command.

Extended configuration options for collected entities

Profile now allows you to add filters for specific URLs, IPs, Subnets and countries. Once each is selected for data collection in your HTTP Analytics profile, you can further configure statistics collection to include up to 10 specific entities. The system includes all available combinations of entity filters when collecting data.

Collected entities for your HTTP Analytics

Your HTTP Analytics Profile now allows you to enable filters that only collect traffic that is qualified for JavaScript injection.

You can modify these collected entity filters via the BIG-IP GUI or tmsh command.

Limit number of entities in a snapshot per virtual server

Enhanced data transferring capabilities

AVR statistics data transfer capabilities to BIG-IQ have been enhanced to ensure secure and efficient data processing.

Improved performance for complex data queries

AVR now support multiple data queries in a single request, improving response time for displaying statistics data.

DNS cache statistics

For this release, the TMSH command 'show ltm dns resolver', which is used to monitor DNS cache resolver, has new statistics added to give insight into traffic from the resolvers to nameservers and for various types of zones. Relabeling and reformatting of the output was also completed.

Support for large DNS zones

Increased the stability and scalability of the DNS Express system to allow hundreds of thousands of DNS zones with a combined hundreds of millions of records to be hosted with a total zone database size approaching 100GB on suitable F5 platforms.

Running gtm_add and bigip_add without requiring passwords

Extending existing scripts, gtm_add and bigip_add, to run without requiring interactive input of passwords.

Support for EDNS0

For this release, the BIG-IP system now supports certain functionality associated with the Extended DNS (EDNS0 or EDNS) client subnet option.

SPA support - page/view identification

Single Page Application (SPA) Views: BIG-IP 14.0.0 supports configuring FPS on Single Page Application (SPA) views. In a Single Page Application, a URL can have multiple views (layouts/content sets), where views change without a full page reload. SPA views can be configured in BIG-IP 14.0.0 with Malware Detection, Automatic Transactions Detection, and Application Level Encryption; and a SPA view can be configured as a login page.

Add wildcard support for parameters

Wildcard Parameters: Parameters can now be defined on a URL or SPA view using wildcard expressions, which allows applying the various types of FPS detection and encryption to a much broader range of parameters.

GUI: improve parameters view

GUI Improvements: The user interface for defining parameters on a URL or SPA view has been improved. Parameters are now defined in their own screen so that all the settings for a parameter are clearly visible and logically presented to the user. Only parameter settings relevant to the URL type (web-based or mobile-based) are displayed.

No new features

There are no new policy-enforcement-specific features in this release.

No new features

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

Support for C5 and M5 AWS instance types

When deploying BIG-IP in AWS EC2, the C5 (compute optimized) and M5 (general purpose) series of instances are now supported. This includes support for NVMe storage as well as the Elastic Network Adapter (ENA). Versions of BIG-IP prior to 14.0.0.1 do not support these instance types.

No new features

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

No new features

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

BIG-IP i850 Platform

This release adds software support for the BIG-IP i850 platform. For more information, see Platform Guide: i800 Series.

BIG-IP i11000 Series Platform

This release adds software support for the BIG-IP i11000 Series platform. For more information, see Platform Guide: i5000/i7000/i10000/i11000 Series.

Support for vCMP on i15000 Series Platforms

This release adds software support for Virtual Clustered Multiprocessing (vCMP) on BIG-IP i15000 Series platforms.

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

Upgrading from version 12.x or later

When you upgrade from version 12.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 12.x

You cannot roll forward a configuration directly to this version from BIG-IP version 11.x or earlier. You must be running version 12.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 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.

Upgrading to Fraud Protection Service (FPS) 14.0.0

WebSafe Dashboard Compatibility

FPS 14.0.0 can be used with WebSafe Dashboard version 4.1 and later versions. Earlier versions of the WebSafe Dashboard are not compatible with FPS 14.0.0.

MobileSafe Compatibility

For Mobile Security users, this release can be used with all versions of the MobileSafe SDK currently supported by the F5 support policy.