News お知らせ/記事
- 技術情報
- ASR1000
- Catalyst 8000
- Cisco Systems
- Crypto
- IOS-XE
- IPsec
- ISR
- VPN
- 暗号化
【Cisco Systems】IOS-XEルーター 17.12.xへのアップデートについて
目次
はじめに
以前（2024年6月28日）の記事で、Cisco Systems社のOSバージョンについて取り上げました。
前記事の執筆時点でもIOS-XE 17.12.3が推奨とマークされていましたが、Early Deployment (ED)なリリースであったため、現在までに多く採用されるバージョンは、脆弱性の対策がされた17.9.4aや更新版の17.9.5aが多くを占めていた印象です。
しかし、次の長期サポートの候補であった17.12.xは、17.12.3aよりMaintenance Deployment (MD)としてマークされ、現在は17.12.4と17.9.5aがいずれも推奨リリースとなっています。
今回の記事では、ASR1000を除くISR1100/ISR4000/C8200/C8300/C8500などで「推奨かつMaintenance Deployment (MD)なリリースとなったIOS-XE 17.12.4」へのアップデートを題材として、特にルーター製品に影響する機能や動作に関わる重要な留意事項をお送りさせて頂きます。
【重要な留意事項】弱い暗号化の非サポート
従来のリリース（17.6.1以降）でも、設定時に警告（%Warning: weaker encryption algorithm is deprecated）が表示される対象でしたが、IOS-XE 17.11.1a以降では、以下のような弱い暗号化アルゴリズムは正式にサポート外となりました。
- ・DES 3DES MD5
- ・DH Group: 1/2/5
- ・esp-gmac transforms
※前バージョンとなるIOS-XE 17.11.xのRelease Notesや17.xのConfiguration Guide、そしてField Noticeでも注意喚起されています。
このため、以下のようなConfigurationについては、アップデート後のOSでReloadすると、自動的にサポートされるアルゴリズムに変換されます。
crypto isakmp policy 1
encryption 3des
hash sha
authentication pre-share
group 2crypto isakmp policy 1
encryption aes
hash sha
authentication pre-share
group 14【重大な影響が発生する例1】サイト間接続
サイト間をIPsec VPNで接続する2台1対のルーターを例に考えると、当然ながらある一方をアップデートして設定値が変換されると、もう一方と暗号化アルゴリズムが一致しないため、正常に接続を確立できません。これを避けるためには、バージョンアップの前に予めサポートされるアルゴリズムでの再設定を双方で完了した後に、アップデートを行う必要があります。
しかし、実際の環境においては次のような課題が存在します。
ハードウェア（Crypto Engine）での暗号化サポートとスペック
従来から多く使用されている暗号化アルゴリズムは、現在主流となっているルーターでHardware Offloadingの対象となっていました。今回の更新を機にAES256やSHA256、DH Group 14/19/20/21など強い暗号化へ移行する場合、これらのHardware Offloadingに対応しないルーターに実装するとソフトウェアによって処理され、意図しないパフォーマンスの低下を招く恐れがあります。
特に小規模なスポークサイトにC921J-4PやC891FJ-K9などのIOSルーターを採用している構成で顕著な問題となり得ます。IOSルーターはIOS-XEルーターと異なり旧来のアーキテクチャを踏襲した機器であり、パフォーマンスやサイジングも従来のアルゴリズムによる稼働を前提として設計されたモデルとなっているためです。
このようなパフォーマンスにも及ぶ問題となるため、安定的なパフォーマンスを前提とした展開には、十分な事前評価が要求されます。
※C8200、C8300、C8500、ASR1000、ISR4000等のIOS-XEルーターでも、全ての暗号化についてHardware Offloadingをサポートしているわけではありません。ご利用されるデバイスでのサポート有無についてはdebugコマンドの出力で確認が可能ですが、使用する暗号化アルゴリズムとパフォーマンスを踏まえたサイジングについては、十分な検証と実環境での運用に基づくナレッジが要求されます。このようなクリティカルな設定値についてご検討の皆様におかれましては、ご懇意のパートナー様などから提言を得ることを強く推奨いたします。
その他の接続対向先への折衝
暗号化通信はRFCで定められた規格であり、接続の対象全てが単一の組織や支配下にあるとは限りません。同様に暗号化通信全ての対向が同一ベンダーの製品に限定されるものではなく、様々なベンダー間で接続されていることが環境の必然となっています。前述のパフォーマンスに関連する課題は当然ながら、相互にサポートするアルゴリズムや稼働値を折衝する必要があります。
一例を挙げると、日本国内で多くご利用されているYAMAHA社のルーターにおいては、DH Groupは以下のみがサポートされています。
- ・MODP768 (DH Group 1)
- ・MODP1024 (DH Group 2)
- ・MODP1536 (DH Group 5)
- ・MODP2048 (DH Group 14)
ここから既に弱い暗号化とされる1/2/5を除くと、選択肢は14のみとなります。セキュリティが大幅に強化された19/20/21は実装されていないため、これらを採用するその他の対向先とCiscoルーター自身の構成によっては、暗号化の区分毎に終端するハードウェアなどを追加で用意する必要性が生じます。
また、現在主流となっているクラウドサービスのプラットフォームにおいては、ほぼ全てが強い暗号化をサポートしていますが、旧来からのサービスを含めて全てが対応していることは保証されておらず、個別に確認が必要となるでしょう。
【重大な影響が発生する例2】リモートアクセス
従来よりP2Sなリモートアクセスで多く利用されてきたL2TPv2/IPsec、IKEv2を筆頭に、暗号化を使用するリモートアクセス通信もこの問題に該当します。
現行のmacOSなどでは標準でAES-128/256やDH Group 14などをサポートしていますが、Windowsでは3DES/SHA1/DH Group 2がデフォルトとなっているため、これまでWindows OSに合わせたアルゴリズムでリモートアクセスを終端していたルーターを17.12.xへアップデートした時点から、Windows端末はデフォルトの状態では接続が確立できないことになります。
さらに、このアルゴリズムの変更については、Intuneなどでプロファイルの配布を行う構成を除き、接続プロファイル毎にコマンドで適切な値を設定する必要があるため、端末数に比例した労力が必要となります。
Windows OSの標準動作がこのような仕様となっている以上、筆者個人の見解ですが具体的な解決策は以下の何れかが現実的かと思います。
- ・前述の手順で各クライアント端末のプロファイルを変更する（Intuneでプロファイルを配布するか、PowerShellスクリプト等を作成して実行するなど）
- ・多要素認証を含めたセキュリティ強化の一環として、Secure Client（旧AnyConnect）などを使用したソリューションへ移行する
現実問題として、L2TPv2/IPsec、IKEv2をOS標準の仕様で接続する、「接続対向先へデフォルトルートを向けてしまう形態」では、インターネットブレークアウトを含めたトラフィックが集中してしまうため、近年の利用形態へは見合わないものとなってしまっていると感じます。
直近で筆者が携わらせて頂いている事案では、前述のSecure Clientを筆頭としたベンダーのクライアントソフトウェアを使用して、他要素認証やトラフィックの集中を回避するために必要なアドレス及びFQDNのみを経路としてプッシュ可能な構成へ移行するケースや、オンプレミスからクラウドサービスへの移行と併せて、外部デバイスを含めて包括的に通信を保護する構成の採用が、ご用命頂く事案の多くを占めるようになっている状況です。
【推奨されない解決方法】弱い暗号化の継続使用
ここまでに、2つの例を挙げて今回のケースに伴う影響をご案内させて頂きました。
しかし、実情としてはこれら全ての課題解決を果たすことが難しく、「推奨されるOSバージョンを使用したいが、非サポートの弱い暗号化を継続使用する必要がある」などの状況も往々にして発生するかと思います。
この場合、Cisco Systems社の非推奨となりますが、以下のコマンドを実行して保存してからReloadすることで、CSDL Complianceが無効となり、従来の暗号化アルゴリズムを継続して動作させることが可能となります。
Router(config)#crypto engine compliance shield disableこの方法で弱い暗号化を使用し続けることは、セキュリティ上のリスクへ直結するため、繰り返しになりますがCisco Systems社では推奨しておらず、代替策が無い場合の最後の手段に限定するべきとしています。当然ながらこれらのアルゴリズムに起因する事象もサポート対象外となるため、筆者としても推奨できるものではありませんが、「推奨バージョンで通信動作を継続するための最終手段」としてご案内させて頂きます。
- ※このコマンドはIOS-XE 17.7.1以降のリリースから実行可能となっているため、17.6.xなどのバージョンをご利用の環境では実行が出来ません。中間の推奨バージョンである17.9.5などにアップデートしてから実行するなどの対処が必要になります。
- ※短絡的に無効化するのではなく、無効化する対象：Cisco Secure Development Lifecycle (CSDL)がどのような概念であるか、そして無効化に伴うリスクと責任を正しく認識する必要があります。
まとめ
いかがだったでしょうか。
今後のIOS-XE 17.12.xへの移行は、従来までの運用環境へ大きな影響を及ぼすものとなっています。影響範囲や解決すべき事象も多岐に渡るため、管理者の皆様には多大な労力を伴うものとなってしまいますが、安全性とこの進化は常に対処し続けるべき課題であり、先送りすることはリスクの減少に寄与しません。将来に渡ってセキュアで安定的な運用を行うためにも、これを良い機会と捉えて頂ければ幸いです。
今回はアップデートについてネガティブな情報ばかりをお送りすることとなってしまいましたが、17.9.xから17.12.xまでには、以下のような多くの機能アップデートが含まれています。
- ・DHCPv4、DHCPv6でVendor-class-dataにMAC addressを設定可
- ・EVPNでのDynamic BGP Peering
- ・IPv6でSegment Routingのサポート
特にDHCPv6でのVendor-class-dataについては17.10.1aで修正された問題で、スポークサイトで多く使用されるフレッツ網のIPv6サービスへ適合するなど、広域網と接続するルーターとして大きなトピックとなっています。さらにNX-OSやIOS-XRで主に利用されているDCやコアネットワーキング向けの機構もIOS-XEへ実装が進んでおり、様々なスケールで進化したアーキテクチャが選択可能となっています。このような推奨リリースの間で追加された機能についても、今後機会があれば取り上げたいと思います。
この記事が、ご覧いただいた皆様へ少しでもお役に立てば幸いです。
- ※この記事は筆者個人の見解によるものであり、各メーカー様や当社としての意見や見解を示すものではありません。
- ※この記事に含まれる情報については、その内容について当社として何らの保証をするものではありません。
- ※この記事に含まれる情報を利用したことに起因する、利用者又は第三者が被る直接的及び間接的損害に関して、当社はその責任を一切負いません。
Recruit 採用情報
技能に誇りをもった技術者の皆様を歓迎いたします。
市場価値以上の待遇と、更なる探究の環境を、必ずお約束いたします。
Contact お問い合わせ
当社の業務などに関するお問い合わせを受け付けています。
※エンドユーザー様から直接のご依頼は、原則として受け付けておりません。全てのお問い合わせにお答えできない場合がございますので、ご了承ください。