本文旨在解决modsecurity在处理特定uri和get参数（如uuid）时可能产生的误报问题。通过创建精准的modsecurity排除规则，指导用户如何针对特定的请求文件名和参数，绕过部分安全检查，从而确保应用程序的正常运行，同时维持核心的安全防护。
ModSecurity作为一个强大的Web应用防火墙（WAF），能够有效抵御多种网络攻击。然而，在某些特定的应用场景下，其默认规则可能会对合法的请求产生误报，例如当URL的GET参数包含特殊格式数据（如UUID）时，可能被误识别为恶意注入。为了解决这类问题，ModSecurity提供了灵活的白名单机制，允许我们为特定的URI或参数创建排除规则，以绕过不必要的安全检查。
理解ModSecurity排除规则
ModSecurity的排除规则通过SecRule指令配合ctl:ruleRemoveTargetById动作来实现。这种方式允许我们精确地指定在何种条件下，移除哪些特定规则对哪些特定参数的检查。
一个典型的排除规则结构如下：
SecRule REQUEST_FILENAME "@endsWith /path/to/your/script.php" \
"id:1000001,\
phase:2,\
pass,\
t:none,\
nolog,\
ctl:ruleRemoveTargetById=932130;ARGS:get_param_uuid,\
ctl:ruleRemoveTargetById=941100;ARGS:another_param,\
ctl:ruleRemoveTargetById=932130;ARGS:yet_another_param"下面我们来详细解析这个规则的各个组成部分：
-
SecRule REQUEST_FILENAME "@endsWith /path/to/your/script.php"
-
id:1000001
- 每个ModSecurity规则都必须有一个唯一的ID。这个ID用于内部引用和日志记录。在创建自定义规则时，请确保使用一个不与现有规则冲突的ID（通常建议使用高位数字，例如1000000以上）。
-
phase:2
- ModSecurity的处理流程分为多个阶段（phase）。phase:2表示在请求体处理阶段执行此规则。对于GET参数，通常在phase:2（请求头和URI处理后，请求体处理前）或phase:1（请求头处理阶段）进行。如果涉及POST参数，phase:2是更合适的选择。
-
pass
- 这是一个动作。pass表示如果此规则匹配成功，ModSecurity将继续处理后续规则，而不是立即中断请求。这对于排除规则是必要的，因为我们只是想移除某些检查，而不是完全绕过所有ModSecurity。
-
t:none
- t代表转换函数。t:none表示不对匹配到的数据执行任何转换。
-
nolog
- nolog动作表示此规则被触发时，不生成审计日志。在排除规则中，这通常是可取的，以避免日志文件被大量无关的排除信息填充。如果需要调试或监控排除规则是否按预期工作，可以暂时移除nolog。
-
ctl:ruleRemoveTargetById=RULE_ID;ARGS:PARAMETER_NAME
- 这是排除规则的核心。
- ctl: 控制动作，用于修改ModSecurity的运行时配置。
- ruleRemoveTargetById: 这个指令用于移除特定规则对特定目标（变量）的检查。
- RULE_ID: 这是你希望禁用检查的ModSecurity规则的ID。如何获取这个ID至关重要。当ModSecurity阻止一个请求时，它会在审计日志（通常是audit.log）中记录触发的规则ID。你需要查看这些日志来识别导致误报的具体规则ID。
- ARGS:PARAMETER_NAME: 指定要排除检查的具体GET或POST参数的名称。例如，如果你的URL是script.php?uuid=123-abc-456，那么PARAMETER_NAME就是uuid。ARGS变量会同时匹配GET和POST请求中的参数。
如何识别触发误报的规则ID
要找到需要排除的规则ID，你需要：
- 启用ModSecurity审计日志：确保你的ModSecurity配置中启用了审计日志，例如SecAuditEngine On和SecAuditLog /var/log/httpd/modsec_audit.log。
- 重现误报：尝试访问导致ModSecurity阻止的URI，并观察ModSecurity的阻止页面或HTTP错误码。
-
检查审计日志：查看ModSecurity的审计日志文件（例如/var/log/httpd/modsec_audit.log）。在被阻止的请求条目中，你会找到类似以下内容的行：
--H--9a073e5f-A-- [...其他日志信息...] --Z--9a073e5f-A-- Message: Access denied with code 403 (phase 2). Pattern match "..." at ARGS:uuid. [file "/etc/httpd/modsecurity.d/modsecurity_crs_41_sql_injection_attacks.conf"] [line "123"] [id "932130"] [rev "2"] [msg "SQL Injection Attack: Common SQL Injection Tautology"] [data "Matched Data: ..."] [severity "CRITICAL"] [hostname "your.domain.com"] [uri "/path/to/your/script.php"] [unique_id "9a073e5f-A"]
在[id "932130"]这一行，932130就是你需要添加到ctl:ruleRemoveTargetById中的规则ID。
放置排除规则文件
为了确保你的排除规则在核心规则集（CRS）之前被处理，你应该将其放置在一个适当的配置文件中。对于OWASP CRS，通常建议将这类规则放在以下文件之一：
- REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
- 或者在你的主ModSecurity配置中，通过Include指令确保它在CRS规则之前加载。
例如，在CentOS 7上，你可能需要将文件放置在/etc/httpd/modsecurity.d/目录下，并确保它在modsecurity_crs_10_setup.conf等CRS初始化文件之后、具体规则文件之前被加载。
示例代码
假设你的应用程序在/api/v1/process.php路径下接受一个名为transaction_id的GET参数，该参数可能是UUID格式，并被ModSecurity规则ID 941100和932130误报。你可以创建如下排除规则：
# 文件名: /etc/httpd/modsecurity.d/my_custom_exclusions.conf
# 确保此文件在CRS规则之前被加载
SecRule REQUEST_FILENAME "@endsWith /api/v1/process.php" \
"id:1000002,\
phase:2,\
pass,\
t:none,\
nolog,\
msg:'ModSecurity: Whitelisting transaction_id for /api/v1/process.php',\
ctl:ruleRemoveTargetById=941100;ARGS:transaction_id,\
ctl:ruleRemoveTargetById=932130;ARGS:transaction_id"注意事项与最佳实践
- 最小化排除范围：尽量使你的排除规则尽可能具体。只针对特定的URI和特定的参数进行排除，而不是对整个应用程序或所有参数进行宽泛的排除，以避免不必要的安全风险。
- 唯一ID：确保你自定义的id是唯一的，避免与ModSecurity核心规则集或其他自定义规则冲突。
- 仔细测试：在生产环境中部署排除规则之前，务必在测试环境中进行充分的测试，确保规则按预期工作，并且没有引入新的安全漏洞。
- 日志监控：即使使用了nolog，也建议定期检查ModSecurity的审计日志和错误日志，以确保没有新的误报或遗漏的攻击。
- 理解ctl动作：除了ruleRemoveTargetById，ctl还有其他强大的功能，如ruleRemoveById（移除整个规则，不区分目标）、ruleEngine（控制ModSecurity引擎状态）等。了解它们可以帮助你更灵活地管理ModSecurity。
总结
通过创建针对特定URI和参数的ModSecurity排除规则，可以有效解决因应用程序特定数据格式导致的误报问题。这种方法既能确保应用程序的正常运行，又能维持ModSecurity的核心安全防护。关键在于精准识别触发误报的规则ID，并以最小化的范围应用排除规则，同时不忘严格的测试和监控。
