Beelzebub レビュー: YAML と LLM でデコイサービスを組む Go 製 deception runtime
A secure low code deception runtime framework, leveraging AI for System Virtualization.
ひと目でわかる
- これは何？
- Beelzebub は SSH、HTTP、TCP、TELNET、MCP のデコイサービスを YAML 定義と LLM 応答で運用する Go 製フレームワークである。低コードで囮を増やせる一方、設定ファイルとプラグインの管理が導入判断の中心になる。
- 誰に向いている？
- すでに SSH や HTTP の囮を自前で維持していて、設定の追加だけでデコイを増やしたいチームには向く。逆に、LLM の外部依存を許容できない環境や、MCP を扱わない組織では導入理由が薄い。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Beelzebub が埋めるのは囮の運用コストという穴
従来のハニーポットは、攻撃者を引き止めるために応答を人手で書き続ける必要があった。Cowrie のような SSH ハニーポットはコマンドごとの挙動を実装済みだが、新しいプロトコルや社内システムを模した囮を足すたびにコードを書くことになる。Beelzebub はこの部分を YAML のサービス定義と正規表現のコマンドマッチングに寄せ、追加のデコイを設定ファイルの追加で表現しようとする。README はこれを low-code service definition と呼び、カスタムコードなしで新しいデコイサービスを配備できると説明している。対象読者は、SOC や研究目的で囮を複数プロトコルに展開したいが、各プロトコルごとに専用のハニーポット実装を保守したくない運用者である。MCP サービスが含まれている点は特徴的で、AI エージェント向けの攻撃面、具体的にはプロンプトインジェクションの検知を想定している。
LLM が応答を生成し、正規表現がコマンドを拾う二段構え
Beelzebub の中心は adaptive deception engine と呼ばれる部分で、OpenAI と Ollama を LLM バックエンドとして使い、攻撃者とのやり取りに対して文脈に沿った応答をリアルタイムに生成する。README の表現では、攻撃者を十分長く引き止めて actionable な TTP を集めることが狙いとされている。すべての応答を LLM に投げるのではなく、YAML 側の正規表現でコマンドをマッチさせ、マッチしたものを処理系に渡す構造になっている。拡張点は 3 つのインターフェースに分かれる。CommandPlugin は SSH、TCP、TELNET、HTTP 向けのテキスト応答を返し、HTTPPlugin はステータスコード、ヘッダ、ボディを含む完全な HTTP 応答を組み立てる。WirePlugin はバイナリの TCP 交換を観測し、必要なら書き換える。TCP サービスでは wirePlugins キーにプラグイン名を並べ、実行順を明示する。README の例では vnc という 1 行が示されている。接続ごとの状態を解放するために WireSessionCloser という任意インターフェースも用意されている。
起動までの経路は installer、make、Helm の 3 つ
配布形態は複数用意されている。リポジトリ同梱の ./install.sh は対話形式で local か Docker を尋ね、前提条件を確認して起動する。非対話で使う場合は ./install.sh --local または ./install.sh --docker を渡す。ビルドだけして起動したくない場合は ./install.sh --local --no-run を使う。README には、非 root ホストでは既定設定が特権ポートを含む場合にローカルインストールが自動起動しないと明記されている。Go で直接動かす場合は make start が宣言済みプラグインのインストール、コンパイルへの組み込み、実行までを行う。コンテナの場合は make docker が宣言済みプラグインを焼き込んだイメージをビルドして起動する。Kubernetes では helm install beelzebub ./beelzebub-chart と helm upgrade beelzebub ./beelzebub-chart が示されている。実行時のフラグは beelzebub run に集約され、-c または --conf-core がコア設定ファイルのパス、既定は ./configurations/beelzebub.yaml、-s または --conf-services がサービス設定ディレクトリ、既定は ./configurations/services/ である。-m または --mem-limit-mib は MiB 単位のメモリ上限で、既定は 100、-1 で無効化する。設定を起動せず検証する beelzebub validate も同じ 2 つのパス引数を取り、CI パイプラインでの利用が想定されている。
MCP デコイという新しい攻撃面の扱い
MCP deception service は Beelzebub の他サービスと性質が異なる。SSH や TELNET の囮はシェル応答を返せば成立するが、MCP は AI エージェントがツール呼び出しを行うためのプロトコルであり、囮が返す内容そのものがエージェントの判断に影響する。README は、AI エージェントに対するプロンプトインジェクション攻撃の検知を用途として挙げている。つまりこのサービスは攻撃者の行動記録だけでなく、エージェント側に注入された指示が囮に到達したかどうかを観測する位置に置かれる。ただし README の記述はここまでで、検知した注入をどう分類するか、誤検知をどう扱うかといった運用面の説明は与えられていない。MCP を社内で使っていない組織にとって、このサービスは設定ファイルと保守対象を増やすだけになる。導入するなら、まず MCP のやり取りを記録する目的が侵害検知なのか研究なのかを決めておく必要がある。
観測と拡張は Prometheus、RabbitMQ、GitHub 取得のプラグインで組む
収集したイベントの出口として Prometheus メトリクスと RabbitMQ へのイベントストリーミングが用意されている。どちらも設定キーの具体形は README の抜粋には現れないため、実際のキー名は docs.beelzebub.ai の Configuration Reference を確認する必要がある。プラグインは pkg/plugin 以下の公開 SDK に対して実装し、init() で登録する方式で、コア側の変更を要求しないと説明されている。外部プラグインは GitHub から取得する前提で、beelzebub plugin install github.com/your-org/beelzebub-myplugin のようにリポジトリパスを渡す。一覧は beelzebub plugin list、削除は beelzebub plugin remove myplugin である。ここで注意したいのは、make start と make docker が宣言済みプラグインをインストールしてからビルドする点だ。プラグインの導入はビルド手順に組み込まれており、実行時に動的ロードするわけではない。プラグインの供給元が GitHub リポジトリである以上、依存の固定方法と取得元の信頼性は利用者側の責任になる。
向かない場面: LLM 依存と低コードの限界
Beelzebub の応答品質は LLM バックエンドに依存する。OpenAI を使うなら囮の通信が外部 API に送られることになり、閉域網や外部送信が禁止された環境では Ollama を自前で立てる必要がある。Ollama を選んだ場合、今度はモデルの推論資源と応答遅延が囮の現実らしさに影響する。SSH のログインプロンプトに対して数秒かかる応答は、攻撃者に囮だと気付かれる手がかりになる。もう一つの制約は low-code という言葉の範囲である。YAML と正規表現で表現できるのは、既存のコマンド体系を模す範囲に限られる。ファイルシステムの状態を保持するとか、複数セッションにまたがる整合性を保つといった挙動は、プラグインを書かない限り実現できない。README が挙げる CommandPlugin、HTTPPlugin、WirePlugin の 3 つは、いずれも Go のコードを書いて init() で登録する必要がある。つまり low-code は「コードを書かずに済む」ではなく「よくある囮はコードを書かずに済む」という意味で読むべきである。
Cowrie との違いは応答生成の置き場所
SSH ハニーポットとして最も名前が上がる Cowrie は、Python で書かれたエミュレーション層を持ち、シェル、ファイルシステム、コマンドの挙動をあらかじめ実装している。応答はコードに埋め込まれており、LLM には依存しない。そのため同じ入力に対して常に同じ応答が返り、再現性があり、外部サービスへの通信も発生しない。一方で、Cowrie が模倣していないプロトコルや、社内固有のアプリケーションを囮にしたい場合は、Python 側に手を入れることになる。Beelzebub はこの関係を逆転させ、応答の生成を LLM に委ね、プロトコルごとの入口を YAML とプラグインで揃える。得られるのは模倣の幅と追加の速さ、失うのは応答の決定性と外部依存のなさである。どちらが優れているかではなく、囮に求めるものが再現性なのか網羅性なのかで選ぶべきものである。MCP を囮にしたい時点で、Cowrie 側には対応する実装がない。
ライセンスと更新の追い方
ライセンスは GPL-3.0 である。Beelzebub を改変して配布する場合、あるいはリンクする形でプラグインを頒布する場合、GPL-3.0 の条件が及ぶ範囲は利用形態によって変わる。ここで法的な判断を代わりに下すことはできないが、社内利用に留めるのか、改変物を外部に配るのか、プラグインを別リポジトリで公開するのかによって確認すべき点が変わることは押さえておきたい。更新頻度は比較的高く、v3.8.0 が 2026-06-02、v3.9.0 が 2026-08-05、v3.9.1 が 2026-08-31 に公開されている。マイナー版が 2 か月ほどで進んでいるため、YAML のスキーマやプラグイン SDK の変更を追う前提で運用を組む必要がある。CI に beelzebub validate を組み込み、設定ファイルの検証をアップグレード時のゲートにしておくのが素直な付き合い方である。
編集部の結論
すでに SSH や HTTP の囮を自前で維持していて、設定の追加だけでデコイを増やしたいチームには向く。逆に、LLM の外部依存を許容できない環境や、MCP を扱わない組織では導入理由が薄い。最初に確認すべきは configurations/services/ 以下の YAML が自組織のポート構成と衝突しないか、beelzebub validate が通るか、そして GPL-3.0 の下でプラグインを配布する前提があるかどうかである。
コミュニティノート