Juniperの重大脆弱性で管理面とBGPを点検｜Junosの系列別更新を確認

シンガポールのCyber Security Agency（CSA）は2026年10月19日、JuniperのJunos OSとJunos OS Evolvedに複数の重大な脆弱性があるとして、更新を促しました。対象にはJ-Webの認証不備、httpdやルーティングデーモンのバッファーオーバーフローなどが含まれ、列挙された問題はCVSS v3.1で9.8とされています。

本稿は10月21日に確認した未掲載の注意喚起を扱います。機器への攻撃や日本の被害を新たに確認したという記事ではありません。Webサイト自体を更新していても、その前段にあるネットワーク機器が停止したり設定を変更されたりすれば、サービスへ影響が及びます。管理インターフェースとルーティング機能を別々に調べることが重要です。

一次資料：Critical Vulnerabilities in Juniper Devices（シンガポールCSA）。以下の運用手順と仮想例は本サイトの提案です。

同じ9.8でも必要な接続条件は異なる

CVE-2026-101986は、J-Webで細工されたHTTP要求によって認証を回避し、高い権限でCGIを実行される可能性のある問題として説明されています。CVE-2026-101954は、J-WebとNETCONFセッションの扱いに関する認証不備で、Web管理が有効かつHTTPまたはHTTPSへ到達できる場合、root相当の設定アクセスにつながる可能性があります。

一方、CVE-2026-102178はBGP flowspecのピアと、update-threadingなどの設定条件に関わる問題です。管理画面のHTTP通信を止めるだけで、BGP関連の全問題も緩和できるとはいえません。逆に、BGPを使わない機器でその条件だけを心配し、J-Webの公開を調べない判断も不十分です。

CSAはほかにもSDX/SRCとの接続、BGP/EVPN、BMPなどに関わる問題を挙げています。本記事のCVE一覧は管理面とBGPの代表例を記録するもので、全問題を網羅した台帳の代わりではありません。対象機器ごとに公式の集合勧告を読み、使う機能と対象版を対応付けてください。

管理面の到達範囲を明らかにする

本サイトでは、インターネットから見えるかに加え、社内端末、VPN、委託先、監視サーバー、管理用ネットワークからの接続を確認することを提案します。外部公開していなくても、侵害された端末から到達できる場合は管理面の防御を説明し切れません。許可元の一覧と実際の経路を照合します。

管理用のアドレス、J-Webの有効状態、HTTPとHTTPS、NETCONF、保守接続の用途を記録します。担当者が普段使う画面だけを対象にすると、以前の保守用設定が残る場合があります。設定を変えるときは、遠隔作業の経路を自分で切断しないよう、別の管理経路や現地対応を確保します。

接続制限は必要な管理者を通すためのものです。正規の監視や構成管理が使う通信まで止めると、障害を把握できなくなるおそれがあります。制限前後に設定バックアップ、監視、時刻同期、ログ転送が継続するかを確かめ、拒否された正規通信を見つける期間を設けます。

Junos OSとEvolvedの更新先を取り違えない

CSAの一覧では、Junos OSの23.4系は23.4R2-S8.13より前、同じ23.4系でもJunos OS Evolvedは23.4R2-S8.11-EVOより前が対象として示されています。系列名が似ていても末尾は同じではありません。ファイル名を見た印象や別機種の手順を使わず、機種、OS、系列、現在版を合わせます。

同資料には24.2、24.4、25.2、25.4、26.2などの系列も列挙されています。自社が使う系列を確認し、その系列の修正先と提供元の互換性情報を選ぶ必要があります。本稿で取り上げた一つの番号をすべての機器の共通更新先として使わないでください。

集合勧告の対象表を機器台帳へ移すときは、CVEごとの利用条件も別列に残します。ネットワーク担当が「更新対象」と判断した理由が、管理面なのか経路広告なのかを分かるようにすると、保守延期中の暫定措置を具体化できます。使っていない機能は、設定と実体から確認した根拠を残します。

Webサービスと経路切り替えを一緒に試験する

説明用の仮想例として、二台の機器がWebサイトの経路を冗長化し、その上でBGPを使っている構成を考えます。片方を更新する際に、もう片方へ経路が切り替わることと、アプリのセッションが維持されることは同じ確認ではありません。通信の迂回で遅延や接続切断が起きる可能性を検証します。

本サイトでは、事前に経路数、隣接状態、インターフェース、CPU、ログ、主要URLの応答を採取し、更新後の比較基準を作ることを勧めます。大量の機微情報を公開作業票へ貼る必要はありません。参照先と取得時刻を管理し、変更内容と観測結果を対応付けます。

更新中の監視は、更新対象の機器を経由する一つの系統だけへ依存させない方がよいでしょう。管理接続が切れても機器が動いている場合と、実際に通信が停止した場合を区別するためです。現地のコンソールや独立した監視経路を、作業の重要度に応じて準備します。

