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.
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.
(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).
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.
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.
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 HighSecurity Level and lower Challenge Passage5 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.