MENU

サイバー攻撃における VPN 機器の保護

VPN は最も狙われる致命的な感染経路

警察庁が発表した資料1によると、ランサムウェアの感染経路として「VPN やリモートデスクトップ用の機器からの侵入が、全体の感染経路の8割以上を占める状況であるところ、その原因としては、ID・パスワード等が非常に安易であったことや、不必要なアカウントがきちんと管理されずに存在していたことなどが挙げられる。」と述べられています。以下の円グラフは、警察庁の資料に掲載された感染経路のグラフです。

VPN 機器が攻撃されるポイント

ランサムウェアの攻撃犯は、① 脆弱性を悪用し VPN 機器への侵入を試みる、② 推測可能な ID、パスワードの設定を想定して辞書攻撃を行い侵入を試みる、のいずれかを選択します。
また、脆弱性を悪用しID/パスワードを解析し、そのID/パスワードをダークウェブで売買する23ことが判明しています。いずれにせよ、VPN 機器の脆弱性や、脆弱なID/パスワードを悪用し組織内のネットワークに侵入することから、VPN 機器の脆弱性管理が重要” となります。以下の表は実際の攻撃に悪用された、VPN 機器の脆弱性の一部です。

主要 VPN 機器で実際の攻撃に悪用された脆弱性
攻撃手法脆弱性CVSS v3
スコア
VPN 機器の脆弱性悪用Cisco ASA、Firepower Threat Defense の認証回避
CVE-2025-20362
8.6 : HIGH
Palo Alto GlobalProtect の OS コマンドインジェクション
CVE-2024-3400
10.0 : CRITICAL
SonicWall のポスト認証の OS コマンドインジェクション
CVE-2023-44221
7.2 : HIGH
SonicWall の未認証でURL操作によりファイルシステムアクセス
CVE-2024-38475
9.1 : CRITICAL
公開された VPN 機器の認証情報の悪用Fortigate の SSL-VPN の脆弱性を悪用し、グローバルIP、ID、パスワードが公開された
CVE-2018-13379
CVE-2022-40684
9.8 : CRITICAL
9.8 : CRITICAL

VPN 機器の管理

小さな組織では、VPN 機器が複数あることは稀ですが、製造業や医療機関では、製造装置や医療機器の監視・保守のために十数台~数十台の VPN 機器が導入されているケースがあります。

サプライチェーンを含めた対策が重要 ~VPN 機器の棚卸 ~

VPN 機器が複数導入されている組織では、VPN 機器の棚卸を確実に実施する必要があります。監視や保守目的の VPN 機器は、必ずしも光回線を使用しておらず、携帯電話回線を使用する 4G/LTE ルーターが設置される場合があり、注意が必要です。
また、オンラインで取引を行っている場合、オンライン先の組織が VPN 機器を導入している場合があり、組織自身が導入していない、把握できていない VPN 機器からの侵害の可能性があります。2022年10月にランサムウェア攻撃を受けた大阪急性期・総合医療センター(大阪市住吉区)では、“オンライン接続をしていた給食事業者の VPN 機器が侵害され、病院側のサーバーにも被害” が及びました。このように、サプライチェーンからの攻撃が実際に発生しているため、他の組織とオンライン接続している場合は、サプライチェーン全体での VPN 機器の棚卸、責任分界点の明確化と、それに応じた脆弱性管理が重要です。
特に、VPN 機器の保守管理を誰が主体的にやるのか“、については契約や取り決めを併せて調査する必要があります。

回線の特定方法

  • 通信回線の請求書を整理しVPN に使用されている回線を特定する
  • 産業機器や医療機器などのベンダーに VPN での監視・保守の有無を確認する
  • オンライン接続している事業者との契約書、ネットワーク構成図等を確認する

VPN 機器管理台帳の作成

VPN 機器管理台帳を作成します。

  • VPN 機器の使用目的
  • 導入・設置年月日
  • VPN 機器メーカーと型番
  • 設置場所
  • 外部接続回線・種別
  • 接続機器、ネットワーク
  • 保守終了日
  • OS、ファームウェアのバージョン
  • TLS 暗号スイート設定
  • 更新日
  • 脆弱性情報の入手先
  • VPN 機器の保有者
  • VPN 機器の保守を実施する者
  • 備考

現行構成(TLS 暗号スイート)の見直し

大半の VPN 機器は脆弱性修正を行っても、TLS 暗号スイートの設定を既存のままにします。従って、脆弱性アップデートを行ったとしても、古く脆弱な TLS1.0/1.1 などが有効のままになっている可能性があります。 また、最新の TLS1.3 が追加されても、自動的に有効にはされません。脆弱性の修正とは別に、最新の暗号スイートは、手動で更新をする必要があります。
優先順位の考え方は、以下の通りです。

  • TLS1.3 が追加されたなら有効化する
  • TLS1.0/1.1 が残っていたら確実に無効化する
  • 楕円曲線暗号(ECDHE)+ AES-GCMSHA256/384 が現行のベストプラクティス
  • RSAキー交換は非推奨(前方秘匿性がないため)
  • CBCモードやSHA1は廃止(脆弱性あり)
  • TLS 1.0/1.1は完全無効化(多くのクラウドサイトがサポート終了済み)

ネゴシエーションの優先順位例

  • TLS 1.3 スイート(最優先)
    • TLS_AES_256_GCM_SHA384
    • TLS_AES_128_GCM_SHA256
    • TLS_CHACHA20_POLY1305_SHA256(モバイルや低CPU環境で有効)
  • TLS 1.2 スイート(互換性確保)
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • 無効化
    • 3DES
    • RC4
    • AES-CBC + SHA1
    • DH 非推奨グループ(1024bit以下)

