使用 Clawdbot (現稱Moltbot) 安全嗎?

AI資訊

使用 Clawdbot (現稱Moltbot) 安全嗎?

使用 Clawdbot (現稱Moltbot) 安全與否，關鍵不在「工具本身安不安全」，而在「你怎樣部署和給了它多少權限」。若設定不當，它可以非常危險；若做對幾個關鍵步驟，它又能比傳統雲端 AI 更有隱私保障。

 

為什麼大家開始擔心 Clawdbot 的資安？

Clawdbot 一爆紅，很快就被資安研究員與安全公司點名，原因是：很多人把它「裝錯、開太大」。研究顯示，已有數百個 Clawdbot 網關（Gateway）實例直接暴露在網路上，沒有做妥善驗證或防護。

• 資安研究員發現，多個 Clawdbot 控制介面直接公開在網路上，任何人只要掃到 IP 就能打開管理頁。

• 在這些暴露實例中，攻擊者可以看到完整設定檔，包括 API Key、OAuth 憑證、各種聊天平台的 Token。

• 更嚴重的是，這些實例通常同時握有 Slack、Telegram、Signal、Discord、WhatsApp 等平台長期對話紀錄，等於把自己所有私訊集中放在一個沒上鎖的房間。

安全公司與慢霧等機構因此發出警告：Clawdbot 類的 AI 代理，因為同時掌握「憑證 + 對話 + 系統執行權 + 長期記憶」，一旦網關被打開，就是單點重大風險。

 

目前已出現什麼類型的風險案例？

公開報導提到幾類已經發生的實際風險情境。

• 管理介面裸露：因反向代理（Nginx、Caddy）設定錯誤，所有外部流量被當成本機 127.0.0.1，繞過身分驗證，讓任何人都能直接進入控制面板。

• API 金鑰外洩：攻擊者在控制台直接看到 OpenAI、Anthropic、雲端服務、Google OAuth 等金鑰，得手後可長期濫用這些資源或進一步入侵其他服務。

• 私訊與對話記錄被看光：研究指出，有實例暴露了跨 Slack、Telegram、Signal、Discord、WhatsApp 數月對話紀錄，包含工作機密與個人隱私。

• Root 權限與遠端指令：由於 Clawdbot 為了「能做事」常被給予高權限，攻擊者一旦登入即可用 Root 身份執行 Shell 命令、讀寫檔案，甚至關機或刪除資料。

• 加密錢包被清空：有用戶把加密貨幣錢包也放在同一台機器，攻擊者取得系統權限後直接操作錢包，資產被洗走，證明這已不是理論風險。​

這些事件有一個共通點：多數不是「程式碼零日漏洞」，而是「部署方式錯誤 + 權限給太大」，讓本來安全設計被完全繞開。

 

Clawdbot 本身有哪些安全優點？

雖然事故不少，但如果回到設計初衷，Clawdbot 其實具備幾個安全上的正向特質，只是必須配合正確部署才能發揮。

• 本地運行：預設是跑在你自己的機器，不像雲端 AI 把資料送到第三方伺服器，理論上資料主權回到用戶手上。

• 加密與認證機制：官方設計有加密通道與身分驗證，只是很多人用反向代理時沒正確設置「可信來源」，導致機制失效。

• 可控權限範圍：文件與社群都建議用沙箱、白名單等方式限制可操作的資料夾與系統指令，而不是一開始就給 Root 全開。

• 社群快速修補：資安研究員披露問題後，開發者與社群會更新文件、加上預警與修補建議，算是開源專案的優勢之一。

所以，工具本身並非「天生不安全」，真正的關鍵是：你有沒有把它當成一個高風險、有超高權限的「伺服器」來對待。

 

一般使用者要注意的安全紅線

如果你只是個人使用，想在自己電腦上玩 Clawdbot，有幾條「不要犯」的紅線，可以大幅降低風險。

• 不要把 Gateway 直接暴露到公網
  避免把控制介面直接綁定 0.0.0.0 或開在公用 IP 上，應維持只綁定 localhost，外部連線一律透過安全隧道（如 SSH port forwarding）。

• 不要在同一台機器放關鍵資產
  避免與加密貨幣錢包、網銀憑證、公司核心資料放在同一台、同一層級權限的裝置上。若要長期開機，考慮用一台專門裝置（如獨立 Mac mini）。

• 不要給無限 Root + 無沙箱
  能用一般用戶權限就不用 Root，檔案系統權限設白名單資料夾，不要讓它「看遍整顆硬碟」。Docker 或虛擬機沙箱是更保險的選擇。

• 不要把所有帳號都綁到同一個 Clawdbot
  減少單點風險，至少不要把個人金融帳號和公司內網權限全部交給同一實例。可以分成「工作用」與「個人用」兩個環境。

