⚠️ 合规声明
本文内容仅用于 Web 应用防火墙（WAF）的合规部署、安全加固、规则调优与攻防学习。部署与测试须在自有或授权环境进行，禁止对未授权系统实施攻击流量验证。一切违规行为由操作者自行承担。本文不含绕过 WAF 的攻击载荷。

前言

ModSecurity 是 Web 安全圈最知名的开源 Web 应用防火墙引擎，配合 OWASP 核心规则集（CRS），能对 SQL 注入、XSS、文件上传、路径遍历、命令注入、恶意机器人等攻击流量做实时拦截。它本身不是威胁情报库，而是一套可编程、可定制、可插拔的请求过滤引擎，这也意味着：规则怎么写、防护强度调多高、误报怎么治，直接决定了它的实战效果。

很多团队把 ModSecurity + CRS 装上，默认全开，结果要么拦不住真实攻击，要么把正常业务大面积误伤，最后干脆关掉，形同虚设。问题不在引擎本身，而在没有吃透规则集结构、没有按业务调 Paranoia 等级、不会写自定义规则、不会治理误报。

本文围绕四条主线展开：第一，CRS 规则集的目录结构、规则编号体系与核心检测类别；第二，Paranoia 等级机制与逐级调整方法；第三，从零编写 ModSecurity 自定义规则，覆盖变量、运算符、动作、响应阶段；第四，完整的误报治理流程，含日志分析、排除规则、动态忽略、限速降噪。全文面向实战，给出可直接落地的配置与规则示例。

一、认识 ModSecurity 引擎与运行机制

1.1 ModSecurity 是什么

ModSecurity 是一款开源、跨平台的 Web 应用防火墙引擎，可作为 Apache、Nginx、IIS 的模块运行，也支持独立部署。它位于 Web 服务器与后端应用之间，对每个请求在多个处理阶段做检测，命中规则则执行对应动作（拦截、记录、放行）。

它的检测能力来自规则。规则定义 “什么样的请求是危险的”，引擎负责逐条匹配。规则可以处理请求行、请求头、请求体、响应头、响应体等不同数据，覆盖整条 HTTP 交互链路。

1.2 五个核心处理阶段

ModSecurity 把请求处理拆成五个阶段，规则可以挂在任一段：

1. 请求头阶段（Request Headers）：检测请求头、方法、URI、协议；
2. 请求体阶段（Request Body）：检测 POST 体、表单参数、JSON/XML；
3. 响应头阶段（Response Headers）：检测响应头；
4. 响应体阶段（Response Body）：检测响应内容（可发现敏感信息泄露、webshell 输出）；
5. 日志阶段（Logging）：记录命中情况，不改变处理结果。

规则通常在越早阶段命中越好，命中即短路，不再继续检测后续阶段。

1.3 规则动作体系

每条规则命中后执行的动作由动作列表决定，常用动作：

• block：拦截请求，返回阻断页面；
• deny：拒绝并结束连接；
• drop：静默丢弃连接（不返回响应，更适合防御扫描器）；
• pass：放行但继续记录；
• log：仅记录，不阻断；
• phase:1~5：指定规则所在阶段；
• id：规则唯一编号；
• msg：命中时的说明信息；
• tag：给规则打标签，便于统计分类；
• severity：风险等级（EMERGENCY、ALERT、CRITICAL、ERROR、WARNING、NOTICE）；
• ctl：运行时动态控制后续规则行为（如动态放行）。

二、CRS 核心规则集详解

CRS（Core Rule Set）是 OWASP 官方维护的规则集，是 ModSecurity 的默认攻击检测库。理解 CRS 的结构是调优的前提。

2.1 CRS 目录结构

标准安装后 CRS 目录内包含：

