日本語

← 一覧に戻る

CyberStrikeAIデプロイ記録：簡単なツール導入こそ細部が重要

itadol5j

最近、Goで書かれたAIネイティブセキュリティテストプラットフォーム「CyberStrikeAI」をいじっている。「ワンクリックデプロイ」ならcloneしてスクリプトを走らせるだけだと思っていたが、結果的にいくつかの大小の落とし穴を踏んだ。記憶が新しいうちに、プロセス全体を記録しておく——多くの落とし穴は実はツールの問題ではなく、細部に気づかなかったことによるものだ。

CyberStrikeAIデプロイ

まず、これはどんなツールか

CyberStrikeAIは「AIネイティブサイバーセキュリティの行動システム」と位置づけられており、Goで書かれ、計画、実行、人間による監督、証拠の保持、リプレイといった作業を1つの監査可能なワークベースにまとめている。中核構成には、Eino駆動のAgent、MCPネイティブツール、RAGナレッジベース、可視化ワークフロー、攻撃チェーンモデリング分析が含まれる。

100以上のツールレシピが内蔵されており、完全なキルチェーンをカバーする：nmap、masscan、rustscanなどのネットワークスキャン；sqlmap、nikto、gobuster、ffufなどのWebスキャン；nuclei、wpscan、dalfoxなどの脆弱性スキャン；さらにサブドメイン列挙、APIセキュリティ、コンテナセキュリティ、クラウドセキュリティ、バイナリ解析、エクスプロイト、パスワードクラック、フォレンジック、ポストエクスプロイテーションなど。正規のペネトレーションテストに必要な道具を、ほぼすべて組み上げてくれている。

さらにBurp Suiteプラグインとブラウザ拡張もあり、キャプチャしたトラフィックをそのままプラットフォームに投げてAI支援分析ができる。この設計は賢い——既存のワークフローを変える必要がない。

デプロイ前の環境準備

公式の前提条件は2つ。バージョンの線を踏まないよう注意：

  • Go 1.25+（go.modで明確に要求されるバージョン。これ未満ではコンパイル時にエラーになる）
  • Python 3.10+（一部のツールで必要。たとえばapi-fuzzer、http-framework-test）

落とし穴1：Goバージョン。最初、システム標準の古いGoを使ってしまい、コンパイル段階まで進んで初めてエラーが出た。先に go version 確認し、足りなければ公式サイトから新版を入れるのがおすすめ。この種の「前提条件」は最も見落とされやすい。エラーがずっと後の段階で出るからだ。

ワンクリックデプロイ：スクリプトがやってくれること

公式のワンクリックデプロイコマンドは簡潔だ：

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

しかし、run.shが実際にやることは思ったより多い。順番に実行される：

  • ✅ GoとPython環境のチェックと検証
  • ✅ Python仮想環境の作成
  • ✅ Python依存関係のインストール
  • ✅ Go依存関係のダウンロード
  • ✅ プロジェクトのビルド
  • ✅ サービスの起動

細部1：venvはスクリプトが自動管理。venv/ディレクトリはrun.shが自動で作成・保守する。Pythonを必要とするツール（api-fuzzer、http-framework-testなど）は自動でこの環境を使う。自分で手動に作ると競合しやすいのでやめておくこと。

起動の確認：必ず確かめるべき点

スクリプトが終わったら、急いでブラウザを開かず、まずターミナルを見る：

  • ターミナルに● ONLINEと表示されることを確認。その後に実際のWeb UIアドレスが続く
  • そのアドレスを開く：デフォルトのHTTPSモードはローカル自己署名証明書を使うため、ブラウザが警告するが、一度受け入れればよい
  • 新規インストールにはワンタイム管理者パスワードがある：ターミナルのADMIN SETUP REQUIREDの下に表示される。ログイン後すぐに変更する

細部2：HTTPSかHTTPか。run.shはデフォルトで–httpsパラメータを付けて起動する（ローカル自己署名TLS。公式によれば同時接続のストリームにやさしい）。純粋なHTTPにしたい場合は、明示的に ./run.sh --http。手動で起動する場合は、–httpsを付けるか、CYBERSTRIKE_HTTPS=1環境変数を設定する。

本番環境では自己署名証明書を使わず、config.yamlにserver.tls_cert_pathとserver.tls_key_pathを設定すること。

落とし穴2：プロトコル不一致のエラー。ログに「client sent an HTTP request to an HTTPS server」と出たら、TLSポートにhttp://でアクセスしているクライアントがいるという意味だ。URLを直せばよい。サーバー側の設定をいじらないこと。

AIネイティブセキュリティテストプラットフォーム

初回設定：AIチャネルは必須

この設定をしないと、プラットフォームを入れていないのと同じだ。初回起動後、https://127.0.0.1:8080/ にアクセスし（ポートはconfig.yamlのserver.portに従う）、 System Settings → Basic Settings → AI Channel Configurationに入り、チャネルを追加して、provider、Base URL、API key、model、token上限を入力する。

