OpenClaw 安全配置完整指南：从 1800 个暴露实例学到的教训

背景

上周我写了一篇关于 Shodan 上暴露实例的文章，当时发现了 299 个。一周后，这个数字涨到了 1800+。

SlowMist 的安全报告里提到一个案例：某用户的 Anthropic API 密钥被盗，一夜之间消耗了 1.8 亿 tokens。按照 Claude 3.5 Sonnet 的定价（$3/M input, $15/M output），这是几千美元的损失。

问题的根源不是软件漏洞，而是配置错误。但 OpenClaw 的架构设计确实让"配置错误"的后果变得特别严重。

这篇文章整理一下正确的安全配置方法。

核心问题：默认配置 vs 实际部署

OpenClaw 的网关默认配置是安全的：

# config.yaml 默认值
gateway:
  host: "127.0.0.1"
  port: 18789

绑定 127.0.0.1 意味着只有本机能访问。问题出在用户想要远程访问时做的修改。

常见的错误配置

错误一：直接改成 0.0.0.0

# 千万别这么干
gateway:
  host: "0.0.0.0"
  port: 18789

这会让网关监听所有网络接口，包括公网 IP。如果服务器没有防火墙规则，任何人都能直接访问。

错误二：Docker 端口映射不当

# 危险配置
docker run -p 18789:18789 openclaw/gateway

这相当于把容器内的 18789 端口映射到宿主机的所有接口。即使容器内绑定的是 127.0.0.1，宿主机层面也暴露了。

正确做法是绑定本地：

# 安全配置
docker run -p 127.0.0.1:18789:18789 openclaw/gateway

错误三：反向代理没加认证

很多用户用 nginx 做反向代理，方便从外部访问：

# 危险配置
server {
    listen 80;
    server_name agent.example.com;
    
    location / {
        proxy_pass http://127.0.0.1:18789;
    }
}

这等于把内网服务原样暴露到公网。没有任何认证。

正确的远程访问方案

如果你确实需要远程访问自己的 OpenClaw 实例，有几种安全的做法。

方案一：Tailscale（推荐）

Tailscale 是最简单的方案。它在你的设备之间建立加密的点对点连接，不需要开放任何公网端口。

在运行 OpenClaw 的服务器上安装 Tailscale：

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up

在你的手机/电脑上也安装 Tailscale，登录同一账号
现在你可以通过 Tailscale 分配的内网 IP 访问 OpenClaw：

http://100.x.x.x:18789

OpenClaw 保持默认的 127.0.0.1 绑定不用改。Tailscale 会处理网络层面的事情。

方案二：Cloudflare Tunnel

如果你想通过域名访问，Cloudflare Tunnel 是个好选择：

安装 cloudflared：

curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared

登录并创建隧道：

./cloudflared tunnel login
./cloudflared tunnel create openclaw

配置隧道：

# ~/.cloudflared/config.yml
tunnel: <tunnel-id>
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: agent.yourdomain.com
    service: http://localhost:18789
  - service: http_status:404

在 Cloudflare 后台为 agent.yourdomain.com 添加 CNAME 记录指向隧道
启用 Cloudflare Access 添加认证层

这样访问 agent.yourdomain.com 会先经过 Cloudflare 的认证，通过后才能访问到本地的 OpenClaw。

方案三：启用内置 JWT 认证

OpenClaw 自带 JWT 认证功能，但默认是关闭的：

# config.yaml
gateway:
  host: "127.0.0.1"
  port: 18789
  auth:
    enabled: true
    jwt_secret: "your-very-long-random-secret-here"

生成一个足够长的随机密钥：

openssl rand -hex 32

启用后，所有请求都需要带上有效的 JWT token。你可以用官方提供的脚本生成 token：

python scripts/generate_token.py --secret your-secret --expiry 30d

这个 token 需要在客户端配置里填入。

注意：即使启用了 JWT，也不建议直接把服务暴露到公网。JWT 只是多一层保护，不是替代网络隔离。

API 密钥的最小权限原则

很多用户直接把自己的主 Anthropic/OpenAI 账号密钥扔进 OpenClaw 配置。这是个坏习惯。

正确做法是创建专用的、权限受限的密钥：

Anthropic

目前 Anthropic 不支持细粒度的 API 密钥权限。替代方案：

创建一个单独的 Anthropic 账户，专门给 OpenClaw 用
设置较低的月度消费上限
开启消费告警

OpenAI

OpenAI 支持项目级别的 API 密钥：

在 OpenAI 后台创建一个新项目
为该项目生成专用的 API 密钥
设置项目级别的消费上限

Settings → Billing → Limits → Set monthly budget

建议设置一个你能接受损失的金额作为上限。即使密钥泄露，损失也是可控的。

密钥泄露后的应急响应

如果你怀疑密钥已经泄露：

1. 立即轮换密钥

# Anthropic
# 在 console.anthropic.com 生成新密钥，删除旧密钥

# OpenAI
# 在 platform.openai.com 生成新密钥，删除旧密钥

2. 检查消费记录

3. 更新 OpenClaw 配置

# 用新密钥更新配置
vim config.yaml

# 重启服务
systemctl restart openclaw

4. 检查对话历史

OpenClaw 默认保存对话历史在本地。检查是否有可疑的对话记录：

ls -la ~/.openclaw/conversations/

如果发现不是你发起的对话，说明攻击者可能已经访问过你的实例。

完整的安全检查清单

部署 OpenClaw 前，过一遍这个清单：

[ ] 网关绑定地址是 127.0.0.1，不是 0.0.0.0
[ ] Docker 端口映射指定了 127.0.0.1
[ ] 如需远程访问，使用 Tailscale/Cloudflare Tunnel
[ ] JWT 认证已启用（作为额外保护层）
[ ] API 密钥是专用的，不是主账号密钥
[ ] API 账户设置了消费上限和告警
[ ] 服务器防火墙关闭了 18789 端口的公网访问
[ ] 定期检查 Shodan 确认自己的实例没有暴露

最后一条可以这么做：

# 查询你的 IP 是否在 Shodan 上有 OpenClaw 相关记录
curl "https://api.shodan.io/shodan/host/YOUR_IP?key=YOUR_SHODAN_KEY"

写在最后

OpenClaw 是个有意思的工具，但它的架构决定了一旦被攻破后果很严重。网关进程存储着 API 密钥、对话历史、浏览器控制权限，是个高价值目标。

花 10 分钟做好安全配置，比事后补救省心得多。

如果你已经按照之前那篇上手指南跑起来了，建议对照这篇检查一下配置。尤其是用 Docker 部署的同学，端口映射那块特别容易踩坑。

有问题可以在评论区交流。

posted @ 2026-02-03 10:40 147API 阅读(253) 评论(0) 收藏举报

刷新页面返回顶部