OpenClaw 暴露面分析：AI 代理框架的安全隐患与防护
从 25 万公开实例看 AI 服务的安全底线
背景与现状
2026 年初，一个名为 OpenClaw 的开源 AI 代理框架在 GitHub 上异军突起，星标增长速度一度超越 React，成为开发者圈内炙手可热的项目。它让用户能够快速搭建高度可定制的私人 AI 助手，支持微信、企业微信、腾讯云、百度等中国生态服务，也兼容主流国际平台。
然而，火爆的背后隐藏着巨大的安全危机：大量用户直接将 OpenClaw 实例部署在公网，未启用任何认证措施，导致这些'AI 代理'成为公开可访问的端点。更可怕的是，一个名为 OpenClaw Watchboard 的监控网站正在实时追踪这些暴露的实例，数量高达 25.8 万，并标记了其中存在凭证泄露、已知漏洞、甚至与 APT 团伙关联的实例。
作为一名既热爱 AI 技术又从事网络安全工作的工程师，我第一时间分析了这份暴露面数据。本文将深入解读 OpenClaw 的架构、暴露风险、Watchboard 的威胁情报，并为部署者提供切实可行的加固方案。
项目概览
OpenClaw（原 Clawdbot）是一个用 TypeScript 开发的开源 AI 代理框架。它的核心能力包括：
- 多平台集成：深度适配微信、企业微信、钉钉、飞书、Slack、Discord 等。
- 多代理协作：支持多个 AI 代理分工协作完成任务。
- 任务自动化：可调用外部工具（搜索引擎、API、数据库）执行复杂工作流。
- 中国生态友好：内置对腾讯云、百度 AI、阿里云等服务的调用支持。
正是这种'即插即用'的便捷性，使得许多开发者和企业快速部署了 OpenClaw，却忽略了最基本的安全配置——访问控制。
暴露风险：为什么 25 万实例'裸奔'？
从 Watchboard 的数据看，大部分暴露的实例直接使用 IP 地址或未加保护的域名，默认不启用认证。攻击者一旦发现这些端点，可以：
- 直接调用 AI 代理功能：窃取对话历史、滥用代理调用内部系统。
- 利用凭证泄露：Watchboard 中标记了部分实例'has_leaked_creds'，意味着环境变量或配置文件中包含云服务密钥、数据库密码等敏感信息。
- 植入恶意指令：通过未授权接口让 AI 代理执行危险操作，如发送钓鱼邮件、删除数据。
- 作为跳板进入内网：如果实例部署在企业内部网络并暴露，攻击者可借此横向移动。
更令人担忧的是，Watchboard 关联了威胁情报，显示某些实例与 APT15、APT17、APT28 等已知威胁行为者有关。这可能意味着攻击者已经在利用这些暴露的实例进行攻击活动。
Watchboard 深度解析
Watchboard 本质上是一个公共威胁情报仪表盘，实时监控全球所有公开可达的 OpenClaw 实例。主要功能包括：
- 实时列表：分页展示 258,305 个实例（数据截至 2026 年 5 月 3 日），每页 100 条，共 2584 页。
- 关键字段：
- Endpoint：实例地址（IP:端口或域名）
- Assistant Name：助手名称（可能泄露用途）
- Country：国家/地区（使用旗帜标识）
- auth_required：是否要求认证（大量为 false）
- has_leaked_creds：是否发现泄露的凭证
- ASN / 组织 / 云服务商：如腾讯云、阿里云、AWS、SberCloud 等
- first_seen / last_seen：首次和最后发现时间
- 威胁情报：关联的 APT 组织、CVE 漏洞列表
地理与云服务分布
根据示例数据，暴露实例主要集中在中国大陆、香港、俄罗斯、美国、新加坡等地。云服务商方面，腾讯云、阿里云、AWS 占据前列。这反映出 OpenClaw 在中国开发者中的流行程度，也意味着国内云用户需要特别关注自身资产。
