PHP 漏洞事件防護架構：防火牆前 Trellix IPS、防火牆後 Trellix NDR

為什麼只靠修補不夠

PHP2Shell 從揭露到大規模利用只花了數小時，7 天或 30 天的修補週期對關鍵對外系統已不再實際（Trellix ARC）。修補空窗主要來自三個地方：

• 修補有流程：升級 PHP 後還要重啟 PHP 與 Web 服務才會生效，正式環境通常需要測試與維護時段；代管主機則要等服務商排程。
• EOL 系統等不到修補：PHP 7.3 以前的版本官方完全不提供修補，7.4～8.1 只有原始碼回補，需要自行編譯。內嵌 PHP 的設備與第三方產品還要等原廠。
• 攻擊在揭露前就開始：誘捕系統早在揭露前 4 天就記錄到利用嘗試，因此調查範圍要回推到 10 月 17 日，而非揭露日。

官方暫時緩解措施（如關閉 session.upload_progress.enabled）只能降低風險，無法消除風險。加上漏洞是研究人員借助 AI 在存在十多年的程式碼中找到，未來同類漏洞只會更快、更多。 結論：修補仍要做，而且要更快；但在修補完成前，需要「不管漏洞叫什麼名字都有效」的網路層控制，讓沒來得及修補的主機依然被擋住、被看見。

架構總覽

所有來自網際網路的請求先經過 inline 的 Trellix IPS，已知攻擊在此丟棄；防火牆放行的流量再由核心交換器鏡像給旁路的 Trellix NDR，監看伺服器被入侵後的回連與往內網的橫向移動。

防火牆前：Trellix IPS（擋）

Trellix IPS 以 inline 方式串接在網際網路與防火牆之間，對進站 HTTP 流量比對特徵碼，命中即丟棄，攻擊請求根本到不了伺服器。這就是「虛擬修補」：在網路上補洞，而不是在每台主機上補洞。

本次事件的 IPS 特徵碼（Trellix ARC，狀態皆為已發布）

為什麼放在防火牆前

• 最早攔截：攻擊在進入內部網路前就被丟棄，防火牆、負載平衡與 Web 伺服器都不必處理惡意請求。
• 一道防線保護多台後端：所有對外 PHP 主機共用同一組規則，包含無法修補的 EOL 系統與內嵌 PHP 的設備。
• 不動伺服器、不停機：更新特徵碼即生效，不需要重啟任何服務，可在正式修補排程前先行防護。
• 看見完整攻擊面：記錄所有來自網際網路的掃描與利用嘗試，作為事件調查與 IOC 擷取的依據。

佈署注意事項

• HTTPS 檢測：多數 PHP 網站走 HTTPS，IPS 必須能看到明文才能比對特徵碼。需規劃入站 SSL 解密（匯入伺服器憑證）或調整檢測點位置，否則加密流量中的攻擊將無法辨識。
• 故障旁通：inline 設備建議搭配旁通（bypass）機制，避免設備異常時中斷對外服務。
• 先觀察後阻擋：新規則可先以偵測模式觀察誤判，確認後再切換為阻擋；本次這類高風險 RCE 規則建議盡快切換為阻擋。
• 流量雜訊較高：防火牆前會看到大量網際網路背景掃描，告警需設定閾值與彙整規則，避免淹沒值班人員。

IPS 的限制在於只能擋「已知樣態」的攻擊。攻擊者已開始輪換請求內容規避規則，因此需要第二道防線偵測漏網之魚。

防火牆後：Trellix NDR（看）

Trellix NDR 透過 TAP 或 SPAN 鏡像接收防火牆內側流量，專門看防火牆已經放行的流量裡發生了什麼：漏過 IPS 的利用請求、伺服器被入侵後的回連、Web Shell 上傳，以及往內網的橫向移動。旁路佈署不影響服務可用性。

本次事件的網路偵測規則（以 Trellix Network Security / NX 名義發布，Trellix ARC）

為什麼放在防火牆後

• 只看放行的流量：防火牆已濾掉大量背景雜訊，NDR 的告警集中在真正進到內部的連線，誤報率較低。
• 抓入侵後行為：IPS 擋的是「進來」，NDR 看的是「進來之後」。伺服器主動對外連線、下載二進位檔、DNS 異常，都是入侵成功的跡象。
• 看得到東西向流量：被入侵的 Web 伺服器若嘗試連往內網資料庫、SSH 或 RDP，NDR 能及時發現。VirusTotal 統計約 39.4 萬台 PHP 主機同時暴露 SSH、23.3 萬台暴露 MySQL（Recorded Future），顯示 Web 伺服器常是進入其他系統的跳板。
• 補應用程式日誌的盲點：成功利用時 PHP 回傳正常 HTTP 200，主機日誌可能沒有異狀，網路流量是少數留得下痕跡的地方。

本次事件 NDR 可特別關注的網路跡象

• 對外 PHP 伺服器主動連往外部 IP 下載檔案（wget、curl 抓取 ELF 二進位檔）。
• 伺服器直接查詢外部公共 DNS 解析器：Mirai Potassium 內建自己的解析器，正常 Web 伺服器應使用內部 DNS。
• 連往已公開的 C2 位址，例如 Mirai Potassium C2 134[.]199[.]154[.]64。注意此樣本的 DNS 回應經過位元組輪換，應封鎖解碼後的真實位址，而非 DNS 原始回應（原始回應是無關的大學 IP）。
• 異常大的 PHPSESSID cookie、帶 PHP_SESSION_UPLOAD_PROGRESS 的 multipart POST，以及上傳端點的 HTTP 500 突增。

攻擊來源 IP 輪換很快，IP 封鎖只能短期有效；長期應以行為偵測為主。

攻擊鏈對照：每一階段由誰處理

兩道網路防線各管一段：IPS 主擋前兩個階段，NDR 主看後三個階段；端點與關聯分析是最後的保險。

攻擊行為依據 Trellix ARC 的事件分析整理；偵測對應 MITRE ATT&CK T1190（利用對外應用程式）與 T1505.003（Web Shell）。

延伸：與端點及關聯分析串連

IPS + NDR 構成網路層的「一外一內」；若要讓偵測直接變成處置，可再往主機與 SOC 延伸。以下偵測規則皆已發布（Trellix ARC）：

Application Control：以白名單只允許核准程式執行，並對網站根目錄做寫入保護。即使攻擊穿過網路兩道防線，Mirai、Go 木馬等未核准程式也無法在受保護伺服器上執行，特別適合內容固定、又無法升級的 EOL 主機。

導入建議與盤點清單

建議依「先擋、再看、後補」的順序推進：先讓 IPS 規則生效爭取時間，再以 NDR 確認是否已有主機失守，同時排程修補。 如需協助盤點對外伺服器或規劃 IPS／NDR 佈署，歡迎聯繫紘瑒科技。

資料來源

• PHP2Shell: What defenders need to know about CVE-2026-109618 and CVE-2026-109619 — Trellix Advanced Research Center
• What We Know About php2shell — CybelAngel
• PHP2Shell Exploitation: Two Critical PHP Flaws Explained — Recorded Future
• PHP Warns of Another Unpatched RCE Risk — The Hacker News