It seems the attacker is diversifying now. More ASN’s involved. All of this is now stopped by the FW so all they are seeing is 403’s. This is now really an attack on CF as this doesn’t reach my Workers anymore.
I wish I understood the ‘Why’ of this all…
There isn’t always a why; some people just want to sabotage businesses.
Feel free to show us the complete firewall tab; I’d also appreciate it if you could show us the “extended information” of some blocked logs, a random sample of blocked requests will suffice.
I took @whistles advice at heart and have started to investigate using CF Pages instead. Quite a nice product I must say! I had a deploy done in 10 minutes after signup. I’m considering switching in a few days if this attack keeps going. Once I switched (and seeing there don’t seem to be any requests limits on Pages) - I guess it becomes CF’s problem to deal with this attack traffic? Seems a bit self-defeating to now charge me for this traffic while I could switch over (to what is essentially the same product) and not pay for this traffic anymore?
The cool thing about CF Pages is that your site is hosted at Cloudflare’s edge. It doesn’t matter what they try; no DDoS attack will bring your site down.
It’s not quite the same, as a Cloudflare Worker will need to execute code for every single request, while Cloudflare Pages just serves static files that don’t change or need any additional execution, which is why the pricing for that is very different.
Can you try deploying this firewall rule?
(cf.threat_score ge 5 and not cf.client.bot and http.request.version in {"HTTP/1.0" "HTTP/1.1"})
I’d suggest a CAPTCHA. It’s a rather aggressive rule so, some legit bots that arent registered on CF DB could be affected; you can measure the legit traffic affected by checking after 24 hours how many captchas were solved out of all challenges.
If requests still go through, you can try lowering the threat score (5).
I have moved all my full blown Worker Sites across to Pages and now use Workers for very specific tasks instead.
Highly recommended
I stand corrected 
That’s correct. Cf client bot is composed of bots that CF classifies as positive for most websites (google crawler, ahrefs, etc).
This is indeed bloody cool. However - it would be even cooler if I didn’t have to pay additionally I guess 
Sure - let me try this. Are cf.client.bot known bots that should be allowed?
Sorry I’m making a mess of this thread - I’ll do better from now on. I really appreciate all the interactions here! Thanks!
I deployed this as first rule. I’ll report back after a while.
Don’t apologize. This is a high quality thread full of very useful information.
Question: it seems rather under control at the moment, however, I did see a large peak about 30 minutes ago in normal analytics. Those were let through the FW so I do not have any information on those ‘visits’ from the FW overview. Suppose this attacker employs another ASN or another way of attacking - a way that doesn’t actually trigger a FW rule (either manual or managed) - how do I detect this? Any Tips & Tricks for that?
One way I can think of is to switch ‘Under Attack Mode’ back on so those requests end up in the FW logs (right?). Any other ways?
Most likely fresh IPs that have yet to be recorded on CF database. You can make the rule I provided more strict by reducing the threat level; that would surely catch them.
Besides that, things get slightly trickier from now on. You might want to try and export logs from Cloudflare, the information you have in the dashboard slowly becomes a bottleneck when you have to deal with DDoS attacks that leave no traces in the firewall tab.
Maybe set it to 3 or 4 first? Is that relatively safe for legitimate customers?
I am learning a lot!
You’d have to play around with this for your audience somewhat. From Fields reference · Cloudflare Ruleset Engine docs
Represents a Cloudflare threat score from 0–100, where 0 indicates low risk. Values above 10 may represent spammers or bots, and values above 40 identify bad actors on the internet.
It is rare to see values above 60. A common recommendation is to challenge requests with a score above 10 and to block those above 50.
and how they relate to CF Security Levels https://support.cloudflare.com/hc/en-us/articles/200170056-Understanding-the-Cloudflare-Security-Level
| Security Level | Threat Scores | Description |
|---|---|---|
| Off (Enterprise customers only) | N/A | Does not challenge IP addresses |
| Essentially off | greater than 49 | Only challenges IP addresses with the worst reputation |
| Low | greater than 24 | Challenges only the most threatening visitors |
| Medium | greater than 14 | Challenges both moderate threat visitors and the most threatening visitors |
| High | greater than 0 | Challenges all visitors that exhibit threatening behavior within the last 14 days |
| I’m Under Attack! | N/A | Only for use if your website is currently under a DDoS attack |
Cloudflare sets Security Level to Medium by default. Change the Security Level settings via the Cloudflare Firewall app under the Settings tab. Also, the Threat Score values mentioned above are useful as Field criteria within Firewall Rules . Security Level is also configurable via Cloudflare Page Rules.
To prevent bot IPs from attacking a website, a new website owner might set a Medium or High Security Level and lower Challenge Passage 5 to 30 minutes to ensure that Cloudflare is constantly protecting the site. Alternatively, an experienced website administrator that is confident in their security settings might set Security Level to Essentially Off or Low while setting a higher Challenge Passage for a week, month, or even year to provide a less obtrusive visitor experience.
Only use I’m Under Attack! mode when a website is under a DDoS attack. I’m Under Attack! mode may affect some actions on your domain, such as your API traffic. Set a custom Security Level for your API or any other part of your domain by creating a Page Rule for that portion of your site traffic.