Show search and navigation.
WAF is our latest security offering. It expands upon all of the capabilities offered by WAF (Legacy) and Rate Limiting (Legacy) with a simplified and centralized setup that allows you to:
WAF is designed to analyze HTTP traffic for malicious content. Upon detecting a threat, it will either generate an alert, block, redirect, or provide a custom response. Blocked requests will terminate at the edge of our network. This shields your origin serverRefers to the server(s) where content served via the CDN is stored. There are two types of origin servers, which are CDN and customer origin servers. All requests that cannot be fulfilled directly by an edge server are forwarded to an origin server. For example, a request for content that has not been previously cached is forwarded from an edge server to an origin server. from these threats.
Yes. Please contact your CDN account manager to activate WAF on your account.
No. WAF, which is a cloud-based platform that runs on our CDN, is designed to detect and prevent malicious traffic from reaching your web servers. By enforcing your security logic on the edge of our network, WAF is able to efficiently protect your web applications.
Add a managed rule, custom rule, or both to your Security Application Manager configuration to detect:
A wide variety of threats ranging from application-specific (e.g., IIS, WordPress, Drupal, etc.) to generic attacks (e.g., HTTP request violations, Java, SQL injections, etc.).
Threats based off of custom criteria.
The Custom rules capability requires WAF Premier or WAF Standard. If you currently have WAF Essentials or WAF Insights and would like to use custom rules, please contact your CDN account manager to upgrade to the full version.
Yes. WAF only protects traffic that is routed via our CDN. It is considered a security best practice to obfuscate your web servers to prevent malicious actors from directly attacking your web servers and thereby bypassing the various security measures provided by our CDN.
Set up your firewall to only allow requests from our network.
The latency due to WAF screening traffic can be measured in sub-milliseconds. Users should not be able to perceive a difference in the performance of secured traffic when compared to traffic that is not secured by WAF.
The factors that determine the set of traffic that will be screened are:
Your Security Application Manager configuration.
A Security Application Manager configuration identifies a set of requests (e.g., all traffic or application-specific traffic) and the security policy that will be enforced on them.
Type of threat detection.
WAF's primary purpose is to protect your applications. It does this by screening traffic that flows to your web servers (i.e., cache missesIndicates that the requested content could not be served immediately from the edge of our network because it either hasn't been cached or its TTL has expired. This type of request is forwarded to an origin server.) to verify that it does not qualify as a malicious request as defined within a managed rule and a custom rule.
Additionally, WAF screens cache hits and misses to ensure that those requests:
Threat detection workflow:
WAF configuration is modular and very flexible. It allows you to:
The recommended approach for securing site traffic requires performing the following steps:
You may configure a Security Application Manager configuration to audit a new access rule, managed rule, and custom rule. This type of setup allows you to test changes to your WAF configuration while still ensuring that your traffic is protected by WAF with a known configuration. Once you have vetted your changes and eliminated false positives, you may then quickly enforce the new configuration on your production traffic.
Changes to your security configuration take approximately 2 minutes to take effect.
The recommended approach to minimizing false positives is summarized below.
You may configure a Security Application Manager configuration to audit a new access rule, custom rule, and managed rule. This type of setup allows you to test changes to your WAF configuration while still ensuring that your traffic is protected by WAF with a known configuration. Once you have vetted your changes and eliminated false positives, you may then quickly enforce the new configuration on your production traffic.
A managed rule identifies a rule set that contains a set of policies that define how site traffic may be screened for malicious traffic.
Create a managed rule and then select it as your Security Application Manager configuration's production managed rule.
Yes. The ECRS rule set contains a variety of policies that are application-specific. Those policies should be disabled if they do not apply to the traffic being filtered by WAF (as defined by a Security Application Manager configuration). Leaving these policies enabled may introduce false positives.
The ECRS rule set is updated as needed to address new threats.
Our recommendation is to verify that the latest version of a rule set does not introduce a significant number of false positives and then enforce it on your production traffic.
The recommended approach for applying a new rule set to a Security Application Manager configuration is described below.
A rate rule defines a rate limit.
Control the flow of requests through the following steps:
Create a rate rule that:
The Apply rate limit to option determines how requests will be counted against a rate limit and therefore should be taken into strong consideration when defining a rate limit.
All clients are treated as a single source. The defined rate limit will be applied across all clients.
Each client is treated as a separate entity. The defined rate limit will be applied to each client.
IP address and user agent
Unique User Agent
Each user agent (e.g., web browser) within a client is treated as a separate entity. The defined rate limit will be applied to each unique combination of client and user agent.
A rate limit of 20 requests per minute may make sense for unique clients or user agents. However, it is too restrictive when rate limiting all traffic as a single source (i.e., Any request).
A request counts towards a rate limit when it satisfies all of the following conditions:
Security Application Manager
It must satisfy the hostname match condition defined within a Security Application Manager configuration that uses that rate rule.
Security Application Manager
It must satisfy the URL path match condition defined within a Security Application Manager configuration that uses that rate rule.
All of the conditions defined within at least one condition group.
If a rate rule does not contain conditions, then the Security Application Manager configuration determines whether a request qualifies for rate limiting.
All CDN traffic, regardless of delivery platform, is eligible for rate limiting.
WAF evaluates traffic from each delivery platformIdentifies the environment through which your content will be efficiently delivered to your users. (i.e., HTTP Large, HTTP Small, or ADN) separately. As a result, requests to each delivery platform are counted separately.
This scenario assumes the following configuration:
A rate rule that:
It also assumes the following traffic levels for a single client:
The above client will be rate limited as follows:
A rate rule and the Security Application Manager configuration associated with it defines the type of requests whose flow should be restricted. No further instruction is provided on how rate limiting should be applied to these requests. As a result, WAF must assume that all identified requests should be treated equally. In order to apply a rate limit equally to all eligible requests, it calculates the percentage of requests that exceed the rate limit and then applies a user-defined action to that percentage of eligible traffic. This enforcement action is applied randomly without regard to the order in which requests are received.
For example, if the rate limiting policy is exceeded by 10%, then an enforcement action will be applied to 10% of eligible requests.
No. It may take up to a couple of minutes before the enforcement of a rate limit takes place.
WAF will process rate rules in the order in which they are listed. Once a rule is satisfied, it will be applied to the request and no additional rate rules will be processed.
It is recommended to order rate rules according to how they identify requests. Stricter rules that identify requests using multiple conditions should be placed closer to the top of the list, while catch-all rules should be placed closer to the bottom. This ensures that rules are applied to requests as intended.
Yes, a rate rule only limits traffic that is routed via our CDN. It is considered a security best practice to obfuscate your web servers to prevent malicious actors from directly attacking your web servers and thereby bypassing the various security measures provided by our CDN.
Set up your firewall to only allow requests from our network.
A Security Application Manager configuration determines the action that will take place when a rule is violated. You may customize this enforcement action for each rule associated with your Security Application Manager configuration.
If you are auditing an access rule or managed rule, then rule violations will only generate alerts. Review these alerts from the Threats dashboard.
Event log data is available for 30 days.