crs-setup.conf          # 全局配置、Paranoia 等级、排除项等
rules/                  # 核心规则文件
  REQUEST-901-INITIALIZATION.conf
  REQUEST-903.9001-DROPPED.conf
  REQUEST-905-COMMON-EXCEPTIONS.conf
  REQUEST-910-IP-REPUTATION.conf
  REQUEST-911-METHOD-ENFORCEMENT.conf
  REQUEST-913-SCANNER-DETECTION.conf
  REQUEST-920-PROTOCOL-ENFORCEMENT.conf
  REQUEST-921-PROTOCOL-ATTACK.conf
  REQUEST-930-APPLICATION-ATTACK-LFI.conf
  REQUEST-931-APPLICATION-ATTACK-RFI.conf
  REQUEST-932-APPLICATION-ATTACK-RCE.conf
  REQUEST-933-APPLICATION-ATTACK-PHP.conf
  REQUEST-941-APPLICATION-ATTACK-XSS.conf
  REQUEST-942-APPLICATION-ATTACK-SQLI.conf
  REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
  REQUEST-949-BLOCKING-EVALUATION.conf
  RESPONSE-950-DATA-LEAKAGES.conf
  RESPONSE-951-DATA-LEAKAGES-SQL.conf
  RESPONSE-952-DATA-LEAKAGES-JAVA.conf
  RESPONSE-959-BLOCKING-EVALUATION.conf
  RESPONSE-980-CORRELATION.conf

编号体系非常清晰：901~905 是初始化与例外，910~949 是请求攻击检测，950~980 是响应与关联检测。

2.2 核心检测类别与对应规则文件

协议强制与通用攻击

• 920：协议强制、RFC 合规、HTTP 参数滥用、Content-Type 校验；
• 921：HTTP 协议攻击（分块传输、参数污染）；
• 911：HTTP 方法白名单；
• 913：扫描器 / 恶意爬虫检测。

应用攻击检测（重点）

• 930：本地文件包含（LFI）；
• 931：远程文件包含（RFI）；
• 932：远程命令执行（RCE）；
• 933：PHP 注入 / 代码执行；
• 941：跨站脚本（XSS）；
• 942：SQL 注入（含大量细分规则）；
• 943：会话固定攻击。

响应侧检测

• 950/951/952：敏感信息泄露、SQL 报错、Java 异常回显；
• 980：关联分析（把多个低危命中聚合成一次高可信事件）。

2.3 规则触发判定与异常分数

CRS 采用**异常评分（Anomaly Score）**机制，而非 “命中即拦截”：

• 每条规则命中时按严重级别累加异常分；
• 请求处理完，如果总分超过 tx.inbound_anomaly_score_threshold，则判定为攻击并触发 block；
• 同理有出站异常分阈值。

这套机制的意义：允许低危特征累计，减少单规则误杀，把 “多特征叠加” 识别为真实攻击。

2.4 关键变量（tx.*）

CRS 把大量配置放在 tx.* 集合变量里，在 crs-setup.conf 中调整，常用：

• tx.allowed_request_content_type：允许的 Content-Type 白名单；
• tx.allowed_http_methods：允许的请求方法；
• tx.inbound_anomaly_score_threshold：入站异常分阈值；
• tx.outbound_anomaly_score_threshold：出站异常分阈值；
• tx.crs_setup_paranoia_level：Paranoia 等级。

三、Paranoia 等级机制与调整

Paranoia 是 CRS 最核心的调优概念，直接决定防护强度与误报率。

3.1 什么是 Paranoia

CRS 把规则按攻击确定性分成若干等级。等级越低，规则越保守、只拦截高可信攻击、误报少；等级越高，规则越激进、能拦截更多变形攻击，但误报率随之上升。Paranoia 等级从 1 到 4 逐级增强。

3.2 各等级含义

• Paranoia 1（PL1）：默认等级，只启用高可信、低误报的核心规则，适合大多数生产环境；
• Paranoia 2（PL2）：增加中等可信规则，拦截更多变体，误报略升；
• Paranoia 3（PL3）：启用较多启发式规则，能拦更多混淆攻击，误报明显上升；
• Paranoia 4（PL4）：启用全部规则，覆盖最全，但误报率最高，适合高安全要求、可接受人工治理误报的场景。

