ModSecurity Rules and Alt Languages

UmairSYS

Member
May 3, 2016
6
0
1
PK
cPanel Access Level
Root Administrator
Hello,

I am using Standard Mod_sec rules provided via cPanel (OWSAPv3) and after the recent update (I didn't for last few version) all my sites (based on WP) using any language other than English are having issue. I have identified these rules
942100
949110
980130
941160

They seem to think it's an "SQL Injection" attack. While We are simply posing a blog post in Urdu/Hindi Language. I have already reported these rules. Not sure when I will get a reply back.

The rules seems to be important (i.e. stopping SQL injection) but no idea why they were published without proper testing.

I had to disable them for the time being to get things working properly for my clients.
Please let me know if there is any other way to get things working (i.e. make sure we block attacks and not the right content )

I am sure other people who are using any other language will also be having issues due to these rules.

Thanks
 

fuzzylogic

Well-Known Member
Nov 8, 2014
136
78
28
cPanel Access Level
Root Administrator
Firstly do not disable rule 949110. It blocks requests in response to a high score tally from attack rules. (You might as well disable Modsecurity entirely).
Secondly do not disable rule 980130. It is just a logging rule. Without good logs it will be harder to examine modsecurity's reaction to a request.

This exclusion rule, I think, (with such limited information) that would likely fix your issue.
It addresses the 2 scoring rules you listed.
Code:
# WP Alt Language rule
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:5555555,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@rx ^(?:edit|editpost)$" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
       ctl:ruleRemoveTargetById=942100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=942100;ARGS:content,\
       ctl:ruleRemoveTargetById=941160;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941160;ARGS:content"
This rule should be added/removed through the WHM admin
WHM » Security Center » ModSecurity™ Tools » Rules "Add Rule button"

Note just updated the rule to exit faster for GET requests
 
Last edited:

UmairSYS

Member
May 3, 2016
6
0
1
PK
cPanel Access Level
Root Administrator
Hello,

I added the above rule, just changed rule ID to 10001 (as I already has a custom rule with 10000). And still can not post anything from WordPress as the other two rules keep blocking it.

Here is a screenshot if it helps.
http://i68.tinypic.com/2j11w5f.png

If you expand the error, it will only say
Code:
 Request:
POST /wp-admin/post.php
Action Description:
Warning.
Justification:
Operator GE matched 5 at TX:inbound_anomaly_score.
Thanks
 

fuzzylogic

Well-Known Member
Nov 8, 2014
136
78
28
cPanel Access Level
Root Administrator
That request is hitting another rule, an XSS rule beginning with 941xxx.
The rule it is hitting is not within the screenshot you posted.
That rule is adding 5 points to the Inbound Anomaly Score,
then 949110 is blocking it (due to the 5 points)
and 980130 is logging the details.

Is there another hit with the same timestamp with a rule id starting with 941?
 

UmairSYS

Member
May 3, 2016
6
0
1
PK
cPanel Access Level
Root Administrator
Hello,

I found one other rule that is being issue. Its not in 941XX range but it's 921160
It gives 404 with

Code:
 Request:
POST /wp-admin/post.php
Action Description:
Warning.
Justification:
Pattern match "(?:\\n|\\r)+(?:\\s+|location|refresh|(?:set-)?cookie|(X-)?(?:forwarded-(?:for|host|server)|host|via|remote-ip|remote-addr|originating-IP))\\s*:" at ARGS:content.
So I think I need to change the condition to be
Code:
       ctl:ruleRemoveTargetById=942100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=942100;ARGS:content,\
       ctl:ruleRemoveTargetById=921100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=921100;ARGS:content,\
       ctl:ruleRemoveTargetById=941160;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941160;ARGS:content"
Is that okay?
 

fuzzylogic

Well-Known Member
Nov 8, 2014
136
78
28
cPanel Access Level
Root Administrator
I have never had to exclude rule 921160 to be able to save a WordPress post.
Are you sure the request is from a trusted ip (eg. yours) and not a vulnerability scanner.

If you have confirmed it is a true false positive, generated when posting from within the WordPress back end, then the code you posted will work to disable that rule in those limited circumstances.

These requests are being logged as 404 because the host/site to which the request is aimed does not have a 403.shtml in place.
The sequence is...
Modsecurity blocks request
Returns 403 status
Server attempts to serve 403.shtml but it is missing
Returns 404 status
Apache logs 404 as the response status for the request in apache error_log

Likewise if the host/site has a 301 redirect in place for example www to non-www.
a modsecurity blocked request to www will be logged in apache error_log as 301

The most important log to read when preparing to write modsec exclusions is /usr/local/apache/logs/modsec_audit.log
I have written instructions on how to find requests you want in /usr/local/apache/logs/modsec_audit.log using Configserver Firewall
in another post...
ModSec shows security scanner scanning 127.0.0.1

OR if you dont have CFS or prefer to use the command line then find the time stamp of the request in "WHM >> Security Center >> ModSecurity Tools >> Hits"
then use it in the following command...
Code:
grep "23:24:47" -B 2 -A 50 /usr/local/apache/logs/modsec_audit.log
 

UmairSYS

Member
May 3, 2016
6
0
1
PK
cPanel Access Level
Root Administrator
Hello FuzzyLogic,

First of all, really appreciate you taking time to respond here and helping me out.

On the other hand, I have no idea why cPanel even bother to have the option to "Report that hit" when I have never received a single response in last 3 weeks.

This has been a nightmare for me when every other post ends up with an error. Most of the site on the server use Urdu language. But now even English sites are having issue with simple stuff. I user just reported getting error while all he is doing is embedding Google Map using pre built functions in his theme. And the stupid Mod_security is blocking it due to " ModSecurity: Warning. detected XSS using libinjection."

I mean seriously?? V3 was supposed to have less false positives. My experience has been totally opposite.

I currently have 3 custom rules. (Thanks to @fuzzylogic for the help)
Code:
# WP Alt Language rule
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:10001,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@rx ^(?:edit|editpost)$" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
       ctl:ruleRemoveTargetById=942100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=942100;ARGS:content,\
       ctl:ruleRemoveTargetById=941160;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941160;ARGS:content"
Code:
# WP Alt Language rule For Admin
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:10002,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/admin-ajax.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@streq heartbeat" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
    ctl:ruleRemoveTargetByTag=942100;ARGS:data[wp_autosave][post_title],\
    ctl:ruleRemoveTargetByTag=942100;ARGS:data[wp_autosave][content],\
    ctl:ruleRemoveTargetByTag=942360;ARGS:data[wp_autosave][post_title],\
    ctl:ruleRemoveTargetByTag=942360;ARGS:data[wp_autosave][content],\
    ctl:ruleRemoveTargetByTag=941160;ARGS:data[wp_autosave][post_title],\
    ctl:ruleRemoveTargetByTag=941160;ARGS:data[wp_autosave][content]"
Code:
# WP Alt Language rule
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:10003,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@rx ^(?:edit|editpost)$" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
       ctl:ruleRemoveTargetById=921100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=921100;ARGS:content"

I added 10003 separately as I wanted to see which sites are hitting this one.

Now even when having all these 3 rules. all users are reporting random issue. (Getting 403 while posting). Now they are getting it for random posts, not all of them.

50596 is for a site in Urdu language when writer is simply adding an Urdu language post.

50663 is for a site in English when writer is simply embedding Google Map in Contact Us page using the theme function.


I am really tempted to remove cPanel provided rules and try Comodo WAF.
This has been an absolute nightmare for me.

If makes any difference,
I am running Cloudlinux. I also have CSF / CXS / CMC on the server.
This is a CentOS 7 server.

Thanks


Example-001.png Example-002.png
 

cPanelMichael

Technical Support Community Manager
Staff member
Apr 11, 2011
47,911
2,233
363
cPanel Access Level
DataCenter Provider
Twitter
Hello,

We document some of the risks of using the OWASP ruleset at:

OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation

EX:

What are the risks?
As with any mechanism that blocks web traffic, OWASP rules could block legitimate traffic (false positives). While both OWASP and cPanel, Inc. aim to curate the OWASP rule set to reduce the potential for false positives, the rule set may block legitimate traffic. Review the ModSecurity Tools interface (WHM >> Home >> Security Center >> ModSecurity™ Tools ) routinely to evaluate the traffic that the rule set blocks and whether these blocks affect legitimate users.
It's one of the reasons we don't enable this rulset by default. There's some discussion of this at:

Why are modsecurity rules not installed by default?

Reporting the hit is the best way to note the false positive, but manually excluding the rule for a specific account is likely the best approach if it's an ongoing issue. CSF offers a utility to manage rules on a per-account basis if you are interested:

ConfigServer ModSecurity Control (cmc)

Thank you.
 

Metro2

Well-Known Member
May 24, 2006
455
41
178
USA
cPanel Access Level
Root Administrator
Firstly do not disable rule 949110. It blocks requests in response to a high score tally from attack rules. (You might as well disable Modsecurity entirely).
Secondly do not disable rule 980130. It is just a logging rule. Without good logs it will be harder to examine modsecurity's reaction to a request.

This exclusion rule, I think, (with such limited information) that would likely fix your issue.
It addresses the 2 scoring rules you listed.
Code:
# WP Alt Language rule
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:5555555,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@rx ^(?:edit|editpost)$" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
       ctl:ruleRemoveTargetById=942100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=942100;ARGS:content,\
       ctl:ruleRemoveTargetById=941160;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941160;ARGS:content"
This rule should be added/removed through the WHM admin
WHM » Security Center » ModSecurity™ Tools » Rules "Add Rule button"

Note just updated the rule to exit faster for GET requests
I just want to thank you for this extremely helpful post. I've been struggling with customer issues with editing their WordPress for a while, and had resorted to using CSMSC to disable 941160 and 941100 on specific accounts, knowing that was not the best approach but needing to do something.

I had a hard time finding understandable documentation for creating proper exclusion rules until I came across your post, and have slightly modified it to work on the two rules that are affecting my users, as follows:

Code:
# WP Alt Language rule
SecRule REQUEST_METHOD "@streq POST" \
   "msg:'WP Alt Language rule is being hit',\
   id:5555555,\
   phase:2,\
   t:none,\
   log,\
   pass,\
   chain"
   SecRule REQUEST_FILENAME "@endsWith /wp-admin/post.php" \
       "t:none,\
       chain"
   SecRule ARGS:action "@rx ^(?:edit|editpost)$" \
       "t:none,\
       chain"
   SecRule &ARGS:action "@eq 1" \
       "t:none,\
       ctl:ruleRemoveTargetById=941100;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941100;ARGS:content,\
       ctl:ruleRemoveTargetById=941160;ARGS:post_title,\
       ctl:ruleRemoveTargetById=941160;ARGS:content"
I really didn't want to add 941100 because it helps prevent xmlrpc injections, but on my servers 941100 was hand-in-hand with every instance of legitimate user editing their WordPress pages.

It's a bit soon to tell, but it appears there's already a major decrease in the false positives / user WP editing issues.

Thank you!
 
  • Like
Reactions: cPanelMichael

fuzzylogic

Well-Known Member
Nov 8, 2014
136
78
28
cPanel Access Level
Root Administrator
You're welcome.
If you want to view more examples of WordPress specific exclusion rules, the CRS version 3.0.2 on GitHub has a .conf file for WordPress exclusions.
It is an external link so I won't attempt to post it here.
You can search for...
github SpiderLabs OWASP ModSecurity Core Rule Set
The No. 1 result is the correct repository. (to be sure check that it is the SpiderLabs/owasp-modsecurity-crs repository)
On the "Code" tab, which should be the default tab when the page opens, click on the "rules" directory link.
Then click on the REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf link.
Any of the rules in this conf file should function as designed as standalone rules added through...
WHM » Security Center » ModSecurity™ Tools » Add Custom Rule

BUT there is a gotcha.
If you add a rule from that .conf file and use the id No. without change...
THEN cPanel eventually adds these rules to the cPanel CRS then a duplicate rule id error will occur when Apache restarts after the ruleset update.
It may cause the ruleset update to fail, it may cause apache to fail to start, I'm not sure.
I am sure that it will happen in the middle of the night when your not watching though.

So if you use any then renumber them first, and watch for update to cPanel CRS ver 3.1 (I don't expect it any time soon), so you can remove the rules you have added with duplicate function to the crs rules.
 

cPanelMichael

Technical Support Community Manager
Staff member
Apr 11, 2011
47,911
2,233
363
cPanel Access Level
DataCenter Provider
Twitter
Hello @fuzzylogic,

Thank you for taking the time to share this information. Your posts here are always incredibly helpful.

It is an external link so I won't attempt to post it here.
You can search for...
github SpiderLabs OWASP ModSecurity Core Rule Set
The No. 1 result is the correct repository. (to be sure check that it is the SpiderLabs/owasp-modsecurity-crs repository)
On the "Code" tab, which should be the default tab when the page opens, click on the "rules" directory link.
Then click on the REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf link.
Here's the direct URL:

owasp-modsecurity-crs/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf at v3.0/master · SpiderLabs/owasp-modsecurity-crs · GitHub

Feel free to post the direct link in the future. While we generally discourage the use of external links (e.g. somewebhost.tld/how-to-fix-problem), it's acceptable if you are simply attempting to reference code on a website such as GitHub.

Thank you.
 
  • Like
Reactions: Metro2