Cisco ASA 5500 シリーズ コンフィギュレーション ガイド(CLI を使用)
暗号化音声検査の TLS プロキシ の設定
暗号化音声検査の TLS プロキシの設定
発行日;2012/02/01 | 英語版ドキュメント(2011/07/15 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 15MB) | フィードバック

目次

暗号化音声検査の TLS プロキシに関する情報

統合された通信の暗号化されたシグナリングの復号化と検査

CTL クライアントの概要

TLS プロキシのライセンス

暗号化音声検査の TLS プロキシの前提条件

暗号化音声検査の TLS プロキシの設定

暗号化音声検査の TLS プロキシの設定のタスク フロー

トラストポイントの作成と証明書の生成

内部 CA の作成

CTL プロバイダー インスタンスの作成

TLS プロキシ インスタンスの作成

Skinny または SIP 検査での TLS プロキシ インスタンスのイネーブル化

TLS プロキシのモニタリング

暗号化音声検査の TLS プロキシの機能履歴

暗号化音声検査の TLS プロキシ の設定

この章では、暗号化音声検査機能の TLS プロキシ用に適応型セキュリティ アプライアンスを設定する方法を説明します。

この章には、次の項があります。

「暗号化音声検査の TLS プロキシに関する情報」

「TLS プロキシのライセンス」

「暗号化音声検査の TLS プロキシの前提条件」

「暗号化音声検査の TLS プロキシの設定」

「TLS プロキシのモニタリング」

「暗号化音声検査の TLS プロキシの機能履歴」

暗号化音声検査の TLS プロキシに関する情報

エンドツーエンド暗号化では、ネットワーク セキュリティ アプライアンスがメディアやシグナリング トラフィックに対して「盲目」になることがよくあります。これにより、アクセス コントロールや脅威回避セキュリティの機能が低下する場合があります。このように可視性が失われると、ファイアウォール機能と暗号化された音声間の相互運用性が失われ、企業では両方の主要なセキュリティ要件に対応できない状態が続く可能性があります。

適応型セキュリティ アプライアンスは、シスコ暗号化エンドポイントから Cisco Unified Communications Manager(Cisco UCM)までの暗号化されたシグナリングを代行受信して復号化し、必要な脅威回避とアクセス コントロールを適用します。また、Cisco UCM サーバへのトラフィックを再暗号化して機密性を保証することもできます。

通常、適応型セキュリティ アプライアンスの TLS プロキシ機能は、構内の統合された通信ネットワークに展開されます。このソリューションは、エンドツーエンド暗号化とファイアウォールを利用して Unified Communications Manager サーバを保護する構成に最も適しています。

図 45-1 のセキュリティ アプライアンスは、Cisco IP Phone と Cisco UCM の対話で、クライアントとサーバの両方のプロキシとして機能します。

図 45-1 TLS プロキシ フロー

 

統合された通信の暗号化されたシグナリングの復号化と検査

暗号化音声検査を使用すると、セキュリティ アプライアンスは、音声シグナリング トラフィックの復号化、検査、変更(必要に応じて NAT フィックスアップの実行など)、および再暗号化を行う一方で、Skinny および SIP プロトコルに対する既存の VoIP 検査機能はすべて維持します。音声シグナリングが復号化されると、プレーンテキストのシグナリング メッセージが既存の検査エンジンに渡されます。

セキュリティ アプライアンスは、Cisco IP Phone と Cisco UCM の間の TLS プロキシとして機能します。プロキシは、電話と Cisco UCM の間の音声通話に対しては透過的です。Cisco IP Phone は、登録の前に Cisco UCM から Certificate Trust List(CTL; 証明書信頼リスト)をダウンロードします。CTL には、TFTP サーバや Cisco UCM サーバなど、電話が信頼すべきデバイスの ID(証明書)が含まれています。サーバ プロキシをサポートするには、CTL ファイルに、セキュリティ アプライアンスが Cisco UCM 用に作成した証明書が含まれている必要があります。セキュリティ アプライアンスが Cisco IP Phone に代わってコールをプロキシするには、セキュリティ アプライアンス上にある、認証局によって発行され、Cisco UCM が確認可能な証明書(電話のローカル ダイナミック証明書)を提示する必要があります。

TLS プロキシは、Cisco Unified CallManager Release 5.1 以降でサポートされています。ユーザは Cisco UCM のセキュリティ機能について詳しく知っておく必要があります。Cisco UCM のセキュリティの背景と詳細な説明については、次の Cisco Unified CallManager のマニュアルを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/sec_vir/ae/sec504/index.htm

