The Cloudflare Web Application Firewall (WAF) blocks more than 57 billion cyber threats per day. That is 650k blocked HTTP requests per second. The original code that filters this traffic was written by Cloudflare’s now CTO and the WAF has since received many accolades including the highest score for ability to execute in the 2020 Gartner Magic Quadrant for WAF.
Because we value replacing code when it is no longer as maintainable, performant, or scalable as it once was, we regularly rewrite key parts of the Cloudflare stack. That’s necessary as our enormous growth makes yesterday’s solutions unworkable. For some time, we have been working on replacing that original LuaJIT code John wrote with new code, written in Rust, along with an improved UI.
We are now excited to announce a new Cloudflare Web Application Firewall.
Starting today, 10% of newly created accounts on Cloudflare will be given access to the new WAF whenever a Pro plan zone or above is added. This percentage will increase to 100% of new accounts over the month of April, after which migration efforts will commence for existing customers. Enterprise customers may migrate early by contacting their account team.
The Web Application Firewall (WAF) is a core component of the Cloudflare platform. As one of the most used products in the portfolio, we have gained a lot of feedback and experience from running it at scale, that helped guide us in this major iteration. The new WAF brings:
- Better rule browsing and configuration - easy one click deploy without losing the power tools: advanced filtering, bulk editing, rule tags and more. Turning on all WordPress rules, setting all Cloudflare Managed Rules to LOG or figuring out which rules are not running is now easy.
- A new matching engine - written in Rust and supporting the wirefilter syntax - the same syntax used by custom Firewall Rules. This engine will allow us to have faster managed rule deployments and the ability to scale to the next level by allowing the WAF to be deployed on even more traffic. All while improving performance and security.
- Updated Rulesets - the new WAF ships with updated rulesets that provide better control separating rule status from action. The Cloudflare OWASP Core Ruleset has also been improved based on the latest version of the OWASP Core Ruleset (v3.3 at time of writing), which adds paranoia levels and improves false positives rates compared to the current version available.
- Global configuration - deploy the same configuration across your entire account. Group rules as rulesets and make use of native versioning and rollback capabilities.
The list above is only a small subset of the things we are excited about and each point deserves its own post, but here are the highlights.
Better rule browsing and configuration
The Cloudflare Managed Ruleset, which includes the Cloudflare Specials1 group, is one of the main components of the WAF. It has several hundred rules that are provided and maintained by Cloudflare. In its default configuration we aim to achieve a very low false positive rate, while providing a very good security baseline for any web application. For the best possible security stance though, you should enable as many rules as possible. This means that, sometimes it’s necessary to deep dive and customise the ruleset behaviour based on the underlying application.
With the new WAF, we wanted to make sure enabling the Managed Ruleset was a one click effort with the default configuration, while allowing a much better configuration experience for those interested.
Today, to turn on our Cloudflare Managed Ruleset, you need to enable a global WAF switch and configure any rule groups of interest. The ten rule groups, which include WordPress, Joomla, PHP, and similar, are displayed directly on the page with on/off toggles. This UI does not allow to easily filter or configure rules within those groups without checking each rule individually.
Although the UI was simple, it did not allow common tasks to be executed quickly. For example: show me all rules that are off or show me all rules mitigating XSS attacks. Now, all rules are displayed in a single table - but filtering by rule status, action and tag is one click away. Rule tags are also replacing groups, and a rule may have one or more tags, making the system a lot more flexible. Tags will be used for:
- Identifying if a rule is applicable to a specific software component
- Identifying the attack vector (e.g. XSS, SQLi, RCE)
- Identifying rules that are CVE specific
Finally, we are allowing for bulk editing controls in addition to inline single rule controls to allow for faster configuration changes based on specific use cases.
As we expect the number of rules available to increase, and for more users to adopt custom configurations, we have added a review screen when deploying configuration changes. From here you can easily see any changes from the defaults, and optionally revert them.
A new matching engine
The current Cloudflare WAF, responsible for managed ruleset execution, is written in LuaJIT and is implemented as an NGINX module. The rule syntax followed a superset of the syntax implemented by ModSecurity with added features specific to the Cloudflare implementation.
By moving to a new engine we wanted to achieve:
- A safer, better and more performant environment consistent with other technologies used at Cloudflare
- Exposure of much better filtering and matching capabilities to allow for flexibility of deployment and easier exception handling
- Unified product feature set by adopting the wirefilter syntax as the basis for managed rulesets
The last point was especially important not only for us but also for our users because this syntax is already in use for our custom Firewall Rules, which even uses the same underlying Rust library to execute the filters!
The new engine is implemented in Rust, which we have talked about how much we love quite a few times before on this blog. We're also working on making sure that this new implementation not only comes with safety improvements, but speed improvements as well, the specifics of which we'll go into in future blog posts.
Updated Cloudflare Rulesets
The Cloudflare rulesets have been updated and ported over to the new WAF. Notably the rulesets now use wirefilter syntax and rule status is separated from rule action, allowing you to configure both independently.
The Cloudflare OWASP Core Ruleset has also received a major update independently from the engine. The current Cloudflare WAF implements a 2.x version of the official OWASP ModSecurity Core Ruleset. In the new WAF the Cloudflare OWASP Core Ruleset is based directly on the latest 3.3 version available from the GitHub repository.
The new Cloudflare OWASP Core Ruleset, along with added engine features, brings several improvements over the existing one:
- Fewer false positives and more powerful application generic rules
- More control over the sensitivity score, with clear indication of how much each rule contributes to the score and what the total score was on triggered requests
- The addition of a paranoia level - to provide easy inclusion or exclusion or rule groups based on false positive risk
- Rule tags to allow deployment with pertinent rules based on the application
As part of the efforts to convert the latest version of the OWASP ModSecurity Core Ruleset to its Cloudflare implementation, the team has also built a ModSecurity to wirefilter syntax converter. This will enable us to easily deploy and update the ruleset shortly after any upstream improvements to ensure customers have access to the latest version at all times. We also plan to open source and expose the converter in the UI in the future to make customer migrations from ModSecurity-based WAFs to Cloudflare easier.
Cloudflare has operated on a zone-based model for the Cloudflare WAF since the beginning. This serves well for simple use cases where customers are protecting a small number of applications, or a very diverse set of applications on a per-zone basis.
With the new WAF, ruleset deployments can be made across any arbitrary filter of traffic under a single account. For example:
- Deploy Cloudflare Managed Ruleset across all my zones.
- Deploy Cloudflare OWASP Core Ruleset on all traffic that does not contain
/api/*in the path.
- Disable the Managed Rulesets across my account for traffic coming from my IP.
This enables powerful account wide WAF configurations with a couple of clicks.
To achieve this, rulesets (group of rules) become a first class concept, and are natively versioned allowing for both rollback and diffing capabilities directly in the UI — features that we plan to start exposing in the coming months.
Account-based configurations will initially only be available to Enterprise customers who can now request early access by contacting their account team. Custom Firewall Rules themselves will soon be migrated onto the new engine, allowing for customers to also create their own custom firewall rulesets, and deploy them as needed on any traffic filter.
A new platform for new features
There is a lot more to the WAF than meets the eye and the team is already busy finalising a set of additional features built on the new WAF — these include improvements to the engine itself, better analytics and visibility into actionable events. The entire engine is in fact designed to be the basis for many of the Cloudflare rule-based products, with the aim of ultimately representing the entire Cloudflare configuration as a set of rules.
In the meantime, we look forward to your feedback and we are excited to see how far we can innovate.
1The Cloudflare Specials are rules written by the Cloudflare security team based on observing and protecting millions of web applications that sit behind the Cloudflare platform.