mod_security只是规则引擎,防护依赖OWASP CRS;需确认SecRuleEngine On、模块加载、APR版本匹配及SecResponseBodyAccess开启,否则规则不生效或检测不全。

直接上结论:mod_security 本身不是开箱即用的 WAF,它只是规则引擎;真正起防护作用的是 OWASP ModSecurity Core Rule Set (CRS)。不装 CRS,只启用 mod_security 模块等于装了把没子弹的枪。
怎么确认 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 还拦不住 SQL 注入
常见现象:请求 /login.php?user=admin' OR '1'='1 没被拦截,但日志里有 Matched "rx ..." at REQUEST_URI —— 这说明规则匹配了,但没阻断。原因通常是:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
-
SecRuleEngine设成了DetectionOnly(只记录不拦截),生产环境必须设为On - CRS 的规则集版本太老:
crs-setup.conf中SecAction引用的id:900100等基础规则未加载,导致后续 SQLi 规则(如id:942100)缺少上下文而跳过 - URI 路径含非 ASCII 字符或编码绕过,CRS 默认规则对
%27解码后才检测,但若 Apache 的AllowEncodedSlashes设为Off,请求可能在到达 mod_security 前就被拒了,反而看不到拦截日志
如何最小化误报又不放行真实攻击
刚启用 CRS 时,id:980130(异常检测评分)常把正常 POST 表单当攻击。不要直接关规则,优先调参:
- 在虚拟主机配置中加
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 检测,保留参数体检测) - 注意
SecRequestBodyLimit和SecRequestBodyNoFilesLimit:若表单上传大文件失败,可能是这两个值太小(默认 131072 字节),调大后 CRS 才能完整解析 body
日志怎么看才定位到真实攻击
CRS 日志默认写进 Apache 错误日志,但字段杂乱。关键不是找 “blocked”,而是看 Matched vars 和 Operator:
- 一条典型拦截日志里,
Matched "rx ^[\d\.\:]+$" at ARGS:ip表示规则用正则校验 IP 参数,发现输入含字母,这很可能是扫描器试探 - 若
Message是SQL Injection Attack但Matched vars显示ARGS_NAMES:sort_by,说明攻击藏在排序参数里,不是常见id或q - 用
grep -A 5 -B 2 "id \"942.*\"" /var/log/apache2/modsec_audit.log快速筛出 SQLi 相关审计日志段 - 别忽略
phase:1(请求头)和phase:2(请求体)的日志差异:前者可防 Host 头伪造,后者才管 POST 数据,两者规则不能互相替代
CRS 规则更新频繁,但每次升级都要重新测试白名单和阈值;最易被忽略的是 SecResponseBodyLimit —— 若设得太小(比如默认 524288 字节),JSON 接口返回大数组时,mod_security 截断响应后就无法检测敏感信息泄露规则(如 id:933120 匹配密码字段),结果防护形同虚设。

















