Bot Defense

On This Page:

Objective

This guide provides instructions on how to configure and use F5 Distributed Cloud Bot Defense (XC Bot Defense) on F5 Distributed Cloud Console (XC Console). For more information on Bot Defense, see About Bot Defense.

Prerequisites

Enabling XC Bot Defense

Use one of these methods to enable XC Bot Defense:

Option 1 - WAAP add-on service

  1. On the XC Console Home page, select Billing. The Billing Plan page appears.

  2. Scroll to the right until you see the Organization plan.

  3. Under the Organization plan, select the Bot Defense link. The XC Bot Defense service landing page appears.

Option 2 - Standalone service

If you have both an account and Organization plan, you can enable the XC Bot Defense add-on service by going to the XC Console Home page and selecting the Bot Defense card.

If XC Bot Defense isn't enabled, the Bot Defense landing page appears. Select Request Service to enable XC Bot Defense.

Otherwise, if XC Bot Defense is already enabled, the Monitor page appears.

Note: To manage protected applications, a ves-io-power-developer-role or greater is required in system and application namespaces. To access the Bot Defense Monitor page, a ves-io-monitor-role or greater is required.

Enabling mitigation (blocking mode) for XC Bot Defense

Typically, users configure XC Bot Defense in Flag mode to start, which logs (but does not block) any traffic. When ready, users can enable blocking mode (Block or Redirect) to start blocking malicious traffic.

This process assumes you have completed a False Positive analysis for your traffic.

To start mitigating attack traffic:

  1. Go to Home > Load Balancers > Manage Configuration > Edit Configuration > Bot Defense Config > Bot Defense Policy > Protected App Endpoints > App Endpoint Type > Edit Endpoint.

  2. Under Select Bot Mitigation Action, change the Action for the protected endpoints to Block or Redirect.

  3. If you selected Block, select a Status code and enter a message body. If you selected Redirect, enter a redirect URI.

Backend configuration

Common best practices

  • When configuring endpoints, use wildcards to terminate the match. For example: /login*

    This prevents attackers from adding a slash to the end of the request (for example, /login/) when both variants reach the same application endpoint.

  • The mitigating response should try to mimic how the application responds when the request is invalid (for example, when invalid credentials are used).

WAAP or Distributed Mesh best practices

  • If your site is served from an apex domain, configure a redirect from the apex domain to the FQDN domain (for example, customer.com redirects to www.customer.com). This is required because your domain must point to a Distributed Cloud-provided CNAME. Pointing a CNAME from an apex domain is not recommended as that prevents you from having SOA and all other DNS records at apex.
  • Do not use IP-based session persistence to load-balance internally. F5 Distributed Cloud has a range of egress IPs and if you have IP-based load balancing at the origin, this may break your session persistence. Use cookie-persistence, if possible.
  • Lock down your infrastructure to Distributed Cloud egress IPs only. This prevents attackers from bypassing Distributed Cloud altogether and hitting your origin directly.
  • Validate your internal tools (such as logging tools or fraud tools) see the traffic accurately when going through XC Bot Defense.
  • If you have a CDN (such as CloudFront) implemented before F5 Distributed Cloud (Client > CDN > F5 Distributed Cloud > Origin), ensure:
    • The XC Bot Defense JavaScript file is excluded from the cached entities.
    • The CDN passes the origin User-Agent rather than injecting CDN User-Agent, such as "Cloud Front".

Web application best practices

  • Identify all URL paths to be protected by XC Bot Defense.
  • Use wildcards cautiously. Avoid enabling XC Bot Defense protection for more URLs than required by adding wildcards.

