Apache LocationMatch wildcard for ModSecurity on wordpress site

2 comments

1. While Carsten’s answer is correct, it should be noted that Location and Location directives run after phase 1 ModSecurity rules. However it looks like your rules are all phase 2 anyway, so this doesn’t particularly matter in this case – though I don’t have access to rule 300016 so couldn’t be 100% sure about that.

   Anyway for this reason I don’t like using Location and LocationMatch and personally prefer to do Location filtering within ModSecurity with a new rule such as this:

   SecRule REQUEST_URI "@beginsWith /wp-(admin|login)/" 
      "phase:2,id:1000,nolog,pass,ctl:ruleRemoveById=300016,
      ctl:ruleRemoveById=950117,
      ctl:ruleRemoveById=950005
      ...etc.
   

   That way I can be consistent in rule filtering (rather than have phase 1 rules filtered with a rule like above, and other rules filtered by location matching). You will however need one rule for each phase. Anyway, as I say, that doesn’t really matter if all of these are phase 2 or above rules for now.

   Another funny worth remembering is that, if you use SecRuleRemoveById you need to specify this after the rule you are removing, whereas if you use ctl:ruleRemoveById you need to specify this before the rule you are removing.

   However most WordPress attacks will be against these very URLs. So you want to be very sure that you don’t need these rules. And by moving to a more generic exceptions like this, you are matching each rule against more than it needs to. For example if looks like from your original set up, /wp-login.php only needs 4 of these exceptions but you will move it having them all.

   I would suggest that instead of loosening the rules to match more, you should aim to keep them tight and not make this change.

   In fact you could tighten them further to only match certain arguments that are causing the need for the exception. For example if only the username field is causing you issues then you could tighten the rules to this:

   <LocationMatch "(/wp-admin/|/wp-login.php)">
        SecRuleUpdateTargetById 950117 !ARGS:'username'
        SecRuleUpdateTargetById 950005 !ARGS:'username'
        SecRuleUpdateTargetById 981173 !ARGS:'username'
        SecRuleUpdateTargetById 960024 !ARGS:'username'
   </LocationMatch>
   

   or in the other format to this:

   SecRule REQUEST_URI "@beginsWith /wp-(admin|login)/" 
     "phase:2,id:1000,nolog,pass,
     ctl:ruleRemoveTargetById=950117;ARGS:username,
     ctl:ruleRemoveTargetById=950005;ARGS:username,
     ctl:ruleRemoveTargetById=981173;ARGS:username,
     ctl:ruleRemoveTargetById=960024;ARGS:username
   

   Yes this may mean extra work, and I know you came here looking to consolidate your rules to make this easer, but there is little point in running a WAF like ModSecurity if you end up disabling a lot of the rules that you are aiming to protect against and, unfortunately, WordPress is an active target for a lot of bad people due in part to it’s popularity.

   So, while I didn’t directly answer your question, I hope that’s useful and gives you food for thought.

2. This should work:

   <LocationMatch "/wp-(admin|login)/">
   

   You don’t need a wildcard here, because you just want to detect the beginning of the path and it doesn’t matter, what comes after the 2nd slash.

   For Location, you need a ~ to trigger the regex interpretation:

   <Location ~ "/wp-(admin|login)/">
   

   More details:

   • https://httpd.apache.org/docs/2.2/mod/core.html#location (please note the comments about trailing slashes there)
   • https://httpd.apache.org/docs/2.2/mod/core.html#locationmatch

Comments are closed.