巧妙に細工されたTCPパケットがサービス拒否を引き起こす可能性

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

TCPパケットを受信するように設定されているCisco IOSデバイスは、この問題に該当します。このアドバイザリは、デバイスを通過するトラフィックには適用されません。

Cisco IOSデバイス上の物理インターフェイスまたは仮想インターフェイスに割り当てられたIPv4アドレス宛てに巧妙に細工された特定のパケットによって、デバイスで少量のメモリリークが発生する可能性があります。このようなメモリリークは、時間の経過とともにメモリ不足を招き、サービス低下の可能性があります。

これはTCPの問題ですが、メモリリークをトリガーするためにTCP 3ウェイハンドシェイクを完了する必要はありません。したがって、スプーフィングされた送信元アドレスを持つTCPパケットがリークをトリガーする可能性があります。

次の文書には、ルータでプロセッサメモリのメモリリークが発生しているかどうかを識別する方法についての追加情報が記載されています。

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a6f3a.shtml#tshoot2

Cisco 機器に適用可能な追加の軽減策については以下の "Cisco Applied Intelligence companion document" より入手可能です。

https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20070124-crafted-tcp

注：VTYアクセスクラスフィルタの設定は、この脆弱性に対する効果的な緩和策ではありません。

インフラストラクチャ ACL（iACL）

ネットワークを移動するトラフィックをブロックするのは往々にして困難ですが、インフラストラクチャ デバイスに送られてはならないトラフィックを識別し、ネットワークの境界でそのトラフィックをブロックすることは可能です。インフラストラクチャ ACL はネットワーク セキュリティのベスト プラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワーク セキュリティへの長期的な付加機能として考慮する必要があります。次に示す ACL の例は、インフラストラクチャ IP アドレス範囲内の IP アドレスを持つすべてのデバイスを保護するために配備されたインフラストラクチャ アクセス リストの一部として含める必要があります。

Cisco IOS が稼働するデバイスのアクセス リストの例：

!--- Permit TCP services from trust hosts destined 
!--- to infrastructure addresses.


access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK


!--- Deny TCP packets from all other sources destined to infrastructure addresses.


access-list 150 deny   tcp any INFRASTRUCTURE_ADDRESSES MASK


!--- Permit all other traffic to transit the device.


access-list 150 permit IP any any

interface serial 2/0
  ip access-group 150 in

ホワイトペーパー『Protecting Your Core: Infrastructure Protection Access Control Lists』には、アクセスリストによるインフラストラクチャ保護のガイドラインと推奨される導入方法が記載されています。このホワイトペーパーは、http://www.cisco.com/warp/public/707/iacl.htmlから入手できます。

受信ACL(rACL)

分散型のプラットフォームにおいては、Cisco12000 シリーズ(GSR) では 12.0(21)S2、 Cisco7500 シリーズでは 12.0(24)S、Cisco10720 シリーズでは 12.0(31)S の IOS ソフトウェアにてサポートされている Receive ACL も選択肢となります。受信 ACL は、ルート プロセッサが有害なトラフィックの影響を受ける前に、そのトラフィックからデバイスを保護します。受信 ACL は、それが設定されたデバイスのみを保護する設計になっています。12000 では、受信 ACL は通過トラフィックに作用しません。このため、以下の ACL の例において宛先 IP アドレス "any" が用いられても、自ルータの物理あるいは仮想 IP アドレスのみが参照されます。7500 および 10720 では、IP オプションの設定された通過トラフィックは、受信 ACL の対象となり、これに従って許可または拒否されます。受信 ACL はネットワーク セキュリティのベスト プラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワーク セキュリティへの長期的な付加機能として考慮する必要があります。ホワイトペーパー『GSR: Receive Access Control Lists』には、デバイスへの正当なトラフィックを識別して許可し、望ましくないパケットをすべて拒否する方法が記載されています。http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml

次の receive path ACL は信頼できるホストからのこのようなタイプのトラフィックを許可するように記述されています。

!--- Permit tcp services from trusted hosts allowed to the RP.
   
                                                
access-list 151 permit tcp TRUSTED_ADDRESSES MASK any                                                        


!--- Deny tcp services from all other sources to the RP.
                                                         

access-list 151 deny   tcp any any                                                                           


!--- Permit all other traffic to the RP.
                                                                         

access-list 151 permit ip any any                                                                            


!--- Apply this access list to the 'receive' path.
                                                               

ip receive access-list 151

コントロール プレーン ポリシング（CoPP）

コントロールプレーンポリシング(CoPP)機能を使用して、この脆弱性を緩和することができます。次の例では、信頼できるホストからのTCPトラフィックで、宛先IPアドレスが「receive」のトラフィックだけが、ルートプロセッサ(RP)に到達することを許可されています。他のすべての「通過」IPトラフィックには影響しません。

不明な IP アドレスや信頼できない IP アドレスからのトラフィックを廃棄することにより、Cisco IOS デバイスへの接続で IP アドレスが動的に割り当てられたホストには影響が及ぶ可能性がある点に注意してください。