Mobile application best practices

  • Add XC Bot Defense headers only to those requests which are also configured for XC Bot Defense protection in WAAP or iApp. This helps avoid filling up bandwidth unnecessarily.

  • Before onboarding the mobile application, identify all URLs which need to be configured.

  • Ideally, F5 Mobile SDK is integrated into applications with forced-upgrade capability. This will allow you to upgrade users to the protected application.

  • F5 recommends you implement the integration as described in the SDK documentation. If you plan to deviate from those recommendations, please explore the knowledge base for other integration considerations.

  • Initialize the F5 Mobile SDK as early as possible in the application lifecycle to ensure the SDK is initialized and ready to add headers before a protected request is made. If you use Push Notifications on Android, there are special integration considerations when push notifications are sent to many applications at once.

  • Include an application version marker in the User-Agent header of the request.

    Example: User-Agent: sometext MyApp/3.3 sometext

    This allows you to examine traffic filtered by a specific version of your application.

  • Execute parseResponseHeaders() for all responses returned to protected requests.

  • Do not send the same set of headers more than once since each set of headers contains a unique token.

  • The XC Bot Defense SDK is obfuscated. If you use code obfuscation, exclude it from being obfuscated again.

  • If the application is accessing endpoints by using WebView and those endpoints need XC Bot Defense protection, consider using the JavaScript solution (see Knowledge Base article on how to use JavaScript with the WebView).

  • In the test environment, consider keeping your endpoints in Block Mitigation mode. This way, SDK integration problems will be discovered early during development.

Configuring XC Bot Defense to protect XC Mesh applications through an HTTP load balancer (WAAP add-on service)

  1. In XC Console, go to the Load Balancers page.

  2. Select the … in the Actions column next to your load balancer, and then select Manage Configuration.

  3. Select Edit Configuration.

  4. In the left navigation menu, select Security Configuration.

  5. In the Bot Defense Config section, in the drop-down menu select Specify Bot Defense Configuration.

    For load balancers with types “HTTPS with Custom Certificate” and “HTTPS with Automatic Certificate” set the Path normalize field to Enable path normalization. This is the default setting for new load balancer objects.

    Be sure to clear the Disable under Service Policy.

Adding endpoints for XC Bot Defense protection

In the Bot Defense Config section, follow these steps:

  1. Under Bot Defense Regional Endpoint, select the region where the endpoint resides.

  2. (Optional) Select the Show Advanced Fields switch in the upper right corner. The Timeout field appears. In the Timeout field, enter the number of milliseconds Bot Defense should wait for the inference check to complete before timing out. The default value is 1000.

  3. In the Bot Defense Policy section, select Configure.

  4. In the Protected App Endpoints section, select Configure.

  5. Select Add Item to add an application endpoint. You can create multiple endpoints.

  6. Enter the following for each endpoint:

    • Name: The name of the message. Must follow DNS-1035 format.
    • Description: A human-readable description of the endpoint.
    • HTTP Methods: Which HTTP methods are monitored on this endpoint. Commonly used methods include POST/PUT/GET(XHR). GET requests are protected only if they are sent by XHTTPRequest from the page with XC Bot Defense JavaScript injected, not from direct navigation using the address bar or link. The ANY method should be used carefully and only when intended.
    • Protocol: Which protocols are protected.
    • Domain Matcher: Since HTTP load balancers can serve multiple domains, you can specify domains here. Enter an exact value, a suffix value, or a regex value.
    • Path: Specify protected paths here. Enter a prefix, exact path, or regex value.
    • Bot Traffic Mitigation: Specify what action to take when a bot is detected.
    • Block: The endpoint returns a status code and message. You can select the code and edit the message here.
    • Redirect: The endpoint forwards the browser to a URI, specified here.
    • Flag: Select No headers to create a log record only, or select *Append Headers to create custom headers for Inference and Automation Type.

Mobile SDK for WAAP

There is a new Mobile SDK Settings section. This section is disabled by default. If a user adds a mobile endpoint in the Protected App Endpoints section, then they can enable the section and specify their specific header for mobile.

Users can select one of the following Traffic Channel options per endpoint:

  • Web Traffic
  • Mobile Traffic
  • Web and Mobile Traffic (needs to be enabled by the Show Advanced Fields filter at the top-right of the page)

Note: If Web and Mobile is selected, then the user needs to add specific mobile request identifier and select header. The Header will be defined in the Mobile SDK Setting Advanced fields.

Mobile SDK settings

This is section of Bot Defense Policy lets you specify your mobile preferences. You must select Show Advanced Fields for the Mobile Traffic Identifier Header section to appear. Select Add Item.

You can specify the mobile header name and set their matcher preferences. Select from the following Match Options:

  • Match Values
  • Present
  • Not Present

If you want to set Transformers, select Show Advanced Features.

When done configuring, select Add item to save the details.

Injecting the XC Bot Defense JavaScript into your web pages

