CF blocking all requests if user-agent contains "diamond"

There seems to be a global misconfiguration error in Cloudflare’s User Agent blocking rules. For every site that passes through CF, if the user-agent header contains the word “diamond”, the response is always 403.

Here’s commands to test it yourself. These all 403 for me, but if you change “diamond” to anything, even delete a single letter, it then works.

curl -I --header "User-Agent: Diamond" "https://deliciousbrains.com/"
curl -I --header "User-Agent: Diamond" "http://www.runa.org/"
curl -I --header "User-Agent: Diamond" "https://www.boiseauditorium.com/"
1 Like

Not a known and standard user-agent to me, at least.

My best guess is either Bot Fight Mode or Browser Integrity Check feature challenges or blocks the request :thinking:

Could you share what options have you got selected for:

  • Security Level
  • I am under an attack mode
  • Bot Fight Mode
  • Browser Integrity Check
  • Custom Firewall Rules
  • Managed WAF Rules (if using a paid plan)

You should see the challenged/blocked firewall events in the firewall events if you navigate to the Cloudflare dashboard → Security → Overview and lookup for Firewall events for the past 24hours or so. Once you find them, click on a particular one to find more details about it (user-agent, IP, HTTP version …).

Could you share some details which service was triggered that blocked you? :thinking:

You could determine if this behaviour continues even by using a “Pause” option at Cloudflare as follows:

  1. Use the “Pause Cloudflare on Site” option from the Overview tab for your domain at dash.cloudflare.com .
  2. The link is in the lower right corner of that page.
  3. Give it five minutes to take effect, then make sure site is working as expected with HTTPS.
  4. Re-try with updating.
  5. Upon success, un-pause and continue using Cloudflare.

Otherwise, maybe the hosting provider is Cloudways? :thinking:

Hi,
True it’s not a standard user-agent, but was a minimal test case to reproduce the issue. I only run one those websites listed and when I checked under the Security Overview I did see Browser integrity check failure for my test requests.

However the issue is that CF has a problem with the word “diamond” itself, no matter its context in the user-agent header. I first came across this issue on my site that is WordPress powered. I have a plugin, WP Migrate, that makes API calls to https://api.deliciousbrains.com/. WordPress sets the User-Agent on server based requests to WordPress/<version>; <site-url>, which on my site is WordPress/6.1; https://dev.bluediamond.com. The “diamond” in the domain name is getting the request 403’d.

This command recreates the request (minus the payload):
curl --header "User-Agent: WordPress/6.1; https://dev.bluediamond.com" "https://api.deliciousbrains.com/"

Could you share what options have you got selected for:

Security Level: Medium
I am under an attack mode: Off
Bot Fight Mode: Off
Browser Integrity Check: On
Custom Firewall Rules: None

Otherwise, maybe the hosting provider is Cloudways?
They’re all definitely protected by Cloudflare, it’s in the response headers.

1 Like

I also wanted to add these examples to point out why this simple word blocking is such an issue. If I use my browser’s actual user agent in the request, it goes through, but if I add the word “diamond”, it fails, it makes no sense how that word triggers Cloudflare rules:

Normal UA:
curl -I --header "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0" "https://api.deliciousbrains.com/"

With “diamond”:
curl -I --header "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0; diamond) Gecko/20100101 Firefox/106.0" "https://api.deliciousbrains.com/"

1 Like

Seems like a valid report… I agree that this is an odd behavior.
I will try to get the attention of the dev(s) of the feature to see what the reason might be. Does it only happen with BIC enabled?

1 Like

Since it’s related to the WordPress, I’d suggest you to whitelist your origin host / server / hosting IP address by navigating to the Security → WAF → Tools → IP Access Rules with the action “allow” for your Website and try again.

It knows to happen due to the WordPress using HTTP/1.0 and empty user-agent, therefore while executing WP-Cron or some other related JSON/REST API request via plugin.

Yes, only with BIC enabled.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.