脆弱性情報の入手先

VPN 機器の棚卸ができたら、VPN 機器ごとの脆弱性情報の入手先を調べます。

Allied TelesisCiscoNETGEARSophos
Barracuda Networks FortinetPalo Alto NetworksWatchGuard
Check PointJuniper NetworksSonicWallYAMAHA

脆弱性の評価と監視

脆弱性の評価

VPN 機器はインターネットに公開された通信機器であり、初期侵入に悪用されることから、最も注意を払う必要があります。LAN 内に設置されたコンピューターとは、異なる対応が必要です。

入手した脆弱性情報を基に、実際の攻撃に悪用される可能性を検討します。評価方法は、CVSS v3 ベーススコア を参考にします。“CVSS v3 スコアが 7.0 以上であれば実際の攻撃に悪用される可能性が高い” ため、Workaround(応急措置)が示されていれば、至急 Workaround を適用し、その後、以下の期間をめどに、脆弱性の修正プログラムを適用します。

CVSSv3 スコアリスク区分対策の目安実際の攻撃が確認されている
9.0–10.0Critical48–72時間以内即日(24h以内)
7.0–8.9High7日以内
4.0–6.9Medium14日以内
0–3.9Low60日以内ゼロデイ対象外

資格情報流出の監視

過去において Fortigate の脆弱性を悪用した攻撃犯が、ダークウェブにグローバル IP アドレス、ユーザーID、ユーザーパスワードを公開した事例があります。こうした場合、“脆弱性の修正以前に、VPN 機器の ID、パスワードの変更が必須” となります。脆弱性情報を入手したら、継続的に資格情報の公開の有無があるか監視する必要があります。

脆弱性の修正

Workaround の適用

実際の脆弱性の修正前に、ベンダーが推奨する暫定対策を適用します。暫定対策は、VPN 機器の機能や設定を変更することで、攻撃を緩和するために行います。過去の Workaround では次のような対応策が公開されました。

  • Fortinet → affected interface の IPv4 policy に制限
  • Palo Alto → GlobalProtect portal の公開制限
  • Cisco ASA → “no webvpn” を一時的に設定
  • SonicWall → SSL-VPN を disable して IPsec のみに切替
  • OPNsense / pfSense → WAN 側の GUI 公開制限

メンテナンスの周知

主に業務終了後にメンテナンスを実施しますが、利用者に対しては事前通知を行います。なお、緊急事態に備えて、夜間の特定時間は、“予告なくVPN 機器の保守を行う” 旨を社内に周知しておくことも重要です。

  • 社内ユーザー
  • 拠点担当者
  • 取引先(外部VPN接続ありの場合)

バックアップの取得

現在の VPN 機器の設定/構成情報をバックアップします。パッチ適用で重大な不具合が発生することがあり、切り戻しのためにもバックアップは重要です。また、ログはアップデートで消去される場合が多いので留意します。

  • コンフィグ(Config backup)
  • OS/Firmware の旧版イメージ
  • ログ
  • ライセンスキー
  • VPN クライアント設定
  • CA/証明書のバックアップ
  • Config はオフライン保管(NASは不可)

パッチの入手(Firmware / OS / Module)

ベンダー Support ポータルでアカウントログインし、対応 OS のパッチ/アップデート情報を確認します。Release Notes で、次の項目を確認します。影響が大きいと判断される場合で、Workaround が有効な場合は、パッチ適用を見送ることも検討します。

  • 既知の不具合(Known Issues)
  • 必要な再起動の有無
  • 設定互換性
  • Special Upgrade Note(大幅アップグレード時の注意)

また、危険な脆弱性で、Workaround がなく、かつ、パッチ適用の影響が大きい場合は、VPN 機器の WAN 側接続を切断し、要望に応じて都度接続やオフライン運用も検討します。

パッチ適用

パッチ適用によって、WAN(インターネット)側の通信が切断され、その後の操作が不能になる場合があるため、必ず、LAN(社内)側から実施します。

  • 管理用 LAN から管理者権限でログイン
  • Firmware / OS を更新
  • VPN 機器の再起動
  • 起動後のバージョン確認
  • Config の整合性チェック

動作テスト

以下の点を中心にテストを実施します。

  • SL-VPN / IPsec-VPN が正常に接続できる
  • Ping が正常に通る
  • ログから認証 AD / Radius 連携が正常であることが確認できる
  • NAT / Firewall / Routing が正常である
  • 拠点間 VPN トンネルが正常に接続できる
  • Syslog / SIEM にログが出力されている
  • アプリケーション(RDP / ERP / 基幹)が正常動作する

また、更新後のユーザー操作で不具合が発見されたり、デグレード(直し壊し)もありえるため、24~72時間はログの監視を実施します。

  • 連続した認証失敗がないか
  • 不審なセッションがないか
  • 拠点間 VPN トンネルが断続していないか
  • 大量のトラフィックが検知されていないか

構成管理

脆弱性修正や応急処置を施した場合は、”VPN 機器管理台帳” に適用した措置等を記入します。なお、不具合発生の場合やロールバックも必ず記入し、実際に稼働している OS、ファームウェアのバージョンが確実に記録されるようにします。


  1. 警察庁サイバー警察局「令和7年上期におけるサイバー空間をめぐる脅威の情勢等について↩︎
  2. Cyberint Initial Access Brokers: The Hard Facts ↩︎
  3. Prey The rise of access brokers: How cybercriminals are selling stolen credentials like a marketplace commodity ↩︎
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次