After you add the domains for which to apply XC Bot Defense protection, you must inject the XC Bot Defense JavaScript into the web pages.

To inject the XC Bot Defense JavaScript, follow these steps:

In the JavaScript Insertion section:

  1. Under JavaScript Download Path, enter the path where the HTTP load balancer can find the JavaScript to serve to the client browser.

  2. Under JavaScript Insertion Settings, specify if the HTTP load balancer should insert JavaScript into all pages, or if some pages should be excluded.

If you select Insert JavaScript in All Pages:

  • Choose where the JavaScript will be inserted:
    • After <head> tag
    • After </title> tag
    • Before <script> tag

If you select Insert JavaScript in All Pages with the Exceptions:

  1. Choose where the JavaScript will be inserted:
- After \<head> tag
- After \</title> tab
- Before \<script> tag
  1. Select Add Item to add an excluded page. The JavaScript Insertion Exclusion Rule page appears.

  2. In the JavaScript Insertion Exclusion Rule page, enter the following for each excluded page:

- **Name**: The name of the message. Must follow DNS-1035 format.
- **Description**: A human-readable description of the endpoint.
- **Domain Matcher**: Since HTTP load balancers can serve multiple domains, you can specify domains here. Enter an exact value, a suffix value, or a regex value.
- **Path**: Specify protected paths here. Enter a prefix, exact path, or regex value.
  1. Select Add Item.

Note: The following options are visible only when the Show Advanced Fields switch is set to On.

If you select Custom JavaScript Insertion Rules:

  1. Under JavaScript Insertions, select Configure. The JavaScript Insertions page appears.

  2. Select Add Item and enter the following for each endpoint:

- **Name**: The name of the message. Must follow DNS-1035 format.
- **Description**: A human-readable description of the endpoint.
- **Domain Matcher**: Since HTTP load balancers can serve multiple domains, you can specify domains here. Enter an exact value, a suffix value, or a regex value.
- **Path**: Specify protected paths here. Enter a prefix, exact path, or regex value.
- **JavaScript location**:
  - After \<head> tag
  - After \</title> tab
  - Before \<script> tag
  1. When you are finished adding endpoints, select the Back button. The JavaScript Insertions screen appears.

  2. Select the Back button.

  3. Under Exclude Paths, select Add Item and enter the following for any paths you want to exclude from inserting JavaScript:

    • Name: The name of the message. Must follow DNS-1035 format.
    • Description: A human-readable description of the endpoint.
    • Domain Matcher: Since HTTP load balancers can serve multiple domains, you can specify domains here. Enter an exact value, a suffix value, or a regex value.
    • Path: Specify protected paths here. Enter a prefix, exact path, or regex value.

If you select Disable JavaScript Insertion, no further action is necessary. JavaScript will not be inserted to any page.

Configuring XC Bot Defense to protect other applications through the Template Connector

Adding protected applications to XC Bot Defense

To add applications to XC Bot Defense:

  1. On the XC Console Home page, select the Bot Defense card. The Applications page appears.

  2. On the Applications page, if you haven't added any applications yet, select the Add Protected Application. Otherwise, select Add Application. The Protected Application page appears.

  3. On the Protected Application page, enter the following:

    • Name: The application's name.
    • Labels: Select or add a label for this application.
    • Description: Describe the application.
    • Application Region: The region where the application's origin server resides.
    • Connector Type: The type of connector the application uses.

    Users can add a new Connector Type called Custom when creating a new application. If added, the system displays Custom under the Connector Type on the Application Overview.

    Users will add metadata, region, and then select their connector type. A new Custom field appears. The user should select Custom if their specific platform is not listed. The Custom type will provide the needed authentication parameters for use on other platforms.

    If a Custom Connector Type is selected, the user has access to the following authentication parameters to use on the other platforms:

    • Copy App ID
    • Copy Tenant IF
    • Copy API Key
    • Copy Web API Hostname
    • Copy Mobile API Hostname
    • Copy Telemetry Header Predix

    Note: Each Connector Type will have different action, usually associated with the specific platform. Custom is intended to support many platforms and may have more fields than what is required to get started.

  4. Select Save and Exit.

Managing protected applications

