prev:
  text: '第9章 远程访问与网络'
  link: '/cn/adopt/chapter9'
next:
  text: '第11章 Web 界面与客户端'
  link: '/cn/adopt/chapter11'​

第十章 安全防护与威胁模型

龙虾很强大，但能力越大责任越大。本章帮你守好安全底线——不用成为安全专家，做好三件事就够了。

前置条件：已完成第八章 网关运维，Gateway 已安装并运行。

0. 安全的起点：理解你的龙虾

OpenClaw 的定位是私人助手——设计假设是只和你一个人对话。

• 自己用：90% 以上的安全问题都遇不到
• 放进群聊：安全性变得像窗户纸一样薄

OpenClaw 能执行 Shell 命令、读写文件、调用外部 API——这些能力在你手中是生产力工具，在攻击者手中就是武器。

1. 四类主要风险

1.1 提示词注入攻击

攻击者通过精心构造的文本，绕过 AI 的原始指令，让它执行恶意操作。分两种：

后果：执行任意 Shell 命令、泄露 API Key、盗用 Token、向攻击者发送敏感数据。提示词注入是大模型的固有问题，目前无法根治。

1.2 IP 暴露风险

2026 年初，安全研究者发现超过 27 万个 OpenClaw 实例直接暴露在公网上，没有任何认证保护——任何人都可以直接访问、盗用 Token、读取对话记录。根本原因：部署时未配置认证，或直接将端口映射到公网。

1.3 恶意 Skill 后门

ClawHub 上有 16,000+ 技能，但并非所有 Skill 都安全：部分 Skill 可能含隐藏的数据上传逻辑、请求超出功能所需的系统权限，或通过依赖包植入供应链攻击。

1.4 文件误删风险

即使只是自己使用，OpenClaw 在执行自动化任务时也可能误操作——构造了错误的 Shell 指令、清理任务范围设置过大，或在命令注入场景下意外公开敏感环境变量。

2. 自查清单：你的龙虾安全吗？

2.1 检查 IP 暴露

第一步：查找你的公网 IP

直接在浏览器访问 ifconfig.me，页面显示的就是你的公网 IP。

或者在终端执行：

# Linux / macOS
curl -s ifconfig.me

# Windows PowerShell
curl.exe -s ifconfig.me
​

本地部署通常在路由器 NAT 后面，默认不会暴露到公网。但如果你做了端口映射或使用了内网穿透工具（如 frp、ngrok），你的 OpenClaw 可能已经暴露。

第二步：验证是否暴露

访问 OpenClaw 暴露查询工具，输入你的服务器 IP 地址进行检查：

• 暴露监测面板：https://openclaw.allegro.earth/

如果查询结果显示你的实例在列，请立即按第 3 节的防护措施进行加固。

第三步：检查端口是否对外开放

# 检查 OpenClaw 默认端口是否对外监听（默认端口：18789）
ss -tlnp | grep 18789
​

如果看到 0.0.0.0:18789 或 :::18789，说明端口对所有网络接口开放，存在暴露风险。应改为 127.0.0.1:18789（仅本地访问）。

2.2 检查认证配置

确保 Gateway 认证已开启：

openclaw config set gateway.auth.enabled true
​

2.3 检查 Skill 来源

# 列出所有已安装的 Skill
clawhub list

# 用 skill-vetter 扫描安全风险
clawhub install skill-vetter
# skill-vetter 会自动扫描已安装的 Skill
​

逐一检查：

• 是否来自 ClawHub 官方或知名作者？
• 安装量和评价如何？
• 是否请求了超出功能需要的权限？

3. 防护措施

3.1 开启沙盒模式（防止文件误删）

沙盒模式让 OpenClaw 只能操作自己工作区内的文件，不会触及你电脑上的其他文件：

openclaw config set agents.defaults.sandbox.mode non-main
​

强烈建议所有用户开启沙盒模式，尤其是刚开始使用的新手。

三种模式对比：

沙盒的详细配置（Docker 隔离、工具策略、提权模式）请参考第八章第 6 节。

3.2 网络隔离（不要直接暴露到公网）

本地部署用户：

