Blocking additional cloudflare specials

[matthew.giannelis]

I am currently operating a standard wordpress blog as a news publication.

Looking at the Cloudflare specials ruleset in WAF I have noticed quite a few of these that arer not turned on by default.

I understand some dont apply to me due to being for a different CMS. Howerver, I would like to list some of these (that are not turned on by default) and request some advise in regards to if I can/should turn these on. (Block)

These are

Drupal, Wordpress - DoS - XMLRPC - CVE:CVE-2014-5265, CVE:CVE-2014-5266, CVE:CVE-2014-5267

Wordpress - DoS - CVE:CVE-2018-6389

Wordpress - REST API - Invalid Post ID - Body

Wordpress - REST API - Invalid Post ID - Rest Route

Anomaly:Body - Large

Anomaly:Body - ReGeorg webshell

Anomaly:Header:Accept - Invalid

Anomaly:Header, Anomaly:URL - Invalid UTF-8 Encoding - All

Anomaly:Header:Content-Type

Anomaly:Header:Content-Type - Missing

Anomaly:Header:User-Agent, Anomaly:Header:Referer - Missing or empty

Anomaly:Header:User-Agent - Empty

Anomaly:Method - Unknown HTTP Method

Anomaly:Method - Unusual HTTP Method

Anomaly:URL:Path - Multiple Slashes, Relative Paths, CR

Anomaly:URL:Query String - Multiple Slashes, Relative Paths, CR, LF or NULL

Anomaly:URL:Query String - Relative Paths

Apache HTTP Server - Server-Side Includes

Apache Struts - Code Injection - CVE:CVE-2018-11776

Command Injection - Sleep

File Inclusion - Double Slash Path

jQuery File Upload - Dangerous File Upload - Backdoor

PHP - Anomaly:Header, Anomaly:URL - NULL Byte - CVE:CVE-2020-7066

PHP - Code Injection

SQLi - Ending Comment

XSS, HTML Injection

XSS, HTML Injection - Data URI

XSS, HTML Injection - IFrame Tag and Src Attribute

XSS, HTML Injection - Object Tag

Anomaly:Header:Accept - Missing or Empty

Anomaly:Header:Content-Length - Missing in POST

Anomaly:Header:X-Forwarded-Host

Apache JXPath Library - Code Injection - CVE:CVE-2022-41852

Template Injection

Noted -

1. I have left many out (dont apply to me I think)

2. There were also some options such as XSS, HTML Injection that show up more than once but with a different rule id

eg
XSS, HTML Injection
b910aec795a44492b783da68301de41f

XSS, HTML Injection
882b37d6bd5f4bf2a3cdb374d503ded0

As above I was not able to look up what the difference was between these two and nothing to reference 882b37d6bd5f4bf2a3cdb374d503ded0 for example

About my wordpress site.

Standard Blog.
No users
Wordfence
Google News req RSS
No sales or other services
Uses an external backup system
cPanel shared hosting with security meaures and modsec enabled
Does nothing else special

[cbrandt]

@matthew.giannelis

a standard wordpress blog

No such as thing as “standard” when it comes to WordPress (see below).

@matthew.giannelis

if I can/should turn these on. (Block)

If you can: You can enable the mentioned WAF rules that seem relevant to your WordPress blog for added security. However, monitor your site closely for any false positives or unintended blocks. If issues arise, reassess and adjust the rules as needed. Enabling security features, such as WAF and Rate Limiting, can help protect your site from various attacks and vulnerabilities.

If you should: The reason these are not set to block by default is the same reason why we cannot suggest what one should do with their specific website. Each WordPress installation is a forest with different trees. (Think hosting provider tools, server configs, local configs, themes, child themes, plugins, functions.php, wp-config.php etc.) Enable the rules, monitor closely by visiting the Security > Events log (or fetching events via API), and you’ll have to decide for yourself what works and what doesn’t for your installation.

One thing I personally suggest, regardless of WordPress, is that you start by setting the action to Managed Challenge instead of Block. This will minimize the impact on legit visitors when false positives occur.