ModSecurity特定URI精细化白名单配置指南，优化白名单

正文：

在Web应用防火墙（WAF）的日常运维中，ModSecurity的规则灵活性使其成为防御复杂攻击的利器。然而，过度严格的全局规则可能导致误拦截合法流量，尤其是针对API接口或静态资源路径。此时，精细化URI白名单配置便成为平衡安全与可用性的关键。

---

一、为什么需要URI白名单？

1. 避免误杀：如登录接口（/api/login）可能因高频POST请求触发防爆破规则。
2. 性能优化：静态资源（如/static/*）无需SQL注入检测，减少规则匹配开销。
3. 第三方集成：Webhook回调路径（如/webhook/payment）需放行特定来源IP和参数。

---

二、基础白名单配置语法

通过SecRule的@unconditionalMatch或@beginsWith实现基础放行：
apache

# 放行特定URI（完全匹配）  
SecRule REQUEST_URI "@unconditionalMatch ^/healthcheck$" "id:1001,phase:1,pass,nolog"  

# 放行路径前缀（如静态资源）  
SecRule REQUEST_URI "@beginsWith /static/" "id:1002,phase:1,pass,nolog"  

---

三、高级场景：条件化白名单

结合变量检查实现动态放行，例如仅允许/admin路径来自内网IP：
apache

SecRule REQUEST_URI "@streq /admin" "id:1003,phase:1,chain,pass"  
    SecRule REMOTE_ADDR "@ipMatch 192.168.1.0/24" "t:none"  

常见条件组合：
– Method限制：@pmFromFile匹配允许的HTTP方法（GET/POST）。
– Header验证：如放行带有特定User-Agent的请求。

---

四、避坑指南

1. 规则顺序：ModSecurity按规则ID顺序执行，白名单规则应置于拦截规则之前。
2. 正则性能：避免@rx复杂正则，优先使用@streq或@contains。
3. 日志干扰：添加nolog避免无关日志淹没审计系统。

---

五、实战案例：放行GraphQL接口

GraphQL的单一端点（如/graphql）需禁用部分规则：
apache

# 禁用SQL注入检测（仅针对GraphQL）  
SecRule REQUEST_URI "@streq /graphql" "id:1004,phase:2,ctl:ruleRemoveById=942000-942999"  

# 允许JSON内容类型  
SecRule REQUEST_URI "@streq /graphql" "id:1005,phase:1,chain,pass"  
    SecRule REQUEST_HEADERS:Content-Type "@contains application/json"  

---

通过上述方法，可精准构建“安全例外”，既保障核心业务流畅性，又不降低整体防护水位。建议在测试环境验证后逐步灰度上线，观察日志中的ruleId拦截记录进一步调优。