仕組まれた ICMP メッセージによるサービス拒否の発生の可能性

Internet Control Message Protocol（ICMP；インターネット制御メッセージプロトコル）を使用して、Transmission Control Protocol（TCP；伝送制御プロトコル）に対する多数のDenial of Service（DoS；サービス拒否）攻撃を実行する方法について説明したドキュメントが公開されています。このドキュメントは、Internet Engineering Task Force（IETF；インターネット技術特別調査委員会）のInternet Draftプロセスで公開されており、「ICMP Attacks Against TCP」(draft-gont-tcpm-icmp-attacks-03.txt)というタイトルになっています。

これらの攻撃は、デバイス自体で終了または開始するセッションにのみ影響を与え、次の3つのタイプがあります。

1. ICMPの「ハード」エラーメッセージを使用する攻撃
2. ICMPの「fragmentation needed and Don't Fragment (DF) bit set」メッセージを使用する攻撃(Path Maximum Transmission Unit Discovery(PMTUD)攻撃とも呼ばれる)
3. ICMP「ソースクエンチ」メッセージを使用する攻撃

攻撃に成功すると、攻撃の種類に応じて、接続がリセットされたり、既存の接続のスループットが低下したりする可能性があります。

複数のシスコ製品が、このインターネットドラフトに記載されている攻撃の影響を受けます。

シスコでは、これらの脆弱性に対応する無償ソフトウェアを提供しています。場合によっては、脆弱性の影響を軽減するための回避策があります。

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

次の表に、このドキュメントで説明されている脆弱性がシスコ製品に及ぼす影響をまとめます。

1つの製品ファミリ内で異なるモデルが影響を受ける可能性があるため、詳細については「詳細」セクションを参照してください。

Internet Control Message Protocol（ICMP；インターネット制御メッセージプロトコル）は、Transmission Control Protocol/Internet Protocol（TCP/IP；伝送制御プロトコル/インターネットプロトコル）プロトコルスイートに不可欠な部分であり、エラー状態の報告や診断情報の提供に使用されます。ICMPエラーメッセージは、エンドシステムと中間システム（ルータ）の両方で生成される可能性があります。エンドシステムと中継システムは、ICMPを介して受信したエラーメッセージに対して、報告されるエラーのタイプに応じて異なる方法で反応します。ICMP経由で報告できるエラーのタイプは、「ソフト」エラーと「ハード」エラーの2つのカテゴリに分類されます。

