Beelzebub：用 YAML 和 LLM 拼出多协议蜜罐的运行时
A secure low code deception runtime framework, leveraging AI for System Virtualization.
秒懂
- 它是什么？
- Beelzebub 是一个 Go 编写的欺骗运行时，把 SSH、HTTP、TCP、TELNET、MCP 五类诱饵服务的响应逻辑放进 YAML 配置，由 LLM 或正则规则生成应答。它的价值在于把部署一个交互式蜜罐从写代码变成写配置，代价是引入了模型依赖与 GPL-3.0 的许可证约束。
- 适合谁用？
- Beelzebub 适合已经有明确诱捕目标、愿意维护一份 YAML 服务定义、并且能接受 GPL-3.0 与外部模型调用的安全团队，尤其是需要覆盖 MCP 这类 AI Agent 攻击面、又不想为每种协议单独写服务的场景。不适合只想跑一个开箱即用的单协议蜜罐的人，也不适合把诱饵逻辑视为商业机密、无法接受 GPL 传染性考量的闭源产品团队。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它填的是哪一类坑：交互式诱饵的部署成本
传统蜜罐的麻烦不在协议实现，而在应答内容。一个 SSH 蜜罐要骗住攻击者，得让 shell 回显看起来像真的文件系统；一个 HTTP 蜜罐得让目录结构和错误页合理。这类逻辑过去要么靠硬编码的假响应，要么靠把真实系统放进容器再打补丁，改一次交互就要动一次代码。Beelzebub 的定位是把这层逻辑外置：README 把它描述为 deception runtime，用 YAML 定义服务，用正则匹配命令，用 LLM 生成上下文相关的回答，从而在攻击者那边维持更长的会话，收集 TTP。目标读者是安全团队里负责诱捕与威胁情报的工程师，以及需要给 AI Agent 加一层攻击面监测的人。注意仓库把它标为 research-project，这个标签本身说明了成熟度预期：它是可运行的框架，不是封装好的商业产品。
运行时如何组起来：配置目录、服务定义与 LLM 应答
从 CLI 的默认值能看出它的数据流。beelzebub run 默认读取 ./configurations/beelzebub.yaml 作为核心配置，读取 ./configurations/services/ 目录作为服务配置集合。也就是说，一个进程按目录扫描多份服务定义，每份定义对应一类协议诱饵，核心配置负责全局项。应答生成分两条路：正则命令匹配负责确定性回复，LLM 集成（README 列出 OpenAI 与 Ollama）负责生成式的回复。README 的原话是 LLM 集成“generates contextually accurate responses in real time”。这里有一个需要自己确认的边界：材料没有给出正则匹配与 LLM 调用的优先级关系，也没有说明 LLM 不可用时是否回落到静态应答。如果你的诱饵部署在无法访问外部模型的网段，Ollama 是本地的选项，但具体配置键在给出的材料里没有展开，需要对照 docs.beelzebub.ai 或 configurations 目录确认。
TCP 服务走的是另一条插件路径。服务定义里用 wirePlugins 列表显式启用已安装的 wire 插件，并且按列表顺序执行：
wirePlugins: - vnc
WireContext 会暴露原始请求与响应字节、匹配到的命令、服务身份、历史记录等字段。这个设计把二进制协议的解析交给插件，核心只负责转发与匹配，是合理的分层：VNC 这类协议没法用文本正则描述。
三种部署路径与对应的命令
本地构建走 make start，README 说这条命令会安装声明的插件、编译进去、然后运行。Docker 走 make docker，同样把插件打进镜像。两者都依赖 Makefile 里的插件安装步骤，这意味着插件不是运行时动态加载的，而是编译期进入二进制。Kubernetes 场景用 helm install beelzebub ./beelzebub-chart，升级用 helm upgrade。
还有一条交互式安装路径 ./install.sh，会询问本地还是 Docker，检查前置条件后启动。非交互形式是 ./install.sh --local 或 ./install.sh --docker，只想构建不启动用 ./install.sh --local --no-run。README 里有一条容易被忽略的限制：在非 root 主机上，如果默认配置包含特权端口，本地安装不会自动启动。这条限制很实际，80、22、23 这些端口对应 HTTP、SSH、TELNET 诱饵，普通用户跑不起来。CI 里可以用 beelzebub validate 只做配置解析与校验，不启动任何服务，命令形式是 beelzebub validate --conf-core ./configurations/beelzebub.yaml --conf-services ./configurations/services/。
运行时资源控制由 beelzebub run 的 -m 或 --mem-limit-mib 控制，默认 100 MiB，传 -1 关闭限制。默认值偏紧，如果同时挂多个 LLM 应答的服务，需要自己评估。
插件 SDK 的接口边界
扩展点放在 pkg/plugin，README 称其为稳定公共 SDK。接口有四个：CommandPlugin 为 SSH、TCP、TELNET、HTTP 生成文本响应，实现 Metadata 和 Execute 两个方法；HTTPPlugin 返回完整 HTTP 响应，包含状态码、头和 body，实现 HandleHTTP；WirePlugin 用于观察并可能改写匹配到的二进制 TCP 交换，实现 OnExchange；WireSessionCloser 是可选的，用来释放每连接的插件状态，实现 OnSessionClose。注册方式是在 init() 里完成，不需要改核心代码。
这套接口划分有一个值得注意的取舍：文本类协议全部收敛到 CommandPlugin 的字符串返回值，意味着 HTTP 之外的服务没法直接控制连接层行为；而二进制协议必须走 WirePlugin，且必须在服务 YAML 里逐个列出。插件安装命令是 beelzebub plugin install github.com/your-org/beelzebub-myplugin，配套有 list 和 remove。从 GitHub 拉取插件源码再编译进二进制，这条链路意味着插件供应链就是你的构建供应链，评审插件的必要性不低于评审依赖库。
可观测性与事件出口
README 列出两条输出通道：Prometheus 指标和 RabbitMQ 事件流。对诱捕系统来说，指标回答的是“诱饵活着吗、被碰了多少次”，事件流回答的是“攻击者具体做了什么”，两者用途不同，缺一个都不完整。材料没有给出具体的指标名、RabbitMQ 的 exchange 或 routing key，也没有说明事件 schema，这些需要查文档。一个务实的判断是：如果你的团队已经有 Prometheus 和 RabbitMQ，接入成本主要是配置；如果没有，为了跑一个诱饵服务而引入消息队列，运维负担可能超过收益，此时应优先确认是否支持更简单的落盘或 stdout 输出。给出的材料里没有提到这一点。
LLM 应答带来的失败模式
把应答交给模型，会引入几类在静态蜜罐里不存在的问题。第一类是延迟与成本：每次交互都要调用模型，攻击者用高频命令刷你的诱饵，账单和响应时间都会跟着走，而 --mem-limit-mib 限制的是内存，不是调用次数。第二类是一致性：同一个会话里前后回答如果互相矛盾，稍有经验的攻击者就能识破，材料没有说明框架是否维护跨命令的会话上下文。第三类是模型本身的安全边界，诱饵进程会把攻击者输入送进模型，这等于把不可信输入接进你的模型调用链，提示注入的防护责任落在部署方。
还有一类更基础的错配：Beelzebub 适合需要长时间交互、需要收集攻击者意图的场景。如果你的目标只是发现扫描行为，一个只监听端口、记录源 IP 的简单服务就够了，引入 LLM 只会增加依赖面。反过来，如果诱饵部署在隔离网段、无法访问任何模型端点，LLM 这条能力线基本作废，剩下的就是正则匹配加静态响应，此时它相对其他低代码蜜罐的优势会明显缩小。
与 Cowrie 这类专用蜜罐的路线差异
Cowrie 是 SSH 与 TELNET 蜜罐里被广泛使用的实现，走的是另一条路：它模拟一个完整的类 Unix shell 环境，文件系统、命令输出、会话记录都在自身内部实现，不依赖外部模型，也不依赖 YAML 描述服务。差异在于覆盖范围与可预测性。Cowrie 把 SSH 这一件事做得深，交互细节由项目自己维护；Beelzebub 用一份配置同时铺开五种协议，代价是每种协议的仿真深度取决于你写的规则和模型的输出质量。
选择上可以这样分：如果诱捕目标集中在 SSH 爆破与交互式登录，Cowrie 的现成仿真更省事，也不需要模型调用预算。如果要覆盖 HTTP、TCP 以及 MCP 这类较新的攻击面，并且希望用同一套配置和同一套指标体系统一管理，Beelzebub 的结构更合适。MCP 这一项是它区别于传统蜜罐的地方，README 明确把 MCP 列为支持的欺骗服务之一，并提到检测针对 AI Agent 的提示注入攻击，这在同类项目里不常见。
许可证、维护成本与升级节奏
许可证是 GPL-3.0。对内部部署的诱捕系统，通常不构成分发，影响有限；但如果你打算把 Beelzebub 或其修改版打包进对外交付的产品，GPL-3.0 的传染性会成为必须由法务评估的问题。这里只陈述许可证标识，不构成法律意见。
维护成本主要来自三处。一是版本节奏：从发布记录看，v3.9.0 到 v3.9.1 相隔不到一个月，v3.8.0 到 v3.9.0 相隔约两个月，属于活跃迭代的项目，跟随升级需要留出回归测试的时间。二是插件编译期绑定，每次升级核心都要重新编译已声明的插件，插件与 SDK 的兼容性需要自己验证。三是配置漂移，服务定义是 YAML，正则匹配规则会随攻击者手法变化而需要更新，这部分工作量不会因为低代码而消失，只是从写代码变成了改配置。
升级前值得跑一遍 beelzebub validate，把配置问题挡在启动之前；beelzebub version 会打印版本、commit SHA、构建日期和 Go 运行时信息，排查环境差异时比猜更可靠。
编辑结论
Beelzebub 适合已经有明确诱捕目标、愿意维护一份 YAML 服务定义、并且能接受 GPL-3.0 与外部模型调用的安全团队，尤其是需要覆盖 MCP 这类 AI Agent 攻击面、又不想为每种协议单独写服务的场景。不适合只想跑一个开箱即用的单协议蜜罐的人，也不适合把诱饵逻辑视为商业机密、无法接受 GPL 传染性考量的闭源产品团队。上手前先做三件事：用 beelzebub validate 跑通核心配置与服务目录，确认 ./install.sh --local 在非 root 主机上因特权端口不会自动启动这一行为是否符合你的部署方式，再确认 LLM 供应商（OpenAI 或 Ollama）的接入方式与数据出境要求。如果这三点里任何一点卡住，先别急着把它放进生产网段。
社区笔记