network-appliance-offensive

ネットワークアプライアンスのオフェンシブセキュリティ

firewall-review は 設定 を静的に監査し、infrastructure は 汎用的な ポート／DNS／SMB を対象とします。どちらも稼働中の境界 アプライアンス や、その VPN 暗号 をテストしません。そのため、IKE ビルダー、SIC／OPSEC フィンガープリンティング、TTL 判別器は、エンゲージメントのたびに生ソケットから再実装されてきましたが、多くの場合は不十分で、CVE の適用可能性は環境全体で UNDETERMINED のままになっていました。このスキルでは、決定論的でテスト済みのツールと、前提条件でゲートされた手法を提供します。非破壊のみです。すべてのツールは観測／デコード／推論を行い、エクスプロイトを実行するものはありません。また、CVE の適用可能性はあくまで 前提条件の確認 であり、盲目的に「脆弱」と判定するものではありません。

ツール

ツール	内容	誤用防止策
tools/ike_enum.py	IKEv1 アグレッシブモードの検出、IKEv1／IKEv2 のトランスフォームと DH グループの列挙、NOTIFY／NAT-T のデコード（ike-scan をラップし、未使用時は生の ISAKMP SA_INIT ビルダーにフォールバック）	アグレッシブモードのサポート（PSK ハッシュの漏えい）が検出事項です。列挙にとどめ、インバンドでクラックしないでください
tools/checkpoint_sic_opsec.py	SIC（18190/1）、OPSEC LEA/ELA（18183/4）、CA（18192/18210）、FW1（256/264）、Gaia Portal をフィンガープリントし、CVE-2024-24919 を含む CVE の前提条件マップを出力	CVE-2024-24919 が applicable になるのは、RA／Mobile-Access マーカーが観測された場合のみです。それ以外は undetermined です
tools/appliance_version_infer.py	ヘッダー、ログインマーカー、証明書の CN／シリアルから FortiGate／PAN-OS／Cisco ASA／Citrix のファームウェア／パッチレベルを安全に推定し、CVE の適用可能性を判定	信頼度が低い場合やバージョンが不明な場合に applicable と断定することはありません。undetermined を返します
tools/tls_handshake_probe.py	プロトコルを固定してハンドシェイクを完了し、サポートされている TLS バージョンを確認	openssl s_client の終了コード／SECLEVEL による誤検知を防ぎます。ハンドシェイクの中断はサポートを意味しません
tools/ntlm_decode.py	NTLM Type-2（CHALLENGE）の AV_PAIR ブロックをデコードし、NetBIOS／DNS ホスト、ドメイン、フォレスト、OS ビルドを取得	認証されていないチャレンジからの情報漏えいを検出します。認証は試行しません
tools/perimeter_forensics.py	RST-TTL 偽造判別器（実ホストか、RST を偽造するファイアウォールかを判別）と IKE NOTIFY デコード	RST だけを根拠に「FW の背後に内部ホストがある」と断定しません。このレイヤーではファイアウォールが判別不能な RST を偽造できます。開いているサービスの TTL 基準値がなければ undetermined を返します

ワークフロー

1. アプライアンスを特定する — ポートの組み合わせ、バナー、ログインマーカーから、appliance_version_infer.py（ベンダー＋バージョンの推定＋信頼度）を実行し、Check Point の場合は checkpoint_sic_opsec.py も実行します。バージョンの推定結果が undetermined または低信頼度の場合は、undetermined のままにします。そのバージョンに対して CVE を評価してはいけません。
2. VPN 暗号 — UDP 500/4500 で ike_enum.py を実行します。IKEv1 のアグレッシブモード（PSK ハッシュが漏えいするため、指摘事項になります）を検出し、受け入れられるトランスフォームと弱い DH グループ（1/2/5）を列挙して、NAT-T/NOTIFY をデコードします。IKEv1 RA が存在しない場合は IKEv2 のみです（IKEv1 アグレッシブモードを必要とする CVE は、その場合 not_applicable です。severity-calibration.md のルール 5 を参照）。
3. TLS の状態 — ホストごとに tls_handshake_probe.py を実行し、ハンドシェイクが完了したバージョンのみを報告します。TLS 1.0/1.1 のハンドシェイク完了が、弱いプロトコルに関する指摘事項です（openssl の終了コードではありません）。
4. 情報漏えい — NTLM Type-2 チャレンジがあれば、ntlm_decode.py でデコードし、内部ホスト、ドメイン、OS の情報を取得します。情報漏えいに関する指摘事項として記録します。
5. CVE の該当性（前提条件による判定） — 検出されたアプライアンスの各 CVE について、手順 1 のベンダーとバージョン、および前提条件マップ（checkpoint_sic_opsec / appliance_version_infer の applicability）を使って、applicable / undetermined / not_applicable のいずれかに分類します。python3 tools/nvd-lookup.py で CVE の情報を補完します。該当性が undetermined の場合は、そのまま報告します。確認済みの脆弱性として扱ってはいけません。
6. フォレンジック — 「closed」と表示されたホストがファイアウォールの背後で稼働しているように見える場合、何かを断定する前に perimeter_forensics.py --classify-ttls を実行します。実ホストの RST と、フィルターが偽造した RST を区別します（オープンサービスの TTL ベースラインが必要です。ない場合は undetermined とします）。

アンチパターン

• バナーに表示されたバージョンだけで、アプライアンスの CVE を確認済みとして評価してはいけません。バナーはバックポートや偽装が可能です。applicability に基づいて判定してください（severity-calibration.md のルール 4-5）。
• openssl s_client がゼロ以外の終了コードを返したことを根拠に、TLS 1.0/1.1 をサポートしていると主張してはいけません。ハンドシェイクの完了が必要です（tls_handshake_probe.py）。
• RST を根拠に「ファイアウォールの背後に内部ホストがある」と断定してはいけません。ファイアウォールは RST を偽造します。TTL による判別を使い、undetermined の結果を受け入れてください。
• エンゲージメント中に IKE アグレッシブモードの PSK ハッシュをその場でクラックしてはいけません。アグレッシブモードの露出を捕捉して指摘することが目的です。オフラインでのクラックには明示的な許可が必要です。

参照

• 静的な対応資料：firewall-review（設定監査）。一般的なネットワーク情報：infrastructure。
• CVE の前提条件／該当性の取り扱い：../coordination/reference/severity-calibration.md（ルール 4-5）。