既存の kali-mcp を Go で再実装してみました。

こんにちは。情報保護学科に在学中の大学生です。

ペネトレーションテスト / トラフィックテスト / CTF 自動化作業で kali-mcp をよく使ってきましたが、複数のエージェントを同時に接続する環境でボトルネックが発生したため、Go で自分で再実装してみました。

GitHub: https://github.com/found-cake/kali-mcp-go

---

既存の kali-mcp の構造と限界

元の実装は Flask + Python で構築されており、CommandExecutor クラスがリクエストごとに subprocess.Popen を生成した後、stdout/stderr をそれぞれ読むための daemon thread を 2 本追加で起動する構造です。

単一エージェントでは十分ですが、multi-agent 環境で同時リクエストが集中すると、次のような問題が発生します。

• Flask のデフォルト単一ワーカー — エージェント同士が互いにブロックする
• リクエストごとにプロセス + thread を生成するオーバーヘッド
• エージェントが応答遅延をタイムアウトと誤認し、同じ作業を再試行する

---

主な変更点

サーバー

• 既存: Flask（デフォルト単一ワーカー）
• 変更: Fiber v3 / fasthttp — 完全な並行性

出力収集

• 既存: daemon thread 2 本による readline ループ
• 変更: goroutine 2 本 + WaitGroup で同期し、stdout/stderr の収集タイミングを明確に合わせて出力の取りこぼしなく処理

timeout/cancel

• 既存: process.wait(timeout=...) + 強制 kill
• 変更: context ベース — パイプまで正確に閉じる

Metasploit 一時ファイル

• 既存: /tmp/mks_msf_resource.rc をハードコード — 同時リクエスト時にレースコンディションの可能性
• 変更: os.CreateTemp — リクエストごとに固有のファイル名で安全に処理

tshark サポート

• 既存: なし
• 変更: 専用エンドポイントを追加

---

アーキテクチャ

従来と同じ 2 ティア構造を維持しつつ、内部を置き換えました。

[AI Client]  →(MCP stdio)→  [mcp-client]  →(HTTP + Bearer token)→  [kali-server]  →(exec)→  [nmap, tshark, ...]