工程師思路系列・事出必有因
資安
AI 助理
PHP
續篇：我們努力過了——請 AI 助理陪我探查老舊主機的真實環境
Mr. τ ｜ 風雲網通系統 ｜ 2026-10-22
昨天那篇談的是「更新不動、換機不實際、放著不管、廠商不扛」四道難題。有人問我：你說得頭頭是道，那你自己的呢？
這篇就是交代。我沒有憑印象下結論，而是請 AI 助理陪我確認一台對外主機的實際狀況。為了不替別人提供地圖，這篇刻意不寫品牌、型號、版本、位址與路徑，只談做法和結論。
一、我是怎麼做的
流程：AI 助理擬出唯讀指令，我貼到主機上執行，再把輸出貼回去讓它判讀。它自己能做的，只有從外網做最基本的連線測試，只看回應狀態。
它一度想直接遠端登入，驗證失敗後就停手，沒有重試，也沒有猜密碼。
檢查指令本身都是唯讀的。唯一的設定變動，是我為了檢查而暫時啟用了一個高權限帳號 【請確認：檢查後是否已停用並更換密碼】。
二、查到什麼
1
平台沒有修復路徑。這台機器已升到它能升的最後一版系統，而平台提供的執行環境選項，全都停在已終止支援的舊分支，沒有任何一個落在官方的修復線上。這不是我忘了更新，是平台已經沒路了。
2
PHP 實際被誰用。對外的網站只用到單一一組執行環境。同一台機器上另有少數附屬套件各自帶有執行環境，網站目錄裡也堆著多年累積的舊專案與測試檔。
3
對外曝露。網站前面有 CDN，從正式網域測試未使用的管理介面，回應是找不到。但來源主機的另一個入口上，仍有一個沒在使用的管理介面入口沒有來源限制，只要有人知道來源位址就可能連到。另外，我從外網確認有少數不該公開的檔案可以直接下載。漏洞公告逼你檢查，而檢查常常先翻出自己留下的爛攤子。【發文前請先處理這兩項，並把這段改成過去式】
4
入侵跡象。我掃描了常見的後門特徵，也檢查了使用者上傳區：沒有命中。近期被修改的程式檔，我還在確認是否都出自我自己的更新。另有少數項目因為權限問題，檢查帳號讀不到；我查了擁有者、權限和內容開頭，判斷是我自己先前測試時留下的【請確認】，網站程式本身也讀不到它。
所以「沒有發現入侵證據」只涵蓋上述這幾項，不等於「沒事」。
5
順手發現的雜物。網站程式本身落後多年；附加元件很多，我還沒逐一確認哪些有啟用、哪些仍在維護；有些檔案的權限開得過寬；網站目錄裡有開發測試殘留。這些在多數老站都很常見，建議你也逐項檢查。
三、同一台機器上別的套件呢？
給也在用類似設備的讀者：不是每個套件都共用網頁服務的 PHP。我順便查了郵件類套件：執行中的行程和相依項目裡都沒有 PHP，所以在我這台機器上看不到它們使用 PHP 的跡象。
但有些套件會自帶獨立的執行環境，改網頁服務的設定改不到它 【查完該套件的實際情況再補上，或刪掉這句】。這只代表我這台機器，你的情況請自己查。
四、今天的新情況
✔
攻擊活動變多了。據報導，雲端業者的蜜罐最早在 10/17 就觀察到攻擊嘗試，PoC 公開後嘗試快速增加。相對地，資安廠商在 10/21 的報告裡寫的是尚未獨立確認有大規模利用。兩者其實只是時間差，而且講的都是「嘗試」。我仍未看到可靠證據確認有網站被成功入侵，但風險已從「可能被利用」變成「正在被大量嘗試」，所以日誌建議至少從 10/17 起保存。
✔
設備廠商還沒有官方修補。截至目前我沒有看到官方公告或修補套件。第三方有人提出關閉某項上傳進度功能的緩解做法，但依 PHP 官方說明，這只擋部分路徑，擋不住另一個漏洞，也不是修補。【已套用／尚未套用，請依實際填寫】
✔
舊分支其實有官方原始碼向後移植。PHP 團隊為部分舊分支發布了只含這兩項修補的原始碼，但那需要自己編譯、不受設備廠商支援，其他已知漏洞仍在，分支也不會持續維護，只能爭取時間。
✔
業界的第一反應是邊緣 WAF，不是網路閘道。主要 CDN 業者在消息公開前就部署了防護，免費與付費方案都預設受到保護。資安廠商的報告也只建議檢視 WAF 的防護設定，沒有點名任何入侵防護特徵碼。
五、我的決定：不搬，也不假裝問題解決了
這台機器上的 PHP 沒有修補路徑，這一點不變。我選擇不搬遷。我知道這是風險接受，不是風險消除。 【可在此補上你不搬的原因，用你自己的話】
我的做法是分層，不靠單一一道防線：
1
前面有 CDN。擋掉一部分惡意流量。CDN 業者自己也說攻擊者一直在變形 payload，所以它只是降低風險。
2
設備防火牆的國家阻擋與放行。這裡有個要特別提醒的坑：經過 CDN 的連線，來源 IP 是 CDN 的節點，所以設備上的國家規則看不到真正的訪客。它取代不了「只允許 CDN 公布的 IP 範圍連進來源」，兩者要一起用；真正依國家阻擋，要放在 CDN 那邊。【來源是否已改成只允許 CDN 的 IP，請依實際填寫】
3
異機異地備份加快照。快照讓我能快速回復，也能拿來和攻擊前的狀態比對，看哪些檔案被動過。我會把重要的快照版本設為鎖定，避免它被輪替刪除 【依實際填寫：鎖定了哪幾份】。備份防的是「被毀」，救不回已被拿走的資料庫密碼、金鑰和郵件，這點我很清楚。
4
考慮按需開放。我考慮改成約時段開放給預約的客戶，把暴露時間從全天縮到預約時段，這比其他幾項都有效。可行的做法有：在網站前加一道身分驗證，沒通過的人，請求根本到不了主機；讓主機主動連出去，路由器就不需要對外轉發連接埠；或最簡單地，在不預約的時段把網站暫停對外。這幾個在老舊設備上能不能穩定跑，要先測試。
剩下的風險，我也寫清楚：PHP 與網站程式本身的洞還在；CDN 的規則可能被變形攻擊繞過；而這台機器還有其他服務，一旦網站層被突破，後果不只是網站。這就是我接受的部分。
六、CDN 核對清單
不管搬不搬，這份清單都適用：
1
確認 WAF 規則有開。登入 CDN 後台，找到 WAF 的受管規則，確認業者針對這次漏洞發布的規則是啟用狀態。選單名稱與方案內容以實際畫面為準。
2
只允許 CDN 的 IP 連進來源。CDN 的防護只對經過它的流量有效，有人直連你的主機 IP 就繞過了。在路由器或設備防火牆，讓網頁連接埠只接受 CDN 業者公布的 IP 範圍。設定前先想好回復方式，並確認不會把自己鎖在管理介面外；若憑證續約依賴該連接埠，也要先確認。
3
擋掉不需要的路徑。在 CDN 建規則，擋掉用不到的服務入口，以及不該被下載的檔案類型；更好的做法是直接把這些檔案移出網站目錄。
5
從外部驗證。確認用主機 IP 直連打不通，用正式網域則正常；到 CDN 的安全事件看有沒有擋到東西。
6
用快照比對。拿攻擊嘗試開始前的快照，和現在的網站目錄做唯讀比對，列出哪些檔案變了，不認識的程式檔就要查。比對的指令請 AI 助理依你的環境產生，這篇不附。
7
收尾。關掉沒在用的管理介面與入口；工作用檔案移出網站目錄；敏感設定檔的權限收緊。
要提醒的是：CDN 業者自己也說，漏洞提前外洩後，攻擊者一直在變形 payload 來繞過防護。這些只能降低風險，不是修補，也不能保證擋得住針對 PHP 本身的攻擊。
七、給想請 AI 助理做同樣事情的管理者
我相信很多管理者這幾天都會這樣做。這次的經驗，我整理成幾條：
1
密碼不要貼進對話。我這次就犯了這個錯，密碼留在對話紀錄裡。比較好的做法是建一個臨時帳號，或用金鑰驗證，檢查完就停用。
2
指令自己執行，輸出貼回去給 AI。AI 擬指令、人執行，每一步你都看得到它要做什麼。AI 想改設定或重啟服務，要等你同意。
3
指令貼壞了，AI 會被誤導。我有一條搜尋指令因為特殊符號被貼壞了，結果列出一大串誤判。AI 當場指出這份輸出不能當證據，要求重跑。工具再聰明，也要確認指令真的是你要的那條。
4
AI 會修正自己。它一度推測某項限制是空的，後來讀到實際的設定才更正。重點是它有標明「我收回這一點」，而不是默默改口。
5
要求它區分「已確認」和「未驗證」。這次最有用的是它一路標出哪些我們沒查完：讀不到的檔案、被截斷的清單。不要只看結論。
6
它的判斷不是證據。「看起來是舊遺物」「應該是某個元件的占位檔」，都要你自己用權限、時間和內容去核對。
7
別人整理的摘要也要查證。搜尋引擎的 AI 摘要列了一長串廠商動作，我逐項查證後，只有部分查得到原文。
8
檢查完要收尾。停用臨時帳號、更換密碼、關掉不需要的遠端登入。
9
檔案沒變，不代表沒被利用。攻擊者可以只讀取機密、往外連線、改資料庫，完全不動檔案。所以除了檔案比對，也要看資料庫（管理員帳號、文章內容）和外連、登入、存取紀錄。
八、下一步：給網站一個「閱覽模式」
這次討論下來，我有個比較大的想法：只負責讓人閱讀文章的網站，應該有一個預設的「閱覽模式」。像展示機有展示狀態一樣：對外只提供閱覽，不接受寫入、不跑後台；要解除，必須由人從系統之外的管道進行，網路上的程式無法自己解開。
三個條件：
1. 對外只做讀取，沒有登入、沒有後台、沒有寫入。
2. 改變狀態只能走另一條路，例如內網管理或實體管道，保護機制不能放在被保護的程式裡面。
3. 異常時往安全的方向退（退回只讀），而不是退回全開。
我評估了三種做法，目前都是「規劃中」，還沒有實測：
1
讓 CDN 擔任閱覽模式。文章頁長時間快取，來源主機平常不對外，只在發文時短暫開放。要處理的是：沒被快取的頁面會回到來源、發文後要清除快取，以及開放時段來源仍要只允許 CDN 連入。
2
把對外那一面改成靜態輸出。文章在內部寫好，輸出成純網頁檔再發佈。對外沒有 PHP、沒有資料庫、沒有後台，這類漏洞就打不到。代價是留言、站內搜尋、表單要改用外部服務或拿掉，發文多一個發佈步驟，內部那份舊系統還是要隔離。
3
內網切換唯讀。網站目錄與資料庫帳號平常只給讀取，發文時才從內網用管理帳號切換，之後切回。開關必須放在網站程式之外，而且網站帳號不能有權改它。備份和發佈輸出，可以再放進儲存設備的「寫入一次」資料夾。
這幾個想法不是我發明的，業界在別的場景早就在用，只是很少被當成「個人與小型網站的標準狀態」：
| 類型 |
做法與限制 |
| CDN 的離線快取服務 |
來源連不上時，改提供快取或存檔的舊版頁面。限制：只涵蓋部分頁面、存檔更新間隔很長、動態功能（留言、購物車）不能用，而且只在來源「連不上」時才啟動。它是備援，不是完整的閱覽模式。 |
| 靜態網站產生器 |
把內容管理系統輸出成純網頁，編輯端留在私有環境。已有多種外掛與託管服務可用。限制：動態功能要用替代方案，各工具的相容性要自己測。 |
| 容器的唯讀根檔案系統 |
雲端維運的標準做法：程式只能寫入明確掛載的資料區，其餘一律唯讀，以防惡意程式寫入。這就是「閱覽模式」在企業環境的名字。 |
| 儲存設備的寫入一次機制 |
在保存期間內，檔案不能被修改或刪除。限制：通常只有部分機型、部分檔案系統支援，且一旦啟用往往不能關閉，所以第一次要用小資料夾試。 |
要提醒的是：「閱覽模式」縮小的是攻擊面，擋的是持久化的寫入，不是漏洞本身。程式還是可能被執行，機密還是可能被讀走，所以它是其中一層，要和 CDN 防護、來源限制與備份一起用。
我的看法是：這個狀態應該是內容管理系統與儲存設備出廠就有的標準模式，用實體或獨立的管道進出，而不是每個管理者自己拼湊。這次漏洞事件，正好讓需求被看見。
九、AI 做得到什麼、做不到什麼
| 項目 |
說明 |
| 做得到 |
把分散的事實快速攤開、讀設定檔做比對、做機械式的掃描，還能提醒你漏查了什麼。 |
| 做不到 |
替我修補，也不能證明「沒事」。讀不到的檔案、要不要信任某個東西，最後還是要人判斷。 |
| 要核對 |
它的輸出一樣要核對。CVE 編號和修復版本，我都回頭對照了原文才寫進來。 |
這次學到的三件事
1. 更新網站程式 ≠ 更新 PHP。兩層分開，責任也不一定在同一個人身上。
2. 舊設備是隱形的債。它沒壞，只是沒人再為它更新，這種風險不會亮任何警示燈。
3. 漏洞公告是很好的大掃除理由。我找到最多的不是漏洞，而是多年累積的雜物。
我們努力過了：該查的查了，沒查完的標出來了，該承認的承認了（平台沒路），然後做了一個我清楚代價的選擇。你的站如果也在一台更新不動的機器上，至少先做一件事：確認它現在實際跑的是什麼，然後知道自己選了什麼，包括「放著」。
更新紀錄：2026-10-22 下午 決策改為不搬遷、縮小暴露面；加入快照、按需開放、CDN 核對清單；內容改為不指名敘述；新增「閱覽模式」評估與業界實例。2026-10-22 中午 初版。
本文僅記錄個人環境的檢查經驗，不構成專業資安建議。文中刻意不寫品牌、型號、版本、位址、帳號與檔案路徑。
參考資料
Comments