3.3 如何设置 Paranoia

在 crs-setup.conf 中：

SecAction "id:900000,phase:1,pass,nolog,setvar:tx.crs_setup_paranoia_level=1"

把数字改为 2/3/4 即可逐级提升。

3.4 按业务灵活分级：per-request 覆盖

CRS 支持为特定路径或特定来源 IP 单独调整等级。例如后台管理接口用高等级、公开接口用低等级：

# 全局 PL2
SecAction "id:900000,phase:1,pass,nolog,setvar:tx.crs_setup_paranoia_level=2"

# 后台路径提升到 PL4
SecRule REQUEST_URI "@beginsWith /admin" "id:900001,phase:1,pass,nolog,setvar:tx.crs_setup_paranoia_level=4"

注意等级设置规则需在初始化阶段执行，且 setvar:tx.crs_setup_paranoia_level 对后续规则生效。

3.5 升级 Paranoia 的落地建议

不建议直接跳到 PL4。推荐路径：

1. 从 PL1 起步，接入真实流量观察一段时间；
2. 收集误报清单，逐条治理；
3. 平稳后升 PL2，重复治理；
4. 高安全场景再评估 PL3/PL4，配合白名单排除。

调 Paranoia 的前提是能治理误报，等级越高，越依赖后续的误报治理能力。

四、从零编写 ModSecurity 自定义规则

理解引擎语法是编写自定义规则的基础。下面从变量、运算符、动作到完整示例逐步讲。

4.1 规则基本结构

SecRule TARGET "OPERATOR" "ACTIONS"

一条规则由三部分组成：目标（检测哪里的数据）、运算符（判断条件）、动作（命中后做什么）。

4.2 常用目标变量（TARGET）

• REQUEST_URI：请求的 URI 路径
• ARGS：所有请求参数（含 GET/POST）
• ARGS_NAMES：参数名
• REQUEST_HEADERS：请求头
• REQUEST_COOKIES：Cookie
• REQUEST_BODY：请求体原始内容
• REQUEST_METHOD：请求方法
• REMOTE_ADDR：客户端 IP
• RESPONSE_BODY：响应体

4.3 常用运算符（OPERATOR）

• @rx：正则匹配（最常用）
• @eq / @ge / @lt：数值比较
• @streq：精确字符串匹配
• @contains：包含子串
• @beginsWith / @endsWith：前后缀匹配
• @pm：词典匹配（多个关键词，性能好）
• @ipMatch：IP 匹配

4.4 动作组合示例

一条拦截 SQL 注入特征的规则：

SecRule ARGS "@rx (?i)union\s+select|information_schema|sleep\s*\(" \
  "id:100001,phase:2,deny,status:403,msg:'SQL injection detected',severity:'CRITICAL',tag:'attack-sqli'"

