ModSecurity 请求处理生命周期

🌐 ModSecurity 请求处理生命周期

[客户端请求]  
     │
     ▼
┌───────────────┐
│ Phase 1       │  → 请求头阶段
│ Request Headers│
│ - 检查 URI / header
│ - 可设置 ctl:ruleEngine / RequestBodyAccess
└───────────────┘
     │
     ▼
┌───────────────┐
│ Phase 2       │  → 请求体阶段
│ Request Body   │
│ - 已经解析 POST body
│ - SQLi/XSS 等规则检查参数
│ - 审计日志也可能记录 body
└───────────────┘
     │
     ▼
┌───────────────┐
│ Phase 3       │  → 响应头阶段
│ Response Headers│
└───────────────┘
     │
     ▼
┌───────────────┐
│ Phase 4       │  → 响应体阶段
│ Response Body │
└───────────────┘
     │
     ▼
┌───────────────┐
│ Phase 5       │  → 日志阶段
│ Logging       │
│ - 写 error.log / audit.log
└───────────────┘
     │
     ▼
[返回客户端]

🔧 ModSecurity 优化手段对比

方法	写法示例	生效阶段	优点	缺点	适用场景
禁用特定规则	ctl:ruleRemoveById=942100	phase:1/2	精确，只关闭某些误报规则	如果是 body 太大，性能问题依然存在	少数规则误报，body 不大
关闭 ruleEngine	ctl:ruleEngine=Off	建议 phase:1	整个引擎都不检查	安全性最低，接口完全裸奔	可信任的内部接口
检测模式	ctl:ruleEngine=DetectionOnly	phase:1	不拦截，只记录日志	仍解析 body → 仍有性能消耗	调试阶段，排查误报
关闭 auditEngine	ctl:auditEngine=Off	phase:1/2	不写审计日志 → 降低 IO 压力	规则依然会跑，CPU 仍高	body 较大但主要问题是磁盘 IO
关闭 RequestBodyAccess	ctl:RequestBodyAccess=Off	必须 phase:1	不解析 body，直接跳过 → 大幅减轻 CPU/内存	规则无法检测 body 攻击	POST 参数特别大但接口可信任
组合关闭	ctl:RequestBodyAccess=Off,ctl:auditEngine=Off	phase:1	不解析 body + 不写日志 → 性能最优	安全性大幅下降	长 POST 内部接口（如 /api/upload、/api/convert）