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.
185.188.61.86 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
63.250.57.234 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
16.170.202.159 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
212.164.63.102 - - [28/May/2022:21:57:13 +0300] " GET / HTTP/1.1"
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:
103.156.50.161 - - [28/May/2022:22:16:57 +0300] “POST / HTTP/1.1”
104.248.82.154 - - [28/May/2022:22:16:57 +0300] “POST / HTTP/1.1”
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?
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.
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.
