WAF 防火墙怎么部署：云 WAF、硬件 WAF 与开源 WAF 对比

WAF 防火墙（Web 应用防火墙）怎么部署，取决于你的网站放在哪、谁来维护规则、预算花在哪。常见的三种部署方式是：云 WAF，把域名 CNAME 到服务商的节点，流量先过节点再回源，源站几乎不用改；硬件或虚拟 WAF，以设备或虚拟机镜像的形式串联在机房链路上，一台设备保护一批服务器；开源 WAF，如 ModSecurity 加 OWASP 核心规则集、雷池社区版、Nginx 自定义规则，装在你自己的服务器上，软件不花钱，规则要自己调。三者检查的都是 HTTP 请求的内容，差别在部署位置、抗流量能力、费用构成和误拦处理的方式。

三种部署方式一张表看懂

对比项	云 WAF	硬件 / 虚拟 WAF	开源 WAF
部署位置	服务商的云端节点	机房出口或业务区前，串联在链路上	源站本机，或源站前的一台代理服务器
接入方式	域名解析改为 CNAME	透明桥接、反向代理、路由或旁路	Web 服务器模块，或独立的反向代理
对源站的改动	锁定回源地址、取回真实 IP	透明模式不改 IP，代理模式要改解析	改 Nginx、Apache 配置，或把解析指向代理
HTTPS 证书	上传到服务商平台	导入设备	留在自己的服务器上
规则来源	服务商维护，自动更新	厂商特征库，按订阅更新	社区规则集加自己写的规则
抗流量能力	取决于节点带宽和套餐里的防御值	受机房入口带宽限制	和源站共用带宽与 CPU，被打时一起受影响
费用构成	按域名数、QPS 或带宽分档，包年包月	设备采购、特征库订阅、维保，高可用至少两台	软件免费，成本在服务器资源和人力
误拦处理	控制台里按规则 ID 或 URL 加例外	设备管理界面里加例外，必要时切直通	改配置文件或管理界面，自己排查
适合	网站分散在多处、没有专职安全人员	IDC、托管大量站点的企业	站点少、有运维能力、对数据出境或第三方解密敏感

费用这一行没有标准答案，比较报价时把三年总成本摊开算：云 WAF 是“套餐费 × 年数 + 超出套餐的域名和流量”；硬件 WAF 是“设备 + 每年的特征库与维保 + 机位电力”，而且串联设备要考虑单点故障，通常两台起步；开源 WAF 是“多占用的服务器资源 + 运维每周花在看日志和调规则上的工时”。人力这一项最容易被低估，一个没人看日志的 WAF，比没有 WAF 好不了多少。

云 WAF：改一条 CNAME 就能接入

云 WAF 的原理是让访客先连到 WAF 节点：你在控制台添加域名、填写源站地址并上传证书，平台分配一个 CNAME 地址；把域名解析改成这个 CNAME 后，访客的请求先到节点检查，再由节点转发回源站。接入时按下面的顺序做，可以做到切换过程不中断：

1. 提前一天把解析记录的 TTL 调低，例如 600 秒，出问题时改回去生效更快。
2. 在控制台添加域名，填源站 IP 和端口，上传证书或使用平台签发的证书，拿到 CNAME 地址。
3. 改解析之前先在本机验证：查出 CNAME 对应的节点地址，用 curl --resolve 让本机绕过 DNS 直接访问节点，确认证书、回源和页面都正常。
4. 把 A 记录改成 CNAME。根域名（example.com 本身）按 DNS 规范不能设 CNAME，部分 DNS 服务商提供 CNAME 拉平或 ALIAS 记录，不支持时让根域名 301 跳转到 www。
5. 锁定源站：源站的 80、443 只对 WAF 的回源地址段开放，否则攻击者直接访问源站 IP 就绕过了 WAF。回源地址段以控制台公布的列表为准，列表变化时要同步更新。
6. 取回真实客户端 IP：源站看到的来源都是 WAF 节点，Web 服务器要从 X-Forwarded-For 等请求头里还原，并且只信任来自回源地址段的请求头。

