本教程详细介绍了如何在modsecurity中为特定uri和get/post参数配置白名单，以解决因核心规则集（crs）误报而阻断合法请求的问题。通过创建自定义排除规则并精确指定要绕过的modsecurity规则id和请求参数，确保web应用程序的正常运行，同时维持其他部分的安全性。
引言
ModSecurity作为一款强大的Web应用防火墙（WAF），通过其核心规则集（CRS）能够有效抵御多种Web攻击。然而，在某些特定的Web应用场景中，ModSecurity的默认规则可能会对合法的请求产生误报（False Positive），例如当应用程序的GET或POST参数包含UUID、长哈希字符串或其他复杂模式时，这些参数可能被CRS误识别为恶意输入，导致请求被阻断。为了解决这一问题，我们需要为这些特定的URI和参数配置精确的白名单排除规则，以便ModSecurity在处理这些请求时绕过特定的安全检查。
理解ModSecurity规则排除机制
ModSecurity的规则排除机制允许管理员在不禁用整个规则集的前提下，针对特定的请求、URI或参数禁用或修改某些规则的行为。这通常通过SecRule指令结合ctl:ruleRemoveTargetById动作来实现。
- SecRule: 定义一个ModSecurity规则。
- REQUEST_FILENAME: 匹配请求的文件路径（URI）。
- @endsWith: 一个运算符，用于匹配字符串的结尾。
- id: 为当前排除规则分配一个唯一的ID，便于管理和调试。
- phase: 指定规则执行的阶段。phase:2通常用于在请求头和请求体解析后，但CRS规则执行前应用。
- pass: 表示如果匹配到此规则，则继续处理后续规则，而不是立即阻断请求。
- nolog: 可选，表示不记录此规则的匹配日志，减少日志噪音。
-
ctl:ruleRemoveTargetById: 这是核心指令，用于从指定的请求目标中移除或禁用一个或多个ModSecurity规则。
- ruleRemoveTargetById=RULE_ID: 指定要禁用的ModSecurity规则的ID。这些ID通常可以在ModSecurity的审计日志中找到，当误报发生时，日志会记录触发的规则ID。
- ARGS:parameter_name: 指定要应用排除规则的GET或POST参数的名称。例如，ARGS:uuid表示仅针对名为uuid的参数禁用指定的规则。
配置特定URI的白名单规则
以下是一个配置ModSecurity白名单的示例，旨在为特定URI下的特定参数绕过ModSecurity的某些检查。
假设您的Web应用程序有一个PHP脚本/api/process_data.php，它接收一个名为uuid的GET参数和一个名为payload的POST参数。由于这些参数的复杂性，它们可能触发ModSecurity的CRS规则ID 941100（常见XSS规则）和932130（常见SQL注入规则）。
您可以创建如下的排除规则：
# ModSecurity 白名单排除规则
# 针对 /api/process_data.php 路径下的特定参数进行规则排除
SecRule REQUEST_FILENAME "@endsWith /api/process_data.php" \
"id:1001,\
phase:2,\
pass,\
nolog,\
ctl:ruleRemoveTargetById=941100;ARGS:uuid,\
ctl:ruleRemoveTargetById=932130;ARGS:payload,\
ctl:ruleRemoveTargetById=920350;ARGS:uuid"规则解析：
- SecRule REQUEST_FILENAME "@endsWith /api/process_data.php": 这条规则将只应用于以/api/process_data.php结尾的请求URI。请根据您的实际文件路径进行替换。
- id:1001: 这是您自定义的排除规则的唯一ID。建议使用一个不与CRS规则冲突的ID范围（例如，从1000开始）。
- phase:2: 表示此规则在ModSecurity的第二阶段（请求头和请求体解析后）执行。这是在CRS规则被评估之前应用排除的最佳阶段。
- pass: 匹配此规则后，ModSecurity将继续处理其他规则，不会立即停止。
- nolog: 禁用此规则的日志记录，以避免生成不必要的日志条目。
- ctl:ruleRemoveTargetById=941100;ARGS:uuid: 这行是关键。它告诉ModSecurity，对于当前请求中名为uuid的参数，移除或禁用ID为941100的规则。
- ctl:ruleRemoveTargetById=932130;ARGS:payload: 类似地，对于名为payload的参数，禁用ID为932130的规则。
- ctl:ruleRemoveTargetById=920350;ARGS:uuid: 示例中还展示了对同一参数禁用不同规则ID的情况。
规则放置与生效
为了确保您的排除规则在ModSecurity核心规则集（CRS）之前被处理，从而达到预期的排除效果，您应该将上述规则放置在一个特定的配置文件中。
在ModSecurity的配置结构中，通常有一个用于放置自定义排除规则的文件，其命名约定通常是REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf。这个文件会在CRS主规则集加载之前被ModSecurity加载和处理。
请将您的自定义排除规则添加到此文件中。如果该文件不存在，您可能需要创建它，并确保它被ModSecurity的主配置文件（通常是modsecurity.conf或crs-setup.conf）通过Include指令引用。
示例文件路径（CentOS 7 + Apache2）：
/etc/httpd/modsecurity.d/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
添加规则后，请务必重启您的Web服务器（例如Apache），以使配置生效：
sudo systemctl restart httpd
注意事项
- 精确性原则：白名单规则应尽可能精确。只排除您确认会产生误报的特定规则ID和特定参数，避免过度放宽安全检查，从而引入潜在的安全风险。
- 查找规则ID：当ModSecurity阻断请求时，相关的规则ID会记录在Apache的错误日志（error_log）或ModSecurity的审计日志（audit_log）中。仔细检查这些日志是确定需要排除的规则ID的关键步骤。
- 参数名称：确保ARGS:parameter_name中的参数名称与您的Web应用程序实际使用的GET/POST参数名称完全一致，包括大小写。
- 测试验证：部署排除规则后，务必对受影响的Web应用程序功能进行充分的测试，确认误报问题已解决，同时也要检查其他功能是否正常，以及ModSecurity是否仍在对其他请求提供保护。
- 安全性考量：每一次规则排除都意味着放弃了一部分ModSecurity提供的保护。在生产环境中实施任何排除规则之前，请务必评估其潜在的安全影响，并确保您的应用程序代码本身对这些被排除的参数进行了严格的输入验证和清理。
- ModSecurity版本：不同版本的ModSecurity和CRS可能在语法或行为上略有差异，请查阅您所使用版本的官方文档。
总结
通过本教程，您应该能够为ModSecurity配置精确的白名单排除规则，以解决特定URI和参数引起的误报问题。这种方法既能确保Web应用程序的正常运行，又能最大程度地维持ModSecurity提供的安全防护。记住，精确识别误报规则ID和参数名称，并进行充分的测试，是成功实施白名单策略的关键。
