|
| 1 | +--- |
| 2 | +meta: |
| 3 | + title: Understanding Edge Services Web Application Firewall (WAF) |
| 4 | + description: Learn how to protect your web applications with Scaleway Edge Services Web Application Firewall (WAF). Discover the principles, paranoia levels, and limitations of WAF, and find out how to define exclusions for optimal security and performance. |
| 5 | +content: |
| 6 | + h1: Understanding Edge Services Web Application Firewall (WAF) |
| 7 | + paragraph: Learn how to protect your web applications with Edge Services Web Application Firewall (WAF). Discover the principles, paranoia levels, and limitations of WAF, and find out how to define exclusions for optimal security and performance. |
| 8 | +tags: edge-services web-application-firewall waf paranoia-levels exclusions |
| 9 | +dates: |
| 10 | + validation: 2025-03-03 |
| 11 | + creation: 2025-03-03 |
| 12 | +categories: |
| 13 | + - network |
| 14 | +--- |
| 15 | + |
| 16 | +<Message type="note"> |
| 17 | +WAF is in Public Beta, and currently available only via the [Edge Services API](https://www.scaleway.com/en/developers/api/edge-services/). It will be coming soon to the Scaleway console. |
| 18 | +</Message> |
| 19 | + |
| 20 | +If your Edge Services pipeline points towards a Load Balancer origin, you can choose to enable the **W**eb **A**pplication **F**irewall (WAF) feature, for added protection. This documentation page gives a detailed overview of WAF, and the different settings, modes and functionalities available. |
| 21 | + |
| 22 | +## WAF overview |
| 23 | + |
| 24 | +When enabled, WAF protects your Load Balancer backend from potential threats. |
| 25 | + |
| 26 | +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. |
| 27 | + |
| 28 | +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. |
| 29 | + |
| 30 | +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. |
| 31 | + |
| 32 | +<Lightbox src="scaleway-edge-services-waf-diag.webp" alt="A diagram shows how Edge Services WAF deals with three different types of HTTP request. A request meeting the criteria for WAF exclusion is passed directly to the Load Balancer origin. A benign request is first checked by the WAF rules, then allowed to pass to the Load Balancer origin. A malicious request is checked by the rules, and blocked from passing to the Load Balancer origin." /> |
| 33 | + |
| 34 | +## WAF in an Edge Services pipeline |
| 35 | + |
| 36 | +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. |
| 37 | + |
| 38 | +<Lightbox src="scaleway-edge-services-pipeline-diag.webp" alt="A diagram shows the elements and workflow of an Edge Services pipeline. The user connects to the customizable Edge Services endpoint (with its SSL/TLS certificate), which fetches content from the Edge Services cache, which itself fetches content to cache from an origin which is either an Object Storage bucket or Load Balancer. A Web Application Firewall sits between the cache and origin, protecting the origin from threats." /> |
| 39 | + |
| 40 | +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. |
| 41 | + |
| 42 | +## WAF ruleset and paranoia levels |
| 43 | + |
| 44 | +Scaleway Edge Services WAF uses the [OWASP **C**ore **R**ule **S**et (CRS)](https://coreruleset.org/). 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](https://coreruleset.org/docs/). |
| 45 | + |
| 46 | +**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. |
| 47 | + |
| 48 | +The four levels are: |
| 49 | + |
| 50 | +- **1 - Minimal protection**: Basic security, suitable for environments with low sensitivity, prioritizing minimal false alerts. |
| 51 | +- **2 - Moderate protection**: Solid protection for environments dealing with real-world customer data. |
| 52 | +- **3 - Strong protection**: Banking-standard security, prioritizing safety but prone to frequent false alerts. |
| 53 | +- **4 - Maximum protection**: Hyper-paranoid rules, fit for protecting the most critical and sensitive assets. |
| 54 | + |
| 55 | +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. |
| 56 | + |
| 57 | +- 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. |
| 58 | + |
| 59 | +- 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. |
| 60 | + |
| 61 | +| | Level 1 | Level 2 | Level 3 | Level 4 | |
| 62 | +|---|---|---|---|---| |
| 63 | +| Number of threats detected | Lowest | Moderately Low | Moderately High | Highest | |
| 64 | +| Number of false positives | Lowest | Moderately Low | Moderately High | Highest | |
| 65 | + |
| 66 | +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. |
| 67 | + |
| 68 | +- Anyone running an HTTP server on the internet could benefit from level 1 protection. |
| 69 | +- If real user data is involved, consider level 2. |
| 70 | +- For online banking, consider level 3 |
| 71 | +- For crown-jewel level assets, consider level 4. |
| 72 | + |
| 73 | +Find out more about paranoia levels in the [official OWASP CRS documentation](https://coreruleset.org/docs/2-how-crs-works/2-2-paranoia_levels/). |
| 74 | + |
| 75 | +Read on to find out how you can use **exclusions** to mitigate the effect of some false positives. |
| 76 | + |
| 77 | +## WAF exclusions |
| 78 | + |
| 79 | +WAF **exclusions** are filters that allow matching requests (based on **path** and/or **HTTP request type**) to bypass WAF entirely. |
| 80 | + |
| 81 | +You can set up to 100 exclusions after enabling WAF on a given pipeline. |
| 82 | + |
| 83 | +- **Path filter**: Define a regular expression to filter for in request paths, e.g. `/api/v1/.*` |
| 84 | +- **HTTP request filter**: Define one or more HTTP request types to filter requests for, e.g. `GET`, `DELETE`, `POST` etc. |
| 85 | + |
| 86 | +Each exclusion can consist of: |
| 87 | + |
| 88 | +- A path filter only, OR |
| 89 | +- An HTTP request filter only (which itself can filter for multiple request types on an `ANY` basis), OR |
| 90 | +- 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. |
| 91 | + |
| 92 | +## WAF limitations |
| 93 | + |
| 94 | +- WAF is in Public Beta, and currently available only via the [Edge Services API](https://www.scaleway.com/en/developers/api/edge-services/). |
| 95 | +- WAF is only compatible with Load Balancer origins. It cannot be enabled for Object Storage bucket origins. |
| 96 | +- WAF protects your origin only, and not your cache. |
| 97 | +- You can add a maximum of 100 WAF exclusions |
| 98 | +- You cannot currently specify exclusions at the individual rule level. Requests matching exclusion filters bypass WAF entirely. |
0 commit comments