HTTP Load Balancer

Origin server subset rules provide the ability to create match conditions on incoming source traffic to the HTTP load balancer using country, ASN, regional edge (RE), IP address, or client label selectors for subset selection of destination (origin servers).

As prerequisites, (1) create a label (key-value pair), (2) in origin pool configuration, add labels to one or more origin servers, (3) and then in the Other Settings subsection, select Enable Subset Load Balancing. Add one or more keys to origin server subset classes. Choose a setting for subset fallback policy. The default option is to select any origin server.

• Enable the Show Advanced Fields option.

• Under Origin Server Subset Rules, click Configure.

Figure: Origin Server Subset

• Click Add Item.

• In the Name field, enter a name for the rule.

Figure: Origin Server Subset Rule Configuration

• From the Action field, click Add Label and select the same label(s) that you assigned to origin servers in the origin pool configuration.

• Optionally, select a country from the Country Codes List menu.

• From the Client Selector Match menu, select an option to match on label selectors.

• From the Source IPv4 Match menu, select an option to match on client IP address.

• From the Source ASN Match menu, select an option to match on client ASN.

• In the Regions Edges section, click Add Item to select an RE to match traffic to.

• After you finish, click Apply.

You can choose to disable WAF application (default setting) or you can select a WAF that was previously created, configured, and apply it in your load balancer security settings. In addition, you can also create and enable a new WAF and have your load balancer configured to exclude specific WAF rules from processing certain requests.

• Go to the Web Application Firewall section.

• From the Web Application Firewall (WAF) drop-down menu, select whether to enable the WAF for this HTTP load balancer. Disable is the default value.

• If you select Enable, use the Enable drop-down menu to select your WAF to apply to this load balancer.

Figure: Add App Firewall

Note: You can also add App Firewall per route. In the route configuration, for Simple Route, go to advanced options configuration, go to security section, and select App Firewall for the Web Application Firewall (WAF) field. Select an App Firewall object. By default, the route inherits the App Firewall configured for the load balancer.

• To add exclusion rules for the WAF, follow the instructions at Create WAF Exclusion Rules.

• Select Configure in the Data Guard Rules section and follow the instructions listed in Configure Data Guard to set data guard rules.

• Select Configure for the Cross-Site Request Forgery Protection option. Specify allowed domains in the Allowed Domains (Source Origin) field in the CSRF protection page, and select Apply. You can either configure to allow all load balancer domains or set specific domains to the allow list.

Note: You can verify the CSRF mitigation in the load balancer security monitoring page. The CSRF mitigation event is displayed as a Service Policy event. Expand the security event's JSON view. The sec_event_name field with value CSRF Policy Violation indicates that CSRF mitigation is active. For more information on load balancer monitoring, see Monitor HTTP Load Balancer.

• To configure the settings for GraphQL inspection, perform the following:

  • Under the GraphQL Inspection section, click Configure.

  • Click Add Item.

  • In the Name field, enter a name for this rule.

  • From the Domain drop-down menu, select an option that corresponds to your domain setting. Default value is Any Domain. You can choose an option match by Exact Value or Suffix Value.

  • From the Path drop-down menu, select an option for the location of your GraphQL server endpoint. Default value is /graphql.

  • From the HTTP Method drop-down menu, select an option that specifies the method used to access the GraphQL endpoint server.

  • In the GraphQL Settings section, perform the following:

    • From the Maximum Total Length menu, enter a value to specify the maximum total length in bytes for a query.

    • From the Maximum Structure Depth menu, enter a value to specify the maximum depth for a query.

    • From the Maximum Batched Queries menu, enter a value to specify the maximum number of single batch queries.

    • From the Introspection Queries menu, select whether to enable introspection of GraphQL schema.

  • Click Apply to save settings.

  • Click Apply to apply settings to load balancer configuration.

• Optionally, in the Cookie Protection field, click Configure to add attributes to an HTTP Response cookie that is sent to the client:

  • Click Add Item.

  • In the Cookie Name field, enter a name for this cookie.

Note: Wildcards and regular expressions (regex) are not supported. You must use the exact cookie name.

