Cisco ASAとFTDのSSL VPNでDoS悪用を確認｜二次認証の設定と修正版を点検

Ciscoは2026年10月28日、Secure Firewall ASAとSecure Firewall Threat Defense（FTD）のリモートアクセスSSL VPNに、認証不要の遠隔攻撃で機器を再起動させる脆弱性CVE-2026-76418を公表しました。PSIRTは同月中の悪用を把握しており、修正版への更新を強く推奨しています。VPNを通じて本番環境を保守する組織は、接続不能が復旧作業を妨げる前に、稼働版とトンネルグループの二次認証設定を確認してください。

Cisco公式勧告の評価はHigh、CVSS v3.1は8.6です。本稿は10月29日に確認した修正情報と運用上の点検を扱います。一般的なVPN障害の記事ではなく、対象設定で成立するDoSへの対応です。以降の作業順や記録方法は本サイトの提案であり、実機で攻撃や修正効果を測定した結果ではありません。

ログインを成功させなくても再起動に至る

問題は、トンネルグループに二次認証を設定した際の処理のロジックエラーです。細工されたSSLリモートアクセスVPNへの接続要求により、機器が予期せず再起動する可能性があります。Ciscoは、問題の処理経路へ到達するためにVPNログインの成功は不要と説明しています。

本サイトの分析では、通常利用者のパスワードを変更したことや、ログイン成功の記録が見当たらないことだけでは、このDoSへの対処を終えられません。認証する前の接続が入口になるため、認証情報の保護と、接続先装置の脆弱性修正を別の対策として扱う必要があります。

この勧告が示す直接の影響は可用性です。今回の1件から、情報窃取、認証回避によるVPN内への侵入、遠隔コード実行まで確認されたと読み替えないでください。悪用の規模や被害組織の一覧も公表内容からは確定しません。再起動があっただけで本件の攻撃と断定することもできません。

影響判定は稼働版・到達性・二次認証を組み合わせる

対象は、脆弱なASAまたはFTDを動かし、SSL VPNのログインサービスへ到達でき、勧告が示すトンネルグループの範囲で二次認証を使用している構成です。Cisco製品を持つという理由だけで全台を影響ありにしたり、製品名が違う管理画面の更新だけで対応済みにしたりしないようにします。

最初に運用台帳と実機を対応付け、装置名、ASAかFTDか、稼働するソフトウェアの完全な版番号、SSL VPNを有効にしたインターフェースを残します。設定にwebvpnがあり、少なくとも一つのインターフェースで有効になっているかが確認点です。次の例は公式が示す設定の形であり、本番へ追加するための例ではありません。

webvpn
 enable <interface_name>

FTDでは、FMCのDevices > VPN > Remote Access、またはFDMのRemote Access VPNから管理する構成が示されています。管理画面に設定があることだけでなく、配備したポリシーと装置の実行中設定を照合します。変更を保存した状態と、対象装置へ配備済みの状態を混同しないことが重要です。

Web運用チームは、装置の所有部門だけでなく、そのVPNを通る作業を確認します。本番サーバーの保守、障害時のログ取得、委託先の緊急接続に利用しているなら、VPN停止は公開サイトの復旧にも影響し得ます。これは自社構成で評価する業務上の影響であり、今回の脆弱性によって公開サイト自体が直接攻撃されたという説明ではありません。

外部の保守会社に点検を依頼する場合は、「VPNを更新したか」だけでなく、対象装置の稼働版、SSL VPNの公開インターフェース、一覧設定の有無、既定グループの二次認証、適用した修正を回答項目にします。管理画面を運営する組織と実機の保守者が異なる場合も、同じ装置の結果であることを照合できます。

グループ一覧を消しても既定グループの確認が残る

tunnel-group-list enableを使用している場合、ログイン画面で目にするプロファイルだけで確認を終えません。CiscoはDefaultWEBVPNGroupを含む全トンネルグループでsecondary-authentication-server-groupを確認するよう案内しています。表示されているものだけを台帳にすると、既定の経路を取りこぼす可能性があります。

グループ一覧が無効、またはno tunnel-group-list enableで削除済みの場合も、DefaultWEBVPNGroupの二次認証設定が確認対象です。既定グループで二次認証を使っているなら、一覧を非表示にしたことだけでは露出がなくなりません。「画面から選べない」と「影響する処理へ届かない」は別の判断です。

担当を分けるなら、画面上のプロファイル名、実行中設定のトンネルグループ名、既定グループの確認結果を一組にして引き継ぐ方法を提案します。使っていないはずの設定が見つかっても、その場で削除せず、利用部門と保守契約を確認します。緊急時の接続先だけがその設定を使っている場合、削除が復旧経路を失わせるためです。

最初の修正版と実際に選ぶ更新先を分ける

