From 51e766908338f3a41375f12078365700f32e89f6 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Thu, 12 Dec 2024 11:25:07 +0000 Subject: [PATCH 01/10] Initial commit --- .../diagram-1.svg | 138 +++++++++++++++ .../diagram-2.svg | 146 ++++++++++++++++ ...ployment-across-zones-and-applications.mdx | 159 ++++++++++++++++++ 3 files changed, 443 insertions(+) create mode 100644 src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg create mode 100644 src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg create mode 100644 src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx diff --git a/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg new file mode 100644 index 000000000000000..1e72a2512e5c00a --- /dev/null +++ b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg @@ -0,0 +1,138 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg new file mode 100644 index 000000000000000..62e189a6bda89de --- /dev/null +++ b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx new file mode 100644 index 000000000000000..6e414bae6c4b09c --- /dev/null +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -0,0 +1,159 @@ +--- +title: Streamlined WAF deployment across zones and applications +pcx_content_type: design-guide +products: + - Account Level WAF +sidebar: + label: Streamlined WAF deployment across zones and applications +updated: 2024-12-11 +--- +## Introduction + +Security perimeters have become less defined compared to the traditional “Castle and Moat” deployment that were popular in the past. Before, it was relatively easier to secure multiple applications with a single Web Application Firewall (WAF) appliance inside a datacenter. Today this approach is not flexible enough, as applications and services expand beyond the traditional datacenter in order to support additional requirements around elasticity, reliability and multi-cloud. + +In this sense, Cloud-based WAF solutions can help in controlling the perimeter sprawl, with a flexible deployment model that can cover applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. + +At the same time, an incorrect implementation of a Cloud-based WAF can lead to security policy fragmentation and duplication, with increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, lower efficiency can also lead to a worse security posture, culminating in security incidents. + +### Who is this document for and what will you learn? + +This Design Guide is written for security and network administrators / architects that are looking to implement a flexible WAF security configuration. This configuration may be spanning across multiple applications and domains, and services deployed in a hybrid environment. + +Cloudflare offers a comprehensive Application Security & Performance solutions, which include a highly-configurable Web Application Firewall (WAF). In this guide, you will learn: + +* How to leverage the WAF features to factor common rules and easily implement common configurations across multiple applications. +* How to deploy exceptions and specific configurations when needed +* Best Practices to follow when deploying the Cloudflare Web Application Firewall (WAF) + +## Example Scenario + +Most Cloudflare customers onboard multiple Cloudflare Zones within a single Account (or Enterprise Organization). Each Cloudflare Zone is usually mapped to a second-level domain (such as example.com), and all its subdomains are then handled within that Cloudflare Zone (web1.example.com, web2.example.com etc…) + +Cloudflare is agnostic towards the origin infrastructure that sits behind each Fully Qualified Domain Name (FQDN): each FQDN record can point to its own infrastructure, and it doesn’t matter where that infrastructure is located (on-premises, in the cloud, SaaS). + +In some situations, multiple FQDNs are pointing to the same web infrastructure (represented by an IP address or another hostname, for example). Certain FQDNs can instead be pointing to a dedicated infrastructure. + +When multiple Cloudflare Zones are used (such as example.com and example.org), the FQDNs can be pointing to the same web infrastructure behind the scenes. + +For example: +* You may have the majority of your web applications running on a newly deployed in-house Content Management System (CMS) +* You may have some legacy web applications that are running on their custom stacks. +* Furthermore, you may have dedicated infrastructure (managed by a partner) for a few applications + + The example scenario is described in the below diagram: + ![Diagram showing the example scenario with multiple domains, subdomains and web applications](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-and-applications/diagram-1.svg "Figure 1: An example scenario with multiple domains, subdomains and web applications.") + +In this scenario, there are multiple requirements from a WAF setup perspective: +* To create an easily deployable configuration that deploys standard WAF rules configuration in front of most applications. +* To have the ability to fine tune and tweak which rules are deployed in front of the legacy applications, which may be more prone to false positives than the others. +* To include a “catch-all” configuration which ensures that a Cloudflare default WAF setup is always applied to all web traffic not falling in the above scenarios. +* To minimize any ongoing maintenance and set up time as applications are added and removed over time. + +In this Design Guide we will review how the Cloudflare WAF operates and what tools are provided to achieve all the above architectural requirements. + +## Cloudflare Web Application Firewall + +The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (http_request_firewall_custom, http_ratelimit and http_request_firewall_managed) that map to Custom Rules, Rate Limiting Rules and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). + +It is important to note that the Account rulesets are evaluated before the zone rulesets. + +## Implementation Scenario + +For the purposes of this guide, we will consider a scenario where a customer has multiple zones under an account. These zones are used to proxy traffic directed to various applications, identified by FQDNs. From a security perspective, the requirement is to provide a uniform layer of security based on a standard setup, and then handle specific scenarios for each single application as required. + +Referring to the earlier scenario, there may be 6 applications (on 6 different FQDNs across multiple zones) that share the same underlying web application stack. For these applications, the customer wants to apply a baseline WAF security posture. However, of these 6 applications, 2 have specific behaviors that require enabling or disabling specific rules within a ruleset, as they may cause false positives. + +This is what the structure would look like for the scenario described above, using “example.com” and “example.org” as 2nd domains. + +![Diagram showing how the example scenario can be modelled in a Cloudflare Account with multiple zones](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-and-applications/diagram-2.svg "Figure 2: The example scenario now included in a Cloudflare Account with multiple zones.") + +We have two Cloudflare zones within a single Cloudflare Account, and within each zone multiple applications identified by their FQDNs + +* web1.example.com +* web2.example.com +* web3.example.com +* special4.example.com +* web5.example.org +* special6.example.org + +In the next section we will see in practice how to deploy the Cloudflare Managed Rulesets in this scenario. + +## Use Case - Implementing the Cloudflare Managed Rulesets + +Given the above scenario, the requirements might be: + +* For web1,web2,web3 and web5 → Apply a subset of the WAF Managed Ruleset. +* For special4 → Apply the default WAF Managed Ruleset, except selected rules. +* For special6 → Apply the default WAF Managed Ruleset, in log mode only. + +In this case, the logic to follow could be: + +* Set up an Account level WAF Managed Ruleset entry to implement the common subset of rules for the four FQDNS requiring it. This is easier to do than implementing the same rule four times at the zone level. +* For special 4 and special6, I will still deploy rulesets at the Account Level, as at this level it is possible to deploy multiple instances of the same ruleset (in this case, the Managed Ruleset) + +To implement these requirements, I can do the following: + +* At the Account level, I select the Managed Ruleset +* I create a Custom Filter Expression including the hostnames that I want to cover +* In the ruleset setup, I browse the rules, I select the first one with a checkbox and then Select all the rules. Then with “Set Status” I mark them all as “Disabled”. Finally, I browse the specific rules that I want to enable and use the Status toggle to re-enable them (my subset) +* Finally I deploy the Account Level ruleset, which implements requirement (A) as above + +For the other two requirements, I can deploy two instances of the Managed Rulesets by repeating the , in step (3) I will deploy the ruleset, and then change the “Ruleset Action” from “Default” to “Log” +above steps 1 to 4 and adding the correct hostnames in the filter: +* For special4.example.com, in step (3) I will instead deploy the ruleset and use the “Status” toggle to disable the rules I don’t want to enforce. +* For special6.example.org + +The setup is depicted below + +To summarize, there are three instances of the “Managed Rulesets” that are calibrated for each application group. + +If in the future I have more applications that require the same configuration, these can be added by including their FQDN in the existing filter expression (or by using lists as explained further below): for example if I deploy a new application on special8.example.com which needs the Managed Ruleset in Log mode (so that I can evaluate its performance), I will simply add it to the filter in the third rule. + +## Additional Considerations + +### The Cloudflare Managed Rules are already tuned to avoid False Positives + +The Cloudflare rulesets (and in particular the Managed Ruleset) are already finely tuned to avoid False Positives, meaning it can be deployed for most or all the applications in use with little to no tweaking required. This means that most customers do not really require creating custom lists of rules that are enabled or disabled, but can work directly with the default rulesets configurations provided. + +In such scenario, the setup could be simplified in the following way: + +* Identify which applications (FQDNs) require a special treatment. For example, special1.example.com requires disabling a small set of Managed Rules, and special2.example.org disabling a similar but different set of rules. +* Deploy two managed Exceptions, each matching on the FQDN, and then Skipping specific rules from the Managed Ruleset +* Finally, deploy a Default version of the Managed Ruleset, which will match on all requests NOT matching the above hostnames, and that will execute the default settings of the Managed Ruleset. + +In this case, it may be much simpler to just handle the few exceptions and rely on the fine tuning against False Positives that is already done by the Cloudflare Team. + +### Using Lists +Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/create-dashboard/). In this case, the Filter expression can be changed to reference list variables. + +The lists will be populated with the actual hostnames, and maintained over time. + +The rules [will refer to the lists](/waf/tools/lists/use-in-expressions/), greatly reducing the configuration overhead. + +When using lists, it is also much easier to adopt a “catch all rule”. For example, I can deploy a last rule in the evaluation order (at the Account Level) which will execute the Default Managed Ruleset when the host is not part of the list used for the custom configurations. This would ensure that a default WAF Managed Rules configuration is applied in case some hosts are not added by mistake to the lists. + +### Using automations + +The WAF configuration can be managed [via API calls](/api/) and [Terraform](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). In this case, the setup and deployment (especially when a specific set of rules must be selected and enabled/disabled) can be simplified by using programmatic approaches, instead of using the UI for repeated tasks. + +For example, a default Terraform configuration file could be created to define Rulesets and Lists, and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard + +### Avoid mixing setup at Account and Zone level + +When possible, it is recommended to maintain the configuration at the Account level, in particular when a zone will contain multiple DNS records which will require different configurations per FQDN. This can be the case if the Cloudflare zone is a 2nd level domain, and all 3rd level and further domains will be managed within that single Cloudflare zone. + +At the zone level, it is possible to deploy only one instance of each ruleset (Managed, OWASP, Credential Check), meaning that the handling of multiple FQDNs is better managed at the Account level. + +### Custom Rules and Rate Limiting Rules + +Similarly to what was described above for Managed Rules, Custom and Rate Limiting rules that require application across multiple hostnames and zones are better configured at the Account Level WAF. + +Otherwise, these can be set up at the Zone level, especially when they pertain to a single Cloudflare zone. + +For more information, please refer to the Cloudflare Documentation: +* [Create a Rate Limiting Rule at the Account level](/waf/rate-limiting-rules/create-account-dashboard/) +* [Create Custom Rulesets at the Account level](/waf/custom-rules/custom-rulesets/) + +## Summary + +In conclusion, this design guide illustrates how customers can implement flexible WAF configurations that cover multiple applications and multiple domains while reducing the effort required to set up and maintain the configuration. From 98fe466c7129d38e48993a45a87e60889c3bc75e Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Thu, 12 Dec 2024 11:47:59 +0000 Subject: [PATCH 02/10] Fix diagrams path --- package-lock.json | 1 + ...reamlined-waf-deployment-across-zones-and-applications.mdx | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/package-lock.json b/package-lock.json index 1cc4a9a7bc73e32..0ada359fb1c5adc 100644 --- a/package-lock.json +++ b/package-lock.json @@ -15810,6 +15810,7 @@ "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.7.2.tgz", "integrity": "sha512-i5t66RHxDvVN40HfDd1PsEThGNnlMCMT3jMUuoh9/0TaqWevNontacunWyN02LA9/fIbEWlcHZcgTKb9QoaLfg==", "dev": true, + "license": "Apache-2.0", "bin": { "tsc": "bin/tsc", "tsserver": "bin/tsserver" diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 6e414bae6c4b09c..8bf093623977e43 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -41,7 +41,7 @@ For example: * Furthermore, you may have dedicated infrastructure (managed by a partner) for a few applications The example scenario is described in the below diagram: - ![Diagram showing the example scenario with multiple domains, subdomains and web applications](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-and-applications/diagram-1.svg "Figure 1: An example scenario with multiple domains, subdomains and web applications.") + ![Diagram showing the example scenario with multiple domains, subdomains and web applications](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg "Figure 1: An example scenario with multiple domains, subdomains and web applications.") In this scenario, there are multiple requirements from a WAF setup perspective: * To create an easily deployable configuration that deploys standard WAF rules configuration in front of most applications. @@ -65,7 +65,7 @@ Referring to the earlier scenario, there may be 6 applications (on 6 different F This is what the structure would look like for the scenario described above, using “example.com” and “example.org” as 2nd domains. -![Diagram showing how the example scenario can be modelled in a Cloudflare Account with multiple zones](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-and-applications/diagram-2.svg "Figure 2: The example scenario now included in a Cloudflare Account with multiple zones.") +![Diagram showing how the example scenario can be modelled in a Cloudflare Account with multiple zones](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg "Figure 2: The example scenario now included in a Cloudflare Account with multiple zones.") We have two Cloudflare zones within a single Cloudflare Account, and within each zone multiple applications identified by their FQDNs From c7e3812e3e9a6dbb427d36ae6335210cc1fb7ee2 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:17:37 +0000 Subject: [PATCH 03/10] Adding new diagram and rewriting wording --- .../diagram-3.svg | 179 ++++++++++++++++++ ...ployment-across-zones-and-applications.mdx | 145 +++++++------- 2 files changed, 246 insertions(+), 78 deletions(-) create mode 100644 src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg diff --git a/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg new file mode 100644 index 000000000000000..66856935eb8e0a1 --- /dev/null +++ b/src/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 8bf093623977e43..8366e8a22a578e0 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -9,146 +9,135 @@ updated: 2024-12-11 --- ## Introduction -Security perimeters have become less defined compared to the traditional “Castle and Moat” deployment that were popular in the past. Before, it was relatively easier to secure multiple applications with a single Web Application Firewall (WAF) appliance inside a datacenter. Today this approach is not flexible enough, as applications and services expand beyond the traditional datacenter in order to support additional requirements around elasticity, reliability and multi-cloud. +Security perimeters have become less defined compared to the traditional “Castle and Moat” deployment that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility, as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach, as well as adopting SaaS platforms, so it is valuable to update the WAF approach to cover this scenario. -In this sense, Cloud-based WAF solutions can help in controlling the perimeter sprawl, with a flexible deployment model that can cover applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. +In this sense, Cloud-based WAF solutions can control the perimeter sprawl, with a flexible deployment model that covers applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. -At the same time, an incorrect implementation of a Cloud-based WAF can lead to security policy fragmentation and duplication, with increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, lower efficiency can also lead to a worse security posture, culminating in security incidents. +At the same time, an incorrect implementation of a Cloud-based WAF can lead to security policy fragmentation and duplication, causing increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, the lower efficiency can also degrade the security posture itself. This ultimately can lead to security incidents of varying degrees of severity depending on the scenario. ### Who is this document for and what will you learn? -This Design Guide is written for security and network administrators / architects that are looking to implement a flexible WAF security configuration. This configuration may be spanning across multiple applications and domains, and services deployed in a hybrid environment. +This Design Guide is written for security and network administrators / architects that are looking to implement a flexible, Cloud-based WAF security configuration. This configuration can span across multiple applications, domains, and services - all deployed in a hybrid environment. -Cloudflare offers a comprehensive Application Security & Performance solutions, which include a highly-configurable Web Application Firewall (WAF). In this guide, you will learn: +Cloudflare offers a comprehensive Application Security & Performance solutions, which include a highly-configurable, cloud-based Web Application Firewall (WAF). -* How to leverage the WAF features to factor common rules and easily implement common configurations across multiple applications. -* How to deploy exceptions and specific configurations when needed -* Best Practices to follow when deploying the Cloudflare Web Application Firewall (WAF) +In this guide, you will learn: + +* How to implement the Cloudflare WAF, and factor common rules. +* How to easily implement common configurations across multiple applications. +* How to deploy exceptions and specific configurations when needed. +* What are the best practices to follow when deploying the Cloudflare WAF. ## Example Scenario -Most Cloudflare customers onboard multiple Cloudflare Zones within a single Account (or Enterprise Organization). Each Cloudflare Zone is usually mapped to a second-level domain (such as example.com), and all its subdomains are then handled within that Cloudflare Zone (web1.example.com, web2.example.com etc…) +Most Cloudflare customers onboard multiple Cloudflare Zones within a single Account (or Enterprise Organization). Each Cloudflare Zone is usually mapped to a second-level domain (such as `example.com`), and all its subdomains are then handled within that Cloudflare Zone (`web1.example.com`, `web2.example.com` etc.). -Cloudflare is agnostic towards the origin infrastructure that sits behind each Fully Qualified Domain Name (FQDN): each FQDN record can point to its own infrastructure, and it doesn’t matter where that infrastructure is located (on-premises, in the cloud, SaaS). +In this setup, Cloudflare is a DNS-based reverse proxy. Each Fully Qualified Domain Name (FQDN) is configured in its Cloudflare zone, and it points to a customer origin server. In this respect, Cloudflare does not make particular distinctions on what/where that origin server is located. It could be deployed on-premises, it could be a virtual machine running in the Cloud, or it could be a SaaS service provided by a third-party. -In some situations, multiple FQDNs are pointing to the same web infrastructure (represented by an IP address or another hostname, for example). Certain FQDNs can instead be pointing to a dedicated infrastructure. +Frequently, multiple FQDNs are pointing to the same, shared web infrastructure. This is reached using an IP address or another FQDN, for example. It is also possible that some FQDNs are pointed at dedicated origin infrastructure or to an external SaaS endpoint. -When multiple Cloudflare Zones are used (such as example.com and example.org), the FQDNs can be pointing to the same web infrastructure behind the scenes. +In many cases, Cloudflare customers end up managing many Cloudflare Zones (such as `example.com`,`example.org`, `myappexample.com` and so on) within a single Cloudflare Account, and many FQDNs within each zone. Frequently, many FQDNs across multiple zones are pointing at a shared web infrastrcuture behind the scenes. -For example: -* You may have the majority of your web applications running on a newly deployed in-house Content Management System (CMS) -* You may have some legacy web applications that are running on their custom stacks. -* Furthermore, you may have dedicated infrastructure (managed by a partner) for a few applications +For example, you could be in the following (or similar) scenario: +* The majority of your web applications run on a newly deployed in-house Content Management System (CMS) +* You also have some legacy web applications that are running on their custom stacks. +* Finally, you may have dedicated infrastructure (managed by a partner) for a few applications. - The example scenario is described in the below diagram: + The example scenario is visualized in the below diagram: ![Diagram showing the example scenario with multiple domains, subdomains and web applications](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-1.svg "Figure 1: An example scenario with multiple domains, subdomains and web applications.") -In this scenario, there are multiple requirements from a WAF setup perspective: -* To create an easily deployable configuration that deploys standard WAF rules configuration in front of most applications. +### WAF Requirements + +From a WAF setup perspective, this scenario raises interesting requirements: +* To create an easily deployable configuration that implements standard WAF rules configuration in front of most applications. * To have the ability to fine tune and tweak which rules are deployed in front of the legacy applications, which may be more prone to false positives than the others. -* To include a “catch-all” configuration which ensures that a Cloudflare default WAF setup is always applied to all web traffic not falling in the above scenarios. -* To minimize any ongoing maintenance and set up time as applications are added and removed over time. +* To include a “catch-all” configuration, ensuring that a Cloudflare default WAF setup is always applied to all web traffic that does not fall in the above scenarios. +* To minimize set up time and ongoing maintenance efforts, as applications are added and removed over time. -In this Design Guide we will review how the Cloudflare WAF operates and what tools are provided to achieve all the above architectural requirements. +In this Design Guide we will review how the Cloudflare WAF operates, and what tools are provided to achieve all the above architectural requirements. ## Cloudflare Web Application Firewall -The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (http_request_firewall_custom, http_ratelimit and http_request_firewall_managed) that map to Custom Rules, Rate Limiting Rules and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). +The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (`http_request_firewall_custom`, `http_ratelimit` and `http_request_firewall_managed`) that map to Custom Rules, Rate Limiting Rules and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). It is important to note that the Account rulesets are evaluated before the zone rulesets. -It is important to note that the Account rulesets are evaluated before the zone rulesets. +## Example Use Case - Implementing the Cloudflare Managed Ruleset -## Implementation Scenario +For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization), and two 2nd level domains onboarded on it. -For the purposes of this guide, we will consider a scenario where a customer has multiple zones under an account. These zones are used to proxy traffic directed to various applications, identified by FQDNs. From a security perspective, the requirement is to provide a uniform layer of security based on a standard setup, and then handle specific scenarios for each single application as required. +Let's imagine that there are six applications behind six FQDNs across two domains. For these applications, you want to apply apply a baseline WAF security posture. However, of these six applications, two will require a more special treatment: -Referring to the earlier scenario, there may be 6 applications (on 6 different FQDNs across multiple zones) that share the same underlying web application stack. For these applications, the customer wants to apply a baseline WAF security posture. However, of these 6 applications, 2 have specific behaviors that require enabling or disabling specific rules within a ruleset, as they may cause false positives. +* One is implemented on a legacy application server, prone to false positives. +* Another is implemented by a third party on their own infrastrcuture. -This is what the structure would look like for the scenario described above, using “example.com” and “example.org” as 2nd domains. +Let's visualize the scenario below: ![Diagram showing how the example scenario can be modelled in a Cloudflare Account with multiple zones](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-2.svg "Figure 2: The example scenario now included in a Cloudflare Account with multiple zones.") -We have two Cloudflare zones within a single Cloudflare Account, and within each zone multiple applications identified by their FQDNs - -* web1.example.com -* web2.example.com -* web3.example.com -* special4.example.com -* web5.example.org -* special6.example.org +### Using Account Level WAF to minimize configuration overheads -In the next section we will see in practice how to deploy the Cloudflare Managed Rulesets in this scenario. +We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudflare-managed-ruleset/) as an example, keeping in mind that the approach can also be used for other Cloudflare Managed Rules, Rate Limiting Rules and Custom Rules. -## Use Case - Implementing the Cloudflare Managed Rulesets +* For `web1.example.com`, `web2.example.com`, `web3.example.com` and `web5.example.org`: you want to apply the default WAF Managed Ruleset, already tuned by Cloudflare. +* For `special4.example.com`: you want to apply a different subset of the default Managed Ruleset, as you already identified a couple of rules that are causing false positives on the legacy application. +* For `special6.example.org`: you want to apply the Managed Ruleset in logging mode, as this is a newly introduced application from a third party and you need to start evaluating how to protect it. -Given the above scenario, the requirements might be: +Then, you can adopt the following approach: -* For web1,web2,web3 and web5 → Apply a subset of the WAF Managed Ruleset. -* For special4 → Apply the default WAF Managed Ruleset, except selected rules. -* For special6 → Apply the default WAF Managed Ruleset, in log mode only. +* Deploy one instance of the Cloudflare Managed Ruleset, at the Account Level. This implements the common subset of rules for the four FQDNS requiring it. This is easier to set up and maintain than replicating the same configuration four times at the Zone level. +* For `special4.example.com` and `special6.example.org`, you will deploy two additional instances of the Managed Ruleset, with the specific tweaks required by the applications behind these particular FQDNs. -In this case, the logic to follow could be: +In practice, using the [Account Level WAF's Managed rulesets](/waf/account/managed-rulesets/), you can deploy the three instances of our Managed Ruleset. Each instance will have its own [Custom Filter Expression](/ruleset-engine/rules-language/expressions/edit-expressions/), which will check that the HTTPS requests's hostname belongs to one of the FQDNs in a list: -* Set up an Account level WAF Managed Ruleset entry to implement the common subset of rules for the four FQDNS requiring it. This is easier to do than implementing the same rule four times at the zone level. -* For special 4 and special6, I will still deploy rulesets at the Account Level, as at this level it is possible to deploy multiple instances of the same ruleset (in this case, the Managed Ruleset) +* For the first list (`web1.example.com`, `web2.example.com`, `web3.example.com` and `web5.example.org`), you will apply the Cloudflare Managed Ruleset in its `Default` configuration. +* For `special4.example.com`, the same ruleset will be deployed in `Default` mode, but taking care of disabling the specific rules that cause false positives. This can be achieved with the [Rule Overrides](/ruleset-engine/managed-rulesets/override-managed-ruleset/), using the Dashboard or the APIs. [Real examples are available here](ruleset-engine/managed-rulesets/override-examples/). +* For `special6.example.org`, you repeat the setup done for the first list, this time modifying the Managed Ruleset instance to operate in `Log` mode instead of `Default`. -To implement these requirements, I can do the following: +Let's visualize the complete configuration in the below diagram: -* At the Account level, I select the Managed Ruleset -* I create a Custom Filter Expression including the hostnames that I want to cover -* In the ruleset setup, I browse the rules, I select the first one with a checkbox and then Select all the rules. Then with “Set Status” I mark them all as “Disabled”. Finally, I browse the specific rules that I want to enable and use the Status toggle to re-enable them (my subset) -* Finally I deploy the Account Level ruleset, which implements requirement (A) as above +![Diagram depicting the implemented WAF configuration at the account level](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg "Figure 3: The Account WAF implementation to protect multiple applications across different hostnames with repeatable configurations.") -For the other two requirements, I can deploy two instances of the Managed Rulesets by repeating the , in step (3) I will deploy the ruleset, and then change the “Ruleset Action” from “Default” to “Log” -above steps 1 to 4 and adding the correct hostnames in the filter: -* For special4.example.com, in step (3) I will instead deploy the ruleset and use the “Status” toggle to disable the rules I don’t want to enforce. -* For special6.example.org +This setup will provide three instances of the "Managed Ruleset", calibrated for each application group. -The setup is depicted below - -To summarize, there are three instances of the “Managed Rulesets” that are calibrated for each application group. - -If in the future I have more applications that require the same configuration, these can be added by including their FQDN in the existing filter expression (or by using lists as explained further below): for example if I deploy a new application on special8.example.com which needs the Managed Ruleset in Log mode (so that I can evaluate its performance), I will simply add it to the filter in the third rule. +If you have additional applications to be protected in the future, it is sufficient to include the new application FQDN to the filter expression. Generally, most will be added to the standard ruleset instance that is using the recommended Cloudflare configuration. Another common strategy is to add new applications to the `Log` mode instance, so that it can be monitored and eventually transitioned to the `Default` mode ruleset or to a more specific variation if required. ## Additional Considerations -### The Cloudflare Managed Rules are already tuned to avoid False Positives +### False Positives Tuning -The Cloudflare rulesets (and in particular the Managed Ruleset) are already finely tuned to avoid False Positives, meaning it can be deployed for most or all the applications in use with little to no tweaking required. This means that most customers do not really require creating custom lists of rules that are enabled or disabled, but can work directly with the default rulesets configurations provided. +The rulesets (and in particular the Managed Ruleset) are already finely tuned by Cloudflare to avoid false positives. They can be deployed for most applications with little to no tweaking required. This means that customers work directly with the default rulesets configurations in most cases, with the possibility to customize only when needed. -In such scenario, the setup could be simplified in the following way: +If this is your scenario, you can simplify the above setup in the following way by using [Exceptions](/waf/managed-rules/waf-exceptions/): -* Identify which applications (FQDNs) require a special treatment. For example, special1.example.com requires disabling a small set of Managed Rules, and special2.example.org disabling a similar but different set of rules. -* Deploy two managed Exceptions, each matching on the FQDN, and then Skipping specific rules from the Managed Ruleset -* Finally, deploy a Default version of the Managed Ruleset, which will match on all requests NOT matching the above hostnames, and that will execute the default settings of the Managed Ruleset. +* First, you can identify which applications (FQDNs) require a special treatment by deploying the ruleset in `Log` mode. For example, following testing you find that `special1.example.com` requires disabling a small set of Managed Rules, and `special2.example.org` disabling a similar, but different set of rules. +* Deploy two managed Exceptions, with a filter matching on the each FQDN, and then skipping thoserules from the Managed Ruleset. +* Finally, deploy a Default version of the Managed Ruleset, which will match on everything else, and run the Cloudflare recommended settings of the Managed Ruleset. -In this case, it may be much simpler to just handle the few exceptions and rely on the fine tuning against False Positives that is already done by the Cloudflare Team. +This approach can be simpler when there are few exceptions to the norm, and when the initial calibration confirms that the fine tuning already done by Cloudflare to minimize false positives is appropriate in your situation. ### Using Lists -Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/create-dashboard/). In this case, the Filter expression can be changed to reference list variables. - -The lists will be populated with the actual hostnames, and maintained over time. +Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/create-dashboard/). In this case, the Filter expression can be changed to reference such list variables. -The rules [will refer to the lists](/waf/tools/lists/use-in-expressions/), greatly reducing the configuration overhead. +You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules but also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration. -When using lists, it is also much easier to adopt a “catch all rule”. For example, I can deploy a last rule in the evaluation order (at the Account Level) which will execute the Default Managed Ruleset when the host is not part of the list used for the custom configurations. This would ensure that a default WAF Managed Rules configuration is applied in case some hosts are not added by mistake to the lists. +When using lists, it is also much easier to adopt a “catch all rule” that runs last in the evaluation order. This could implement, for example, the `Default` Cloudflare Managed Ruleset when the host in the HTTPS request is not included in any of your lists. This ensures that a default WAF Managed Rules configuration is always applied, in case some of your applications are not added by mistake to the lists. ### Using automations -The WAF configuration can be managed [via API calls](/api/) and [Terraform](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). In this case, the setup and deployment (especially when a specific set of rules must be selected and enabled/disabled) can be simplified by using programmatic approaches, instead of using the UI for repeated tasks. +The WAF configuration can be managed [via API calls](/api/) and [Terraform](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). This is particularly useful when you want to scale the approach to many more zones and FQDNs, and to avoid repetitive and manual tasks in the Dashboard. -For example, a default Terraform configuration file could be created to define Rulesets and Lists, and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard +For example, a default Terraform configuration file could be created to define Rulesets and Lists, and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard. ### Avoid mixing setup at Account and Zone level -When possible, it is recommended to maintain the configuration at the Account level, in particular when a zone will contain multiple DNS records which will require different configurations per FQDN. This can be the case if the Cloudflare zone is a 2nd level domain, and all 3rd level and further domains will be managed within that single Cloudflare zone. +When possible, Cloudflare recommends to maintain the configuration at the Account level, in particular when a Cloudflare Zone will contain multiple DNS records, each requiring custom configuration. -At the zone level, it is possible to deploy only one instance of each ruleset (Managed, OWASP, Credential Check), meaning that the handling of multiple FQDNs is better managed at the Account level. +At the Zone level WAF, you can deploy only one instance of each ruleset (Managed Rules, OWASP Rules, etc.), and therefore handling special scenarios can be more complex or not possible at this level. ### Custom Rules and Rate Limiting Rules -Similarly to what was described above for Managed Rules, Custom and Rate Limiting rules that require application across multiple hostnames and zones are better configured at the Account Level WAF. +The approach described above for Managed Rules can be applied also to [Custom](/waf/account/custom-rulesets/) and [Rate Limiting](/waf/account/rate-limiting-rulesets/), extending the flexibility to all the WAF security tools at your disposal. -Otherwise, these can be set up at the Zone level, especially when they pertain to a single Cloudflare zone. +Unless your configuration is specific to a single zone, Cloudflare recommends to implement it at the Account level. For more information, please refer to the Cloudflare Documentation: * [Create a Rate Limiting Rule at the Account level](/waf/rate-limiting-rules/create-account-dashboard/) @@ -156,4 +145,4 @@ For more information, please refer to the Cloudflare Documentation: ## Summary -In conclusion, this design guide illustrates how customers can implement flexible WAF configurations that cover multiple applications and multiple domains while reducing the effort required to set up and maintain the configuration. +In conclusion, this design guide illustrates how you can implement flexible WAF configurations covering multiple applications and domains. The described approach reduces the effort required to deploy, maintain and update your WAF security configuration. From ce5d0fe1fb53901aa5037dd3e26a22daf8c47ee2 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:32:14 +0000 Subject: [PATCH 04/10] Update src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx OK Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com> --- ...streamlined-waf-deployment-across-zones-and-applications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 8366e8a22a578e0..a2984afc0c868c1 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -9,7 +9,7 @@ updated: 2024-12-11 --- ## Introduction -Security perimeters have become less defined compared to the traditional “Castle and Moat” deployment that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility, as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach, as well as adopting SaaS platforms, so it is valuable to update the WAF approach to cover this scenario. +Security perimeters have become less defined compared to the traditional "Castle and Moat" deployment that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility, as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach, as well as adopting SaaS platforms, so it is valuable to update the WAF approach to cover this scenario. In this sense, Cloud-based WAF solutions can control the perimeter sprawl, with a flexible deployment model that covers applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. From 6e0235e4481ae1f2951fe2e83f12776797c944eb Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:32:31 +0000 Subject: [PATCH 05/10] Update src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx OK Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com> --- ...streamlined-waf-deployment-across-zones-and-applications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index a2984afc0c868c1..57d26e7261a4f3b 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -51,7 +51,7 @@ For example, you could be in the following (or similar) scenario: From a WAF setup perspective, this scenario raises interesting requirements: * To create an easily deployable configuration that implements standard WAF rules configuration in front of most applications. * To have the ability to fine tune and tweak which rules are deployed in front of the legacy applications, which may be more prone to false positives than the others. -* To include a “catch-all” configuration, ensuring that a Cloudflare default WAF setup is always applied to all web traffic that does not fall in the above scenarios. +* To include a "catch-all" configuration, ensuring that a Cloudflare default WAF setup is always applied to all web traffic that does not fall in the above scenarios. * To minimize set up time and ongoing maintenance efforts, as applications are added and removed over time. In this Design Guide we will review how the Cloudflare WAF operates, and what tools are provided to achieve all the above architectural requirements. From 3ab51d5ccf33cbee696557e1ff2227f9b34a5734 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:32:47 +0000 Subject: [PATCH 06/10] Update src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx OK Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com> --- ...streamlined-waf-deployment-across-zones-and-applications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 57d26e7261a4f3b..eeb8ddbff2e403f 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -64,7 +64,7 @@ The Cloudflare WAF operates at both the zone and the account level. There are di For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization), and two 2nd level domains onboarded on it. -Let's imagine that there are six applications behind six FQDNs across two domains. For these applications, you want to apply apply a baseline WAF security posture. However, of these six applications, two will require a more special treatment: +Let's imagine that there are six applications behind six FQDNs across two domains. For these applications, you want to apply a baseline WAF security posture. However, of these six applications, two will require a more special treatment: * One is implemented on a legacy application server, prone to false positives. * Another is implemented by a third party on their own infrastrcuture. From 074d815d4bc4fc7d1c5ef59141493ca762bc3d83 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:32:58 +0000 Subject: [PATCH 07/10] Update src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx OK Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com> --- ...streamlined-waf-deployment-across-zones-and-applications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index eeb8ddbff2e403f..18d98a407059b3f 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -119,7 +119,7 @@ Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/ You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules but also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration. -When using lists, it is also much easier to adopt a “catch all rule” that runs last in the evaluation order. This could implement, for example, the `Default` Cloudflare Managed Ruleset when the host in the HTTPS request is not included in any of your lists. This ensures that a default WAF Managed Rules configuration is always applied, in case some of your applications are not added by mistake to the lists. +When using lists, it is also much easier to adopt a "catch all rule" that runs last in the evaluation order. This could implement, for example, the `Default` Cloudflare Managed Ruleset when the host in the HTTPS request is not included in any of your lists. This ensures that a default WAF Managed Rules configuration is always applied, in case some of your applications are not added by mistake to the lists. ### Using automations From 71a48760f3f4b4f5b4b072c84b2a98a7b6fdb43c Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Fri, 13 Dec 2024 13:36:46 +0000 Subject: [PATCH 08/10] Update streamlined-waf-deployment-across-zones-and-applications.mdx Fix broken link --- ...streamlined-waf-deployment-across-zones-and-applications.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 18d98a407059b3f..551226c0b1dabc2 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -89,7 +89,7 @@ Then, you can adopt the following approach: In practice, using the [Account Level WAF's Managed rulesets](/waf/account/managed-rulesets/), you can deploy the three instances of our Managed Ruleset. Each instance will have its own [Custom Filter Expression](/ruleset-engine/rules-language/expressions/edit-expressions/), which will check that the HTTPS requests's hostname belongs to one of the FQDNs in a list: * For the first list (`web1.example.com`, `web2.example.com`, `web3.example.com` and `web5.example.org`), you will apply the Cloudflare Managed Ruleset in its `Default` configuration. -* For `special4.example.com`, the same ruleset will be deployed in `Default` mode, but taking care of disabling the specific rules that cause false positives. This can be achieved with the [Rule Overrides](/ruleset-engine/managed-rulesets/override-managed-ruleset/), using the Dashboard or the APIs. [Real examples are available here](ruleset-engine/managed-rulesets/override-examples/). +* For `special4.example.com`, the same ruleset will be deployed in `Default` mode, but taking care of disabling the specific rules that cause false positives. This can be achieved with the [Rule Overrides](/ruleset-engine/managed-rulesets/override-managed-ruleset/), using the Dashboard or the APIs. [Real examples are available here](/ruleset-engine/managed-rulesets/override-examples/). * For `special6.example.org`, you repeat the setup done for the first list, this time modifying the Managed Ruleset instance to operate in `Log` mode instead of `Default`. Let's visualize the complete configuration in the below diagram: From 435f765041b6a804ae7edc7714f1ea446e502305 Mon Sep 17 00:00:00 2001 From: Paolo Tagliaferri Date: Tue, 17 Dec 2024 09:03:35 +0000 Subject: [PATCH 09/10] Fix 2 links to remove redirects --- ...reamlined-waf-deployment-across-zones-and-applications.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index 551226c0b1dabc2..c9f386d98f72ee5 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -140,8 +140,8 @@ The approach described above for Managed Rules can be applied also to [Custom](/ Unless your configuration is specific to a single zone, Cloudflare recommends to implement it at the Account level. For more information, please refer to the Cloudflare Documentation: -* [Create a Rate Limiting Rule at the Account level](/waf/rate-limiting-rules/create-account-dashboard/) -* [Create Custom Rulesets at the Account level](/waf/custom-rules/custom-rulesets/) +* [Create a Rate Limiting Rule at the Account level](/waf/account/rate-limiting-rulesets/create-dashboard/) +* [Create Custom Rulesets at the Account level](/waf/account/custom-rulesets/) ## Summary From ed21a4acab819ca4b13d57a4ef94bca4c655c68a Mon Sep 17 00:00:00 2001 From: Simon Thorpe Date: Tue, 17 Dec 2024 14:54:56 -0800 Subject: [PATCH 10/10] Apply suggestions from code review Co-authored-by: Claire W <78226508+crwaters16@users.noreply.github.com> --- ...ployment-across-zones-and-applications.mdx | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx index c9f386d98f72ee5..929a4d61a49f3d2 100644 --- a/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx +++ b/src/content/docs/reference-architecture/design-guides/streamlined-waf-deployment-across-zones-and-applications.mdx @@ -9,21 +9,21 @@ updated: 2024-12-11 --- ## Introduction -Security perimeters have become less defined compared to the traditional "Castle and Moat" deployment that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility, as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach, as well as adopting SaaS platforms, so it is valuable to update the WAF approach to cover this scenario. +Security perimeters have become less defined compared to the traditional "Castle and Moat" deployments that were popular in the past. Within a fixed perimeter, it was relatively easier to secure multiple applications using a single Web Application Firewall (WAF) deployment inside a datacenter. Today this approach does not provide enough flexibility as applications and services expand beyond the traditional datacenter. There are several good reasons to configure networks and services in a hybrid approach and to adopt SaaS platforms, so it is valuable to update the WAF approach to cover this scenario. -In this sense, Cloud-based WAF solutions can control the perimeter sprawl, with a flexible deployment model that covers applications and services deployed on-premises, on cloud based IaaS and PaaS environments, and also in hybrid environments. +Cloud-based WAF solutions can control the perimeter sprawl with a flexible deployment model that covers applications and services deployed on-premises, on cloud-based IaaS and PaaS environments, and in hybrid environments. -At the same time, an incorrect implementation of a Cloud-based WAF can lead to security policy fragmentation and duplication, causing increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, the lower efficiency can also degrade the security posture itself. This ultimately can lead to security incidents of varying degrees of severity depending on the scenario. +At the same time, an incorrect implementation of a cloud-based WAF can lead to security policy fragmentation and duplication, causing increased overheads both in maintenance and in monitoring. Aside from the clear economic impact that such inefficiencies bring, the lower efficiency can also degrade the security posture itself. This ultimately can lead to security incidents of varying degrees of severity depending on the scenario. ### Who is this document for and what will you learn? -This Design Guide is written for security and network administrators / architects that are looking to implement a flexible, Cloud-based WAF security configuration. This configuration can span across multiple applications, domains, and services - all deployed in a hybrid environment. +This Design Guide is written for security and network administrators / architects that are looking to implement a flexible, cloud-based WAF security configuration. This configuration can span across multiple applications, domains, and services - all deployed in a hybrid environment. -Cloudflare offers a comprehensive Application Security & Performance solutions, which include a highly-configurable, cloud-based Web Application Firewall (WAF). +Cloudflare offers comprehensive Application Security & Performance solutions, which include a highly-configurable, cloud-based Web Application Firewall (WAF). In this guide, you will learn: -* How to implement the Cloudflare WAF, and factor common rules. +* How to implement the Cloudflare WAF and factor common rules. * How to easily implement common configurations across multiple applications. * How to deploy exceptions and specific configurations when needed. * What are the best practices to follow when deploying the Cloudflare WAF. @@ -54,15 +54,15 @@ From a WAF setup perspective, this scenario raises interesting requirements: * To include a "catch-all" configuration, ensuring that a Cloudflare default WAF setup is always applied to all web traffic that does not fall in the above scenarios. * To minimize set up time and ongoing maintenance efforts, as applications are added and removed over time. -In this Design Guide we will review how the Cloudflare WAF operates, and what tools are provided to achieve all the above architectural requirements. +In this Design Guide we will review how the Cloudflare WAF operates and what tools are provided to achieve all the above architectural requirements. ## Cloudflare Web Application Firewall -The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (`http_request_firewall_custom`, `http_ratelimit` and `http_request_firewall_managed`) that map to Custom Rules, Rate Limiting Rules and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). It is important to note that the Account rulesets are evaluated before the zone rulesets. +The Cloudflare WAF operates at both the zone and the account level. There are different [WAF phases](/ruleset-engine/about/phases/) (`http_request_firewall_custom`, `http_ratelimit` and `http_request_firewall_managed`) that map to Custom Rules, Rate Limiting Rules, and Managed Rules. These phases exist both at the account and the zone level. For more information, please [refer to the following documentation](/waf/reference/phases/). It is important to note that the Account rulesets are evaluated before the zone rulesets. ## Example Use Case - Implementing the Cloudflare Managed Ruleset -For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization), and two 2nd level domains onboarded on it. +For the purposes of this guide, we will build on the example scenario and WAF Requirements provided above. You have a single Cloudflare Account (or Enterprise Organization) and two 2nd level domains onboarded on it. Let's imagine that there are six applications behind six FQDNs across two domains. For these applications, you want to apply a baseline WAF security posture. However, of these six applications, two will require a more special treatment: @@ -75,7 +75,7 @@ Let's visualize the scenario below: ### Using Account Level WAF to minimize configuration overheads -We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudflare-managed-ruleset/) as an example, keeping in mind that the approach can also be used for other Cloudflare Managed Rules, Rate Limiting Rules and Custom Rules. +We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudflare-managed-ruleset/) as an example, keeping in mind that the approach can also be used for other Cloudflare Managed Rules, Rate Limiting Rules, and Custom Rules. * For `web1.example.com`, `web2.example.com`, `web3.example.com` and `web5.example.org`: you want to apply the default WAF Managed Ruleset, already tuned by Cloudflare. * For `special4.example.com`: you want to apply a different subset of the default Managed Ruleset, as you already identified a couple of rules that are causing false positives on the legacy application. @@ -83,7 +83,7 @@ We will use the [Cloudflare Managed Ruleset](/waf/managed-rules/reference/cloudf Then, you can adopt the following approach: -* Deploy one instance of the Cloudflare Managed Ruleset, at the Account Level. This implements the common subset of rules for the four FQDNS requiring it. This is easier to set up and maintain than replicating the same configuration four times at the Zone level. +* Deploy one instance of the Cloudflare Managed Ruleset at the Account Level. This implements the common subset of rules for the four FQDNS requiring it. This is easier to set up and maintain than replicating the same configuration four times at the Zone level. * For `special4.example.com` and `special6.example.org`, you will deploy two additional instances of the Managed Ruleset, with the specific tweaks required by the applications behind these particular FQDNs. In practice, using the [Account Level WAF's Managed rulesets](/waf/account/managed-rulesets/), you can deploy the three instances of our Managed Ruleset. Each instance will have its own [Custom Filter Expression](/ruleset-engine/rules-language/expressions/edit-expressions/), which will check that the HTTPS requests's hostname belongs to one of the FQDNs in a list: @@ -96,7 +96,7 @@ Let's visualize the complete configuration in the below diagram: ![Diagram depicting the implemented WAF configuration at the account level](~/assets/images/reference-architecture/streamlined-waf-deployment-across-zones-apps/diagram-3.svg "Figure 3: The Account WAF implementation to protect multiple applications across different hostnames with repeatable configurations.") -This setup will provide three instances of the "Managed Ruleset", calibrated for each application group. +This setup will provide three instances of the Managed Ruleset, calibrated for each application group. If you have additional applications to be protected in the future, it is sufficient to include the new application FQDN to the filter expression. Generally, most will be added to the standard ruleset instance that is using the recommended Cloudflare configuration. Another common strategy is to add new applications to the `Log` mode instance, so that it can be monitored and eventually transitioned to the `Default` mode ruleset or to a more specific variation if required. @@ -117,7 +117,7 @@ This approach can be simpler when there are few exceptions to the norm, and when ### Using Lists Cloudflare provides the ability to create [lists of hostnames](/waf/tools/lists/create-dashboard/). In this case, the Filter expression can be changed to reference such list variables. -You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules but also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration. +You can then update the lists directly and re-use them across multiple rulesets. For example, use the same list for the Cloudflare Managed Rules and also for the OWASP Ruleset and Rate Limiting. Your filters [will reference the lists directly](/waf/tools/lists/use-in-expressions/), meaning a cleaner and maintainable configuration. When using lists, it is also much easier to adopt a "catch all rule" that runs last in the evaluation order. This could implement, for example, the `Default` Cloudflare Managed Ruleset when the host in the HTTPS request is not included in any of your lists. This ensures that a default WAF Managed Rules configuration is always applied, in case some of your applications are not added by mistake to the lists. @@ -125,24 +125,24 @@ When using lists, it is also much easier to adopt a "catch all rule" that runs l The WAF configuration can be managed [via API calls](/api/) and [Terraform](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). This is particularly useful when you want to scale the approach to many more zones and FQDNs, and to avoid repetitive and manual tasks in the Dashboard. -For example, a default Terraform configuration file could be created to define Rulesets and Lists, and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard. +For example, a default Terraform configuration file could be created to define Rulesets and Lists and then maintained and applied as needed without needing to make changes in the Cloudflare Dashboard. ### Avoid mixing setup at Account and Zone level -When possible, Cloudflare recommends to maintain the configuration at the Account level, in particular when a Cloudflare Zone will contain multiple DNS records, each requiring custom configuration. +When possible, Cloudflare recommends maintaining the configuration at the Account level, in particular when a Cloudflare Zone will contain multiple DNS records, each requiring custom configuration. At the Zone level WAF, you can deploy only one instance of each ruleset (Managed Rules, OWASP Rules, etc.), and therefore handling special scenarios can be more complex or not possible at this level. ### Custom Rules and Rate Limiting Rules -The approach described above for Managed Rules can be applied also to [Custom](/waf/account/custom-rulesets/) and [Rate Limiting](/waf/account/rate-limiting-rulesets/), extending the flexibility to all the WAF security tools at your disposal. +The approach described above for Managed Rules can be applied also to [Custom Rulesets](/waf/account/custom-rulesets/) and [Rate Limiting](/waf/account/rate-limiting-rulesets/), extending the flexibility to all the WAF security tools at your disposal. -Unless your configuration is specific to a single zone, Cloudflare recommends to implement it at the Account level. +Unless your configuration is specific to a single zone, Cloudflare recommends implementing it at the Account level. -For more information, please refer to the Cloudflare Documentation: +For more information, please refer to the following resources: * [Create a Rate Limiting Rule at the Account level](/waf/account/rate-limiting-rulesets/create-dashboard/) * [Create Custom Rulesets at the Account level](/waf/account/custom-rulesets/) ## Summary -In conclusion, this design guide illustrates how you can implement flexible WAF configurations covering multiple applications and domains. The described approach reduces the effort required to deploy, maintain and update your WAF security configuration. +In conclusion, this design guide illustrates how you can implement flexible WAF configurations to cover multiple applications and domains. The described approach reduces the effort required to deploy, maintain, and update your WAF security configuration.