You get full control over who sees what, when and where. Get protected from digital thefts.

Web Application Firewall (WAF)

Many web sites, web applications, and web servers receive and process requests from outside a company's protected internal network. That can result in a variety of malicious attacks including SQL injections, cross-site scripting, and application layer distributed denial of service (DDoS).

This exposure poses a threat to the customer’s infrastructure and the confidentiality, integrity, and availability of the data delivered by those resources over the Internet. These types of attacks can result in unauthorized access to content, the loss of personally identifiable information (PII), and the dissemination of private/copyrighted information.

The Web Application Firewall (WAF) service provides a layer of security between many of these security threats and the customer’s external web infrastructure. Our WAF increases security by monitoring, detecting, and preventing application layer attacks. It inspects inbound HTTP/HTTPS traffic against reactive and proactive security policies and blocks malicious activity in-band and on a real-time basis.

There are various layers to the protection provided to an origin server via Web Application Firewall, such as:

• Inherent protection from DDoS attacks.
- Our worldwide presence establishes an imposing and extensive barrier between an origin server and malicious traffic, regardless of whether it consists of a high-volume HTTP GET flood attack or a slow DDoS attack.
• Protection from application layer attacks.
  - Enable a comprehensive set of threat detection measures for the purpose of identifying malicious traffic. These measures define the types of application layer attacks that will be detected, such as:
  • Protocol validation
  • Malicious client identification
  • Generic attack signatures
  • Known vulnerabilities signatures
  • Trojan/backdoor access
  • Virus and Denial of Service
• Filtering out unwanted traffic by screening for a custom delivery profile.
  - Traffic that doesn’t meet the requirements defined in this HTTP delivery profile may be blocked before it even reaches our core network.
• Establishing traffic restrictions to block malicious traffic.
  - Requests may be whitelisted/blacklisted by IP address, country, URL, and/or referrers.

The diagram below illustrates how traffic is screened before it can ever reach our core network. The distributed nature of our worldwide network provides an additional layer of protection to origin servers. Finally, an intermediate caching layer may be enabled on an origin server as an additional measure to prevent web servers from being overloaded. This capability is known as Origin Shield.



WAF Setup

The manner in which Web Application Firewall should be configured varies by organization due to a variety of factors, such as those listed below.




HTTP Rules Engine

The Media Control Center (MCC) provides many different options that the customer can leverage to configure how his assets are handled by our CDN. However, the customer’s unique working environment may require an additional level of customization. For this reason, we provide an interface through which the customer can create custom rules that will override his MCC configuration and the default behavior of our edge servers. These custom rules can be created to handle how our edge servers cache and grant access to large and small assets.

A rule defines the criteria that a request has to meet before one or more features can take effect. For example, the customer can define a rule that disables caching for PHP assets.

However, when setting up a rule's criteria, the customer should keep in mind that a rule is interpreted as it is laid out. In other words, actions take place as a set of criteria is met. Once a set of criteria has been satisfied, then no additional attempts to match other criteria in the current rule will take place.

Using multiple rules allows the customer to exercise both coarse and granular control over how requests for his assets are handled. For example, the customer could create a rule that determines the default manner through which all requests are handled. After which, he could create a set of rules that determine how certain types of requests are handled for a particular location. In order for this type of configuration to work properly, the customer will need to pay attention to the order in which these rules are listed.

The order in which multiple rules are listed affects how they are handled. Rules are typically processed in the order that they appear. If a client's request satisfies the criteria for more than one rule, then the features associated with the matching criteria for each rule will take place. This could lead to a situation where conflicting actions will take place. In such a case, the last action to take place will take precedence over previous actions. Therefore, it is recommended that the customer place rules that should take precedence as close to the bottom of the list as possible.

The following illustration contains four sample rules that provide different instructions based on the type of request being performed. In this scenario, we'll assume that the client requests an HTML asset from the "Secure" folder on "myhostname.com." This type of request will satisfy the match criteria for all four rules. Therefore, the features associated with each of the rules will be applied to the request. If one or more rules contain conflicting instructions, then the rule closest to the bottom of the list will take precedence. In this sample scenario, the rule called "Apply to All HTML Requests for "myhostname.com" in "Secure" Folder" would take precedence over the other rules.


HTTP Rules Engine can be used to override and/or extend the CDN configuration defined in the MCC and the response headers defined by a web server (e.g., Apache or IIS).

• Web Server (Customer Origin): A web server can define key response headers that will be associated with assets requested through our CDN. For example, a web server can define response headers that control the cache policy for requested assets. HTTP Rules Engine allows the customer to override those response headers to create a custom cache policy for content served through the CDN.
• Default CDN Response Headers: If certain key response headers have not been defined by the origin server, then a default response header value may be assigned to the cached asset and the response returned to the user agent. These default response header values can also be overridden by HTTP Rules Engine.
• MCC: The MCC allows the customer to define how assets can be accessed through the CDN. HTTP Rules Engine can be used to customize the actions that will take place when content is requested on the customer’s account. For example, he can create a rule that prevents users from a particular country or region from requesting content from a customer origin.

The following illustration is of a rule that disables Token-Based Authentication for HTML files.


Token-Based Authentication

If Token-Based Authentication is enabled, then only requests that provide an encrypted token and comply to the requirements specified by that token will be honored. Only requests from clients that provide a valid token and meet its requirements will be honored. FTP transactions are excluded from Token-Based Authentication.