1

I'm getting tripped by my WHM ModSecurity using OWASP3 rules.

I'd like to create a custom rule to the Rules List in Home>Security Center > ModSecurity Tools>Rules List following these exclusions:

    <locationmatch "/wp-admin/admin-ajax.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

<locationmatch "/wp-admin/page.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

<locationmatch "/wp-admin/post.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

I am unsure of how to frame this using the modsec rules syntax 'SecRule / phase, etc'

Any advice welcomed.

*** UPDATE Here are the triggered items from ModSecurity HitList

921110: HTTP Request Smuggling Attack Request: POST /wp-admin/post.php Action Description: Warning. Justification: Pattern match "(?:get|post|head|options|connect|put|delete|trace|track|patch|propfind|propatch|mkcol|copy|move|lock|unlock)\s+(?:\/|\w)[^\s]*(?:\s+http\/\d|[\r\n])" at ARGS:content.

941100: XSS Attack Detected via libinjection Request: POST /wp-admin/post.php Action Description: Warning. Justification: detected XSS using libinjection.

941160: NoScript XSS InjectionChecker: HTML Injection Request: POST /wp-admin/admin-ajax.php Action Description: Warning. Justification: Pattern match "(?i:(?:<\w[\s\S]*[\s\/]|'"?)(?:on(?:d(?:e(?:vice(?:(?:orienta|mo)tion|proximity|found|light)|livery(?:success|error)|activate)|r(?:ag(?:e(?:n(?:ter|d)|xit)|(?:gestur|leav)e|start|drop|over)|op)|i(?:s(?:c(?:hargingtimechange ..." at ARGS:actions.

Nfable
  • 33
  • 7
  • Did you add those rule exclusions yourself? They're essentially turning off the Core Rule Set for those locations listed. You mentioned that you want to create a custom rule. What do you want it to do? If you can tell us what you're trying to achieve then we can suggest a rule or at least where to start from. – xanadu Jan 12 '22 at 22:41
  • No, I did not add those yet. I thought they may help (found on a blog somewhere) My client and I kept getting 403 / 404 errors updating a page. I have edited my original post with the specific hitlist items. – Nfable Jan 13 '22 at 23:12

1 Answers1

4

Core Rule Set Dev on Duty here. As the list of exclusions you gave comes from someone else's blog post it's probably best to ignore them. They disable some key functionality of the Core Rule Set (the 9xxxxx rules you're using is the OWASP Core Rule Set) so it's best not to apply those rule exclusions unless you're certain you know what you're doing and why those exclusions are required.

The three entries from the "HitList" that you quoted: are you certain those are the result of known good traffic? Are those definitely from when you were trying to update a page and you got 403 errors? If you're sure those are genuine false positives (and not attacks) then let's continue…

False positive #1

  • The rule causing the false positive: 921110
  • The location in question: /wp-admin/post.php
  • The variable causing the false positive: ARGS:content

Applying a rule exclusion means poking a hole in your WAF's security. We want to try and be as specific as possible so that we make only the smallest hole necessary. We just want to let through the transactions that are being blocked in error and nothing more. We don't want to open a large hole and present an opportunity for attackers to get through.

With that in mind, let's try taking the following approach: let's exclude only the variable in question (ARGS:content) and exclude it only from the rule causing the issue (921110) and only for the location we've seen the problem occur at (/wp-admin/post.php).

Putting all that together looks like so:

SecRule REQUEST_URI "@beginsWith /wp-admin/post.php" \
    "id:1000,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=921110;ARGS:content"

False positive #2

  • The rule causing the false positive: 941100
  • The location in question: /wp-admin/post.php
  • The variable causing the false positive: Unknown

We don't know what variable is causing the issue here.

You can simply disable rule 941100 entirely for location /wp-admin/post.php, but that might be overkill (remember the smallest hole possible that we're trying to make?)

You probably want to check your logs again to find out which variable was causing you an issue with rule 941100.

False positive #3

  • The rule causing the false positive: 941160
  • The location in question: /wp-admin/admin-ajax.php
  • The variable causing the false positive: ARGS:actions

Following the same recipe as before:

SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:1010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=941160;ARGS:actions"

More information

For much more information on rule exclusions and tonnes of examples you can use and adapt for yourself, take a look at our excellent documentation here: https://coreruleset.org/docs/concepts/false_positives_tuning/

xanadu
  • 416
  • 2
  • 7
  • Thank you Xanadu for skating in and giving such focused info and solution - much appreciated! – Nfable Jan 17 '22 at 19:34
  • I wanted to mention that these instances seem to be triggered by the Elementor page builder plugin as far as I can discern. Many thanks! – Nfable Jan 17 '22 at 19:53
  • 1
    Updated link to false positive tuning docs: https://coreruleset.org/docs/concepts/false_positives_tuning/ – Kevin Andrews May 19 '23 at 23:20