免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

你的 Moltbot 很可能正在裸奔:安全宝典清单

发布日期:2026-01-29 22:32:21 浏览次数: 1530
作者:架构师

微信搜一搜,关注“架构师”

推荐语

你的Moltbot可能正在裸奔!8个关键配置帮你堵住安全漏洞,避免私钥泄露等重大风险。

核心内容:
1. Moltbot常见的安全隐患与真实案例
2. 8项必须立即实施的最低安全配置
3. 从触发源到工具权限的完整防护思路

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

 


架构师(JiaGouX)
我们都是架构师!
架构未来,你来不来?



写这篇的原因

前两天帮朋友看他的 Moltbot 配置,打开一看,网关直接绑在 0.0.0.0,没有任何 token。

我问他知不知道这意味着什么,他说"应该只有我自己能连吧"。

不是的。这意味着任何人只要扫到你的 IP 和端口,就能给你的 bot 发消息,然后你的 bot 就会照做——跑命令、读文件、开浏览器,什么都行。

后来我又刷到有人做公网扫描,一下子扫出 120 多个这样的实例。另一份报告说 1600 多个。这些不是"理论上可能被攻击",而是"正在被扫描器盯着"。

还有一种更隐蔽的风险:你以为只有"陌生人发消息"才危险,但实际上 bot 读取的任何外部内容(网页、邮件、附件、你粘贴进去的日志)都可能夹带指令,诱导它调用工具。这叫 prompt injection,听上去很学术,但真出事就是"bot 把你的私钥发给了攻击者"。

所以这篇不聊提示词,不聊模型选择,只做一件事:把你已经跑起来的 Moltbot 锁住

你不需要变成安全专家,但你得知道哪些配置是在"敞开大门"。


太长不看版(先做这 8 件事)

下面 8 项是最低安全门槛。做到这些,90% 的常见事故都能提前挡住。

  • • 网关只绑本机gateway.bind: "loopback"。不要 0.0.0.0,不要图省事改成 LAN。
  • • 网关必须鉴权gateway.auth.mode: "token" 或 "password",能轮换。
  • • 远程访问别开公网端口:走 Tailnet 或 SSH 隧道,把"你的人"带回内网。
  • • 定期跑安全审计moltbot security audit --deep --fix,尤其改完配置之后。
  • • DM 默认配对/白名单:陌生人不能触发 bot。
  • • 群聊默认必须 @:不点名不回应,只允许特定群触发。
  • • 工具权限按爆炸半径设计exec/browser/写文件默认收紧,高风险能力只给你自己的 Agent
  • • 本地目录当钥匙串保护~/.moltbot 权限收紧,日志脱敏,分享排障信息前先删减。

先说清楚一件事:Moltbot 不是聊天工具,是控制面

普通聊天机器人最坏的情况是"说错话"。Moltbot 不一样,它的价值就在于能做事:

  • • 跑命令
  • • 读写文件
  • • 控浏览器
  • • 接入消息平台——意味着任何能给你发消息的人,都可能变成触发源

一旦这些能力打开,你就得换一套思路来想安全:

  • • 先管"谁能触发":配对、白名单、群策略
  • • 再管"触发后能动哪里":沙箱、工具权限、工作目录
  • • 最后才是模型:模型再强也会被诱导,强只是"更不容易上当",不是"不会上当"

这个顺序很重要。很多人把精力花在调提示词上,但真正出事的往往是"谁都能给 bot 发消息"或者"bot 能动的东西太多"。


一张图看清风险链路

我们要防的不是某个单点漏洞,而是一条常见的事故链:

我们要做的,就是在 B 和 D 两处把闸门装牢,默认把外部内容当成不可信输入。


15 分钟锁定流程

下面这套流程不追求"完美安全",目标是快速把风险从"可被远程接管"降到"需要多层突破"。

先跑一次安全审计

在动手改配置之前,建议先跑一遍审计,看看自己踩了哪些坑:

moltbot security audit
moltbot security audit --deep

重点看三类问题:

  • • Network exposure:网关是不是 loopback、有没有认证、有没有开不该开的公网面
  • • DM/group policy:是不是 open、有没有配对/白名单
  • • Browser control:控制端点有没有 token、是不是 HTTP、是不是暴露在不可信网络

如果你只想"先止血",可以直接让它自动修复:

moltbot security audit --deep --fix

--fix 会做一些"安全基线回滚":把常见渠道的 open 策略收紧、把脱敏设置改回默认、把敏感目录权限收紧。不是万能药,但能补掉很多低级失误。


把网关绑回 loopback

这是最关键的一刀。

原则很简单:网关默认只给本机连。要远程访问,就通过安全隧道把"你的人"带回本机,而不是把服务推到公网。

你只需要记住三行配置:

{
  gateway: {
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "your-long-random-token" }
  }
}

要避免的只有一句话:不要把网关暴露到 0.0.0.0 且不做强鉴权。这种配置被测绘引擎抓到只是时间问题。


