WAF does not work


I have a free tariff. The site was hit by DDoS attacks. The attacker loads the main page via HTTP 1.1. Since in my normal life the number of connections via HTTP 1.1 does not exceed several percent, I decided to block all clients who use this protocol. I created a rule:

(http.request.version eq “HTTP/1.1”) or (http.request.version eq “HTTP/1.0”) = BLOCK

But for some reason it does not work, although it is at the top of the list. Requests via HTTP 1.1 have been coming to the attacked site, and they are coming. - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1" - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1" - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1" - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"

What did I do wrong?

Cloudflare will always request your site over HTTP/1.1 so that is the version you will always see in your logs.

Your rules just block the HTTP version that users request Cloudflare with.

User ← Any HTTP Version → Cloudflare ← HTTP/1.1 → Origin

Your rules apply to the User ← → Cloudflare version.

1 Like

I don’t think you’re quite right. I conducted an experiment. On my site, HTTP 1.0 is practically not used at all by clients. I made a rule:

(http.request.version ne “HTTP/1.0”) = BLOCK

That is, I left clients only with HTTP 1.0 and in theory DDoS should be blocked - but in fact nothing has changed.

Another example, now the bots gateway requests to the main page using the POST method. I made a rule:

(http.request.method eq “POST”) = BLOCK

Similarly, the web server logs are full of lines: - - [28/May/2022:22:16:57 +0300] “POST / HTTP/1.1” - - [28/May/2022:22:16:57 +0300] “POST / HTTP/1.1”

That is, again, WAF does not work.

In regards to what, the HTTP version that Cloudflare uses?

Without knowing what domain you’re using or anything more about your site, it’s hard to give any further suggestions.

Is the record proxied? Do you have any page rules on that domain? Have you tried the Test Rule button next to the Action when making the firewall rule?

Sorry, I can’t understand what you’re asking.

Yes, proxy for www.site.ru and site.ru enabled. There are no other subdomains.

I don’t have such a button. Only Cancel, save as draft, deploy firewall rule


Double-checked with a few others and it seems like HTTP/2 may also appear in some scenarios, maybe it’s being rolled out in a phased approach.

As long as the records are proxied and the firewall rule you’ve created is enabled, it should ‘just work’ really. Do you have a screenshot of the full firewall rule page & the rule itself?

Beyond that, I’m not sure what else there is to suggest as I’m not able to replicate the issues that you’re having outside of opening a support ticket.

Those requests are not coming from Cloudflare. You must block requests that don’t originate from the IP ranges listed on https://www.cloudflare.com/ips/ - otherwise an attacker can simply bypass Cloudflare.

1 Like

Even if blocked, if the attacker has the server ip address that is a serious leak that needs plugging inmediatley.

Of course, these are not Cloudflare addresses, but IP clients. I have configured the web server to display the real addresses of clients. So everything is correct here.

The attack goes exactly by the domain name, and not by the server address. The IP address of the server is unfortunately compromised, I will change it in the near future.

I’m not convinced. I set up a WAF rule to block 1.1, and tested with Curl. It works (those requests are blocked).

I suspect that what you’re seeing in the log is a restored IP address, but not a restored HTTP version.

So the attacker is using something other than 1.1, but Cloudflare makes the request to your server with 1.1.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.