• From the SameSite menu, select if or how the new cookie is sent with same-site and cross-site requests. You can select from the following:

  • Ignore
  • Strict
  • Lax
  • None

• From the Secure menu, select whether this new cookie is sent only over an HTTPS encrypted connection to the server. Default option is Ignore.

• From the HttpOnly menu, select whether this new cookie is inaccessible to JavaScript Document.cookie API. Default option is Ignore. Select Add to ensure the cookie is inaccessible.

• Select Enable for the Cookie Tampering Protection field to enable cookie tampering protection. This prevents attackers from modifying the values of session cookies.

• Click Apply to save settings.

• Click Apply to apply settings to load balancer configuration.

Note: You need to have Bot Defense enabled in your tenant as a service prior to configuring it for your load balancer.

• Go to the Bot Protection section. From the Bot Defense menu, select an option to configure bot defense. The following options are available:

  • Disable: No bot defense configuration is applied to the load balancer.

  • Enable: Specifies a bot defense configuration for you to apply to the load balancer. Follow the instructions listed in the Configure Bot Defense guide to set Bot defense protection for your load balancer.

TheAPI Protection section provides a number of different API protection capabilities.

Step 5.3.1: API Definition.

• From the API Definition menu, select whether to use an API definition. The default value is Disable, meaning an API definition is not used for this load balancer.

• If you select Enable:

  • From the API Definition menu, select the API definition.

  • To create a new definition, click Add item.

Figure: Enable API Definition

• From the Validation menu, select an option to perform OpenAPI specification validation. Following are the options:

  • Disabled: Default option. No validation is performed.

  • All Endpoints: Validate all endpoints listed in the OpenAPI specification file. Any other endpoints not listed will act according to Fall Through Mode.

  • Custom List: Define API groups, base path, or API endpoints and their validation modes. Any other endpoints not listed will act according to Fall Through Mode.

Figure: API Validation Options

Note: OpenAPI Validation is a feature that ensures API traffic complies with the specified schema and can block or report non-compliant traffic. Validation can be configured on a per-endpoint, per-group, or per-base-path basis. The Fall Through Mode allows for identifying and handling Shadow APIs by either blocking, reporting, or allowing them. Allowed IPs list can be created to pass OpenAPI Validation by specific IP addresses.

• From the OpenAPI Validation Processing Mode menu, select whether to Validate or Skip.

• From the Validation Enforcement Type menu, select an option to specify the type of enforcement.

• From the Request Validation Properties menu, select one or multiple options from the following:

  • Query Parameters: The incoming requests are validated against the query parameters specified in the API definition.

  • Path Parameters: The incoming requests are validated against the path parameters specified in the API definition.

  • Content-type: The incoming requests are validated against the content-types specified in the API definition.

  • Cookie Parameters: The incoming requests are validated against the cookie parameters specified in the API definition.

  • HTTP Headers: The incoming requests are validated against the HTTP headers specified in the API definition.

  • HTTP Body: The incoming requests are validated against the HTTP body specified in the API definition.

Figure: Request Validation Properties

• From the Fall Through Mode menu, select an action for every request that targets endpoints which are not in validation list.

Step 5.3.6: Optionally Configure Sensitive Data Exposure Rules.

This feature allows you to specify rules to mask sensitive data in API responses.

• Click Configure in the Sensitive Data Exposure Rules section.

• Click Add Item to create the first rule.

• In the Target section, enter the path that will respond to the request. Also enter one or more methods with responses containing sensitive information.

• In the Values field in the Pattern section, enter the JSON field value you want to mask. For example, given the JSON below is the response,

      { "user": 
        { "Email":"elmer1980@yahoo.com", 
          "ID":1, 
          "altEmails":["elmo@sesamest.com, Mr.E@Muppets.net"]
        } 
      }

Copied!