鉴权要强,而且要能轮换

网关鉴权支持 token 或 password,怎么选都行,但必须满足两个要求:

  • • 强度够:长随机字符串,不要短 token、不要可猜测密码
  • • 能轮换:怀疑泄露的时候要能快速换掉,并验证旧的失效

轮换的步骤(建议写进你的运维笔记里):

  1. 1. 生成新 secret
  2. 2. 重启网关
  3. 3. 更新客户端配置
  4. 4. 验证旧 secret 失效

还有一点容易忽略:浏览器控制 token 不要和网关 token 复用。复用意味着一处泄露会放大爆炸半径。


远程访问走隧道,别开公网端口

如果你的需求是"外面用手机也能控制家里的 Moltbot",最常见的错误做法是:开端口、做转发、甚至把服务挪到 VPS 并暴露公网。

更稳的做法:

  • • 网关继续绑 loopback
  • • 远程通过 Tailnet(比如 Tailscale Serve)或 SSH 隧道访问

为什么不建议 LAN bind?因为一旦误配置或被端口转发带到公网,你很难第一时间意识到自己已经"裸奔"。

如果你确实必须跑在 VPS 上,就得把它当生产系统来做:防火墙白名单、强鉴权、最小权限、监控告警、应急预案。省下的那点成本,抵不上一次事故。


关掉 mDNS 广播

这个坑很多人没意识到。即便不暴露公网端口,网关在局域网里广播自身也会泄露运行细节:

  • • CLI 安装路径(包含用户名、目录结构)
  • • SSH 端口
  • • 主机名

如果你不依赖"自动发现设备"的功能,直接关掉最省心:

{
  discovery: {
    mdns: { mode: "minimal" }  // 或 "off"
  }
}

或者设环境变量:MOLTBOT_DISABLE_BONJOUR=1


把"谁能触发我"锁死

很多事故不是黑客技术高超,而是"有人给 bot 发了消息,bot 就照做了"。所以这一步优先级很高。

DM 默认要配对或白名单

DM 策略大概分四档:

  • • pairing:陌生人先拿配对码,你批准了才能触发。推荐默认用这个。
  • • allowlist:只有白名单能 DM
  • • open:任何人可 DM。除非你非常清楚自己在干什么,否则不要用。
  • • disabled:彻底不收 DM

配对审批用 CLI:

moltbot pairing list <channel>
moltbot pairing approve <channel> <code>

还有一个细节:如果你允许多人 DM,默认所有 DM 可能进入同一主会话,上下文会串。可以启用会话隔离:

{
  session: { dmScope: "per-channel-peer" }
}

群聊默认要 @,而且只允许特定群

群聊里最危险的模式是"always-on":任何人说一句话,bot 就能被拉进来,然后被诱导做事。

建议做两件事:

  1. 1. requireMention:只有被 @ 才处理
  2. 2. group allowlist:只允许你明确列出的群触发,不要用 "*" 放开所有群
{
  channels: {
    whatsapp: {
      groups: { "*": { requireMention: true } }
    }
  }
}

这条规则的现实收益:把攻击面从"任何能说话的人"缩小到"能点名的人",同时显著降低误触发。


工具权限:按爆炸半径设计

只要工具开着,注入就有机会被放大成真实动作。所以工具权限不是"默认全开",而是安全系统的一部分。

把工具分层

我建议你先把工具按风险分三类(以后每加一个集成,就对照一下):

  • • 高风险execbrowser、写文件(write/edit/apply_patch
  • • 中风险read(可能读到密钥)、web_fetch/web_search(会把外部内容带进来)
  • • 低风险:纯总结、纯检索

然后做一个简单策略:

  • • 你自己的 agent:才给 exec/browser/写文件(也建议加 sandbox 或审批)
  • • "读者 agent":专门读网页/邮件/附件,做摘要,把摘要交给主 agent。不带 exec/browser,避免内容注入直接触发动作。
  • • 公共/家人/团队 agent:只读。通过 allow/deny 列表把高风险工具关掉。

沙箱:把工具关进容器

Moltbot 支持把工具执行放到 Docker sandbox 里:网关在宿主机,工具在容器里跑。

它不是绝对安全边界,但能显著缩小文件系统和进程访问范围。模型做傻事的时候,损失上限会小很多。

推荐从 non-main 开始

三个概念你得知道:

  • • mode:什么时候用沙箱(off/non-main/all
  • • scope:一个容器服务多少会话(session/agent/shared
  • • workspaceAccess:沙箱能不能看到你的真实工作目录(none/ro/rw

推荐的起点(把群聊/非主会话先关进沙箱):

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        scope: "session",
        workspaceAccess: "none"
      }
    }
  }
}

这里的直觉是:群聊/多入口会话风险更高,让它们先沙箱化;workspaceAccess: "none" 能避免容器直接读取你真实工作区的文件。