含义：检测所有请求参数，若匹配 union select、information_schema、sleep ( 等特征，则阶段 2 直接 deny 并返回 403。

4.5 一个更实用的自定义规则示例

拦截上传目录中的可执行脚本访问：

SecRule REQUEST_URI "@rx ^/upload/.*\.(php|jsp|asp|sh)$" \
  "id:100002,phase:1,deny,status:403,msg:'Script file access in upload dir',severity:'WARNING',tag:'attack-upload'"

4.6 动态放行（ctl 动作）

某些参数命中但业务确需通过时，可用 ctl:ruleRemoveById 临时移除某条规则对当前请求的判定：

SecRule REQUEST_URI "@beginsWith /api/open" \
  "id:100003,phase:1,pass,nolog,ctl:ruleRemoveById=942100"

五、误报治理：从发现到根治的完整流程

误报是 WAF 上线后最棘手的问题。治理得不好，业务被误伤、防护被关闭。下面给出标准治理流程。

5.1 开启审计日志，定位误报规则

ModSecurity 审计日志记录每个命中请求的完整信息，包括命中的规则 ID 与 msg。先确保审计日志开启：

SecAuditEngine RelevantOnly
SecAuditLog /var/log/modsec_audit.log
SecAuditLogParts ABIDEHZ

5.2 分析误报根因

拿到误报请求后，要判断误报发生在哪一层：

1. 是 Paranoia 等级过高导致的启发式误判？
2. 是业务数据本身含攻击特征（如富文本、代码片段、SQL 关键词）？
3. 是 CRS 默认规则与业务场景不匹配？

举例：业务允许用户提交代码片段，会大量命中 XSS 规则；富文本编辑器允许 onerror= 等属性，会命中 XSS 规则；分页参数带数字可能命中协议规则。

5.3 三类治理手段

手段一：移除特定规则对特定路径的限制
把误报限定在最小范围，用 ctl:ruleRemoveById 或全局排除：

SecRule REQUEST_URI "@beginsWith /api/editor" \
  "id:100010,phase:1,pass,nolog,ctl:ruleRemoveById=941100,941110"

手段二：调整 Paranoia 等级（降误报）
整体误报偏高时，先把 PL 降回上一级，观察误报是否回落。PL 是误报率最直接的杠杆。

手段三：调整异常分阈值
把 tx.inbound_anomaly_score_threshold 调高，让低危特征累计到更高分才触发拦截，减少偶发误报：

SecAction "id:900020,phase:1,pass,nolog,setvar:tx.inbound_anomaly_score_threshold=10"

5.4 动态速率与限流降噪

对非攻击但高频的请求（爬虫、刷接口），可单独做限速，避免触发 CRS 通用规则造成误报：

SecRule REMOTE_ADDR "@pm 扫描器IP1 扫描器IP2" \
  "id:100020,phase:1,drop,msg:'Block known scanner',severity:'NOTICE'"

5.5 建立误报台账

每次治理都记录：误报规则 ID、触发场景、业务数据样例、治理手段。长期积累可沉淀成一套 “业务专属例外规则集”，让 WAF 越用越贴合业务、越用越准。

六、常见问题与实战注意点

ModSecurity 与 Nginx/Apache 的部署差异：Apache 原生模块较成熟；Nginx 需编译第三方模块或用 Nginx ModSecurity connector，部署前确认版本兼容。

规则更新：CRS 会随 OWASP 更新，注意定期同步，避免规则滞后导致漏拦截新攻击变体。

性能影响：规则越多、Paranoia 越高、审计越全，对性能消耗越大。高流量场景要评估，可结合 SecRuleEngine 只对部分路径开检测。

先记录后拦截：上线初期建议用 SecRuleEngine DetectionOnly（仅记录不拦截），观察误报情况，稳定后再切 On 拦截模式。这是最稳妥的上线方式。

---

最后

关于网络安全技术储备

网络安全是当今信息时代中非常重要的一环。无论是找工作还是感兴趣（黑客），都是未来职业选择中上上之选，为了保护自己的网络安全，学习网络安全知识是必不可少的。

如果你是准备学习网络安全（黑客）或者正在学习，下面这些你应该能用得上：

①网络安全学习路线
②20份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥网络安全必备书籍
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

一、网络安全（黑客）学习路线

网络安全（黑客）学习路线，形成网络安全领域所有的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

二、网络安全教程视频

我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。

三、网络安全CTF实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这里带来的是CTF&SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~

四、网络安全面试题

最后，我们所有的作为都是为就业服务的，所以关键的临门一脚就是咱们的面试题内容，所以面试题板块是咱们不可或缺的部分，这里我给大家准备的就是我在面试期间准备的资料。

网安其实不难，难的是坚持和相信自己，我的经验是既然已经选定网安你就要相信它，相信它能成为你日后进阶的高效渠道，这样自己才会更有信念去学习，才能在碰到困难的时候坚持下去。

机会属于有准备的人，这是一个实力的时代。人和人之间的差距不在于智商，而在于如何利用业余时间，只要你想学习，什么时候开始都不晚，不要担心这担心那，你只需努力，剩下的交给时间！

这份完整版的网络安全学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】