第 3 步和第 5 步的验证命令：

# 查 WAF 分配的 CNAME 解析到了哪些节点（地址换成控制台给你的）
dig +short www.example.com.waf.example.net

# 不改 DNS，让本机直接访问节点，看证书和回源是否正常
curl -sI --resolve www.example.com:443:198.51.100.20 https://www.example.com/

# 带一个明显的注入特征，确认节点在检查请求：拦截模式返回 403，观察模式返回 200 但控制台有记录
curl -s -o /dev/null -w '%{http_code}\n' --resolve www.example.com:443:198.51.100.20 \
  "https://www.example.com/?id=1%20union%20select%201,2,3"

# 锁定源站后，从一台不在回源地址段里的机器直连源站，应当超时或被拒绝，而不是返回页面
curl -skI -m 5 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

源站 IP 一旦泄露过（历史解析记录、邮件头里的发信地址、没接入 WAF 的子域名），除了锁定回源，还应该换一个新 IP。云 WAF 的其他限制也要提前确认：只代理 HTTP 和 HTTPS，并且只支持指定端口；WebSocket、大文件上传、长连接是否支持、有没有大小和超时限制，以产品文档为准；使用中国内地节点的域名需要先完成 ICP 备案；证书私钥要交给服务商保管。

硬件 WAF 与虚拟 WAF：四种接入模式怎么选

硬件 WAF 是一台装好 WAF 软件的专用设备，虚拟 WAF 是同一套软件的虚拟机镜像，可以跑在 VMware、KVM 或云平台上，功能基本一致，区别在性能上限和授权方式。它们放进机房网络时，有四种接入模式：

模式	放在哪里	要不要改 IP 或解析	能否拦截	设备故障时	适合
透明桥接	串联在网关和服务器之间，二层透明转发	不用改	能	带硬件 Bypass 网卡的设备掉电后直通，否则断网	给一个网段的服务器整体加防护，改动最小
反向代理	WAF 有自己的业务地址（VIP），解析指向它	要改解析	能	可以做双机或集群	多个站点统一出口，顺带做负载均衡
路由模式	WAF 作为服务器网段的三层网关	要改网关或路由	能	网关故障，整段中断	新建网络时一并规划，存量网络少用
旁路镜像	交换机端口镜像一份流量给它	不用改	以告警为主	不影响业务	只要求检测和留存记录

IDC 机房里最常见的是透明桥接和反向代理：前者把 WAF 串在某个业务区的上联链路上，网段里的服务器不用做任何改动；后者适合把 WAF 当增值服务卖给客户，客户逐个站点接入。两种模式都要导入客户的证书才能检查 HTTPS，等于客户把私钥交给了机房，合同里要写清楚证书的保管和销毁责任。

选型时别只看宣传页上的“网络吞吐”，那个数字往往是不开防护规则、用大包测出来的。真正决定能保护多大业务的是三个指标：开启全部规则后的 HTTP 吞吐、HTTPS 每秒新建连接数（每秒能完成多少次 TLS 握手）和最大并发连接数，让厂商按你的业务特征给出测试条件。串联部署还要确认硬件 Bypass、双机热备和配置同步怎么做，否则 WAF 本身就成了单点故障。

开源 WAF：ModSecurity、雷池与 Nginx 规则

