因應 Tailworm：在不影響正式環境的前提下強化我們的 Tailscale 網路

我們如何對照 Tailworm 的發現檢查自己的 Tailscale 網路，移除 Tailscale SSH 暴露面，同時讓所有正式環境作業持續運作。

摘要

2026 年 10 月 25 日，一位資安研究人員發布了「Tailworm」：針對 Tailscale 與 headscale 的 11 項發現，且未經協調揭露（coordinated disclosure）。截至撰文時，Tailscale 尚未發布修正。當天晚上，我們便對照每一項發現檢查了自己的 Tailscale 網路。我們移除了唯一一項與我們相關的暴露面，收緊了存取權限，期間所有正式環境作業都持續運作。

本文說明我們檢查了什麼、變更了什麼、如何避免服務中斷，以及我們學到了什麼。本文並非對該報告的獨立驗證。

Tailworm 報告內容簡述

這 11 項發現大致可分為以下幾類：

• Tailscale SSH（最嚴重）。經授權的 SSH 工作階段可以提權為目標機器上的 root。在研究人員的實驗環境中，攻擊隨後在機器之間擴散。
• App connectors。未驗證目的地（destination）。
• 記憶體耗盡，發生在控制伺服器與用戶端。
• Serve 與 Funnel 的邊界情況。

每一項發現都需要攻擊者事先已有立足點，沒有任何一項是可直接從網際網路發動的遠端攻擊。部分資安從業人員認為報告的說法誇大了風險，但主要的暴露面 Tailscale SSH 確實存在，而且很容易移除。

步驟 1：先檢查，再變更

我們從唯讀檢查開始，並在變更任何東西之前記錄結果：

• 使用中的 Tailscale 用戶端版本
• 實際啟用了哪些功能
• 60 天的 SSH 工作階段記錄，查看誰從哪裡連線，以及是否有人使用連接埠或通訊端轉送
• 裝置清單，包括數個月未上線的裝置

檢查結果：

• 我們的部分環境啟用了 Tailscale SSH，因此發現 F1–F3 與 F5 與我們相關。
• 其他發現所依賴的功能我們並未使用，因此大多數不適用。
• SSH 記錄中沒有預期外的來源，也沒有轉送請求。

步驟 2：在不中斷服務的情況下移除暴露面

最直接的做法是關閉 Tailscale SSH，改用標準的 OpenSSH 金鑰驗證。但事前檢查發現了一個陷阱。

Tailscale SSH 是以 tailnet 身分進行驗證，而不是 SSH 金鑰。我們的自動化指令碼在命令列中指定了一把 SSH 金鑰，但該金鑰受密語保護，根本不可能在無人值守的情況下運作。這些作業之所以能執行，只是因為 Tailscale SSH 從不檢查金鑰。如果我們直接關閉 Tailscale SSH，所有自動化作業都會停擺。

因此，我們依照以下順序進行切換：

1. 建立自動化專用金鑰，僅允許來自單一來源機器，並停用轉送。
2. 在切換前測試新路徑。我們開啟一個僅能從 tailnet 內部連線的暫時 OpenSSH 連接埠，並在與作業執行環境相同的條件下（無 SSH 代理程式、無終端機），以指令碼呼叫 SSH 的每一種方式進行連線。
3. 執行反向測試。確認新金鑰在允許的來源之外會被拒絕，轉送請求也會被拒絕。
4. 先設定好自動復原。在關閉 Tailscale SSH 之前，我們排定了一個計時器，時間一到會自動重新啟用它。這條復原路徑不依賴 SSH 是否正常。
5. 切換後，以新連線逐一檢查所有自動化作業。每個作業都實際完成了一次執行。我們不把已開啟的工作階段當作證明。
6. 移除暫時性設定——額外的連接埠、防火牆規則和復原計時器——並再次驗證。

步驟 3：收緊其餘部分

• 清空 Tailscale SSH 原則。預設原則允許使用者從自己的任何裝置對自己的其他裝置開啟 SSH 工作階段（包括以 root 身分），只需每週在瀏覽器中重新核准一次。我們清空了該原則，因此即使不小心重新啟用 Tailscale SSH，也不會再授予存取權。
• 關閉來自網際網路的 SSH。關閉之前，我們確認了頻外（out-of-band）主控台登入可用，以免把自己鎖在外面。之後我們從外部網路驗證 SSH 已不再回應。
• 要求裝置核准。新裝置必須經管理員核准才能加入。
• 檢查註冊金鑰。沒有需要撤銷的金鑰。
• 確認管理員帳戶已啟用 MFA。任何接管管理員登入的人都能撤銷網路層級的控制措施。
• 開始觀察裝置之間的實際流量，讓下一步——縮小哪些裝置可以存取哪些服務——是根據證據而非猜測。

Tailnet Lock 與裝置核准都能防止惡意裝置加入，但兩者無法同時使用，請審慎地擇一。

步驟 4：不只修正伺服器，也要修正作業手冊

我們舊的復原程序要求在啟用 Tailscale SSH 的情況下重新連接伺服器。若在這次變更後照做，就會在不知不覺中讓這項有風險的功能重新回來。我們重寫了程序：

• 先診斷。是網路連線中斷，還是 SSH 本身（金鑰、設定、防火牆）出了問題？兩者的修正方式不同。
• 重新連線時不變更設定。不加任何額外參數，重新連線前先儲存節點設定，連線後再比對。
• 緊急存取只在計時器控制下開放。先取得核准，開放前排定自動關閉，限制來源，並同時檢查 IPv4 與 IPv6。
• 即使在緊急情況下也不重新啟用 Tailscale SSH。它所需的存取原則變更無法自動復原。

我們學到的事

1. 移除安全功能之前，先弄清楚它實際驗證的是什麼。我們指令碼中指定的金鑰從未被使用過。
2. 測試你要轉移過去的那條路徑本身，在作業實際執行的相同環境中，於切換之前完成。
3. 設定一個不依賴變更對象的復原機制。用計時器，而不是「我們再 SSH 進去修就好」。
4. 關門之前，先確認復原用的存取途徑。我們在關閉來自網際網路的 SSH 之前，先確認了主控台存取。
5. 在同一次變更中更新作業手冊。過時的復原步驟可能在幾個月後撤銷一項安全修正。
6. 閱讀預設原則。「允許自己的裝置互相存取，包括 root」正是我們一開始的預設設定。
7. 將「變更成功」與「弱點已解決」區分開來。我們已不再受 Tailscale SSH 相關發現影響，但在上游修正發布之前，Tailworm 整體仍未解決。修正發布後我們會更新用戶端。
8. 先量測，再收緊。先掌握觀察到的流量與實際相依性清單，再訂定更嚴格的存取規則，強化措施才不會影響業務。

下一步

我們正依據觀察到的流量，將裝置之間的網路存取縮小到每項服務所需的最小範圍。Tailscale 的修正一旦發布，我們會立即安裝。

參考資料：Tailworm 報告（tailworm.com）以及 Tailscale 關於 Tailnet Lock 的文件。