TLS プロキシは、暗号化レイヤに適用されるので、アプリケーション レイヤ プロトコル検査を設定する必要があります。ユーザは適応型セキュリティ アプライアンスの検査機能、特に Skinny 検査と SIP 検査について詳しく知っておく必要があります。

CTL クライアントの概要

Cisco Unified CallManager Release 5.1 以降で提供される CTL クライアント アプリケーションは、CTL ファイルで TLS プロキシ サーバ(ファイアウォール)をサポートします。図 45-2 から図 45-5 は、CTL クライアントでサポートされる TLS プロキシ機能を示しています。

図 45-2 CTL クライアントの TLS プロキシ機能:ファイアウォールの追加

 

図 45-2 のように、TLS プロキシとしてのセキュリティ アプライアンスで構成される CTL エントリを追加できます。

図 45-3 CTL クライアントの TLS プロキシ機能:ASA の IP アドレスまたはドメイン名

 

図 45-3 のように、CTL クライアントにセキュリティ アプライアンスの IP アドレスまたはドメイン名を入力できます。

図 45-4 CTL クライアントの TLS プロキシ機能:ASA の CTL エントリ

 

図 45-4 は、TLS プロキシとしてのセキュリティ アプライアンスの CTL エントリが追加されたことを示しています。CTL エントリは、CTL クライアントがセキュリティ アプライアンスの CTL プロバイダー サービスに接続してプロキシ証明書を取得した後に追加されます。

 

図 45-5 CTL クライアントの TLS プロキシ機能:ASA にインストールされている CTL ファイル

 

セキュリティ アプライアンスでは、CTL ファイルをそのままフラッシュ メモリに保存することはなく、CTL ファイルを解析して適切なトラストポイントをインストールします。図 45-5 は、インストールが正常に完了したことを示しています。

TLS プロキシのライセンス

適応型セキュリティ アプライアンスでサポートされる暗号化音声検査機能の TLS プロキシには、Unified Communications Proxy ライセンスが必要です。

次の表に、Unified Communications Proxy ライセンスの詳細をプラットフォーム別に示します。

 

モデル
ライセンス要件

ASA 5505

基本ライセンスと Security Plus ライセンス:2 セッション1

オプション ライセンス:24 セッション。

ASA 5510

基本ライセンスと Security Plus ライセンス:2 セッション1

オプション ライセンス:24、50、または 100 セッション。

ASA 5520

基本ライセンス:2 セッション1

オプション ライセンス:24、50、100、250、500、750、または 1000 セッション。

ASA 5540

基本ライセンス:2 セッション1

オプション ライセンス:24、50、100、250、500、750、1000、または 2000 セッション。

ASA 5550

基本ライセンス:2 セッション1

オプション ライセンス:24、50、100、250、500、750、1000、2000、または 3000 セッション。

ASA 5580

基本ライセンス:2 セッション1

オプション ライセンス:24、50、100、250、500、750、1000、2000、3000、5000、または 10,000 セッション。2

1.Phone Proxy、Presence Federation Proxy、および Encrypted Voice Inspection アプリケーションでは、それらの接続に TLS プロキシ セッションが使用されます。各 TLS プロキシ セッションは、UC ライセンスの制限に対してカウントされます。これらのアプリケーションは、すべて UC Proxy として包括的にライセンスされるので、混在させたり、組み合せたりできます。アプリケーションによっては、1 つの接続に複数のセッションを使用する場合があります。たとえば、プライマリとバックアップの Cisco Unified Communications Manager で電話機を設定する場合、2 つの TLS プロキシ接続が存在し、そのため 2 つの UC Proxy セッションが使用されます。

:Mobility Advantage Proxy は、ライセンスを必要とせず、その TLS プロキシ セッションは UC ライセンス制限に対してカウントされません。

使用可能な UC セッションの最大数も TLS プロキシ セッション制限に依存します。
- 「K8」で終わるライセンス製品番号の場合(250 ユーザ未満のライセンスなど)、TLS プロキシ セッションは 1000 までに制限されます。
- 「K9」で終わるライセンス製品番号の場合(250 ユーザ以上のライセンスなど)、TLS プロキシ制限は、使用する設定とプラットフォーム モデルに依存します。TLS プロキシの制限を設定するには、tls-proxy maximum-sessions コマンドを使用します。モデルの制限を表示するには、tls-proxy maximum-sessions ? コマンドを入力します。