• 不要使用 frp、ngrok 等内网穿透工具直接暴露 OpenClaw 端口
• 如果需要远程访问，使用 SSH 隧道或 Tailscale（详见第九章）

云服务器用户：

• OpenClaw 端口只绑定 127.0.0.1，不要绑定 0.0.0.0
• 使用防火墙规则限制访问：

# 仅允许特定 IP 访问（替换为你的 IP）
sudo ufw allow from YOUR_IP to any port 18789
sudo ufw deny 18789
​

• 使用反向代理（如 Nginx）+ HTTPS + 基本认证：

server {
    listen 443 ssl;
    server_name your-domain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        auth_basic "OpenClaw";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:18789;
    }
}
​

3.3 认证与访问控制

# 开启认证
openclaw config set gateway.auth.enabled true

# 重启使配置生效
openclaw gateway restart
​

3.4 Skill 安全审查

安装任何新 Skill 前：

1. 先用 skill-vetter 扫描：clawhub install skill-vetter
2. 检查 Skill 来源：优先选择 ClawHub 官方推荐和高安装量的 Skill
3. 阅读 SKILL.md：了解 Skill 需要的权限和外部依赖
4. 在沙盒模式下先试用：确认行为符合预期后再放开权限

3.5 敏感信息保护

• API Key 使用环境变量，不要写在配置文件里：

export OPENROUTER_API_KEY="sk-..."
​

• 不要在工作区文件中存放密码、Token 等敏感信息
• 定期轮换 API Key：如果怀疑 Key 泄露，立即在提供商后台重新生成

4. 进阶防护：虚拟机隔离架构

给它全部权限，但它碰不到你的钥匙。

前面的措施（沙盒、认证、防火墙）都是软件层面的防护。如果你希望更彻底地解决问题——让 OpenClaw 保持完整能力，同时 API Key、个人文件和宿主机完全不暴露——可以考虑硬件级隔离。

4.1 裸跑的真实风险

如果 OpenClaw 直接跑在你的主力电脑上，它理论上能接触到：

沙盒模式能限制文件访问范围，但不是物理边界。Docker 容器隔离优于无隔离，但容器逃逸并非罕见事件。虚拟机逃逸属于百万级 0day，难度高出一个量级——云厂商的商业模式就建立在 VM 隔离的可靠性之上。

4.2 三层隔离方案

核心思路：用两台虚拟机构建隔离边界，OpenClaw 在 VM1 中拥有完整能力，但真实密钥永远不进入 VM1。

第一层：虚拟机隔离

VM1 运行完整的 Linux 桌面（Debian/Ubuntu + GUI），OpenClaw 在其中拥有全部能力——包括浏览器自动化、Shell 执行、文件读写。即使 VM1 被攻破，重置快照即可恢复，宿主机不受影响。

第二层：密钥隔离

VM2 是最小化 CLI 环境，只运行一个 API 密钥中转代理（如 CLIProxyAPI 或类似工具）。真实 API Key 只存在于 VM2 中，VM1 中的 OpenClaw 通过 VM 内网请求 VM2，VM2 再代理到模型 API。OpenClaw 永远看不到真实密钥。

第三层：网络隔离

• VM1 和 VM2 之间使用 host-only 内网通信
• 对外只需主动外连（outbound），不需要公网 IP
• 藏在家庭路由器 NAT 后面，天然防线

4.3 成本对比

如果购买 Mac Mini 作为专用主机，总成本 ≈ Mac Mini 一次性 + ¥100/年云节点中继（可选），与云服务器费用差一个数量级。

4.4 实施建议

# 推荐配置
# CPU: 4 核  |  内存: 8GB  |  磁盘: 40GB
# 系统: Debian 12 / Ubuntu 24.04（带桌面环境）

# 安装 OpenClaw（参考第二章）
# 模型 API 地址指向 VM2 内网 IP
# 例如：http://192.168.56.2:8080/v1
​

# 最小化配置
# CPU: 1 核  |  内存: 512MB  |  磁盘: 5GB
# 系统: Debian 12 minimal（无桌面）

# 安装 API 中转代理
# 将真实 API Key 配置在此 VM 中
# 监听 host-only 网络接口
​