• 不要忽略日誌與異常行為
  定期檢查 Clawdbot 的執行紀錄與系統日誌，發現不明操作、陌生 IP 或詭異指令時，立即停機與更換所有金鑰。

如果你已經跑了 Clawdbot，又不確定當初怎麼設的，建議立刻檢查是否有任何對外開放的控制介面與反向代理配置。

 

如何在「可用」與「安全」之間取得平衡？

對多數人來說，理想狀態是：既能享受 24/7 自動化，又不把自己所有的數位資產暴露在風險中。可以參考資安與技術社群總結的幾個折衷做法。

• 單機本地使用 + 不對外開放
  最簡單的安全方案：把 Clawdbot 當成「只有你自己能連上的本地工具」，只透過家用網路或本機聊天客戶端使用。

• 使用 SSH 隧道取代直接開放 HTTP 端口
  需要遠端控制時，不是把管理介面開在公網，而是先 SSH 進機器，再透過本機轉發端口訪問控制台。

• 把最危險的權限拆出去
  不在 Clawdbot 裡放錢包私鑰、公司最高權限帳號等，而是改用更嚴格工具手動操作，只讓 Clawdbot 負責「風險較低、可替代」的工作。

• 定期輪換 API Key 與憑證
  即使不覺得自己被駭，也應定期更換金鑰，把潛在風險壓縮在較短時間內。

• 接受它「不是零風險」
  只要有一個軟體同時握有你的一堆帳號、檔案與執行權限，就注定不可能完全零風險。真正的作法是：明確劃出「能交給它做的事」與「永遠不交給它做的事」。

 

綜合來看，「使用 Clawdbot 安全嗎？」這個問題的答案是：設得好，它可以比把所有東西丟給雲端更安全；設得差，它就會是你系統裡最大的單一破口。

 

 

安全部署參考指南

對於企業或高風險用戶，建議採用以下「零信任架構」：

 

基礎層：隔離環境

# Docker沙箱部署（強制推薦）
docker run -d
  --name clawdbot
  --network=container:nginx
  -v /opt/clawdbot/data:/data
  clawdbot:latest
 

網路層：嚴格防火牆

# 只開放SSH，禁用所有HTTP端口
ufw deny 8080
ufw deny 3000
ufw allow 22/tcp
ufw enable
 

權限層：最小授權原則

# 創建專用低權限用戶
useradd -r -s /bin/false clawdbot
chown -R clawdbot:clawdbot /opt/clawdbot
# 只讀取指定資料夾
SKILLS.md: allow_paths: ["/home/user/documents", "/tmp"]
 

憑證層：旋轉與隔離

# 定期90天旋轉所有API Key
# 建立專用低額度帳號，不共用主帳號
# 使用臨時憑證而非長期Token
 

監控層：即時告警

# 整合ELK日誌分析
# Sentry錯誤追蹤
# 異常指令告警（rm, wget, curl等）
 

個人用戶安全實踐清單（10項必做）

網路隔離：絕不直接暴露8080端口，使用SSH隧道
權限降級：改用一般用戶，不要Root/sudo
資料隔離：獨立硬碟分區，勿與重要檔案共存
白名單限制：只允許操作特定資料夾與指令
定期檢查：每月驗證無公網暴露端口
金鑰隔離：建立專用低額度API帳號
日誌審計：每周檢查執行紀錄
備份策略：重要資料異地備份
緊急斷線：發現異常立即systemctl stop clawdbot
社群驗證：只用ClawdHub審核通過的Skills

 

風險權衡決策矩陣

高風險場景（強烈不建議）：
├── 公網部署無防火牆
├── Root權限 + 加密錢包
├── 企業核心資料直接授權
└── 多用戶共享單一實例

中風險場景（需嚴格控管）：
├── 家用網路部署
├── 個人文件/郵件授權
├── 低風險自動化任務
└── 定期安全審計

低風險場景（安全推薦）：
├── 本地單機使用
├── 只讀權限任務
├── Docker沙箱隔離
└── 定期金鑰旋轉
 

結論：強大工具需要相應責任

Clawdbot不是「即插即用玩具」，而是「高權限系統管理員」。它能帶來生產力爆炸性提升，但前提是你願意花時間理解並嚴格執行安全措施。

安全使用 Clawdbot 的三個心法：

1. 永不方便於安全：任何犧牲安全換取便利的配置都是自掘墳墓

2. 最小必要權限：能不用就不用，絕不預先授權高風險操作

3. 假設已被入侵：從一開始就按最高安全標準部署，而非事後修補

對一般用戶來說，最安全的方案可能是「單機本地使用 + Docker沙箱 + 定期檢查」，享受80%功能同時控制90%風險。對企業來說，則應評估是否真的需要如此高風險高報酬的工具，或者先從低風險場景開始POC測試。

 

歡迎查看/報讀 「OpenClaw (前稱 Clawbot / Moltbot) AI教學課程」!