:K8 および K9 は、ライセンスのエクスポートが制限されているかどうかを示します。K8 は制限なし、K9 は制限ありです。

接続に SRTP 暗号化セッションを使用することもできます。
- K8 ライセンスでは、SRTP セッション数は 250 までに制限されます。
- K9 ライセンスに制限はありません。

:SRTP の制限に対してカウントされるのは、メディアの暗号化または復号化が必要なコールだけです。コールにパススルーが設定されている場合は、両方のコール レッグが SRTP であっても、制限に対するカウントは行われません。

2.10,000 セッション ライセンスの場合、組み合せたセッション数は合計 10,000 までですが、Phone Proxy セッションの最大数は 5000 です。

表 45-1 に、TLS セッションのデフォルト数と最大数の詳細をプラットフォーム別に示します。

 

表 45-1 セキュリティ アプライアンス上での TLS セッションのデフォルト数と最大数

セキュリティ アプライアンス プラットフォーム
TLS セッションのデフォルト数
TLS セッションの最大数

ASA 5505

10

80

ASA 5510

100

200

ASA 5520

300

1200

ASA 5540

1000

4500

ASA 5550

2000

4500

ASA 5580

4000

13,000

ライセンスの詳細については、「機能のライセンスの管理」を参照してください。

暗号化音声検査の TLS プロキシの前提条件

TLS プロキシを設定する前に、次の前提条件を満たす必要があります。

TLS プロキシを設定する前に、セキュリティ アプライアンスの時刻を設定する必要があります。手動で時刻を設定し、時刻を表示するには、clock set コマンドと show clock コマンドを使用します。セキュリティ アプライアンスでは Cisco Unified CallManager クラスタと同じ NTP サーバを使用することをお勧めします。セキュリティ アプライアンスと Cisco Unified CallManager サーバの間で時刻が同期していないと、証明書確認が失敗し、その結果、TLS ハンドシェイクが失敗する場合があります。

Cisco Unified CallManager と相互運用するには、3DES-AES ライセンスが必要です。AES は、Cisco Unified CallManager と Cisco IP Phone で使用されるデフォルトの暗号です。

Cisco UCM に保存されている次の証明書をインポートします。適応型セキュリティ アプライアンスで Phone Proxy を使用するには、これらの証明書が必要です。

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

CAPF 証明書(オプション)

LSC プロビジョニングが必要な場合や、IP 電話の LSC がイネーブルになっている場合は、Cisco UCM から CAPF 証明書をインポートする必要があります。Cisco UCM に CAPF 証明書が複数ある場合は、それらのすべてを適応型セキュリティ アプライアンスにインポートする必要があります。

「Cisco Phone Proxy の設定」を参照してください。たとえば、Phone Proxy で IP 電話の証明書を検証するには、CA 製造業者証明書が必要です。

暗号化音声検査の TLS プロキシの設定

この項は、次の内容で構成されています。

「暗号化音声検査の TLS プロキシの設定のタスク フロー」

「トラストポイントの作成と証明書の生成」

「内部 CA の作成」

「CTL プロバイダー インスタンスの作成」

「TLS プロキシ インスタンスの作成」

「Skinny または SIP 検査での TLS プロキシ インスタンスのイネーブル化」

暗号化音声検査の TLS プロキシの設定のタスク フロー

セキュリティ アプライアンスに TLS プロキシを設定するには、次の手順を実行します。


ステップ 1 (オプション)次のコマンドを使用してセキュリティ アプライアンスがサポートする最大 TLS プロキシ セッション数を設定します。次に例を示します。

hostname(config)# tls-proxy maximum-sessions 1200
 

) tls-proxy maximum-sessions コマンドは、TLS プロキシのような暗号化アプリケーション用に予約されているメモリ サイズを制御します。暗号化メモリは、システムのブート時に予約されます。設定した最大セッション数がその時点で予約されているものよりも大きい場合、コンフィギュレーションを有効にするためにセキュリティ アプライアンスのリブートが必要になることもあります。


ステップ 2 トラストポイントを作成し、暗号化音声検査の TLS プロキシの証明書を生成します。「トラストポイントの作成と証明書の生成」を参照してください。

ステップ 3 Cisco IP Phone 用の LDC に署名する内部 CA を作成します。「内部 CA の作成」を参照してください。

