我刚刚在服务器上设置了 Apache modsecurity，原则上它运行良好，但我得到了相当多的误报。
我正在使用 OWASP ModSecurity 核心规则集 (CRS)，基本上是“开箱即用”。
我在“自包含”（传统）模式而不是协作（异常）模式下运行：
SecDefaultAction "phase:1,deny,log"
SecDefaultAction "phase:2,deny,log"
特别值得关注的是 SQL 注入集。双管道 (||) 双尖括号 (>>) 和一大堆其他输入将触发规则并导致页面被阻止。其中许多很容易出现在合法的用户输入中。
是否有一种优雅的方式来选择性地允许不一定表示注入攻击的常见输入？我知道我目前已经用完了，但是对于几乎每个用例来说，阻止双管道和尖括号肯定会过于严格吗？
【问题讨论】：
标签： mod-security
Kully 有一些优点，我也绝对推荐ModSecurity Handbook。我会说切换到异常模式确实需要一些时间来适应，并且在我看来需要额外的监控工作，所以我个人更喜欢在阻塞模式下运行并关闭嘈杂的规则。
您确实需要在 DetectionOnly 模式下运行并在 CRS 规则变得有用之前对其进行调整，这确实需要时间。经过几个月的迭代，我才感到足够舒服，可以将其切换到阻塞模式。
尤其是 SQL 注入规则很容易出现过度警报。
以下是您可能希望关闭或调整的一些 CRS v2 通用规则 - 特别是在传统警报模式下：
#Lots of browsers don't send accept header so disable rule 960015 which blocks that:
SecRuleRemoveById 960015
#ModSecurity does not handle gzip files and falsely alerts code leakage for such binary files so disable this rule
SecRuleRemoveById 970903
#Range header is set by some Android devices so ignore that rule
SecRuleRemoveById 958291
#We allow Google Tag Manager which uses small iframe so disable the rules that disallow small iframes:
SecRuleRemoveById 981000
SecRuleRemoveById 981001
#These produce many false positives as checking for things like lots of spaces and ' characters (valid in names and addresses). So disable.
SecRuleRemoveById 950109
SecRuleRemoveById 950901
SecRuleRemoveById 960024
SecRuleRemoveById 973338
SecRuleRemoveById 981172
SecRuleRemoveById 981173
SecRuleRemoveById 981231
SecRuleRemoveById 981242
SecRuleRemoveById 981243
SecRuleRemoveById 981245
SecRuleRemoveById 981246
SecRuleRemoveById 981248
SecRuleRemoveById 981257
SecRuleRemoveById 981260
SecRuleRemoveById 981318
SecRuleRemoveById 981319
SecRuleRemoveById 981320
#Allow Search argument (q) to include SQL words:
SecRuleUpdateTargetById 959071 !ARGS:'q'
SecRuleUpdateTargetById 959072 !ARGS:'q'
SecRuleUpdateTargetById 981247 !ARGS:'q'
#Passwords can (and arguable should!) contain special chars
SecRuleUpdateTargetById 950010 !ARGS:'/[pP](ass)?word/'
SecRuleUpdateTargetById 981240 !ARGS:'/[pP](ass)?word/'
#Email address can contain some SQL injection phrases
SecRuleUpdateTargetById 981241 !ARGS:'/[eE](-)?mail/'
#Remove checking of rules which checks for http calls in arguments will have URLs in them
SecRuleUpdateTargetById 950007 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 950120 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 973304 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 981241 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 981256 !ARGS:'utm_referrer'
CRS v3 进行了规则 id 重新编号，并删除了一些规则，因此上面的 v3 等效项如下：
#Lots of browsers don't send accept header so disable rule 920300 which blocks that:
SecRuleRemoveById 920300
#These produce many false positives as checking for things like lots of spaces and ' characters (valid in names and addresses). So disable.
SecRuleRemoveById 920230
SecRuleRemoveById 942130
SecRuleRemoveById 942460
SecRuleRemoveById 941140
SecRuleRemoveById 942420
SecRuleRemoveById 942430
SecRuleRemoveById 942440
SecRuleRemoveById 942330
SecRuleRemoveById 942370
SecRuleRemoveById 942260
SecRuleRemoveById 942340
SecRuleRemoveById 942210
SecRuleRemoveById 942200
SecRuleRemoveById 942450
SecRuleRemoveById 942110
SecRuleRemoveById 942120
SecRuleRemoveById 942140
#Allow Search argument (q) to include SQL words:
SecRuleUpdateTargetById 942390 !ARGS:'q'
SecRuleUpdateTargetById 942400 !ARGS:'q'
SecRuleUpdateTargetById 942360 !ARGS:'q'
#Passwords can (and arguable should!) contain special chars
SecRuleUpdateTargetById 942300 !ARGS:'/[pP](ass)?word/'
#Email address can contain some SQL injection phrases
SecRuleUpdateTargetById 942230 !ARGS:'/[eE](-)?mail/'
#Remove checking of rules which checks for http calls in arguments will have URLs in them
SecRuleUpdateTargetById 931130 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 942230 !ARGS:'utm_referrer'
SecRuleUpdateTargetById 942250 !ARGS:'utm_referrer'
当然，完全关闭这些规则（就像我在上面代码 sn-p 的前半部分所做的那样）会降低 ModSecurity 的有效性，因此您需要确定这是否适合您的网站。
关闭特定参数的规则（就像我在上面代码 sn-p 的后半部分所做的那样）通常是首选，但同样只有您可以决定这些参数是否不需要规则提供的保护。
【讨论】：
首先要做的是切换到异常评分，而不是将默认操作设置为拒绝，这将真正减少你得到的错误 +ves 的数量。
其次，切换到 DetectionOnly 模式并让它运行几天，您就会知道要解决什么问题。 对于每个误报，请考虑：
Ivan Ristic ModSecurity 这本书现在有点上头，但它是真正了解并为它背后的应用程序定制 modsec 的最佳资源，不幸的是它有一个废话索引，所以我推荐你可以搜索的电子版本. 很遗憾，modsec中有很多隐藏的技巧，您必须通过查看源代码，偶然发现书中的一个小文本框或将调试级别设置为5并查看来一一找到modsec 实际上在做什么。
?
【讨论】：
这是我们从下方 (https://stackoverflow.com/a/34027786/1008215) 用于我们的 wordpress modsec 配置的内容。
SecRuleRemoveById 950109
SecRuleRemoveById 950120
SecRuleRemoveById 950901
SecRuleRemoveById 960008
SecRuleRemoveById 960015
SecRuleRemoveById 973338
SecRuleRemoveById 981242
SecRuleRemoveById 981243
SecRuleRemoveById 981245
SecRuleRemoveById 981246
SecRuleRemoveById 981248
SecRuleRemoveById 981257
SecRuleRemoveById 981319
SecRuleRemoveById 981320
【讨论】：