Cisco IOS Secure ShellのDoS脆弱性

セキュアシェル(SSH)は、デバイスのリモートアクセスを可能にするtelnet、ftp、rlogin、rsh、およびrcpプロトコルに代わる安全なプロトコルとして開発されました。SSHと古いプロトコルの主な違いは、SSHは強力な認証を提供し、機密性を保証し、暗号化されたトランザクションを使用することです。

Cisco IOSのSSH実装のサーバ側には複数の脆弱性があり、認証されていないユーザがスプリアスメモリアクセスを生成したり、場合によってはデバイスをリロードしたりすることが可能です。攻撃者がデバイスをリロードできる場合、これらの脆弱性が繰り返し不正利用され、長時間にわたるDenial of Service(DoS)状態が発生する可能性があります。

SSHサーバが有効になっているデバイスには脆弱性が存在します。

これらの脆弱性は、Cisco Bug ID

• CSCsk42419(登録ユーザのみ)
  
• CSCsk60020(登録ユーザのみ)
  
• CSCsh51293(登録ユーザのみ)
  

IOS SSHサーバを無効にできない場合は、環境の一部のお客様に次の回避策が役立つ可能性があります。

Telnet

Telnetはこのアドバイザリで説明されている問題に対して脆弱ではなく、SSHに代わる安全でない手段として使用される可能性があります。Telnetは認証情報やデータを暗号化しません。そのため、信頼できるローカルネットワークに対してのみ有効にする必要があります。

VTYアクセスクラス

VTYアクセスクラスを適用して、既知の信頼できるホストだけにSSH経由でのデバイスへの接続を許可することで、シスコデバイスの公開を制限できます。

VTYへのトラフィック制限の詳細については、http://www.cisco.com/en/US/docs/ios/12_2/ipaddr/command/reference/1rfip1.html#wp1017389を参照してください。

次の例では、192.168.1.0/24ネットブロックと単一のIPアドレス172.16.1.2からのVTYへのアクセスを許可し、その他の場所からのアクセスは拒否しています。

Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255
Router(config)# access-list 1 permit host 172.16.1.2
Router(config)# line vty 0 4
Router(config-line)# access-class 1 in

サポートする端末回線数は、Ciscoプラットフォームによって異なります。デバイスの設定をチェックして、プラットフォームに適した端末回線数を確認します。

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

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

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

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


access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 22


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


access-list 150 deny   tcp any INFRASTRUCTURE_ADDRESSES MASK eq 22


!--- 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から入手できます。

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

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

注：不明なIPアドレスや信頼できないIPアドレスからのトラフィックを廃棄すると、動的にIPアドレスが割り当てられたホストがCisco IOSデバイスに接続できなくなることがあります。

access-list 152 deny   tcp TRUSTED_ADDRESSES MASK any eq 22
    access-list 152 permit tcp any any eq 22
    !
    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機能の設定と使用方法の詳細については、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

12.4(7)、12.4(13d)JA、および12.4(9)Tより前のIOSリリースは、この脆弱性の影響を受けません。

シスコでは、このバグに関連するカスタマーサポートケースが増加したため、このIOSアドバイザリを通常の年2回のサイクルからリリースする予定です。Cisco PSIRTは、悪意のある不正利用の報告を受け取っていません。

この脆弱性は、シスコ内部でのテストとカスタマーサービスリクエストによって発見されました。