Cloudflare TV

Firewall Feature Walkthrough

Presented by Zein Jaber
Originally aired on 

Screen demo of the Firewall tab of the Cloudflare dashboard. In depth demo of the Firewall Rules feature.


Transcript (Beta)

Hi everyone. Thank you all for joining. My name is Zein Jaber and I'm a product specialist at Cloudflare.

I have also held a position for a technical support engineer for about two years.

Today I will briefly talk about the Cloudflare security products and then go through a live demo to show you how do you benefit from the Firewall product to protect your business against different layer 7 attack vectors.

I will also cover the most common use cases being asked by our customers.

So if you have any questions, please submit them to live studio at and I will try to answer them during the session.

So let's get started. Okay, I'm just going to present my screen share.

Okay, so I like to begin any conversation about the product by grounding in the mission because it guides everything we do.

Our mission is bold but simple to help build a better Internet.

One that is faster, more secure and more reliable for all.

Let's first talk about security.

Our vision is to empower teams of any size and technical sophistication to keep their Internet property safe and secure without sacrificing speed and performance.

Our goal is to secure any combination of platforms including public cloud, private cloud, on premise, SaaS applications and IoT devices.

This is our security suite of products.

We are passionate about creating security solutions that protect our customers, customers applications and data agnostic of where it resides either on premise or in the cloud.

That's our main focus. So we put that in the center of our design philosophy.

Then we look at the threat landscape of our customers like zero day vulnerabilities, brute force attack, brute force login, API abuse, DDoS attacks, bot attacks, and so on.

And we purposefully build security products to protect against those.

As part of our global cloud platform, we offer security as a service to prevent attacks that attempts to leverage any of the attack factor mechanism shown in the slide.

Our offering includes WAF, layer three protection using magic transit, layer four using spectrum, layer seven DDoS protection, freight limiting, SSL, TLS and DNS.

Also we offer Cloudflare access for Zero Trust security and bot management.

In the next slide, I will I will go through what's inside the firewall product.


Let me just present my screen again. There we go. So, the firewall product consists of large security chain, including IP access rules, firewall rules, zone lockdown, user agent, and so on.

That also includes rate limiting and managed pools or the web application firewall.

For example, firewall rules only evaluate requests that first clear IP access rules.

If a request is blocked by any rule at any stage in this chain, then Cloudflare does not evaluate the request further.

Now let's go through a live demo to walk you through what's inside the firewall application and how do you use it, how to use each feature to protect your business against layer seven attack factors.

So I'm going to switch to my dashboard. As you can see here, the firewall application is located under the firewall app on the Cloudflare dashboard.

The first tab is the overview tab that shows you the firewall analytics.

It allows management and visualization of threats. That helps you tailor security configuration.

So it allows filters and exclusions and provides detailed data for a predefined duration between 30 minutes and 72 hours.

So events by action, it provides the count of firewall activities per action, including block, log, challenge taken on your traffic.

The next section is the events by service, it lists it lists the activity per Cloudflare security and feature web application firewall rules, access rules.

And the next session section is the top events by source. This will show you the detailed traffic flag or action by a Cloudflare security feature.

This includes IP address, path, host, ASN, and so on.

Okay, so moving on.

The next section is the activity logs. This is where you can see the summary of your firewall events by date to show the action taken and the Cloudflare security features applied.

You can expand you can expand your activity logs to see additional data like the array ID method, IP address that was used for that request.

So you get exposed to more data in the activity logs.

So this is just a quick overview on the firewall analytics. Moving on to the manage rules.

So here where you can see the web application firewall here where you turn on the web application firewall.

And, yeah, basically, the web application firewall comprised of three, three main rule sets.

The first one is the Cloudflare managed rule set contains security rules written and created by our firewall application firewall team.

These rules protect different types of a type of a tag vector.

So for example, if you have a including SQL injection, cross site scripting, some of these rules are specific to certain applications like Joomla.

As you can see here, the like Joomla and Cloudflare flash, Drupal, and so on.

If you click on a group, you will reveal different web application rules specific for Drupal, for example, you would see the ID, its description, and you will see the default mode.

You could also change each rule ID from you can either disable it, set it to simulate, or you can set it to block or challenge.

Moving to the top. We have the OWASP in addition to Cloudflare manageable sets.

We have also integrated the OWASP in our firewall. And this is created by the open web application security project group to provide protection against common attack categories, including SQL injection and cross site scripting.

The way OWASP works, it assigns a score to each request based on how many OWASP rules trigger.

Some OWASP rules have a higher sensitivity score than others.

