Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

ModSecurity Rules and Alt Languages

Discussion in 'Security' started by UmairSYS, Dec 19, 2017.

Tags:
  1. UmairSYS

    UmairSYS Member

    Joined:
    May 3, 2016
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  2. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    60
    Likes Received:
    25
    Trophy Points:
    18
    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
     
    #2 fuzzylogic, Dec 19, 2017
    Last edited: Dec 19, 2017
    cPanelMichael and rpvw like this.
  3. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    41,396
    Likes Received:
    1,605
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello @UmairSYS,

    The previous response should help. Let us know if you have additional questions.

    Thank you.
     
  4. UmairSYS

    UmairSYS Member

    Joined:
    May 3, 2016
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  5. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    60
    Likes Received:
    25
    Trophy Points:
    18
    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?
     
  6. UmairSYS

    UmairSYS Member

    Joined:
    May 3, 2016
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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?
     
  7. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    60
    Likes Received:
    25
    Trophy Points:
    18
    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
     
  8. UmairSYS

    UmairSYS Member

    Joined:
    May 3, 2016
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  9. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    41,396
    Likes Received:
    1,605
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

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

    OWASP ModSecurity CRS - cPanel Knowledge Base - cPanel Documentation

    EX:

    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.
     
Loading...

Share This Page