═══ 劇團官網的凌晨垃圾信風暴：驗證碼開著，為什麼還是被打穿？ ═══

資安事件簿 · 更新於 2026.07.03 · 約 6 分鐘閱讀

一個劇團官網在凌晨被大量詐騙表單灌爆、燒光寄信額度。奇怪的是驗證碼明明開著。追查後發現：攻擊者花錢請「代解驗證碼服務」正大光明地通過。這篇記錄我們如何用多層防線把它擋下來，以及一般網站管理員能學到什麼。

──────────────────────────────

［圖片：letter, email, mail, hand, write, contact, spam, e-mails, internet, communication, digital, news, computer, networking, computer science, information, post office, transfer, envelope, network, email, spam, spam, spam, spam, spam］

凌晨，一個我們維護的劇團官方網站，像被按住喇叭一樣，把一封又一封的詐騙訊息從「聯絡我們」表單灌進管理員信箱，還順手把網站每天能寄信的免費額度一次燒光。最奇怪的是——這個表單前面明明站著一個「我不是機器人」的驗證碼。它開著，卻沒擋住。這是我們追查、踩坑、最後把它擋下來的完整經過。

◆ 本文重點

• 攻擊者透過「聯絡表單」大量灌入詐騙訊息，短時間燒光網站的寄信額度，也讓正常來信寄不出去。

• 網站其實有裝 Cloudflare Turnstile 驗證碼，但攻擊者用「代解驗證碼服務」花錢請人代解，驗證碼形同虛設。

• 真正擋下來的是「多層防線」：看內容判斷的垃圾過濾、封鎖老舊攻擊入口、在 Cloudflare 邊緣做速率限制與封鎖匿名流量。

• 最大的教訓：驗證碼只是其中一道門，不是萬能鎖。

◆ 案發：一封接一封的詐騙信

那天早上打開信箱，滿滿都是網站的表單通知。內容大同小異：一段亂碼般的名字，夾帶一條假的「匯款／獎金」詐騙連結，慫恿你點進去。單看一封是垃圾，麻煩的是——它們是「成千上百封」地湧進來。

更糟的是連鎖反應：這個網站是靠一個免費的寄信服務發信的，而免費方案每天有封數上限。垃圾表單把額度一次灌爆，結果是——真正想聯絡劇團的觀眾來信，反而卡住寄不出去。攻擊者不只製造電子垃圾，還癱瘓了網站真正的功能。

◆ 第一個謎團：驗證碼明明開著

這個聯絡表單前面，站著一個 Cloudflare Turnstile。理論上，機器人拿不到「通行證」，送出的表單會被判定失敗、不會觸發寄信。

什麼是驗證碼／Turnstile？就是那種「我不是機器人」的小方塊，用來分辨對面是真人還是自動化程式。通過後，網站會發一張看不見的「通行證」，表單要帶著這張通行證才算數。Turnstile 是 Cloudflare 出的新版本，大多數時候你甚至不用點，它在背景就驗證完了。

我們甚至試著把整個聯絡頁面改成「草稿」，想讓表單直接消失——結果垃圾訊息還是照進不誤。最後只能把整個表單外掛停用，才總算止血。這個現象很關鍵：它代表問題不只是「那個頁面」這麼單純，攻擊走的是更底層的路。

◆ 追查：日誌裡的線索

打開伺服器的存取日誌，對準凌晨那段時間，畫面很清楚：同一個表單網址，被「先載入頁面、再送出表單」成對地重複了好幾千次，每分鐘大約十次，而且每一筆的瀏覽器指紋都不一樣——手機、電腦、各種舊版瀏覽器輪番上陣，一看就是一整批殭屍在輪流敲門。

老實說，追查過程我判斷錯了兩次。一開始我以為是「驗證碼沒設定好、整個放行」；後來又懷疑是「攻擊者繞過 Cloudflare、直接打伺服器」。直到把每一筆請求「真正的來源」一筆一筆攤開來看，真相才浮現。

◆ 真相：有人「花錢請人解驗證碼」

那些請求其實都乖乖經過了 Cloudflare，真實來源大多是 Tor 匿名網路的出口節點，以及一批一次性的機房／VPN 位址——全球分散、換來換去，抓不到固定對象。而「先載入頁面、再送出」成對出現的模式，正是「解驗證碼」的標準流程：

• 先載入表單頁面，拿到一道全新的驗證題。

• 把這道題丟給網路上的「代解驗證碼服務」，換回一張有效的通行證。

• 帶著這張真通行證送出表單——於是驗證碼「合法」通過了。

換句話說：驗證碼確實有在運作，但攻擊者是「正大光明」地通過的。市面上這種代解服務，一題只要千分之幾美元；對想大量灌信的人來說，成本低到幾乎等於免費。

驗證碼不是萬靈丹。它擋得住隨手亂試的低階機器人，卻擋不住「有預算、用代解服務」的攻擊者。它是一道門，不是萬能鎖。這也是為什麼——就算把表單外掛整個換掉（例如換成另一套熱門表單），只要防線還是「單靠驗證碼」，一樣會被同一招穿過。

◆ 怎麼守住：把單一防線換成多層防線

既然「你是不是機器人」這一關被繞過，我們就改用「這則訊息本身像不像垃圾」來把關，再從裡到外疊上好幾層：

• 內容過濾當主力：改用會「讀訊息內容」判斷垃圾的機制（Akismet）。那些夾帶詐騙連結、亂碼的訊息，內容一看就有問題，直接判定為垃圾、不寄信。實測攻擊還在進行時，每一筆都被擋下，一封都沒漏出去。

• 關掉用不到的老舊入口：網站有個叫 XML-RPC 的老介面，常被拿來暴力破解和攻擊，現代網站幾乎用不到——直接封掉。

• 把真實訪客來源找回來：因為伺服器架構層層代理，後台原本只看得到自己的位址、看不到攻擊者的真實來源。修好這點，日誌和防護才有辦法對「真正的來源」動作。

• 在最外層設關卡：在 Cloudflare 對「聯絡表單」這個網址做速率限制（同一來源短時間送太多次就擋），並對 Tor／匿名流量發出額外挑戰，把噪音擋在進入網站「之前」。

藏在細節裡的幫兇：自動回覆。這個表單原本設定「一收到訊息，就自動回一封『我們已收到』給填表人」。平時很貼心，被攻擊時卻變成幫兇——等於幫攻擊者把信寄到他隨便填的任意信箱，還多燒一倍寄信額度。被攻擊時，這種「自動回覆」要特別小心。

◆ 給一般網站管理員的自保清單

• 聯絡表單一定要有「內容過濾」這一層，別只靠驗證碼。

• 寄信服務設定用量上限或警示，一被灌爆能馬上察覺。

• 用不到的老介面（例如 XML-RPC）該關就關。

• 網站若在 Cloudflare 這類服務後面，善用它的速率限制與封鎖匿名流量功能。

• 小心「自動回覆」在被攻擊時會放大災情。

• 養成定期看網站日誌的習慣，很多攻擊在爆發前就有跡象。

這次事件最大的體會是：資安沒有「裝一個東西就一勞永逸」的手段。驗證碼、防火牆、內容過濾，各自只擋一種攻擊；疊在一起，才是真正的防線。那場凌晨的垃圾信風暴，最後不是被某一招擋下的，而是被「好幾層一起」擋下的。

（本文由AI根據真實維運事件改寫，並由人工審稿，技術細節已簡化、敏感資訊已隱去，重點放在思路與可套用的原則。）

──────────────────────────────
來源：https://ethome.cc/theatre-contact-form-spam/
ethome.cc — 生活化的資安科普