• To mask the Email value, enter user.Email.
• To mask all emails in the array altEmails, enter user.altEmails[_]. Note that an underscore between the square brackets indicates the array's elements.
• Masked values in the response will be masked as follows: All letters changed to a or A (matching case) and all numbers converted to1. Thus the response example above will be masked as shown below:

      { "user": 
        { "Email":"aaaa1111@aaaaa.aaa", 
          "ID":1, 
          "altEmails":["aaaa@aaaaaaaa.aaa, Aa.A@Aaaaaaa.aaa"]
        } 
      }

Copied!

Figure: Request Validation Properties

Note: To apply masking to nested objects, the exact location of the key must be specified. For the example shown below,

{
   "A": {
       "B": {
           "key1": "val1",
           "key2": "val2"
       }
   }
}

Copied!

the masking configuration should be set as A.B.key1 or A.B.key2, depending on which value you want to mask.

• Click Apply to save the rule to the list of Sensitive Data Exposure Rules.

• Click Add Item to add more rules.

• Click Apply to save the list of rules to your load balancer.

• From the L7 DDoS Auto Mitigation menu, select an option:

  • Default: This option blocks traffic from suspicious sources. No JavaScript challenge is returned.

  • Block: This option blocks traffic from suspicious sources. No JavaScript challenge is returned.

  • JavaScript Challenge: This option serves a JavaScript challenge to all traffic from suspicious sources. Click View Configuration to change the default settings and message for the JavaScript challenge.

• Under DDoS Mitigation Rules, select Configure to open the rules list page. Use Add Item to add a rule:

  • In the DDoS Mitigation Rule page, set a name for the rule.

  • Select a choice for the Mitigation Choice menu. The mitigation choice can be either a list of IP addresses or combination of ASN, Region, and TLS Fingerprinting.

  • Click Apply to add the rule to the list of rules.

  • Click Apply to add the rules list to the DDoS protection configuration.

• From the Slow DDoS Mitigation menu, select an option:

  • For the Custom option, enter Request Headers Timeout and Total Request Timeout values.

Note: See the Explore Security Monitoring section in the Monitor HTTP Load balancer guide to learn more about observing and reacting to an active DDoS attack.

Ensure that this service is enabled for your tenant. See Client-Side Defense for more information and configuration instructions.

Go to Common Security Controls section and perform the following:

Figure: Service Policy Configuration

• From the Service Policies menu, select an option to apply the service policy. The following options are available:

  • Apply Namespace Service Policies: This option applies the service policy to an entire namespace.

  • Do Not Apply Service Policies: This option does not apply any service policy.

  • Apply Specified Service Policies: This option applies a service policy to a specified load balancer, not the entire namespace.

• To apply a specific service policy, select Apply Specified Service Policies, and perform the following:

  • Click Configure.

Figure: Apply Specific Service Policy

• From the Policies menu, select a service policy, and then click Apply.

Figure: Select Specific Service Policy

The IP reputation service analyzes IP threats and publishes a dynamic data set of millions of high-risk IP addresses, to protect users from inbound traffic from malicious IPs. IP threat categories include Spam Sources, Windows Exploits, Web Attacks, BotNets, Scanners, Denial of Service, Reputation, Phishing, Proxy, Mobile Threats, and TOR Proxy.

For more information, see Deny Malicious IPs Using IP Threat Categories.

Threat Mesh provides F5 Distributed Cloud customers with an additional layer of protection against web application attacks. Threat Mesh leverages cross-customer correlation (i.e. correlation of client attacks across different customers) to identify malicious intent of a client. Whenever a client is flagged due to a malicious intent by our WAAP decisions engines, that client will be added to the ThreatDB.

Enabling Threat Mesh means that requests coming into an application from an IP that is in the ThreatDB will be automatically blocked by the load balancer.

Requests that are blocked due to Threat Mesh can be seen and evaluated in the Web App & API Protection service on the Overview > Security > Security Analytics tab for a specific load balancer and the Multi-Cloud App Connect service on the Overview > Applications > Security Analytics tab for a specific load balancer. Blocked requests will show as a Service Policy violation in the Event Type column with Threat Mesh in the Threat Name column. For more information, see Load Balancer Security Monitoring in the Security Analytics section.

From the Threat Mesh drop-down menu, select the Enable or Disable for the feature.