After OWASP evaluates a request, Cloudflare compares the final score to the sensitivity set on your OWASP.

And if that exceeds the sensitivity set, then it will be action based on the action you set here, either a simulate, challenge, or block.

And the third rule set is the custom request rules or the custom map rules.

These are created by our firewall and custom support engineers that are tailored to your specific needs.

For some of you who don't know, we no longer create custom map rules, you should be able now to use the benefit to use firewall rules to create them right inside the firewall rules.

For example, now you should be able to create create rules to inspect for headers and body, bodies as well.

You can also create HMAC authentication right inside the firewall. So that's it for the WAF.

Now I will talk about the firewall rule feature, which is in the third tab.

So firewall rules, it provides the customers, provides the customers a tool to have a flexible and granular control of your traffic.

So it allows you to control incoming traffic to your zone by filtering requests based on IP address, URI, user agent, and many more.

And the tool section, the tools section here, we offer additional security tools or products, including IP access rules to block IPs, ranges, country name, ASN, and so on.

Another important tool is the rate limiting.

This is helpful if you are under DDoS attack, or if you want to block any brute force attack your login page.

We also offer user agent blocking to block specific user agents.

You can also use zone lockdown if you want to lock your internal application to specific IP address.

This zone lockdown is a useful tool as well.

Okay, so this is a quick overview of the firewall application here.

I'm going to switch back to my slides.

Just to put all of these features into action, I have prepared some common use cases that are being asked by our customers on a daily basis and show you how, how do you tackle these kind of problems and troubleshoot them.

So the first use case is when you have a firewall rule to allow an IP address, but the web application firewall has also triggered on the same request and blocked it.

As you can see here in this example, I'm going to go to my firewall rules to show you the rule I have created.

So under allow IP, I have created a simple rule to allow IP

If I switch back to my firewall event, you would see the request has triggered first on the firewall rule, it was allowed, and then it was also triggered on the web application firewall.

The reason why the request was flagged by the WAF, it's because it has no user agent.

But the reason why the request continued and it didn't stop at the firewall rule, because of the allow action you have used in your firewall rule.

So the scope of allow action is limited to firewall rules.

Matching requests are not exempt from actions by other Cloudflare firewall products like WAF, rate limiting, and so on.

So if you want to work around this issue, you have different ways. You could take this IP address and whitelist it in IP access rules.

And once you have this IP whitelisted and a request is coming from, the request should bypass the security chain, including firewall rules and web application firewall.

You could also use the manage rules to create a rule. Sorry, you could you could use firewall rule to create a rule to look for the IP address.

And you can use the bypass action if you really trust this IP address, bypass manage firewalls.


The second use case is when you have your request or the IP address get challenged by the security level.

So as you can see here in this example, this IP address was challenged by the security level.

So the security level uses an IP reputation of a visitor to decide whether to present a CAPTCHA challenge page.

IP reputation is collected from Project Honeypot and Cloudflare internal IP reputation database.

And the reason why the security level has triggered because you have a security level set to high and based on the score that the IP address was given it exceeded the the the score level here and a challenge was issued.

To work around this issue, you can create again a firewall rule to look for that IP address and you can use bypass action to bypass security level on that IP address.

Okay, moving on.

You often see requests get blocked by the sanity check.

So first, what is a sanity check?

Sanity check is the first layer of defense in our network. For example, requests containing certain attack patterns in any HTTP request header are blocked by the sanity check service.

So, for example, if there is any suspicious user agent that host header, etc.

and the request, sanity check will immediately block those kind of requests.

As you can see in this example, sanity check has triggered because it's so a user agent, if you notice that there is a malicious content in the user agent itself and it has blocked it.

And at this point, you can't disable sanity check on your zone on a DNS proxy records.

The only way to disable to bypass the sanity check is by disabling the DNS record that is affected.

So there is a possible change in the future could the sanity check could be moved to the manage rules and you should be able to control it there.

Okay. Moving on.

Another use case that we commonly see is is when you have a request using Google user agent, but the request is still blocked by the web application firewall.

When investigating these type of issues, the First, you need to look at the at the event by source section here and look specifically for the IP address user agent and the ASN network.

And in this example, as you can see this user agent looks to be a Google bot user agent, but the incoming request is not coming from Google network.

Therefore, the manage rule 100201 detected that this is a fake Google bot and it blocked the request.

And just going to switch to my Terminal just to show you how we check for a fake Google bot IP address.

This is something what Google does as well.

And so first, the, the, we use an R DNS reverse DNS lookup validator and if we see the IP address that ends with suffix Google bot .com Or then you would need to use a forward DNS lookup to the pointer and then if it points back to the same IP address, then this is a verified Google bot.

