ModSecurity WAF（Web 应用防火墙）不是把规则全部打开就结束的安全开关。真正容易出问题的地方，往往是不同攻击场景混在同一套默认策略里：SQL 注入需要重点看参数和数据库关键字，跨站脚本更关注表单与富文本，扫描探测则要结合路径、频率和来源。本文会教你如何按攻击场景拆分 ModSecurity WAF 防护策略，用日志验证规则是否命中正确对象，并在不影响正常业务的前提下逐步收紧拦截。
先把防护目标拆成可验证的场景
很多站点启用 ModSecurity WAF（Web 应用防火墙）后，只盯着“拦截次数”看。这个指标有参考价值，但不能直接说明防护质量。一个搜索框因为合法特殊字符被拦截 200 次，和一个登录页遭遇自动化撞库被拦截 200 次，处理方式完全不同。前者需要缩小例外，后者可能要叠加频率限制、强密码策略和登录告警。
建议先把网站入口分成四类：公开页面、登录后台、用户提交入口、文件上传入口。公开页面重点防扫描和异常路径，登录后台重点防爆破和异常参数，用户提交入口重点防 SQL 注入与跨站脚本，文件上传入口则重点看请求体大小、扩展名和内容类型。若网站运行在 VPS（虚拟专用服务器）主机 上，还应记录 Web 服务器、运行时版本和日志位置；如果使用 服务器配置 更灵活的环境，则可以把 WAF 策略与系统防火墙、应用日志一起纳入变更记录。
拆场景的目的，是让后续每条规则都有测试入口。比如 SQL 注入规则至少要覆盖查询参数和表单字段，跨站脚本规则要覆盖评论框或富文本字段，扫描探测规则要覆盖不存在的后台路径。没有这些入口，日志里出现规则 ID 时，你很难判断它是有效命中还是误报。
针对 SQL 注入：重点看参数、编码和数据库关键词
SQL 注入通常发生在查询参数、搜索框、筛选条件、登录字段和接口请求体中。ModSecurity WAF（Web 应用防火墙）会通过规则识别异常组合，例如数据库关键词、注释符、布尔条件拼接、异常编码和可疑函数名。配置这类规则时，不建议一开始就全局强拦所有命中，而是先挑高风险入口进入检测模式，观察 24 到 72 小时。
可执行的基线测试可以这样设计：准备 3 条正常搜索、1 条包含特殊符号的合法搜索，以及 1 条经过授权的异常测试输入。记录每次请求的 URL、状态码、响应时间和审计日志中的规则 ID。若正常搜索与异常输入命中同一条规则，就说明规则粒度还需要调整；若只有异常输入命中，并且正常请求状态码保持 200 或业务预期状态，则可以考虑把该规则从记录切换到阻断。
配置策略上，优先保护会触发数据库查询的入口，而不是把静态资源路径也纳入高强度检查。图片、CSS、JS 等静态文件通常不需要完整请求体规则；把它们排除在高成本检查之外，有助于减少日志噪声。对于使用 网站性能优化 策略的站点，还要观察 WAF 检查是否明显拉长 TTFB（首字节时间），避免安全层成为新的性能瓶颈。
针对跨站脚本：不要把富文本和攻击载荷混为一谈
跨站脚本通常出现在评论、留言、资料编辑、搜索结果回显和富文本发布场景。它和 SQL 注入最大的区别，是很多合法业务本来就会提交尖括号、链接、样式片段或编码字符。内容管理系统、表单插件、编辑器和客服插件都可能触发规则，所以这类规则最容易误报。
处理跨站脚本规则时，先确认字段用途，再决定例外范围。比如普通留言表单不应接收脚本片段，命中后可以更快切换到阻断；但后台富文本编辑器可能需要保存 HTML 结构，这时更适合针对登录后的特定路径、特定参数和特定角色做例外。不要因为一个编辑器误报，就全局关闭跨站脚本规则。
建议把跨站脚本策略拆成两个层级：公开入口偏严格，后台编辑入口偏审计。公开入口如评论、询盘、注册表单，可以在验证后启用更强拦截；后台编辑入口先保留日志，确认具体字段和用户行为后再做精确例外。若站点是内容型 WordPress，建议同时参考 WordPress 相关文章，把插件更新、账号权限和 WAF 日志一起检查。
针对扫描探测：把路径、频率和来源串起来看
扫描探测不一定带有明显攻击载荷，它更常表现为短时间访问大量不存在路径，例如后台入口、备份文件、配置文件、旧插件路径和常见脚本文件。单次 404 可能只是用户输错地址，但同一来源在 10 分钟内访问几十个敏感路径，就值得进入安全事件分析。
ModSecurity WAF（Web 应用防火墙）在这类场景中适合负责两件事：记录可疑路径和标记异常请求特征。真正的频率限制和来源封禁，通常还要结合 Web 服务器、系统防火墙或应用层安全插件完成。为了避免误判，建议日志里至少保留来源 IP（互联网协议地址）、请求路径、User-Agent、规则 ID、响应状态码和时间戳。
首次上线时可以按下面 4 个观察点建立记录，每项都要能从日志里复核：
- 同一来源 10 分钟内访问不存在后台路径超过 20 次，标记为扫描候选。
- 同一 User-Agent 连续请求配置文件、备份文件和脚本路径，优先进入阻断观察。
- 公开页面 404 次数升高但来源分散，先看是否有站内链接错误，再判断攻击。
- 登录路径出现高频失败时，把 WAF 日志与应用登录日志按分钟对齐。
这组观察点不是固定阈值，而是让团队形成一致判断。低流量企业站可以把阈值设低一些，活动页或内容站则要结合自然访问量调整。关键是不要只凭单条日志做永久封禁，也不要把所有 404 都当成攻击。
针对异常请求体：限制大小、类型和上传路径
文件上传、API 提交、表单附件和导入功能，经常会触发请求体相关规则。这里的风险不只包括恶意脚本文件，还包括超大请求体、伪造内容类型、压缩包嵌套、异常字段数量和编码绕过。配置时要先知道业务真实需要多大的上传限制，再让 WAF 策略贴合这个范围。
比如一个只接收联系表单附件的站点，可以把单文件大小限制在业务允许范围内，并限制扩展名；一个需要上传产品图片的站点，则要保留图片格式，同时阻断可执行脚本、双扩展名和异常 MIME 类型。不要为了“方便上传”把请求体检查整体关闭，否则攻击者会优先利用上传入口绕过其他防护。
验证请求体策略时，至少准备 3 类样本：合法小文件、合法边界大小文件、明确不允许的文件类型。每个样本都记录上传路径、返回状态码、应用日志和 WAF 审计日志。若合法边界文件被误拦，先调整大小或字段例外；若不允许的文件仍能通过，则说明规则覆盖不足，不能进入正式拦截验收。
用日志把规则从“能拦”变成“拦得准”
日志验证的重点不是保存越多越好，而是能回答三个问题：谁触发了规则，在哪个入口触发，处置动作是什么。ModSecurity 审计日志通常会包含事务 ID、规则 ID、请求路径、匹配变量和处置结果。实际排查时，先按时间定位，再按规则 ID 聚合，最后回到具体 URL 和参数。
建议每次调整规则后都保留一条变更记录：变更时间、规则 ID、影响路径、预期处置、回滚方式和验证结果。这样一旦出现 403、表单提交失败或后台保存异常，可以直接对照最近一次变更，而不是在多份配置文件里猜。对于 Hostease 用户，我们建议把主机环境、备份策略和安全变更放在同一份运维记录中，便于后续支持和排障沟通。
如果你要从检测模式切换到拦截模式，可以用这个顺序做最后确认：
- 正常登录、搜索、提交、上传各测试 1 次，并记录状态码。
- 对每个高风险入口执行 1 条授权异常输入，确认日志能记录规则 ID。
- 切换拦截后观察 30 到 60 分钟，重点看 403 数量和业务投诉。
- 出现集中误报时先回到检测模式，再按路径和参数缩小例外。
总结：按场景收紧，比一次性全开更可靠
ModSecurity WAF（Web 应用防火墙）的价值，来自“按攻击场景配置、按日志证据调整、按业务入口验证”的持续流程。SQL 注入、跨站脚本、扫描探测和异常请求体的风险不同，误报来源也不同。如果把它们都放进同一套默认开关里，短期看似省事，长期很容易在安全和可用性之间反复摇摆。
我们推荐的做法是：先列出网站的关键入口，再为每个入口设计正常样本和异常样本；先让规则记录，再根据日志判断是否拦截；每次例外都写清楚路径、规则 ID 和原因。对于业务正在增长的网站，可以考虑在资源更稳定、日志更完整的主机环境中部署这套流程。如果你需要更稳妥地推进生产环境防护，建议先从低风险入口试运行 1 周，再把经验复制到登录、表单和上传等关键路径。