To manage a protected application:

  1. On the XC Console Home page, select the Bot Defense card.

  2. On the Applications page, in the Actions column, select the three dots next to your application. The Actions menu appears.

  3. From the Actions menu, select one of the following:

    • Manage Configuration: Opens the Protected Application page. Select Edit Configuration to make changes.
    • Copy App ID: Copy the application's unique ID to your clipboard.
    • Copy Tenant ID: Copy the tenant's unique ID to your clipboard.
    • Copy API Key: Copy the application's API key to your clipboard.
    • Delete: Delete the application.
    • Download Template: Download an iApp template for use with BIG-IP.

Note: XC Bot Defense supports iApp template versions 3.0.2 and later.

Client configuration

Adding XC Bot Defense SDK to your mobile applications

Native applications can be integrated with XC Bot Defense by following the two links below:

For integration, you will need:

  • Native SDK library
  • Base configuration file

Both can be downloaded from this portal.

  • Use getRequestHeaders and parseResponseHeaders API, rather than the generateHeaders and analyzeResponse. This API is simpler and meets the needs of XC Bot Defense.
  • For body, you can pass in nil on iOS and null on Android.
  • For XC Bot Defense, getRequestHeaders will always return headers, regardless of which URL is passed. For this reason, the developer should only add headers to the requests which require protection.
  • Similarly, parseResponseHeaders should be called for every response to the protected requests.

Explore the knowledge articles for integrating XC Bot Defense with:

  • Flutter
  • React Native
  • Xamarin and Xamarin.Forms
  • Angular + Ionic

Verifying XC Bot Defense integration

Confirming JavaScript injection is working

To confirm XC Bot Defense is adding JavaScript to an entry page, inspect the page in your browser and look for XC Bot Defense-specific headers using the procedure below.

  1. Obtain the following information from your load balancer configuration. You can find the entry page's host and path in your HTTP load balancer configuration by going to Home > Load Balancers > Manage Configuration > Edit Configuration > Bot Defense Config > Bot Defense Policy > Protected App Endpoints.

    • Entry page path (for example, www.yourwebsite.com/endpoint)
    • JavaScript download path (for example, /yourscript.js)
  2. Go to the entry page path in your browser. For example: www.yourwebsite.com/endpoint

  3. Right-click (Windows) or Control-click (iOS) near the outer edge of the page and select Inspect. Your browser’s inspector opens.

  4. In the inspector, select the Network tab.

  5. Refresh the browser. A list of requests appears in the inspector.

  6. Look for three scripts in the list of requests named with your JavaScript download path, followed by ?matcher, ?cache, and ?async query parameters.

    Examples:
    yourscript.js?matcher
    yourscript.js?cache
    yourscript.js?async

If you see three scripts with your JavaScript download path followed by ?matcher, ?cache, and ?async, XC Bot Defense is injecting JavaScript into the entry page.

Validating Mobile SDK integration

This section describes how to validate if F5 Mobile SDK is properly integrated. Complete these test cases:

  1. Review the Integration documentation to make sure all integration steps have been followed.

  2. SDK Initialization

    1. Deploy the application onto a device for the first time (if the device already had the application, remove it before this test).
    2. Start the application.
    3. On the on the Bot Defense dashboard or the Bot Traffic Overview Dashboard, filter by your client IP. You should observe a GET request configuration fetch from your application.
  3. Decorated Request

    1. Make a request for every protected URL.
    2. On the Bot Defense dashboard, filter by your client IP. You should see all protected requests marked as Human.
  4. Mitigation

    1. Temporarily alter the application code to not call getRequestHeaders.
    2. Launch the application and make protected requests.
    3. On the Bot DefesnseDefense Dashboard filter by your client IP. You should see all protected requests marked as an Automation. You should see a GET request configuration fetch occur right after each blocked mitigated request.
    4. Update your code to call getRequestHeaders again.

Your integration is successful if you were able to complete all of these test-cases. Incorporate these Mobile SDK test-cases into your standard regression testing.

Before releasing a new application into the production environment, set mitigation action to Flag. Perform the false positive analysis before re-enabling mitigation.

False positive analysis

False positive analysis for web traffic

This section provides guidance for how to confirm XC Bot Defense is working as expected on your website after being enabled for real users. Specifically, you will need to determine if any legitimate traffic is marked as automation.

Although this documentation provides some guidance, this is a creative process. Explore your traffic reports and examine anything unexpected. Resolve all issues before you move to blocking mode.

