Cloudflare WAF Rules

catgirl

New member
Have any forum administrators here used the Cloudflare Pro "WAF"? If so what rulesets did you enable/disable to block legitimate attacks while avoiding false positives?

E.g. A WAF might block a code block in a post with PHP being blocked as "code injection" when the user is actually just trying to show us a snippet of code.

I noticed a lot of XenForo's posting is done through JavaScript, is there a way to make it use a traditional style post where a new page is loaded? If Cloudflare's CAPTCHA Challenge shows up (e.g. a post looks like SQL or Code Injection) it can't be solved as it doesn't show up when jQuery receives the 403 page. To the user it's a silent failure.
 
Last edited:
Bumping this thread incase someone here has more advanced knowledge of this. After some testing I found that unless there's a way to force traditional posts instead of the jQuery API-based posts or show the Cloudflare CAPTCHA in a model that the WAF probably isn't worth using. It will block any post that shows PHP or SQL in a code block as attempted code injection. Maybe for some non-coding forums this is okay but given the nature of my personal forum I can't say it's worth it. But if I'm missing something in settings please let me know.
 
I had to disable several rules, they block XF from working.
  1. 100005
  2. 100007
  3. 100007NS
  4. 100135B
  5. 100173
  6. 100173_BETA
All rules from the "Cloudflare Specials" group, you can simply disable the group. Otherwise, you need to study the WAF logs
 
I too am having issues with cloudflare WAF and XF. Seems to happen when editing large posts. I disabled the rules above but it didn't fix it. I had to turn off the WAF altogether in order to get past the error. Hopefully someone smarter than me can determine which rule is causing the problem so we can disable that one.
 
I too am having issues with cloudflare WAF and XF. Seems to happen when editing large posts. I disabled the rules above but it didn't fix it. I had to turn off the WAF altogether in order to get past the error. Hopefully someone smarter than me can determine which rule is causing the problem so we can disable that one.
I seemed to have solved this issue by lowering the sensitivity of "Package: OWASP ModSecurity Core Rule Set" to low. Both High and Medium triggered it when editing a long post. No idea why...
 
Cloudflare recently announced an update to its Web Application Firewall (WAF). I had to migrate to new Managed Rules for the site I have a Pro plan with. Does anyone have any experience getting the Cloudflare OWASP Core Ruleset configured properly? When I enable it, it breaks normal functioning.
 
Can anybody please share his working setup of the OWASP Ruleset?

I just got migrated to the new WAF rules and immeditately the forum was not working anymore for most of my users.
 
Cloudflare recently announced an update to its Web Application Firewall (WAF). I had to migrate to new Managed Rules for the site I have a Pro plan with. Does anyone have any experience getting the Cloudflare OWASP Core Ruleset configured properly? When I enable it, it breaks normal functioning.
If you've figured this out by now, please post a full list (with all the understanding that it may depend on the add-ons and particular forum configuration).

Until we get a full list, this is what worked for me with WordPress (I understand it's not the same, but I'm yet to give CF Pro a try with a XenForo domain), perhaps it can help you start "fine-tuning" the WAF rules. Copy/pasting this from my notes:

Two asterisks ( ** ) mark the options that sometimes need to be disabled.

Cloudflare Managed RulesetEnable the following:
Miscellaneous, PHP, ** Specials, WordPress

Package: OWASP ModSecurity Core Rule Set
Sensitivity: ** Low
Action: Legacy CAPTCHA
Disable the following:
OWASP Slr Et Joomla Attacks, OWASP Slr Et PhpBB Attacks

** If you have problems updating WordPress widgets, temporarily disable the “Specials” ruleset, and set “OWASP Sensitivity” to “Off”.
 
I've been battling with cf issues for years now. Finally figured out that it's been OWASP issues. You'll have to get the ray-id from whoever is getting the error, search for the ray-id in the security tab. Once you find the connection that had the issue, you'll have to export the event and open it in notepad. In there, if you scroll down some, you'll see a section of all the OWASP rule ID's that were causing the users score to go up to the point of being blocked.

kCrqEYY.png


From there, you'll go into your OWASP settings and search for those. You can disable all of them or be picky. The other option is to also change the anomaly score. If you are like me, it's probably set to high. But changing it to medium can help prevent some of these scripts with xenforo from being blocked:
u9KdnIo.png


We just updated a bunch of our stuff and the board is running much more smoothly. It's been a few days but finally just had someone trigger a new event so I came across this thread to see if others were having the same issue and if there were better solutions out there. Seems no one has a better option that what I've disclosed here.

I'm not smart enough to figure this **** out but maybe someone else here can. I was thinking a page rule for either post-thread or post-reply to disable some of these features. Xenforo natively should prevent most if not all of the stuff that cf claims to be blocking...so I would think that it would be safe enough to put some sort of disable OSWAP on post-thread and post-reply queries.

There are also custom parameters you can add to these rulesets. I just don't know what I'd put here:
BtM8wsb.png


So instead of going through all incoming requests, you can make it so only certain types of requests are getting hit. I've set up so many firewall rules that I would feel safe with disabling this stuff on the post-thread and post-reply pages.
 
I have a WAF rule for triggering a managed challenge for visits from countries outside my primary target audience/members.
I would like to also not trigger the challenge for logged-in users, only guests/visitors. I'd expect this is possible by CF checking XF cookie?

Here's the WAF rule expression, with the cookie check at the end;
(ip.geoip.country ne "xx" and not cf.client.bot and len(http.request.cookies["xf_user"]) == 0)

Is xf_user the appropriate cookie? and setting a length check of 0 will mean it doesn't exist?
 
Last edited:
I also had to disable 949110.

#
# -=[ Anomaly Mode: Overall Transaction Anomaly Score ]=-
#
SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" "msg:'Inbound Anomaly Score Exceeded (Total Score: %{TX.ANOMALY_SCORE})', severity:CRITICAL, phase:request, id:949110, t:none, deny, log, tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-generic', setvar:tx.inbound_tx_msg=%{tx.msg}, setvar:tx.inbound_anomaly_score=%{tx.anomaly_score}"
 
Back
Top Bottom