wordpress 站点上用于 ModSecurity 的 Apache LocationMatch 通配符

Question

我在 Ubuntu 14.04 Apache 2.4.7 运行 WordPress 站点上安装了 mod_security。我有一些需要忽略的规则，但我在实施一些通配符规则时遇到了问题，因此我不必指定每一页..

我的（在我的 site.conf 文件中）是...

  <LocationMatch "/wp-admin/post.php">
     SecRuleRemoveById 300016
  </LocationMatch>

  <LocationMatch "/wp-admin/nav-menus.php">
     SecRuleRemoveById 300016
  </LocationMatch>

  <LocationMatch "(/wp-admin/|/wp-login.php)">
     SecRuleRemoveById 950117
     SecRuleRemoveById 950005
     SecRuleRemovebyID 981173
     SecRuleRemovebyId 960024
  </LocationMatch>

    <LocationMatch "/wp-admin/load-scripts.php">
     SecRuleRemoveById 981173
    </LocationMatch>


    <LocationMatch "/wp-admin/plugins.php">
     SecRuleRemoveById 981173
    </LocationMatch>

    <LocationMatch "/wp-admin/customize.php">
     SecRuleRemoveById 981173
    </LocationMatch>

我想要的是将所有内容合并到一个规则中，该规则在 wp-admin 和 wp-login 上使用通配符。

我尝试了以下方法，但似乎被忽略了，因为 mod_security 拒绝了..

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

还有

<LocationMatch "(/wp-admin/*)">
....

还有

<Location "/wp-admin/*">
....

我已经对 LocationMatch 和正则表达式进行了一些研究，但我在这里没有得到任何东西。我想做的事情可行吗？

编辑： modsec_audit.log 中的引用 URL 是 http://www.<site>.com/wp-admin/customize.php?theme=modality

Answer 1

这应该有效：

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

这里不需要通配符，因为您只想检测路径的开头，第二个斜杠后面的内容无关紧要。

对于Location，你需要一个~来触发正则表达式解释：

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

更多详情：

https://httpd.apache.org/docs/2.2/mod/core.html#location（请注意此处关于尾部斜杠的注释）
https://httpd.apache.org/docs/2.2/mod/core.html#locationmatch

Answer 2

虽然 Carsten 的回答是正确的，但应该注意 Location 和 Location 指令运行 after 阶段 1 ModSecurity 规则。但是看起来您的规则无论如何都是第 2 阶段，所以在这种情况下这并不特别重要 - 虽然我无权访问规则 300016，所以不能 100% 确定这一点。

无论如何，出于这个原因，我不喜欢使用 Location 和 LocationMatch，个人更喜欢使用新规则在 ModSecurity 中进行位置过滤，例如：

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

这样我就可以在规则过滤中保持一致（而不是用上面的规则过滤第 1 阶段规则，并通过位置匹配过滤其他规则）。但是，每个阶段都需要一个规则。无论如何，正如我所说，如果所有这些现在都是第 2 阶段或以上规则，那并不重要。

另一个有趣的值得记住的是，如果您使用 SecRuleRemoveById，您需要在之后指定您要删除的规则，而如果您使用 ctl:ruleRemoveById，则需要在要删除的规则之前指定此。

然而，大多数 Wordpress 攻击将针对这些 URL。所以你想非常确定你不需要这些规则。通过转向像这样更通用的例外情况，您正在将每个规则与超出其需要的范围进行匹配。例如，如果从您的原始设置看起来像，/wp-login.php 只需要这些例外中的 4 个，但您将把它们全部移动。

我建议不要放宽规则以匹配更多，而应着眼于保持严格，不要进行此更改。

事实上，您可以进一步收紧它们以仅匹配导致异常需要的某些参数。例如，如果只有用户名字段导致您出现问题，那么您可以将规则收紧为：

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

或其他格式：

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

是的，这可能意味着额外的工作，我知道你来这里是为了巩固你的规则，让这更容易，但如果你最终禁用了一个像 ModSecurity 这样的 WAF，那么运行您旨在防止的许多规则，不幸的是，Wordpress 是许多坏人的活跃目标，部分原因是它的受欢迎程度。

所以，虽然我没有直接回答你的问题，但我希望这对你有用并能给你带来思考。

wordpress 站点上用于 ModSecurity 的 Apache LocationMatch 通配符

Apache LocationMatch wildcard for ModSecurity on wordpress site

regex

wordpress

apache

mod-security