在 Web 安全的学习路线上，绕过 WAF（Web 应用防火墙）是每一个渗透测试人员和安全研究者都必须面对的课题。而在众多商业和开源 WAF 中，ModSecurity 无疑是“祖师爷”级别的存在。
今天这篇笔记，就来系统梳理一下这段时间对 ModSecurity 的学习心得。了解防御者的底牌，是我们打透防线的第一步。
一、 什么是 ModSecurity？不仅仅是防火墙
提到 WAF，很多人第一反应是一个能够自动拦截攻击的黑盒。但严格来说，ModSecurity 本身只是一个规则引擎。
如果把 WAF 比作一把枪：
- ModSecurity 就是枪械的机械结构（引擎）：它负责拦截 HTTP 请求、解析数据、执行判断逻辑。但如果没有子弹，它什么也拦截不了。
- OWASP CRS 就是子弹（规则集）：全称 OWASP Core Rule Set。这是一套由全球安全专家维护的开源防御规则，定义了什么是 SQL 注入、什么是 XSS、什么是恶意爬虫。
业界极度流行的“ModSecurity + OWASP CRS”组合，才构成了一个真正具备强大杀伤力的 WAF 防线。
二、 它的防护是如何生效的？（核心工作机制）
ModSecurity 的强大之处在于它介入了 HTTP 流量处理的全生命周期。它将对流量的检测分为了 5 个核心阶段（Phases）：
- Phase 1 (Request Headers) - 请求头解析：
在服务器接收到 HTTP 请求的头部时触发。常用于拦截恶意的 User-Agent、非法的 Content-Type，或者直接阻断恶意 IP。 - Phase 2 (Request Body) - 请求体解析：
这是最核心的阶段！POST 提交的表单、上传的文件都在这里被深度解剖。绝大多数针对 SQLi、XSS、RCE 的拦截规则都在这个阶段生效。 - Phase 3 (Response Headers) - 响应头解析：
流量准备返回给客户端时触发。可以用来防止敏感信息泄露，例如自动抹除Server: Apache/x.x这样的指纹信息。 - Phase 4 (Response Body) - 响应体解析：
检查服务器返回的网页内容。如果发现页面被挂马，或者探测到数据库报错信息（如 SQL 语法错误）回显，可以在这里进行拦截或替换，防止攻击者获取有效信息。
但是我就算正向cat /etc/passwd也没见回包检测，不知道什么原因？ - Phase 5 (Logging) - 日志记录：
决定哪些被拦截或放行的请求需要被完整记录到审计日志（Audit Log）中。
日志显示，攻击者不仅试图直接使用纯数字 IP 发起请求（精准触发了 OWASP CRS 的 920350 协议合规拦截规则），甚至还使用 HTTPS 握手包强行试探明文 HTTP 端口。
三、 ModSecurity 的核心特点
作为业界最主流的开源 WAF 之一，也是很多商业 WAF 的底层技术参考，它具备以下几个显著特点：
- 灵活的 SecRule 语法：
它允许安全人员像写代码一样编写精细化的防护策略。语法虽然陡峭，但极其强大。下面是一个简单的规则示例：
# 拦截 URL 参数中带有 "select ... from" 的 SQL 注入请求
SecRule ARGS "(?i)(select.*from)" "id:1001,phase:2,deny,status:403,msg:'SQL Injection Detected'"
