1 of 20
2 of 20
3 of 20
4 of 20
5 of 20
6 of 20
7 of 20
8 of 20
9 of 20
10 of 20
11 of 20
12 of 20
13 of 20
14 of 20
15 of 20
16 of 20
17 of 20
18 of 20
19 of 20
20 of 20

Web Application Firewall

Edit on GitHub

The Web Application Firewall (WAF) protects your applications against threats such as SQL Injections, Remote File Inclusion (RFI), Cross-Site Scripting (XSS), and more. WAF scans HTTP, and HTTPS requests detect and block malicious activities before reaching your infrastructure and without impacting your applications’ performance.

It is a barrier that uses a set of rules to filter and monitor the traffic between your application and the internet. It operates in layer 7 known as the application layer, where applications access network services.

  1. How it works
  2. Support Documentation

1. How it works

Web Application Firewall is an Azion Edge Firewall’s module, based on the request scoring methodology. Each http/https request is compared to a set of extremely restrictive blocking rules and receives a score for each family of threat.

According to the received score by the request, it can be released or blocked directly at Azion’s Edge Nodes, before the threat reaches your origin or causes any damage. You define the desired sensitivity level to block each threat family.

To avoid blocking licit requests and malfunctioning of your application, you must run a learning stage, in which the WAF Rule Set identifies legitimate behaviors in your application, inserting them into an whitelist.

You can also monitor the behavior and effectiveness of your Web Application Firewall settings. Through our Real-Time Events and Data Streaming tools, Azion provides dashboards and reports for online and real-time event log checks. Furthermore, you may import Azion’s log records and manipulate them within your own analysis tools.

To use your WAF Rule Sets resources you need to enable the Web Application Firewall module in the Edge Firewall Rule Set.

Operation Mode

In order to get maximum performance and accuracy from the product, the learning stage is required. See the two modes of operation to support you in this stage:

Operation Mode Description
Counting Mode It is used to specify that the WAF should not block any request. Your applications’ traffic will be analyzed and the threats found will only be counted. Use this mode of operation during the first learning stage.
Blocking Mode It is used to analyze and block detected threats, protecting your applications from malicious users. You can run the learning stage whenever you think it is necessary, even during Blocking Mode.

Families of Threats

Threats are categorized into families according to the purpose of the attack. You can enable or disable protection for each threat family individually according to the protections required by the type of your application and the features it provides.

Threat Type Description
SQL Injections Sensitivity It detects attack attempts by injecting SQL code into the application.
Remote File Inclusions (RFI) It detects attempts to include files, usually through scripts, on the web server.
Directory Traversal It prevents exploitation of vulnerability regarding insufficient sanitization of file name fields provided by users, so that characters representing shortcuts to the parent directory are passed through the file API.
Cross-Site Scripting (XSS) It prevents the injection of client-side scripts into pages viewed by your visitors.
File Upload It detects the attemp to upload files to the web server.
Evading Tricks It prevents some coding tricks used to try to evade the protection mechanisms.
Unwanted Access It detects attempts to access administrative or vulnerable pages, bots and security scanning tools.
Identified Attacks It prevents several types of common attacks and known vulnerabilities that should certainly be blocked.

Sensitivity

Sensitivity defines how strictly the WAF will consider a request as a threat, see the details of each level below:

Lowest

It is a lower level of sensitivity, the request will be considered a threat if it presents very strong evidence and receives a high score. This sensitivity has a lower level of protection for your applications, but it will also avoid blocking requests with less chance of representing threats - false positives.

Low

It is a lower level of sensitivity, the request will be considered a threat if it presents very strong evidence and receives a high score. This sensitivity has a lower level of protection for your applications, but it will also avoid blocking requests with less chance of representing threats - false positives.

Medium

It is the level of sensitivity recommended by Azion. The request will be considered a threat if it presents sufficient evidence and receives an intermediate score.

High

It is the high level of protection for your application. At the slightest hint of a threat, the request can be blocked, even when it has a relatively low score. This level of sensitivity may have more false positives if the learning stage does not have enough coverage of the variability of scenarios and uses of your application.

Highest

It is the highest level of protection for your application. At the slightest hint of a threat, the request can be blocked, even when it has a very low score. This level of sensitivity may show many false positives, if the learning stage does not have enough coverage on the variability of scenarios and uses of your application.

Rules

The set of rules which increase the score of a request. The bigger the score is, the higher is the probability of a request to be considered an attack by WAF.

Azion works with an extremely restrictive set of rules to ensure the security of your application. Each rule consists of the following fields.

Field Description
Rule Id Unique numeric ID for each rule of the WAF.
Rule Description A textual description of what the rule does.
Match Pattern Comparison condition, string or regex, which will be sought in the request.
Path When specified, restrict the application of the Match Zone to the defined path only. Path delimits the scope of the rule.
Match Zones Parts or fields of the requisition that will be compared to the Match Pattern. These can be:
Path: match pattern will be compared to the path of the request.
Query String: match pattern will be compared to the query string, also called GET arguments.
Request Header: match pattern will be compared to the HTTP headers of the request.
Request Body: match pattern will be compared to the body of a POST, also called POST arguments.
File Name (Multipart Body): match pattern will be compared to the file names in multipart POSTs.
Raw Body: match pattern will be compared to body that was not interpreted from a request, also called unparsed body.
Attack Family The attack family(s) for which the rule increases the score.

Whitelist

It is the list of legitimate behaviors of your application, which should not increase the score of requests. It can be generated automatically during the learning stage or inserted manually through custom rules.

Each blocking rule has match zones, as explained in the Rules section. The Whitelist aims to disable certain Match Zones from a blocking rule.

Field Description
Rule Id Unique numeric ID for the blocking rule for which the whitelist was generated.
Rule Description A textual description of what makes the blocking rule for which the whitelist was generated.
Path When specified, restrict the application of the whitelist to the defined path only. Path delimits the scope of the whitelist.
Whitelist Match Zone It is the whitelist itself. It defines the part or field of the request for which the blocking rule is to be disabled.
Path: the rule id will not be applied to the request path.
Query String: the rule id will not be applied to the query string, also called GET arguments. It can be restricted to both the name and the value of the arguments. It is possible to limit the scope of the whitelist to a single GET argument using Conditional Query String.
Request Header: the rule id will not be applied to the HTTP headers of the request. It can be restricted to both the name and the value of the headers. It is possible to limit the scope of the whitelist to a single HTTP header using the Conditional Request Header.
Request Body: the rule id will not be applied to the body of a POST, also called POST arguments. It can be restricted to both the name and the value of the arguments. It is possible to limit the scope of the whitelist to a single POST argument using Conditional Request Body.
File Name (Multipart Body): the rule id will not be applied to the file name in a multipart POST.
Raw Body: the rule id will not be applied to the body that was not interpreted from a request, also called an unparsed body.
Status The activation status of the rule in the whitelist.

2. Support Documentation


Didn’t find what you were looking for? Open a support ticket.