Web Application Firewall (Legacy) Frequently Asked Questions

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.

WAF may be configured 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 about our ECRS policies.

WAF screens traffic and then either alerts, blocks, redirects, or provides a custom response when a malicious request is detected. Leverage Rate Limiting to prevent your web server(s) from being overloaded by too many requests.

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 set of traffic that will be screened by WAF varies according to these factors:

• Your configuration.

  Rules Engine identifies a set of requests (e.g., all traffic or only traffic that flows through a specific site) and the security policy that will be enforced on them.

  Learn more.

• Type of threat detection.

  WAF's primary purpose is to protect your web servers. It does this by screening traffic that will flow 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 each request meets the following criteria defined within your profile:

  • It does not violate the structure of a valid HTTP request.
  • It does not qualify as a malicious request as defined by your active policies and rules.

  Additionally, WAF enforces your access control configuration across all traffic (i.e., cache hits and misses). This prevents blacklisted traffic from accessing your content.

WAF configuration is very flexible. It allows you to tailor the traffic profiles that will be protected by each WAF configuration. This provides you with the ability to:

• Apply a single WAF configuration to all of your traffic.
• Tune your WAF configuration for each desired site or domain.
• Tune your WAF 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 a profile.
2. Create an instance that alerts when malicious site traffic is found.
3. Create a rule that determines when WAF security will be applied to your site's traffic.
4. Monitor the WAF dashboard. Verify that alerts are not generated for legitimate traffic.
5. Once the frequency of false positives reaches an acceptable level, modify the instance to block malicious traffic.

You may configure WAF to screen your traffic using two different profiles. This type of setup, known as Dual WAF, 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.

Rules Engine identifies the types of requests that will be screened by WAF and the WAF policy that will be used to screen those requests. Leveraging Rules Engine to screen traffic allows WAF security policy to vary according to the type of traffic. For example, a CMS-specific policy may be enabled for CMS traffic and disabled for all other traffic.

The following table describes the length of time it takes for changes to your WAF configuration to take effect.

The role of Rules Engine in a WAF setup is to determine the type of requests that will be secured by WAF. As a result, it should not require frequent updates. Typically, updates to profiles and instances fine-tune your WAF configuration. These type of updates take effect in a relatively short time period. This allows you to quickly react to newly identified security threats.

Rules defined within Rules Engine take effect before WAF. Rules that may conflict with a WAF configuration typically involve blocking or modifying certain types of requests. For example, Rules Engine may block a request even though it qualifies for whitelisting via WAF.

All profiles must be associated with a rule set. A profile's rule set may be defined upon creating or modifying a profile.

The recommend rule set is ECRS. This rule set provides protection against a variety of application-specific and unknown vulnerabilities.

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 Rules Engine). Leaving these policies enabled may introduce false positives.

View the recommended rule set configuration.

The ECRS rule set is updated as needed to address new threats.

Our recommendation is to always use the latest version of a rule set. However, care should be taken when making changes to a profile that is being leveraged by WAF to filter site traffic. Modifying such a profile will alter how WAF filters HTTP traffic.

The recommended approach for updating a profile's rule set is through the following process:

1. Create a copy of the desired profile.

   Make sure that the new profile leverages the latest version of the rule set.

2. Create a new instance that leverages the newly created profile.

   Set the Production Action option to "alert."

3. From within Rules Engine, update a rule to include an additional Web Application Firewall feature that leverages the new instance.
   1. Edit the rule that enables WAF.
   2. Add a Web Application Firewall feature under the existing one.
   3. Point the new Web Application Firewall feature to the newly created instance.
   4. Save your changes. Once the rule has been approved, it may take up to an hour for the new rule to take effect.
4. Monitor the WAF dashboard for false positives.
5. If the level of false positives is acceptable, update the original profile to use the new version of the rule set and then remove the duplicate Web Application Firewall feature from your rule.

The recommended approach to minimizing false positives is summarized below.

1. Create a profile for each type of request that requires a different screening process.
2. Create an instance for each profile created in step 1. Make sure to set each instance to only alert when a threat is detected.

3. From within Rules Engine, add ruleRules Engine: Refers to a set of statements that identify a set of requests and the manner in which those requests will be handled.s or rule statementRules Engine: Refers to the set of conditional expressions & conditions that identify a single type of request. The last conditional expression in a statement should contain a set of actions that will be applied to that request type.s that identify specific types of requests and the instances that will be leveraged when screening that traffic.

4. Wait until a representative sampling of traffic has been screened (e.g., 24 hours).
5. Use the dashboard to review the detected threats. Adjust the corresponding profiles as needed.

Learn more.

The user experience for requests blocked by WAF is described below.

• The user will receive a 403 Forbidden instead of the requested asset.
• The response for the blocked request will include an additional response header. The name of this response header is defined by the corresponding profile's Response Header Name option. This response header will be set to "403."

Default WAF response header name/value:

Event log data is available for 30 days.

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

Learn more about our REST API service.

• Content Delivery

  • ADN
  • IPv6
  • Cache Management
  • Rules Engine

• Security

  • CDN Security
  • MCC Security
  • Origin Shield
  • Rate Limiting
  • Token-Based Authentication
  • WAF

• Streaming

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