diff --git a/public/__redirects b/public/__redirects index 3046084f2a7f6f7..ac10bb13ce29306 100644 --- a/public/__redirects +++ b/public/__redirects @@ -417,8 +417,16 @@ /ddos-protection/tcp-protection/rule-settings/ /ddos-protection/advanced-ddos-systems/rule-settings/ 301 /ddos-protection/dns-protection/ /ddos-protection/advanced-ddos-systems/overview/advanced-dns-protection/ 301 /ddos-protection/tcp-protection/api/ /ddos-protection/advanced-ddos-systems/api/ 301 - -# dns +/ddos-protection/managed-rulesets/http/configure-api/ /ddos-protection/managed-rulesets/http/http-overrides/configure-api/ 301 +/ddos-protection/managed-rulesets/http/configure-dashboard/ /ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/ 301 +/ddos-protection/managed-rulesets/http/link-configure-terraform/ /ddos-protection/managed-rulesets/http/http-overrides/link-configure-terraform/ 301 +/ddos-protection/managed-rulesets/http/override-expressions/ /ddos-protection/managed-rulesets/http/http-overrides/override-expressions/ 301 +/ddos-protection/managed-rulesets/network/configure-api/ /ddos-protection/managed-rulesets/network/network-overrides/configure-api/ 301 +/ddos-protection/managed-rulesets/network/configure-dashboard/ /ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/ 301 +/ddos-protection/managed-rulesets/network/link-configure-terraform/ /ddos-protection/managed-rulesets/network/network-overrides/link-configure-terraform/ 301 +/ddos-protection/managed-rulesets/network/override-expressions/ /ddos-protection/managed-rulesets/network/network-overrides/override-expressions/ 301 + + # dns /dns/additional-options/cname-flattening/ /dns/cname-flattening/ 301 /dns/additional-options/dnssec/ /dns/dnssec/ 301 /dns/foundation-dns/graphql-analytics/ /dns/additional-options/analytics/ 301 diff --git a/src/content/docs/ddos-protection/about/how-ddos-protection-works.mdx b/src/content/docs/ddos-protection/about/how-ddos-protection-works.mdx index 277c6db268034d5..d15f75f6c38152f 100644 --- a/src/content/docs/ddos-protection/about/how-ddos-protection-works.mdx +++ b/src/content/docs/ddos-protection/about/how-ddos-protection-works.mdx @@ -23,7 +23,7 @@ Cloudflare uses a set of dynamic rules that scan for attack patterns, known atta :::note -You can set an override expression for the [HTTP DDoS Attack Protection](/ddos-protection/managed-rulesets/http/override-expressions/) or [Network-layer DDoS Attack Protection](/ddos-protection/managed-rulesets/network/override-expressions/) managed ruleset to define a specific scope for sensitivity level or action adjustments. +You can set an override expression for the [HTTP DDoS Attack Protection](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/) or [Network-layer DDoS Attack Protection](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/) managed ruleset to define a specific scope for sensitivity level or action adjustments. ::: Once attack traffic matches a rule, Cloudflare's systems will track that traffic and generate a real-time signature to surgically match against the attack pattern and mitigate the attack without impacting legitimate traffic. The rules are able to generate different signatures based on various properties of the attacks and the signal strength of each attribute. For example, if the attack is distributed — that is, originating from many source IPs — then the source IP field will not serve as a strong indicator, and the rule will not choose the source IP field as part of the attack signature. Once generated, the fingerprint is propagated as a mitigation rule to the most optimal location on the Cloudflare global network for cost-efficient mitigation. These mitigation rules are ephemeral and will expire shortly after the attack has ended, which happens when no additional traffic has been matched to the rule. diff --git a/src/content/docs/ddos-protection/best-practices/third-party.mdx b/src/content/docs/ddos-protection/best-practices/third-party.mdx index 396893979061b57..a8532fdb68ff4c4 100644 --- a/src/content/docs/ddos-protection/best-practices/third-party.mdx +++ b/src/content/docs/ddos-protection/best-practices/third-party.mdx @@ -49,6 +49,6 @@ Additionally, since this traffic may also be targeting a limited set of destinat If your organization uses VPNs, NATs, or third-party services at high rates of over 100 Mbps, it is recommended that you one of the following: - Change the **Sensitivity Level** of the relevant rules to a lower level. Changing the level to _Essentially Off_ will prevent the rules from being triggered. Refer to [HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/) and [Network-layer DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/network/) for more information on the available adjustments per ruleset and how to perform them. -- Exclude the desired traffic from the Managed DDoS rule using expression filters. You can exclude a combination of source ports, source IP addresses, destination ports, destination IP addresses, and protocol. For more information, refer to [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/configure-api/). +- Exclude the desired traffic from the Managed DDoS rule using expression filters. You can exclude a combination of source ports, source IP addresses, destination ports, destination IP addresses, and protocol. For more information, refer to [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/). If you are on an Enterprise plan, you can change a rule’s action to _Log_ to view the flagged traffic in the [analytics dashboard](/ddos-protection/reference/analytics/). After gathering this information, you can later define rule adjustments as previously described. diff --git a/src/content/docs/ddos-protection/change-log/index.mdx b/src/content/docs/ddos-protection/change-log/index.mdx index df67f67483a3558..793eab0c5d3e662 100644 --- a/src/content/docs/ddos-protection/change-log/index.mdx +++ b/src/content/docs/ddos-protection/change-log/index.mdx @@ -21,7 +21,7 @@ Cloudflare has a regular cadence of releasing updates and new rules to the DDoS The release cycle for a new rule within the regular cadence follows this process: - Cloudflare adds a new rule configured with the _Log_ action, and announces the rule in the "Scheduled changes" section of each managed ruleset. -- From that point on, if this rule matches any traffic, the matched traffic will be visible in one of the [analytics dashboards](/ddos-protection/reference/analytics/). If you suspect this might be a false positive, you can lower the sensitivity for that rule. Refer to [Handle a false positive](/ddos-protection/managed-rulesets/adjust-rules/false-positive/) for details. +- From that point on, if this rule matches any traffic, the matched traffic will be visible in one of the [analytics dashboards](/ddos-protection/reference/analytics/). If you suspect this might be a false positive, you can lower the sensitivity for that rule. Refer to [override examples](/ddos-protection/managed-rulesets/http/http-overrides/override-examples/#legitimate-traffic-is-incorrectly-identified-as-an-attack-and-causes-a-false-positive) for details. - Cloudflare updates the rule action to mitigate traffic (for example, using the _Block_ action) after a period of at least seven days, usually on a Monday. The exact date is shown in the scheduled changes list. Changes to existing rules follow the same process, except that Cloudflare will create a temporary updated rule (denoted as `BETA` in rule description) before updating the original rule on the next release cycle. diff --git a/src/content/docs/ddos-protection/frequently-asked-questions.mdx b/src/content/docs/ddos-protection/frequently-asked-questions.mdx index 6504629c1d6c825..0f469c7c189248b 100644 --- a/src/content/docs/ddos-protection/frequently-asked-questions.mdx +++ b/src/content/docs/ddos-protection/frequently-asked-questions.mdx @@ -112,11 +112,11 @@ These tools and attacks exploit different aspects of network protocols and behav ## Can I exclude specific user agents from HTTP DDoS protection? -Yes, you can create an [override](/ddos-protection/managed-rulesets/http/override-expressions/) and use the expression fields to match against HTTP requests with the user agent. There are a variety of [fields](/ddos-protection/managed-rulesets/http/override-expressions/#available-expression-fields) that you can use. +Yes, you can create an [override](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/) and use the expression fields to match against HTTP requests with the user agent. There are a variety of [fields](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/#available-expression-fields) that you can use. You can then adjust the [sensitivity level](/ddos-protection/managed-rulesets/http/override-parameters/#sensitivity-level) or [mitigation action](/ddos-protection/managed-rulesets/http/override-parameters/#action). -Refer to the guide on how to [create an override](/ddos-protection/managed-rulesets/http/configure-dashboard/#create-a-ddos-override). +Refer to the guide on how to [create an override](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/#create-a-ddos-override). The use of expression fields is subject to [availability](/ddos-protection/#availability). diff --git a/src/content/docs/ddos-protection/get-started.mdx b/src/content/docs/ddos-protection/get-started.mdx index 47598a11908f73d..c2706ec1384c24e 100644 --- a/src/content/docs/ddos-protection/get-started.mdx +++ b/src/content/docs/ddos-protection/get-started.mdx @@ -14,7 +14,7 @@ In some situations, the default protection offered by DDoS rules may need to be ### Adjust the provided DDoS rules -If one or more DDoS rules provided by Cloudflare affects legitimate traffic, you can adjust them so that they do not perform any mitigation action against this kind of traffic. Follow the steps in [Handle a false positive](/ddos-protection/managed-rulesets/adjust-rules/false-positive/) to reduce the sensitivity level of one or more DDoS rules and allow incoming legitimate traffic. +If one or more DDoS rules provided by Cloudflare affects legitimate traffic, you can adjust them so that they do not perform any mitigation action against this kind of traffic. Follow the steps in [handling a false positive](/ddos-protection/managed-rulesets/http/http-overrides/override-examples/#legitimate-traffic-is-incorrectly-identified-as-an-attack-and-causes-a-false-positive) to reduce the sensitivity level of one or more DDoS rules and allow incoming legitimate traffic. ### Configure additional protection @@ -47,13 +47,13 @@ The _Log_ action is only available to Enterprise customers. ::: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/), and select your account. -2. [Configure all the rules in the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/configure-dashboard/#create-a-ddos-override), setting their action to _Log_. -3. [Configure all the rules in the Network-layer DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/network/configure-dashboard/#create-a-ddos-override), setting the action to _Log_. +2. [Configure all the rules in the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/#create-a-ddos-override), setting their action to _Log_. +3. [Configure all the rules in the Network-layer DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/#create-a-ddos-override), setting the action to _Log_. Alternatively, if you are using the API, define an override at the ruleset level to set the action of all managed ruleset rules to `log` by following these instructions: -- [Configure an override for the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/configure-api/#configure-an-override-for-the-http-ddos-attack-protection-managed-ruleset) -- [Configure an override for the Network-layer DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/network/configure-api/#configure-an-override-for-the-network-layer-ddos-attack-protection-managed-ruleset) +- [Configure an override for the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/#configure-an-override-for-the-http-ddos-attack-protection-managed-ruleset) +- [Configure an override for the Network-layer DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/#configure-an-override-for-the-network-layer-ddos-attack-protection-managed-ruleset) ### 2. Review flagged traffic @@ -66,13 +66,13 @@ Customize the specific managed ruleset rules you identified, changing their sens If you are using the Cloudflare dashboard, refer to: -- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/configure-dashboard/) -- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/configure-dashboard/) +- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/) +- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/) If you are using the API, refer to: -- [Configure HTTP DDoS Attack Protection via API](/ddos-protection/managed-rulesets/http/configure-api/) -- [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/configure-api/) +- [Configure HTTP DDoS Attack Protection via API](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/) +- [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/) When using the API, ensure that you add any required rule overrides without removing the ruleset override you configured in [Step 1](#1-configure-ruleset-actions-to-log). @@ -80,4 +80,4 @@ When using the API, ensure that you add any required rule overrides without remo Revert the change you did in [Step 1](#1-configure-ruleset-actions-to-log), changing the action of each managed ruleset rule back to _Default_ in **Ruleset action**. -Alternatively, if you are using the API, [remove the override](/ddos-protection/managed-rulesets/http/configure-api/#configure-an-override-for-the-http-ddos-attack-protection-managed-ruleset) you previously configured at the ruleset level for each managed ruleset. Ensure that you only remove the ruleset override and not any of the rule overrides you may have configured in [Step 3](#3-customize-managed-ruleset-rules). +Alternatively, if you are using the API, [remove the override](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/#configure-an-override-for-the-http-ddos-attack-protection-managed-ruleset) you previously configured at the ruleset level for each managed ruleset. Ensure that you only remove the ruleset override and not any of the rule overrides you may have configured in [Step 3](#3-customize-managed-ruleset-rules). diff --git a/src/content/docs/ddos-protection/managed-rulesets/adaptive-protection.mdx b/src/content/docs/ddos-protection/managed-rulesets/adaptive-protection.mdx index 71c419828443969..82353f29b6177c3 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/adaptive-protection.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/adaptive-protection.mdx @@ -45,7 +45,7 @@ Cloudflare may change the logic of these protection rules from time to time to i Cloudflare’s network is built to automatically monitor and mitigate large DDoS attacks. Cloudflare also helps mitigate smaller DDoS attacks, based on the following general rules: -- For zones on any plan, Cloudflare will apply mitigations when the HTTP error rate is above the _High_ (default) sensitivity level of 1,000 errors-per-second rate threshold. You can decrease the sensitivity level by [configuring the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/configure-dashboard/). +- For zones on any plan, Cloudflare will apply mitigations when the HTTP error rate is above the _High_ (default) sensitivity level of 1,000 errors-per-second rate threshold. You can decrease the sensitivity level by [configuring the HTTP DDoS Attack Protection managed ruleset](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/). - For zones on Pro, Business, and Enterprise plans, Cloudflare performs an additional check for better detection accuracy: the errors-per-second rate must also be at least five times the normal origin traffic levels before applying DDoS mitigations. Cloudflare determines the error rate based on all HTTP errors in the 52X range (Internal Server Error) and in the 53X range, except for [error 530](/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-530). Currently, for DDoS mitigations based on HTTP error rate, you cannot exclude specific HTTP error codes. @@ -90,8 +90,8 @@ You can adjust the action and sensitivity of the Adaptive DDoS Protection rules. To configure a rule, refer to the instructions in the following pages: -- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/configure-dashboard/) (for L7 rules) -- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/configure-dashboard/) (for L3/4 rules) +- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/) (for L7 rules) +- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/) (for L3/4 rules) For more information on the available configuration parameters, refer to the following pages: diff --git a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-negative.mdx b/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-negative.mdx deleted file mode 100644 index 483c5c552e7e2f2..000000000000000 --- a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-negative.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -pcx_content_type: how-to -title: Handle a false negative or an incomplete mitigation -description: Learn how to handle false negatives and incomplete mitigations in Cloudflare DDoS Protection. Adjust rules to ensure effective attack mitigation. -sidebar: - order: 3 - ---- - -import { Details, GlossaryTooltip } from "~/components" - -## False negatives - -A false negative is a lack of identification. In the case of DDoS protection, there is a false negative when attack traffic is mistakenly classified as legitimate traffic and is not mitigated. This can occur when the attack traffic is not sufficiently high to trigger mitigation actions or if there are no rules matching the attack. - -To address a false negative: - -- If you are a WAF/CDN customer, follow the steps in the [Respond to DDoS attacks](/ddos-protection/best-practices/respond-to-ddos-attacks/) page, which guides you on enabling the _Under Attack_ mode and creating rate limiting rules and WAF custom rules as needed. -- If you are a Magic Transit customer, [use Magic Firewall rules](/magic-firewall/how-to/add-rules/) to help mitigate the attack. - -## Incomplete mitigations - -An incomplete mitigation is a case when the DDoS protection systems have applied mitigation, but not all the attack was mitigated. This can happen when Cloudflare's systems apply a mitigation action that is less strict than what the attack requires. - -The system chooses the mitigation action based on the logic and the DDoS protection system's confidence that the traffic is indeed part of an attack: - -- For high-confidence rules, the system will apply a strict mitigation action such as the _Block_ action. -- For low-confidence rules, the system will apply a less strict mitigation rule such as _Challenge_ or _Force Connection Close_. - -If you are experiencing a DDoS attack detected by Cloudflare and the applied mitigation action is not sufficiently strict, change the rule action to _Block_: - -1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. -2. Go to the analytics dashboard and apply filters to the displayed data. -
- 3. Select the zone that is experiencing an incomplete mitigation of a DDoS attack. - 4. Go to **Security** > **Events**. - 5. Select **Add filter** and filter by `Service equals HTTP DDoS`. -
-
- 6. Go to Account Home > **Analytics & Logs** > **Network Analytics**. - 7. Identify the DDoS attack that is having incomplete mitigations. Use the Attack ID number included in the DDoS alert (if you received one), or apply dashboard filters such as destination IP address and port. -
-8. Scroll down to **Top events by source** > **HTTP DDoS rules**. -9. Copy the rule name. -10. Go to your zone > **Security** > **DDoS** and select **Deploy a DDoS override**. If you cannot deploy any additional overrides, edit an existing override to adjust rule configuration. -11. Select **Browse rules** and paste the rule name in the search field. -12. Change the rule’s **Action** to *Block*. -13. Select **Next** and then select **Save**. - -Once saved, the rule takes effect within one or two minutes. The rule adjustment should provide immediate remedy, which you can view in the [analytics dashboard](/ddos-protection/reference/analytics/). - -### Alternate procedure - -If you cannot stop an attack from overloading your origin web server using the above steps, [contact Cloudflare Support](/support/contacting-cloudflare-support/) for assistance, providing the following details: - -- Time period of the attack (UTC timestamp) -- Domain/path being targeted (zone name/ID) -- Attack frequency -- Steps to reproduce the issue, with actual results versus expected results -- Any relevant additional information such as site URLs, error messages, screenshots, or relevant logs from your origin web server \ No newline at end of file diff --git a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-positive.mdx b/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-positive.mdx deleted file mode 100644 index 7d81b2b84a3a3d9..000000000000000 --- a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/false-positive.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -pcx_content_type: how-to -title: Handle a false positive -description: Learn how to handle false positives in Cloudflare DDoS Protection. Adjust rules to prevent service disruptions from legitimate traffic misclassified as attacks. -sidebar: - order: 2 - ---- - -import { Details } from "~/components" - -A false positive is an incorrect identification. In the case of DDoS protection, there is a false positive when legitimate traffic is mistakenly classified as attack traffic. This can occur when legacy applications, Internet services, or faulty client applications generate legitimate traffic that appears suspicious, has odd traffic patterns, deviates from best practices, or violates protocols. - -In these cases, Cloudflare’s DDoS Protection systems may flag that traffic as malicious and apply mitigation actions. If the traffic is in fact legitimate and not part of an attack, the mitigation actions can cause service disruptions and outages to your Internet properties. - -To remedy a false positive: - -1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. -2. Go to the analytics dashboard and apply filters to the displayed data. -
- 3. Select the zone that is experiencing DDoS attack false positives. - 4. Go to **Security** > **Events**. - 5. Select **Add filter** and filter by `Service equals HTTP DDoS`. -
-
- 6. Go to Account Home > **Analytics & Logs** > **Network Analytics**. - 7. Identify the legitimate traffic that is causing the false positives. Use the Attack ID number included in the DDoS alert (if you received one), or apply dashboard filters such as destination IP address and port. -
-8. Scroll down to **Top events by source** > **HTTP DDoS rules**. -9. Copy the rule name. -10. Go to your zone > **Security** > **DDoS** and select **Deploy a DDoS override**. If you cannot deploy any additional overrides, edit an existing override to adjust rule configuration. -11. Select **Browse rules** and paste the rule name in the search field. -12. Decrease the rule’s **Sensitivity Level** to _Essentially Off_ or change the rule action to _Log_ (if supported by your current plan and subscriptions). -13. Select **Next** and then select **Save**. - -Once saved, the rule takes effect within one or two minutes. The rule adjustment should provide immediate remedy, which you can view in the [analytics dashboard](/ddos-protection/reference/analytics/). - -## Update the adjusted rules later - -Later, you can change the [sensitivity level](/ddos-protection/managed-rulesets/network/override-parameters/#sensitivity-level) of the rule causing the false positives to avoid future issues, and change the rule action back to its default value. - -:::note[Recommendation: Enable DDoS alerts] - -Cloudflare recommends that you create notifications for [DDoS alerts](/ddos-protection/reference/alerts/) to get real-time notifications on detected and mitigated attacks automatically performed by Cloudflare’s systems. When you receive these notifications, you can review if it is in fact a real DDoS attack, or if it is a false positive, and then take action to remedy it. -::: - -## Use cases - -### Avoid false positives while retaining protection and visibility - -To see what DDoS Managed Rules do in a high sensitivity level while remaining protected by blocking attacks at a low sensitivity level, Advanced DDoS protection customers can [create a first override](/ddos-protection/managed-rulesets/network/configure-dashboard/#create-a-ddos-override) that blocks attacks at a low sensitivity and a second override to log at a high sensitivity. - -The overrides must be set in that order. Otherwise, it will not work. This is because overrides are evaluated in order and will stop at the first override that matches both expression and sensitivity. Setting the overrides in the wrong order would cause the `Log` override at a high sensitivity to match all instances. As a result, Cloudflare will never evaluate the `Block` override that would be placed behind it, causing all rules to be set in `Log` mode. - -If an override without an expression matches, Cloudflare will not evaluate the expressions that follow it. diff --git a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/index.mdx deleted file mode 100644 index 640c3c89694da3f..000000000000000 --- a/src/content/docs/ddos-protection/managed-rulesets/adjust-rules/index.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -pcx_content_type: navigation -title: Adjust DDoS rules -sidebar: - order: 6 - ---- - -import { DirectoryListing } from "~/components" - -Refer to the following pages for more information about adjusting DDoS rules according to your situation: - - diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/configure-api.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-api.mdx similarity index 99% rename from src/content/docs/ddos-protection/managed-rulesets/http/configure-api.mdx rename to src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-api.mdx index dfec12f7d765ea9..e42a4607cabc227 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/configure-api.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-api.mdx @@ -2,7 +2,7 @@ title: Configure via API pcx_content_type: concept sidebar: - order: 3 + order: 2 head: - tag: title content: Configure HTTP DDoS Attack Protection via API diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/configure-dashboard.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard.mdx similarity index 95% rename from src/content/docs/ddos-protection/managed-rulesets/http/configure-dashboard.mdx rename to src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard.mdx index 73fb9528e99b458..24b9f9c306a98ad 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/configure-dashboard.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard.mdx @@ -2,7 +2,7 @@ title: Configure in the dashboard pcx_content_type: how-to sidebar: - order: 2 + order: 1 head: - tag: title content: Configure HTTP DDoS Attack Protection in the dashboard @@ -32,7 +32,7 @@ If you cannot deploy any additional overrides, consider editing an existing over 4. Enter a descriptive name for the override in **Override name**. 5. If you are an Enterprise customer with the Advanced DDoS Protection subscription: 1. Under **Override scope**, review the scope of the override — by default, all incoming requests for the current zone. - 2. If necessary, select **Edit scope** and configure the [custom filter expression](/ddos-protection/managed-rulesets/http/override-expressions/) that will determine the override scope. + 2. If necessary, select **Edit scope** and configure the [custom filter expression](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/) that will determine the override scope. 6. Depending on what you wish to override, refer to the following sections (you can perform both configurations on the same override):
7. To always apply a given action for all the rules in the ruleset, select an action in **Ruleset action**. diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/index.mdx new file mode 100644 index 000000000000000..5fde8fc914adcf7 --- /dev/null +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/index.mdx @@ -0,0 +1,13 @@ +--- +title: Overrides +pcx_content_type: concept +sidebar: + order: 4 +head: + - tag: title + content: HTTP DDoS Attack Protection override rules +--- + +import { Render } from "~/components" + + diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/link-configure-terraform.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/link-configure-terraform.mdx similarity index 94% rename from src/content/docs/ddos-protection/managed-rulesets/http/link-configure-terraform.mdx rename to src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/link-configure-terraform.mdx index b3175d8ebf5e9f9..c01042f86b6f1fc 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/link-configure-terraform.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/link-configure-terraform.mdx @@ -3,5 +3,5 @@ pcx_content_type: navigation title: Configure using Terraform external_link: /terraform/additional-configurations/ddos-managed-rulesets/#example-configure-http-ddos-attack-protection sidebar: - order: 4 + order: 3 --- diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx new file mode 100644 index 000000000000000..6cdd113dc609db4 --- /dev/null +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx @@ -0,0 +1,122 @@ +--- +title: Override examples +pcx_content_type: reference +sidebar: + order: 5 +head: + - tag: title + content: Override examples for HTTP DDoS Attack Protection +--- + +import { Details, GlossaryTooltip } from "~/components" + +## Use cases + +The following scenarios detail how you can make use of override rules as a solution to common HTTP DDoS Protection issues. + +### Traffic from your mobile application is blocked by a DDoS Managed Rule + +The traffic from your mobile application may have appeared suspicious, causing a DDoS Managed Rule to block it. + +You should identify the Managed Rule blocking the traffic and change the sensitivity level to `Medium`. If traffic continues to be blocked by the managed rule, set the sensitivity level to `Low` or `Essentially off`. + +If you have access to filter expressions, you can create an override to target the specific affected traffic. + +### Traffic is flagged by an adaptive rule based on the location and may be an attack + +If you recognize that the traffic flagged by an adaptive rule may be considered an attack, you can create an override rule to enable the adaptive rule in mitigation mode to `challenge` (if it is browser traffic) or `block` (for other suspicious traffic). + +### Legitimate traffic is incorrectly identified as an attack and causes a false positive + +A false positive is an incorrect identification. In the case of DDoS protection, there is a false positive when legitimate traffic is mistakenly classified as attack traffic. This can occur when legacy applications, Internet services, or faulty client applications generate legitimate traffic that appears suspicious, has odd traffic patterns, deviates from best practices, or violates protocols. + +In these cases, Cloudflare’s DDoS Protection systems may flag that traffic as malicious and apply mitigation actions. If the traffic is in fact legitimate and not part of an attack, the mitigation actions can cause service disruptions and outages to your Internet properties. + +To remedy a false positive: + +1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. +2. Go to the analytics dashboard and apply filters to the displayed data. +
+ 3. Select the zone that is experiencing DDoS attack false positives. + 4. Go to **Security** > **Events**. + 5. Select **Add filter** and filter by `Service equals HTTP DDoS`. +
+
+ 6. Go to Account Home > **Analytics & Logs** > **Network Analytics**. + 7. Identify the legitimate traffic that is causing the false positives. Use the Attack ID number included in the DDoS alert (if you received one), or apply dashboard filters such as destination IP address and port. +
+8. Scroll down to **Top events by source** > **HTTP DDoS rules**. +9. Copy the rule name. +10. Go to your zone > **Security** > **DDoS** and select **Deploy a DDoS override**. If you cannot deploy any additional overrides, edit an existing override to adjust rule configuration. +11. Select **Browse rules** and paste the rule name in the search field. +12. Decrease the rule’s **Sensitivity Level** to _Essentially Off_ or change the rule action to _Log_ (if supported by your current plan and subscriptions). +13. Select **Next** and then select **Save**. + +Once saved, the rule takes effect within one or two minutes. The rule adjustment should provide immediate remedy, which you can view in the [analytics dashboard](/ddos-protection/reference/analytics/). + +#### Update the adjusted rules later + +Later, you can change the [sensitivity level](/ddos-protection/managed-rulesets/network/override-parameters/#sensitivity-level) of the rule causing the false positives to avoid future issues, and change the rule action back to its default value. + +:::note[Recommendation: Enable DDoS alerts] + +Cloudflare recommends that you create notifications for [DDoS alerts](/ddos-protection/reference/alerts/) to get real-time notifications on detected and mitigated attacks automatically performed by Cloudflare’s systems. When you receive these notifications, you can review if it is in fact a real DDoS attack, or if it is a false positive, and then take action to remedy it. +::: + +#### Avoid false positives while retaining protection and visibility + +To see what DDoS Managed Rules do in a high sensitivity level while remaining protected by blocking attacks at a low sensitivity level, Advanced DDoS protection customers can [create a first override](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/#create-a-ddos-override) that blocks attacks at a low sensitivity and a second override to log at a high sensitivity. + +The overrides must be set in that order. Otherwise, it will not work. This is because overrides are evaluated in order and will stop at the first override that matches both expression and sensitivity. Setting the overrides in the wrong order would cause the `Log` override at a high sensitivity to match all instances. As a result, Cloudflare will never evaluate the `Block` override that would be placed behind it, causing all rules to be set in `Log` mode. + +If an override without an expression matches, Cloudflare will not evaluate the expressions that follow it. + +### An attack is incorrectly identified as legitimate traffic and causes a false negative + +A false negative is a lack of identification. In the case of DDoS protection, there is a false negative when attack traffic is mistakenly classified as legitimate traffic and is not mitigated. This can occur when the attack traffic is not sufficiently high to trigger mitigation actions or if there are no rules matching the attack. + +To address a false negative: + +- If you are a WAF/CDN customer, follow the steps in the [Respond to DDoS attacks](/ddos-protection/best-practices/respond-to-ddos-attacks/) page, which guides you on enabling the _Under Attack_ mode and creating rate limiting rules and WAF custom rules as needed. +- If you are a Magic Transit customer, [use Magic Firewall rules](/magic-firewall/how-to/add-rules/) to help mitigate the attack. + +### Incomplete mitigations + +An incomplete mitigation is a case when the DDoS protection systems have applied mitigation, but not all the attack was mitigated. This can happen when Cloudflare's systems apply a mitigation action that is less strict than what the attack requires. + +The system chooses the mitigation action based on the logic and the DDoS protection system's confidence that the traffic is indeed part of an attack: + +- For high-confidence rules, the system will apply a strict mitigation action such as the _Block_ action. +- For low-confidence rules, the system will apply a less strict mitigation rule such as _Challenge_ or _Force Connection Close_. + +If you are experiencing a DDoS attack detected by Cloudflare and the applied mitigation action is not sufficiently strict, change the rule action to _Block_: + +1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. +2. Go to the analytics dashboard and apply filters to the displayed data. +
+ 3. Select the zone that is experiencing an incomplete mitigation of a DDoS attack. + 4. Go to **Security** > **Events**. + 5. Select **Add filter** and filter by `Service equals HTTP DDoS`. +
+
+ 6. Go to Account Home > **Analytics & Logs** > **Network Analytics**. + 7. Identify the DDoS attack that is having incomplete mitigations. Use the Attack ID number included in the DDoS alert (if you received one), or apply dashboard filters such as destination IP address and port. +
+8. Scroll down to **Top events by source** > **HTTP DDoS rules**. +9. Copy the rule name. +10. Go to your zone > **Security** > **DDoS** and select **Deploy a DDoS override**. If you cannot deploy any additional overrides, edit an existing override to adjust rule configuration. +11. Select **Browse rules** and paste the rule name in the search field. +12. Change the rule’s **Action** to *Block*. +13. Select **Next** and then select **Save**. + +Once saved, the rule takes effect within one or two minutes. The rule adjustment should provide immediate remedy, which you can view in the [analytics dashboard](/ddos-protection/reference/analytics/). + +#### Alternate procedure + +If you cannot stop an attack from overloading your origin web server using the above steps, [contact Cloudflare Support](/support/contacting-cloudflare-support/) for assistance, providing the following details: + +- Time period of the attack (UTC timestamp) +- Domain/path being targeted (zone name/ID) +- Attack frequency +- Steps to reproduce the issue, with actual results versus expected results +- Any relevant additional information such as site URLs, error messages, screenshots, or relevant logs from your origin web server \ No newline at end of file diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/override-expressions.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-expressions.mdx similarity index 99% rename from src/content/docs/ddos-protection/managed-rulesets/http/override-expressions.mdx rename to src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-expressions.mdx index fd8b25cfb82a358..f2cfc912ceee965 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/override-expressions.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-expressions.mdx @@ -2,7 +2,7 @@ title: Override expressions pcx_content_type: reference sidebar: - order: 7 + order: 4 head: - tag: title content: Override expressions for HTTP DDoS Attack Protection diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/index.mdx index 3d3d3078e87fc70..b2d94c4d49e9319 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/index.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/index.mdx @@ -3,7 +3,7 @@ title: HTTP DDoS Attack Protection pcx_content_type: concept description: Explore HTTP DDoS Attack Protection rule categories, including botnets, unusual requests, and advanced features, to enhance your Cloudflare security. sidebar: - order: 3 + order: 1 head: - tag: title content: HTTP DDoS Attack Protection managed ruleset @@ -19,7 +19,7 @@ The HTTP DDoS Attack Protection managed ruleset provides users with increased ob ## Ruleset configuration -If you are expecting large spikes of legitimate traffic, consider customizing your DDoS protection settings to avoid [false positives](/ddos-protection/managed-rulesets/adjust-rules/false-positive/), where legitimate traffic is falsely identified as attack traffic and blocked/challenged. +If you are expecting large spikes of legitimate traffic, consider customizing your DDoS protection settings to avoid [false positives](/ddos-protection/managed-rulesets/http/http-overrides/override-examples/#legitimate-traffic-is-incorrectly-identified-as-an-attack-and-causes-a-false-positive), where legitimate traffic is falsely identified as attack traffic and blocked/challenged. You can adjust the behavior of the rules in the managed ruleset by modifying the following parameters: @@ -35,8 +35,8 @@ You can adjust the behavior of the rules in the managed ruleset by modifying the To adjust rule behavior, do one of the following: -- [Configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/http/configure-dashboard/). -- [Configure the managed ruleset via API](/ddos-protection/managed-rulesets/http/configure-api/). +- [Configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/). +- [Configure the managed ruleset via API](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/). - [Configure the managed ruleset using Terraform](/terraform/additional-configurations/ddos-managed-rulesets/#example-configure-http-ddos-attack-protection). For more information on the available configuration parameters, refer to [Managed ruleset parameters](/ddos-protection/managed-rulesets/http/override-parameters/). @@ -61,7 +61,7 @@ All HTTP errors in the 52x range (Internal Server Error) and all errors in the 5 The HTTP DDoS Attack Protection managed ruleset protects Cloudflare customers on all plans for zones [onboarded to Cloudflare](/dns/zone-setups/full-setup/). All customers can customize the ruleset both at the zone level and at the account level. -Customers on Enterprise plans with the Advanced DDoS Protection subscription can create up to 10 overrides (or up to 10 rules, for API users) with custom [expressions](/ddos-protection/managed-rulesets/http/override-expressions/), to customize the DDoS protection for different incoming requests. +Customers on Enterprise plans with the Advanced DDoS Protection subscription can create up to 10 overrides (or up to 10 rules, for API users) with custom [expressions](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/), to customize the DDoS protection for different incoming requests. Other customers can only create one override (or rule) and they cannot customize the rule expression. In this case, the single override, containing one or more configurations, will always apply to all incoming traffic. diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/override-parameters.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/override-parameters.mdx index 226bd167437298f..09051988ba33af9 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/override-parameters.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/override-parameters.mdx @@ -2,7 +2,7 @@ title: Parameters pcx_content_type: reference sidebar: - order: 6 + order: 2 head: - tag: title content: HTTP DDoS Attack Protection parameters @@ -11,7 +11,7 @@ head: import { Render } from "~/components" -Configure the HTTP DDoS Attack Protection managed ruleset to change the action applied to a given attack or modify the sensitivity level of the detection mechanism. You can [configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/http/configure-dashboard/) or [define overrides via Rulesets API](/ddos-protection/managed-rulesets/http/configure-api/). +Configure the HTTP DDoS Attack Protection managed ruleset to change the action applied to a given attack or modify the sensitivity level of the detection mechanism. You can [configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/) or [define overrides via Rulesets API](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/). The available parameters are the following: diff --git a/src/content/docs/ddos-protection/managed-rulesets/http/rule-categories.mdx b/src/content/docs/ddos-protection/managed-rulesets/http/rule-categories.mdx index 5f5c7673ea8c661..cda80c0339723b4 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/http/rule-categories.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/http/rule-categories.mdx @@ -2,7 +2,7 @@ title: Rule categories pcx_content_type: reference sidebar: - order: 5 + order: 3 head: - tag: title content: Rule categories — HTTP DDoS diff --git a/src/content/docs/ddos-protection/managed-rulesets/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/index.mdx index 21df9ae87033426..3cc98aa01eba3ec 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/index.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/index.mdx @@ -27,4 +27,4 @@ Only available on Business and Enterprise plans. When Cloudflare creates a new managed rule, we check the rule impact against the traffic of Business and Enterprise zones while the rule is not blocking traffic yet. -If a [false positive](/ddos-protection/managed-rulesets/adjust-rules/false-positive/) is detected, we proactively reach out to the affected customers and help them make configuration changes (for example, to lower the sensitivity level of the new rule) before the rule starts mitigating traffic. This prevents the new rule from causing service disruptions and outages to your Internet properties. +If a [false positive](/ddos-protection/managed-rulesets/http/http-overrides/override-examples/#legitimate-traffic-is-incorrectly-identified-as-an-attack-and-causes-a-false-positive) is detected, we proactively reach out to the affected customers and help them make configuration changes (for example, to lower the sensitivity level of the new rule) before the rule starts mitigating traffic. This prevents the new rule from causing service disruptions and outages to your Internet properties. diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/index.mdx index 28a671ae9780172..32e063fe342a096 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/network/index.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/network/index.mdx @@ -27,13 +27,13 @@ Adjust the behavior of the rules in the managed ruleset by modifying the followi To adjust rule behavior, use one of the following methods: -- [Configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/network/configure-dashboard/). -- [Configure the managed ruleset via Cloudflare API](/ddos-protection/managed-rulesets/network/configure-api/). +- [Configure the managed ruleset in the Cloudflare dashboard](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/). +- [Configure the managed ruleset via Cloudflare API](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/). - [Configure the managed ruleset using Terraform](/terraform/additional-configurations/ddos-managed-rulesets/#example-configure-network-layer-ddos-attack-protection). You can only configure the behavior of the managed ruleset to set a stronger mitigation action or a lower sensitivity. Refer to [Managed ruleset parameters](/ddos-protection/managed-rulesets/network/override-parameters/) for more information. -Overrides can apply to all packets or to a subset of incoming packets, depending on the override expression. Refer to [Override expressions](/ddos-protection/managed-rulesets/network/override-expressions/) for more information. +Overrides can apply to all packets or to a subset of incoming packets, depending on the override expression. Refer to [Override expressions](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/) for more information. ## Availability diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/configure-api.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/configure-api.mdx similarity index 99% rename from src/content/docs/ddos-protection/managed-rulesets/network/configure-api.mdx rename to src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/configure-api.mdx index d996d432a457b0c..98b3c46d3d53a14 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/network/configure-api.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/configure-api.mdx @@ -123,7 +123,6 @@ The response returns the created (or updated) phase entry point ruleset. } ``` -
For more information on defining overrides for managed rulesets using the Rulesets API, refer to [Override a managed ruleset](/ruleset-engine/managed-rulesets/override-managed-ruleset/). diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/configure-dashboard.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard.mdx similarity index 100% rename from src/content/docs/ddos-protection/managed-rulesets/network/configure-dashboard.mdx rename to src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard.mdx diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/index.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/index.mdx new file mode 100644 index 000000000000000..77dd2c963d36d02 --- /dev/null +++ b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/index.mdx @@ -0,0 +1,13 @@ +--- +title: Overrides +pcx_content_type: concept +sidebar: + order: 4 +head: + - tag: title + content: Network DDoS Attack Protection override rules +--- + +import { Render } from "~/components" + + diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/link-configure-terraform.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/link-configure-terraform.mdx similarity index 100% rename from src/content/docs/ddos-protection/managed-rulesets/network/link-configure-terraform.mdx rename to src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/link-configure-terraform.mdx diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-examples.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-examples.mdx new file mode 100644 index 000000000000000..d8b8eb339dec5e1 --- /dev/null +++ b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-examples.mdx @@ -0,0 +1,28 @@ +--- +title: Override examples +pcx_content_type: reference +sidebar: + order: 6 +head: + - tag: title + content: Override examples for Network-layer DDoS Attack Protection + +--- + +import { Details, GlossaryTooltip } from "~/components" + +## Use cases + +The following scenarios detail how you can make use of override rules as a solution to common Network DDoS Protection issues. + +### VPN traffic is blocked by a UDP rule + +If you have VPN traffic concentrated to a single or a few single destination IP addresses and the traffic is being blocked by a UDP rule, you can create an override rule for the UDP rule to the destination IPs or ranges. + +:::note +The override only applies to the fingerprint and not the detection. Refer to [Important remarks](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/#important-remarks) for more information. +::: + +### Attack traffic is flagged by the adaptive rule based on UDP and destination port + +If you recognize that the traffic flagged by the adaptive rule based on UDP and destination port is an attack, you create an override rule to enable the adaptive rule in mitigation mode, setting the action to block the traffic. \ No newline at end of file diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/override-expressions.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-expressions.mdx similarity index 99% rename from src/content/docs/ddos-protection/managed-rulesets/network/override-expressions.mdx rename to src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-expressions.mdx index b2f0cdcdb742a00..42d378fb8cba568 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/network/override-expressions.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/network/network-overrides/override-expressions.mdx @@ -2,7 +2,7 @@ title: Override expressions pcx_content_type: reference sidebar: - order: 7 + order: 5 head: - tag: title content: Override expressions for Network-layer DDoS Attack Protection diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/override-parameters.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/override-parameters.mdx index f50027b67b34262..27ae7b13e90facc 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/network/override-parameters.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/network/override-parameters.mdx @@ -2,7 +2,7 @@ title: Parameters pcx_content_type: reference sidebar: - order: 6 + order: 2 head: - tag: title content: Network-layer DDoS Attack Protection parameters @@ -11,7 +11,7 @@ head: import { Render } from "~/components" -Define overrides for the Network-layer DDoS Attack Protection managed ruleset to change the action applied to a given attack or modify the sensitivity level of the detection mechanism. You can [define overrides in the Cloudflare dashboard](/ddos-protection/managed-rulesets/network/configure-dashboard/) or [define overrides via Rulesets API](/ddos-protection/managed-rulesets/network/configure-api/). +Define overrides for the Network-layer DDoS Attack Protection managed ruleset to change the action applied to a given attack or modify the sensitivity level of the detection mechanism. You can [define overrides in the Cloudflare dashboard](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/) or [define overrides via Rulesets API](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/). The available parameters are the following: diff --git a/src/content/docs/ddos-protection/managed-rulesets/network/rule-categories.mdx b/src/content/docs/ddos-protection/managed-rulesets/network/rule-categories.mdx index 42251281d90c4af..7037457361b56c2 100644 --- a/src/content/docs/ddos-protection/managed-rulesets/network/rule-categories.mdx +++ b/src/content/docs/ddos-protection/managed-rulesets/network/rule-categories.mdx @@ -2,7 +2,7 @@ title: Rule categories pcx_content_type: reference sidebar: - order: 5 + order: 3 head: - tag: title content: Rule categories — Network-layer DDoS diff --git a/src/content/docs/learning-paths/data-center-protection/post-prefix-fine-tuning.mdx b/src/content/docs/learning-paths/data-center-protection/post-prefix-fine-tuning.mdx index d217db69524019d..776fc8e78f83bb6 100644 --- a/src/content/docs/learning-paths/data-center-protection/post-prefix-fine-tuning.mdx +++ b/src/content/docs/learning-paths/data-center-protection/post-prefix-fine-tuning.mdx @@ -13,7 +13,7 @@ On this page, you can find suggestions to monitor your prefix advertisements and [These rules](/ddos-protection/managed-rulesets/adaptive-protection/) are based on a seven-day rolling window. We recommend reviewing the logs from these adaptive rules in Network Analytics seven days after your last prefix advertisement. -If you see matches for legitimate traffic, consider lowering the sensitivity of the rule and then review the logs again. Once you are satisfied that legitimate traffic is not being flagged, [create a DDoS override](/ddos-protection/managed-rulesets/network/configure-dashboard/#create-a-ddos-override) for this rule with action as `DDOS Dynamic` or `Block`. +If you see matches for legitimate traffic, consider lowering the sensitivity of the rule and then review the logs again. Once you are satisfied that legitimate traffic is not being flagged, [create a DDoS override](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/#create-a-ddos-override) for this rule with action as `DDOS Dynamic` or `Block`. ### Advanced TCP Protection and Advanced DNS Protection diff --git a/src/content/docs/learning-paths/data-center-protection/troubleshooting.mdx b/src/content/docs/learning-paths/data-center-protection/troubleshooting.mdx index eaf282f6b62161d..733b56a64503d33 100644 --- a/src/content/docs/learning-paths/data-center-protection/troubleshooting.mdx +++ b/src/content/docs/learning-paths/data-center-protection/troubleshooting.mdx @@ -50,7 +50,7 @@ If you suspect that Cloudflare mitigations might be dropping legitimate traffic 3. In the **All traffic** tab select **Add filter** to configure the filters for the traffic-flow in question — like source IP, destination IP and protocol/ports. 4. Check the analytics results to determine which Cloudflare mitigation system has dropped the traffic — for example, DDoS Managed Rules, Advanced TCP/DNS Protection or Magic Firewall. 5. If the traffic was dropped by DDoS Managed Rules: - - Check whether the rule that dropped the traffic is customizable. If it is, go to [DDoS Overrides](/ddos-protection/managed-rulesets/network/configure-dashboard/#create-a-ddos-override). There, you can create/amend an existing override to ensure that this endpoint IP is added to the override with a lower sensitivity applied. + - Check whether the rule that dropped the traffic is customizable. If it is, go to [DDoS Overrides](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/#create-a-ddos-override). There, you can create/amend an existing override to ensure that this endpoint IP is added to the override with a lower sensitivity applied. - If this rule is not customizable and is part of Cloudflare's always-on standard DDoS mitigations, reach out to Cloudflare support team to request for assistance on this. 6. If the traffic was dropped by Advanced TCP Protection (ATP): - If the mode for the global rule is **Mitigation** you can set up a filter for `monitoring` so that ATP will not drop traffic for this particular traffic flow. diff --git a/src/content/docs/learning-paths/prevent-ddos-attacks/advanced/customize-security.mdx b/src/content/docs/learning-paths/prevent-ddos-attacks/advanced/customize-security.mdx index b1292196c806607..c5c8879951b3b9e 100644 --- a/src/content/docs/learning-paths/prevent-ddos-attacks/advanced/customize-security.mdx +++ b/src/content/docs/learning-paths/prevent-ddos-attacks/advanced/customize-security.mdx @@ -10,7 +10,7 @@ Another way of reducing origin traffic is customizing the Cloudflare WAF and oth To reduce incoming malicious requests, you could: - Create [WAF custom rules](/waf/custom-rules/) for protection based on specific aspects of incoming requests. -- Adjust DDoS rules to handle [false negatives and false positives](/ddos-protection/managed-rulesets/adjust-rules/). +- Adjust DDoS rules to handle [false negatives and false positives](/ddos-protection/managed-rulesets/http/http-overrides/override-examples/). - Build [rate limiting rules](/waf/rate-limiting-rules/) to protect against specific patterns of requests. - Enable [bot protection](/bots/get-started/) or set up [Bot Management for Enterprise](/bots/get-started/bot-management/) to protect against automated abuse. - Explore [network-layer DDoS attack protection](/ddos-protection/managed-rulesets/network/). diff --git a/src/content/docs/ruleset-engine/managed-rulesets/override-managed-ruleset.mdx b/src/content/docs/ruleset-engine/managed-rulesets/override-managed-ruleset.mdx index 9f968ad371f546c..98a29fad5cbec10 100644 --- a/src/content/docs/ruleset-engine/managed-rulesets/override-managed-ruleset.mdx +++ b/src/content/docs/ruleset-engine/managed-rulesets/override-managed-ruleset.mdx @@ -19,8 +19,8 @@ If you are using Terraform, refer to the following pages: To define overrides in the Cloudflare dashboard, refer to the following resources: - [Configure a WAF managed ruleset in the dashboard](/waf/managed-rules/deploy-zone-dashboard/#configure-a-managed-ruleset) -- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/configure-dashboard/) -- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/configure-dashboard/) +- [Configure HTTP DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/http/http-overrides/configure-dashboard/) +- [Configure Network-layer DDoS Attack Protection in the dashboard](/ddos-protection/managed-rulesets/network/network-overrides/configure-dashboard/) ## Working with overrides diff --git a/src/content/docs/ruleset-engine/reference/phases-list.mdx b/src/content/docs/ruleset-engine/reference/phases-list.mdx index 322bb58ff715234..653319f2b459999 100644 --- a/src/content/docs/ruleset-engine/reference/phases-list.mdx +++ b/src/content/docs/ruleset-engine/reference/phases-list.mdx @@ -15,7 +15,7 @@ The following tables list the [phases](/ruleset-engine/about/phases/) of Cloudfl | Phase name | Used in product/feature | | ---------------- | ------------------------------------------------------------------------------------------------ | -| `ddos_l4` | [Network-layer DDoS Attack Protection](/ddos-protection/managed-rulesets/network/configure-api/) | +| `ddos_l4` | [Network-layer DDoS Attack Protection](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/) | | `magic_transit` | [Magic Firewall](/magic-firewall/how-to/add-rules/) | | `mt_managed` | [Magic Firewall managed rulesets](/magic-firewall/how-to/enable-managed-rulesets/) | | `mt_ids_managed` | [Magic Firewall Intrusion Detection System (IDS)](/magic-firewall/about/ids/) | diff --git a/src/content/docs/security/rules.mdx b/src/content/docs/security/rules.mdx index 564566fdb61f0c3..ff8141c685be0bc 100644 --- a/src/content/docs/security/rules.mdx +++ b/src/content/docs/security/rules.mdx @@ -45,8 +45,8 @@ The **DDoS Protection** tab shows the multiple DDoS mitigation services provided To learn more about DDoS protection overrides, refer to the following resources: -- [HTTP DDoS attack protection overrides](/ddos-protection/managed-rulesets/http/override-expressions/) -- [Network-layer DDoS attack protection overrides](/ddos-protection/managed-rulesets/network/override-expressions/) +- [HTTP DDoS attack protection overrides](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/) +- [Network-layer DDoS attack protection overrides](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/) :::note You define overrides for the Network-layer DDoS attack protection managed ruleset at the account level in Account Home > **L3/4 DDoS** > **Network-layer DDoS Protection**. diff --git a/src/content/docs/security/settings.mdx b/src/content/docs/security/settings.mdx index 51d8b727bf89a32..04cf842d40b4aa3 100644 --- a/src/content/docs/security/settings.mdx +++ b/src/content/docs/security/settings.mdx @@ -34,8 +34,8 @@ The **DDoS protection** security module shows the multiple DDoS mitigation servi To learn more about DDoS protection overrides, refer to the following resources: -- [HTTP DDoS attack protection overrides](/ddos-protection/managed-rulesets/http/override-expressions/) -- [Network-layer DDoS attack protection overrides](/ddos-protection/managed-rulesets/network/override-expressions/) +- [HTTP DDoS attack protection overrides](/ddos-protection/managed-rulesets/http/http-overrides/override-expressions/) +- [Network-layer DDoS attack protection overrides](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/) :::note You define overrides for the Network-layer DDoS attack protection managed ruleset at the account level in Account Home > **L3/4 DDoS** > **Network-layer DDoS Protection**. diff --git a/src/content/docs/terraform/additional-configurations/ddos-managed-rulesets.mdx b/src/content/docs/terraform/additional-configurations/ddos-managed-rulesets.mdx index b6947fc333bad46..e9bf8673b7073d4 100644 --- a/src/content/docs/terraform/additional-configurations/ddos-managed-rulesets.mdx +++ b/src/content/docs/terraform/additional-configurations/ddos-managed-rulesets.mdx @@ -21,8 +21,8 @@ DDoS managed rulesets are always enabled. Depending on your Cloudflare services, If you are using the Cloudflare API, refer to the following resources: -- [Configure HTTP DDoS Attack Protection via API](/ddos-protection/managed-rulesets/http/configure-api/) -- [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/configure-api/) +- [Configure HTTP DDoS Attack Protection via API](/ddos-protection/managed-rulesets/http/http-overrides/configure-api/) +- [Configure Network-layer DDoS Attack Protection via API](/ddos-protection/managed-rulesets/network/network-overrides/configure-api/) For more information on deploying and configuring rulesets using the Rulesets API, refer to [Work with managed rulesets](/ruleset-engine/managed-rulesets/) in the Ruleset Engine documentation. diff --git a/src/content/partials/ddos-protection/managed-rulesets/create-override.mdx b/src/content/partials/ddos-protection/managed-rulesets/create-override.mdx index 424b052ff266fda..a1a54d21eb310e9 100644 --- a/src/content/partials/ddos-protection/managed-rulesets/create-override.mdx +++ b/src/content/partials/ddos-protection/managed-rulesets/create-override.mdx @@ -8,7 +8,7 @@ import { Details, Render } from "~/components" 2. Go to Account Home > **L3/4 DDoS** > **Network-layer DDoS Protection**. 3. Select **Deploy a DDoS override**. 4. In **Set scope**, specify if you wish to apply the override to all incoming packets or to a subset of the packets. -5. If you are creating an override for a subset of the incoming packets, define the [custom expression](/ddos-protection/managed-rulesets/network/override-expressions/) that matches the incoming packets you wish to target in the override, using either the Rule Builder or the Expression Editor. +5. If you are creating an override for a subset of the incoming packets, define the [custom expression](/ddos-protection/managed-rulesets/network/network-overrides/override-expressions/) that matches the incoming packets you wish to target in the override, using either the Rule Builder or the Expression Editor. 6. Select **Next**. 7. Depending on what you wish to override, refer to the following sections (you can perform both configurations on the same override):
diff --git a/src/content/partials/ddos-protection/override-logic.mdx b/src/content/partials/ddos-protection/override-logic.mdx new file mode 100644 index 000000000000000..b87f433f4b6d6b9 --- /dev/null +++ b/src/content/partials/ddos-protection/override-logic.mdx @@ -0,0 +1,75 @@ +--- +{} + +--- + +When Cloudflare's DDoS Protection systems detect an attack, mitigations are emitted against it. Each mitigation has a single managed rule from the managed ruleset associated with it. + +All mitigations and its associated managed rules are evaluated in order by DDoS Protection systems one by one. + +You can create only one override ruleset that can contain one or multiple override rules. An override rule instructs the DDoS Protection system on the action it should take based on its matching managed rule. + +For each active mitigation that is linked to a single managed rule, Cloudflare will go through all of the override rules defined in the override ruleset until one matches the managed rule, and apply the action and stop at that point. Otherwise, evaluation will continue in order until a rule matches. + +However, within an override rule, specificity matters. If the override rule has the following two elements defined, then DDoS Protection systems will prioritize specificity when evaluating overrides: + +- All of the managed rules in the ruleset are set to a specific action. +- A managed rule within that ruleset is set to a different action from the rest of the rules. + +## Examples + +### General example + +A managed ruleset contains the following managed rules: + +- Managed rule 1 +- Managed rule 2 +- Managed rule 3 + +An override ruleset contains the following override rules: + +- Override rule 1 + - Managed rule 1 is set to `block` +- Override rule 2 + - *All managed rules* are set to `challenge` + - Managed rule 1 is set to `log` + - Managed rule 2 is set to `log` +- Override rule 3 + - Managed rule 3 is set to `log` + +If DDoS Protection triggers three mitigations — one linked with an individual managed rule — then the override for each mitigation is evaluated one by one. + +**Mitigation 1 linked with managed rule 1** + +Since managed rule 1 matches override rule 1, Cloudflare will `block` the attacks and not proceed with the rest of the rules. + +**Mitigation 2 linked with managed rule 2** + +Since managed rule 2 does not match override rule 1, Cloudflare will proceed to override rule 2. + +Override rule 2 matches both *All managed rules* and managed rule 2, but specificity takes precedent. It does not `challenge` as dictated by *All managed rules* and instead proceeds with `log` since it matches the most specific managed rule. + +**Mitigation 3 linked with managed rule 3** + +Since managed rule 3 does not match override rule 1, Cloudflare will proceed to override rule 2. + +Override rule 2 sets *All managed rules* to `challenge`, so Cloudflare challenges the attack and does not proceed to override rule 3. + +--- + +### Sensitivity example + +An additional dimension to take into account is Cloudflare will apply a given Override Rule only if its conditions are met, which includes the Sensitivity level. + +While the override rule needs to match and modify the correct managed rule (or all managed rules in the case of mitigation 3 above), it also has to meet the specified Sensitivity level of the rule. + +- Override rule 1 + - All managed rules are set to `challenge` at `low` sensitivity + +- Override rule 2 + - Managed rule 1 is set to `log` at `default` sensitivity. + +**Scenario**: You receive a small attack below the threshold for `low` sensitivity, but above the threshold for `high` sensitivity on managed rule 1. + +- Override rule 1 does not meet the `low` sensitivity threshold. Therefore, we do not match the override and do not mitigate the attack, but proceed to evaluate the next managed rule in case the override rules instruct DDoS Protection to mitigate. +- Override rule 2 sets `log` at default visibility, which matches the condition, so the defined action is applied and attack traffic is logged.