You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/ddos-protection/managed-rulesets/http/http-overrides/override-examples.mdx
+43-49Lines changed: 43 additions & 49 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,11 +26,50 @@ If you have access to filter expressions, you can create an override to target t
26
26
27
27
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).
28
28
29
-
### An end user is experiencing a false positive
29
+
### Legitimate traffic is incorrectly identified as an attack and causes a false positive
30
+
31
+
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.
32
+
33
+
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.
34
+
35
+
To remedy a false positive:
36
+
37
+
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
38
+
2. Go to the analytics dashboard and apply filters to the displayed data.
39
+
<Detailsheader="For WAF/CDN customers">
40
+
3. Select the zone that is experiencing DDoS attack false positives.
41
+
4. Go to **Security** > **Events**.
42
+
5. Select **Add filter** and filter by `Service equals HTTP DDoS`.
43
+
</Details>
44
+
<Detailsheader="For Magic Transit and Spectrum customers">
45
+
6. Go to Account Home > **Analytics & Logs** > **Network Analytics**.
46
+
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.
47
+
</Details>
48
+
8. Scroll down to **Top events by source** > **HTTP DDoS rules**.
49
+
9. Copy the rule name.
50
+
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.
51
+
11. Select **Browse rules** and paste the rule name in the search field.
52
+
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).
53
+
13. Select **Next** and then select **Save**.
54
+
55
+
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/).
56
+
57
+
#### Update the adjusted rules later
58
+
59
+
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.
60
+
61
+
:::note[Recommendation: Enable DDoS alerts]
30
62
31
-
If you observe that one of your end users is experiencing a false positive, you can create an override for the rule that caused the false positive and use the filter expressions to apply it only to the hostname.
63
+
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.
64
+
:::
65
+
66
+
#### Avoid false positives while retaining protection and visibility
32
67
33
-
[INSERT false-positive.mdx PAGE CONTENT HERE]
68
+
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.
69
+
70
+
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.
71
+
72
+
If an override without an expression matches, Cloudflare will not evaluate the expressions that follow it.
34
73
35
74
### An attack is incorrectly identified as legitimate traffic and causes a false negative
36
75
@@ -80,49 +119,4 @@ If you cannot stop an attack from overloading your origin web server using the a
80
119
- Domain/path being targeted (zone name/ID)
81
120
- Attack frequency
82
121
- Steps to reproduce the issue, with actual results versus expected results
83
-
- Any relevant additional information such as site URLs, error messages, screenshots, or relevant logs from your origin web server
84
-
85
-
### Legitimate traffic is incorrectly identified as an attack and causes a false positive
86
-
87
-
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.
88
-
89
-
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.
90
-
91
-
To remedy a false positive:
92
-
93
-
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
94
-
2. Go to the analytics dashboard and apply filters to the displayed data.
95
-
<Detailsheader="For WAF/CDN customers">
96
-
3. Select the zone that is experiencing DDoS attack false positives.
97
-
4. Go to **Security** > **Events**.
98
-
5. Select **Add filter** and filter by `Service equals HTTP DDoS`.
99
-
</Details>
100
-
<Detailsheader="For Magic Transit and Spectrum customers">
101
-
6. Go to Account Home > **Analytics & Logs** > **Network Analytics**.
102
-
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.
103
-
</Details>
104
-
8. Scroll down to **Top events by source** > **HTTP DDoS rules**.
105
-
9. Copy the rule name.
106
-
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.
107
-
11. Select **Browse rules** and paste the rule name in the search field.
108
-
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).
109
-
13. Select **Next** and then select **Save**.
110
-
111
-
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/).
112
-
113
-
#### Update the adjusted rules later
114
-
115
-
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.
116
-
117
-
:::note[Recommendation: Enable DDoS alerts]
118
-
119
-
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.
120
-
:::
121
-
122
-
#### Avoid false positives while retaining protection and visibility
123
-
124
-
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.
125
-
126
-
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.
127
-
128
-
If an override without an expression matches, Cloudflare will not evaluate the expressions that follow it.
122
+
- Any relevant additional information such as site URLs, error messages, screenshots, or relevant logs from your origin web server
0 commit comments