Synology 威脅防護：能攔截什麼與無法察覺什麼
更新於 2026 年 10 月 25 日
Threat Prevention 是大多數人在決定於 Synology NAS 上架設網站時第一個選擇的套件。它部位於路由器上，擁有盾牌圖示，儀表板顯示的攻擊次數多達數百次，因此看起來就像是維護公開網站安全的守護者。我們在我們擁有的每台機器前方的 RT6600ax 上都運行它，且它確實值得擁有。然而，對於自託管網站而言，它也幾乎完全抓不到重點。
這篇 NAS 託管 101 文章將打開我們自己的路由器，讀取其中真實的一週事件，並以 PHP2Shell 作為 Threat Prevention 永遠無法察覺的攻擊範例，精確展示 Threat Prevention 在何處開始無法提供協助。
SynoPower Club點： 我曾在 Synology 技術支援團隊工作了很長一段時間，經常收到這個問題：我該開啟哪個選項才能阻止這種攻擊？這是正確的直覺，卻用錯了地方。最終讓我豁然開朗的是閱讀我們自己的事件列表，而不是功能介紹頁面。我們路由器本月記錄的每條警示都是信譽不良的 IP 地址，而不是帶有惡意載荷的請求。一旦你明白這一點，你就不會再要求 Threat Prevention 去檢查它裝在密封信封裡的流量了。
Threat Prevention 在 Synology 路由器上究竟做了什麼 #
Threat Prevention 是基於 Snort 和 Suricata 系譜構建的入侵檢測與防禦系統。它在路由器轉發封包時讀取封包，將其與特徵碼集進行比對，並記錄警示或丟棄封包。在我們的 RT6600ax 上，特徵碼來源是 ET Open（Emerging Threats 規則集的免費版本），每天上午 09:00 定時更新。
此設計衍生出三個特性，這三個特性都比介面中的任何核取方塊更重要：
- 它只能檢查路由器 轉發的封包。未經過路由引擎的流量並非檢查緩慢，而是完全不可見。
- 它只能比對它能夠 讀取的位元組。Threat Prevention 完全沒有任何 TLS 攔截功能，因此加密的載荷是完全不透明的。
- 它只能比對 他人撰寫的特徵碼。介面上只提供廠商類別供您開啟或關閉，並不支援任何由您自己編寫的規則。
這些都不是缺陷。在網路邊界建置 IPS 是合情合理且很有用的做法。錯在以為邊界就是網站遭受攻擊的地方。
Threat Prevention 與 Web 應用程式防火牆 (WAF) 的比較 #
看清差距最清晰的方法，就是把 Threat Prevention 與 Web 應用程式防火牆擺在一起，並比較它們在做出決策時分別掌握了什麼。Threat Prevention 掌握的是一個封包；而 WAF 掌握的是已解密的 HTTP 請求。
| 問題 | 路由器 IPS | 反向代理 WAF |
|---|---|---|
| 它運行 | 在路由路徑上，TLS 結束之前 | 在邊緣端，TLS 結束之後 |
| 檢查的內容 | 封包標頭與任何明文位元組 | 方法 (Method)、路徑 (Path)、標頭 (Headers)、Cookies、內文 (Body) |
| HTTPS 流量 | 不透明 | 完全可讀 |
| 可新增的規則 | 開啟或關閉廠商類別 | 您自訂的運算式，加上代管規則集 |
| 同一子網路的流量 | 完全無法察覺 | 不適用，它位於所有項目的上游 |
| 典型攔截項目 | 信譽比對、掃描、明文漏洞利用、出站命令與控制 (C2) | 隱碼攻擊 (Injection)、路徑穿越 (Traversal)、已知 CVE 請求型態、憑證填充 (Credential Stuffing)、機器人 |
這兩者並非競品。它們涵蓋同一流程的不同階段，而自託管網站對第二者（WAF）的需求遠高於第一者。我們兩者都有使用，並且對各自抱持著截然不同的期待。
解讀我們自家路由器一週內的 595 個事件 #
這是我們正式運作路由器在 2026 年 10 月 25 日的 Threat Prevention 概覽畫面。七天內記錄了 595 個惡意事件，其中 75 個屬於高嚴重性。看起來就像是一道擋住洪水的高牆。
該畫面中有兩個細節比頭條數字更有價值。第一，在「潛在威脅」下出現的裝置完全只有一台，那就是終止 TLS 且運行 MailPlus 的機器 REVERSE_MAIL。第二，是綠色勾勾旁邊的特徵碼日期。現在打開單一事件，看看實際上觸發了什麼。
分類：Misc Attack，嚴重性：中，狀態：警示，特徵碼名稱：ET CINS Active Threat Intelligence Poor Reputation IP group 24。打開規則內文，它以 alert ip 開頭，接著是一長串 IP 地址。這只是黑名單的比對。HTTP 請求的任何部分都沒有被讀取，因為根本無法讀取。我們針對第二個目的地（我們的 Virtual DSM 主機）對事件進行抽樣，發現了相同類別但群組編號不同的規則。
因此，這一週坦白的總結是：路由器辨識出了幾百個來自已知信譽不良 IP 地址的連線。這確實很有用。但這並非 Web 攻擊偵測，任何人都不應該把 595 這個數字解讀為 Web 攻擊次數。
如何透過 4 個步驟稽核 Threat Prevention #
在完全信任 Threat Prevention 之前，花十分鐘了解它在您自己的網路上實際在做什麼。以下的每個步驟都是唯讀的，不會更改任何設定。
開啟一個事件並讀取簽章內文 #
前往 Threat Prevention，接著進入「事件」，並點選任意項目。越過彩色的嚴重性標籤，查看「特徵碼規則」方塊。以 alert ip 開頭的規則僅根據位址信譽進行比對；包含 content 或 pcre 的規則則是根據封包內容 (payload) 進行比對。在您判定 Threat Prevention 正在保護什麼之前，不妨先統計看看您自己的列表中各有幾條這類規則。
檢查正在監控哪些介面 #
開啟「設定」並檢視「已監控介面」表格。系統僅會檢查在此處勾選的介面，在一般的部署情況下，這些通常是面向網際網路的介面。同一 LAN 子網路中兩台裝置之間的流量是透過交換而非路由傳輸，因此永遠不會到達檢測引擎，此頁面上的任何設定都無法改變這一點。
了解當路由器繁忙時會發生什麼事 #
在同一個面板中，請查看預設模式。「網路穩定性優先」意味著當流量超過引擎所能處理的範圍時，超出的流量會不經過濾直接通過。「安全性優先」則意味著超出的流量會被丟棄。一種選擇是「故障開放（Fail-Open）」並維持您的線路連線，另一種則是「故障關閉（Fail-Closed）」並導致您的線路中斷。請決定您真正需要的是哪一種。
嘗試新增您自己的規則 #
開啟「自訂原則」。您可以變更廠商已提供的特徵碼所對應的處理動作，並能依來源或目的地位址來限定其套用範圍。此處完全沒有任何欄位可以接收您自行撰寫的特徵碼。若您面臨的威脅更新於目前的特徵碼庫，您就會在這個畫面發現自己無從因應。
它真正發揮價值的地方 #
我們持續開啟 Threat Prevention，絕非出於迷信。它承擔了我們技術架構中其他工具無法替代的四項任務。
- 外連命令與控制 (Outbound command and control)。 這是目前最顯著的應用情境。受感染的裝置必須「回傳訊息 (call home)」，該連線必須通過路由器出去，而且很大一部分仍是明文傳輸或指向已知地址。我們的路由器在「Malware Command and Control Activity」類別中啟用了 3,498 條規則中的 3,450 條，在「Domain Observed Used for C2」類別中啟用了 7,202 條規則中的 7,157 條。
- 來自網際網路的明文協定。 我們的郵件伺服器透過埠號 25 回應，而 SMTP 在使用 STARTTLS 之前均為明文。這是真正可被檢查的流量，郵件主機經常出現在我們的事件列表中絕非巧合。
- 掃描與偵察。 通訊埠掃描 (Port sweeps) 與指紋識別 (fingerprinting) 是透過連線行為而非封包內容 (payload) 來辨識的，因此加密無法隱藏它們。
- 可視性 (Visibility)。 擁有可搜尋的記錄（載明誰嘗試連線以及其信譽評分）是非常有價值的，即使每筆紀錄都只是信譽判定。這屬於監控價值的範疇，應被視為監控效益而非防護機制。
這四點的共通之處在於，它們都不是針對網站的攻擊。
為什麼網站管理者對 Threat Prevention 抱持錯誤的期待 #
當您在 NAS 上託管網站時，請求路徑通常包含反向代理 (reverse proxy)。我們的架構如下所示，而此架構決定了一切：
- 訪客連線至 Cloudflare，它會從快取回應大部分請求，並以明文形式檢查其餘請求。
- 剩餘的流量會穿過 路由器，在此處 Threat Prevention 只會看到加密的 TLS 串流，別無其他。
- 這 反向代理 NAS 解密 (terminate) TLS 並將明文 HTTP 轉發給執行網站的機器。
- 這最後一跳 (hop) 位於 同一子網路，因此訊框會經過交換器，路由器並不在連線路徑上。
綜合上述四點，陷阱便顯而易見。請求唯一以可讀形式存在的區段是最後一跳，而這恰好是路由器無法監測的唯一區段。在路由器能夠監測的所有地方，請求都被加密了。沒有任何設定選項能解決這樣的矛盾，因此當 Threat Prevention 保持沉默時，並非它失效了，而是它在準確回報其在結構上無法讀取的流量。
這也是為什麼將 Threat Prevention 指定給特定網站無效的原因。該套件是綁定到路由器介面，而不是主機名稱 (hostnames)。它無法得知某個連線屬於您的哪一個網站，因為它根本看不到 Host 標頭。
PHP2Shell 無法在路由器端被偵測到的三個原因 #
PHP2Shell 是一對未經身份驗證的遠端執行程式碼漏洞（追蹤編號為 CVE-2026-109618 和 CVE-2026-109619），於 2026 年 10 月 20 日外洩，並於次日在上游完成修補。這正是人們希望路由器 IPS 能攔截的漏洞類型，值得具體說明為何它無法做到這一點。
首先，在路由器監控的所有區段上，流量都是經過加密的。 此漏洞利用存在於 HTTP 請求中，而 HTTP 請求只有在 TLS 解密 (terminate) 後才以明文存在，這發生在路由器的下游，位於路由器完全不經手的路徑節點。
其次，不存在可供啟用的 Threat Prevention 特徵碼。 我們在 2026 年 10 月 25 日再次檢查，未發現針對這兩個 CVE 發布的 Snort 或 Emerging Threats 規則。我們使用的來源是 ET Open（免費版本，落後於商業版本），且「自訂策略 (Self-Defined Policy)」畫面不接受自行編寫的規則。因此，即使管理者精確知道要比對什麼，也無處可新增規則。
第三，也是最根本的一點，這種攻擊沒有可供比對的有效載荷特徵 (payload shape)。 該攻擊鏈需要兩個請求。第一個請求必須迫使 PHP 耗盡其記憶體限制，導致引擎經由跳過清理程序的路徑放棄請求，並留下部分全域狀態。第二個請求則是普通的請求，正是它觸及了過期指標 (stale pointer) 並轉化為程式碼執行。
第一個請求是由它消耗多少記憶體來決定的，而不是由任何位元組序列決定的；大型上傳、龐大的 JSON 內容、深層陣列以及正則表達式中的長字串都符合此特徵。第二個請求則完全不包含任何惡意位元組。IPS 是針對單一封包與單一流量進行特徵判定，它無法建模「工作程序將受污染的狀態從一個請求帶入下一個請求」的行為，而這恰恰是此漏洞所在之處。
這也揭示了當時流行之緩解措施的局限性，即在 PHP 設定中關閉 session.upload_progress。這確實消除了一種有完整文件記錄、用來觸發第二個 CVE 的途徑，對於你真的無法套用修補程式的機器來說，這總比沒有好。但這並不是根本解決之道：記憶體耗盡並非只能透過該功能觸發，而且該設定對 CVE-2026-109618 完全沒有影響。我們僅在一台主機上將其用作臨時應急措施，並將其視為爭取時間的權宜之計，而非最終解決方案。有關我們如何完成修補的完整記錄，請參閱我們的 PHP2Shell 分析文章.
設計上的故障開放（Fail Open），以及它讓我們失去郵件的那一天 #
在你將 Threat Prevention 視為可信賴的防護控制措施之前，還有一個特性值得了解。其推薦的預設模式是網路穩定性優先模式，介面毫不委婉地說明了這意味著什麼：當流量超過處理能力時，待處理的封包將在未經過濾的情況下被繞過。另一種選擇是安全性優先模式，它會改為丟棄封包，並警告在問題解決之前連線將會不穩定。
對於家用路由器來說，這是一個合理的預設值。但這也意味著 Threat Prevention 在你最需要它強大時反而是最脆弱的，因為流量過載既是你想要過濾的對象，也是超出處理能力的原因。
我們也有另一種故障模式的記錄。在 2026 年 8 月 2 日，有人用針對 Windows PHP-CGI 漏洞（對 Linux 完全無效）的漏洞利用程式對我們的反向代理發起了 116 次攻擊。Threat Prevention 丟棄了足夠多的封包，以至於卡死自己的狀態，隨後開始拒絕它所保護的機器的對外流量。我們的郵件佇列停滯，症狀看起來完全像是 DNS 故障。重啟路由器後恢復了正常。代理伺服器的存取日誌中沒有留下任何記錄，因為根本沒有任何封包抵達代理伺服器。一場在結構上根本不可能成功的攻擊，竟透過本應阻止它的工具，依然給我們造成了服務中斷。
在看那個清單時，順便注意一下已啟用的數量。「Web 應用程式攻擊」顯示 6,010 條規則中有 5,928 條處於啟用狀態，在我們關心的其他類別中比例也類似。啟用某個類別並不代表會啟用其中的每一條規則，而且介面沒有提供任何方法讓你查看剩餘未啟用的規則是哪些。
在前端放置代理伺服器，然後將源站鎖定至該代理 #
如果你從 NAS 提供網站服務，那麼能完成路由器無法勝任工作的控制措施就是反向代理 WAF。我們使用 Cloudflare，原因在於部署位置而非品牌：TLS 在邊緣終止，因此在做出決策的瞬間，整個請求都是可讀的。方法（Method）、路徑（Path）、查詢（Query）、標頭（Headers）、Cookie 和主體（Body）都可以被規則存取與解析。
這就是為什麼 PHP2Shell 的防護是在那裡生效，而非在路由器上。當這些 CVE 爆發時，託管規則集在兩天內就為這對漏洞新增了七條規則，而且在我們完成重建自家容器之前，它們就已經在我們運行的所有四個區域（Zones）中上線生效了。Threat Prevention 的資訊來源中從未出現過對應的規則，而五天過去了，依然沒有可供安裝的公開 Snort 或 Emerging Threats 規則。
一個比選擇供應商更重要的警告：前端代理只有在無法被繞過時才有效。如果你的源站位址直接對公眾網際網路回應，任何發現該位址的人都能繞過你撰寫的每一條邊緣規則。請將源站上的連接埠 443 限制為僅允許代理伺服器的網路 IP 範圍，從供應商的端點獲取這些範圍而非硬編碼，並透過直接向其 IP 位址請求網站來驗證鎖定設定。我們更廣泛的部署設定以及此層背後的另外四個層級，詳見於 我們運行的五個防禦層.
Threat Prevention 的局限性與安全性說明 #
Threat Prevention 需要在路由器上使用外接儲存裝置，且並非所有機種都支援，因此在規劃之前請先確認您的硬體是否支援。這個引擎也是路由器運作中最繁忙的元件，在消費級機種上，它最有可能成為傳輸量的瓶頸。與其相信行銷宣傳數據，不如在開啟前後親自實測。
請將概觀畫面上的每個數字視為特徵碼（Signature）比對成功的次數，而不是已阻止的攻擊次數。這兩者在雙向上都有所不同。例如對一個根本無法攻擊成功的掃描器進行信譽紀錄會虛增總數；而平靜的一週也無法證明引擎無法解讀的 HTTPS 流量是安全的。
在 Threat Prevention 中，狀態與嚴重程度一樣重要。「自動丟棄高風險封包」僅對高風險級別起作用，因此中度嚴重程度的項目仍會被記錄並轉發。若介面顯示「警告」（Alert），代表該封包已被傳送出去。
特徵碼來源就像供應鏈一樣。ET Open 會按時程更新，但落後於商業規則集，且對於已出現數天的漏洞可能完全沒有提供規範。儀表板若顯示資料庫為最新狀態，僅代表它與特徵碼來源同步，並不代表該來源已涵蓋當前正被利用的漏洞。
這些防護都無法取代修補程式（Patching）。這裡討論的每一層防護都是在為真正修復漏洞爭取時間，也就是更新受影響的軟體。以 PHP2Shell 而言，這意味著需要新的 PHP 套件與重新建置的容器，沒有任何網路防護措施可以替代它。
最後，請克制在閱讀資安通告後開啟所有類別的衝動。像 Misc activity 這類類別包含數千條低價值的規則，大部分只會產生雜訊，並消耗有用類別所需的處理能力。一份安靜、經過良好調校且您會真正去閱讀的事件列表，遠勝過一份您最後選擇無視的嘈雜列表。
經常問的問題 #
Threat Prevention 能保護架設在我 NAS 上的網站嗎？ #
幾乎不行，而且運作方式並非如其名稱所暗示。網站是透過 HTTPS 提供服務，而 Threat Prevention 並不會執行 TLS 攔截，因此在路由器能接收到的範圍內，請求內容都是不透明（加密）的。在典型的設定下，請求只有在反向代理 (reverse proxy) 終止 TLS 後才會變為可讀取，而該跳躍點 (hop) 通常位於同一個子網路中，因此它是透過交換 (switched) 而非路由 (routed) 傳送，路由器根本不會處理到此流量。請為網站改用反向代理 WAF，並讓 Threat Prevention 專注於它所擅長的功能。
我應該開啟哪個選項來阻擋特定的 CVE？ #
通常沒有，因為答案取決於廠商是否已為其提供特徵碼。開啟 Self-Defined Policy（自訂策略），您會發現您可以變更現有特徵碼的處理動作，但無法新增您自己的特徵碼。如果資料庫中不存在任何規則，就沒有可以啟用的內容，而對於才出現幾天的漏洞來說，這是正常情況。
為什麼我的事件清單只列出一個或兩個裝置？ #
因為這些是接收該引擎實際上能夠讀取之流量的裝置。在我們的網路中，這一直是郵件伺服器，它會在連接埠 25 上回應明文 SMTP。位於反向代理後方的 Web 主機產生的紀錄較少，並不是因為它受到的攻擊較少，而是因為在路由器檢查的每一個點上，其流量都已進行加密。
Threat Prevention 會檢查我的 LAN 內裝置之間的流量嗎？ #
否。同一子網路中的兩台裝置是透過交換器互相通訊，而路由器不在該路徑上，因此封包永遠不會傳送到檢查引擎。「設定」中的「監控的介面」表格顯示了實際的監控範圍，且那裡沒有任何選項可以將其擴展至同一子網路的流量。
保持啟用 Threat Prevention 安全嗎？ #
是的，但有一個值得注意的警告事項。建議的預設模式會在引擎過載時讓流量未經過濾直接通過，這樣可以確保網路不中斷，代價則是犧牲了檢查。相反的模式則會直接丟棄這些流量。我們也曾遇過引擎在一堆無害的漏洞攻擊嘗試下卡死，並開始拒絕伺服器的對外流量，導致我們的郵件服務中斷，因此當某台機器無預警失去回應時，請把路由器列入排查名單中。
Threat Prevention 對 PHP2Shell 有任何幫助嗎？ #
不行，而且光是三個獨立原因中的任何一個就已足夠。在路由器能檢查到的所有地方，流量都經過加密；這兩個 CVE 均未發布 Snort 或 Emerging Threats 的特徵碼；且該漏洞利用沒有可供比對的 payload 特徵，因為第一個請求是由它所消耗的記憶體來定義，而第二個請求看起來完全正常。修復方法是更新 PHP 套件，過渡期間則由反向代理 WAF 來填補安全空窗。
在無法修補的主機上停用 session.upload_progress 是否足夠？ #
這有幫助，但還不夠。將其關閉可消除已記載的 CVE-2026-109619 攻擊途徑之一，對於您確實無法更新的主機來說值得一做；但記憶體耗盡仍可透過其他方式引發，且該設定對 CVE-2026-109618 完全不起作用。請將此視為爭取緩衝時間的權宜之計，並儘速規劃套件更新。
對於以 NAS 託管的網站，我應該先購買或設定什麼？ #
在網站前端部署帶有託管規則集的反向代理，然後限制來源端，使 Port 443 僅回應該代理網路。這兩個步驟結合在一起，可將檢查點移至能讀取請求的位置，並消除會使其失效的繞過途徑。之後請保持 Threat Prevention 啟用，用於處理對外連線的命令與控制（command and control）及明文服務，這才是它真正發揮作用之處。
參考資料和影片教程 #
上述所有內容的原始資料來源，以及三個值得抽空閱讀的教學指南。
- Synology 知識中心：Threat Prevention 涵蓋需求、模式與機種支援。
- Synology-SA-26:14 列出了 DSM 已修復的 PHP 套件版本，包含 7.4 版本。
- Synology 關於 PHP2Shell 的聲明 指出了受影響的套件以及需要手動更新的套件。
- Cloudflare WAF 託管規則 解釋託管規則集如何進行版本控制與部署。
- Cloudflare IP 位址範圍 是在將來源鎖定至代理伺服器而非寫死 IP 位址時需要參考的端點。