eCDN WAFv2

The Web Application Firewall (WAF) is an important component in mitigating bad actors and protecting your storefront. For details, see eCDN Web Application Firewall.

With WAFv2, you can override specific managed rules and customize each ruleset to meet your specific traffic needs. WAFv2 rulesets are specifically designed to protect against threats such as zero-day vulnerabilities, top-10 attack techniques, use of stolen/exposed credentials, and extraction of sensitive data, and are regularly updated as new vulnerabilities are discovered to improve performance and reduce false positives.

WAFv2 rulesets include:

  • eCDN Managed Ruleset
  • OWASP Managed Ruleset
  • Exposed Credentials Check Ruleset

Business Manager supports eCDN configuration of WAFv2 settings specific to each instance (Development, Staging, Production), which allows you to manage instances individually. When you migrate to, set, or update WAFv2, these changes are not replicated to other instances. This approach simplifies testing and deploying WAFv2 security settings from development and staging to production during transitions.

Ruleset ID: efb7b8c949ac4650a09736fc376e9aee

Created by the eCDN security team, this ruleset provides fast and effective protection for all of your applications. By default, some rules in the ruleset are disabled or set to log by default, to balance providing the right protection with reducing the number of false positives.

You can configure the following settings for this ruleset:

  • Action:
    • default, block, log, managed_challenge, js_challenge, legacy_captcha
  • Enabled:
    • true, false

Ruleset ID: 4814384a9e5d4991b9815dcfc25d2f1f

The OWASP Managed Ruleset is an implementation of the OWASP ModSecurity Core Rule Set (CRS). This ruleset is routinely monitored for OWASP updates, based on the latest version available from the official code repository. The OWASP Managed Ruleset is designed to work as a single entity to calculate a threat score and execute an action based on that score. Individual rules in the OWASP Managed Ruleset do not have their own default action. The ruleset’s action is what is executed if the calculated threat score exceeds the score threshold.

The paranoia level (PL) classifies OWASP rules according to their aggressiveness. Available paranoia levels include:

  • PL1
  • PL2
  • PL3
  • PL4 (most aggressive)

Rules associated with higher paranoia levels are considered more aggressive and provide increased protection. However, they can cause legitimate traffic to get blocked due to false positives. When you configure the paranoia level of the OWASP Managed Ruleset, you are enabling all the rules belonging to all paranoia levels up to the level you select. For example, if you configure the ruleset paranoia level to PL3, you are enabling rules belonging to paranoia levels PL1, PL2, and PL3.

Each OWASP rule that matches the current request has an associated score. The request threat score is the sum of the individual scores of all OWASP rules that matched the request.

The anomaly score threshold (or anomaly score) defines the minimum cumulative score, which is obtained from matching OWASP rules, for the WAF to apply the configured OWASP Managed Ruleset action.

Available score thresholds:

  • Low: 60 and higher
  • Medium: 40 and higher (recommended default value)
  • High: 25 and higher

You can configure the following settings for this ruleset:

  • Action
    • block, log, managed_challenge, js_challenge, legacy_captcha
  • Paranoia Level
    • 1, 2, 3, 4
  • Anomaly Score
    • low, medium, high
  • Enabled
    • true, false

Ruleset ID: c2e184081120413c86c3ab7e14069605

The Exposed Credentials Check Ruleset contains a set of rules that lookup the username/password pair in the request against a database of publicly available stolen credentials. When a request matches a particular rule’s expression and the exposed credentials check is true, the action configured in the rule is performed. For details, see How exposed credentials checks work.

Many web applications have suffered recent attacks in which there is a massive number of login attempts using username/password pairs from databases of exposed credentials. The Exposed Credentials Check Ruleset contains predefined rules for the following CMS applications:

  • WordPress
  • Joomla
  • Drupal
  • Ghost
  • Plone
  • Magento

This managed ruleset also includes generic rules for the following common patterns:

  • Check forms submitted using a POST request containing username and password arguments.
  • Check credentials sent as JSON with email and password keys.
  • Check credentials sent as JSON with username and password keys.

By default, the Exposed Credentials Check Ruleset operates by adding an HTTP header to requests that are flagged by the managed rules in the ruleset (shown as having the rewrite action). The name of the added HTTP header is Exposed-Credential-Check and its value is 1. Your application can then force a password reset, start a two-factor authentication process, or perform any other action. If you wish to challenge or block requests containing exposed credentials, then you can update the ruleset’s action. However, it is strongly recommend to test the Exposed Credentials Check Ruleset in log mode before changing to a different ruleset action.

You can configure the following settings for this ruleset:

  • Action:
    • default, block, log, managed_challenge, js_challenge, legacy_captcha
  • Enabled:
    • true, false

Configuring a managed ruleset can be done via both Business Manager and CDN-API.

When updating the ruleset’s action, selecting an action other than default overrides the action of all managed rules in the ruleset. For example, by default, some rules in the eCDN Managed Ruleset are set to block while others are set to log. If you update the action of the eCDN Managed Ruleset to block, then all rules in the ruleset are set to block. If you wish to change the action of a particular managed rule, you can set an individual rule override.

