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.
22.214.171.124 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
126.96.36.199 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
188.8.131.52 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
184.108.40.206 - - [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.
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:
220.127.116.11 - - [28/May/2022:22:16:57 +0300] “POST / HTTP/1.1”
18.104.22.168 - - [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.
Is the record proxied?
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.
AFAIK, Cloudflare still only speak to origins via HTTP/1.1. Only time HTTP/2 is involved is if you are using Cloudflare Tunnels - then CF Edge speaks with cloudflared installed daemon on origin via HTTP/2 or QUIC but then cloudflared to origin is still HTTP/1.1.
Haven’t really checked, I’d assume it’s in a limited parallel (capped) request capacity.
edit: ok I vaguely recall CF did trial test HTTP/2 to origin connections on some customer sites - they never really announced it publicly as a fu…
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.
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.