# 创建专用网络
docker network create --internal openclaw-net

# 容器 1：OpenClaw（不给真实 Key）
docker run -d --name openclaw \
  --network openclaw-net \
  -e API_BASE_URL=http://proxy:8080/v1 \
  ghcr.io/openclaw/openclaw:latest

# 容器 2：API 中转代理（持有真实 Key）
docker run -d --name proxy \
  --network openclaw-net \
  -e REAL_API_KEY="sk-..." \
  your-proxy-image:latest
​

4.5 谁适合这个方案？

社区经验：除非你已经把 OpenClaw 跑得很顺了，否则不建议一上来就搞虚拟机隔离。基本除了聊天，每走一步都要配权限，升级时很多配置要重来。先把 OpenClaw 用熟，再考虑加固。

5. 群聊场景特别警告

为什么不建议把 OpenClaw 放进群聊？

OpenClaw 的设计假设是：与它对话的人是可信任的（就是你自己）。这个假设在群聊场景中完全不成立。

真实案例：

• 群友发送精心构造的消息，直接让 OpenClaw 执行 rm -rf 删除服务器文件
• 攻击者通过提示词注入获取环境变量中的 API Key
• 恶意用户让 OpenClaw 导出所有对话历史和工作区文件
• 有人让 OpenClaw 执行关机命令，导致整个服务下线

如果必须在群聊中使用

如果你了解风险但仍需要在群聊中使用 OpenClaw（如内部小团队），请至少做到：

1. 开启沙盒模式：openclaw config set agents.defaults.sandbox.mode all
2. 限制 Shell 命令执行：openclaw config set tools.deny '["exec"]'
3. 使用白名单：只允许特定用户 ID 与 OpenClaw 交互
4. 限制敏感操作：在 SOUL.md 中明确禁止文件删除、系统命令等危险操作
5. 独立部署：群聊用的 OpenClaw 实例和你私人使用的实例必须完全分开
6. 监控日志：实时关注异常请求

再次强调：以上措施只能降低风险，不能消除风险。提示词注入目前无法根治。如果你的场景允许，最安全的做法就是不要把 OpenClaw 放进群聊。

6. 信任边界架构

7. 威胁分类（MITRE ATLAS）

重点关注 P0 危急项，这三项无论什么场景都需要防范。

7.1 风险等级总览

恶意 Skill 发布 → 绕过审核 → 收割凭证
(T-PERSIST-001)   (T-EVADE-001)  (T-EXFIL-003)
​

注入恶意提示 → 绕过执行审批 → 执行任意命令
(T-EXEC-001)    (T-EXEC-004)    (T-IMPACT-001)
​

投毒 URL 内容 → Agent 抓取并执行指令 → 数据发送到攻击者
(T-EXEC-002)    (T-EXFIL-001)           外部窃取
​

git clone https://github.com/vignesh07/openclaw-formal-models
cd openclaw-formal-models

# 需要 Java 11+（TLC 运行在 JVM 上）
# 仓库内置了 tla2tools.jar 和 bin/tlc

# 正向验证（绿色 = 属性成立）
make gateway-exposure-v2-protected
make nodes-pipeline
make pairing
make routing-isolation

# 反向验证（红色 = 预期的反例，证明模型在检测真实 bug）
make gateway-exposure-v2-negative
make nodes-pipeline-negative
make pairing-negative
make routing-isolation-negative
​

8. 安全检查定期清单

建议每月执行一次：

• 检查 OpenClaw 是否暴露在公网（用 curl -s ifconfig.me 查 IP，去暴露监测面板验证）
• 确认认证已开启（gateway.auth.enabled: true）
• 确认沙盒模式状态符合预期
• 用 skill-vetter 扫描所有已安装 Skill
• 检查并轮换 API Key（尤其是使用量异常时）
• 查看 OpenClaw 日志中是否有异常请求（openclaw logs --limit 100）
• 确认防火墙规则未被修改
• 备份工作区文件

小结

安全不是一劳永逸的事，而是持续的习惯。 就像锁门一样——你不会因为"这个小区很安全"就不锁门。养成定期检查的习惯，你的龙虾才能安全地为你服务。