403 Error with WAF "Managed Challenge" on all pages

[CarlosJes]

Hello,

lately my servers got attacked. Those attacks also reached my origin servers, because Cloudflare was not able to see the difference between real users and those Bot users (Botnet, different user-agents, different IPs).

To fix the problem, I was required to enable those Managed Challenge on all pages (“Under Attack” mode did pretty much nothing). With that WAF rule the attack stopped, but my real users received empty pages without CSS, JS, etc.
The rule is just (http.request.full_uri contains '[MY URL]") than “Managed Challenge”

The issue seems that Cloudflare asks every time for a “Challenge” for some CSS, Media, JS, etc. even though the user finished the Challenge on the requested DOC.

When I now double-click on for example “video-bg3.png”, it opens it up again, asks for challenge – after doing the challenge I can see the resource. When I then close it, and again double-click on it, it AGAIN asks for the challenge.

It’s obvious that no page will load correctly, when Cloudflare asks for a challenge on every resource, every time.
When disabling the WAF Rule, everything works correctly – It’s not my origin servers making the issues.

(Using OperaGX browser)

Anyone any solutions what to-do?

[jnperamo]

Can you share the URL of your site?

Consider checking these guides:

Mitigating an HTTP DDoS Attack manually with Cloudflare

This guide is for those users of Cloudflare who experience medium-high level complexity DDoS attacks. Continue reading if you want to accomplish the following: Becoming more familiar with the Cloudflare Dashboard and crafting custom firewall rules. Understanding the standard behavior of DDoS attacks and deploying effective firewall rules. Realizing how powerful and valuable Cloudflare Firewall Rules are. I initially thought of making a more complex guide (I will). However, I realized that no…

Understanding Under Attack Mode

Introduction Under attack mode (UAM from now on) is the first shield Cloudflare has to offer against DDoS and Bot attacks, it’s been around for nearly a decade, and even after all this time, it still holds strong against most attacks. While its performance is good, customers must understand how it works and, most importantly, its limitations and how to deal with them. The technique It makes sense that we study the big picture of what’s going on behind the scenes of this screen. …

[CarlosJes]

Unfortunately, I’m not allowed to share the Domain. But for example Chrome browser or IOS Safari it works correctly.

Could it be a problem from Opera GX itself?
Thank you for your incredibly fast answer. That’s just INSANE!

[jnperamo]

@CarlosJes

Could it be a problem from Opera GX itself?

Opera GX might not be sending the challenge cookies to the paths you posted; if that’s the case, visitors will face another managed challenge and thus causing website malfunction.

If that’s the case, a “quick” fix (if that’s the case) is following the first guide I sent and challenging only the malicious requests.

[CarlosJes]

Yes, you’re fully right. I compared the Network data things on Opera GX to Chrome. And on chrome in the cookies-header there is this “cf_clearance=****” while on Opera GX it’s fully missing.

I will check out your guides.
Thank you!

[CarlosJes]

I made some checks and i figured out that Opera blocked the Set-Bookie header for this reason:

Whole site and media are all HTTP (not SSL)
But in chrome or firefox it’s working correctly and the set-cookie header don’t get blocked.

Also there are no cookies set at all, so it could not have overwritten a cookie

[fritex]

Is the “VPN” feature being enabled and used in that Opera Web browser?