Third-party services and DDoS protection

Using a third-party CDN in front of Cloudflare

Some Cloudflare customers choose to use a Content Delivery Network (CDN) in front of Cloudflare to cache and serve their resources.

Cloudflare recommends that you do not use a third-party CDN in front of Cloudflare. Some CDN providers may introduce subtleties into HTTP requests that deviate from protocol standards and/or protocol best practices. Additionally, because traffic to Cloudflare will originate from a limited set of IP addresses of the third-party CDN, in rare occasions — such as when using the Akamai CDN in front of Cloudflare — it may appear as if the CDN is launching a DDoS attack against Cloudflare due to the amount of traffic from these limited IP addresses.

Therefore, it is recommended that you use the Cloudflare CDN, which provides the following benefits:

• You remove an additional hop between vendor data centers, thus reducing latency for your users.
• You perform DDoS filtering in the first point of contact from the Internet, which is a recommended best practice.

Note that, if you are using a third-party CDN in front of Cloudflare and Cloudflare mitigates a DDoS attack, you will still pay your first-hop CDN provider for the attack traffic that they processed before it was mitigated by Cloudflare.

Recommended DDoS configuration adjustments

If you are using a CDN or proxy in front of Cloudflare, it is recommended that you change the action and/or sensitivity level of the following DDoS rules named:

• HTTP requests with unusual HTTP headers or URI path (signature #1) with the rule ID ...3486aee1
• HTTP requests with unusual HTTP headers or URI path (signature #56) with the rule ID ...e269dfd6
• HTTP requests with unusual HTTP headers or URI path (signature #57) with the rule ID ...f35a42a0
• Requests coming from known bad sources with the rule ID ...3a679c52

You should change the rule’s action to Log (only available on Enterprise plans) to view the flagged traffic in the analytics dashboard. Alternatively, change the rule’s Sensitivity Level to Essentially Off to prevent the rule from being triggered.

For more information, refer to HTTP DDoS Attack Protection managed ruleset: Ruleset configuration.

Using VPNs, NATs, and other third-party services

Some Cloudflare Magic Transit customers operate Virtual Private Networks (VPN) so that their remote employees can connect securely to the organization’s services. Additionally, larger organizations have Network Addressing Translation (NAT) systems that manage connections in and out of their network.

Cloudflare Magic Transit customers may also use third-party services such as Zoom, Webex, Microsoft Teams, and others for their internal organization communication. Because traffic to Cloudflare will be originating from a limited set of IP addresses belonging to these third-party services, it may appear as if the services are launching a DDoS attack against Cloudflare due to the amount of traffic from limited IP addresses.

Additionally, since this traffic may also be targeting a limited set of destinations (for example, the same designated service ports, VPN endpoints, or NAT IP addresses), it may appear as if the CDN is launching a DDoS attack against Cloudflare due to the amount of traffic from a limited set of IPs to a limited set of IPs.

Recommended DDoS configuration adjustments

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 and Network-layer DDoS Attack Protection managed ruleset 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.

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. After gathering this information, you can later define rule adjustments as previously described.