Announcing Firewall Rules

Threat landscapes change every second. As attackers evolve, becoming more dynamic and devious, vulnerabilities materialize faster than engineers can patch their applications. Part of Cloudflare’s mission is to keep you and your applications safe. Today, Cloudflare is launching a new feature, giving customers what they have been requesting - fine-grained control over their incoming requests.

Cloudflare already offers a number of powerful firewall tools such as IP rules, CIDR rules, ASN rules, country rules, HTTP user-agent blocking, Zone Lockdown (for these URIs only allow traffic from those IPs), and our comprehensive managed rules within our WAF (Web Application Firewall). But sometimes, you need to combine the power of these to fully mitigate an attack, and to express a block rule that breaks the boundaries of the existing tools, to be able to “block traffic to this URI when the request comes from that IP and the user-agent matches one of these”.

© Stefano Kocka : Source Wikipedia

Common themes arose when we spoke to customers about their needs and also reviewed feature requests that our customer support team had seen, and we categorised the top pieces of feedback and feature requests into three core needs:

1. More flexibility to create a firewall rule that matches more than just a single attribute, like an IP address and User-Agent

2. Flexibility to not only exactly match an attribute, but also partially match it, through using a string or a pattern, for example User-Agent: *Firefox*

3. Complete self-service control through the UI and Cloudflare’s public API, even for the most complex firewall rules

The team worked together to investigate what a fresh approach to our firewall would look like, with one overarching mission being front and center: build a Swiss Army knife of firewalls for our customers. Our key objectives were to:

1. Provide a tool to give customers flexible and granular control of their traffic

2. Maintain a smooth and intuitive user-experience, something we thrive on delivering

3. Ensure it is accessible and usable by all of our customers, regardless of user skill or business size

Cloudflare’s new capability, Firewall Rules, provides customers the ability to control requests, in a flexible and intuitive way, inspired by the widely known Wireshark®  language. Configuration of rules can be done through not only our Dashboard and API, but also through Terraform (link here).

The Firewall Rules engine can be thought of as 2 components:

• Matching: define a filter that runs globally and precisely matches your traffic

• Action: declare the action Cloudflare should apply when the filter is matched

Simply put, when the filter matches, apply the action.

Cloudflare Firewall Rules gives customers access to properties of the HTTP request, including referer, user-agent, cookies, Cloudflare Threat Score (IP reputation score), and more.

All of the supported headers can be matched by many operators, including, a partial match (contains), complete string or integer match (equals), and for our Business and Enterprise customers, pattern matching (matches). Yes, you read that right, we now offer pattern matching using Regular Expressions, directly through the Dashboard and API!

The great thing about Firewall Rules is the flexibility for Cloudflare to field options; for example, Cloudflare’s Threat Intelligence, which drives our Security Level functionally on the Dashboard, will be an available field for customers. One of the most important fields Cloudflare is introducing is our cf.client.bot field, which verifies known good bots via reverse DNS. In our initial release, we provide customers access to the general classification of “Known Good Bots”. Details on the list of these bots can be found here. Cloudflare has historically allowlisted Google on behalf of our customers, and utilised Web Application Firewall rules, which are only available to Pro customers and above, to block spoofed crawlers. With Firewall Rules, all customers now have access to these protections. As Cloudflare has removed the allowlisting capability, it is important that customers include simply cf.client.bot in an Allowed rule, to avoid inadvertently blocking good crawlers which could affect your SEO and monitoring.

All of the standard Cloudflare actions such as JavaScript Challenge, Challenge and Block are available.

There is one new addition to the standard mitigation list, which is the allow action, which provides a customer the ability to create Rule to say “if this criteria is matched, stop processing further rules”.

Sure, here’s four cool examples that we see being used today. Advanced or nested rules are not supported in the Visual Rule Builder today. These are noted below each rule.                                                                                                            

Example 1 - Challenge all countries except GBSupported: Visual Builder, Expression EditorThis can be done using our IP Firewall but would require 150+ rules!

(ip.geoip.country ne "GB")

Example 2 - Advanced Hotlink ProtectionSupported: Visual Builder, Expression EditorCloudflare’s built-in hotlink protection can be restrictive for some customers as it does not provide abilities to bypass certain paths. This also can sometimes catch legitimate crawlers.

(http.request.method eq "GET" and http.referer ne ".example.com" and not http.user_agent matches "(googlebot|facebook)" and http.request.uri.path eq "/content/")

Example 3 - Blocking Clients with a Threat Score greater than 10 or Clients originating from an abusive network by AS Number, to my Login pageSupported: Expression EditorOne of the great things about Firewall Rules is that we have provided you access to cf.threat_score, which is what powers the Security Level within the dashboard today.

(http.request.uri.path eq "/login" and (cf.threat_score < 10 or ip.geoip.asnum eq 12345))

Example 4 - Zone Lockdown-like-Use case utilising Regular Expression, IP address CIDRs, Country Code and AS Numbers to protect authentication endpoints via both Wordpress website, and an API.Supported: Expression EditorZone Lockdown is a great tool; however, it is limited for some critical use cases. Here’s something quite crazy to demonstrate the flexibility:

((http.host eq "api.example.com" and http.request.uri.path eq "/api/v2/auth") or (http.host matches "^(www|store|blog)\.example.com" and http.request.uri.path contains "wp-login.php") or ip.geoip.country in {"CN" "TH" "US" "ID" "KR" "MY" "IT" "SG" "GB"} or ip.geoip.asnum in {12345 54321 11111}) and not ip.src in {11.22.33.0/24}
111

This is an awesome addition to the Firewall, as it provides our customers a way to choose between running a Positive Security policy (allow specific requests and deny everything else) or a Negative Security policy (block specific requests and allow everything else).

Cloudflare default for Firewall Rules is an implicit allow all. The great thing about this method of working is being able to block just the bad stuff. Whilst this is a very effective and efficient way of running a firewall, it causes a number of challenges. By letting all traffic through, your security operations have to be reactive when issues arise.

What the security industry has been pushing is a concept of "Zero Trust". Just as it sounds, Zero Trust means you trust nothing, and everything that comes through has to have some kind of justification. To create a "Zero Trust" security policy, you have to reverse the way your firewall default policy works, i.e. changing the last action from allow to block - aka. a positive security policy. Before today, this was not possible; however with Firewall Rules, now you can.

One of the biggest concerns about giving customers power, is delivering that power safely and effectively. The product design and UI engineering team worked through multiple iterations to create a powerful but approachable rule builder and editor. The team spent a number of months working through a number of iterations to create solid rule builder and a rule editor solution without cluttering or complicating the UI.

Pete Thomas, our Lead Designer on the new Firewall UI took us back to basics running paper prototyping sessions to test and discover how rules are built and managed.

Below is a photo of myself and Matthew Bullock, one of our London Solutions Engineers, going through the testing process.

Through the design process, we wanted to focus on why customers would need Firewall Rules. The results were simple, create proactive defensive rules, to secure an application, and reactive rules, to protect applications that were being attacked.

Within the Visual Rule Builder, we have provided customers an intuitive way to create Firewall Rules, whilst not restricting access to the core functionality. The future roadmap delivers more flexible grouping through the Visual Builder. However, we do have an option for more complex requirements or nested Firewall Rules. These can be created within the Rule Editor, which is based on our Wireshark®-inspired language that allows you to take expressions created in Wireshark and create Firewall Rules. David Kitchen, the Engineering Manager responsible for developing Firewall Rules will be writing a blog in the coming weeks detailing why we chose a Wireshark®-inspired DSL for our filter expressions. For a list of supported fields, head over to our documentation.