Recently, there are many DDoSes on my website, so Cloudflare support recommended me to also use Cache Everything. Luckily, last time when I was on DDoS I turned on UAM and all of the requests were cached (before that attack has been happened UAM was turned off).
So I followed up this guide and created page rules to Cache Everything.
In tab Analitics you can see that many of requests come uncached.
Cloudflare let me add only one picture at the time, so I fitted all screenshots here
A DDoS attack is by nature a targeted attack. When hackers use their botnets to probe for vulnerability, or to try and bruteforce passwords, they tend to use a many-to-many approach. But in the case of a DDoS attack, it’s a many-to-one approach, and that one is known to the attacker with a lot more detail. The hacker is likely monitoring any changes you do to protect your site and adjusting accordingly.
Cache Everything will help mitigate a DDoS to a certain extent, by adding HTML to the file types Cloudflare will cache. By default, CF only caches files that are expected to be static by nature, such as images, JS, CSS etc, and a Cache Everything setting will add HTML and certain redirects to the game.
But as soon as the hacker gets to notice the responses are all being cached, they may adjust their strategy by requesting random, non-existing URLs, either by appending a query string or simply by adding a random alphanumeric string to the path, to force Cloudflare to request the page from the origin.
Even with a Cache Everything page rule, a visit to example.com/path-1/ with get a different response than a visit to example.com/path-2k2302lk32j3/ etc. And first visits via a certain colocation are never cached. Also, even a page that is cached by one colocation may be requested again from another colocation, resulting in another request to the origin, as the pool of IPs used by the hacker may contain IPs from many regions in the globe.
You’d need to check the origin server logs to see which files are being requested directly, to try to identify any patterns that may be acted on with a new or adjusted firewall rule.
Also, you may want to review your standard cache setting, as it relates to query strings, by visiting Dashboard > Caching > Caching Level.
