首页 应用实战正文

ModSecurity误拦截处理方法(ModSecurity白名单)

王子 应用实战 2019-11-22 17079 0

本文主要介绍当一个正常访问被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,规则才可生效。

版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。