Web应用防火墙规则配置入门：先盘点资产，再分阶段拦截

Web应用防火墙规则配置入门，第一步不是打开所有拦截开关，而是弄清楚哪些网站、接口和业务流程会经过防护设备。规则范围不清，可能漏掉对外服务，也可能把正常登录、搜索或文件上传请求挡住。稳妥的做法是先盘点资产，再以监测模式观察日志，确认规则效果后逐步拦截。

先列清资产和请求路径

把公网域名、对应应用、负责人和重要接口整理成表。除了首页，也要核对登录、密码重置、搜索、支付回调、文件上传及对外 API 等路径。测试环境与生产环境应分开记录；已经下线的域名和旧接口，要确认是否仍有流量，不能只凭名称判断其用途。

同时画出请求经过的位置：流量是在内容分发网络、反向代理还是云端 WAF 处检查？若有多个入口，需确认每个入口是否都覆盖。检查源站是否仍可绕过 WAF 直接访问；如需限制源站，只允许已确认的代理出口访问，并预留运维和健康检查所需通道。

多数 WAF 可先记录匹配结果而不拦截。Web应用防火墙规则配置入门阶段，应优先开启厂商提供的托管规则集，观察它对请求的命中情况，再逐条调整。常见检测方向包括 SQL 注入、跨站脚本和异常协议格式，但检测命中不等于恶意：包含查询语句的搜索词、富文本内容和编码后的参数，也可能触发规则。

建议按以下步骤推进：

建立基线：在不改变访问策略的情况下观察一段有代表性的业务周期，覆盖工作日高峰、批处理或发布等已知流量变化。记录被匹配的路径、规则编号、请求来源和响应情况。
处理高置信度项：先挑选与明确攻击特征相符、且不影响关键业务的规则，针对单一网站或路径启用拦截。每次只调整一组规则，便于定位变化原因。
验证业务流程：用正常测试账号完成登录、查询、提交表单和上传等操作，并检查应用日志。仅看到网页能打开，不足以证明接口流程正常。
分批扩大范围：确认误报和业务异常处于可接受范围后，再覆盖更多路径或站点；保留变更记录、负责人和回滚方法。

适合快速获得常见攻击特征检测，维护成本较低，但通用规则不了解每个应用的参数格式。启用后应重点看具体命中规则，而不是笼统关闭整个规则集。

适合处理明确的路径、方法或来源条件。例如只允许某个回调地址使用指定请求方法。条件应尽量精确，避免对整个域名放行；例外白名单应限定路径、参数或规则编号，并定期复查。

适合降低登录、验证码或搜索接口遭到高频请求的影响。阈值要结合正常流量设定：可先观察每分钟请求分布，再测试略高于正常峰值的限制。共享出口、移动网络和自动化客户端会影响单 IP 计数；若以每分钟数次到数十次作为试调范围，也应根据接口用途和实际日志校正，不能视为通用标准。

关注误报、拦截数量、受影响路径和应用错误率。出现异常时，先查事件日志中的规则编号、请求方法、参数和处置动作，再判断是攻击流量、业务变化还是规则过宽。对合法请求做窄范围例外，比关闭整组防护更容易保留安全收益。

每次变更前保存原配置；若关键流程失败，先撤销最近一项拦截或恢复监测模式，并通知应用负责人复测。Web应用防火墙规则配置入门的核心不是规则越多越好，而是每条规则都有明确范围、验证依据和回退路径。

没有适用于所有站点的固定时长。至少覆盖有代表性的业务周期；流量变化大或低频接口多的系统，应延长观察并补做测试。

不一定。先核对规则内容与请求上下文，确认恶意特征后再处理；误报应创建精确例外，而不是忽略日志。

不能。WAF 可作为额外防护或临时缓解措施，但输入校验、权限控制和安全编码仍需在应用中落实。

规则变更、应用发布、接口新增或流量模式改变后都应复查；平时也要定期检查例外项和长期未命中的规则。