Select a user identifier for rate limiting and malicious user mitigation.

• From the User Identifier drop-down menu, select the method for user identification:

  • Select Client IP Address to use the user's IP address.

  • Select User Identification Policy to use the object to evaluate the identity. To create a new user ID, click Add item from the User Identification Policy menu.

Figure: User ID Policy

Note: For more information, see Configure Rate Limiting per User.

Malicious User Detection performs user behavior analysis and assigns a risk score and threat level of low, medium or high based on the suspicious activity of the user. The risk score of the user is decayed over time, if no further suspicious activity is noticed. The feature can be configured also via external app_type and labeling this HTTP Load Balancer. In this case, the external app_type configuration overrides the internally disabled feature. Enabling the feature internally is allowed only when there is no labeling to an external app_type.

From the Malicious User Detection drop-down menu, select Enable.

• In the Common Security Controls section, enable the Show Advanced Fields option.

• From the Malicious User Mitigation And Challenges drop-down menu, select Enable. This option enables you to configure a challenge for users detected as malicious.

Note: For the JavaScript Challenge, Captcha Challenge, and Policy Based Challenge options, you can enable a challenge for all users and/or requests matching specific conditions. For any of these options, click View Configuration to create that challenge for users/requests that meet specific criteria.

• From the Malicious User Mitigation Settings menu, select an option for malicious users at different threat levels:

  • Default: Applies low, medium, and high levels.

  • Custom: Defines different levels and actions to take. Select an option from the Custom menu. Or click Add Item to create a custom option.

• From the JavaScript Challenge Parameters menu, select the type of JavaScript challenge to enable:

  • JavaScript Challenge Parameters: This option enables you to configure a custom JavaScript challenge for this load balancer. Click Configure. Set the delay value, cookie expiration value, and custom message to use. After you finish, click Apply. For more information, see Configure JavaScript Challenge.

  • Use Default Parameters: This option sets the default challenge with no customization.

• From the Captcha Challenge Parameters menu, select the type of captcha challenge to enable:

  • Use Default Parameters: This option takes the default settings and applies them.

  • Captcha Challenge Parameters: This option enables you to define the challenge parameters. Click Configure. Set the cookie expiration value and the custom message to use. After you finish, click Apply.

Rate Limiting allows you to control the rate of requests sent to your origin servers and protect against API traffic surge and denial of services attacks.

• To configure rate limiting, select an option from the list:

  • Disable: Default option. No rate limiting enabled for this load balancer.

  • API Rate Limit: Set rate limiting for specific API endpoints.

  • Custom Rate Limiting Parameters: Allows you to set custom parameters to rate limit.

Note: For detailed instruction to set up rate limiting, see Configure API Rate Limiting.

These rules define specific clients for which WAF processing and Bot Defense will be skipped. Add rules to allow trusted clients based on the match conditions configured. You can skip WAF, skip bot processing, or both. The match conditions include IP prefix, AS number, and HTTP headers to identify specific clients.

• To configure the Trusted Client Rules option:

  • Click Configure, and then click Add Item.

  • Complete the configuration process to add rules to allow trusted clients and to prevent the WAF from applying the block rules you previously configured.

  • Click Apply.

  • Select the newly created rules option and then click Apply.

You can choose match condition rules, such as IP prefix, AS number, and HTTP headers to identify specific clients to block from accessing your applications.

• To configure the Client Blocking Rules option:

  • Click Configure, and then click Add Item.

  • Complete the configuration process to add rules to block specific clients from making requests.

  • Click Apply.

  • Select the newly created rules option, and then click Apply.

The Cross-Origin Resource Sharing (CORS) policy is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

• In the CORS Policy field, click Configure.

• To enable a specific origin server, click Add item under the Allow Origin field.

• To enable origin servers by regex, click Add item under the Allow Origin Regex field.

• In the Allow Methods field, enter information to be used for the access-control-allow-methods header.

