IOS以外の複数のシスコ製品におけるTCPの脆弱性

このセクションには、該当製品に関する詳細が掲載されています。

脆弱性のある製品

脆弱性を含んでいないことが確認された製品

TCPは、コネクション型の信頼性の高いデータストリーム配信を提供するように設計されたトランスポート層プロトコルです。これを実現するために、TCPは状態とシーケンス番号を示すフラグの組み合わせを使用して、パケットが再構成される順序を特定します。TCPは、確認応答番号と呼ばれる番号も提供します。この番号は、次に予想されるパケットのシーケンス番号を示すために使用されます。パケットのシーケンス番号が確認応答番号の範囲内（「ウィンドウ」と呼ばれます）にある場合にのみ、受信側のTCP実装によってパケットが再構成されます。リセットではパケットが返されることを予期しないため、確認応答番号(ACK)はリセット(RST)フラグが設定されたパケットでは使用されません。TCPプロトコルの詳細な仕様については、http://www.ietf.org/rfc/rfc0793.txtを参照してください。

RFC793の仕様によると、RSTまたは同期(SYN)フラグが設定されたパケットを送信することで、確立されたTCP接続をリセットすることができます。これを行うには、4タプル（送信元と宛先のIPアドレスとポート）がシーケンス番号とともに既知または推測されている必要があります。ただし、シーケンス番号は完全に一致している必要はなく、アドバタイズされたウィンドウ内に収まるのに十分です。これにより、相手が必要とする労力が大幅に軽減されます。ウィンドウが大きいほど、接続をリセットしやすくなります。送信元と宛先のIPアドレスは比較的簡単に判別できますが、送信元のTCPポートを推測する必要があります。宛先TCPポートは通常、すべての標準サービスで認識されています（たとえば、Telnetの場合は23、HTTPの場合は80）。多くのオペレーティングシステム(OS)は、予測可能な増分で既知のサービスに予測可能な一時的なポートを使用します（次の接続に使用される次のポート）。これらの値は、特定のOSやプロトコルでは一定ですが、OSのリリースによって異なります。

TCPセッションの通常の終了の例を次に示します。

                Host(1)                       Host(2)
                  |                             |
                  |                             |
                  |  ACK ack=1001, window=5000  |
                  |<----------------------------|
                  |                             |



              Host(1) is

         closing the session



                  |        RST seq=1001         |
                  |---------------------------->|
                  |                             |



                                            Host(2) is

                                        closing the session

また、次のシナリオも許可されます。

                Host(1)                       Host(2)
                  |                             |
                  |                             |
                  |  ACK ack=1001, window=5000  |
                  |<----------------------------|
                  |                             |



              Host(1) is

         closing the session



                  |        RST seq=4321         |
                  |---------------------------->|
                  |                             |



                                            Host(2) is

                                        closing the session

シーケンス番号(1001)が次に予想されたものではないにもかかわらず、RSTパケットがセッションを終了できることに注意してください。シーケンス番号は、アドバタイズされた「ウィンドウ」内に収まるのに十分でした。この例では、Host(2)は1001 ～ 6001のシーケンス番号を受け入れており、4321は明らかに許容範囲内にあります。

シスコは、http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txtに従ってこの脆弱性を修正しました。

原則として、TCP接続が1分以上確立されたままになっているすべてのプロトコルは、公開されていると見なす必要があります。

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

この脆弱性の影響を軽減する回避策はありません。

ネットワークのエッジにアンチスプーフィング機能を適用することで、この脆弱性の影響を緩和できます。

Unicast Reverse Path Forwarding(uRPF)を有効にすると、スプーフィングされたすべてのパケットは最初のデバイスでドロップされます。uRPFを有効にするには、次のコマンドを使用します。

router(config)#ip cef 

router(config)#interface  


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

uRPFの動作の詳細と、さまざまなシナリオでの設定方法については、http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.htmlおよび ftp://ftp-eng.cisco.com/cons/isp/security/URPF-ISP.pdfを参照してください。これは、非対称ルーティングを使用している場合に特に重要です。

アクセスコントロールリスト(ACL)も、できるだけエッジの近くに配置する必要があります。uRPFとは異なり、許可される正確なIP範囲を指定する必要があります。ブロックするアドレスを指定することは、維持が難しい傾向があるため、最適なソリューションではありません。

注意：アンチスプーフィング対策を効果的に行うには、保護されるデバイスから少なくとも1ホップ離れた場所にアンチスプーフィング対策を展開する必要があります。理想的には、ネットワークエッジに導入されます。

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

シスコは2004年4月20日に複数のアドバイザリをリリースしました。

この脆弱性は公開カンファレンスで報告されました。Cisco PSIRTでは、このアドバイザリに記載されている脆弱性の不正利用の可能性は確認していません。

RSTフラグが設定されたパケット（リセットパケット）に関する脆弱性の不正利用は、OSVDB.orgのPaul (Tony) Watson氏によって発見されました。攻撃ベクトルがSYNフラグが設定され、データ注入が行われるパケットにまで拡大していることは、この問題の解決に協力しているベンダーによって発見されました。