To demonstrate this I'm going to use the host command and or you can use the NS look In this example, you see the reverse DNS return the pointer to crawl.

The Google

So that's the first step, then you would need to do a forward look up on that pointer.

And if the IP address returns the same, then this is a verified Google bot and this way, part of our validation we check for good or bad Google bot IP addresses.

And so in this example, and As you can see the request. The request has been triggered by the web application firewall and blocked it.

So those are true positive Okay.

And last but not least, I will show you three use cases.

Where you can create rules you were previously asked an email support to write custom F rules for you.

I want to show you three use cases and show you the benefit of firewall and how easily and quickly that you can write advanced rules into firewall rules without contacting the customer support in the first place.

The first example. I'm going to switch to my firewall rules and the first example is the header inspection.

Previously, you were not able to create such kind of rules in firewall rules, you have to email support and ask Customer support and firewall engineers to write such kind of rules for you.

So here, as you can see, you can create rules to inspect for specific headers that has specific values and let's try that by enabling it and I'm going to Let's try this curl.

You can either use curl or your browser and I'm going to use curl at in the terminal here and I'm going to specify the custom header.

And I'm going to use a different value.

The request should be let through. If I use the same value in the custom header.

In fact, that should be custom. Let's try again.

Okay, the request to let through. If I add a value that matches with the firewall expression, I would expect it all to be blocked.

So you see the power of the firewall rules and yeah how easy now that to create custom firewall rules right inside the firewall rules.

Okay, moving on to the body inspection as well. You should be able to create Body inspection rules inside of firewall rules to look, for example, a form called username that contains admin, then you can block it.

Let's demonstrate this by having this form.

I have prepared the HTML file. And Let's try the rule is disabled.

Now let's try to send admin. The request let through.

If I switch back to my firewall rules and enable the rule. I should expect the rule now to be blocked.

I think there is a caching here. So if I use If I use my Firefox in a private mode.

Let's switch here. And do admin.

Here we go. As you can see the rule, the request would be blocked because it matched the body inspection form in the firewall rules.

Okay. Last but not least, for the common use cases.

As you can see here, the last rule I have created.

Now you can create firewall rule to look for specific ports. If you want only to allow rules on port 80 and 443 or maybe you want to allow requests on port 8080 as well.

You can specify them in your firewall rule. And let's demonstrate this example.

So I'm going to switch to my terminal. Let's use the same example over here.

I'm using the default HTTP. I'm using HTTPS on

I could specify 443 the request should be let through. And let's try now port 80.

Same thing if I use now 8080 I would expect the request to be blocked.

And as you can see here, it's forbidden and it was blocked.

Okay. Yeah, I would.

So yeah, these are the main common use cases that we help customers on a daily basis.

And I hope these are helpful. Just to show you how easily, you know, and how powerful firewall rules are.

And I hope these community use cases, you know, allows you now to troubleshoot You know requests related to security level, for example, and send it to check when requests are triggered by WAF and so on.

And there is a, there is an announcement here in the audit logs and We have recently released the feature to add additional logs in inside audit logs for firewall events, for example, for firewall rules.

And as you can see here, the new value and the old value.

These have been added into the audit logs. This is something is helpful if you have issues, for example, or if you want to know why a firewall rule was Disabled who made the change, you should be able to tell from the audit logs or if you want to know or find an answer of why a specific rule has stopped working suddenly Again, in the audit logs, you should be able to find who has made the change.

If the filter has been changed and so on and Yeah, if you would like to learn more about Security in general and about our security products, you can visit help center and the learning center and you can follow us on Cloudflare blog and The what's new website as well to stay tuned on on any product updates and use and just going to leave the last three minutes to check if you guys have submitted any questions.



No questions so far. Okay, I'm just going to check just to double Check as well.

All right.

Um, So yeah, thank you all for for watching. This has been great. And now stay tuned.

For the next segment about to really mess up takes a computer presented by Watson lad Peter who and Tom streaks.

Thank you. So You You A botnet is a network of devices that are infected by malicious software programs called bots.

A botnet is controlled by an attacker known as a bot herder. Bots are made up of thousands or millions of infected devices.

These bots and spam still data fraudulently click on ads and engineer ransomware and DDoS attacks.

There are three primary ways to take down a botnet by disabling its control centers.

Running antivirus software.

Or flashing firmware on individual devices. Users can protect devices from becoming part of a botnet by creating secure passwords.

Periodically wiping and restoring systems and establishing good ingress and egress filtering practices.