ステップ 4 CTL プロバイダー インスタンスを作成します。「CTL プロバイダー インスタンスの作成」を参照してください。

ステップ 5 TLS プロキシ インスタンスを作成します。「TLS プロキシ インスタンスの作成」を参照してください。

ステップ 6 TLS プロキシを SIP 検査と Skinny 検査でイネーブルにします。「Skinny または SIP 検査での TLS プロキシ インスタンスのイネーブル化」を参照してください。

ステップ 7 ローカル CA 証明書(ldc_server)をエクスポートし、信頼できる証明書として Cisco UCM サーバにインストールします。

a. proxy-ldc-issuer で指定されたトラストポイントがダイナミック証明書の署名者として使用される場合、次のコマンドを使用して証明書をエクスポートします。次に例を示します。

hostname(config)# crypto ca export ldc_server identity-certificate
 

b. 埋め込みローカル CA サーバ LOCAL-CA-SERVER の場合、次のコマンドを使用して証明書をエクスポートします。次に例を示します。

hostname(config)# show crypto ca server certificate
 

出力をファイルに保存し、Cisco UCM に証明書をインポートします。詳細については、Cisco Unified CallManager のマニュアル( http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040848 )を参照してください。

この手順の後、次の Cisco Unified CallManager GUI の Display Certificates 機能を使用して、インストールされた証明書を確認することもできます。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_0/iptp_adm/504/iptpch6.htm#wp1040354

ステップ 8 CTL クライアント アプリケーションを実行してサーバ プロキシ証明書(ccm_proxy)を CTL ファイルに追加し、その CTL ファイルをセキュリティ アプライアンスにインストールします。CTL クライアントの設定方法と使用方法については、次の Cisco Unified CallManager のマニュアルを参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/5_1/nci/p08/secuauth.htm


) セキュリティ アプライアンスと相互運用するためには、Cisco Unified CallManager Release 5.1 と一緒にリリースされた CTL クライアントが必要です。TLS プロキシ サポートの詳細については、「CTL クライアントの概要」を参照してください。



 

トラストポイントの作成と証明書の生成

Cisco UCM プロキシ証明書は、自己署名の場合と、第三者 CA 発行の場合があります。証明書は CTL クライアントにエクスポートされます。

前提条件

Cisco UCM に保存されている、必要な証明書をインポートします。「Cisco UCM の証明書」および 「Cisco UCM からの証明書のインポート」を参照してください。

 

コマンド
目的

ステップ 1

hostname(config)# crypto key generate rsa label key-pair-label modulus size

例:

hostname(config)# crypto key generate rsa label ccm_proxy_key modulus 1024
hostname(config)# crypto key generate rsa label ldc_signer_key modulus 1024
hostname(config)# crypto key generate rsa label phone_common modulus 1024

トラストポイントに使用できる RSA キー ペアを作成します。

キー ペアは、Cisco UP(リモート エンティティ用のプロキシ)を含むローカル ドメインに提示される自己署名した証明書で使用されます。

(注) 役割ごとに異なるキー ペアを作成することをお勧めします。

ステップ 2

hostname(config)# crypto ca trustpoint trustpoint_name

例:

hostname(config)# ! for self-signed CCM proxy certificate
hostname(config)# crypto ca trustpoint ccm_proxy

Cisco UMA サーバのトラストポイントを作成するには、指定したトラストポイントのトラストポイント コンフィギュレーション モードに入ります。

トラストポイントは、CA が発行する証明書に基づいた CA のアイデンティティとデバイスのアイデンティティを表します。

ステップ 3

hostname(config-ca-trustpoint)# enrollment self

自己署名した証明書を生成します。

ステップ 4

hostname(config-ca-trustpoint)# fqdn none

登録時に、Subject Alternative Name 拡張子に Fully Qualified Domain Name(FQDN; 完全修飾ドメイン名)を含めるかどうかを指定します。

ステップ 5

hostname(config-ca-trustpoint)# subject-name X.500_name

例:

hostname(config-ca-trustpoint)# subject-name cn=EJW-SV-1-Proxy

登録時に、指定したサブジェクト DN を証明書に含めます。

