Cisco IOS Secure Shell(SSH)サーバの脆弱性

Cisco Internetwork Operating System(IOS)^®の特定のリリーストレインでは、IOSデバイスでリモート管理タスクを実行する手段として、Terminal Access Controller Access Control System Plus(TACACS+)と組み合せてIOS Secure Shell(SSH)サーバを使用するように設定されている場合、IOSデバイスでリソースが枯渇してリロードが発生する可能性のある2つの脆弱性が含まれている可能性があります。これらの脆弱性が繰り返し悪用されると、サービス拒否(DoS)状態が発生する可能性があります。Remote Authentication Dial In User Service(RADIUS)やローカルユーザデータベースなどの他の認証方式でのSSHの使用も影響を受ける可能性があります。

シスコでは、該当するすべてのユーザに対して、これらの脆弱性に対応する無償ソフトウェアを提供しています。脆弱性の影響を緩和する回避策があります(「回避策」セクションを参照)。

このアドバイザリは https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20050406-ssh に掲載されています。

セキュアシェル(SSH)は、ネットワークデバイスへのセキュアなリモート接続を提供するプロトコルです。現在、SSHプロトコルにはSSHバージョン1とSSHバージョン2の2つのバージョンがあり、どちらもCisco IOSでサポートされています。IOSのSSHサーバコンポーネントは、プロトコルのバージョン1.0のみを実行している場合はバージョン「1.5」、プロトコルのバージョン2のみを実行している場合はバージョン「2.0」、プロトコルバージョン1にフォールバックしてプロトコルバージョン2を実行している場合はバージョン「1.99」と識別します。

IOSのSSHサーバ機能を使用すると、SSHクライアントからCisco IOSデバイスへのセキュアで暗号化された接続を確立できます。この接続は、認証情報を含む、サーバとクライアント間のすべてのトラフィックがワイヤを通して暗号化されて送信されるという違いがあるため、telnet接続に似た機能を提供します。

TACACSは、サーバ、ワークステーション、ルータ、スイッチ、アクセスサーバ、およびその他のネットワークデバイスにアクセスしようとするユーザを一元的に検証する方法を提供します。

このドキュメントで説明されている2つの脆弱性は、リモート管理にIOS SSHサーバ機能を使用するように設定されたIOSデバイスに影響するサービス拒否(DoS)状態を引き起こす可能性があります。

1つ目の脆弱性は、IOSデバイスがSSHバージョン2サーバとして機能するように設定され、次のいずれかのイベントが発生した場合に、デバイスのリロードを引き起こす可能性があります。

• TACACS+サーバに対して(aaa authentication login <group name> group tacacs+ localなどのコマンドを使用して)ユーザを認証するようにデバイスが設定されており、アカウントのユーザ名にドメイン名が含まれています。この条件は、RADIUSサーバやローカルユーザデータベースなど、異なる方法で認証するように設定されたデバイスには適用されません。
  
• 新しいSSHセッションが認証フェーズにあり（サーバがユーザ名またはパスワードを待機している）、すでにログインしている別のユーザがsendコマンドを使用している。この条件は、TACACS+、RADIUS、およびローカルユーザデータベースを含むすべての認証方式に適用されます。
  
• メッセージのロギングは、すでに確立されているSSHセッションに(terminal monitorコマンドを使用して)転送され、SSHサーバがクライアントにデータを送信している間は、IOSデバイスへのSSHセッションは終了します。この条件は、TACACS+、RADIUS、およびローカルユーザデータベースを含むすべての認証方式に適用されます。
  

この脆弱性は、Cisco Bug ID CSCed65778( 登録ユーザ専用)「ドメイン名が含まれているTACACS+ユーザ名が原因でSSHv2がクラッシュする」に記載されています。

注：この脆弱性は、SSHプロトコルバージョン2に影響します。SSHプロトコルバージョン1は影響を受けません。

2つ目の脆弱性は、IOSデバイスがTACACS+サーバに対してSSHユーザを認証するように設定され、ユーザ名またはパスワードが無効であるためにログインが失敗した場合に発生するメモリリークで構成されています。これは、SSHバージョン1とバージョン2の両方の接続に影響します。SSHバージョン2接続の場合、ログインが成功した後でもメモリリークが発生します。ユーザがRADIUSサーバまたはローカルユーザデータベースに対して認証されている場合、デバイスは影響を受けないことに注意してください。

メモリリークを検出するには、次の例のように、show tcp briefコマンドを実行します。

