自動ブロックパイプライン

概要 — 何をする機能か

自動ブロックは、攻撃元 IP を人手を介さずに検知・審査・遮断する InfraGuard のバックグラウンドパイプラインです。これは画面ではなく、コレクター・スケジューラ・カーネル ipset をまたぐ流れです。本記事ではその全体構造を解説します。

このパイプラインには、単一の適用点（ipset）に合流する2つの独立したブロック経路があります。

どちらの経路も、ブロックの直前にホワイトリストと無罪判定のチェックを実行します。 確証のある悪用だけが残り、誤検知の可能性が高い候補は免責されます。経路 ②（スケジューラ）は既定で OFF であり、管理者が有効化する必要があります。

いつ使うか

• ボットネット・スキャナー・ブルートフォース探索が絶え間なく到来し、手動のブロックでは追いつかないときに、自動防御を有効にします。
• 検知 ▸ JA3 にフィンガープリントをローテーションするボットネットが現れたら、それを自動的に捕捉できるようしきい値を調整します。
• 脅威 で特定の重大度（赤／橙）の IDS 警報を繰り返し発生させる送信元を、自動的にブロックしたいとき。
• ブロックリスト・評判 に蓄積されるブロック理由を確認し、過剰なブロックをホワイトリストで免責するとき。

画面構成

自動ブロックに専用の画面はありません。制御と観測のポイントは次のとおりです。

• 設定 — 運用ポリシー ▸ セキュリティ設定タブ ▸ 自動ブロックカード（マスタースイッチ・方式・範囲・トリガー・無罪判定）。
• 結果の観測 — ブロックリスト・評判（コレクターの /24 ＋ スケジューラの /32 のブロック、理由、解除）。
• 免責 — ホワイトリスト（手動／自動無罪判定の IP・CIDR、有効期限つき）。
• トリガー元 — 脅威（IDS 重大度）、検知（JA3 ローテーション）。

使い方

1. 経路 ② スケジューラ自動ブロック — 有効化とチューニング

既定は OFF です（autoblock_on=0）。運用ポリシー ▸ セキュリティ設定でマスタースイッチを入れ、そのうえでポリシーを調整します。

方式（mode）

範囲（scope）

トリガー（OR — 候補はどちらか一方を満たすだけで成立）

① IDS ルールセット重大度   suricata_alert_ct
   WHERE alert_ts >= NOW() - INTERVAL {window_min} MINUTE
     AND severity <= {sev_max}          -- crit=1, warn=2（Suricata: 1=最重大 … 3=低）
   GROUP BY src_ip HAVING COUNT(*) >= {sev_count}

② JA3 ローテーション型ボットネット   suricata_tls_ct
   WHERE event_ts >= NOW() - INTERVAL {ja3_window_min} MINUTE
     AND ja3_hash IS NOT NULL
   GROUP BY src_ip HAVING COUNT(DISTINCT ja3_hash) >= {ja3_rotation}

重大度トリガーが使う時刻カラムは alert_ts ですが、JA3 トリガーが使うのは event_ts です（テーブルごとに異なります）。しきい値を調整する際は、それぞれの期間がどのカラムで絞り込まれるのかに注意してください。

ポリシーの既定値（OpsPolicy::autoBlock()）

JA3 ローテーションのチューニング（実測）: 実環境の JA3 ローテーション攻撃者は、/32 セッションあたり相異なる JA3 が約 32 個でピークに達するのが典型です（データセンター／クラウドのボットで、GREASE を使わないため安定していてブロックしやすい）。したがって既定の ja3_rotation=50 では何も捕捉できません。 実際に発火させるには 15–20 程度まで下げてください。まず --dry を実行して候補の件数を確認します。

2. 候補の審査順序（AutoBlockService::run）

収集された候補 IP は、実際にブロックされる前に、次の関門を順番に通過しなければなりません。

