WAF Frequently Asked Questions

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:

• Define the type of requests that will be secured.
• Reuse configurations when securing different applications.

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.).

  Learn more.

• Threats based off of custom criteria.

  Learn more.

  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.

• Traffic generated by basic bots.

Create a rate rule that defines a rate limit and add it to your Security Application Manager configuration.

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.

View our IP blocks (Customer Origin Group / Legacy).

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:

  • Do not violate your access controls.
  • Do not exceed your rate limit.
  • Do not violate the structure of a valid HTTP request.

  Threat detection workflow:

  

WAF configuration is modular and very flexible. It allows you to:

• Apply the same security configuration to all of your traffic.
• Tune your security configuration for each desired application.
• Tune your security configuration for specific types of requests (e.g., URLs) to a particular site or domain.

The recommended approach for securing site traffic requires performing the following steps:

1. Create an access rule that identifies legitimate or suspicious traffic by country, referrer, IP address, etc.
2. Create a rate rule to ensure that requests do not overload your application.
3. Create a bot rule to filter out traffic generated by basic bots.
4. Create a custom rule that defines custom criteria for identifying threats. Take into consideration your site's traffic profile when crafting this criteria to avoid false positives.
5. Create a managed rule that provides generic protection against a variety of unknown vulnerabilities.
6. Create a Security Application Manager configuration that identifies the application whose traffic will be screened by host, URL path, or both. Add the above rules and set their production action to Alert only.
7. Monitor the Rates dashboard. Verify that legitimate traffic flows unimpeded to your application.
8. Wait until a representative sampling of traffic has been screened (e.g., 24 hours).
9. Monitor the Threats dashboard. Verify that alerts are not generated for legitimate traffic.
10. Once the frequency of false positives reaches an acceptable level, modify the Security Application Manager configuration to block malicious traffic by setting the production action for its access rule and managed rule to Block request.

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.

1. Create a Security Application Manager configuration for each application that requires a different screening process.
2. Add the desired access rule, bot rule, custom rule, managed rule, and rate rule(s) to it. Configure the production action for the access rule, custom rule, and managed rule to Alert only.
3. Wait until a representative sampling of traffic has been screened (e.g., 24 hours).
4. Monitor the Threats dashboard. Verify that alerts are not generated for legitimate traffic.
5. Adjust the access rule, custom rule, and managed rule as needed to reduce false positives.
6. Once the frequency of false positives reaches an acceptable level, modify the Security Application Manager configuration to block malicious traffic by setting the production action for its access rule, custom rule, and managed rule to Block request.

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.

Learn more.

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.

View policies.

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.

1. Create a managed rule that is configured to automatically opt-in to the latest ECRS rule set.
2. Identify the Security Application Manager configuration that corresponds to the application whose traffic will be screened.
3. Set that Security Application Manager configuration's Audit Managed Rule option to the above managed rule.
4. Wait until a representative sampling of traffic has been screened (e.g., 24 hours).
5. Monitor the Threats dashboard for false positives.
6. If the level of false positives is acceptable, update the above Security Application Manager configuration's Production Managed Rule option to the above managed rule.

Control the flow of requests through the following steps:

1. Create a rate rule that:

   • Determines whether it will be applied to aggregate traffic, each unique client, or each unique client's user agentRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link). (e.g., web browser).
   • Defines the rate at which requests will be limited.
   • Defines conditions, if any, that must be met before a request qualifies for rate limiting.
2. Identify the Security Application Manager configuration that corresponds to the application whose traffic will be rate limited.
3. Add the above rate rule to that Security Application Manager configuration and define the type of action that will be applied to eligible requests when the rate limit is exceeded.

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.

Example

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:

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.

Sample Scenario

This scenario assumes the following configuration:

• A Security Application Manager configuration that matches all hostnames and URL paths.

• A rate rule that:

  • Identifies unique clients by IP address.
  • Has a rate limit of 8 requests per second.
  • Does not contain condition groups.

It also assumes the following traffic levels for a single client:

• ADN: 5 requests per second
• HTTP Large: 10 requests per second

The above client will be rate limited as follows:

• The client's ADN traffic will not be rate limited.
• The client's HTTP Large traffic will be rate limited to 8 requests per second.

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.

View our IP blocks (Customer Origin Group / Legacy).

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.

Learn more.

Event log data is available for 30 days.

Event log data for the last 30 days is available either through the dashboard or our REST API service.

Learn more (threats).

Learn more (rates).

• Content Delivery

  • ADN
  • IPv6
  • Cache Management
  • Rules Engine

• Security

  • CDN Security
  • MCC Security
  • Origin Shield
  • Token-Based Authentication
  • Web Application Firewall (WAF)

• Streaming

  • Dynamic Cloud Packaging
• Raw Logs
• Route (DNS)
• Storage