Web Application Firewall
Web Application Firewall (WAF) protects your applications from threats such as SQL Injections, Remote File Inclusion (RFI), Cross-Site Scripting (XSS), and other web vulnerabilities. WAF analyzes HTTP and HTTPS requests, detects, and blocks malicious activity before it reaches your application infrastructure.
WAF is a barrier that uses a set of rules to filter and monitor traffic between your application and the internet. It operates at layer 7, known as the application layer, where applications access network services.
1. How WAF works
Web Application Firewall is an Azion Edge Firewall module based on the requisition scoring methodology. Each HTTP/HTTPS request is compared to a very strict and detailed set of application standards and given a score that is associated with a particular family of threats.
According to the score received by the request, it can be released or blocked directly in Azion’s edge nodes, before the threat reaches its origin or causes any type of damage. You define the desired level of sensitivity for blocking each family of threats.
To avoid blocking lawful requests and malfunctions of your application, you must perform a learning step. In this step, the WAF Rule Set identifies the legitimate behaviors of your application by placing them on a allowlist.
If internal traffic, tests, and false positives are being blocked by WAF, you can also fine-tune its settings in the Tuning tab, inside a created WAF.
To use WAF Rule Sets, you must enable the Web Application Firewall module in the Edge Firewall Rule Set.
2. Creating a WAF
To access the WAF page:
- Access Real-Time Manager (RTM).
- Open the Products menu, indicated by the icon ☰.
- In the Edge Libraries category, click WAF Rules. This page will show all WAFs created. If you don’t have any WAF configured, click the Add WAF button.
The button will send you to the WAF configuration page, with the field to add an Identifier name, the tabs Main Settings, Tuning, and Allowed Rules, in addition to the Threat Type Configuration table, where you set the sensitivity level for each threat family.
3. Main Settings
The Threat Type Configuration table is available in the Main Settings tab. Threats are categorized into families, according to the purpose of the attack.
Threat family | Description |
---|---|
SQL Injections Sensitivity | Detects attack attempts by injecting SQL code into the application. |
Remote File Inclusions (RFI) | Detects attempts to include files, usually through scripts on the web server. |
Directory Traversal | 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) | Prevents the injection of client-side scripts into pages viewed by your visitors. |
File Upload | Detects the attempt to upload files to the web server. |
Evading Tricks | Protects against some coding tricks used to try to evade protective mechanisms. |
Unwanted Access | Detects attempts to access administrative or vulnerable pages, bots, and security scanning tools. |
Identified Attacks | Prevents several types of common attacks and known vulnerabilities that should certainly be blocked. |
You can also enable or disable protection for each threat family individually through the Active switch in the third column.
Sensitivity
Sensitivity defines how strictly WAF must consider a request as a threat.
Sensitivity | Description |
---|---|
Lowest | The requisition 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’ll also avoid blocking requests with less chance of false positives. |
Low | 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’ll also avoid blocking requests with less chance of false positives. |
Medium | Recommended sensitivity level. The request will be considered a threat if it presents sufficient evidence and receives an intermediate score. |
High | At the slightest hint of a threat, the requisition may be blocked, even when it has a relatively low score. This level of sensitivity may present more false positives if the learning stage doesn’t have sufficient coverage on the variability of scenarios and uses of its application. |
Highest | At the slightest hint of a threat, the requisition may be blocked, even when it has a relatively low score. This level of sensitivity may present more false positives if the learning stage doesn’t have sufficient coverage on the variability of scenarios and uses of its application. |
4. WAF Tuning
WAF Tuning is an analytical tool that shows IPs blocked by possible attack attempts. The Tuning tab is where you can make the WAF’s operation more flexible. Blocked IPs are displayed grouped in the Filter Possible Attacks table. You can filter by Domain, Time Range, Network Lists, IP, and Countries.
In the filters below Filter Possible Attacks:
- Enter the domain (required), time range, which Network Lists you prefer to use, which IPs you are investigating, and the country of origin of the requests.
- Click the Apply filter button.
To see IPs blocked by WAF, you must at least specify the domain (or the domains) of your application. The other fields are optional but enable a more detailed selection.
By clicking the Apply filter button, a list of Possible Attacks will be displayed. This list includes the fields Rule ID, Description, Hits, IPs, Countries, Top 10 IPs Address, and Top 10 Countries.
For more information about these possible attacks, see the WAF Custom Allowed Rules documentation.
If you notice internal traffic, tests, or even false positives being blocked by WAF, you can create an Allowed Rule for these IPs and blocked behaviors. To do this:
- Click on the line that represents the blocked rule, to read more details such as Field and Top 10 Paths.
- Select the checkbox of the rules you want to allow.
- Click Allow Rules. A modal will appear asking to confirm the action and describe the reason.
Tip: it’s important to remember that when describing the reason, it’ll overwrite the description of the Rule ID. If you want to keep the description, along with the reason, copy the description and paste along with the reason.
5. Allowed Rules
The Allowed Rules are composed of the fields:
- Rule ID: unique numeric ID of each WAF rule.
- Rule Descriptions: textual description of what the rule does.
- URI: Uniform Resource Identifier (URI) is the path that goes after the domain in the URL. Example:
/products/edge-firewall
. - Path: when specified, restricts the application of the Match Zone only to the defined path. The path delimits the scope of action of the rule.
- Match Zone: parts or fields of the requisition that’ll be compared with the
match pattern
. It could be:- Path: the
match pattern
will be compared with the request path. - Query String: the
match pattern
will be compared to the query string, also called GET arguments. - Request Header: the
match pattern
will be compared to the HTTP headers of the request. - Request Body: the
match pattern
will be compared to the body of a POST, also called POST arguments. - File Name (Multipart Body): the
match pattern
will be compared with the name of files in multipart POSTs. - Raw Body: The
match pattern
will be compared to the uninterpreted body of a requisition, also called the unparsed body.
- Path: the
- Last Editor: name of the last user to modify this Allowed Rule.
- Last Modified: date the rule was last modified.
- Active: Allowed Rule status.
If you want to delete a created rule:
- Go to the Allowed Rules tab.
- Click on the trash can icon.
- Type delete in the confirmation window, then click the Delete button.
6. Related documentation
Didn’t find what you were looking for? Open a support ticket.