access-list 152 deny   tcp TRUSTED_ADDRESSES MASK any
access-list 152 permit tcp any any
access-list 152 deny  ip any any
!
class-map match-all permit-tcp-class
 match access-group 152
!
!
policy-map permit-tcp-policy
 class permit-tcp-class
  drop
!
control-plane
 service-policy input permit-tcp-policy

上の CoPP の例では、「permit」アクションがあり悪用パケットと一致する ACL エントリがある場合、ポリシー マップの「drop」機能によってこれらのパケットは廃棄されますが、「deny」アクションと一致するパケットはポリシー マップ drop 機能の影響を受けません。

Cisco IOS トレイン 12.2S および 12.0S では、ポリシーマップの構文が異なることに注意してください。

policy-map permit-tcp-policy                                                                             
 class class permit-tcp-class                                                                            
  police 32000 1500 1500 conform-action drop exceed-action drop

CoPP は、Cisco IOS リリース トレイン 12.0S、12.2SX、12.2S、12.3T、12.4、および 12.4T で使用できます。

CoPP 機能の設定と使用方法についての詳細は、次の URL で確認できます。

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html

アンチスプーフィング

Unicast Reverse Path Forwarding（ユニキャストRPFまたはuRPF）機能は、スプーフィングされたIP送信元アドレスによって引き起こされる問題の緩和に役立ちます。シスコのルータおよびファイアウォールで使用できます。詳細については、次を参照してください。

http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html

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

router(config)#ip cef                                                                                     
router(config)#interface interface #                                                                      
router(config-if)#ip verify unicast source reachable-via rx

BGPおよびBTSH/GTSM

ソフトウェアのリリースによっては、このメモリリークからBGPセッションを保護できる場合があります。CSCee73956(登録ユーザ専用)の導入により、Cisco IOSではBTSH(BGP TTL Security Hack)のサポートが改善され、この脆弱性によるメモリリークのリスクを排除できなくても、これを軽減できるようになりました。この機能はGTSM(Generalized TTL Security Mechanism)とも呼ばれ、RFC 3682で文書化されています。このセクションでは、eBGPセッションのみに適用されるGTSMについて説明します。

CSCee73956を含むCisco IOSのリリースは、BGPポート（TCPポート179）に対してのみこの攻撃から保護されます。その他のポートは、それに応じて保護する必要があります。

BTSHはiBGPセッションではサポートされていません。BTSHは、Cisco IOSの12.0(27)S、12.3(7)T、および12.2(25)Sで最初に導入されました。CSCee73956より前のBTSH機能では、この脆弱性に対する保護は行われないことに注意してください。

BTSHの詳細については、次のサイトを参照してください。http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html

BGPおよびMD5

Cisco IOSデバイスでBGP MD5認証を設定することは、BGPポート(TCP 179)に対して送信される巧妙に細工されたTCPパケットから脆弱性のあるデバイスを保護するための有効な回避策です。

これは、次の例に示すように設定できます。

router(config)#router bgp <AS_number>
router(config-router)#neighbor <IP_address> password <enter_your_secret_here>

両方のピアで同時に同じ共有MD5シークレットを設定する必要がある場合があります。CSCdx23494(登録ユーザ専用)の導入により、BGPセッションを切断せずにBGP MD5キーを動的に変更できるようになりました。

BGPセッションはリセットされませんが、同じMD5キーが両側で設定されるまでBGPアップデートは処理されません。

CSCdx23494(登録ユーザ専用)が導入される前は、MD5パスワードを同時に変更しないと、既存のBGPセッションが中断され、両方のデバイスで同じMD5共有秘密が設定されるまで、新しいセッションが確立されません。BGPの設定方法の詳細については、次の文書を参照してください。

http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.html

MD5共有秘密を設定したら、定期的に変更することをお勧めします。正確な期間は、会社のセキュリティポリシーに適合している必要があります。

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

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

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

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

http://www.cisco.com/web/about/security/intelligence/ios-ref.html にアクセスしてください。

注：2007年1月24日に公開されるIOSセキュリティアドバイザリは3件、Field Noticeは1件です。各アドバイザリには、そのアドバイザリに記載された問題を修正するリリースのみが記載されています。結合されたソフトウェアテーブルはhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20070124-bundleで入手でき、2007年1月24日の時点で公開されているすべてのセキュリティ脆弱性を修正するソフトウェアリリースの選択に使用できます。このアドバイザリとField Noticeへのリンクを次に示します。

• https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20070124-IOS-IPv6
• https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20070124-crafted-tcp
• https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20070124-crafted-ip-option
• http://www.cisco.com/en/US/ts/fn/620/fn62613.html

サマータイム (DST) の変更を含むソフトウェア・リビルドは 2007年3月に提供されます。これについてのリクエストは Technical Assistance Center（TAC）まで直接お問い合わせください。その際にこのアドバイサリーをリファレンスとしてご利用ください。

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

この脆弱性は、シスコの社内テストプロセスで発見されたものです。

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