Identify false positives

  1. Review human and bot traffic on the Bot Defense dashboard or the Bot Traffic Overview Dashboard.

  2. Is any traffic marked as non-human? If yes:

    • What is the automation type of the non-human traffic?
    • Does the traffic marked as malicious have a diurnal pattern which increases during the day and drops at night? This might indicate human traffic.
    • Look at the distribution of IPs and the countries they are from. Does this distribution look like it's coming in from your normal user base?
    • Look at the User Agent field. Are any suspicious user agents present? You can also identify wanted automation (like test tools or SEO bots) by using this technique.

False positive analysis for mobile traffic

Before you enable mitigation, be sure to confirm XC Bot Defense for Mobile is working as expected after it has been enabled for real users.

Specifically, in the Bot Defense dashboard, confirm the following:

  • Low or non-existent rate of requests with no XC Bot Defense headers and requests with headers are marked as Human.
  • Configuration fetch requests are made at an expected rate. Each configuration fetch corresponds to one user session.

Explore your traffic reports and examine anything unexpected. Resolve all issues before you turn on mitigation.

Reporting

Viewing traffic data for XC Mesh applications through the load balancer dashboard

When XC Bot Defense is enabled and configured, the HTTP load balancer's security screen has two additional tabs: Bot Defense and Bot Traffic Overview. You can use these tabs to access their respective dashboards to view data about your traffic.

To access the Bot Defense and Bot Traffic Overview dashboards:

  1. In XC Console, go to Web App & API Protection > Apps & APIs > Security.

    You can also access the XC Bot Defense dashboards from the HTTP load balancer's Security Monitoring page.

  2. Select a load balancer in the Load Balancers list. The Security dashboard appears. One card in the Security dashboard shows the Bot Defense top three automation types.

  3. In the Security dashboard, select either the Bot Defense or the Bot Traffic Overview tab.

Viewing traffic data for other applications

When XC Bot Defense is enabled and configured, you can monitor traffic and activity with the Dashboard and Traffic Overview tabs on the XC Bot Defense page. Use these tabs to view data about your traffic.

To access the XC Bot Defense dashboard and Traffic Overview screens:

  1. On the XC Console Home page, select the Bot Defense card. The XC Bot Defense page appears.

  2. Select Monitor.

  3. Select either Dashboard or Traffic Overview.

Load Balancer XC Bot Defense dashboard

The XC Bot Defense dashboard provides a snapshot of human and malicious bot activity in your web traffic for a specified time period.

The dashboard presents key information like which bots are making the most malicious requests, which endpoints are attacked most, and which automation types are being used most. You can customize the time period, filter results, and make other adjustments using the dashboard features described below.

  • Time Window drop-down: Select a time range for analysis.
  • Hide Filter/Show Filter button: Select to toggle the Add filter link and any active filters. You can filter results by IP address, AS Organization, and User Agent.
  • Traffic Types: The total number of transactions in the selected time window, how many were malicious bots, and how many were humans.
  • Top Automation Types: The most common automation type for the selected time window.
  • Traffic Overview: The transactions per minute of human and malicious bot traffic for the selected time period. You can point to the graph to view specific values.
  • Top Malicious Bots: The five bots that made the most malicious requests in the selected time period, including the source IP, ASN, user agent, country where the bot is based, and number of malicious requests in the selected time period. You can view each bot's Source IP, AS Organization, and User Agent.
  • Top Endpoints Attacked: The five endpoints being attacked most frequently by malicious bots, including the host name, endpoint path, and number of malicious requests in the selected time period.

Load Balancer Bot Traffic Overview dashboard

The Bot Traffic Overview dashboard provides detailed insight into traffic on the HTTP load balancer.

In addition to the chart showing transactions per minute for a specified time window, you can also view details about every HTTP request sent through XC Bot Defense. Each HTTP request includes the following information:

  • Time
  • Country
  • IP Address
  • ASN
  • AS Organization
  • User Agent
  • Host
  • Path
  • Method
  • Inference

Rearrange and sort the columns by selecting them. Show or hide columns by selecting the gear icon to the upper right of the list.

Bot Defense dashboard

The Bot Defense dashboard is a snapshot of human and malicious bot activity in your web traffic for a specified time period.

