ModSecurity本身不是开箱即用的WAF，仅是规则引擎；真正起防护作用的是OWASP CRS。未安装CRS或SecRuleEngine未设为On、模块未载入、APR版本不匹配、SecResponseBodyAccess未开启，均会导致防护失效。
ModSecurity 本身不是开箱即用的 WAF，它只是规则引擎；真正起防护作用的是 OWASP ModSecurity Core Rule Set（CRS）。没装 CRS，只启用 mod_security 模块等于装了把没子弹的枪。
确认基础运行状态
很多问题卡在模块根本没生效。不能只看 a2enmod security2 是否执行成功，必须验证运行时状态：
- 检查 Apache 配置中是否包含
SecRuleEngine On（默认是Off，必须显式打开） - 用
apache2ctl -M | grep security（Debian/Ubuntu）或httpd -M | grep security（RHEL/CentOS）确认模块已载入 - 查错误日志：
tail -f /var/log/apache2/error.log，若启动时出现ModSecurity: APR compiled version mismatch，说明 mod_security 编译时用的 APR 版本和当前 Apache 不一致，需重编译或换包 -
SecResponseBodyAccess On必须开启，否则 CRS 对响应体的检测（如防敏感信息泄露）完全不触发
确保 CRS 正确加载并阻断攻击
装了 CRS 却拦不住 SQL 注入，常见原因不是规则没匹配，而是没阻断：
Apache 2.4.62
下载
Apache 2.4.62 官方 tar.gz 源码包是 Linux 及类 Unix 系统构建 Web 服务器的核心基础。通过源码编译安装，开发者能够灵活定制模块、优化性能并精准控制安装路径，满足多样化的业务需求。
-
SecRuleEngine设成了DetectionOnly（只记录不拦截），生产环境必须设为On - CRS 的规则集版本太老：检查
crs-setup.conf中SecAction引用的id:900100等基础规则是否加载成功，缺失会导致后续 SQLi 规则（如id:942100）因缺少上下文而跳过 - URI 含非 ASCII 字符或编码绕过：CRS 默认对
%27解码后检测，但若 Apache 的AllowEncodedSlashes Off，请求可能在到达 mod_security 前就被拒，反而看不到拦截日志
平衡防护强度与业务可用性
刚启用 CRS 时误报高是常态，不要直接关规则，优先调参：
- 在虚拟主机配置中加
SecAction "id:900120,phase:1,pass,nolog,tag:'OWASP_CRS',setvar:tx.anomaly_score_threshold=10"，把默认 5 分阈值提到 10，先压低误报 - 对特定路径放行检测：例如
SecRule REQUEST_URI "@beginsWith /api/v2/" "id:1001,phase:1,pass,nolog,ctl:ruleRemoveByTag=OWASP_CRS" - 禁用某条高误报规则比全关 CRS 更安全，比如
SecRuleRemoveById 942100（仅移除 SQL 注入 URI 检测，保留参数体检测）
关键配置项检查清单
以下配置建议写入 /etc/modsecurity/modsecurity.conf 或站点级配置中，缺一不可：
SecRuleEngine OnSecRequestBodyAccess OnSecResponseBodyAccess OnSecResponseBodyMimeType text/plain text/html text/xml-
SecResponseBodyLimit 524288（避免大响应拖慢性能） -
SecAuditLog /var/log/apache2/modsec_audit.log（开启审计日志便于排查） - 确保 CRS 的
crs-setup.conf和rules/目录被Include进主配置