Cisco IP Phone では、CTL ファイルを参照して証明書を確認するために、X.509v3 証明書に特定のフィールドが存在している必要があります。そのため、プロキシ証明書トラストポイントの subject-name エントリを設定する必要があります。このサブジェクト名は、CN、OU、O の各フィールドを順に連結して構成する必要があります。CN フィールドは必須で、それ以外はオプションです。


) 連結したフィールド(存在する場合)はそれぞれセミコロンで区切られ、次のいずれかの形式になります。
CN=xxx;OU=yyy;O=zzz
CN=xxx;OU=yyy
CN=xxx;O=zzz
CN=xxx


ステップ 6

hostname(config-ca-trustpoint)# keypair keyname

例:

hostname(config-ca-trustpoint)# keypair ccm_proxy_key

公開キーが認証の対象となるキー ペアを指定します。

ステップ 7

hostname(config-ca-trustpoint)# exit

CA トラストポイント コンフィギュレーション モードを終了します。

ステップ 8

hostname(config)# crypto ca enroll trustpoint

例:

hostname(config)# crypto ca enroll ccm_proxy

CA への登録プロセスを開始し、登録するトラストポイントの名前を指定します。

次の作業

トランスポイントを作成し、証明書を生成したら、Cisco IP Phone の LDC に署名する内部 CA を作成します。「内部 CA の作成」を参照してください。

内部 CA の作成

Cisco IP Phone の LDC に署名する内部ローカル CA を作成します。

このローカル CA は、proxy-ldc-issuer がイネーブルな標準の自己署名トラストポイントとして作成されます。LDC を発行するには、適応型セキュリティ アプライアンス上の埋め込みローカル CA である LOCAL-CA-SERVER を使用できます。

 

コマンド
目的

ステップ 1

hostname(config)# crypto ca trustpoint trustpoint_name

例:

hostname(config)# ! for the internal local LDC issuer
hostname(config)# crypto ca trustpoint ldc_server

LDC 発行元のトラストポイントを作成するには、指定したトラストポイントのトラストポイント コンフィギュレーション モードに入ります。

ステップ 2

hostname(config-ca-trustpoint)# enrollment self

自己署名した証明書を生成します。

ステップ 3

hostname(config-ca-trustpoint)# proxy-ldc-issuer

TLS プロキシのローカル ダイナミック証明書を発行します。 proxy-ldc-issuer コマンドは、暗号トラストポイントに、LDC を発行するためのローカル CA としての役割を付与します。このコマンドには、Crypto ca トラストポイント コンフィギュレーション モードからアクセスできます。

proxy-ldc-issuer コマンドは、TLS プロキシのダイナミック証明書を発行するトラストポイントに、ローカル CA の役割を定義します。このコマンドは、「自己登録」を使用するトラストポイントでのみ設定できます。

ステップ 4

hostname(config-ca-trustpoint)# fqdn fqdn

例:

hostname(config-ca-trustpoint)# fqdn my-ldc-ca.exmaple.com

登録時に、指定した FQDN を証明書の Subject Alternative Name 拡張子に含めます。

ステップ 5

hostname(config-ca-trustpoint)# subject-name X.500_name

例:

hostname(config-ca-trustpoint)# subject-name cn=FW_LDC_SIGNER_172_23_45_200

登録時に、指定したサブジェクト DN を証明書に含めます。

ステップ 6

hostname(config-ca-trustpoint)# keypair keyname

例:

hostname(config-ca-trustpoint)# keypair ldc_signer_key

公開キーが認証の対象となるキー ペアを指定します。

ステップ 7

hostname(config-ca-trustpoint)# exit

CA トラストポイント コンフィギュレーション モードを終了します。

ステップ 8

hostname(config)# crypto ca enroll trustpoint

例:

hostname(config)# crypto ca enroll ldc_server

CA への登録プロセスを開始し、登録するトラストポイントの名前を指定します。

次の作業

内部 CA を作成したら、CTL プロバイダー インスタンスを作成します。「CTL プロバイダー インスタンスの作成」を参照してください。

CTL プロバイダー インスタンスの作成

CTL クライアントからの接続に備えて CTL プロバイダー インスタンスを作成します。

CTL プロバイダーのデフォルトの受信ポート番号は TCP 2444 です。これは、Cisco UCM のデフォルトの CTL ポートです。Cisco UCM クラスタが異なるポートを使用している場合は、service port コマンドを使用してポート番号を変更します。

 

コマンド
目的

ステップ 1

hostname(config)# ctl-provider ctl_name

例:

hostname(config)# ctl-provider my_ctl

証明書信頼リスト プロバイダー インスタンスを作成するには、CTL プロバイダー コンフィギュレーション モードに入ります。