方案	形态	检测方式	管理方式	适合
ModSecurity + OWASP CRS	Apache 模块（v2），Nginx 通过 libmodsecurity3 和连接器模块加载（v3）	特征匹配加异常评分	改配置文件，没有官方图形界面	熟悉 Apache、Nginx 配置的运维
OWASP Coraza	Go 语言实现的引擎，可嵌入 Caddy、Envoy 等	兼容 ModSecurity 规则语法，可直接用 CRS	配置文件	已在用 Go 生态或云原生网关
雷池（SafeLine）社区版	长亭科技发布的免费社区版，项目在 GitHub 公开，Docker 部署的反向代理；是否所有组件都开源，以官方说明为准	以语义分析为主	自带 Web 管理界面	想要图形界面、不想手写规则
Nginx / OpenResty 自定义规则	在现有 Nginx 配置里加 location、map 或 Lua 脚本	简单的路径、参数、UA 匹配	配置文件	作为补充，挡住最常见的扫描

ModSecurity 原本由 Trustwave 维护，2024 年起交给 OWASP 社区维护。它和 CRS 是最常见的开源组合，Debian、Ubuntu 上配 Apache 可以直接从软件源安装，推荐配置文件默认就是只记录不拦截的观察模式：

apt install libapache2-mod-security2 modsecurity-crs
cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
grep '^SecRuleEngine' /etc/modsecurity/modsecurity.conf    # 应显示 SecRuleEngine DetectionOnly
systemctl restart apache2

# 测试：观察模式下返回 200，日志里能看到命中记录；切到 On 后返回 403
curl -s -o /dev/null -w '%{http_code}\n' "http://127.0.0.1/?exec=/bin/bash"
grep -c 'ModSecurity' /var/log/apache2/error.log

Nginx 上用 ModSecurity 需要 libmodsecurity3 加 Nginx 连接器模块，模块要和 Nginx 版本匹配，安装方式以发行版和 Nginx 来源为准。雷池社区版的安装脚本、硬件要求和各版本的功能差异，以官方文档为准，它的管理后台只对运维地址开放，不要暴露在公网。

纯 Nginx 规则算不上完整的 WAF，它不会解码、不做评分，攻击者换一种编码就能绕过，但成本几乎为零，适合挡住批量扫描最爱探测的路径：

# server 块中：版本库、环境变量文件、备份和数据库导出文件一律不对外
location ~ /\.(git|svn|hg|env) { return 404; }
location ~* \.(bak|old|swp|sql|tar\.gz)$ { return 404; }

# 网站只用到 GET、POST、HEAD 时，其他方法直接拒绝
if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; }

上线步骤：先观察，再分批拦截

不管哪种 WAF，第一天就开全量拦截几乎一定会误伤正常业务。按阶段推进，每个阶段有明确的退出标准：

阶段	做什么	进入下一阶段的标准
0. 准备	列清单：域名、端口、证书、回源地址；登录、上传、支付回调、第三方 Webhook、API 这些容易误拦的接口；导出现有解析记录，写好回退步骤	清单经业务负责人确认
1. 接入（观察模式）	流量切到 WAF，只记录不拦截；逐项测试清单里的功能	功能全部正常，访问日志里的客户端 IP 是真实地址
2. 观察 7–14 天	每天按规则 ID 和 URL 统计命中最多的记录，逐条判断真假，对误报做精确排除	连续几天没有出现新的误报类型
3. 分批拦截	先对 SQL 注入、命令注入、WebShell 上传这类高危类别开拦截，其他类别继续观察；或先切非核心站点	拦截日志里看不到正常用户
4. 全量拦截	打开全部类别，拦截页显示事件编号，客服拿到编号就能查日志	—
5. 常态运行	规则升级、新接口上线时，对新的部分重复一次观察	—

支付回调和第三方 Webhook 要特别对待：它们的请求体常带 XML、签名串和各种特殊字符，很容易命中规则，而且出错时用户看不到报错，只会出现“付了款订单没变”。这类接口在第 0 步就要单独列出，按来源地址段加例外。

WAF 防火墙怎么关：误拦时关一条规则，不要整体关掉

搜“WAF 防火墙怎么关”的人，多半是正常操作被拦了：后台保存文章报 403、上传接口失败、支付回调收不到。这时要做的不是关掉整个 WAF，而是按影响范围从小到大选一种处理方式：