• In the Allow Headers field, enter information to be used for the access-control-allow-headers header.

  Important: When you enable Bot Defense on your HTTP load balancer, Bot Defense adds the following headers to the Allow Headers field in your CORS policy: Xa4vrhYP3Q-a, Xa4vrhYP3Q-a0, Xa4vrhYP3Q-b, Xa4vrhYP3Q-c, Xa4vrhYP3Q-d, Xa4vrhYP3Q-e, Xa4vrhYP3Q-f and Xa4vrhYP3Q-z. These headers are required for Bot Defense to support requests that use CORS.

• In the Expose Headers field, enter information to be used for the access-control-expose-headers header.

Figure: CORS Policy

• In the Maximum Age field, enter information in seconds to cache the headers.

• After you finish, click Apply.

From the VIP Advertisement drop-down menu, select from one of the options available:

• Select Internet to advertise the default VIP on the public network.

• Select Internet (Specified VIP) and enter an IP address in the Public IP field to advertise that IP as VIP on a public network.

• Select Custom. Click Configure in the Advertise Custom field, and then click Add Item for each site you want to advertise. Perform the configuration per the following guidelines for each site:

  • From the Select Where to Advertise menu, select an option for where a load balancer should be advertised.

    • Choose Site:

      • From the Network drop-down menu, choose a network type to be used on the site.
      • Select a Site Reference object from the drop-down menu.
      • Optionally enable the Show Advanced Fields option and enter an IPv4 and/or an IPv6 to be used as the VIP on the site.

    • Choose Virtual Site:

      • From the Network drop-down menu, choose a network type to be used on the site.
      • Select a Site Reference object from the drop-down menu.

    • Choose vK8s Service Network on RE:

      • Select RE or Virtual Site Reference from the drop-down menu.
      • Select a reference (RE or virtual site) from the associated Reference drop-down menu.

    • Choose Virtual Network:

      • Select a network reference from the Network drop-down menu.
      • Select Default V4 VIP or Specific V4 VIP from the Select V4 VIP drop-down menu. If you select a specific one, then enter the specific V4 VIP.
      • Select Default V6 VIP or Specific V4 VIP from the Select V6 VIP drop-down menu. If you select a specific one, then enter the specific V6 VIP.

    • Choose Segment on Site:

      • Select a segment from the Segment drop-down menu.
      • Select a site from the Site drop-down menu.
      • Enter the IPv4 address of the VIP on the site.
      • Enter the IPv6 address of the VIP on the site.

    • Choose Segment on Virtual Site:

      • Select a segment from the Segment drop-down menu.
      • Select a virtual site from the Virtual Site Reference drop-down menu.
      • Enter the IPv4 address of the VIP on the virtual site.
      • Enter the IPv6 address of the VIP on the virtual site.

    • Choose Segment on Cloud Edge:

      • Select a segment from the Segment drop-down menu.
      • Select a cloud edge from the Cloud Edge drop-down menu.
      • Enter the IPv4 address of the VIP on the cloud edge.
      • Enter the IPv6 address of the VIP on the cloud edge.

  • Configure a TCP listener port or select a default option for the TCP Listen Port Choice field. The default option sets port 80 for the HTTP load balancer and 443 for the HTTPS load balancer.

  • Click Apply to save the site to advertise to the list. Then click Apply to save the list of sites to advertise.

• Select Do Not Advertise to disable VIP advertisement.

Note: If you have enabled Internet VIP on the AWS cloud site to allow clients to access Load Balancer VIP directly from the internet, set the VIP Advertisement selection to Custom, and then configure the custom VIP advertisement to advertise on a Site or Virtual Site with Site Network set to either Outside Network with internet VIP or Inside and Outside Network with internet VIP. For more information, see Create AWS Site.

Note: The following ports are not supported for advertising on a Distributed Cloud Services site:

• K8s node port range 28000-32767
• Distributed Cloud Services port range 65000-65535
• 10249
• 10250
• 10251
• 10252
• 10256
• 10257
• 10259
• 1067
• 18091
• 18092
• 18093
• 18095
• 22
• 22222
• 2379
• 23790
• 23791
• 2380
• 23801
• 23802
• 323
• 4500
• 500
• 53
• 5355
• 6443
• 68
• 8005
• 8007
• 8087
• 8443
• 8444
• 8505
• 8507
• 9007
• 9090
• 9153
• 9999

