PHP2Shell 漏洞公開前九個小時，Cloudflare 就已經為它部署了防護規則。消息傳開後，不少人鬆了一口氣：網站有用 Cloudflare，應該就沒事了吧？

但 Cloudflare 自己的說法很保守：這些規則只是暫時性的防護，大家還是要盡快更新 PHP。這句話其實點出了網站防火牆（WAF）的本質：它很有用，但它不是修補。

這篇說明 WAF 是什麼、可能裝在哪幾個地方、擋得住什麼、擋不住什麼。最後一段會講一件很多人遇過卻不知道原因的事：為什麼有時候你只是在後台存一篇文章，卻被自己的防火牆擋下來。

WAF 是什麼？跟一般防火牆差在哪

WAF 是 Web Application Firewall 的縮寫，中文通常叫「網站應用程式防火牆」，或直接叫網站防火牆。

一般說的防火牆，管的是「誰可以連進來、可以連哪個門」：哪些 IP 可以連、哪些通訊埠要開。它不看你送進來的內容是什麼。

WAF 管的是更細的一層：它會打開每一個網頁請求，檢查裡面的內容。網址裡帶了什麼參數、表單送出了什麼資料、請求的格式正不正常，只要符合已知的攻擊特徵，就在請求抵達網站之前把它擋掉。

用大樓來比喻，一般防火牆是大門的門禁，決定誰能進大樓；WAF 是大廳的警衛，會檢查每個訪客的包包裡裝了什麼。

WAF 可能裝在三個地方

同樣叫 WAF，裝的位置不同，能做的事差很多。一個網站可能同時有好幾層：

位置	常見例子	在哪一步擋	限制
雲端（CDN）	Cloudflare	請求還沒到主機就先擋	只能保護經過它的流量
主機伺服器	ModSecurity	請求進到主機、交給網站程式之前	由主機商管理，網站主通常無法自己調整
網站程式內	Wordfence 等資安外掛	WordPress 啟動之後	PHP 和 WordPress 都已經開始執行了

第三種的限制特別值得注意。資安外掛本身就是一支 PHP 程式，就算設定成比 WordPress 更早載入，也一定要等 PHP 開始處理請求之後才能工作。PHP2Shell 這類漏洞在 PHP 處理請求的初期就會觸發，那時候外掛根本還沒開始執行，自然擋不到。不是外掛不好，而是它站的位置太後面。

這不代表資安外掛沒用。它在登入保護、檔案掃描、偵測被竄改的程式碼這些事情上很實用，只是要知道它防的是哪一層。資安外掛的選擇與設定，在〈網站被駭怎麼辦〉有完整說明。

WAF 擋得住什麼

已知的攻擊手法

WAF 的核心是一套規則，記錄著各種已知攻擊長什麼樣子。例如在網址參數裡塞資料庫指令、在留言欄位塞惡意程式碼、針對某個外掛已知漏洞的特定請求格式。請求只要符合規則，就會被擋下。

大量的自動化攻擊

短時間內大量試登入、同一個來源瘋狂請求不存在的路徑，這些都是自動化程式的典型行為。WAF 可以限制頻率，或直接封鎖行為異常的來源。這類掃描在主機紀錄裡長什麼樣子，可以參考〈網站被攻擊了嗎？從存取紀錄分辨正常訪客、爬蟲與攻擊掃描〉。

在你更新之前先擋一陣子

這是 WAF 最有價值的一點，業界叫做「虛擬修補」。新漏洞公開時，WAF 業者可以很快寫出對應的規則部署上去，在網站真正更新之前，先把已知的攻擊方式擋在外面。這次 Cloudflare 搶在漏洞公開前部署規則，就是這個用途。

WAF 擋不住什麼

新的手法和變形

規則是根據已知的攻擊寫的。攻擊者只要換個寫法、繞過規則比對的特徵，就有機會穿過去。這就是 Cloudflare 強調「暫時性」的原因：規則可以爭取時間，但攻擊者也在找繞過的方法。

看起來完全正常的請求

如果攻擊者拿到了正確的帳號密碼，他登入的請求和你本人登入沒有任何差別，WAF 沒有理由擋。被偷的密碼、外洩的資料庫連線資訊，都不是防火牆能處理的問題。

沒有經過它的流量

雲端 WAF 只保護經過它的請求。如果攻擊者知道主機的真實 IP，直接連過去，就完全繞過了雲端那一層。這也是為什麼主機端最好也要有自己的防護，不能只靠前面那一層。

它不是修補