1. 内部・自社網の除外 — SecurityScope::isInternal($ip) が真ならスキップします（skipped_internal）。この判定は、登録済みインスタンスの IP（/24 接頭辞＋完全一致 IP）と、運用ポリシーの internal_networks ホワイトリストを統合したものです。クエリ段階でも excludePrefixes() を NOT LIKE であらかじめ除外しています。
2. ホワイトリストによる免責 — infr_whitelist に有効かつ期限切れでない /32 または /24 のエントリがあればスキップします（skipped_wl）。
3. 無罪判定による拒否 — ハードシグナル（重大度トリガー）を持たない JA3 単独の候補にのみ適用されます。reputation_cap の予算内で AbuseIPDB の評判を照会し、その IP が完全に潔白（悪用スコア 0 かつ 通報 0 かつ Tor でない）であれば、ブロックする代わりに innocent_days 日間の自動ホワイトリスト登録（infr_whitelist(source=auto)）を行います（innocent）。重大度による候補はこの関門を飛ばし、そのままブロックされます。
4. server_index の解決 — global→[0]、per_server→対象の dest_ip を ServerIndexResolver::byIp で解決します（解決できなければ [0]）。
5. 書き込み — InfrBlock::updateOrCreate([server_index, cidr], …) により infr_block へ upsert し、source='schedule'、is_active=true、reason='[InfraGuard Auto] …' を付与します。

候補の収集（OR） → 内部の除外 → ホワイトリスト → （JA3 単独）無罪判定による拒否 → server_index → infr_block へ書き込み

isSpotless() は、評判の照会が失敗した場合・未設定の場合・判定できなかった場合に false（＝慎重にブロックする）を返します。無罪による免責は、IP が明らかに潔白なときにだけ発動する保守的な関門です。

3. スケジューラとコマンド

infr:auto-block はデーモンではなく、1回だけ評価して終了する単発コマンドです。スケジューラは毎分 tick しますが、実効的な間隔は autoblock_interval_min です。

# ゲートを確認し（ポリシーが OFF なら即座に no-op）、1回だけ評価して書き込む
php artisan infr:auto-block

# 書き込みを行わず候補の集計だけを行う（チューニング・検証用）
php artisan infr:auto-block --dry

# ポリシーのゲート（有効化・間隔）を迂回して1回だけ強制実行する
php artisan infr:auto-block --force

# 何もブロックしなかった場合は出力を抑制する（スケジュール用）
php artisan infr:auto-block --quiet-if-ok

スケジュールへの登録（routes/console.php）:

Schedule::command('infr:auto-block --quiet-if-ok')
    ->everyMinute()
    ->withoutOverlapping(2)
    ->onOneServer()
    ->when($is_leader);   // リーダーゲーティング — 複数台のうち1ノードだけ

ゲートのロジック:

• autoblock_on=0 → コマンドは即座に「スキップ」と報告します（既定は OFF で安全）。
• 前回の実行から間隔がまだ経過していない → スキップします。
• --force と --dry はゲートを迂回します。

出力例:

infr:auto-block — 候補 12（sev 3 · ja3 9） · ブロック 7 · wl-skip 1 · internal-skip 2 · innocent 2

4. 経路 ① コレクター自動ブロック（Node）

各ホスト上の Node コレクターは、Suricata のイベントを取り込み、/24 単位で blacklist_info に直接ブロックを書き込みます。この経路はスケジューラ（経路 ②）から独立しており、常に動作します。

srct_tx の5つの脅威分類:

(A) [HTTP] URL スキャナー      .env / .git / wp-login などスキャナー特有の URL
(B) [HTTP] ボット User-Agent   curl / python-requests / sqlmap などツールの痕跡
(C) [HTTP] 総当たり探索        短時間に大量の 4xx 応答（パスの総当たり）
(D) [TLS]  JA3 異常            JA3 が多数、SNI が欠落などボットネットのフィンガープリント
(E) [FLOW] TCP フラグ異常      短いスキャンセッションが多数（ポートスキャン）

srct_tx もブロックの直前にホワイトリストによる絞り込みと自動無罪免責を実行します。AbuseIPDB の評判を照会するのは E-only（短いスキャン単独）の候補だけで、明らかに潔白（通報 0 · 悪用スコア 0 · Tor でない）であれば 30 日間の免責（infr_whitelist(source=auto)）として登録し、ブロックを見送ります。ハードシグナル（A/A2/B/C/D）が1つでもあれば、そのままブロックします。定数としきい値は規則としきい値で管理します。

5. 経路 ③ 適用 — sync_black → ipset

infr_sync_black.mjs は各ホストで定期的に実行され、両方のリストをカーネル ipset blacklist に同期します。

# ホストごとに、その server_index を指定して実行する（root 権限が必要）
node infr_sync_black.mjs sv=4

