ModSecurity误拦截处理方法（ModSecurity白名单）

本文主要介绍当一个正常访问被ModSecurity误拦截时的处理方法。

本文中涉及的规则均已在景安网络（http://www.zzidc.com）的20万个虚拟主机业务中正常运行（或测试通过），可正常使用。

一、查询触发拦截的规则

如果访问触发ModSecurity的规则，ModSecurity会在WEB服务器的错误日志文件中进行相关记录。常见的ModSecurity日志有以下两种：

警告日志：

[Fri Nov 22 14:57:03.347755 2019] [:error] [pid 31155:tid 139776509122304] [client 116.255.132.12:43216] [client 116.255.132.12] ModSecurity: Warning. Pattern match "^[\\\\d.:]+$" at REQUEST_HEADERS:Host. [file "/usr/local/apache/conf/modsecurity/rules/base/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "696"] [id "920350"] [msg "Host header is a numeric IP address"] [data "49.233.80.239"] [severity "WARNING"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "49.233.80.239"] [uri "/"] [unique_id "XdeGv-A9Epb@DhWb6sUlUgAAAMM"]

上述日志表示，由于是通过IP地址来访问服务器内网站，因此触发了/usr/local/apache/conf/modsecurity/rules/base/REQUEST-920-PROTOCOL-ENFORCEMENT.conf文件中ID编号为920350的规则。警告日志只会在错误日志中进行记录，不会对访问进行任何拦截操作。

拦截日志：

[Fri Nov 22 15:03:34.634534 2019] [:error] [pid 31155:tid 139776380348160] [client 116.255.132.12:41216] [client 116.255.132.12] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/usr/local/apache/conf/modsecurity/rules/base/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 18)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "49.233.80.239"] [uri "/"] [unique_id "XdeIRvA9Epb@DhWb6sUlVgAAAMo"]

上述日志表示，此次访问被认定为存在攻击行为，因此触发了/usr/local/apache/conf/modsecurity/rules/base/REQUEST-949-BLOCKING-EVALUATION.conf文件中ID编号为949110的规则，同时根据ModSecurity的配置，将此次访问拦截并向客户端返回403状态码。

查询到触发拦截的规则后，我们便可以通过禁用规则（全局），或禁用规则（白名单）的方式来避免再次进行误拦截的情况发生。

二、禁用规则（全局）

#禁用ID为942100的规则
SecRuleRemoveById 942100

#禁用ID为942100、942100的两条规则
SecRuleRemoveById 942100 942101

#禁用ID在941000-942000区间（包含前后ID）的所有规则
SecRuleRemoveById 941000-942000

#禁用ID为942100、942100,以及ID在941000-942000区间（包含前后ID）的所有规则
SecRuleRemoveById 942100 942101 "941000-942000"

#禁用Tag属性含有"attack-injection-php"的所有规则
SecRuleRemoveByTag "attack-injection-php"

通过以上任意一种方式将在全局范围内对指定的规则进行禁用，即规则彻底失效，被指定禁用的规则将不会对任何访问进行匹配校验。

三、禁用规则（白名单）

以下为几种较为常见的禁用规则（白名单）方式：

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" "id:1000,phase:1,pass,nolog,ctl:ruleEngine=Off"

上述规则表示，当请求的发起IP地址是192.168.1.100时，用ctl临时修改ModSecurity配置，将ruleEngine设置为Off，即，将192.168.1.100设置为白名单，只要是该IP发起的访问均不进行任何规则的匹配校验，其他IP的访问则依然会进行匹配校验。

SecRule REQUEST_URI "@beginsWith /index.php" "id:1001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"

上述规则表示，当被访问的URL为/index.php开头时，通过使用ctl:ruleRemoveById，取消ID编号为942100的规则匹配校验，即ID编号为942100的规则在此次访问中将不会执行，其他规则依然会进行匹配校验。

SecRule REQUEST_URI "@beginsWith /index.php" "id:1002,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:password"

上述规则表示，当被访问的URL为/index.php开头时，选择性的只针对password参数取消ID编号为942100的规则匹配，该次请求的其他参数依旧会被该规则进行匹配校验。

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1003,phase:2,pass,nolog,ctl:ruleRemoveById=941000-942999"

上述规则表示，当被访问的URL为/admin开头时，取消ID在941000-942999区间（包含前后ID）的规则匹配，其他规则依然会进行匹配。

SecRule REQUEST_FILENAME "@endsWith /wp-login.php" "id:1004,phase:2,pass,nolog,ctl:ruleRemoveByTag=attack-sqli"

上述规则表示，当被访问的URL为/wp-login.php结尾时，取消所有tag属性包含"attack-sqli"的规则的匹配校验，其他规则依然会进行匹配校验。

四、其他补充

1. 通过全局方式禁用规则，指令需加载在RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf文件中，也可创建自定义规则文件，但需先加载ModSecurity核心规则文件，再加载自定义规则文件。

2. 通过白名单方式禁用规则，指令需加载在REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf文件中，也可创建自定义规则文件，但需先加载自定义规则文件，再加载ModSecurity核心规则文件。

3. 以Apache为例，httpd.conf中的完整加载顺序如下：

<IfModule security2_module>
Include conf/modsecurity/modsecurity.conf
Include conf/modsecurity/crs-setup.conf

#Include 自定义白名单规则文件在此处加载
#Include conf/modsecurity/rules/whitelist.conf

#ModSecurity核心规则文件
Include conf/modsecurity/rules/base/*.conf

#Include 自定义全局禁用规则文件在此处加载
#Include conf/modsecurity/rules/disablerule.conf
</IfModule>

4. REQUEST_FILENAME与REQUEST_URI虽然都表示对访问的URL进行匹配，但略有不同，REQUEST_FILENAME代表不包含GET请求参数的URL地址，如完整的URL为"/admin/index.php?username=admin&password=123456"，REQUEST_URI代表"/admin/index.php?username=admin&password=123456"，REQUEST_FILENAME仅代表"/admin/index.php"。

5. 请注意ruleRemoveById与ruleRemoveTargetById的不同，两者虽然都需要配置规则ID，但意义不同，ruleRemoveById代表指定的规则在当前访问中不生效，ruleRemoveTargetById代表指定的规则对当前访问中指定的参数不生效，ruleRemoveTargetById除了需要配置规则ID外，也要配置不需要进行检测的参数，否则对应的网站链接将无法访问，谷歌浏览器会显示服务器“未发送任何数据”，其他类似的指令，如ruleRemoveByTag与ruleRemoveTargetByTag，ruleRemoveByMsg与ruleRemoveTargetByMsg在使用时也需注意上述情况。

6.新添加规则，或规则变更后，需要将配置文件重新加载，如Apache为：apachectl graceful、Nginx为：nginx -s reload，规则才可生效。