把以上幾點合起來，結論只有一個：WAF 是在爭取時間，修補才是解決問題。漏洞還在，防火牆就只是暫時把門擋住；更新完成，門才真正關上。PHP2Shell 那次事件中網站主該確認的事，整理在〈PHP2Shell 漏洞是什麼？用共用主機的網站該確認的 4 件事〉。

為什麼 WAF 會擋到你自己

這是很多網站主遇過、但不知道原因的狀況：在 WordPress 後台按下儲存或發佈，結果跳出「403 Forbidden」；或是頁面編輯器一直轉圈圈，怎麼樣都載入不完。網站沒壞，帳號也沒問題，就是存不進去。

原因通常就是主機的 WAF。規則比對的是「攻擊者常用的字串」，但這些字串不只攻擊者會用。如果你寫的是技術教學，文章裡難免出現程式碼範例、伺服器路徑、設定檔名稱，這些內容剛好跟攻擊特徵長得很像，WAF 分不出你是在寫教學還是在發動攻擊。

我們自己遇過的三個例子

5NET 的部落格寫的就是主機和網站技術，這種狀況我們自己也踩過好幾次：

• 網址裡帶了本機開發環境的主機名稱：一篇講網站從本機搬上主機的文章，原本的網址用了那個詞，發佈後前台直接出現 403。把網址改成不含那個詞，馬上就正常了。那篇後來的內容在〈寫好的網站怎麼上線〉。
• 頁面編輯器卡在載入中：同樣的原因，編輯器在背景送出的請求裡帶著文章內容，裡面有敏感字串，請求被擋下，畫面就一直轉圈圈。
• 內文提到設定檔的名稱：發佈當下沒事，但之後重新編輯儲存時就有被擋的風險。後來我們在不影響理解的地方，改用「設定檔」這類說法帶過。

被擋到的典型症狀

• 儲存、發佈、更新時出現 403 Forbidden
• 頁面編輯器或外掛設定頁一直轉圈，載入不完
• 只有某幾篇文章或某幾個頁面會發生，其他都正常
• 前台表單送出失敗，但只在填了某些內容時發生

最後兩點是關鍵：如果問題只跟特定內容有關，換一篇文章、換一段文字就沒事，幾乎可以確定是 WAF。

被擋到時怎麼辦

1. 先確認是不是內容觸發的

把最近新增或修改的那段內容暫時拿掉，再存一次看看。如果能存了，就代表問題在那段內容裡。程式碼範例、伺服器路徑、檔案名稱，是最常見的嫌疑犯。

2. 能改寫的就改寫

網址改用不含敏感字的英文代稱，內文的檔名改用文字描述。這是最快、也最不需要麻煩別人的做法，對讀者的理解通常也沒什麼影響。

3. 改不了的，請主機商調整規則

如果那段內容一定要保留，例如讀者需要照抄的設定值，就聯絡主機商。提供三個資訊：發生的時間、出問題的網址、你當時的 IP。主機商可以從防火牆的紀錄找出是哪一條規則擋的，針對那個路徑做例外處理。

4. 不要要求整個關掉

為了存一篇文章把整個網站的防火牆關掉，等於為了方便把大門拆了。正確的做法是針對特定規則、特定路徑開例外，其他防護照常運作。

如果你的網站在 Cloudflare 後面，Cloudflare 的控制台裡也有安全性事件的紀錄，可以先在那裡看看是不是它擋的。

用共用主機的話，該注意什麼

共用主機的網站主通常摸不到伺服器層級的設定，所以挑主機時值得問清楚：主機端有沒有 WAF、規則多久更新一次、被誤擋的時候怎麼處理。這些問題的答案，比規格表上的數字更能看出主機商的維護品質。挑主機的完整判斷標準，在〈台灣虛擬主機怎麼選〉。

主機端的防火牆、雲端的 Cloudflare、網站裡的資安外掛，三層各管各的，不是互相取代的關係。對一般中小企業網站來說，主機端有防護、網站裝一個資安外掛，就已經涵蓋大部分的情況；流量大或常被攻擊的網站，再考慮加上雲端那一層。

結語：防火牆是安全帶，不是煞車

WAF 能擋掉大量的自動化攻擊，在新漏洞剛公開、還來不及更新的那段空窗期，更是重要的緩衝。但它擋的是已知的手法，擋不住新的變形，也擋不住被偷的密碼。真正讓網站安全的，還是即時更新、定期備份和好的密碼習慣。

如果你在後台遇到莫名其妙的 403，或想知道自己的網站目前有哪幾層防護，歡迎與我們聯絡。5NET 的虛擬主機方案在伺服器端都有防火牆防護，遇到誤擋時也可以由我們協助調整。