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、資料庫連接埠的暴露要靠防火牆和安全組，這幾層各管一段，不能互相替代。