服务器装了防火墙、只开了 80 和 443、系统补丁也打全了，网站还是被拖库了。原因很简单：传统防火墙工作在三四层，只看 IP 和端口，它对 HTTP 请求里携带的内容一无所知。攻击者把恶意内容放在正常端口的正常请求里，三层防火墙看到的是"一个合法的 80 端口访问"，直接放行。
WAF（Web Application Firewall）就是补上这一层的东西。它工作在应用层，理解 HTTP 协议和请求内容，能判断"这个请求是不是在尝试注入"。这篇文章讲清楚 WAF 的部署形态、检测原理、能力边界、规则管理与误拦处理，以及与 CDN、负载均衡的叠加关系。全文是防御视角，不讨论任何绕过方法。
WAF 的部署形态
WAF 不是某一种产品，而是一类能力，落地形态主要有四种，选择取决于你的架构和运维能力。
云 WAF（SaaS 模式）是当前最常见的形态。把域名解析 CNAME 到 WAF 厂商的节点，流量先经过 WAF 再回源。优点是不需要在自己的服务器上装任何东西，防护能力由厂商维护，规则库自动更新，扩容透明。缺点是流量要绕行第三方节点，需要评估延迟和数据合规；同时必须做回源 IP 白名单，否则源站 IP 暴露后防护可以被绕过。
反向代理型 / 网关型 WAF 部署在自己的网络里，常见做法是在 Nginx 前面加一层带 WAF 能力的网关，或者直接用云负载均衡集成的 WAF 功能。优点是数据不出自己的网络，回源链路可控；缺点是要自己维护规则和性能容量。
软件 WAF（主机型） 以模块形式安装在 Web 服务器上，最典型的是 ModSecurity，配合 OWASP CRS 规则集使用。它作为 Nginx 或 Apache 的模块运行，检查经过的每一个请求。
# Debian、Ubuntu 安装 ModSecurity（Nginx 动态模块）
sudo apt update && sudo apt install -y libnginx-mod-security
# RHEL、Rocky、CentOS
sudo dnf install -y nginx-mod-modsecurity mod_security_crs
安装后加载规则集并开启引擎：
# /etc/nginx/modsecurity/modsecurity.conf 关键项
SecRuleEngine On # On=拦截，DetectionOnly=只记录不拦截
SecRequestBodyAccess On
SecAuditEngine RelevantOnly
SecAuditLog /var/log/nginx/modsec_audit.log
# nginx 站点配置中启用
server {
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;
}
首次上线强烈建议用 DetectionOnly（观察模式），先跑一段时间看日志里会拦什么，确认没有误拦再切到 On。这一步能避免上线即事故。
代码级 WAF / RASP 以 SDK 或探针形式嵌入应用进程内部，能看到请求在应用里的实际执行上下文（比如 SQL 语句最终长什么样），误判率更低，但侵入性更强，对应用有性能影响，且与语言栈绑定。
| 形态 | 部署成本 | 维护成本 | 数据合规 | 适用场景 |
|---|---|---|---|---|
| 云 WAF | 低，改 DNS 即可 | 低，厂商维护规则 | 流量经第三方 | 大多数网站、中小企业 |
| 反向代理型 | 中，需加一层 | 中 | 数据不外流 | 有合规要求的行业 |
| 软件 WAF | 中，装模块 | 高，需自己调规则 | 数据不外流 | 有能力调优的团队 |
| RASP | 高，需改应用 | 中 | 数据不外流 | 对误判极敏感的核心业务 |
WAF 是怎么检测攻击的
理解检测原理，才能理解 WAF 能防什么、为什么会有误拦、以及为什么它不是万能的。
第一层是协议合规校验。 HTTP 协议本身有规范，很多攻击会先违反规范。比如请求缺少 Host 头、Content-Length 与实际 body 不符、URL 编码嵌套多层、HTTP 方法不在允许列表内、Header 里出现非法字符。这一层几乎不会误判，因为它不猜测意图，只判断"合不合规"。
第二层是特征匹配。 把请求内容与已知攻击特征库比对，主要用正则。比如检测 SQL 注入会匹配 union select、or 1=1、sleep(、注释符等组合；检测 XSS 会匹配 onerror=、javascript: 等。OWASP CRS 规则集包含数千条这样的规则，按类型分组并赋予严重级别。
特征匹配的优点是直观、可解释、可追溯；缺点是对变形敏感，攻击者稍作编码或改写就能让单条正则失效，所以规则库需要持续更新，这也是云 WAF 的价值所在。
第三层是语义分析。 这是比正则更进一步的做法：先对请求做规范化（URL 解码、Unicode 归一化、注释去除、大小写归一），再判断它在语义上是否构成攻击。举个例子，参数值是 1 UNION/**/SELECT 这种带混淆的写法，正则可能漏过，但语义分析能还原出它的结构。一些产品还会做简易的语法解析，判断输入是否改变了预期的语句结构。
第四层是行为与频率分析。 不关心单次请求的内容，而是看一段时间内的行为模式：某个 IP 在一分钟内请求了多少次、请求的是不是同一个高消耗接口、失败登录次数、爬虫行为的比例、访问路径是否像人在浏览。这一层主要应对 CC 攻击、撞库、爬虫和内容爬取。
第五层是 IP 情报与信誉库。 基于历史数据标记的恶意 IP、代理出口、僵尸网络节点、已知扫描器来源。命中情报库的 IP 可以直接拒绝或加重校验。这一层成本低，但对分布式攻击效果有限。
第六层是机器学习辅助。 用正常流量的统计模型识别偏离基线的请求。它擅长发现未知模式的异常，但存在可解释性差、误判难以排查的问题，通常作为打分因子与其他方法组合使用，不单独作为拦截依据。
实际产品通常把多层结果加权成一个分数或风险等级，再决定放行、记录、挑战（验证码/JS 校验）还是拦截。理解这一点很重要：WAF 的判断是概率性的，不是确定性的，这决定了它需要观察模式和人工调优。
WAF 能防什么，防不了什么
能防的：
SQL 注入、XSS 跨站脚本、命令注入、路径穿越、文件包含（本地与远程）、SSRF 的常见特征、反序列化载荷的特征、WebShell 上传与访问、扫描器探测、常见的自动化工具指纹、CC 与高频请求、撞库、恶意爬虫与内容抓取、敏感信息泄露（如返回内容里的身份证号、银行卡号可做脱敏或告警）。
防不了的：
| 无法覆盖的场景 | 原因 |
|---|---|
| 业务逻辑漏洞 | 越权查看他人订单、金额篡改、优惠券重复使用，请求本身完全合法 |
| 认证与会话缺陷 | 弱口令、会话固定、Token 泄露，不是请求内容问题 |
| 0day 与未知漏洞 | 没有特征可匹配，只能靠行为异常碰运气 |
| 客户端漏洞 | 用户浏览器侧的问题，服务端看不到 |
| 内部威胁 | 有合法权限的人做非法操作 |
| 供应链与第三方组件后门 | 请求层面看起来正常 |
| 配置错误 | 目录遍历式的暴露、备份文件可下载，是配置问题 |
最后一条值得展开：很多拖库事件不是因为绕过 WAF，而是因为网站根目录下放着一个 backup.sql 可以随便下载，或者管理后台地址是猜得到的路径且没有二次认证。这类问题 WAF 只能起到部分缓解作用（比如拦截对已知备份文件后缀的访问），根本解法是做好配置管理。
所以正确的定位是：WAF 是把已知攻击的自动化尝试挡在门外，让攻击成本大幅提高，但它不能替代安全的代码、正确的配置和完善的认证设计。
规则管理与误拦处理
上线 WAF 之后最大的工作量不是配置，而是处理误拦。
先用观察模式跑。 云 WAF 一般都有"观察/告警但不拦截"模式，ModSecurity 是 SecRuleEngine DetectionOnly。跑一到两周，看日志里有哪些规则被触发，逐条评估：是真的攻击，还是正常业务触发的误报。
建立白名单而非关规则。 遇到误拦，正确的做法是针对具体的 URL、参数或来源加白名单，而不是把整条规则关掉。关掉一条 SQL 注入规则等于给所有 URL 开了口子。云 WAF 一般支持按规则 ID 加例外，ModSecurity 可以这样做：
# 对某个 URL 的某个参数关闭特定规则（按规则 ID）
SecRule REQUEST_URI "@beginsWith /api/search" \
"id:10001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:q"
# 对某个来源 IP 关闭特定规则
SecRule REMOTE_ADDR "@ipMatch 203.0.113.10" \
"id:10002,phase:1,pass,nolog,ctl:ruleRemoveById=942100"
日志是调优的依据。 云 WAF 要开启全量或采样日志并保留足够长时间；ModSecurity 的审计日志要配置轮转：
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Concurrent
SecAuditLogStorageDir /var/log/nginx/modsec_audit
审计日志里记录完整的请求头和 body，包含敏感信息，必须按敏感数据管理，控制访问权限并设置留存期限。
版本与变更管理。 规则集升级会改变拦截行为，升级前要在测试环境验证。把 WAF 配置纳入版本管理，变更走评审，避免有人随手改一条规则导致大面积误拦或防护失效。
误拦的应急通道。 出现大面积误拦时要有快速降级手段：切回观察模式、临时关闭某条规则、或者直接绕过 WAF 访问源站（仅限紧急情况，且绕过时要确认源站有其他保护）。这个通道要有权限控制和审计记录，不能成为绕过防护的常态路径。
与 CDN、负载均衡的叠加关系
一个典型的 Web 架构里，WAF 的位置通常是：用户 → CDN → WAF → 负载均衡 → 应用。
与 CDN 的关系： CDN 负责缓存加速和隐藏源站，WAF 负责安全过滤。很多 CDN 产品内置了基础 WAF 能力，中小站点用这一层就够。顺序上，CDN 先处理缓存命中，未命中的请求回源时经过 WAF，这样静态资源不会被 WAF 重复检查，性能更优。
与负载均衡的关系： WAF 可以放在负载均衡之前（集中式，所有流量都过）或之后（每台后端单独）。集中式更常见，也更容易管理。如果用了云负载均衡，检查它是否已集成 WAF，避免重复部署两层导致延迟叠加和排查困难。
真实客户端 IP 的传递。 经过多层代理后，应用看到的是上一层代理的 IP。需要逐层传递真实 IP：CDN 加 X-Forwarded-For，WAF 追加，负载均衡保留，最后由 Nginx 用 real_ip 模块还原：
# nginx.conf
set_real_ip_from CDN或WAF的IP段;
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
关键安全点： X-Forwarded-For 是可以被客户端伪造的头部。必须配置 set_real_ip_from 只信任上游代理的 IP 段，否则攻击者可以伪造任意 IP 绕过基于 IP 的限流和黑名单。同时源站要拒绝一切非来自 WAF/CDN 的直接访问。
证书与 TLS。 HTTPS 通常在最外层终止，回源可用 HTTP 或 HTTPS。用 HTTPS 回源时，内层链路也要配置证书，且要确认证书校验没有为了方便而关闭（关闭校验等于允许中间人）。
性能影响与容量规划
WAF 是串联在链路上的，必然带来性能影响：
延迟。 每多一跳就多一点网络延迟，加上规则匹配的计算时间。量级通常在几毫秒到几十毫秒，取决于规则数量、请求体大小和节点位置。对延迟敏感的接口要实测。
吞吐。 规则检查是 CPU 密集操作，云 WAF 需要按 QPS 峰值选型，自建 WAF 需要评估单机的处理能力并预留余量。请求体越大、规则越多，开销越大。
优化手段包括：静态资源交给 CDN 不经过 WAF、对确定安全的路径（如静态文件目录）跳过部分规则、关闭不必要的请求体检查、只对关键接口开启完整检查。
可用性与故障域。 WAF 串联意味着它挂了业务就挂了。要评估厂商的可用性承诺，自建的话要做集群和探活。同时准备应急绕过方案：能够在紧急情况下把流量切回源站（源站需有基础限流保护）。
常见问题
装了 WAF 是不是就不用改代码了？
不是。WAF 是把已知的自动化攻击挡住，为修复代码争取时间。业务逻辑漏洞、越权、认证缺陷这些 WAF 完全防不了。正确做法是：WAF 拦截发现的攻击记录下来，同步推动代码修复，形成闭环。
为什么 WAF 把正常用户请求拦了？
最常见的原因是业务参数里包含了看起来像攻击的内容，比如搜索框里输入了带引号的文本、表单提交了 HTML、API 传了 JSON 里带尖括号。处理办法是针对具体 URL 和参数加例外，而不是关掉整条规则。观察模式跑一段时间能提前发现大部分误拦。
云 WAF 和自建 WAF 怎么选？
看团队能力和合规要求。没有专职安全人员、流量规模不大，用云 WAF 更划算，规则维护和容量扩容都由厂商负责。有合规要求数据不能出网、或者有专人能持续调优规则，可以考虑自建。也有混合做法：云 WAF 做第一层，自建做关键接口的精细化防护。
WAF 能防 CC 攻击吗？
能，但要看配置。CC 防护依赖频率限制和行为分析，需要针对业务设定合理的阈值（比如单 IP 每分钟请求数、单会话请求频率），配合验证码或 JS 挑战。阈值设得太松无效，太紧会误伤共用出口 IP 的用户，需要观察真实业务流量后调整。
WAF 日志要不要全量保存？
至少保存攻击命中的日志，保留时长按合规要求（常见是六个月以上）。全量访问日志成本高，可以采样保存。日志要送到独立的日志系统，避免攻击者入侵主机后删除。同时注意日志里含敏感请求内容，访问控制和留存期限要按敏感数据管理。
总结
- WAF 工作在应用层，补的是传统防火墙看不懂 HTTP 内容的空白；部署形态有云 WAF、反向代理型、软件 WAF（如 ModSecurity）和 RASP 四种，按团队能力与合规要求选择。
- 检测手段是多层的：协议合规校验、特征正则匹配、语义分析、行为频率分析、IP 情报、机器学习辅助打分，最终结果是概率性判断，所以需要观察模式和持续调优。
- WAF 能防注入、XSS、命令注入、路径穿越、文件包含、扫描器、CC 等已知攻击模式，但防不了业务逻辑漏洞、认证缺陷、0day、内部威胁和配置错误，不能替代安全的代码与正确的配置。
- 上线先用观察模式跑一到两周，误拦处理要按 URL、参数、来源加白名单而不是关整条规则，规则集升级前在测试环境验证，配置纳入版本管理。
- 与 CDN、负载均衡叠加时要解决真实 IP 传递（
real_ip只信任上游段，防止X-Forwarded-For被伪造）和源站访问控制；同时评估延迟、吞吐与故障域，准备应急绕过通道。
企业QQ咨询
