IOS Stack Group Bidding Protocolの巧妙に細工されたパケットによるDoS

Cisco IOSソフトウェアの特定のバージョンのCisco IOS Stack Group Bidding Protocol(SGBP)機能は、リモートから悪用できるサービス妨害(DoS)状態に対して脆弱です。SGBPプロトコルをサポートしていないデバイス、またはSGBPプロトコルを有効にしていないデバイスは、この脆弱性の影響を受けません。

シスコでは、該当するお客様用に、この脆弱性に対応する無償ソフトウェアを提供しております。この脆弱性に対しては、影響を緩和するための回避策があります。

このアドバイザリは、https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20060118-sgbp で公開されています。

マルチリンクPPP(MLP)を使用すると、ユーザは複数のPPPリンクを1つの論理ネットワーク接続に結合できるため、オンデマンドの帯域幅割り当てが可能になります。複数のデバイスシャーシに実装する場合、これはマルチシャーシマルチリンクPPP(MMP)と呼ばれます。Stack Group Bidding Protocol（SGBP；スタックグループビッディングプロトコル）は、MMPに参加しているデバイスが互いを探し出し、接続ターミネーションポイントをネゴシエートするメカニズムです。

Cisco Internetwork Operating System(IOS)によって提供されるSGBP実装は、巧妙に細工されたUDPパケットが提示されると、サービス拒否攻撃の影響を受けやすくなります。このようなパケットを該当デバイスのポート9900に送信すると、パケットがフリーズし、トラフィックへの応答やトラフィックの受け渡しが停止します。遅延が発生すると、システムウォッチドッグタイマーがこの状態を検出し、デバイスのリセットを強制します。システムの回復動作は、デバイスのコンフィギュレーションレジスタによって制御されます。たとえば、ルータがリロードしたり、ROMモニタにドロップしたりする場合があります。

この脆弱性は、Cisco Bug ID CSCsb11124(登録ユーザ専用)に記載されています。

このセクションでは、次の脆弱性の回避策について説明します。

• アクセスコントロールリスト(ACL)の設定
  SGBPプロトコルを有効にする必要があるサイトでは、アクセスコントロールリスト(ACL)を適用して、信頼できないホストがこの脆弱性を不正利用するのを防ぐことができます。次の拡張アクセスリストをネットワークに適用できます。この例では、SGBPメンバーが192.168.10.0ネットワークを使用して通信することを前提としています。
  

  access-list 101 permit udp 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255 port eq 9900 
  access-list 101 deny udp any 192.168.10.0 0.0.0.255 port eq 9900 
  access-list 101 permit ip any any
  

  その後、次のような設定コマンドを使用して、すべてのインターフェイスにアクセスリストを適用する必要があります。
  

  interface ethernet 0/0 
  ip access-group 101 in 

• コントロールプレーンポリシングの有効化
  次の例に示すように、コントロールプレーンポリシー(CoPP)機能を使用して、この脆弱性を軽減できます。
  

  ! Do not police SGBP traffic from the trusted network 
  access-list 140 deny udp 192.168.10.0 0.0.0.255 any eq 9900 
  ! Police SGBP traffic from untrusted hosts and networks 
  access-list 140 permit udp any any eq 9900 
  ! Do not police any other type of traffic going to the router 
  access-list 140 deny ip any any 
  ! 
  class-map match-all sgbp-class 
  match access-group 140 
  ! 
  policy-map control-plane-policy 
  ! Drop all traffic that matches the class "sgbp-class"
  class sgbp-class 
  drop 
  ! 
  control-plane 
  service-policy input control-plane-policy
  

  注：CoPPが利用できるのは、特定のプラットフォームとIOSリリーストレインだけです。CoPP 機能の設定と使用方法についての詳細は、次の URL で確認できます。

  http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html
  
• インフラストラクチャ ACL（iACL）
  ネットワークを移動するトラフィックをブロックするのは往々にして困難ですが、インフラストラクチャ デバイスに送られてはならないトラフィックを識別し、ネットワークの境界でそのトラフィックをブロックすることは可能です。インフラストラクチャ ACL はネットワーク セキュリティのベスト プラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワーク セキュリティへの長期的な付加機能として考慮する必要があります。ホワイトペーパー『Protecting Your Core: Infrastructure Protection Access Control Lists』では、iACLのガイドラインと推奨される導入方法について説明しています。http://www.cisco.com/warp/public/707/iacl.html
  
• 受信アクセスリスト(rACL)の設定
  分散プラットフォームでは、Cisco IOSソフトウェアバージョン12.0(21)S2(12000シリーズGSR)および12.0(24)S（7500シリーズ）以降では、rACLがオプションになる場合があります。受信アクセス リストは、ルート プロセッサが有害なトラフィックの影響を受ける前に、そのトラフィックからデバイスを保護します。受信パスACLはネットワークセキュリティのベストプラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワークセキュリティへの長期的な付加機能として考慮する必要があります。CPU 負荷がライン カード プロセッサに分散されるため、メイン ルート プロセッサの負荷を軽減させるのに役立ちます。ホワイトペーパー『GSR: Receive Access Control Lists』では、デバイスへの正当なトラフィックを特定して許可し、不要なパケットをすべて拒否します。http://www.cisco.com/warp/public/707/racl.html
  

シスコでは、この脆弱性に対処する最新のソフトウェアを提供しています。詳細については、次のソフトウェアの表を参照してください。

アップグレードを検討する場合は、http://www.cisco.com/go/psirt と後続のアドバイザリも参照して、問題の解決状況と完全なアップグレード ソリューションを確認してください。

いずれの場合も、アップグレードする機器に十分なメモリがあること、および現在のハードウェアとソフトウェアの構成が新しいリリースで引き続き適切にサポートされていることの確認を十分に行ってください。情報に不明な点がある場合は、Cisco Technical Assistance Center（TAC）または契約を結んでいるメンテナンス プロバイダーにお問い合せください。

Cisco IOS ソフトウェアの表（下掲）の各行には、リリース トレインとそれに対応するプラットフォームまたは製品が記載されています。特定のリリース トレインに脆弱性がある場合は、修正を含む最初のリリース（「第 1 修正済みリリース」）とそれぞれの提供日が「リビルド」列と「メンテナンス」列に記載されます。特定の列に記されているリリースよりも古い（第 1 修正済みリリースより古い）トレインに含まれるリリースが稼働しているデバイスは脆弱であることが確認されています。このようなリリースは、少なくとも、示されているリリース以上（最初の修正リリース ラベル以上）にアップグレードしてする必要があります。

「リビルド」および「メンテナンス」という用語の詳細については、次のURLを参照してください。http://www.cisco.com/warp/public/620/1.html

Cisco PSIRT では、本アドバイザリに記載されている脆弱性の不正利用事例やその公表は確認しておりません。

この脆弱性は内部テストで発見されました。