我需要逐步实现ModSecurity。必须将其配置为仅阻止单一攻击类型(例如SQLi)的攻击,但记录来自其他攻击类型的所有其他攻击。
为便于升级owasp规则,建议避免修改原始owasp规则。理想情况下,我正在寻找一种解决方案,该解决方案将遵循此准则,并且不需要修改原始owasp规则。
目前,我的测试配置仅能完成部分工作。通过此Debian安装的ModSecurity,我从配置中从/usr/share/modsecurity-crs/rules/*.conf中删除了单个规则文件。这样一来,我就可以使用engine = on启用ModSecurity,并且仅启用配置中加载的特定攻击类型的规则集,但不记录其他攻击类型的事件。
答案 0 :(得分:0)
您有几种选择:
1)使用异常评分和OWASP CRS为SQLi规则设置的sql_injection_score
值。
sql_injection_score
超过一定数量时阻止。这可以通过一条额外的规则来实现:
SecRule tx.sql_injection_score "@gt 1”
"id:9999,\
phase:5,\
ctl:ruleEngine=on \
block"
将”@gt 1”
设置为适当的阈值。
OWASP CRS也为其他类别设置了类似的变量。
2)分别加载规则以及前后打开和关闭规则引擎的规则。
在阶段内,规则将按指定的顺序执行。您可以使用它进行如下配置:
SecRuleEngine DetectionOnly
Include rules/other_rules_1.conf
Include rules/other_rules_2.conf
SecAction “id:9000, phase:2, ctl: ctl:ruleEngine=on”
Include rules/sqli_rules.conf
SecAction “id:9001, phase:2, ctl: ctl:ruleEngine=off”
Include rules/other_rules_3.conf
Include rules/other_rules_4.conf
但是,如果一个类别包含多个阶段,则您需要添加多个SecAction-每个使用的阶段都添加一个。
3)通过更改操作以包括打开ruleEngine来激活所需的规则。
这可能有点脆弱,因为它取决于了解特定的规则ID,并且还需要检查每个规则的操作或假设它们都相同。老实说,最好编辑CRS文件。
如果您只想启用一组规则而不是整个类别,那可能是最好的选择。
4)编辑文件,以直接执行上述操作。
如果您知道这将是一个短期选择,并且最终希望无论如何都启用所有规则,那么这不是一个坏选择。准备好后,将文件还原回去。
或者保留原始规则,然后复制规则,为它们提供新的ID,并添加ctl:ruleEngine=on
操作。