RFC 1122 ("Requirements for Internet Hosts - Communications Layers" - http://www.ietf.org/rfc/rfc1122.txt)では、3つの「ハード」エラー（"protocol unreachable"、"port unreachable"、および"fragmentation needed and Don't Fragment bit set"）と5つの「ソフト」エラー（"network unreachable"、"host unreachable"、"source route failed"、"time exceeded"、および"parameter problem"）、"Source quench"はインターネットホストによって生成される別のICMPエラーメッセージであり、RFC 1111222ははRFCでは明確RFCはRFCをとして分類定していません「ソフト」または「ハード」の場合、これを受信したホストはこのメッセージタイプを処理する方法がソフトエラーと見なす必要があります。ホストは、一定期間、ICMPの「ソースクエンチ」メッセージを生成したホストにデータを送信するレートをカットバックし、その後で再び伝送レートを徐々に上げる必要があります。

「Fragmentation needed and Don't Fragment bit set」（タイプ3、コード4）メッセージは、RFC 1191(「Path MTU discovery」 - http://www.ietf.org/rfc/rfc1191.txt)に記載されているPath MTU Discoveryと呼ばれる重要なメカニズムによって使用されることに注意してください。PMTUDを使用すると、TCP/IPプロトコルスイートの一部のプロトコルでパスのMTUを動的に検出できるため、IPフラグメンテーションが最小限に抑えられ、帯域幅をより効率的に使用できます。このメカニズムはインターネットホストでは必須ではありませんが、これを実装するホストでは、ICMPの「fragmentation needed and DF bit set」メッセージを「soft」エラーとして扱う必要があります。IPフラグメンテーションの動作の仕組みと、フラグメンテーションの削減においてPMTUDが果たす役割を理解するための適切なリファレンスは、http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtmlで入手できるCiscoのホワイトペーパー『IP Fragmentation and PMTUD』です。

ICMP経由で報告できるエラーの種類（「ソフト」と「ハード」）を区別することは重要です。インターネットホストがそれらに応答する方法を決定するためです。一般に、TCPなどのコネクション型プロトコルは、ICMPの「ハード」エラーメッセージに対する応答として既存の接続をアボートする必要があります。また、インターネットホストは、ICMPの「ソフト」エラーメッセージの受信を誘発するエラー状態を修正する必要があります。

ICMPプロトコルを使用してTCPプロトコルに対する多数のDoS攻撃を実行する方法を記述したIETFインターネットドラフト「ICMP Attacks Against TCP」(draft-gont-tcpm-icmp-attacks-03.txt)が公開されました。これらの攻撃には、2台のインターネットホストが相互に通信するために使用しているIPアドレスとポート（TCPの場合）の知識が必要です。また、接続のリセットや既存の接続のスループットの低下を引き起こす可能性があります。

注：これらの攻撃は、デバイス自体で終了または開始されるセッションにのみ影響し、トランジットトラフィックには影響しません。つまり、デバイスを通過するが、他の場所に宛てられたトラフィックには影響しません。

巧妙に細工されたハードICMPエラーメッセージに基づく攻撃

「ハード」ICMPエラーメッセージを受信すると、インターネットホストはICMPエラーメッセージが適用されるホストとの接続を中断する必要があります。このホストは必ずしもICMPメッセージを生成したシステムではありませんが、ICMPペイロードに埋め込まれたIPヘッダーとトランスポートプロトコルデータによって一意に識別されます。この理由は、「ハード」エラーが回復の可能性がない深刻なネットワークの問題を表しているためです。巧妙に細工された「ハード」ICMPエラーメッセージにより、実際にはネットワークの問題がない場合に、インターネットホストが既存の接続を誤って中断する可能性があります。このタイプの攻撃は、Internet Draft draft-gont-tcpm-icmp-attacks-03.txtの「ブラインド接続リセット」攻撃に分類されます（このドキュメントの「Internet Draft」セクションを参照してください）。

PMTUD攻撃

インターネット・ホストがPMTUDを実行している場合、巧妙に細工された「Fragmentation Needed and DF bit set」ICMPメッセージを使用して、接続のパスMTUを非常に低い、実用的でない値に設定できます。接続がまだ確立状態であっても、この値によって、スループットが非常に低いため、上位層プロトコルがタイムアウトを開始する可能性があります。このタイプの攻撃は、Internet Draft draft-gont-tcpm-icmp-attacks-03.txtで「スループット低減」攻撃として分類されています(Cisco Bug ID CSCse1728を参照)。

RFC 1191で説明されているPMTUDアルゴリズムに従って、実装ではキャッシュされたMTU値を「エージング」する必要があります。これは、MTUが最適なサイズ（最大10分かかるプロセス）に戻ることを意味します(RFC 1191では10分が推奨されていますが、これは要件ではないため、実装に依存しています)。 ただし、攻撃者が巧妙に細工されたICMP「Fragmentation Needed and DF bit set」メッセージを脆弱なホストに送信し続けると、キャッシュされたMTUがエージングせず、サービス妨害(DoS)状態が継続して発生することに注意してください。

前述したように、ICMPの「Fragmentation Needed and DF bit set」メッセージを受信しているインターネットホストがPMTUDを実行していない場合、RFC 1122に従って、このメッセージは「ハード」エラーと見なされます。これは、PMTUD攻撃によって接続リセットが発生する可能性があることを意味します。

TCPやその最大セグメントサイズ(MSS)変数のように、「トランスポート層」MTUを使用してフラグメンテーションのリスクを最小限に抑えるプロトコルの場合、接続が攻撃に成功したかどうかを判断する良い方法は、この「トランスポート層」MTUの値を監視することです。値が不当に低い場合は、攻撃が行われたことを示している可能性があります。Cisco IOSでこれを行う方法の例については、このドキュメントの後半で説明します。

注：いくつかの一般的なプロトコルはTCPを使用するため、PMTUD攻撃の影響を受ける可能性があります。たとえば、BGP、Hyper Text Transfer Protocol（HTTP；ハイパーテキスト転送プロトコル）（World Wide Webで使用）、Simple Mail Transfer Protocol（SMTP；シンプルメール転送プロトコル）（電子メールの転送に使用）、Secure Shell（SSH；セキュアシェル）などがあります。Data-Link Switching(DLSw)、Serial Tunneling(STUN)、Block Serial Tunneling(BSTUN)などのIBMスイートの一部のプロトコルは、トランスポートプロトコルとしてTCPを使用するように設定できます。通常、ドメインネームシステム(DNS)はユーザデータグラムプロトコル(UDP)を使用しますが、状況によっては（大規模なゾーン転送など）、TCPも使用します。

巧妙に細工されたSource Quench ICMPメッセージに基づく攻撃

先に述べたように、インターネットホストは、ICMPの「ソースクエンチ」メッセージを生成した別のホストにデータを送信する速度を削減する必要があります。ICMPの「ソースクエンチ」メッセージに対する実際の応答は、TCP/IPの実装および使用されているトランスポート層プロトコルによって異なりますが、一般に、ICMPの「ソースクエンチ」メッセージを受信するホストは、輻輳回避アルゴリズムをトリガーする必要があります。

TCPを使用して他のホストと通信するホストの場合、ICMPの「source quench」メッセージを受信すると、再送信タイムアウトが発生したかのように「slow start」をトリガーするRFC 1122に従った推奨手順が実行されます。RFC 2001(『TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms』(http://www.ietf.org/rfc/rfc2001.txt)では、TCPの最近の実装で使用される「slow start」アルゴリズムと「congestion avoidance」アルゴリズムについて説明し、実際には「slow start」アルゴリズムと「congestion avoidance」アルゴリズムを一緒に実装することを規定しています。

送信側ホストがデータを送信する速度が低いほど、ICMP「source quench」メッセージを生成したホストは受信バッファを処理して空にすることができます。

巧妙に細工された「ソースクエンチ」ICMPメッセージを使用して、ホストがデータを送信するレートを下げることができます。時間の経過とともに、追加のSource Quenchメッセージが受信されない限り、ウィンドウサイズは妥当な値まで増加しますが、巧妙に細工された「Source Quench」メッセージは通信効率を大幅に低下させる可能性があります。攻撃者が巧妙に細工されたICMP「ソースクエンチ」メッセージを脆弱性のあるデバイスに定期的に送信すると、その接続のサービスが長時間低下する可能性があります。

このタイプの攻撃は、Internet Draft draft-gont-tcpm-icmp-attacks-03.txtで「スループット低減」攻撃として分類されています。

シスコ製品の影響

このドキュメントで説明されているICMP攻撃に対する影響は、シスコ製品によって異なります。特定の設定またはネットワークプロトコルが使用されている場合に、一部の製品が影響を受ける場合があります。次に、脆弱性のある製品がどのように影響を受け、どのような設定になっているかについて説明します。各製品の特定のCisco Bug IDに関する情報が表示されます。

Cisco IOS

Cisco IOSは、ICMPの「ハード」エラーメッセージを使用する攻撃に対しては脆弱ではありません。これは、IOSが接続が「確立」状態にあるかどうかをチェックし、「確立されていない」状態の接続に対してのみアクションを実行するためです。

また、IOSはICMPの「ソースクエンチ」メッセージを処理しないため、このタイプのメッセージの作成に基づく攻撃に対して脆弱ではありません。

「脆弱性が存在する製品」セクションで説明されているように、IOSはPMTUD攻撃に対して脆弱です。これは、攻撃者がICMPの「Fragmentation Needed and DF bit set」メッセージ（IPv6の場合は「packet too big」メッセージ）を作成することによって、パスMTUを変更できることを意味します。 次のリストは、IOSのさまざまなプロトコルにおけるPMTUDの脆弱性に関するCisco Bug IDを示しています。

• PMTUDを使用するすべてのプロトコル:CSCef60659(登録ユーザ専用):ICMP到達不能に対してより厳密なチェックが必要。
• Transmission Control Protocol over Internet Protocol Version 4:CSCed78149(登録ユーザ専用):PMTUDを実行するIPバージョン4上のTCP接続は、巧妙に細工されたICMPパケットに対して脆弱です。
  接続がPMTUD攻撃の影響を受けているかどうかを確認する優れた方法は、接続のMSS値を調べることです。BGPセッションの場合、コマンドshow ip bgp neighbors | include data segmentは、次の例のようにMSS(max data segment)を表示します。
  

  Router#show ip bgp neighbors | include data segment
  Datagrams (max data segment is 1460 bytes):
  Router#
  

  公式の最小MTUは68バイトですが、今日のインターネットでは576バイト未満のMSSは疑わしいと見なされるはずです。RFC 1191のセクション7には、インターネットで使用される一般的なMTU値のリストが含まれています。
  その他のTCP接続の場合は、show tcp briefコマンドを使用して特定の接続の伝送制御ブロック(TCB)を判別してから、このTCBをshow tcp tcb <TCB identified with show tcp brief>コマンドで使用する必要があります | include data segmentと入力すると、MSS(max data segment)が表示されます。
  

  Router#show tcp brief
  TCB       Local Address           Foreign Address        (state)
  00E97148  192.168.100.1.23        192.168.100.1.11002    TIMEWAIT
  00E97A78  192.168.100.1.23        192.168.100.1.11003    ESTAB
  00E975E0  192.168.100.1.11003     192.168.100.1.23       ESTAB
  Router#show tcp tcb 0x00E975E0 | include data segment
  Datagrams (max data segment is 1474 bytes):
  Router#
  

  このテクニックは、TCP over IPv6にも使用できることに注意してください。
• Transmission Control Protocol over Internet Protocol Version 6:CSCef61610(登録ユーザ専用):ICMPv6メッセージの不適切な処理により、TCPパフォーマンスの問題が発生する可能性があります。
• IPSec:CSCsa59600(登録ユーザ専用):IOS IPSec接続は、特定のフローに対してIPSecが非常に小さいPMTU値を使用する原因となる可能性がある、巧妙に細工されたICMPパケットに対して脆弱な場合があります。巧妙に細工されたICMP「Fragmentation Needed and DF bit set」メッセージによってPMTUが減少した後、追加のICMP「Fragmentation Needed and DF bit set」メッセージを受信しないと、学習されたMTUが10分間アクティブになり、その後RFC 1191に従ってPMTUがファーストホップデータリンクMTUに復元されます。
  IPSecトンネルがPMTUD攻撃の影響を受けているかどうかを確認するには、show crypto ipsec saコマンドを実行します | include mtuコマンドを使用します。
  

  Router#show crypto ipsec sa | include mtu
    path mtu 1500, media mtu 1500
  Router#
  

• Generic Routing Encapsulation(GRE)およびIPinIP:CSCef44699(登録ユーザ専用):GREトンネルおよびIPinIPトンネルは、巧妙に細工されたICMPパケットに対して脆弱である可能性があります。
  GREまたはIPinIPトンネルがPMTUD攻撃の影響を受けているかどうかを確認するには、次の例のように、コマンドshow interface tunnel <number> | include Path MTUを実行します。
  

  Router#show interface tunnel 0 | include Path MTU
    Path MTU Discovery, ager 10 mins, MTU 1476, expires never
  

  これらのトンネリングプロトコルの場合、ICMPエラーメッセージには、メッセージを正しく認証するためにエラーを引き起こすGREまたはIPinIPパケットに関する十分な情報が含まれていないことに注意してください。このため、Cisco Bug ID CSCef44699(登録ユーザ専用)に追加された新しいコマンドを使用すると、GREトンネル経由で到達すると予想される最小パスMTUをユーザが指定できるようになります。新しいコマンドはtunnel path-mtu-discovery min-mtu <minimum MTU>で、トンネルインターフェイスコンフィギュレーションモードで使用できます。このコマンドが使用中で、設定された最小パスMTUよりも小さいネクストホップのパスMTUをアドバタイズするICMP「Fragmentation Needed and DF bit set」メッセージをデバイスが受信した場合、デバイスでは次のようなログメッセージが生成されます。 
  

  %TUN-5-IGNOREICMPMTU Tunnel1 ignoring received ICMP Type 3 Code 4,
   due to pmtud min-mtu setting

• Layer 2 Tunneling Protocol Version 2 and Layer 2 Tunneling Protocol Version 3:L2TPバージョン2の場合、Cisco Bug IDはCSCsa52807(登録ユーザ専用):PMTUDを実行するL2TPv2は、スプーフィングされたICMPパケットに対して脆弱です。L2TPバージョン3の場合、バグIDはCSCef43691(登録ユーザ専用)です。Layer 2 Tunneling Protocol v3(L2TPv3)を使用し、PMTUディスカバリを実行する接続は、巧妙に細工されたICMPパケットに対して脆弱である可能性があります。
  L2TPv2セッションがPMTUD攻撃の影響を受けているかどうかを確認するには、show vpdn session allコマンドを実行します | include Session MTUを使用します。
  

  Router#show vpdn session all | include Session MTU
    Session MTU is 68 bytes

  L2TPv3では、show l2tun session allコマンドを実行することで、PMTUD攻撃を識別できます | include PMTUコマンドを使用します。
  

  Router#show l2tun session all | include Session MTU
    Session PMTU enabled, path MTU is 68 bytes
    Session PMTU enabled, path MTU is 68 bytes
    Session PMTU enabled, path MTU is 68 bytes

  L2TPv2の場合、ICMPエラーメッセージには、L2TPv2パケットに関する十分な情報が含まれていないため、メッセージを正しく認証するためにエラーが発生する点に注意してください。このため、Cisco Bug ID CSCsa52807(登録ユーザ専用)に対する修正では、L2TPv2トンネル全体で使用すると予想される最小および最大パスMTUをユーザが指定できる新しいコマンドが追加されています。新しいコマンドはvpdn pmtu minimum <minimum MTU>およびvpdn pmtu maximum <maximum MTU>で、vpdn-groupコンフィギュレーションモードで使用できます。これらのコマンドが使用中で、最小および最大範囲外のネクストホップパスMTUをアドバタイズするICMP「Fragmentation Needed and DF bit set」メッセージをデバイスが受信した場合、デバイスは次のログメッセージを生成します。 
  

  %VPDN-5-IGNOREICMPMTU Ignoring received ICMP Type 3 Code 4, 
  due to pmtu min or max setting

IOS XR

IOS XRは、ICMPの「ハード」エラーメッセージに基づく攻撃およびPMTUD攻撃に対して脆弱です。この脆弱性を文書化しているCisco Bug IDはCSCef45332(登録ユーザ専用)です。CRS-1接続は、巧妙に細工されたICMPパケットに対して脆弱である可能性があります。IOS XRはICMP「source quench」メッセージを処理しないため、このタイプのメッセージに基づく攻撃に対して脆弱ではありません。

Cisco IP フォン

Cisco IP Phoneのさまざまなモデルは、ICMPの「ハード」エラーメッセージ、ICMPの「ソースクエンチ」メッセージ、および/またはPMTUD攻撃に基づく攻撃に対して脆弱です。

• CSCef46728(登録ユーザ専用):SCCPファームウェアを搭載した7940/7960 IP Phoneは、巧妙に細工されたICMPの「ハード」エラーメッセージの影響を受ける可能性があります。
• CSCef54947(登録ユーザ専用):SCCPファームウェアを搭載した7970 IP Phoneは、巧妙に細工されたICMPの「ハード」エラーメッセージの影響を受ける可能性があります。
• CSCef54204(登録ユーザ専用):SIPファームウェアを搭載した7940/7960 IP Phoneは、巧妙に細工されたICMP「source quench」エラーメッセージに対して脆弱な場合があります。SIPファームウェアを搭載した7940/7960 IP Phoneはシグナリング用のTCPをサポートしないため、この脆弱性の影響を受けるのは、電話機へのtelnetセッション（管理用）と、電話機からの短時間のHTTPセッション（ディレクトリサービスを提供するサーバなど）だけです。
• CSCef54206(登録ユーザ専用):SIPファームウェアを搭載した7940/7960 IP Phoneは、巧妙に細工されたICMPの「ハード」エラーメッセージに対して脆弱な場合があります。SIPファームウェアを搭載した7940/7960 IP Phoneはシグナリング用のTCPをサポートしないため、この脆弱性の影響を受けるのは、電話機へのtelnetセッション（管理用）と、電話機からの短時間のHTTPセッション（ディレクトリサービスを提供するサーバなど）だけです。

Cisco PIXセキュリティアプライアンス

IPSecが設定されたPIXセキュリティアプライアンスは、RFC 1191およびRFC 2401(「Security Architecture for the Internet Protocol」 - http://www.ietf.org/rfc/rfc2401.txt .)に従ってPMTUDに積極的に参加します。これは、PIXセキュリティアプライアンスがICMPの「fragmentation needed and DF bit set」メッセージを受信すると、特定のIPSecフローのパスMTUを動的に検出して調整できます。

このシナリオでは、PIXセキュリティアプライアンスは、パスMTUを非常に低い値に設定しようとする巧妙に細工されたICMPタイプ3コード4メッセージにも対して脆弱です。この脆弱性は、Cisco Bug ID CSCef57566(登録ユーザ専用)として文書化されています。IPSecが設定されたPIXセキュリティアプライアンスは、パスまたはセキュリティアソシエーションに対して非常に小さなPMTUを示唆する巧妙に細工されたICMPパケットの影響を受けやすくなっています。この症状は、IPSecがPMTUD用に設定されている場合に発生します。PMTUDは、PIXセキュリティアプライアンスでIPSecが設定されると自動的にオンになります。

Catalyst 6608 と 6624

デジタルPRIゲートウェイ、会議ブリッジ、またはトランスコーダ/MTPファームウェアを実行しているCisco Catalyst 6000音声E1/T1およびサービスモジュール（WS-X6608-E1およびWS-X6608-T1）のCisco 6000 FXSアナログインターフェイスモジュール(WS-X6624-FXS)は、ICMPの「hard」エラーと「source ench」に基づく攻撃にに脆弱です」メッセージが表示されます。これらの脆弱性を文書化するCisco Bug IDは、CSCsa60692(登録ユーザ専用):ICMPハードエラー処理です。

Cisco 11000および11500 Content Services Switch

Cisco 11000および11500 Content Services Switchは、管理ポート上のICMP「source quench」メッセージに基づく攻撃に対して脆弱です。ネットワークポート上の攻撃に対しては脆弱ではありません。CSSはPMTUDを実行しないため、PMTUD攻撃に対して脆弱ではありません。ICMPの「source quench」メッセージに対する脆弱性を文書化しているCisco Bug IDは、CSCeh45454(登録ユーザ専用):TCPに対するICMPエラーパケット攻撃です。

シスコグローバルサイトセレクタ

Cisco Global Site Selectorバージョン1.2以前は、ICMPの「ソースクエンチ」メッセージに基づく攻撃に対して脆弱です。ICMPの「ハード」エラーメッセージに基づく攻撃やPMTUD攻撃に対しては脆弱ではありません。ICMPの「source quench」メッセージに対する脆弱性を文書化しているCisco Bug IDは、CSCeh20083(登録ユーザ専用):TCPに対するICMPエラーパケット攻撃です。

Cisco MDS 9000 Series Multilayer Switches

Cisco MDS 9000シリーズマルチレイヤスイッチは、PMTUDおよび「ソースクエンチ」攻撃に対して脆弱です。この脆弱性を文書化しているCisco Bug IDは、CSCeh04183(登録ユーザ専用):TCPに対するICMP攻撃です。

Cisco ONS製品

該当するCisco ONS製品は、PMTUD攻撃に対してのみ脆弱です。

VPN 5000 コンセントレータ

VPN 5000コンセントレータは、PMTUD攻撃に対して脆弱です。ICMPの「ソースクエンチ」メッセージは、メッセージ数を維持するためにのみ処理されますが、輻輳を回避するためのものではありません。したがって、このデバイスは、このタイプのメッセージに基づく攻撃に対して脆弱ではありません。PMTUDの脆弱性を文書化しているCisco Bug IDは、CSCeh59823(登録ユーザ専用)です。ICMP 3/4メッセージはIPSecセッションに影響を与える可能性があります。

Cisco MGX-8250およびMGX-8850

Cisco MGX1(PXM1)およびMGX2(PXM45s、PXM1E)は、管理側でのICMP「ソースクエンチ」攻撃、PMTUD攻撃、およびICMP「ハード」エラー攻撃に対して脆弱です。これは、管理TCP接続(telnet、SSH)に影響し、サービスのスイッチングには影響しないことに注意してください。これらの脆弱性を追跡するCisco Bug IDは、Cisco MGX1の場合はCSCeh65337(登録ユーザ専用)で、Cisco MGX2の場合はCSCeh63449(登録ユーザ専用)です。

Cisco コンテント スイッチング モジュール

Cisco Content Switching Module(CSM)は、デバイスへのTCPベースの管理接続に対するICMP「ソースクエンチ」攻撃に対して脆弱です。デバイスを通過するトラフィックは影響を受けません。

Microsoft Windowsのバージョンを含むシスコ製品

シスコがカスタマイズしたバージョンのMicrosoft Windowsを使用する音声およびIPコミュニケーション製品と、同じくバージョンのMicrosoft Windowsを含むACS Solution Engineは、PMTUD攻撃およびICMPの「ハード」エラーメッセージに基づく攻撃に対して脆弱です。Microsoft Windowsにおけるこれらの脆弱性の詳細については、Microsoft Security Bulletin MS05-019を参照してください。

音声およびIPコミュニケーション製品におけるこれらの脆弱性を追跡するCisco Bug IDはありません。ACS Solution Engineの場合、これらの脆弱性の追跡に使用されるCisco Bug IDはCSCeh62307(登録ユーザ専用)です。

回避策の効果は、製品の組み合わせ、ネットワークトポロジ、トラフィックの動作、組織のミッションなど、お客様の状況によって異なります。該当する製品とリリースは多岐に渡るので、サービス プロバイダーやサポート機関に連絡し、ネットワーク内で使用するのに最も適した回避策を確認してから、実際に配備することを推奨いたします。

PMTUDの無効化による影響

次に示すように、巧妙に細工されたICMP「fragmentation needed and DF bit set」メッセージ（またはICMPv6「message too big」メッセージ）に基づく攻撃の影響を緩和する最も一般的な回避策の1つは、設定コマンドを使用して可能な場合にPMTUDを無効にすることです。

一般に、PMTUDを無効にすることに対して悪影響があってはならないことに注意することが重要です。PMTUDを無効にすると、デバイスはDFビットがクリアされたデータグラムを送信します。大きなパケットが小さなMTUのルータに到達すると、そのルータはパケットを複数の小さなパケットにフラグメント化します。小さな断片化されたデータは宛先に到達し、元の大きなパケットに再構成されます。

もう1つの考慮事項として、TCPでPMTUDを無効にした場合、TCPはパスMTUの変更に基づいてMSSを調整せず、実際に使用されるMSSの値がパスMTUよりも大きい場合は、そのMSSによって不必要なセグメンテーションが発生する可能性があります。使用されるMSS値は、（コンフィギュレーションコマンドを使用して）手動で設定された値か、何も明示的に設定されていない場合はデフォルトの536バイト（宛先がリモートの場合）、または発信インターフェイスのMTUから40バイト（IPヘッダーサイズは20バイト、TCPヘッダーサイズは20バイト）を引いた値（宛先がローカルの場合）になります。不必要なセグメント化を避けるために、MSSはデータパス内の最小のMTUを通過するのに十分な小さな値に手動で設定することをお勧めします。

注：Cisco IOSの特定のケースでは、実装の詳細が原因でPMTUDが無効になっている場合、MSS値を(ip tcp mss <MSS value>コマンドを使用して)手動で設定することはできません。PMTUDを無効にした場合に使用される実際のMSSは、宛先がリモートの場合は536バイトになり、宛先がローカルの場合はインターフェイスのMTUから40バイト（イーサネットの場合は1460バイトなど）を引いた値になります。

最後に、一般に、PMTUDを無効にしても既存の接続には影響しません。つまり、新しいPMTUD設定を有効にするには、既存の接続を手動で終了して再確立する必要があります。

音声アプリケーション、PIXセキュリティアプライアンス、およびPMTUD

音声アプリケーション（Cisco CallManagerなど）を実行しているデバイスでPMTUDを無効にすると、音声トラフィックがCisco PIXセキュリティアプライアンスを通過していて、PIXセキュリティアプライアンスでSCCP(fixup protocol skinny)、SIP(fixup protocol sip)、H.323(fixup protocol h323)などの音声プロトコルのフィックスアップが行われている場合に、望ましくない状態になる可能性があります

注：Cisco CallManagerのデフォルトのインストールでは、PMTUDが無効になっています。

この問題は、セグメント化またはフラグメント化されたProtocol Data Unit（PDU；プロトコルデータユニット）を持つ音声シグナリングトラフィックを、PIXセキュリティアプライアンス/FWSMソフトウェアが常に完全に検査できないために発生します。PMTUDが無効になっていると、十分に大きなPDUが複数のTCPセグメントまたはIPフラグメントに分割される可能性があり、これが原因で、セカンダリ接続およびメディアトラフィック用のピンホールが適切に開かない場合があります。

したがって、音声アプリケーションを実行しているデバイスでPMTUDを無効にすることを決定する場合は、必要なセカンダリシグナリングとメディアトラフィックを許可し、各プロトコルのフィックスアップを無効にするアクセスルールをプロビジョニングするように注意してください。

ローカルセキュリティポリシーによっては、ポートを事前に開く必要があるため、PMTUDを無効にする回避策は適用されません。

ICMP到達不能メッセージのフィルタリングによる影響

特にIPSecの場合や、PMTUDを無効にできない製品の場合に推奨される別の回避策は、ICMPの「fragmentation needed and DF bit set」メッセージをフィルタリングすることです。ICMPの「Fragmentation Needed and DF bit set」メッセージをブロックする推奨事項は、ネットワーク内の他の場所に宛てられたメッセージではなく、保護されるデバイス宛てのメッセージに適用されることに注意してください。ICMP到達不能メッセージを無差別にブロックすると、RFC 2923で説明されている「ブラックホール」が発生する可能性があります(「TCP Problems with Path MTU Discovery」 - http://www.ietf.org/rfc/rfc2923.txt )。

また、ICMPの「Fragmentation Needed and DF bit set」メッセージがエンドホストで受信されるのをブロックしている場合、エンドホストはDFビットがクリアされたパケットを送信する必要があります。これを行うには、PMTUDを無効にします。無効にする方法がない場合は、サポートされている箇所で「crypto ipsec df-bit clear」などの特別なメカニズムを使用します（IPSecの場合）。

ICMP到達不能パケットがブロックされ、パケットがDFビットが設定された状態で送信された場合、中間ルータが特定のPMTUに対して大きすぎるパケットをフラグメント化する必要がある状況にエンドホストが対応できなくなります。この状況では、送信元（エンドホスト）でパケットをフラグメント化するか、DFビットがクリアされた状態でパケットを再送信する必要があります。

Cisco IOSの回避策

Transmission Control Protocol Over IPバージョン4

PMTUDが明示的に有効になっている場合、PMTUD攻撃を防ぐ回避策として考えられるのは、グローバルコンフィギュレーションコマンドno ip tcp path-mtu-discoveryを使用してPMTUDを無効にすることです。このコマンドを実行すると、PMTUDはすべての新しい TCP接続に対して無効になります。IOSデバイスでPMTDを設定しても、ルータとの間ですでに確立されている既存のTCPセッションには影響しません。

PMTUDが無効な場合、使用されるMSSは、ip tcp mssコマンドで設定された値、またはリモート宛先の場合はデフォルトの536バイト、ローカル宛先の場合は1460バイトになります。

Transmission Control Protocol Over IPバージョン6

TCP over IPv6を使用している場合、PMTUDはデフォルトで有効になっており、無効にすることはできません。このため、考えられる回避策は、ACLを使用してICMPv6「packet too big」メッセージをブロックすることです。

ICMPv6「packet too big」メッセージのフィルタリングは、レイヤ3(IPv6)PMTUDもシャットダウンされていることを意味します。したがって、エンドホストのMTUを可能な限り小さいIPv6 MTU（1280バイト）に設定する必要があります。そうしないと、デバイスは「packet too big」メッセージを認識しないため、中継システムが大きすぎるためにパケットをドロップしたことを認識できません。

ICMPv6「packet too big」メッセージは、ICMPv4「fragmentation needed and DF bit set」メッセージと同等のIPv6です。したがって、「ICMP到達不能メッセージのフィルタリングアウトの効果」セクションで説明した同じ考慮事項が、ICMPv6「パケットが大きすぎる」メッセージのフィルタリングアウトにも適用されます。

IPSec

IPSecの場合、推奨される回避策はPMTUDを「無効」にすることです。IPSecでPMTUDを無効にするコマンドは1つだけではありませんが、他のメカニズムを使用して実行できることに注意してください。特に、次の2つのことを行う必要があります。

1. Access Control List（ACL；アクセスコントロールリスト）またはControl Plane Policing（CoPP；コントロールプレーンポリシング）機能を使用して、ルータ自体を宛先とするICMPの「Fragmentation Needed and DF bit set(Fragmentation Needed and DF Bit Set)」メッセージ（タイプ3、コード4）をフィルタリングします。
   次の例は、インターフェイスACLを使用してデバイスのIPアドレスにアドレス指定されるICMP「fragmentation needed and DF bit set」（タイプ3、コード4）メッセージをブロックする方法を示しています(タイプ3、コード4メッセージは、packet-too-bigキーワードを使用して指定されていることに注意してください)。
   

   access-list 111 deny icmp any host <fa0/0's IP address> packet-too-big
   access-list 111 deny icmp any host <fa0/1's IP address> packet-too-big
   access-list 111 deny icmp any host <fa0/2's IP address> packet-too-big
   access-list 111 permit ip any any
   !
   interface fastEthernet 0/0
     ip access-group 111 in
   !
   interface fastEthernet 0/1
     ip access-group 111 in
   !
   interface fastEthernet 0/2
     ip access-group 111 in
   

   注：この回避策を有効にするには、ルータのすべてのIPアドレスをACLに含め、ACLをすべてのインターフェイスに適用する必要があります。

   このタイプのフィルタリングは、ネットワークのベストプラクティスであるインフラストラクチャACLの一部として実装できます。iACLの詳細については、http://www.cisco.com/warp/public/707/iacl.htmlの「Protecting Your Core: Infrastructure Protection Access Control Lists」を参照してください。
   次の例は、コントロールプレーンポリシング(COPP)を使用して同じ処理を行う方法を示しています。
   

   access-list 140 permit icmp any host <interface0 IP address> packet-too-big
   access-list 140 permit icmp any host <interface1 IP address> packet-too-big
   [...]
   access-list 140 permit icmp any host <interfaceN IP address> packet-too-big
   access-list 140 deny   ip   any any
   !
   class-map match-all icmp-class
     match access-group 140
   !
   policy-map control-plane-policy
     ! Drop all traffic that matches the class "icmp-class"
     class icmp-class
            drop
   !
   control-plane
    service-policy input control-plane-policy
   

   注：CoPPは、IOSリリーストレイン12.0S、12.2S、および12.3Tで使用できます。CoPP機能の設定と使用方法の詳細については、次のURLを参照してください。http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html

2. DFビットが設定されている場合でも、IPSecが埋め込みパケットをフラグメント化することを許可します。これを行うには、crypto ipsec df-bit clearコマンド(IOS 12.2(2)T以降で使用可能)を使用するか、Policy-Based Routing（PBR；ポリシーベースルーティング）(IOS 12.1(6)以降で使用可能)を使用してDFビットをクリアします。
   次に、PBRを使用してDFビットをクリアする方法の例を示します。
   

   route-map clear-df permit 10
     match ip address 101
   
     
   !--- The following command is used to change the !--- Don't Fragment (DF) bit value in the IP header; !--- it must be used in route-map configuration mode.
   
     set ip df 0
   
   access-list 101 permit tcp 10.1.3.0 0.0.0.255 any
   
   interface ethernet0
     ...
   
     
   !--- The following command is used to identify a !--- route map to use for policy routing on an !--- interface; if must be used in interface !--- configuration mode.
   
     ip policy route-map clear-df
   

   この例では、ルートマップは暗号化されていないトラフィックがルータに入るインターフェイスに適用され、10.1.3.0/24はIPSecトンネルを介してトラフィックを送信しているアドレス空間です。

総称ルーティングカプセル化とIPinIP

この場合の唯一の回避策は、トンネルインターフェイスでPMTUDが有効になっている場合に、PMTUDを無効にすることです。これは、特定のトンネルインターフェイスコンフィギュレーションモードでno tunnel path-mtu-discoveryコマンドを使用して実行します。

tunnel path-mtu-discoveryコマンドが設定されていない場合、GRE IPヘッダーのDFビットは常にクリアされます。これにより、カプセル化されたデータIPヘッダーにDFビットが設定されていても、GRE IPパケットをフラグメント化できます。通常、DFビットはパケットのフラグメント化を許可しません。

IPSecでGREを使用している場合は、コマンドcrypto ipsec df-bit clearの代わりにno tunnel path-mtu-discoveryコマンドを使用して、送信パケットでDFビットがクリアされるようにする必要があります。また、アクセスコントロールリスト(ACL)または前述のコントロールプレーンポリシング(CoPP)機能を使用して、ルータ自体を宛先とするICMP「fragmentation needed and DF bit set」メッセージ（タイプ3、コード4）もから除外するする必要があります。

Cisco Bug ID CSCef44699(登録ユーザ専用)で修正されたイメージがある場合は、特定のトンネルインターフェイス設定モードで新しいコマンドtunnel path-mtu-discovery min-mtu <minimum MTU>を使用することにより、PMTUDプロセスを介して学習されるMTUに下限を設定できます。

Layer 2 Tunneling Protocol Version 2およびLayer 2 Tunneling Protocol Version 3

レイヤ2トンネリングプロトコル(L2TP)セッション（バージョン2と3の両方）をPMTUD攻撃から保護する唯一の回避策は、PMTUDが有効になっている場合にPMTUDを無効にすることです。L2TPv2の場合は、次に示すように、vpdn-groupコンフィギュレーションモードでno ip pmtuコマンドを使用して設定を行います。

router(config)#vpdn enable
router(config)#vpdn-group 1
router(config-vpdn)#no ip pmtu

L2TPv3の場合は、次に示すように、疑似回線クラスコンフィギュレーションモードでno ip pmtuコマンドとno ip dfbit setコマンドを使用して設定します。

pseudowire-class [pseudowire class name]
  encapsulation l2tpv3
  no ip pmtu
  no ip dfbit set
  [...]

L2TPv2の場合、Cisco Bug ID CSCsa52807(登録ユーザ専用)で修正されたイメージがある場合は、新しいコマンドdsvpdn pmtu minimum <minimum MTU>およびvpdn pmtu maximum <maximum MTU> をvpdn-groupコンフィギュレーションモードで使用することにより、PMTUDプロセスで学習されるMTUに上限とを設定できます。

IOS XRの回避策

Cisco CRS-1が他のピアとのTCPセッションを確立している場合は、設定上の回避策がないため、SMUを適用するか、脆弱性のないバージョンのIOS XRにアップグレードすることを推奨します。

Cisco IP Phoneの回避策

Cisco IP Phoneに対するICMP「ハード」エラーおよび「ソースクエンチ」攻撃の回避策はありません。ただし、VLANテクノロジーを使用して音声とデータをセグメント化することで、これらの攻撃を軽減できます。一般的には、ホワイトペーパー『SAFE: IP Telephony Security in Depth（SAFE: IPテレフォニーセキュリティの詳細）』(http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_papers_list.html)に記載されているIPテレフォニーの推奨ベストプラクティスに従うことで軽減できます。

Cisco PIXセキュリティアプライアンスの回避策

「脆弱性が存在する製品」セクションで説明したように、PIXセキュリティアプライアンスは、IPSecが設定され、有効になっている場合にのみ影響を受けます。この脆弱性に該当する場合は回避策がなく（PIXセキュリティアプライアンスではPMTUDを無効にできないため）、脆弱性のないバージョンのPIXセキュリティアプライアンスソフトウェアにアップグレードすることを推奨します。

PMTUD攻撃を防ぐことはありませんが、コマンドclear ipsec saを使用すると、管理者はセキュリティアソシエーション(SA)をリセットして、トンネルのパスMTUを元の値に戻すことができます。

Cisco VPN 5000コンセントレータの回避策

設定ディレクティブPreTunnelFragmentationを「no」に設定することで、PMTUDを完全に無効にすることができます。

PreTunnelFragmentationが「yes」設定でオンのままになっている場合でも、VPN 5000には着信パケットに対して非常に厳密なアクセスルールがあることに注意してください。攻撃が外部（インターフェイスEthernet 1）から発信された場合、パケットは常に廃棄され、IPSec接続には影響しません。トンネルを通過するパケット、または内部インターフェイス(Ethernet 0)から発信されるパケットは、引き続きPMTUD攻撃に対して脆弱です。一部のお客様は、イーサネット0だけが接続され、トンネルを終端する「シングルアームモード」でデバイスを実行しています。このシナリオに該当するお客様には脆弱性が存在します。

その他のオペレーティングシステムの回避策

シスコには、Microsoft Windowsや異なるバージョンのUnixなど、他のオペレーティングシステム上で動作する製品があります。これらの製品は通常、中間システムとしてではなく、エンドホストとして動作します。したがって、オペレーティングシステムに脆弱性が存在する場合は、このドキュメントで説明されている脆弱性の影響を受ける可能性があります。このセクションで説明する回避策、特にPMTUDを無効にする回避策は、これらのオペレーティングシステムに対しても有効な回避策です。

Microsoft Windowsおよび複数のバージョンのUnixでパスMTUを無効にする方法については、『Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems』ドキュメント(http://cisco.com/en/US/tech/tk870/tk877/tk880/technologies_tech_note09186a008011a218.shtml)を参照してください。

ICMPソースクエンチ攻撃からの保護

ICMPの「ソースクエンチ」メッセージは、ネットワークの輻輳を処理するための初期の試みでしたが、現在の標準では、このシナリオを処理するための効果的な方法ではないことが認識されています。このため、最近のほとんどのTCP/IP実装では、このようなメッセージの受信は無視され、送信はされません。この状況では、脆弱なデバイスとネットワークのエッジの両方で、ICMPの「ソースクエンチ」メッセージを比較的安全にフィルタリングできます。

スプーフィングされたパケットに対する保護

ネットワークのベストプラクティスと考えられますが、ユニキャストReverse Path Forwarding(uRPF)、IPソース検証、DHCPリースクエリー、ダイナミックACLとAAA、およびミニACL（AAAも含む）などの機能は、スプーフィングされたIP送信元アドレスによって発生する問題を緩和するのに役立ち、これらのICMPパケットがスプーフィングされていない場合には、ICMPメッセージに基づく攻撃を緩和するのに効果的ではありません。この理由は、攻撃者がこの脆弱性を不正利用するために、必ずしもパケットの送信元アドレスをスプーフィングする必要がないためです。ただし、攻撃者がパケットをスプーフィングする場合は、ネットワークのエッジでアンチスプーフィングメカニズムを実装すると、攻撃を軽減するのに役立ちます。

アンチスプーフィングの詳細については、http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#sec_ipおよびRFC 2827(『Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing』 - http://www.ietf.org/rfc/rfc2827.txt )を参照してください。

IOSのuRPF機能は、スプーフィングされたIP送信元アドレスによって引き起こされる問題を軽減するのに役立ちます。uRPFを有効にするには、次のコマンドを使用します。

router(config)# ip cef
router(config)# interface  

router(config-if)# ip verify unicast reverse-path

uRPFの動作の詳細やさまざまなシナリオでの設定方法については、機能ガイドUnicast Reverse Path Forwarding Loose Modeおよびftp://ftp-eng.cisco.com/cons/isp/security/URPF-ISP.pdfを参照してください。これは、非対称ルーティングを使用している場合に特に重要です。

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

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

IOSベースの製品

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

「リビルド」および「メンテナンス」という用語の詳細については、次のURLを参照してください。

http://www.cisco.com/web/about/security/intelligence/ios-ref.html

ソフトウェアの可用性の違いと、Cisco IOSに脆弱性が存在する機能シナリオの違いにより、最初の修正済みリリースの表は、各テクノロジーに影響を与えるさまざまな脆弱性に基づいて分類されています。次の4つのグループがあります。

1. TCPv4:CSCed78149(登録ユーザ専用)およびCSCef60659(登録ユーザ専用)を表します。1つ目のCisco Bug IDでは、PMTUD攻撃に対するTCPの脆弱性を追跡します。2つ目のCisco Bug IDでは、PMTUDを使用するすべてのプロトコルに影響を与える脆弱性を追跡します。ただし、TCP over IPv6はこの脆弱性の影響を受けません。
2. トンネル：CSCef60659(登録ユーザ専用)、CSCef43691（登録ユーザ専用）、CSCsa61864(登録ユーザ専用)、CSCsa59600（登録ユーザ専用）、およびCSCef44699（登録ユーザ専用）を表します。これらは、影響を受けるほとんどのトンネリングプロトコル(GRE、L2TPv3、IPSec)の脆弱性を追跡するCisco Bug IDです。
3. TCPv6:CSCef61610(登録ユーザ専用)を表します。これは、IPv6での実行時にPMTUD攻撃に対するTCPの脆弱性を追跡するCisco Bug IDです。
4. L2TPv2:CSCsa52807(登録ユーザ専用)を表します。これは、PMTUD攻撃に対するL2TPv2の脆弱性を追跡するCisco Bug IDです。

非IOSベースの製品

IOSベース以外の製品表（下記）の各行には、修正を含む最初のリリース（「最初の修正済みリリース」）とリリース予定日が記載されています。リストされているリリースより前（First Fixed Releaseより前）のリリースを実行している製品には、脆弱性が存在することが確認されています。製品は、少なくとも指定されたリリース以降のリリース（First Fixed Releaseラベル以上）にアップグレードする必要があります。

サードパーティのオペレーティングシステムをベースとするすべてのシスコ製品について、シスコがOSを提供していない場合は、該当するパッチについて各ベンダーに問い合わせてください。

本アドバイザリは無保証のものとしてご提供しており、いかなる種類の保証も示唆するものではありません。 本アドバイザリの情報およびリンクの使用に関する責任の一切はそれらの使用者にあるものとします。 また、シスコは本ドキュメントの内容を予告なしに変更したり、更新したりする権利を有します。
本アドバイザリの記述内容に関して情報配信の URL を省略し、単独の転載や意訳を施した場合、当社が管理した情報とは見なされません。そうした情報は、事実誤認を引き起こしたり、重要な情報が欠落していたりする可能性があります。 このドキュメントの情報は、シスコ製品のエンドユーザを対象としています。