Router# show tcp brief
TCB       Local Address           Foreign Address        (state)
637202B8  10.0.0.19.13294       172.16.112.29.49       ESTAB
6371C978  10.0.0.19.13233       172.16.112.29.49       ESTAB
636CB228  10.0.0.19.13041       172.16.112.29.49       CLOSEWAIT
636B6900  10.0.0.19.12912       172.16.112.29.49       CLOSEWAIT
63697548  10.0.0.19.12848       172.16.112.29.49       CLOSEWAIT
63687930  10.0.0.19.12784       172.16.112.29.49       CLOSEWAIT
635F4A80  10.0.0.19.12659       172.16.112.29.49       CLOSEWAIT

上記の出力では、CLOSEWAIT状態のTransmission Control Block（TCB；伝送制御ブロック）は消えず、メモリリークを示しています。外部TCPポートが49（TACACSの既知のポート）のTCP接続だけが関連することに注意してください。

この脆弱性は、Cisco Bug ID CSCed65285(登録ユーザ専用)「SSHリークのメモリとバッファ」に記載されています。

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

緩和戦略

ここに示した緩和戦略のすべてが、すべてのお客様に有効とは限りません。リストされている回避策の一部は、ネットワーク内に存在するIOSのバージョンと機能セットによって異なります。

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)の設定

VTYアクセスクラスの設定に加えて、ネットワークインフラストラクチャ宛てのすべてのSSHトラフィックをブロックすることが望ましい場合があります。

信頼できるネットワークへのすべてのアクセスを制御するトランジットACLの一部として、TelnetとリバースTelnetをブロックする必要があります。トランジットACLは、ネットワークセキュリティのベストプラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワークセキュリティへの長期的な付加機能として考慮する必要があります。ホワイトペーパー『トランジットアクセスコントロールリスト：エッジでのフィルタリング』では、トランジットACLのガイドラインと推奨される導入方法について説明しています。

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml

インフラストラクチャアクセスリスト(iACL)の設定

ネットワークを移動するトラフィックをブロックするのは往々にして困難ですが、インフラストラクチャ デバイスに送られてはならないトラフィックを識別し、ネットワークの境界でそのトラフィックをブロックすることは可能です。インフラストラクチャ ACL はネットワーク セキュリティのベスト プラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワーク セキュリティへの長期的な付加機能として考慮する必要があります。ホワイトペーパー『Protecting Your Core: Infrastructure Protection Access Control Lists』では、インフラストラクチャ保護ACLのガイドラインと推奨される導入方法について説明しています。

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

受信アクセスリスト(rACL)の設定

分散プラットフォームの場合、rACLは、12000シリーズGSRのCisco IOSソフトウェアバージョン12.0(21)S2および7500シリーズの12.0(24)S以降のオプションである可能性があります。受信アクセス リストは、ルート プロセッサが有害なトラフィックの影響を受ける前に、そのトラフィックからデバイスを保護します。受信パスACLはネットワークセキュリティのベストプラクティスと考えられており、ここでの特定の脆弱性の回避策としてだけでなく、優れたネットワークセキュリティへの長期的な付加機能として考慮する必要があります。CPU 負荷がライン カード プロセッサに分散されるため、メイン ルート プロセッサの負荷を軽減させるのに役立ちます。ホワイトペーパー『GSR: Receive Access Control Lists』では、デバイスへの正当なトラフィックを識別して許可し、望ましくないパケットをすべて拒否するのに役立ちます。

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml

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

次の例のように、コントロールプレーンポリシー(CoPP)機能を使用して、この脆弱性を緩和できます。

! Do not police SSH traffic from trusted hosts
access-list 140 deny   tcp host <trusted host 1's IP address> any eq 22
access-list 140 deny   tcp host <trusted host 2's IP address> any eq 22
[...]
access-list 140 deny   tcp host <trusted host N's IP address> any eq 22
! Trust an entire network if desired
access-list 140 deny   tcp <trusted network address> <trusted network mask> any eq 22
! Police SSH traffic from untrusted hosts
access-list 140 permit tcp any any eq 22
! Do not police any other type of traffic going to the router
access-list 140 deny   ip  any any
!
class-map match-all ssh-class
  match access-group 140
!
policy-map control-plane-policy
  ! Drop all traffic that matches the class "ssh-class"
  class ssh-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

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

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

http://www.cisco.com/warp/public/620/1.html

ソフトウェアのアップグレードを検討する場合は、http://www.cisco.com/en/US/products/products_security_advisories_listing.htmlおよび後続のアドバイザリも参照して、侵害を受ける可能性と完全なアップグレードソリューションを確認してください。

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

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

この脆弱性は、Cisco の社内テストで発見されたものです。