公式のFixed Software欄が示す修正を初めて含む版は次のとおりです。これは機種や途中経路を問わず直接更新できるという一覧ではありません。系列をまたぐ場合や、表にない稼働版の判断は、勧告のSoftware Checkerと対応する互換性・アップグレード資料へ進んで確認してください。

製品・系列	最初の修正版
ASA 9.16以前	9.16.4.104
ASA 9.18	9.18.4.96
ASA 9.20	9.20.4.50
ASA 9.22	9.22.3.200
ASA 9.23	9.23.1.48
ASA 9.24	9.24.1.27／9.24.10.1
FTD 7.0以前	7.0.11
FTD 7.2	7.2.13
FTD 7.4	7.4.9
FTD 7.6	7.6.7
FTD 7.7	7.7.14
FTD 10.0	10.0.3
FTD 10.1	10.1.1

一つの番号との大小だけで、別の分岐や特別なビルドまで一括判定しないようにします。Software Checkerには、個別勧告の最初の修正版と、検索で見つかった複数の勧告をまとめて修正する版を区別する機能があります。今回だけを直す候補と、保有装置で必要なほかの修正を含む候補を比較するための情報です。

Cisco ASAアップグレードガイドは、現在版から目標版への経路、必要な中間版、途中・目標版の制約、フェイルオーバーやクラスタへの注意、設定のバックアップを事前に確認するよう案内しています。修正番号が決まっても、更新可能な経路と作業中の管理手段を用意する工程が残ります。

例えば同ガイドは、ASA Virtualを9.24(1)へ更新した後、以前の版へダウングレードできない制約を示しています。通常の切り戻しを前提とした手順を、そのまま全機種・全系列へ適用できません。機器別の制約は今回のDoSの成立条件とは別ですが、修正を安全に反映する判断に関係します。

暫定緩和策では二次認証の保護を弱めない判断が必要

勧告は脆弱性を解消するワークアラウンドはないとしつつ、設定に応じた一時的な緩和策を説明しています。既定グループで二次認証を使わない場合はグループ一覧を無効にする方法、既定グループで使う場合はその二次認証を外す方法です。修正版への更新を優先するという推奨は変わりません。

後者にはリモートアクセスVPNの安全性を下げる影響があるとCisco自身が注意しています。本記事は、停止を避けるために認証を一律に弱める操作を勧めません。利用者がプロファイルを選ぶ方法の変化や認証ポリシーへの影響を評価し、担当者が判断できない場合は保守提供元と調整してください。

暫定変更を採る場合の運用案は、対象グループ、変更前後の設定、適用期限、更新後に戻す責任者を残すことです。一覧非表示で対応した装置と、二次認証を外した装置を同じ「緩和済み」にまとめないでください。設定別に残る条件と、通常の保護へ戻す作業が異なります。

更新後は実行版と認証経路を確認する

ここからは本サイトの確認案です。更新後の稼働版を各装置で確認し、取得したファイル名や管理画面の配布予定だけで完了にしません。冗長構成では片側だけが更新済みになっていないかを確認し、保守担当が使う経路からも管理を継続できる状態を確かめます。

VPNの正常性確認は、承認したテスト用アカウントと接続端末で行います。業務で利用するプロファイルごとに接続、二次認証、必要な宛先への到達、切断を確認し、不要な範囲へアクセスできるようになっていないかも見ます。脆弱性の再現要求を本番へ送って安全性を試す必要はありません。

接続できない場合は、更新そのものの失敗、配備設定の食い違い、プロファイル選択の変更、認証先への通信を分けて調べます。今回の更新と同時に複数の設定を変えるほど原因の特定が難しくなるため、変更履歴と接続結果を対応付けて残す方法を提案します。

再起動の記録を修正状況と並べて調べる

悪用が確認されている以上、未更新期間に予期しない再起動やVPN切断があれば、時刻、監視通知、取得可能な装置・認証側の記録を保守担当へ渡します。通常の保守再起動や電源・資源の問題との区別に必要な情報です。確認した勧告には、これだけで攻撃を特定できるログ文字列や判定式は示されていません。

本サイトは特定の検知ルールや攻撃元IPを推測して追加しません。Cisco PSIRTによる悪用の把握と、自社装置で攻撃があったという証拠は別です。一方、再起動の記録がないことだけで対象設定を放置せず、稼働版と設定に基づいて修正を進めてください。

対応の完了条件は、対象装置を特定し、適切な修正版が実際に稼働し、VPNの認証と必要な保守通信を確認できたことです。暫定的に保護を変更した場合は、その復帰も確認します。未対応の装置や判断できない設定が残る場合は、担当者と次の作業を明記して引き継ぎましょう。

関連記事

緊急パッチを安全に適用する実務ランブックでは、対象資産と更新後の確認結果を残す方法を整理しています。機種固有の更新経路はCiscoの資料を優先してください。