
クラウドの力でリコンを拡張する

ReconSwarm は、分散型セキュリティテスト向けに設計されたモジュール型偵察自動化フレームワークです。クラウドインフラストラクチャをプロビジョニングし、並列の偵察パイプラインを実行し、最小限の設定オーバーヘッドで結果を収集します。
ReconSwarm は、手動でのインフラ管理を行わずにスケーラブルで自動化された偵察ワークフローを必要とする、バグバウンティハンター、ペネトレーションテスター、DevSecOps エンジニア、セキュリティ研究者に適しています。

ReconSwarm は、クラウドプロビジョニング、リモートシステム制御、パイプライン実行、設定管理の間で明確な関心の分離を持つモジュール型アーキテクチャに従います。
ReconSwarm はクラウドプロビジョナーに識別共用体型パターンを使用します。provisioner.type フィールドがアクティブなプロバイダー設定を決定します。
provisioner:
type: yandex_cloud # 識別子フィールド
yandex_cloud: # type: yandex_cloud のときに有効
iam_token: "${YC_TOKEN}"
# key_path: "./sa_auth_key.json"
folder_id: "${YC_FOLDER_ID}"
# ... プロバイダー固有の設定
追加のクラウドプロバイダーは、Provisioner インターフェースを実装し、ファクトリに新しいタイプを追加することで統合できます。
ステージは、ワーカー VM 上で操作を実行する拡張可能なコンポーネントです。
すべてのステージフィールドはテンプレートレンダリングをサポートします。新しいステージタイプを追加して機能を拡張できます。
ReconSwarm サーバーは完全にステートレスです。すべての状態は etcd に永続化されます。
このアーキテクチャにより以下が可能です。
| 機能 | 説明 |
|---|---|
| 水平スケーリング | ロードバランサーの背後で複数のサーバーインスタンスを実行。 |
| ダウンタイムゼロの再起動 | パイプラインの状態を失わずにサーバーを再起動。 |
| クラッシュリカバリ |
高可用性構成:
┌─────────────┐
│ Client │
└──────┬──────┘
│
┌──────▼──────┐
│Load Balancer│
└──────┬──────┘
┌────────────┼────────────┐
│ │ │
┌──────▼──────┐ ┌───▼───┐ ┌──────▼──────┐
│ Server 1 │ │Server2│ │ Server 3 │
└──────┬──────┘ └───┬───┘ └──────┬──────┘
│ │ │
└────────────┼────────────┘
│
┌──────▼──────┐
│ etcd cluster│
└─────────────┘
すべてのサーバーは同じ etcd クラスターを共有し、任意のリクエストを処理できます。パイプライン実行中にサーバーがクラッシュした場合、別のサーバーが etcd から状態を読み取って実行を継続できます。
注: 現在の実装では、etcd からロードした後、メモリ内でパイプラインを実行します。パイプライン再開を含む完全なクラッシュリカバリは将来のリリースで計画されています。
git clone <repository>
cd reconswarm
go mod download
task build
ReconSwarm はサーバー設定とパイプライン設定を分離します。
| 設定タイプ | ファイル | 説明 |
|---|---|---|
| サーバー | reconswarm.yaml | クラウドプロバイダー、etcd、ワーカープール設定。 |
| パイプライン | 別の YAML ファイル | ターゲットとステージ。-f フラグで指定。 |
サーバー設定は reconswarm.yaml に保存されます(CONFIG_PATH 環境変数で設定可能)。すべての文字列値は ${VAR} または $VAR 構文を使用した環境変数の展開をサポートします。
# Server settings
server:
port: 50051
# Etcd connection for state management
etcd:
endpoints:
- "localhost:2379"
dial_timeout: 5 # seconds
username: "" # optional, supports ${ETCD_USER}
password: "" # optional, supports ${ETCD_PASSWORD}
# Cloud provisioner (discriminated union)
provisioner:
type: yandex_cloud # Provider selector
# Yandex Cloud configuration (active when type: yandex_cloud)
yandex_cloud:
iam_token: "${YC_TOKEN}"
# key_path: "./sa_auth_key.json"
folder_id: "${YC_FOLDER_ID}"
default_zone: "ru-central1-b"
default_image: "fd8b1cmhmncn7lt4tqn4"
default_username: "root"
default_cores: 2
default_memory: 2 # GB
default_disk_size: 20 # GB
# Worker pool settings
workers:
max_workers: 5
setup_commands:
- "apt update"
- "apt install -y docker.io"
パイプライン設定は別の YAML ファイルに保存し、-f フラグで指定します。ラップ形式とアンラップ形式の両方をサポートします。
ラップ形式(推奨):
# pipeline.yaml
pipeline:
targets:
- value: "example.com"
type: crtsh
- value: ["sub1.example.com", "sub2.example.com"]
type: list
stages:
- name: "Run scanner"
type: exec
steps:
- "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"
- name: "Collect results"
type: sync
src: "/opt/recon/scan.txt"
dest: "./results/{{.Worker.Name}}.txt"
アンラップ形式(同様にサポート):
# pipeline.yaml
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Run scanner"
type: exec
steps:
- "nmap -iL {{.Targets.filepath}} -oN /opt/recon/scan.txt"
設定値は、以下の2つの形式で環境変数の置換をサポートします。
${VAR} — 中括弧内の完全な変数名$VAR — 単純な変数名環境変数が設定されていない場合、リテラル文字列(${VAR} または $VAR を含む)がそのまま使用されます。
Yandex Cloud との統合には、提供されているセットアップスクリプトを使用します。
Yandex Cloud CLI のインストール(まだインストールされていない場合):
# 公式の Yandex Cloud ドキュメントに従って CLI をインストール
Yandex Cloud CLI の設定:
yc config profile create <profile-name>
yc config set cloud-id <your-cloud-id>
yc config set folder-id <your-folder-id>
認証情報のエクスポート:
source ./secrets-setup.sh
このスクリプトは以下をエクスポートします。
YC_TOKEN — 認証用の IAM トークンYC_FOLDER_ID — リソース管理用のフォルダ IDYC_CLOUD_ID — クラウド ID(必要な場合)設定で参照:
provisioner:
type: yandex_cloud
yandex_cloud:
iam_token: "${YC_TOKEN}"
# key_path: "./sa_auth_key.json"
folder_id: "${YC_FOLDER_ID}"
secrets-setup.sh スクリプトは、実行するたびに新しい IAM トークンを自動生成するため、認証情報をハードコードせずに安全な認証が可能です。
サービスアカウントの作成:
環境の設定:
export GCP_PROJECT_ID="your-project-id"
export GCP_CREDENTIALS_PATH="/path/to/key.json"
設定で参照:
provisioner:
type: gcp
gcp:
project_id: "${GCP_PROJECT_ID}"
credentials_path: "${GCP_CREDENTIALS_PATH}"
default_zone: "us-central1-a"
IAM ユーザーの作成:
環境の設定:
export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
設定で参照:
provisioner:
type: aws
aws:
region: "us-east-1"
access_key_id: "${AWS_ACCESS_KEY_ID}"
secret_access_key: "${AWS_SECRET_ACCESS_KEY}"
default_zone: "us-east-1a"
トークンの生成:
環境の設定:
export DO_TOKEN="your-token"
設定で参照:
provisioner:
type: digitalocean
digitalocean:
token: "${DO_TOKEN}"
default_region: "nyc1"
crt.sh 列挙:
targets:
- value: "example.com"
type: crtsh
手動リスト:
targets:
- value: ["sub1.example.com", "sub2.example.com"]
type: list
すべてのステージ設定フィールドは、動的な値生成のために Go テンプレート構文をサポートします。テンプレート変数は実行時にレンダリングされ、コンテキストデータが自動的に提供されます。
テンプレートコンテキスト
すべてのステージテンプレートで以下のデータが利用可能です。
| 変数 | 説明 |
|---|---|
{{.Targets.filepath}} | リモート VM 上のターゲットファイルへの絶対パス。 |
{{.Targets.list}} | プログラムによるアクセス用のターゲット文字列の配列。 |
{{.Worker.Name}} | ワーカー VM インスタンスの一意の識別子。 |
Exec ステージ — テンプレートサポート付きでシェルコマンドを実行:
stages:
- name: "Run tool"
type: exec
steps:
- "docker run --rm -v /opt/recon:/data scanner:latest {{.Targets.filepath}}"
- "cat /opt/recon/results.json"
steps 配列内のすべてのコマンドは、実行前にテンプレートレンダリングが行われます。
Sync ステージ — SFTP を使用してリモートからローカルにファイルまたはディレクトリをコピー。パスがファイルかディレクトリかを自動検出します。
stages:
- name: "Collect results"
type: sync
src: "/opt/recon/results.json"
dest: "./results/{{.Worker.Name}}.json"
# Sync entire directory recursively
- name: "Collect all results"
type: sync
src: "/opt/recon"
dest: "./results/{{.Worker.Name}}"
src(リモートパス)と dest(ローカルパス)の両方が、動的なファイルパスのためのテンプレートレンダリングをサポートします。sync ステージはソースパスがファイルかディレクトリかを自動検出し、それに応じて処理します。
gRPC サーバーを起動してパイプラインの送信を受け付けます。
reconswarm server
サーバーは reconswarm.yaml から設定を読み取り、設定されたポート(デフォルト: 50051)で待機します。
実行中のサーバーにパイプラインを送信します。
reconswarm run -f examples/pipelines/nuclei.yaml
オプション:
-f, --pipeline — パイプラインファイルへのパス(必須)-s, --server — サーバーアドレス(デフォルト: localhost:50051)reconswarm status <pipeline-id>
gRPC サーバーを使わずにパイプラインを直接実行(テストに便利)。
reconswarm manual -f examples/pipelines/nuclei.yaml
このコマンドは:
reconswarm.yaml からサーバー設定を読み取る。workers.max_workers 設定に基づいてワーカー VM を作成する。自動的なインフラ解放により完全な自律性が確保され、すべてのクラウドリソースが手動介入なしにプロビジョニング、使用、破棄されるため、完全に自動化された偵察ワークフローが可能になります。
完全なパイプラインの例については、examples/pipelines ディレクトリを参照してください。
基本的なサブドメイン列挙とスキャン:
# pipeline.yaml
pipeline:
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Scan targets"
type: exec
steps:
- "nmap -sC -sV -iL {{.Targets.filepath}} -oN /opt/recon/nmap-{{.Worker.Name}}.txt"
- name: "Collect results"
type: sync
src: "/opt/recon/nmap-{{.Worker.Name}}.txt"
dest: "./results/nmap-{{.Worker.Name}}.txt"
実行方法:
reconswarm manual -f pipeline.yaml
# またはサーバーに送信:
reconswarm run -f pipeline.yaml
Docker ベースのスキャンによる複数ターゲット:
pipeline:
targets:
- value: "example.com"
type: crtsh
- value: ["api.example.com", "www.example.com"]
type: list
stages:
- name: "Run nuclei scan"
type: exec
steps:
- "docker run --rm -v /opt/recon:/data projectdiscovery/nuclei:latest -l {{.Targets.filepath}} -json -o /opt/recon/nuclei-{{.Worker.Name}}.json"
- name: "Copy nuclei results"
type: sync
src: "/opt/recon/nuclei-{{.Worker.Name}}.json"
dest: "./results/nuclei-{{.Worker.Name}}.json"
複数ステージのカスタムツールチェーン:
サーバー設定 (reconswarm.yaml):
workers:
max_workers: 5
setup_commands:
- "apt update"
- "apt install -y git golang"
- "git clone https://github.com/projectdiscovery/subfinder.git"
- "cd subfinder && go build"
パイプライン設定 (pipeline.yaml):
pipeline:
targets:
- value: "example.com"
type: crtsh
stages:
- name: "Additional enumeration"
type: exec
steps:
- "cd subfinder && ./subfinder -dL {{.Targets.filepath}} -o /opt/recon/subfinder-{{.Worker.Name}}.txt"
- name: "Merge targets"
type: exec
steps:
- "cat {{.Targets.filepath}} /opt/recon/subfinder-{{.Worker.Name}}.txt | sort -u > /opt/recon/all-targets-{{.Worker.Name}}.txt"
- name: "Scan merged targets"
type: exec
steps:
- "nmap -sC -sV -iL /opt/recon/all-targets-{{.Worker.Name}}.txt -oN /opt/recon/scan-{{.Worker.Name}}.txt"
- name: "Collect all results"
type: sync
src: "/opt/recon"
dest: "./results/{{.Worker.Name}}"
注: sync ステージは /opt/recon がディレクトリであることを自動検出し、すべてのファイルとサブディレクトリをローカルの宛先に再帰的にコピーします。
サブドメイン列挙:
reconswarm crtsh-dump example.com
指定されたドメインの crt.sh から解決可能なサブドメインを取得してフィルタリングします。
デバッグコマンド(VM プロビジョニングのテスト用):
reconswarm debug
Task を使用してビルドおよびテストします。
task build # Build binary
task test # Run tests
task lint # Run linter
task vet # Run go vet
task ci # Run all CI checks
notify ステージを追加 — 通知またはアラートを送信(Webhook、メール、Slack)conditional ステージを追加 — 前のステージの結果に基づいてステージを実行parallel ステージを追加 — 同じワーカー上で複数の操作を同時に実行retry ステージを追加 — 設定可能なバックオフで失敗した操作を自動リトライtimeout ステージを追加 — ステージごとに実行タイムアウトを設定validate ステージを追加 — 進む前に結果または条件を検証MIT ライセンス。詳細は LICENSE ファイルを参照してください。
| 新しいサーバーインスタンスが前のインスタンスの続きから実行。 |
| 状態検査 | デバッグと監視のために etcd を直接クエリ。 |