# crontab（5分ごと。重複実行を防ぐため flock を使用）
*/5 * * * * /usr/bin/flock -n /var/run/sync_black.lock \
  /usr/bin/node /root/server_monitor/infr_sync_black.mjs sv=4 \
  >> /var/log/sync_black.log 2>&1

動作:

1. server_index IN (0, <sv>) AND is_active/is_use=1 の条件で blacklist_info（/24）＋ infr_block（/32）を読み込みます。
2. balanced の重複排除 — 親の /24 がすでに覆っている /32 はスキップします。
3. カーネル ipset を hash:net に強制します（型が異なる場合は作り直し）。一時セットに読み込んだうえで、アトミックに入れ替えます（無停止）。
4. iptables -I INPUT -m set --match-set blacklist src -j DROP が存在することを保証します（冪等）。
5. 安全網 — プライベート（RFC1918）・ループバック・自社網の接頭辞（HOME_NET_PREFIX）は、たとえ DB に紛れ込んだとしても ipset には決して読み込みません。

sync_black には root 権限とカーネルの ipset／iptables ツールが必要で、さらに対象ホストに blacklist ipset があらかじめ存在していなければなりません:

ipset create blacklist hash:net family inet hashsize 8192 maxelem 65536
iptables -I INPUT -m set --match-set blacklist src -j DROP

データソース

情報源テーブルと記録テーブルはすべて legacy_glory 接続（コレクターと適用スクリプトが共有する DB）上にあります。

infr_block のスキーマ（要約）

アクセス権限

自動ブロックに利用者向けの実行 UI はありません。関係する権限のゲートは次のとおりです（レベル: demo=1 · staff=5 · admin=10）。

スケジューラが使う認証情報はハードコードされておらず、infr_collector ／ .env に外部化されています。sync_black の DB 認証情報と自社網の接頭辞も同様に、環境変数またはインベントリ ▸ ツールのマッシュアップ置換によって注入されます（ハードコードなし）。

トラブルシューティング・FAQ

有効にしたのに何もブロックされません。

• --dry で候補の件数を確認します: php artisan infr:auto-block --dry。
• JA3 のしきい値が高すぎる可能性が高いです（既定は 50）。実際の攻撃者は約 32 前後なので、15–20 まで下げてください。
• 重大度トリガー: autoblock_severity=crit は sev≤1（赤）しか捕捉しません。橙も含めるには warn（sev≤2）に設定します。
• 候補がすべて internal-skip／wl-skip になる場合は、運用ポリシーの内部網ホワイトリスト、またはホワイトリストを確認してください。

ブロックが実際のファイアウォールに届いていません。

• infr_block のエントリは、sync_black が実行されるまで適用されません。対象ホストの cron、sv=<server_index> 引数、blacklist ipset の存在を確認してください。
• balanced の範囲では、親の /24 にすでに含まれる /32 は意図的に重複排除され、個別には読み込まれません（これは正常です）。

無関係な IP がブロックされました。

• ホワイトリストに /32 または /24 で登録すると、次のスイープから免責されます（既存の infr_block の行はブロックリストから解除してください）。
• 自動無罪による免責は JA3 単独の候補にのみ適用されます。重大度トリガーで捕捉された IP は評判に関係なくブロックされるため、手動での免責が必要です。

per_server なのに、記録が全体（server_index=0）として残ります。

• 対象の dest_ip を infr_server_index で解決できない場合は、安全側に倒して [0] にフォールバックします。コレクター／インスタンスの IP 対応を確認してください。

スケジューラが複数のサーバーで同時に実行されます。

• ->onOneServer()->when($is_leader) のリーダーゲーティングにより、1ノードだけが実行します。リーダーロックの状態は観測ダッシュボードで確認してください。

関連項目

• 運用ポリシー — 自動ブロックのマスタースイッチ・トリガー・範囲（セキュリティ設定タブ）
• ブロックリスト・評判 — 自動ブロックの結果一覧・理由・解除
• ホワイトリスト — 免責する IP／CIDR、自動無罪による免責
• 検知 ▸ JA3 — JA3 ローテーショントリガーの情報源
• 脅威 — IDS 重大度トリガーの情報源
• IP 評判（AbuseIPDB） — 無罪判定による拒否のための評判照会