ステップ 2

hostname(config-ctl-provider)# client interface if_name ipv4_addr

例:

hostname(config-ctl-provider)# client interface inside address 172.23.45.1

証明書信頼リスト プロバイダーに接続できるクライアントを指定します。

interface if_name には、接続できるインターフェイスを指定し、 ipv4_addr には、クライアントの IP アドレスを指定します。

複数のコマンドを発行して、複数のクライアントを定義できます。

ステップ 3

hostname(config-ctl-provider)# client username user_name password password encrypted

例:

hostname(config-ctl-provider)# client username CCMAdministrator password XXXXXX encrypted

クライアント認証のユーザ名とパスワードを指定します。

このユーザ名とパスワードは、Cisco UCM の管理用ユーザ名とパスワードと同じでなければなりません。

ステップ 4

hostname(config-ctl-provider)# export certificate trustpoint_name

例:

hostname(config-ctl-provider)# export certificate

クライアントにエクスポートする証明書を指定します。証明書は、CTL クライアントで構成された証明書信頼リスト ファイルに追加されます。

export コマンドのトラストポイント名は、Cisco UCM サーバのプロキシ証明書です。

ステップ 5

hostname(config-ctl-provider)# ctl install

CTL プロバイダーで CTL クライアントから CTL ファイルを解析し、CTL ファイルからのエントリのトラストポイントをインストールできるようにします。このコマンドでインストールされたトラストポイントには、"_internal_CTL_<ctl_name>" のプレフィックスが付いた名前が設定されます。

次の作業

CTL プロバイダー インスタンスを作成したら、TLS プロキシ インスタンスを作成します。「TLS プロキシ インスタンスの作成」を参照してください。

TLS プロキシ インスタンスの作成

暗号化シグナリングを処理する TLS プロキシ インスタンスを作成します。

 

コマンド
目的

ステップ 1

hostname(config)# tls-proxy proxy_name

例:

hostname(config)# tls-proxy my_proxy

TLS プロキシ インスタンスを作成します。

ステップ 2

hostname(config-tlsp)# server trust-point proxy_trustpoint

例:

hostname(config-tlsp)# server trust-point ccm_proxy

TLS ハンドシェイク中に提示するプロキシ トラストポイント証明書を指定します。

server コマンドでは、元の TLS サーバのプロキシ パラメータを設定します。つまり、TLS ハンドシェイク時、または元の TLS クライアントと対話するときに、適応型セキュリティ アプライアンスがサーバとして機能できるようにするパラメータです。

ステップ 3

hostname(config-tlsp)# client ldc issuer ca_tp_name

例:

hostname(config-tlsp)# client ldc issuer ldc_server

ローカル ダイナミック証明書の発行元を設定します。クライアントのダイナミック証明書を発行するローカル CA は、 crypto ca trustpoint コマンドで定義され、トラストポイントでは proxy-ldc-issuer を設定するか、デフォルトのローカル CA サーバ(LOCAL-CA-SERVER)を使用する必要があります。

ldc issuer ca_tp_name には、クライアントのダイナミック証明書を発行するローカル CA トラストポイントを指定します。

ステップ 4

hostname(config-tlsp)# client ldc key-pair key_label

例:

hostname(config-tlsp)# client ldc key-pair phone_common

キー ペアを設定します。

キー ペア値は、crypto key generate コマンドで生成されている必要があります。

ステップ 5

hostname(config-tlsp)# client cipher-suite cipher_suite

例:

hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1

ユーザ定義の暗号スイートを設定します。

クライアント プロキシ(サーバに対して TLS クライアントとして機能するプロキシ)の場合、ユーザ定義の暗号スイートによって、デフォルトの暗号スイート、または ssl encryption コマンドで定義された暗号スイートが置き換えられます。このコマンドでは、2 つの TLS セッション間で異なる暗号を設定できます。CallManager サーバでは、AES 暗号を使用する必要があります。

次の作業

TLS プロキシ インスタンスを作成したら、Skinny および SIP 検査で TLS プロキシ インスタンスをイネーブルにします。「Skinny または SIP 検査での TLS プロキシ インスタンスのイネーブル化」を参照してください。

Skinny または SIP 検査での TLS プロキシ インスタンスのイネーブル化

Skinny または SIP 検査で、Cisco IP Phone および Cisco UCM の TLS プロキシをイネーブルにします。次の手順は、Skinny 検査で TLS プロキシ インスタンスをイネーブルにする方法を示しています。

 

