Understanding Edge Services Web Application Firewall (WAF)

Note

WAF is in Public Beta, and currently available only via the Edge Services API. It will be coming soon to the Scaleway console.

If your Edge Services pipeline points towards a Load Balancer origin, you can choose to enable the Web Application Firewall (WAF) feature, for added protection. This documentation page gives a detailed overview of WAF, and the different settings, modes and functionalities available.

WAF overviewLink to this anchor

When enabled, WAF protects your Load Balancer backend from potential threats.

It does so by evaluating each request to your Load Balancer origin, to determine whether it is potentially malicious. Four different rulesets can be used to evaluate requests, each more aggressive than the last. The ruleset to use is determined by the paranoia level set by the user.

For requests judged to be malicious, WAF can either block them from passing to your origin (as shown in the diagram below), or simply log them but allow them to pass, depending on the settings you choose.

You can set exclusions, so that certain requests are not evaluated by WAF and are allowed to pass directly to your Load Balancer origin. Exclusion filters are based on the request path and/or HTTP request type.

WAF in an Edge Services pipelineLink to this anchor

In an Edge Services pipeline, WAF sits before the origin stage. This means that WAF only protects your origin, it does not protect or filter requests towards the cache.

If you have both WAF and cache enabled, requests that can be served by the cache will not go through WAF. Only requests that cannot be served by the cache will be filtered by WAF, and allowed to pass to the origin or not depending on your WAF configuration.

WAF ruleset and paranoia levelsLink to this anchor

Scaleway Edge Services WAF uses the OWASP Core Rule Set (CRS). This is an industry standard, open source ruleset for WAF, which protects against multiple categories of attack such as SQL injection and cross-site scripting. Full details are available in the OWASP CRS documentation.

Paranoia level settings are an integral part of the core ruleset. They dictate how aggressive the ruleset should be when judging whether a given request is malicious or not. The paranoia level is rated from 1 to 4, which each being more aggressive and more sensitive to potential threats than the last.

The four levels are:

• 1 - Minimal protection: Basic security, suitable for environments with low sensitivity, prioritizing minimal false alerts.
• 2 - Moderate protection: Solid protection for environments dealing with real-world customer data.
• 3 - Strong protection: Banking-standard security, prioritizing safety but prone to frequent false alerts.
• 4 - Maximum protection: Hyper-paranoid rules, fit for protecting the most critical and sensitive assets.

The higher the paranoia level, the more likely you are to have false positives. This is when WAF classes a request as malicious, when in fact it is not.

• At level 1, the ruleset is unlikely to trigger false positives, however it is also more likely to miss threats and aggressions and classify them as benign.

• At level 4, the ruleset is so aggressive that it detects almost every possible attack, however it is also highly likely to trigger a significant number of false positives whereby a lot of legitimate traffic will be classed as malicious.

Choosing a paranoia level therefore means trading off how hard it is for an attacker to go undetected against how much legitimate traffic is incorrectly classified as malicious. This depends on your use case, and the sensitivity of the application and assets being protected by WAF.

• Anyone running an HTTP server on the internet could benefit from level 1 protection.
• If real user data is involved, consider level 2.
• For online banking, consider level 3
• For crown-jewel level assets, consider level 4.

Find out more about paranoia levels in the official OWASP CRS documentation.

Read on to find out how you can use exclusions to mitigate the effect of some false positives.

WAF exclusionsLink to this anchor

WAF exclusions are filters that allow matching requests (based on path and/or HTTP request type) to bypass WAF entirely.

You can set up to 100 exclusions after enabling WAF on a given pipeline.

• Path filter: Define a regular expression to filter for in request paths, e.g. /api/v1/.*
• HTTP request filter: Define one or more HTTP request types to filter requests for, e.g. GET, DELETE, POST etc.

Each exclusion can consist of:

• A path filter only, OR
• An HTTP request filter only (which itself can filter for multiple request types on an ANY basis), OR
• One path filter and one HTTP request filter. In this case, only requests matching both filters will be considered to meet the criteria for exclusion.

WAF limitationsLink to this anchor

• WAF is in Public Beta, and currently available only via the Edge Services API.
• WAF is only compatible with Load Balancer origins. It cannot be enabled for Object Storage bucket origins.
• WAF protects your origin only, and not your cache.
• You can add a maximum of 100 WAF exclusions
• You cannot currently specify exclusions at the individual rule level. Requests matching exclusion filters bypass WAF entirely.