IOS FTP サーバの複数の脆弱性

IOS FTP サーバ機能には、複数の脆弱性があります。これらの脆弱性は、次の Cisco Bug ID に記述されています。

• CSCek55259：Improper authorization checking in IOS FTP server
  
• CSCse29244：IOS reload when transferring files via FTP
  

IOS の FTP サーバにはこのような問題があるため、この機能は削除されています。Cisco では、完全な機能を提供する安全な FTP サーバ機能を将来的に追加することを検討しています。

IOS FTP サーバ機能の削除に関しては、Cisco Bug ID CSCsg16908 で取り扱われています。

Cisco では、Common Vulnerability Scoring System（CVSS）に基づき、このアドバイザリで説明されている脆弱性のスコアを評価しました。

Cisco では基本スコアと現状スコアを評価します。お客様はこれらを用いて環境評価スコア （Environmental Score） を算出し、個々のネットワークにおける脆弱性の影響度を導き出すことができます。

Cisco PSIRT は、すべてのケースにおける重みを「標準」に設定します。特定の脆弱性の環境的影響を判断する際には、重みパラメータを適用することを推奨します。

CVSS は、脆弱性の重大度を伝える標準ベースのスコア評価方式であり、対応の緊急度や優先度を判断するのに役立ちます。

シスコは、http://www.cisco.com/web/about/security/intelligence/cvss-qandas.htmlでCVSSに関するFAQを提供しています。

また、シスコは個々のネットワークにおける環境影響度を計算するCVSS計算ツールをhttps://sec.cloudapps.cisco.com/security/center/cvssCalculator.xで提供しています。

次のコマンドをコンフィギュレーション モードで実行することにより、IOS FTP サーバ機能の使用を無効にできます。

no ftp-server enable

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

https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20070509-iosftp

代替ファイル転送メカニズム

Cisco IOS は、デバイスでのファイル転送に関して複数の方式をサポートしています。そのうちの 1 つが、Secure Copy（SCP）です。SCP は、強力な暗号化をサポートする Cisco IOS イメージでサポートされています。SCP の機能についての詳細は、次の URL で確認できます。

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftscp.html

この他に、IOS の Trivial File Transfer Protocol（TFTP）サーバを使用する方法もあります。TFTP サーバの設定については、次のリンク先を参照してください。

http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf011_ps1835_TSD_Products_Configuration_Guide_Chapter.html

IOS の FTP サーバを無効にできない場合には、次のいずれかのメカニズムを使用してデバイスへの FTP アクセスを制限できます。

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

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

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

!--- Permit FTP services from trusted hosts destined 
!--- to infrastructure addresses.


access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 21
access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 20


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


access-list 150 deny   tcp any INFRASTRUCTURE_ADDRESSES MASK eq 21
access-list 150 deny   tcp any INFRASTRUCTURE_ADDRESSES MASK eq 20


!--- 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/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtmlから入手できます。

受信ACL(rACL)

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

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

!--- Permit FTP from trusted hosts allowed to the RP.


access-list 151 permit tcp TRUSTED_ADDRESSES MASK any eq 21
access-list 151 permit tcp TRUSTED_ADDRESSES MASK any eq 20


!--- Deny FTP from all other sources to the RP.


access-list 151 deny   tcp any any eq 21
access-list 151 deny   tcp any any eq 20


!--- Permit all other traffic to the RP.
!--- according to security policy and configurations.


access-list 151 permit ip any any


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


ip receive access-list 151

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

コントロール プレーン ポリシング（CoPP）機能を使用すると、これらの脆弱性を緩和できる可能性があります。次の例では、信頼できるホストが送信元であり、宛先 IP アドレスが「receive」である FTP トラフィックのみがルート プロセッサ（RP）に到達できます。

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

    access-list 152 deny   tcp TRUSTED_ADDRESSES MASK any eq 21
    access-list 152 deny   tcp TRUSTED_ADDRESSES MASK any eq 20
    access-list 152 permit tcp any any eq 20
    access-list 152 permit tcp any any eq 21
    access-list 152 deny    ip any any
    !
    class-map match-all COPP-KNOWN-UNDESIRABLE
     match access-group 152
    !
    !
    policy-map COPP-INPUT-POLICY
     class COPP-KNOWN-UNDESIRABLE
      drop
    !
    control-plane
     service-policy input COPP-INPUT-POLICY

上の CoPP の例では、「permit」アクションがあり悪用パケットと一致する ACL エントリがある場合、ポリシー マップの「drop」機能によってこれらのパケットは廃棄されますが、「deny」アクションと一致するパケットはポリシー マップ 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

アップグレードを検討する場合は、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

2008年12月、PhenoelitのFXはカオス通信会議で「Cisco IOS attack and defense」というタイトルのプレゼンテーションを行い、この脆弱性を利用したエクスプロイトを考案したと主張しました。2008年のChaos Communication CongressでのFXのプレゼンテーションでは、新しい脆弱性は公開されませんでした。

http://events.ccc.de/congress/2008/Fahrplan/events/2816.en.html

シスコでは、この脆弱性の悪用に関する情報を入手していません。