保守手順には切り戻し条件を含める

更新前に構成、ライセンス、利用モジュール、起動領域、必要なバックアップを公式手順に沿って確認します。設定形式や動作が変わる可能性があるため、旧版へ戻せば無条件に設定も元どおりになると仮定しません。戻す範囲と時間、設定の復元方法を確定します。

切り戻す条件は、単に担当者が不安になったらではなく、隣接が戻らない、必要な経路がない、一定時間サービスが復旧しないなど、業務と結び付いた観測値にします。具体的な待ち時間は環境と公式手順に依存するため、ここで一律の分数を指定しません。

冗長構成でも全台へ同時に更新を配ると、同じ問題が同時に起きるおそれがあります。一部の機器で設定と業務通信を確認してから対象を広げます。待機系を古いまま放置する計画にもせず、更新後に実際の切り替えを確認する段階まで担当と期限を決めます。

侵害調査では設定変更の記録を保全する

今回確認したCSAの注意喚起から、実際の悪用を確定することはできません。更新が必要なことと、機器が既に侵害されたという結論は分けます。不審な管理ログイン、予定外の設定変更、未知の通信がある場合は、変更前の記録を保全し、組織のインシデント対応へ引き継ぎます。

調査では機器内のログだけでなく、認証基盤、ログ集約、ネットワーク監視、保守作業票を時刻で照合します。ログ保存が短い環境では、更新作業で記録が失われる前の保全を検討します。保存されていない期間を異常なしと書かず、どこまで調べられたかを残してください。

侵害が疑われる場合、通常のアップグレードだけで原因や永続化が除去されたとは扱いません。提供元の案内を使い、構成の検証、クリーンな媒体からの復旧、管理資格情報の扱いまで判断します。具体的な痕跡や復旧手順は状況に依存するため、未確認の対処コマンドは案内しません。

保守委託先へ渡す確認事項

経路の正常性と管理面の保護を別々に報告する

仮想の保守報告で「通信正常」とだけ書くと、利用者向けの通信が通ったことしか分からない場合があります。今回のように管理面とルーティングの問題を含む更新では、管理接続、経路の隣接、経路数、Webの主要通信を分けて結果を残します。使わない機能については、その無効状態を確認した根拠を添えます。

ルーティングの試験では、通常状態の疎通に加え、片系停止、復旧、再切り替えで通信が戻ることを確認します。単一のpingだけでは、実際のHTTPS通信、長時間接続、大きい応答、外部連携の影響を見落とすことがあります。利用サービスを代表する試験を選び、変更前と同じ観測点で比較します。

保守を担当する会社へは、機器ごとの更新版と確認結果を依頼します。複数拠点を一つの「完了」にまとめず、接続できなかった拠点や現地作業待ちの機器を残します。予定どおり更新できなかった場合は、管理面の一時制限、保守用アカウント、次の停止計画を具体的に引き継ぎます。

構成の変更には、ネットワーク機器以外の監視側も関わります。ログの送信元やインターフェース名が変わった場合、監視が新しい状態を正しく取り込めるかを確認します。画面の古いグラフが残っているだけで監視継続と判断せず、更新後に新しい観測値が到着した時刻を確かめます。

災害復旧用の設定や予備機も確認対象です。平常時に接続していない機器は攻撃されにくい場合がありますが、障害時にそのまま旧版を公開すると、対応したはずの条件が戻ります。予備機の更新と復旧手順の見直しを、現行機の作業と関連付けて管理してください。

ネットワークの更新では、正常な通信が続くことと、必要な制限が維持されることの両方を確かめます。更新中だけ一時的に広げた管理アクセスがあるなら、作業後に戻した証拠も残します。切り戻しや現地対応で追加した設定まで追跡すれば、保守の後に新しい公開経路を残す問題を減らせます。

本記事ではCSAの注意喚起日を本文へ明記していますが、各CVEの初回公表日は同資料だけから確定していません。そのため構造化メタデータに推測の日付は保存していません。運用側の台帳でも、情報を知った日、勧告の公表日、修正を適用した日を分けて残すと、対応期間を正しく振り返れます。

委託している機器でも、利用者側が確認できる情報はあります。対象機種と系列、対象CVE、J-Webの到達元、BGPなどの利用条件、修正先、作業日、停止影響、検証結果を回答してもらいます。「ベンダー確認済み」という一文より、次の保守で引き継げる形にします。

管理面の制限と経路広告の条件を分け、OSの系列別に更新し、Webの業務通信まで確認することが今回の対応の要点です。ネットワーク機器をWeb保守の外側へ追い出さず、サービスを届ける基盤として更新と復旧の計画へ含めてください。