本文详细介绍了如何在modsecurity中配置排除规则，以允许特定uri及其参数绕过安全检查。当web应用程序的合法请求（如包含uuid的get参数）被modsecurity误报时，通过创建精确的白名单规则，可以有效地解决误报问题，确保应用程序正常运行，同时维持核心安全防护。
ModSecurity误报场景及排除规则的必要性
ModSecurity作为一款强大的Web应用防火墙（WAF），通过一系列规则集（如OWASP CRS）来检测和阻止恶意请求。然而，在某些特定场景下，合法的请求模式可能与ModSecurity的某些安全规则相冲突，导致“误报”（False Positive）。例如，当Web应用程序的GET或POST参数中包含UUID、Base64编码字符串或其他特殊格式数据时，这些数据可能会被ModSecurity误判为SQL注入、XSS攻击或其他恶意模式。为了解决这类问题，同时又不完全禁用ModSecurity或降低整体安全级别，我们需要为这些特定的URI路径或参数配置精确的排除规则（Whitelisting）。
配置ModSecurity排除规则
配置排除规则的核心是使用SecRule指令结合ctl:ruleRemoveTargetById动作，指定要绕过的URI和需要忽略的特定规则ID及其目标参数。
1. 识别目标URI和参数
首先，确定哪些URI路径和哪些GET/POST参数会触发ModSecurity的误报。例如，如果 /dir/script.php 接收一个名为 uuid_param 的GET参数，并且该参数的UUID值导致误报，那么 /dir/script.php 就是目标URI，uuid_param 就是目标参数。
2. 定位触发规则ID
当ModSecurity阻止请求时，通常会在错误日志（如Apache的error.log）中记录触发的ModSecurity规则ID。这些ID通常以id:XXXXXX的形式出现。仔细检查日志，找出与误报请求相关的规则ID。例如，932130 和 941100 是OWASP CRS中常见的SQL注入和XSS规则ID。
3. 创建排除规则
使用SecRule指令创建一个新的排除规则。以下是一个典型的排除规则示例：
SecRule REQUEST_FILENAME "@endsWith /dir/script.php" \
"id:1000,\
phase:2,\
pass,\
t:none,\
nolog,\
ctl:ruleRemoveTargetById=932130;ARGS:uuid_param,\
ctl:ruleRemoveTargetById=941100;ARGS:uuid_param,\
ctl:ruleRemoveTargetById=932130;ARGS:another_param"让我们详细解析这条规则的各个部分：
-
SecRule REQUEST_FILENAME "@endsWith /dir/script.php":
- REQUEST_FILENAME: 匹配请求的文件路径（不包含查询字符串）。
- @endsWith: 匹配操作符，表示请求的文件路径以 /dir/script.php 结尾。你可以根据实际情况选择其他匹配操作符，例如 @streq（字符串完全相等）、@contains（包含子字符串）等，以确保规则只应用于精确的目标URI。
- id:1000: 为这条排除规则指定一个唯一的ID。建议使用一个在你自定义规则范围内不会冲突的ID（例如，从1000开始递增）。
- phase:2: 指定规则的执行阶段。phase:2表示在请求头和请求体解析完成后执行，这是处理GET/POST参数的常用阶段。
- pass: 如果此规则匹配，则继续处理请求，不立即阻止。这允许后续的ctl动作生效。
- t:none: 不对规则的目标（即REQUEST_FILENAME）应用任何转换函数。
- nolog: 不为此条规则的匹配记录日志。通常排除规则本身不需要详细日志。
-
ctl:ruleRemoveTargetById=932130;ARGS:uuid_param: 这是核心的排除动作。
- ctl:ruleRemoveTargetById: 指示ModSecurity在后续处理中，针对特定的规则ID，忽略特定的目标。
- 932130: 需要被忽略的ModSecurity规则的ID。
- ARGS:uuid_param: 指定该规则ID仅对名为uuid_param的GET/POST参数生效。这意味着其他参数仍将受到规则932130的检查。
- ctl:ruleRemoveTargetById=941100;ARGS:uuid_param: 类似的，为规则941100也排除uuid_param参数。
- ctl:ruleRemoveTargetById=932130;ARGS:another_param: 如果有多个参数需要排除，或者同一个参数需要排除多个规则ID，可以链式添加多个ctl指令。
4. 规则文件位置
将上述排除规则放置在一个ModSecurity配置文件中，该文件必须在主要的OWASP CRS规则集之前加载。通常，ModSecurity配置中会有一个专门用于自定义规则的文件，例如 REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf。确保你的Web服务器（如Apache）在加载ModSecurity主配置时，优先加载包含这些排除规则的文件。
例如，在Apache的ModSecurity配置中，可能看起来像这样：
# Load your custom exclusion rules first IncludeOptional conf.d/modsecurity_custom_exclusions.conf # Then load the main CRS rules IncludeOptional conf.d/modsecurity_crs_10_setup.conf IncludeOptional conf.d/modsecurity_crs_REQUEST-9XX-XX-XX.conf # ... and so on for other CRS rule files
将你的排除规则放在 modsecurity_custom_exclusions.conf 文件中。
注意事项与最佳实践
- 精确性至关重要：尽量使排除规则尽可能精确。避免过于宽泛的规则，例如排除整个URI的所有参数，除非你完全信任该URI的所有输入。过于宽泛的排除会显著降低ModSecurity的保护效果。
- 最小化排除范围：只排除那些确实引发误报的特定规则ID和参数组合。
- 测试与监控：在生产环境中应用排除规则之前，务必在测试环境中进行充分的测试。部署后，持续监控ModSecurity日志和Web服务器日志，确保排除规则按预期工作，并且没有引入新的安全漏洞或导致其他问题。
- 理解风险：每当你创建一个排除规则时，实际上是在某个特定点上降低了安全防护。确保你理解这种权衡，并且排除的必要性大于其潜在风险。
- 文档化：清晰地记录你创建的每一个排除规则，包括其目的、排除的规则ID、目标URI和参数，以及创建日期和负责人。
总结
通过为ModSecurity配置精确的排除规则，我们可以有效地解决特定URI和参数导致的误报问题，确保Web应用程序的正常运行，同时维持ModSecurity作为WAF的核心安全防护能力。关键在于准确识别误报源、定位触发规则ID，并以最小化风险的方式创建和部署排除规则。始终记住，安全配置是一个持续优化的过程，需要细致的测试和持续的监控。