The dashboard presents key information like which bots are making the most malicious requests, which endpoints are attacked most, and which automation types are being used most. You can customize the time period, filter results, and make other adjustments using the dashboard features described below.

  • Region: Select the geographical region to monitor (US, EU, or Asia).
  • Time Window selector: Choose a time range to analyze from this drop-down menu.
  • Hide Filter/Show Filter button: Select this to toggle the Add filter link and any active filters. You can filter results by IP address, AS Organization, and User Agent.
  • Traffic Types: Shows the total number of transactions in the selected time window, how many were malicious bots, and how many were humans.
  • Top Automation Types: Shows the most common automation type for the selected time window.
  • Traffic Overview: This graph shows the transactions per minute of human and malicious bot traffic for the selected time period. You can hover over the graph to see specific values.
  • Top Malicious Bots: This table shows the five bots that have made the most malicious requests in the selected time period. The table includes the source IP, ASN, user agent, country where the bot is based, and number of malicious requests in the selected time period. You can view each bot's Source IP, AS Organization, and User Agent.
  • Top Endpoints Attacked: This table shows the five endpoints that are being attacked most frequently by malicious bots. The table includes the host name, endpoint path, and number of malicious requests in the selected time period.

Traffic Overview page

The Bot Traffic Overview page provides detailed insight into traffic on the HTTP load balancer.

In addition to the chart showing transactions per minute for a specified time window, you can also view details about every HTTP request sent through XC Bot Defense. Each HTTP request includes the following information:

  • Time
  • Country
  • IP Address
  • ASN
  • AS Organization
  • User Agent
  • Host
  • Path
  • Method
  • Inference

Rearrange and sort the columns by selecting them. Show or hide columns by selecting the gear icon to the upper right of the list.

Connectors

Adobe Commerce Connector

Installation

Prerequisites
Install the F5_DistributedCloudConnector extension
  • Download the archive.
  • Run composer require f5/distributed_cloud_connector:VERSION (for example, distributed_cloud_connector:VERSION:v1.0.1). The version of the extension can be found in the composer.json file.
  • Run php bin/magento set:up.
  • Run php bin/magento s:d:c.
  • Run php bin/magento setup:static-content:deploy. If Magento is in developer mode, add an -f argument. Developer mode is not officially supported in the extension.

Extension Configuration

To find the F5 Extension configurations, go to: Admin Panel > Stores > Configuration > F5® DISTRIBUTED CLOUD SERVICES.

Configuration modules include:

  • Bot Defense
  • Account Protection
  • Authentication Intelligence

Bot Defense

The Bot Defense module contains these sections:

  • General
  • JS Insertion
  • Login Protection
  • Protected Endpoints
  • Web Scraping
  • Allow List
General

The General section contains options to enable and configure the connection of the Bot Defense module with the F5 Service.

The configuration options are:

  • Enable Service - enable/disable the module.
  • Mode - there are two options available:
    • Enterprise - the dedicated mode of usage where the “Application ID” and “Tenant ID” fields are not required.
    • Standard - the multi-tenant mode of operation.

    The mode should be selected according to the F5 plan.
  • API Hostname - the hostname provided by F5.
  • Backend API path - the path to the Bot Defense script on the website backend.
  • API Key - the key used for authentication of the API calls to the F5 system. The key can be obtained from the F5® Distributed Cloud console.
  • Telemetry Header Prefix - the header prefix provided by F5.
  • Application ID - available only when Standard mode is selected, and is available in the F5® Distributed Cloud console.
  • Tenant ID - available only when Standard mode is selected, and is available in the F5® Distributed Cloud console.
  • Timeout API response - the time (in milliseconds) that the module waits for a response from the F5 server. After that, the request is processed by the Adobe Commerce backend. The default is 700.
  • Source for Client IP address - select which source to use for getting the customer’s IP address:
    • Connecting IP - the IP address is gathered from the customer’s connection information.
    • X-forwarded-For - the IP address is gathered from the X-forwarded-For header.
    • Custom - define the custom header name to use for gathering the customer’s IP address.
      • Custom Ip address source - the custom header name for gathering the customer’s IP address. In the configured header, the first character of each word should be upper case.
  • Enable Debug - when enabled, the requests and responses to/from the F5 service are recorded into the log file on the website server.

