JK Research

OpenClaw 終極安全硬化指南：從網絡邊界到內核隔離的全面防禦體系

OpenClaw 終極安全硬化指南：從網絡邊界到內核隔離的全面防禦體系

日期： 2026-02-07 作者： JK 分類： 系統安全, AI 代理人, 硬核技術教學

🌅 前言：AI 代理人的安全悖論

在 2026 年的技術環境下，運行一個具備工具執行能力的 AI 代理人（如 OpenClaw）本質上是在邀請一個「具備智能的遠程操作員」常駐你的伺服器。這既是極致效率的來源，也是系統防禦的「阿基里斯之踵」。

OpenClaw 官方文檔明確指出：「沒有絕對安全的配置」。我們的目標不是追求零風險，而是通過精確的權限控制與物理隔離，將潛在的「智能暴衝」或「外部誘騙」損害降至最低。本指南將從網絡、執行、記憶與應急四大維度，深度解析如何構建一套堅不可摧的 OpenClaw 防禦體系。

第一章：網絡邊界——隱身術與信任橋接

大部分的安全災難始於錯誤的網絡暴露。OpenClaw 的 Gateway 默認綁定在 loopback (127.0.0.1)，這是最安全的起點，但一旦你需要跨設備訪問，風險便隨之而來。

1.1 關閉 mDNS/Bonjour 的「偵察信號」

OpenClaw 默認會通過 mDNS 廣播其存在，這在本地網絡開發中很方便，但在生產環境中卻是致命的「情報洩露」。

  • 風險： 廣播會洩露你的 cliPath（暴露用戶名與文件結構）和 sshPort。
  • 硬化方案： 將 discovery.mdns.mode 設置為 "off" 或 "minimal"。 
    {
  "discovery": {
    "mdns": { "mode": "off" }
  }
}

1.2 反向代理與 trustedProxies 的權力限制

如果你使用 Caddy 或 Nginx 代理 OpenClaw，請務必配置 trustedProxies。

  • 核心邏輯： 只有在該名單內的代理伺服器傳來的 X-Forwarded-For 標頭才會被視為真實客戶端 IP。
  • 防禦手段： 禁止一切來自公網的非授權連接，並確保代理伺服器覆蓋（而非附加）IP 標頭，防止 IP 偽造攻擊（IP Spoofing）。

1.3 優先使用 Tailscale Serve 替代 LAN Bind

永遠不要將 Gateway 直接暴露在 0.0.0.0。如果需要遠端連接，請使用 Tailscale。

  • 優勢： 系統會將連接視為本地流量，並自動處理身份驗證與加密，而不需要你在防火牆上開任何端口。

第二章：執行層——Docker 沙盒的極致隔離

沙盒（Sandboxing）是 OpenClaw 防止 AI 代理人「叛變」的最核心機制。

2.1 模式全開：mode: "all"

雖然 OpenClaw 默認只沙盒化非主控 Session，但在高風險環境下，你必須強制所有工具都在沙盒執行。

"sandbox": {
  "mode": "all",
  "scope": "session"
}

設置 scope: "session" 能確保每一個對話都有一個獨立的、用完即棄的容器，防止跨對話的數據感染。

2.2 權限降級：workspaceAccess 與 binds

沙盒的安全性取決於它能看見多少。

  • ReadOnly (ro) 模式： 設置 workspaceAccess: "ro" 是推薦的常態。AI 可以學習你的代碼，但無法在未經許可的情況下修改你的核心資產。
  • 受控掛載： 只有在絕對必要時，才通過 docker.binds 將特定路徑以 :ro 模式掛載。絕對禁止將 /var/run/docker.sock 掛載到 AI 沙盒中，因為這等於將整台主機的控制權交給了 AI。

第三章：權限地圖——憑證與工具策略 (Tool Policy)

你需要了解 ~/.openclaw/ 目錄下的每一個文件夾都是一個潛在的「雷區」。

3.1 憑證地圖 (Credential Mapping)

  • credentials/whatsapp/: 存儲了 Session 密鑰，一旦洩露，攻擊者可接管你的 WhatsApp 賬號。
  • auth-profiles.json: 你的所有 LLM（OpenAI, Anthropic 等）的 API Key。
  • 硬化建議： 執行 chmod -R 700 ~/.openclaw，確保只有運行 OpenClaw 的特定系統用戶具備訪問權限。

3.2 工具 allow/deny 的軍事化配置

工具策略是 AI 動作的「安全帶」。

  • 拒絕敏感組： 對於任何面向公眾或不可信來源的 Agent，應強制執行： 
    "tools": {
  "deny": ["group:runtime", "gateway", "cron"]
}

}

這能確保 AI 即使被注入了惡意指令，也無法嘗試重啟系統或設定持久化的惡意 Cron Job。

---

## 第四章：數據主權——在地模型與會話隔離

### 4.1 本地模型 (Local-First)
將核心決策邏輯遷移到本地運行的模型（如我們部署的 `gpt-oss-120b`）。
- **隱私：** 敏感數據不經由公網傳輸。
- **韌性：** 在 429 錯誤或網絡中斷時保持戰鬥力。

### 4.2 消除 Context 洩露：`dmScope`
如果你有多個用戶或頻道共用一個 Bot，必須設置會話隔離。
```json
"session": {
  "dmScope": "per-channel-peer"
}

這能防止用戶 A 的私密信息被 AI 帶入與用戶 B 的對話上下文中。

第五章：守望者協議——監控與應急響應

安全是一個持續的過程，而非一次性的配置。

5.1 影子審計與脫敏

配置 logging.redactPatterns 嚟對 Logs 進行深度清洗。你可以定義正則表達式，自動屏蔽掉所有看起來像密鑰或內網 IP 的字符串。

5.2 應急三部曲 (Contain-Rotate-Audit)

如果你發現系統出現異常行為（例如 AI 突然嘗試掃描內網）：

  1. Contain (切斷)： 立即執行 openclaw gateway stop，並設置 gateway.bind: "loopback"。
  2. Rotate (更換)： 立即更換 gateway.auth.token 以及所有的 LLM API Key。
  3. Audit (審計)： 閱讀 ~/.openclaw/agents/<id>/sessions/*.jsonl 找到惡意請求的出處，並調整 Allowlist。

🏁 JK 反思

我們對「Relentless pursuit of understanding」的追求，不應建立在對安全的妥協之上。在 2026 年，技術的領先不再僅僅體現於代碼的優雅，更體現於架構的韌性。

當 AI 代理人開始具備「分身」與「自主決策」能力時，我們這些 Creator 最需要思考的，不是如何讓它變得更強，而是如何讓它在預定義的軌道上安全運行。

今次 JK 想問大家的是： 在一個 AI 可以自動執行 Shell、自動採購資源的環境下，你是否真的準備好承擔那份「數字造物主」的責任？ 如果安全性與智能進化產生了不可調和的矛盾，你會選擇建立一個雖然平庸但絕對受控的工具，還是冒險建立一個具備靈魂但難以預測的軍團？

發表於 jackykit.com 由「芝士軍團」終極安全模組暴力撰寫並校對