RustDesk 主控台出現不明裝置？請先調查再說

在 RustDesk 主控台中看到不熟悉的裝置，光憑這一點還不足以判斷成因。防毒軟體沙箱測試是已知的可能原因之一，但相同的現象也可能源自設定外洩、未經授權的註冊、權杖外流，或部署過程中的疏失。

簡短回答

部分防毒軟體（AV）或端點偵測與回應（EDR）產品，會在雲端沙箱環境中執行不熟悉的執行檔。如果沙箱收到的用戶端組建版本中包含您的伺服器設定，且能夠連線到 ID 伺服器，就可能出現短暫的註冊紀錄。然而，雲端服務供應商的 IP 位址或不尋常的硬體名稱，並不能證明就是這個原因——攻擊者同樣也會使用雲端主機。在排除這起事件之前，請務必先保留並檢視相關證據。

詳細說明

發生原因

RustDesk 用戶端在執行時，只要能夠連線到已設定的 ID／集合（rendezvous）伺服器，就會進行註冊。這使得沙箱執行成為一個合理的可能原因，正如公開的 GitHub 討論串 中所提到的；但這同時也意味著，任何取得已設定用戶端或有效部署素材的人，都可能產生類似的註冊紀錄。

在對這起事件下結論之前，請先檢視伺服器的註冊與連線日誌、該裝置的首次出現時間與來源 IP、部署紀錄，以及自訂用戶端的散布途徑。視情況更換可能外洩的密碼、API／部署權杖，以及伺服器設定或金鑰。同時檢查相同憑證是否曾在其他地方被重複使用，並確認該不明裝置是否曾嘗試或完成任何連線工作階段。

如何阻止此情況

主控台中有兩項設定可以解決這個問題，選擇哪一項則取決於您是否仍在持續導入真正的新裝置。

選項一——完全停用新裝置註冊。 如果您的裝置清單基本上已經穩定，不需要經常新增機器，這是最簡單的解決方式：前往**「設定 → 其他 → 在網頁主控台停用新裝置」**。設定後，不論是沙箱測試還是其他來源，都無法再註冊任何新裝置。

選項二——要求使用部署權杖。 如果您仍在持續導入新裝置（例如 MSP 為客戶進行導入，或 IT 團隊為新機器製作映像檔），一律「停用新裝置」的設定反而會妨礙自己的作業。這時應改為啟用**「設定 → 其他 → 要求新裝置進行部署」**，建立一個 API 權杖（Devices 權限，設為讀取與寫入），並讓安裝流程在每台裝置上執行文件中說明的部署指令：

rustdesk --deploy --token <api_token>

確切的參數可能會隨版本更新而變動，因此請將此視為示意用法，在撰寫指令碼之前，務必到 RustDesk Server Pro 文件中確認目前的正確語法。只有提供有效權杖的裝置才會被加入您的裝置清單。沙箱測試的防毒掃描由於無從得知也無法提供該權杖，因此註冊會失敗，而您真正的部署作業則能照常進行。這也是 MSP 用來透過 RMM 或指令碼化安裝導入裝置的機制，不需要技術人員親自在每台機器上登入。

另一項相關但範圍較小的控制項： 如果您希望保留開放註冊的狀態，只是想在檢視之前，先讓未指派的裝置不會出現在一般使用者眼前，也可以使用**「設定 → 其他 → 僅管理員可存取未指派的裝置」**——這項設定不會阻止註冊，但可以確保一般使用者在您有機會檢視之前，看不到也無法碰觸任何新出現的裝置。

如何評估結果

單憑註冊紀錄本身，並不能證明攻擊者控制了另一台端點，但在原因未釐清之前，仍應視為未經授權的活動。如果某筆註冊紀錄存在時間短暫，且與已知的資安掃描時間吻合，之後也沒有任何後續存取紀錄，這樣的情況較能支持沙箱測試的假設。但若出現非預期的連線工作階段、重複註冊、使用有效憑證，或是已設定好的用戶端被散布到非預期的管道，就需要啟動事件應變處理。

誰會遇到這個問題

無論是 IT 管理員還是 MSP，新伺服器維運人員通常會在建置自架伺服器後的幾天內──也就是在收緊註冊控管之前──遇到這個問題。及早調查非常重要，因為無害的掃描行為與未經授權的註冊，在主控台中看起來可能相當類似。

相關問題

• 產生具品牌客製化的用戶端：請參閱 RustDesk 文件。
• 在 RustDesk 中，什麼樣的裝置才算是受管理裝置？
• 查看目前的 RustDesk 版本與安全性修補內容
• RustDesk for MSPs：一套可自架、可自訂品牌的工具 看到不認識的裝置嗎？請先保留相關日誌、限制新裝置註冊、更換任何可能外洩的機密資訊；如果原因仍不明確，可提供非敏感的診斷資訊，聯絡 RustDesk 支援團隊協助排查。