acc general
Figure: General section of Adobe Commerce Cloud connector

JS Insertion

The JS Insertion section contains options to configure the JS tag insertion.

The configuration options are:

  • JS Path - either an absolute path, or a relative path to the JS:
    • Absolute example - https://<FQDN+JS_location>, such as https://www.foo.com/abc.js.


    If using absolute tag insertion, verify the JS requests are routed to the F5 Bot Defense service.
    • Relative example - </JS_location>, such as /abc.js.
  • Insert JS option - specifies where in the page to add the JS tag:
    • Before <script>
    • After </title>
    • After <head>
  • JavaScript load mode - select the load mode of the JavaScript on the page:
    • Async with caching
    • Async with no caching
    • Sync with caching
    • Async with caching and defer XHR
  • Insert JS to specific web pages - displays the Specific pages list, a list of pages that should have the JS inserted.
    • If Yes, the Specific pages list displays:

      • Only the path to the page should be defined, such as /about-us.
      • Each page should be a new line.
      • Wildcards can be used for page path definitions, such as *, %, and so on.
      • To insert the JS tag on all pages put only an asterisk (*).
      • The JS tag is not inserted on any pages if this field is empty.
    • If No,the Specific page list field is hidden and the JS tag is displayed on all available pages that are not defined in the Excluded pages list field.

    • Exclude JS from specific web pages - displays the Excluded pages list, a list of pages that should be excluded from JS insertion.

      • If Yes, the Excluded pages list displays:
        • Only the path to the page should be defined, such as /about-us.
        • Each page should be a new line.
        • Wildcards can be used for page path definitions, such as *, %, and so on.
    • If No, the Excluded pages list field is hidden and the JS tag is inserted according to the Insert JS to specific web pages configuration.

      acc js insertion
      Figure: JS Insertion section of Adobe Commerce Cloud connector

Login Protection

The Login Protection functionality configures Bot Defense for the Login action directly.

The configuration options are:

  • Protection type - defines the protection type, one of:
    • Disable - disables login protection.
    • Collect txn - customer verification is performed after sending the login request to the origin destination.
    • Ignore txn - customer verification is performed right after clicking the Login button on the storefront, but before the Login request is performed to the origin destination.
  • Login Url - defines the login action URL that should be protected by Bot Defense. By default it is set to /customer/account/loginpost*, which is used by the Adobe Commerce platform. It can be customized in cases when a non-default login functionality is being used on the website.
  • Mitigation - there are three options available:
    • Continue - the user is allowed to visit the destination page, but is flagged by the header defined in the Mitigation Continue header field.
    • Block - the user is blocked from reaching the destination page. They are routed to a blank page with the content defined in the Blocked Response Body field and the response code defined in the Blocked Response Code field.
    • Redirect - the user is redirected to the path defined in Mitigation Redirect path.

acc login
Figure: Login protection section of Adobe Commerce Cloud connector

Protected Endpoints

The Protected Endpoints functionality allows to define pages and sources on the website that should be protected by Bot Defense.

The configuration options are:

  • URL endpoint - the path to the page or action that should be protected. Wildcards can be used to define complex URLs.
  • Method - the type of the request being performed to the defined page or action.

These types of request methods are supported:

  • GET
  • POST
  • PUT
  • Mitigation - the mitigation action type. There are three options:
    • Continue - the user is allowed to visit the destination page, but is flagged by the header defined in the Flag Header name field.
    • Block - the user is blocked from reaching the destination page. They are routed to a blank page with the content defined in the Block Response Body field and the response code defined in the Block Response Code field.
    • Redirect - the user is redirected to the path defined in Redirect location.

acc endpoints
Figure: Protected endpoints section of Adobe Commerce Cloud connector

Web Scraping

The Web Scraping functionality defines pages and sources on the website that should be protected by Bot Defense. This option allows you to protect documents and pages that are accessible only by GET requests.

The configuration options are:

  • URL endpoint - the path to the page or action that should be protected. Wildcards can be used to define complex URLs.
  • Mitigation - the mitigation action type. There are three options:
    • Continue - the user is allowed to visit the destination page, but is flagged by the header defined in the Flag Header name field.
    • Block - the user is blocked from reaching the destination page. They are routed to a blank page with the content defined in the Block response Body field and the response code defined in the Block response Code field.
    • Redirect - the user is redirected to the path defined in Redirect location.