コマンド
目的

ステップ 1

hostname(config)# class-map class_map_name

例:

hostname(config)# class-map sec_skinny

検査するセキュア Skinny クラスのトラフィックを設定します。

class_map_name には、Skinny クラスマップの名前を指定します。

ステップ 2

hostname(config-cmap)# match port tcp eq 2443

セキュア Skinny 検査のアクションを適用する TCP ポート 2443 に照合します。

ステップ 3

hostname(config-cmap)# exit

ステップ 4

hostname(config)# policy-map type inspect skinny policy_map_name

例:

hostname(config)# policy-map type inspect skinny skinny_inspect

Skinny 検査アプリケーション トラフィックの特別なアクションを定義します。

ステップ 5

hostname(config-pmap)# parameters
hostname(config-pmap-p)# ! Skinny inspection parameters

Skinny 検査のパラメータを指定します。パラメータは、検査エンジンの動作に影響します。

パラメータ コンフィギュレーション モードで使用できるコマンドは、アプリケーションによって異なります。

ステップ 6

hostname(config-pmap-p)# exit

ポリシーマップ コンフィギュレーション モードを終了します。

ステップ 7

hostname(config)# policy-map name

例:

hostname(config)# policy-map global_policy

ポリシーマップを設定し、アクションをトラフィック クラスに関連付けます。

ステップ 8

hostname(config-pmap)# class inspection_default

デフォルトのクラスマップを指定します。

コンフィギュレーションには、デフォルト グローバル ポリシーで適応型セキュリティ アプライアンスが使用するデフォルトのレイヤ 3/4 クラスマップが含まれます。これは inspection_default と呼ばれ、デフォルト検査トラフィックと一致します。

ステップ 9

hostname(config-pmap-c)# inspect skinny skinny_map

例:

hostname(config-pmap-c)# inspect skinny skinny_inspect

SCCP(Skinny)アプリケーション検査をイネーブルにします。

ステップ 10

hostname(config-pmap)# class classmap_name

例:

hostname(config-pmap)# class sec_skinny

アクションをクラスマップ トラフィックに割り当てることができるポリシーマップにクラスマップを割り当てます。

ステップ 11

hostname(config-pmap-c)# inspect skinny skinny_map tls-proxy proxy_name

例:

hostname(config-pmap-c)# inspect skinny skinny_inspect tls-proxy my_proxy

指定された検査セッションで TLS プロキシをイネーブルにします。

ステップ 12

hostname(config-pmap-c)# exit

ポリシーマップ コンフィギュレーション モードを終了します。

ステップ 13

hostname(config)# service-policy policymap_name global

例:

hostname(config)# service-policy global_policy global

すべてのインターフェイスでサービス ポリシーをイネーブルにします。

 

TLS プロキシのモニタリング

TLS プロキシ接続の問題をデバッグするために、SSL の syslog とともに TLS プロキシのデバッグ フラグをイネーブルにできます。たとえば、TLS プロキシ関連のデバッグと syslog 出力だけをイネーブルにするには、次のコマンドを使用します。

hostname(config)# debug inspect tls-proxy events
hostname(config)# debug inspect tls-proxy errors
hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging list loglist message 711001
hostname(config)# logging list loglist message 725001-725014
hostname(config)# logging list loglist message 717001-717038
hostname(config)# logging buffer-size 1000000
hostname(config)# logging buffered loglist
hostname(config)# logging debug-trace
 

次の出力例では、SIP 電話用に TLS プロキシ セッションのセットアップが完了したことが示されています。