config.yamlを直接編集することもできる。形式はおおむね次の通り：

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

細部3：デフォルトチャネルの適用範囲。ai.default_channelは新規セッションと、チャネルを明示指定しないタスクに使われる。チャットページではセッションごとに、保存済みの任意のチャネルを選べる。だからモデルが複数あっても、1つだけに絞る必要はない。

providerにopenai_compatibleを入力すれば、OpenAI互換インターフェースを持つ大半のサービスに接続できる。base_urlをhttps://api.deepseek.com/v1に、modelをdeepseek-chatに変えてもよいし、qwen3-maxも同様だ。国産モデルを自由に接続でき、これは親切な設計だ。

⚠️ セキュリティ注意：config.yamlに実際のキーをコミットしないこと。公式も実際の認証情報をcommitしないよう明言しており、環境変数で注入する。

アップグレードにも方法がある

公式はワンクリックアップグレードスクリプトを提供しているが、最初に実行権限を与える必要がある：

chmod +x upgrade.sh && ./upgrade.sh –yes

やること：config.yamlとdata/ディレクトリのバックアップ → GitHub Releaseから新コードを取得 → config.yamlのバージョン番号を更新 → サービス再起動。ローカルのtools/、roles/、skills/ディレクトリは常に保持される——これは重要だ。カスタマイズしたツールレシピが上書きされることはない。

落とし穴3：アップグレードスクリプトの依存。Releaseパッケージのダウンロードにはcurlまたはwget、安全なコード同期にはrsyncが必要（公式は推奨/必須としている）。GitHub APIがレート制限にかかった場合は、先に export GITHUB_TOKEN="..." してから再実行する。

問題が起きたら、.upgrade-backup/から復元するか、dataとconfig.yamlを手動でコピーして戻してからrun.shを再実行すればよい。

重要な原則：アップグレード前に必ずターゲットバージョンのrelease notesを確認する。設定、データベース、APIの変更が含まれる場合は特に注意が必要。公式の言葉が実に的確だ——「バックアップは必須。パッチアップグレードであっても。バージョン番号自体は互換性の保証ではない。」

ディレクトリ構成早見

各ディレクトリの役割を把握しておけば、その後の保守で迷わない：

  • cmd/ — サーバー、MCP stdioエントリ、ツール
  • internal/ — Agent、MCPコア、プロセッサ、C2、セキュア実行器
  • web/ — 静的SPAとテンプレート
  • tools/ — YAMLツールレシピ（100+サンプル）
  • roles/ — ロール設定（12+のプリセットセキュリティテストロール）
  • skills/ — Agent Skillsディレクトリ（SKILL.md＋オプションファイル）
  • agents/ — マルチAgent Markdown（orchestrator.md＋サブAgent）
  • config.yaml — 実行時設定
  • run.sh / upgrade.sh — 起動 / アップグレードスクリプト

セキュリティは、ツールが代わりにやってはくれない

このプラットフォームには、WebShell管理、内蔵C2（リスナー、暗号化beacon、セッション、タスクキュー）といった高リスク機能が統合されている。公式の姿勢は極めて明確だ：自分が所有しているか、明確にテストの許可を得たシステムにのみ使用できる。

共有環境や本番環境で高リスクツールを有効にする前に、必ずセキュリティモデルとハードニングガイドを読むこと。さらにツール呼び出しのインターセプトが内蔵されており、MCP実行前に設定可能な正規表現チェックを行い、デフォルトで政府ドメイン保護が有効になっている。

また、デフォルトでは127.0.0.1のみリッスンする。外部にサービスを公開する場合は、必ず先にハードニングを行うこと。これは社交辞令ではなく、痛い目を見た人だけがドキュメントに書く注意書きだ。

ペネトレーションテストプラットフォーム設定

最後に

振り返ると、今回のデプロイ自体に大きな問題は起きなかった。スクリプトがすでに90%の作業をやってくれている。本当にドキュメントを調べる羽目になったのは、すべて「気づかなかった」細部だ：Goのバージョンライン、venvを手動で作らないこと、HTTPSがデフォルト有効によるプロトコル不一致、アップグレード前のバックアップ、キーを設定ファイルに書かないこと。

これらの細部は単体ではどれも難しくないが、1つ漏れるだけで30分ははまる。ツールが成熟するほど「ドキュメントを読む」リターンが大きくなる——複雑さはスクリプトにカプセル化され、残りの複雑さはすべて設定の細部にあるからだ。

プロジェクトはknownsec 404Starlinkに追加され、Apache 2.0ライセンスでオープンソース化されている。正規のセキュリティテストをしている人は試してみるとよい。

ワンクリックデプロイはワンクリック理解を意味しない。細部こそが時間を節約する本当の鍵だ。

プロジェクトアドレス：github.com/Ed1s0nZ/CyberStrikeAI（github.com/AIPentest/CyberStrikeAIに移行済み）
環境要件：Go 1.25+ / Python 3.10+
ライセンス：Apache License 2.0
⚠️ 許可されたテストでのみ使用可能