acc scraping
Figure: Web scraping section of Adobe Commerce Cloud connector

Allow List

Allow List allows requests to get to the origin destination without performing verification by Bot Defense. There are two options that give this possibility, allow listing by IP Address or by request headers.

Allowed IP Addresses

Requests sent from the IP addresses defined in the Allowed IP addresses field are delivered to the endpoint without performing verification. Each IP address should be defined on a new line.

Allow Header

Requests that contain the [header]:[value] pair are delivered to the endpoint without performing verification. Each [header]:[value] pair should be defined on a new line. Wildcards are supported for both header name and header value.

acc allowlist
Figure: Allow list section of Adobe Commerce Cloud connector

Account Protection

F5 Distributed Cloud Account Protection provides a converged solution for application security and fraud protection powered by a real-time, closed-loop engine and large-scale unified telemetry to reduce customer friction and stop fraud before it happens.

The Account Protection module contains these sections:

  • General
  • Protected Endpoints
  • Action
General

The General section contains options to enable and configure the connection of the Account Protection module with the F5 Service. The path to the module is:

Admin panel --> Stores --> Configuration --> F5® DISTRIBUTED CLOUD SERVICES --> Account Protection

The configuration options are:

  • Enable Service - enables or disables the module.
  • API Hostname - the host name of the Account Protection service.
  • Script Tag - path to the F5 Account Protection script
  • JS Path - path to the JS file.
  • Customer ID - the customer identifier, can be obtained from the F5 Service.
  • Cookie name - the name of the cookie from the Account Protection service that should be decrypted and processed.
  • Decryption key - the key that decrypts the fr value in the cookie received from the Account Protection service.
Protected Endpoints

These options define the endpoints that should be protected by the Account Protection.

  • URL endpoint - the path to the page or action that should be protected. Wildcards can be used to define complex URLs.
  • Mitigation - the mitigation action type. There are three options:
    • Continue - the user is allowed to visit the destination page, but is flagged by the header defined in the Mitigation Continue header field.
    • Block - the user is blocked from reaching the destination page. They are routed to a blank page with the content defined in the Blocked response Body field and the response code defined in the Blocked response Code field.
    • Redirect - the user is redirected to the path defined in Mitigation Redirect path.
  • Method - the type of request being performed on the defined page. These types of request methods are supported:
    • GET
    • POST
    • PUT
  • Blocked Response Body - the message to display on the blank page when the Block mitigation action is performed.
  • Blocked Response Code - the status code to deliver when the Block mitigation action is performed.
  • Redirect location - the path the user is redirected to when the Redirect mitigation action is performed.

acc protected endpoints
Figure: Protected endpoint options

Action

The Action section contains the mitigation actions settings, such as:

- **Missing Cookie** - allows you to select the mitigation action for cases when the `Account Protection` cookie is missing. There are three options: - Continue - Block - Redirect - **Invalid Cookie** - allows you to select the mitigation action for cases when the `Account Protection` cookie is invalid. There are three options: - Continue - Block - Redirect #### Authentication Intelligence `Authentication Intelligence` extends the login session lifetime for non-malicious users, after they are verified by F5. ##### General The `General` section contains options to enable and configure the connection of the `Account Protection` module with the F5 Service. The configuration options are: - **Enable Service** - enables or disables the module. - **API Hostname** - the host name of the Authentication Intelligence service. - **Script Tag** - path to the F5 Authentication Intelligence script. - **JS Path** - path to the JS file. - **Customer ID** - the customer identifier, can be obtained from the F5 Service. - **Cookie name** - the name of the cookie from the Authentication Intelligence service that should be decrypted and processed. - **Decryption key** - the key that decrypts the `c` value in the cookie received from the Authentication Intelligence service. ![](images/acc-authintelligence.png?lightbox&classes=caption "Figure: Authentication Intelligence section of Adobe Commerce Cloud connector") ## References * [Firewall or Proxy Reference for Distributed Cloud](/docs/reference/network-cloud-ref) * [System Overview](/docs/ves-concepts/system-overview) * [Load Balancing and Proxy](/docs/ves-concepts/load-balancing-and-proxy)