Beelzebub：用 LLM 驅動的誘餌服務，把攻擊者留在對話裡
A secure low code deception runtime framework, leveraging AI for System Virtualization.
秒懂
- 它是什麼？
- Beelzebub 是一個以 Go 撰寫的欺敵執行環境，用 YAML 定義 SSH、HTTP、TCP、TELNET 與 MCP 誘餌服務，並可接上 OpenAI 或 Ollama 產生即時回應。它的價值在於把被動記錄變成主動對話，代價是你得接受一個會對外送資料到模型供應商的架構。
- 適合誰用？
- Beelzebub 適合已經有隔離網段、想把誘餌服務標準化成 YAML 設定並願意接上 LLM 的團隊，特別是同時要觀察 MCP 這類 AI 代理攻擊面的人。若你的環境不能讓誘餌流量外送到 OpenAI，或你只需要記錄連線而不需要互動，被動式蜜罐更省事。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
被動記錄留下的空白，以及 Beelzebub 想補的那一段
傳統蜜罐記錄的是連線、指令與時間戳。攻擊者打幾行字、發現沒有回應、離開，你手上只有一份短得可憐的紀錄。Beelzebub 的 README 把它定位成 deception runtime，強調它「beyond passive honeypots」，會主動與攻擊者互動。這個差異在實務上意味著什麼：當攻擊者對 SSH 誘餌下了一道指令，回應不是固定字串，而是由 LLM 依上下文生成，讓對方願意多打幾輪。
目標讀者相當明確。一種是維運既有蜜罐、想拉長互動時間以收集 TTP 的資安團隊。另一種是開始面對 AI 代理攻擊面的人，README 特別列出 MCP 協定與偵測 prompt injection 的能力，這是多數傳統蜜罐工具沒有覆蓋的區塊。若你只是想統計掃描來源 IP，這個專案對你而言過重。
YAML 定義服務，外掛決定回應內容
Beelzebub 的設定分成兩層。核心設定走 --conf-core，預設路徑是 ./configurations/beelzebub.yaml；服務定義放在目錄裡，由 --conf-services 指定，預設 ./configurations/services/。README 描述服務定義是 low-code 的 YAML，搭配 regex 指令比對，宣告一個新誘餌服務不需要寫程式。
需要寫程式的部分集中在回應邏輯。專案在 pkg/plugin 提供公開 SDK，定義了三種介面。CommandPlugin 的 Execute 回傳字串，服務 SSH、TCP、TELNET 與 HTTP 的文字回應；HTTPPlugin 的 HandleHTTP 直接回傳狀態碼、標頭與內容；WirePlugin 的 OnExchange 拿到的是原始位元組，可以觀察甚至改寫二元協定交換。另有選用的 WireSessionCloser，用來釋放每條連線的外掛狀態。
TCP 服務要啟用 wire plugin，得在服務設定裡明確列出，且順序即執行順序，例如 wirePlugins 底下寫一項 vnc。這個設計意味著二元協定的處理鏈是人工排序的，順序錯了不會有編譯錯誤，只會得到非預期的位元組。文件對這點的說明偏薄。
從安裝腳本到 Kubernetes 的四條路徑
最省事的是 ./install.sh，它會詢問要用本機或 Docker 模式、檢查前置條件後啟動。要非互動執行則加參數：./install.sh --local 或 ./install.sh --docker。若只想安裝與建置、不啟動本機執行環境，用 ./install.sh --local --no-run。README 附了一個限制：在非 root 主機上，當預設設定包含特權埠時，本機安裝不會自動啟動。特權埠對應的正是 22、23 這類誘餌常用埠，所以這條限制在實務上很容易撞到。
直接用 Go 的話是 make start，它會安裝宣告的外掛、編譯進去再執行。Docker 路線是 make docker，同樣把宣告的外掛烤進映像檔。Kubernetes 走 Helm：helm install beelzebub ./beelzebub-chart，升級用 helm upgrade。
執行期由 beelzebub run 帶起所有服務，三個旗標值得記住：-c 指定核心設定、-s 指定服務目錄、-m 設定記憶體上限（單位 MiB，-1 表示停用，預設 100）。CI 裡則用 beelzebub validate 搭配同樣的兩個路徑參數，只解析與驗證設定、不啟動服務。外掛管理是 beelzebub plugin install、list、remove，來源為 GitHub 上的模組路徑。
可觀測性與記憶體上限這兩個維運開關
README 列出 Prometheus 指標與 RabbitMQ 事件串流兩種輸出。前者適合接進既有的告警與儀表板，後者適合把誘餌事件丟進更大的資料管線。值得注意的是，文件把這些歸在 observability 章節，並沒有描述事件 schema 或指標名稱，要接線的人得自己從程式碼或執行結果反推。
-m 的預設值 100 MiB 是另一個容易低估的地方。這是每個服務的記憶體上限，而 LLM 回應路徑本身有延遲與記憶體成本。當你把服務數量開上去、又讓每個服務都走模型生成，這個數字會直接決定服務是被限縮還是被殺掉。README 沒有給出建議值與服務數量的對應關係，部署前需要自行量測。
LLM 回應帶來的三個實際問題
第一個是資料外流。README 明列 LLM 整合支援 OpenAI 與 Ollama，前者代表誘餌收到的攻擊者輸入會離開你的網段。Ollama 可自架，是唯一能讓整條路徑留在內部的選項。選擇供應商等於選擇資料邊界，這件事在文件裡沒有被當成決策點來討論。
第二個是回應延遲與一致性。模型生成不是固定查表，同一道指令在不同時間可能得到不同回應。對誘餌而言這通常可接受，但如果攻擊者連續下同一道指令並察覺答案不一致，誘餌身分就會被識破。文件沒有描述任何一致性控制機制。
第三個是 prompt injection 的雙面性。README 把偵測 AI 代理的 prompt injection 列為能力之一，這代表誘餌本身也在處理不受信任的輸入。你等於在自家網路裡跑一個會把外部文字送進模型的服務。這不是阻擋導入的理由，但它是架構審查時必須被寫進去的一條。
什麼時候該選被動蜜罐而不是它
最直接的替代方案是傳統被動蜜罐，例如 Cowrie 這類以固定腳本模擬 shell 的工具。兩者的差異在機制而非規模：被動蜜罐用預先寫好的假檔案系統與指令回應表，攻擊者打什麼就回什麼，沒有模型推論、沒有外部 API 呼叫、記憶體足跡可預測。Beelzebub 則把回應生成交給模型，換取更長的互動與更自然的回答，代價是延遲、外部依賴與非決定性。
如果你的目標是蒐集掃描來源與攻擊 payload 樣本，被動蜜罐的資料品質已經足夠，而且不需要處理資料外流問題。如果你要的是讓攻擊者多留幾十分鐘、並觀察他如何逐步探索，模型生成的回應才有意義。另一個分野是協定覆蓋：MCP 誘餌與 prompt injection 偵測在被動蜜罐工具裡幾乎找不到對應功能，這是 Beelzebub 目前較難被取代的位置。
授權、維護成本與升級節奏
授權是 GPL-3.0。這對內部部署通常不構成問題，但如果你打算把 Beelzebub 嵌進對外散布的產品，GPL-3.0 的傳染性條款會影響你的散布方式。這不是法律意見，實際情況請找律師確認。外掛走的是 pkg/plugin 這個公開 SDK，介面本身與主專案分離，但外掛仍與主程式一起編譯。
維護成本主要落在兩處。一是設定檔，服務定義是 YAML 加 regex，改動成本低，但沒有型別檢查，所以 beelzebub validate 應該進 CI，而不是靠執行期才發現。二是外掛，beelzebub plugin install 從 GitHub 抓取並編譯進執行檔，代表每次升級主程式都要重新確認外掛是否仍能編譯。
從版本節奏看，v3.9.1 在 2026-08-31、v3.9.0 在 2026-08-05、v3.8.0 在 2026-06-02，三個版本間隔約一個月到三個月，屬於仍在推進的專案。這意味著 API 與設定格式仍有變動空間，升級前值得先讀 release notes 再動設定檔。
編輯結論
Beelzebub 適合已經有隔離網段、想把誘餌服務標準化成 YAML 設定並願意接上 LLM 的團隊，特別是同時要觀察 MCP 這類 AI 代理攻擊面的人。若你的環境不能讓誘餌流量外送到 OpenAI，或你只需要記錄連線而不需要互動，被動式蜜罐更省事。導入前先跑 beelzebub validate 確認設定可解析，再確認 wirePlugins 的載入順序與記憶體上限是否符合你的服務數量，最後確認 GPL-3.0 對你散布方式的要求。
社群筆記