Similarly, some rules in each managed ruleset are disabled by default. Disabling the entire ruleset will disable all managed rules in the ruleset. However, enabling a ruleset will not enable all rules in the ruleset. Enabling a ruleset maintains each rule’s default status. If you wish to update a rule’s default status, you can set an individual rule override.

  1. Navigate to Embedded CDN Settings. Locate the zone you want to update and navigate to the WAF tab. Verify the zone is using WAFv2.
  2. Update the WAFv2 ruleset settings as needed using the checkboxes and drop-down menus.
  1. Use getWafManagedRulesets to retrieve the WAFv2 managed rulesets and their current configurations by providing the zone ID.

Sample Success Response (200 HttpStatus Code):

  1. Use updateWafManagedRuleset to configure the desired ruleset by providing the zone and ruleset ID. You must provide at least one field in the request body.

Sample Success Response (200 HttpStatus Code):

Configuring individual managed rule overrides must be done using CDN-API.

If you see false positives due to a particular managed rule, you can configure overrides to adjust the rule’s action or default enabled status. Individual managed rule overrides allow you to fine-tune your zone’s WAFv2 configuration beyond the available ruleset-level settings.

  1. Use getWafManagedRulesInRuleset to view all of the rules in a particular managed ruleset by providing the zone and ruleset ID. The response will show the current configuration of each rule, taking into consideration the ruleset’s current action and enabled status. The response will also display the rule’s associated tags (such as wordpress) which are useful when searching for a specific group of rules.

Sample Success Response (200 HttpStatus Code):

  1. Use updateWafManagedRuleInRuleset to configure a rule override by providing the zone, ruleset, and rule ID. You must provide at least one field in the request body.

You can configure the following settings when updating a managed rule:

  • Action:
    • default, block, log, managed_challenge, js_challenge, legacy_captcha
    • The default action will reset any existing action overrides and set the rule back to its default action.
    • The action field is only applicable for the eCDN Managed Ruleset and Exposed Credentials Check Ruleset. Setting an action override is not applicable for the OWASP Managed Ruleset because it operates by calculating a total threat score and then applying the overall ruleset’s action.
  • Enabled:
    • true, false

Sample Success Response (200 HttpStatus Code):

You can migrate to WAFv2 using the Business Manager UI and CDN-API. By default, newly created zones use WAFv2.

You can migrate instances to WAFv2 independently because Business Manager supports eCDN configurations, including WAFv2 settings, specific to each instance (Development, Staging, Production).

Migration to WAFv2 cannot be rolled back.

WAFv2 migration configures the following zone configuration settings:

  • Cloudflare Managed Ruleset
    • Enabled
    • Log
  • OWASP Managed Ruleset
    • Enabled
    • Log
    • PL1
    • Medium
  • Exposed Credentials Check Ruleset
    • Disabled
    • Default

The Cloudflare Managed Ruleset and OWASP Managed Ruleset are set to log. Make sure to test the behavior of the WAFv2 managed ruleset in log mode before switching to a different WAF action. Monitoring the behavior in log mode helps you identify false positives and adjust ruleset settings as needed using either Business Manager or CDN-API.

WAFv2 rules do not have a one-to-one mapping to WAF rules, and existing WAFv1 rule customizations might not be necessary or applicable.

Reevaluate the security settings in log mode as described in Using WAF for the First Time. Review WAF logs using any of the following methods:

For the OWASP Managed Ruleset, we recommend the following WAFv2 settings based on your previous OWASP WAFv1 sensitivity setting:

  1. OWASP WAFv1 Sensitivity High → Paranoia level: PL2; Anomaly score: Medium (40 and higher)
  2. OWASP WAFv1 Sensitivity Medium → Paranoia level: PL1; Anomaly score: High (25 and higher)
  3. OWASP WAFv1 Sensitivity Low → Paranoia level: PL1; Anomaly score: Medium (40 and higher)

WAFv2 default sensitivity settings → Paranoia level: PL2; Anomaly score: Medium (40 and higher)
  1. Navigate to Embedded CDN Settings. Select the zone you want to update and navigate to the WAF tab. This zone should be using WAFv1. Select Start WAFv2 Migration.
  2. Review the information and then select Finish WAFv2 Migration.
  3. A final warning is displayed. Select Confirm WAFv2 Migration. Migration can take up to 60 seconds. After migration completes, a pop-up is displayed.
  1. Use migrateZoneToWafV2 to migrate a zone to WAFv2 by providing the zone ID. The resulting WAFv2 configuration is returned in the response body. Migration may take up to 60 seconds.

Sample Success Response (200 HttpStatus Code):

  • For immediate impact relief, set the ruleset to log.
  • For visibility into WAFv2 firewall events, set up eCDN Logpush with the logType set to firewall_events. You can view logs of firewall events in your zone and get insights into which ruleset and rule(s) are causing the false positives. After you idenitfy the problematic managed rule, use the updateWafManagedRuleInRuleset CDN-API endpoint to override the rule’s action or disable the rule completely.
  • If you are seeing false positives originating from the OWASP Managed Ruleset, you can adjust the ruleset’s paranoia level and score threshold.
  • You can create a custom rule with the skip_wafv2 action to have particular requests skip WAFv2 completely. Any traffic matching the rule expression is not evaluated by WAFv2.