• From the Load Balancing Algorithm menu, set how the HTTP/HTTPS requests are load balanced. The options include:

  • Round Robin: This option sends requests to all eligible servers in a round robin fashion.

  • Least Active Request: This option sends requests to an origin server that has least active requests set.

  • Random: This option sends requests to all origin servers randomly.

  • Source IP Stickiness: This option sends requests to all origin servers using the hash value of the source IP.

  • Cookie Based Stickiness: This option sends requests to all origin servers using the hash value of the cookie. The cookie can be passive or generated. The consistent hashing algorithm, ring hash, is used to select the origin server. Requires you to further configure the parameters.

  • Ring Hash Policy: This option sends requests to all origin servers using the hash value of the request. Requires you to further configure the parameters.

Figure: Load Balancer Control

• If you select Cookie Based Stickiness:

  • In the Name field, enter a name for the cookie.

  • Optionally, set a TTL value in milliseconds and set a path name value.

• If you select Ring Hash Policy:

  • Click Configure to specify a list of hash policies to use.

  • Click Add Item.

  • From the Hash Policy Specifier drop-down menu, select what to apply the hash policy to. The options include:

    • Cookie: Hash policies are applied to a cookie.

    • Header Name: Hash policies are applied to the name of key of the request header used to obtain the hash key.

    • Source IP: Hash policies are applied to the source IP address.

  • In the Name field, enter a name for the cookie that is used to obtain the hash key.

  • To apply the hash policy as a terminal policy, select the Terminal option.

  • Click Apply.

  • Select the newly created hash policy, and then click Apply.

• Select the Enable from the Trusted Client IP Headers drop-down menu.
• Use Add Item button to add one or more headers. The headers are processed in the numerical order they are added, as shown on the page.

When trusted client headers are enabled, system uses real client IP address as the source IP, instead of the proxy's IP address. The following apply when configuring trusted client IP headers:

• When multiple headers are configured, F5 Distributed Cloud platform follows top to bottom precedence. This means initially first header is considered and system checks for its availability in the request. If not present in the request, system proceeds to check for the second header, and so on, until one of the listed headers is found.
• When none of the configured headers exists, or the value of the configured header is not an IP address, then the source IP of the packet is used.
• When multiple IP addresses are available in header value, system reads the rightmost IP address, and considers it as real Client IP address. However, when using the X-Forwarded-For header, and if multiple IPs are available in value, the system reads the rightmost-1 IP address, and considers it as real client IP address.

Note: See Overview of Trusted Client IP Headers in F5 Distributed Cloud Platform for more information.

• Select the Add Location checkbox to specify the regional edge (RE) site name in the header responses.

Figure: Enable RE Site Header Responses

• Click Configure in the More Options field and perform the configuration per the following guidelines:

  • In the Header Options section, click Add Item and add details in each of the request headers and response headers fields to specify add and remove headers accordingly.

  • In the Configure Error Response Options section, click Configure to customize error responses.

  • In the Miscellaneous Options section, click Configure. Complete the configuration options.

• Click Apply.

• Wait for the DNS Info and Certificate status to display the VIRTUAL_HOST_READY and Certificate status Valid values.

Figure: Load Balancer Created

• Verify that the requests to your virtual host domain are processed and load balanced between the configured origin servers.

Note: The Certificate expiration date column displays the expiration date for the certificates. Certificates managed by F5 Distributed Cloud Services are issued for 90 days and auto-renewed after 75 days from the date of issuance.

• Verify that the Certificate status field shows Domain Challenge Pending.

• Click > to view the load balancer information in JSON format.

• Verify that ACME challenge record exists under get_spec > auto_cert_info > dns_records field in the JSON. The record name starts with _acme-challenge and the value is the name of the TXT record created by Distributed Cloud Services.

• Create a CNAME record with the obtained ACME challenge name and value in your DNS server.

• Verify that the Certificate status field value changes to Certificate Valid.

• Verify that the Certificate expiration date field value displays the expiration date for the certificates.