hostname(config)# show log
 
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with client outside:133.9.0.218/49159 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Set up proxy for Client outside:133.9.0.218/49159 <-> Server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Using trust point 'local_ccm' with the Client, RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Waiting for SSL handshake from Client outside:133.9.0.218/49159.
Apr 17 2007 23:13:47: %ASA-7-725010: Device supports the following 4 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : RC4-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[3] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[4] : DES-CBC3-SHA
Apr 17 2007 23:13:47: %ASA-7-725008: SSL client outside:133.9.0.218/49159 proposes the following 2 cipher(s).
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-7-725014: SSL lib error.Function: SSL23_READ Reason: ssl handshake failure
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain.serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-7-717030: Found a suitable trustpoint _internal_ejw-sv-2_cn=CAPF-08a91c01 to validate certificate.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated.serial number: 01, subject name: cn=SEP0017593F50A8.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with client outside:133.9.0.218/49159
Apr 17 2007 23:13:47: %ASA-6-725001: Starting SSL handshake with server inside:195.168.2.201/5061 for TLSv1 session.
Apr 17 2007 23:13:47: %ASA-7-725009: Device proposes the following 2 cipher(s) to server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[1] : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-725011: Cipher[2] : AES256-SHA
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Generating LDC for client 'cn=SEP0017593F50A8', key-pair 'phone_common', issuer 'LOCAL-CA-SERVER', RT proxy cbae1538
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Started SSL handshake with Server
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Client
Apr 17 2007 23:13:47: %ASA-7-725013: SSL Server inside:195.168.2.201/5061 choose cipher : AES128-SHA
Apr 17 2007 23:13:47: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Apr 17 2007 23:13:47: %ASA-7-717029: Identified client certificate within certificate chain.serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717022: Certificate was successfully validated.Certificate is resident and trusted, serial number: 76022D3D9314743A, subject name: cn=EJW-SV-2.inside.com.
Apr 17 2007 23:13:47: %ASA-6-717028: Certificate chain was successfully validated with revocation status check.
Apr 17 2007 23:13:47: %ASA-6-725002: Device completed SSL handshake with server inside:195.168.2.201/5061
Apr 17 2007 23:13:47: %ASA-7-711001: TLSP cbad5120: Data channel ready for the Server
 

アクティブな TLS プロキシ セッションをチェックするには、show tls-proxy コマンドにさまざまなオプションを指定して使用します。以下にいくつかの出力例を示します。

hostname(config-tlsp)# show tls-proxy
Maximum number of sessions: 1200
 
TLS-Proxy 'sip_proxy': ref_cnt 1, seq# 3
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: LOCAL-CA-SERVER
Local dynamic certificate key-pair: phone_common
Cipher suite: aes128-sha1 aes256-sha1
Run-time proxies:
Proxy 0xcbae1538: Class-map: sip_ssl, Inspect: sip
Active sess 1, most sess 3, byte 3456043
 
TLS-Proxy 'proxy': ref_cnt 1, seq# 1
Server proxy:
Trust-point: local_ccm
Client proxy:
Local dynamic certificate issuer: ldc_signer
Local dynamic certificate key-pair: phone_common
Cipher-suite: <unconfigured>
Run-time proxies:
Proxy 0xcbadf720: Class-map: skinny_ssl, Inspect: skinny
Active sess 1, most sess 1, byte 42916
 
hostname(config-tlsp)# show tls-proxy session count
2 in use, 4 most used
 
hostname(config-tlsp)# show tls-proxy session
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
 
hostname(config-tlsp)# show tls-proxy session detail
2 in use, 4 most used
outside 133.9.0.211:50437 inside 195.168.2.200:2443 P:0xcbadf720(proxy) S:0xcbc48a08 byte 42940
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e498 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e478 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 29
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=TLS-Proxy-Signer
Subject Name:
cn=SEP0002B9EB0AAD
o=Cisco Systems Inc
c=US
Validity Date:
start date: 09:25:41 PDT Apr 16 2007
end date: 09:25:41 PDT Apr 15 2008
Associated Trustpoints:
 
outside 133.9.0.218:49159 inside 195.168.2.201:5061 P:0xcbae1538(sip_proxy) S:0xcbad5120 byte 8786
Client: State SSLOK Cipher AES128-SHA Ch 0xca55e398 TxQSize 0 LastTxLeft 0 Flags 0x1
Server: State SSLOK Cipher AES128-SHA Ch 0xca55e378 TxQSize 0 LastTxLeft 0 Flags 0x9
Local Dynamic Certificate
Status: Available
Certificate Serial Number: 2b
Certificate Usage: General Purpose
Public Key Type: RSA (1024 bits)
Issuer Name:
cn=F1-ASA.default.domain.invalid
Subject Name:
cn=SEP0017593F50A8
Validity Date:
start date: 23:13:47 PDT Apr 16 2007
end date: 23:13:47 PDT Apr 15 2008
Associated Trustpoints:
 

暗号化音声検査の TLS プロキシの機能履歴

表 45-2 に、この機能のリリース履歴の一覧を示します。

 

表 45-2 Cisco Phone Proxy の機能履歴

機能名
リリース
機能情報

TLS プロキシ

8.0(2)

TLS プロキシ機能が導入されました。