范围（从小到大）	做法	代价
某个参数跳过某条规则	只对误拦的参数排除这条规则 ID	几乎没有
某个 URL 跳过某条规则	这个路径上不再执行这条规则，其他规则照常	这条规则在该路径上失效
某个 URL 只记录不拦截	配合来源地址段，例如只对支付平台的回调地址生效	该路径失去拦截，但仍有日志
来源 IP 加白	办公网出口、合作方固定地址	这些地址被盗用时毫无防护
整站切回观察模式	临时排障，查清后尽快切回	整站失去拦截
整体关闭	云 WAF 把解析改回源站，ModSecurity 设 SecRuleEngine Off，硬件 WAF 切直通	防护全无，云 WAF 还会暴露源站 IP

先确认请求确实是 WAF 拦的：云 WAF 的拦截页一般带事件编号或特有的响应头，拿编号在控制台查到对应的规则 ID；ModSecurity 在 Apache 或 Nginx 的错误日志里写 ModSecurity: Access denied，CRS 默认的异常评分模式下，这一行的规则号是 949110（总分超过阈值），真正命中的规则要看同一请求（unique_id 相同）前面几条 Warning 记录里的 [id "规则号"]；如果 WAF 日志里没有这次请求，就去查 Nginx 的 deny、安全组或程序本身的权限判断。

以 ModSecurity 为例，下面两条分别对应表里的第 2、3 行，放在一个比 CRS 规则先加载的文件里：

# 某个搜索接口被 XSS 规则 941100 误拦：只在这个路径上去掉这一条
SecRule REQUEST_FILENAME "@streq /api/search" \
    "id:10101,phase:1,pass,nolog,ctl:ruleRemoveById=941100"

# 支付回调：只有来自支付平台地址段（示例地址）的请求，在这个路径上只记录不拦截
SecRule REQUEST_FILENAME "@beginsWith /pay/notify" \
    "id:10102,phase:1,pass,nolog,chain"
    SecRule REMOTE_ADDR "@ipMatch 198.51.100.0/24" "ctl:ruleEngine=DetectionOnly"

REQUEST_FILENAME 是不带查询字符串的路径，用它做精确匹配比 REQUEST_URI 可靠。Nginx 加载 ModSecurity 时，紧急情况下也可以只在出问题的 location 里写 modsecurity off;，影响范围限定在这个路径。云 WAF 和雷池在管理界面里都能按 URL、规则或来源地址添加例外，具体的菜单名称因产品和版本而异。

整站关闭只适合一种情况：WAF 本身故障导致全站不可用。云 WAF 改回源站解析之后，源站 IP 就公开了，要同时解除回源锁定，故障恢复后再切回来；改动的时间和原因记进变更记录，避免“临时关掉”变成永久关掉。

IDC 机房怎么把 WAF 落到日常运维里

对 IDC 来说，WAF 通常作为增值服务提供：在机房出口或某个业务区串联一对硬件 WAF，按客户逐个站点接入，或者帮客户对接云 WAF。无论哪种，都会多出一批需要记清楚的资源：WAF 设备本身、业务 VIP、回源地址段、哪个客户的哪个站点接在哪台设备上。

这些信息适合放进机房管理系统，而不是散落在各人的表格里。WAF 设备上架后，在 机柜与资产 里记录所在机柜和 U 位；业务 VIP 和回源地址段录入 IP 地址管理，用分组与标签标明用途和所属客户，锁定的地址段不会被开通服务器时自动占用。客户来问“为什么我的站被 403”时，运维能先查到他的站点在哪台 WAF 后面，再按事件编号查日志。

也要提前和客户说清楚 WAF 管不到的地方：它只检查 HTTP 请求，带宽型 DDoS 要靠出口清洗或黑洞，SSH、数据库端口的暴露要靠防火墙和安全组，这几层各管一段，不能互相替代。