有一条红线tools.elevated 是绕过沙箱的宿主机执行逃生口。能不开就不开;必须开的话,allowlist 要极窄,只给你本人。


浏览器控制:当成远程管理员 API

浏览器控制最危险的地方不在"能点按钮",而在于浏览器 profile 往往已经登录了一堆敏感账户。模型只要能操作这个 profile,就等于"以你的身份操作"。

如果你不需要 browser 工具,直接禁用,这是最稳的。

如果必须启用,至少做到:

  • • 独立 profile:不要用你的日常主力 profile
  • • 控制端点必须 token:把它当管理员接口,必须鉴权
  • • 只在可信网络:tailnet-only,不要暴露公网
  • • token 别落盘:用环境变量注入

本地数据:把 ~/.moltbot 当钥匙串

状态目录里存着配置、凭据、会话转录、插件代码、沙箱残留。别人能读到这些,就能拿到你的密钥和行为轨迹。

你至少要做到:

  • • ~/.moltbot 目录权限收紧(只允许当前用户读写)
  • • 配置文件、凭据文件、会话文件权限收紧
  • • 日志启用敏感信息脱敏

还有一个常见事故:为了排障,把会话转录/日志原样发到群里。转录里可能包含你粘贴过的 token、目录结构、命令输出(带密钥、URL、内部服务)。

排障分享的底线:先删减,再分享。别把排障当成二次泄露。


怎么确认自己真的锁住了

做完上面这些,你至少应该能通过三个信号确认自己不再裸奔:

  1. 1. 安全审计报告干净moltbot security audit --deep 不再报高危项
  2. 2. 网关不可从外网直连:无论怎么试探,都连不上
  3. 3. 入口策略生效
  • • DM:陌生人无法直接触发
  • • 群:不 @ 不响应;不在 allowlist 的群不响应
  • • 高风险工具:非 personal agent 无法调用

你真正要追求的是:即使发生注入,损失上限也可控。这才是"可用但不危险"。


出事了怎么办

真怀疑被入侵的时候,按这个顺序来:

先止血

  • • 停网关或禁用高风险工具(尤其 exec/browser
  • • 把 DM/群策略临时收紧到 disabled/allowlist
  • • 把 gateway.bind 拉回 loopback

再轮换

  • • 轮换网关 token/password
  • • 轮换 browser control token(如果启用)
  • • 撤销/轮换模型 API key、消息平台凭据、OAuth

再复盘

  • • 回看最近会话转录里有没有异常工具调用
  • • 检查 extensions/ 里有没有不可信插件
  • • 再跑一次 moltbot security audit --deep,确认清理干净

最小可复制基线

下面这份配置不追求"功能全开",追求"先安全可用"。你可以把它当成最终要达到的稳定形态,再逐步放开能力。

{
  gateway: {
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "${MOLTBOT_GATEWAY_TOKEN}" }
  },
  discovery: {
    mdns: { mode: "minimal" }
  },
  session: {
    dmScope: "per-channel-peer"
  },
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
        scope: "session",
        workspaceAccess: "none"
      }
    }
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } }
    },
    telegram: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } }
    }
  }
}

几个说明:

  • • token 用环境变量注入,避免明文落盘
  • • dmScope 单人自用可以不启用,但启用后更不容易串话
  • • 沙箱从 non-main 起步,后续可以按需升级到 all

最后说两句

Moltbot 这类工具的诱惑是:它让你觉得"只要多给点权限,就能更省事"。

但工程现实往往相反:权限越大,出事损失越大;入口越开放,事故概率越高;模型越便宜越弱,越容易被诱导做傻事。

你真正需要的不是"更强的提示词",而是一个可控的系统:身份先行、权限分层、工具收敛、沙箱兜底、审计常态化。

把这几件事做对,Moltbot 才会是助手,而不是风险源。


参考来源

  • • 安全暴露与风险讨论:公网扫描发现大量实例暴露的多篇社区讨论(120+/1673+ 暴露实例数据)


    • https://x.com/NickSpisak_/status/2016195582180700592

  • • 配置原则与最佳实践:Moltbot 安全文档(Gateway Security / Sandboxing / Pairing 等)
  •        https://moltbotcn.com/docs/gateway/

 

如喜欢本文,请点击右上角,把文章分享到朋友圈
如有想了解学习的技术点,请留言给若飞安排分享

因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读:

      版权申明:内容来源网络,仅供学习研究,版权归原创者所有。如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!

      架构师

      我们都是架构师!



      关注架构师(JiaGouX),添加“星标”

      获取每天技术干货,一起成为牛逼架构师

      技术群请加若飞:1321113940 进架构师群

      投稿、合作、版权等邮箱:admin@137x.com


      53AI,企业落地大模型首选服务商

      产品:场景落地咨询+大模型应用平台+行业解决方案

      承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

      联系我们

      售前咨询
      186 6662 7370
      预约演示
      185 8882 0121

      微信扫码

      添加专属顾问

      回到顶部

      加载中...

      扫码咨询