Cisco PIX Firewall/VPN コンフィギュレーション ガイド
アプリケーション検査(フィックス アップ)の設定
アプリケーション検査(フィックスアップ)の設定
発行日;2012/02/04 | 英語版ドキュメント(2009/02/14 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

アプリケーション検査(フィックスアップ)の設定

アプリケーション検査の動作

fixup コマンドの使用

基本的なインターネット プロトコル

DNS

FTP

HTTP

ICMP

IPSec

PPTP

SMTP

アプリケーション検査

設定例

Voice Over IP(VoIP)

CTIQBE

CU-SeeMe

H.323

概要

1 コール シグナリング接続における複数コール

接続ステータスの表示

技術的な背景説明

MGCP

概要

MGCP アプリケーション検査のイネーブル化

複数の呼エージェントおよびゲートウェイのコンフィギュレーション

MGCP 情報の表示

SCCP

概要

SCCP での PAT の使用方法

高セキュリティ インターフェイス上での Cisco CallManager と SCCP の併用

フラグメント化された SCCP パケットで発生する問題

SCCP 情報の表示

SIP

概要

外部電話によって内部電話を保留状態にする

SIP 情報の表示

技術的な背景説明

マルチメディア アプリケーション

Netshow

UDP ストリーム

TCP ストリーム

リアルタイム ストリーミング プロトコル(RTSP)

VDO LIVE

データベースとディレクトリのサポート

ILS と LDAP

ネットワーク ファイル システムと Sun RPC

Oracle SQL*Net (V1/V2)

管理プロトコル

インターネット制御メッセージ プロトコル(ICMP)

Remote Shell

X Display Manager Control Protocol(XDMCP)

アプリケーション検査(フィックスアップ)の設定

この章では、アプリケーション検査を設定して使用する方法について説明します。アプリケーション検査は、 fixup コマンドを使用して設定するため、「フィックスアップ」とも呼ばれます。次の事項について説明します。

「アプリケーション検査の動作」

「fixup コマンドの使用」

「基本的なインターネット プロトコル」

「Voice Over IP(VoIP)」

「マルチメディア アプリケーション」

「データベースとディレクトリのサポート」

「管理プロトコル」

アプリケーション検査の動作

アプリケーションおよびサービスの安全な使用は、PIX Firewall がステートフル アプリケーション検査用に使用するアダプティブ セキュリティ アルゴリズム(ASA)によって保証されます。アプリケーションの中には、PIX Firewall アプリケーション検査機能による特別な処理が必要なものがあります。このようなアプリケーションには、ユーザ データ パケット内に IP アドレッシング情報を埋め込んでいるものや、ダイナミックに割り当てられるポート上で二次チャネルを開くものなどがあります。

アプリケーション検査機能は、埋め込みアドレッシング情報の位置を特定するために、NAT と連携して動作します。この連携により、NAT ではデータ パケット内に埋め込まれたアドレスを変換すること、またチェックサムや変換から影響を受ける別のフィールドを更新することが可能になります。

アプリケーション検査機能はまた、セッションを監視し、二次チャネル用のポート番号を決定します。多くのプロトコルは、パフォーマンスを向上させるために、二次 TCP ポートまたは UDP ポートを開きます。予約済みポート上の初期セッションは、ダイナミックに割り当てられたポート番号をネゴシエートするために使用されます。アプリケーション検査機能は、この初期セッションを監視し、ダイナミックに割り当てられたポートを特定し、所定のセッションの間、それらのポート上でのデータ交換を許可します。

ASA は基本動作において、次の 3 つのデータベースを使用します(図 5-1を参照)。

アクセス コントロール リスト(ACL):特定のネットワーク、ホスト、およびサービス(TCP/UDP ポート番号)に基づく接続の認証および許可に使用されます。

検査:定義済みで固定のアプリケーション検査機能がセットで格納されています。

接続(XLATE テーブルと CONN テーブル):確立された各接続について、状態などの情報が保持されています。この情報は、確立されたセッション内におけるトラフィック転送を効率的に行うために、ASA とカットスルー プロキシによって使用されます。

図 5-1 ASA の基本動作

 

図 5-1の実行順の番号に従って説明します。

1. TCP SYN パケットが、新しい接続を確立するために PIX Firewall に到着します。

2. PIX Firewall は、ACL データベースをチェックして、その接続を許可するかどうかを判別します。

3. PIX Firewall は、接続データベース(XLATE テーブルと CONN テーブル)内に新しいエントリを作成します。

4. PIX Firewall は、検査データベースをチェックして、接続に対してアプリケーション レベルの検査が必要かどうかを判別します。

5. パケットに対してアプリケーション検査機能の処理が完了したら、PIX Firewall は宛先システムにパケットを転送します。

6. 宛先システムは、初期要求に応答します。

7. PIX Firewall は、応答パケットを受信し、接続データベースで接続をルックアップした後、確立されたセッションに属しているパケットを転送します。

PIX Firewall のデフォルトのコンフィギュレーションには、アプリケーション検査エントリのセットが含まれています。このエントリは、サポートされているプロトコルを特定の TCP ポート番号または UDP ポート番号に関連付け、特殊な処理が必要な場合はそれを指定します。アプリケーション検査機能は、特定のアプリケーションに対しては、アプリケーションから課せられる制限のため、NAT または PAT のサポートを行いません。 アプリケーションの中には、そのポート割り当てを変更できるものもあれば、変更できない固定ポートが割り当てられているものもあります。 表 5-1 に、PIX Firewall Version 6.2 以降で提供されているアプリケーション検査機能を要約します。

 

表 5-1 アプリケーション検査機能

アプリケーション
PAT の
有無
NAT (1 対 1)の有無
設定の
有無
デフォルト ポート
標準
制限事項/コメント

CTIQBE

あり

あり

あり

TCP/2748

--

PIX Firewall Version 6.3 で導入

CU-SeeMe

なし

なし

なし

UDP/7648

--

なし

DNS1

あり

あり

なし

UDP/53

RFC 1123

NAT のみ転送。 PTR レコードの変更なし

FTP

あり

あり

あり

TCP/21

RFC 1123

なし

H.323

PIX Firewall Version 6.2
以降

あり

あり

TCP/1720 UDP/1718
UDP(RAS)1718 ~ 1719

ITU-T H.323、H.245、H225.0、Q.931、Q.932

なし。 Version 3 および 4 に対するサポートは、PIX Firewall Version 6.3 で導入されたもの。 セグメント化されたメッセージはサポートしない。

HTTP

あり

あり

あり

TCP/80

RFC 2616

ActiveX と Java のストライプ化時の MTU 制限に注意2

ICMP

あり

あり

なし

--

--

なし

ILS (LDAP)

あり

あり

あり

--

--

PIX Firewall Version 6.2 で導入

MGCP

なし

なし

あり

2427, 2727

RFC2705bis-05

PIX Firewall Version 6.3 で導入

NBDS / UDP

あり

あり

なし

UDP/138

--

なし

NBNS / UDP

なし

なし

なし

UDP/137

--

WINS はサポートしない

NetBIOS over IP3

なし

なし

なし

--

--

なし

PPTP

あり

あり

あり

1723

RFC2637

PIX Firewall Version 6.3 で導入

RSH

あり

あり

あり

TCP/514

Berkeley UNIX

なし

RTSP

なし

なし

あり

TCP/554

RFC 2326, RFC 2327, RFC 1889

HTTP クローキングは処理しない

SIP

PIX Firewall Version 6.2
以降

あり

あり

TCP/5060
UDP/5060

RFC 2543

なし

SKINNY
(SCCP)

PIX Firewall Version 6.3

あり

あり

TCP/2000

--

設定をアップロード済むの TFTP は処理しない

SMTP

あり

あり

あり

TCP/25

RFC 821, 1123

なし

SQL*Net

あり

あり

あり

TCP/1521 (v.1)

--

V.1 および v.2.

Sun RPC

なし

なし

なし

UDP/111 TCP/111

--

ペイロードは NAT 処理しない

VDO LIVE

なし

あり

なし

TCP/7000

--

なし

Windows Media

なし

あり

なし

TCP/1755

--

HTTP、TCP、UDP による Netshow のストリーム送信可能

XDCMP

なし

なし

なし

UDP/117

--

なし

1.NAT サポートは、WINS 経由のネーム解決では使用できません。

2.MTU が小さすぎて Java タグまたは ActiveX タグを 1 つのパケットに納められない場合は、ストライプ化は行われません。

3.NetBIOS は、NBNS UDP ポート 137 および NBDS UDP ポート 138 に対してパケットの NAT 処理を実行することでサポートされます。

fixup コマンドの使用

fixup コマンドは、デフォルトのポート割り当てを変更する場合や、次に挙げるプロトコルとアプリケーションに対してアプリケーション検査をイネーブルまたはディセーブルにする場合に使用できます。

CTIQBE(デフォルト設定ではディセーブル)

ESP-IKE(デフォルト設定ではディセーブル)

FTP

H.323

HTTP

ILS

MGCP (デフォルト設定ではディセーブル)

PPTP (デフォルト設定ではディセーブル)

RSH

RTSP

SIP

SKINNY (SCCP)

SMTP

SQL*Net

fixup コマンドの基本的な構文は次のとおりです。

[no] fixup protocol [protocol] [port]

デフォルトのポート割り当てを変更するには、プロトコルと割り当てる新しいポート番号を指定します。アプリケーション検査エントリをデフォルトにリセットするには、 no fixup protocol コマンドを使用します。


) アプリケーション検査のディセーブル化や修正により影響を受けるのは、fixup コマンドの処理後に開始された接続に限られます。特定のポートやアプリケーションに対してアプリケーション検査をディセーブルにすることで、既存の接続に影響を与えることはありません。変更内容をただちに有効にするには、clear xlate コマンドを入力し、既存のアプリケーション検査エントリをすべて削除します。


次に、設定可能な各アプリケーションに対する fixup コマンドの詳細構文を示します。

fixup protocol ctiqbe 2748 | esp-ike | ftp [strict] [port] | http [port[-port]]
| h323 h225 | ras [port[-port]] | ils [port[-port]] | mgcp [port[-port]| pptp 1723 | rsh [514] | rtsp [port] | sip udp [port] | skinny [port] | smtp [port[-port]] | sqlnet [port[-port]]
 

明示的(設定可能)な fixup protocol 設定は、show fixup コマンドを使用して表示できます。設定可能なプロトコルのデフォルト値は、次のとおりです。

pix# show fixup
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
 

show fixup protocol protocol コマンドを使用すると、プロトコルの設定内容が個別に表示されます。

次に、フィックスアップ設定を管理する関連コマンドを示します。

show conn state :指定プロトコルの接続状態を表示します

show timeout :指定プロトコルのタイムアウト値を表示します

追加した fixup コマンドをコンフィギュレーションから削除するには、clear fixup コマンドを使用します。このコマンドを使用しても、デフォルトの fixup protocol コマンドは削除されません。

no fixup コマンドを使用すると、コンフィギュレーションからプロトコルのすべてのフィックスアップが削除され、フィックスアップがディセーブルになります。フィックスアップをすべて削除すると、コマンドの no fixup フォームまたはデフォルト ポートがコンフィギュレーションに保存されます。

アプリケーションの中には、複数のポート割り当てを定義できるものもあります。この機能は、同一サービスの複数のインスタンスが別個のポート上で実行される場合に役立ちます。

次に、別々にコマンドを入力して、FTP に対して複数のポートを定義する例を示します。

fixup protocol ftp 2100
fixup protocol ftp 4254
fixup protocol ftp 9090
 

上記のコマンドでは、標準の FTP ポート割り当て(21)は変更されません。すべてのコマンドを入力すると、PIX Firewall は、ポート 21、2100、4254、および 9090 上の FTP トラフィックを受信します。

プロトコルの中には、範囲指定によるポート割り当てが可能なものもあります。これは、port[-port] というコマンド構文で示されます。たとえば、次のコマンドでは、1500 ~ 2000 のポート範囲が SQL*Net に割り当てられます。

fixup protocol sqlnet 1500-2000
 

) 複数ポートの割り当てが許可されないプロトコルに新しいポート割り当てを入力すると、入力した値によってデフォルト値が無効になります。


基本的なインターネット プロトコル

ここでは、PIX Firewall による最も一般的なインターネット プロトコルのサポート、および問題を解決するための fixup コマンドの使用方法について説明します。次の項目について説明します。

「DNS」

「FTP」

「HTTP」

「ICMP」

「IPSec」

「PPTP」

「SMTP」

DNS

Domain Name System (DNS; ドメイン ネーム システム)に対するポート割り当ては変更できません。DNS ではアプリケーション検査が必要であるため、DNS クエリーは、アクティビティ タイムアウトに基づく一般的な UPD 処理の対象に含まれません。その代わり、DNS クエリーと応答に関連する UDP 接続は、DNS クエリーに対する応答が受信されるとただちに切断されます。この機能を DNS 保護と呼びます。

DNS 検査は、次の 2 つのタスクを実行します。

メッセージ交換を監視し、DNS 応答の ID が、DNS クエリーの ID と一致することを確認します。

alias コマンドに代わって、DNS A レコードを変換します。PIX Firewall Version 6.2 以降における DNS 検査では、スタティック NAT と ダイナミック NAT および外部 NAT もサポートされるため、 alias コマンドの使用が不要になります。

前方ルックアップだけが NAT 処理されるため、PTR レコードはそのまま維持されます。DNS ゾーン転送に対する Intrusion Detection System (IDS; 侵入検知システム)モジュールで、アラームを作動させることも可能です。


) PIX Firewall では、UDP ポート 53 に送信される DNS パケットのうち、サイズが 512 バイトより大きなパケットを廃棄します。


PIX Firewall Version 6.2 からは、内部(高セキュリティ)インターフェイスまたは外部(低セキュリティ)インターフェイスの両方から発信された DNS メッセージについて、NAT および PAT が完全にサポートされました。これは、内部のネットワーク上のクライアントが、外部インターフェイス上の DNS サーバから送信される内部アドレスの DNS 解決を行う場合に、DNS A レコードが正しく変換されることを示します。

たとえば、図 5-2では、内部ネットワーク上のクライアントが、そのホスト名の server.example.com を使用して、サーバ 192.168.100.1 に HTTP 要求を発行しています。 このサーバのアドレスは、PAT を介して、1 つの ISP 割り当てアドレス 209.165.200.5 にマッピングされます。DNS サーバは、ISP ネットワーク上にあります。

図 5-2 DNS メッセージの NAT/PAT

 

DNS サーバに対して要求が出されると、PIX Firewall は、IP ヘッダー内のルーティング不可能な発信元アドレスを変換して、その外部インターフェイス上の ISP ネットワークに要求を転送します。DNS A レコードが返送されると、宛先アドレスだけでなく、Web サーバの埋め込み IP アドレスにもアドレス変換を適用します。この埋め込み IP アドレスは、DNS 応答パケットのユーザ データ部分に含まれています。結果として、内部ネットワーク上の Web クライアントは、内部ネットワーク上の Web サーバとの接続に必要なアドレスを取得します。

PIX Firewall Version 6.2 以降における、DNS に対する透過的なサポートとは、DNS 要求を行うクライアントが DMZ (つまり、安全性のより低い)ネットワーク上にあり、DNS サーバが内部(またはその他のより安全性の高い)インターフェイス上にある場合にも、同じプロセスが機能することを意味します。

FTP

fixup コマンドを使用して、File Transfer Protocol (FTP; ファイル転送プロトコル)に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

[no] fixup protocol ftp [strict] [port]
 

port パラメータでは、PIX Firewall が FTP トラフィックを受信するポートを指定します。

strict オプションで、Web ブラウザに組み込まれたコマンドが FTP 要求によって送信されることを防止できます。 ftp コマンドに対しては、新しいコマンドが次に送信される前に、それぞれ肯定応答が返される必要があります。組み込みコマンドを送信する接続は廃棄されます。strict オプションでは、FTP サーバによる 227 コマンドの生成、および FTP クライアントによる PORT コマンドの生成だけが許可されます。227 コマンドと PORT コマンドは、エラー文字列に表示されないようにチェックされます。

no fixup protocol ftp コマンドでFTPの変更をディセーブルにした場合、発信ユーザは受動モードでしか接続を開始できず、すべての着信 FTP はディセーブルになります。


strict オプションを使用すると、RFC 基準に準拠しない FTP クライアントとの接続が切断される場合があります。


FTP アプリケーション検査機能は、FTP セッションを検査し、次の 4 つのタスクを実行します。

ダイナミックな二次的データ接続の準備

ftp コマンド応答シーケンスの追跡

監査証跡の生成

埋め込み IP アドレスの NAT 処理

FTP アプリケーション検査によって、FTP データ転送用に二次チャネルが用意されます。二次チャネルは、ファイル アップロード、ファイル ダウンロード、またはディレクトリ リスティング イベントへの応答で割り当てられ、事前にネゴシエートしておく必要があります。ポートは、PORT コマンドまたは PASV コマンドを使用してネゴシエートされます。

strict オプションがイネーブルになっている場合、各 ftp および応答シーケンスが追跡され、次の異常なアクティビティがチェックされます。

切り捨てされたコマンド:PORT コマンドおよび PASV 応答コマンドのカンマの数が 5 であるかどうかが確認されます。カンマの数が 5 でない場合は、PORT コマンドが切り捨てられているとみなされ、TCP 接続は閉じられます。

不正なコマンド:RFC の要求通りに、<CR><LF> 文字で終了しているかを調べるため、 ftp コマンドが確認されます。終了していない場合は、接続が閉じられます。

RETR コマンドと STOR コマンドのサイズ:これらが、固定の定数と比較チェックされます。サイズが定数より大きい場合は、エラー メッセージがロギングされ、接続が閉じられます。

コマンド スプーフィング:PORT コマンドは、常にクライアントから送信されます。PORT コマンドがサーバから送信される場合、TCP 接続は拒否されます。

応答スプーフィング:PASV 応答コマンド(227)は、常にサーバから送信されます。PASV 応答コマンドがクライアントから送信される場合、TCP 接続は拒否されます。これにより、ユーザが「227 xxxxx a1, a2, a3, a4, p1, p2.」を実行する場合のセキュリティ ホールが予防できます。

TCP ストリーム編集。

無効ポート ネゴシエーション:ネゴシエートされたダイナミック ポート値が、1024 未満であるかどうかが調べられます。 1 ~ 1024 の範囲のポート番号は、予約済み接続用に指定されているため、ネゴシエートされたポートがこの範囲内であった場合、TCP 接続は解放されます。

コマンド パイプライン: PORT コマンドと PASV 応答コマンド内のポート番号の後に続く文字数が、定数の 8 と比べられます。 8 より大きい場合は、TCP 接続が閉じられます。

FTP アプリケーション検査では、次のログ メッセージが生成されます。

An Audit record 302002 is generated for each file that is retrieved or uploaded.

The ftp command is checked to see if it is RETR or STOR and the retrieve and store commands are logged.

The username is obtained by looking up a table providing the IP address.

The username, source IP address, destination IP address, NAT address, and the file operation are logged.

Audit record 201005 is generated if the secondary dynamic channel preparation failed due to memory shortage.

NAT と連携することにより、FTP アプリケーション検査では、アプリケーション ペイロード内の IP アドレスが変換されます。これは、RFC 959 に詳細に記述されています。

HTTP

fixup コマンドを使用して、Hypertext Transfer Protocol (HTTP; ハイパーテキスト転送プロトコル)に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

fixup protocol http [port[-port]
 

デフォルト ポートの割り当てを 80 以外に変更するには、 port オプションを使用します。 一定範囲のポート番号に HTTP アプリケーション検査を適用するには、- port オプションを使用します。


) no fixup protocol http コマンド文は、filter url コマンドをディセーブルにします。


HTTP 検査は、次の複数の機能を実行します。

GET メッセージの URL ロギング

N2H2 または Websense による URL スクリーニング

Java と ActiveX のフィルタリング

後の 2 つの機能については、「ネットワーク アクセスとネットワーク使用の制御」「発信接続のフィルタリング」で説明されています。

ICMP

PIX Firewall Version 6.3 からは Internet Control Message Protocol (ICMP; インターネット制御メッセージ プロトコル)エラー メッセージの NAT がサポートされました。 ICMP の NAT はデフォルト設定でディセーブルになっています。 この機能がイネーブルの場合、PIX Firewall はスタティック/NAT コンフィギュレーションに基づいて ICMP エラー メッセージを送信する中間ホップの xlate を作成します。 PIX Firewall は、変換された IP アドレスでパケットを上書きします。

この機能をイネーブルにするには、次のコマンドを使用します。

[no] fixup protocol icmp error
 

ディセーブルになると(Version 6.3 より前のバージョンと同様に)、PIX Firewall は ICMP エラー メッセージを生成する中間ノードの xlate を作成しません。 内部ホストと PIX Firewall との間の中間ノードによって生成される ICMP エラー メッセージは、追加の NAT リソースをいっさい消費せずに、外部のホストに到達します。 これは、外部のホストが traceroute コマンドを使用して PIX Firewall 内部の宛先に対しホップをトレースする場合に適していません。 PIX Firewall で中間ホップを NAT 処理しない場合、すべての中間ホップは変換された宛先 IP アドレスとともに表示されます。

IPSec

PIX Firewall Version 6.3 では Encapsulating Security Payload (ESP)のアプリケーション検査と、NAT での IPSec の使用について、サポートが向上しました。

ESP はデータ機密性、データ整合性、保護サービス、およびオプションのデータ発信者認証とリプレイ攻撃防止サービスを提供する IPSec プロトコルです。ESP では保護対象のデータをカプセル化します。

ただし、ESP パケットでは使用されているポートを特定しないため、ポート 0 (ゼロ)を割り当てることによって PAT が実行されます。 1 度にサポートされる ESP トンネルは 1 つだけです。 また、PIX Firewall のこの機能がイネーブルになっている場合は、その他の IPSec ピアとの関係から VPN トンネルを終端できません。

ESP トラフィックのアプリケーション検査は、デフォルト設定でディセーブルになっています。この機能をイネーブルにするには、次のコマンドを入力します。

fixup protocol esp-ike
 

この機能がイネーブルの場合、PIX Firewall では IKE ソース ポートを保存します。 次の処理についてはサポートされていません。

ESP トンネルのシリアル化

SPI マッチング

ESP 接続別 SPI の記録

PPTP

Point-to-Point Tunneling Protocol (PPTP; ポイントツーポイント トンネリング プロトコル)は PPP トラフィックのトンネリング用プロトコルです。 1 つの PPTP セッションは、1 つの TCP チャネルと通常 2 つの PPTP GRE トンネルで構成されます。 TCP チャネルは PPTP GRE トンネルのネゴシエートおよび管理に使用される制御チャネルです。 GRE トンネルは 2 ホスト間の PPP セッションを伝送します。

RFC 2637 で定義されるように、PPTP プロトコルは主にモデム バンク PPTP Access Concentrator (PAC; PPTP アクセス コンセントレータ)からヘッドエンド PPTP Network Server (PNS; PPTP ネットワーク サーバ)に対して開始された PPP セッションのトンネリングに使用されます。 このように使用される場合、PAC はリモート クライアントで PNS はサーバです。

ただし、Windows により VPN に使用される場合はインタラクションが逆になります。 その場合の PNS は、中央ネットワークへアクセスするためにヘッドエンド PAC への接続を開始する単一ユーザのリモート PC です。

PPTP アプリケーション検査はデフォルト設定でディセーブルになっています。 PPTP をイネーブルにするには fixup コマンドを使用します。コマンドの構文は次のとおりです。

[no] fixup protocol pptp 1723
 

イネーブルの場合、PPTP アプリケーション検査では PPTP プロトコル パケットを検査して PPTP トラフィックの許可に必要な GRE 接続および xlate をダイナミックに作成します。 RFC 2637 で定義されるように、Version 1 だけがサポートされています。

PAT は PPTP TCP 制御チャネルを介してネゴシエートされる場合、修正バージョンの GRE (RFC 2637)だけを対象に実行されます。 未修正バージョンの GRE (RFC 1701、RFC 1702)については PAT は実行されません。

PPTP 接続で使用される xlate を表示するには、次のコマンドを入力します。

show xlate
 

このコマンドには GRE 接続の出力が含まれます。 PAT タイプを表示するには、detail オプションを使用します。 GRE xlate ごとに文字列が表示されます。次に例を示します。

GRE PAT from inside:10.2.1.51/1723 to outside:192.150.49.100/0 flags ri
 

GRE 接続のステータスを表示するには、次のコマンドのいずれかを入力します。

show conn fport 1723
show conn lport 1723
 

show local-host コマンドを使用すれば、GRE xlate と GRE 接続ステータスの両方を表示できます。

SMTP

ここでは、アプリケーション検査と SMTP とを連携させた場合の動作について説明します。次の項目について説明します。

「アプリケーション検査」

「設定例」

fixup コマンドを使用して、SMTP に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

fixup protocol smtp [port[-port]]
 

fixup protocol smtp コマンドによって、Mail Guard 機能がイネーブルになります。この機能により、メール サーバは、RFC 821 セクション 4.5.1 に定義されている 7 つの最小限のコマンド(HELO、MAIL、RCPT、DATA、RSET、NOOP、QUIT)の受信に制限されます。その他のコマンドはすべて拒否されます。

Microsoft Exchange サーバでは EHLO など拡張 SMTP コマンドが使用されており、厳密には RFC 821 セクション 4.5.1 に準拠していません。PIX Firewall は、このようなコマンドをすべて NOOP コマンドに変換します。これによって、RFC の規定に従い、最小限の SMTP コマンドだけを使用するように SMTP サーバが強制的に制限されます。このため、Microsoft Outlook クライアントや Exchange サーバの機能に関しては、パケットが PIX Firewall を通過するときに予測不能な動作をする場合があります。

デフォルト ポートの割り当てを 25 以外に変更するには、 port オプションを使用します。 一定範囲のポート番号に SMTP アプリケーション検査を適用するには、- port オプションを使用します。

現在、Version 5.1 以降のバージョンでは、fixup protocol smtp コマンドにより、サーバ SMTP バナーの文字が「2」、「0」、「0」を除いてアスタリスクに変更されます。復帰(CR)、および改行(LF)は無視されます。PIX Firewall Version 4.4 では、SMTP バナーの文字がすべてアスタリスクに変換されます。

アプリケーション検査

SMTP サーバは、数値応答コード、およびオプションの可読文字列でクライアント要求に応答します。SMTP アプリケーション検査は、ユーザが使用できるコマンドとサーバが返送するメッセージを制御し、その数を減らします。SMTP 検査は、次の 3 つの主要なタスクを実行します。

SMTP 要求を、7 つの最小限のコマンド(HELO、MAIL、RCPT、DATA、RSET、NOOP、QUIT)に制限します。

SMTP コマンド応答シーケンスを監視します。

監査証跡の生成:メール アドレス内に埋め込まれている無効な文字が交換されたときに、監査レコード 108002 が生成されます。詳細については、RFC 821 を参照してください。

SMTP 検査では、次の異常なシグニチャをチェックするため、コマンド応答シーケンスが監視されます。

切り捨てられたコマンド。

不正なコマンド終端(<CR><LR> で終了していない)。

MAIL コマンドと RCPT コマンドでは、メールの送信者と受信者が指定されます。異常な文字がないか、メール アドレスがスキャンされます。パイプ(|)が削除(空白スペースに変更)され、「<」 および「>」については、メール アドレスの定義に使用される場合だけ許可されます(「<」の後には、必ず「>」が使用されている必要があります)。

SMTP サーバによる予期しない移行。

未知のコマンドに対しては、PIX Firewall はパケット内のすべての文字を X に変更します。 この場合、サーバがクライアントに対してエラー コードを生成します。パケット内が変更されているため、TCP チェックサムは、再計算または調節する必要があります。

TCP ストリーム編集。

コマンド パイプライン。

設定例

図 5-3に、内部ネットワーク上に SMTP と NFS を実装するネットワークの事例を示します。

図 5-3 SMTP と NFS (Sun RPC)による設定例

 

この例では、static コマンドが、内部インターフェイス上の 10.1.1.3 Sun Mail ホストに対する外部ホストのアクセスを許可するため、グローバル アドレスを設定します(DNS の MX レコードは、メールが 10.1.1.3 アドレスに送信されるように、209.165.201.1 アドレスを指す必要があります)。access-list コマンドを使用すると、外部ユーザは SMTP ポート(25)でグローバル アドレスにアクセスできます。no fixup protocol コマンドを使用すると、Mail Guard 機能がディセーブルに設定されます。

次の手順を実行して、この例に必要な設定を完了します。


ステップ 1 グローバル アドレス 209.165.201.12 を経由する 10.1.1.3 メール サーバ へのアクセスを可能にします。

static (inside, outside) 209.165.201.12 10.1.1.3 netmask 255.255.255.255 0 0
access-list acl_out permit tcp any host 209.165.201.12 eq smtp
 

access-list コマンドにより、任意の外部ホストが SMTP(ポート25)を経由して、このスタティック アドレスにアクセスすることが許可されます。 デフォルトでは、RFC 821 セクション 4.5.1 の規定に従って、メール サーバへのアクセスはすべて、PIX Firewall によってコマンド DATA、HELO、MAIL、NOOP、QUIT、RCPT、RSET に制限されます。 これは、Mail Guard サービスにより実装され、デフォルトでイネーブルになっています( fixup protocol smtp 25 )。

メール サーバへのアクセスを可能にするには、スタティック グローバル アドレスに対して DNS MX レコードが確実にあることが重要です。外部ユーザは、メールをサイトに送信する時に、このグローバル アドレスにアクセスします。

ステップ 2 ポート 113、つまり IDENT プロトコルに対するアクセスを作成します。

access-list acl_out permit tcp any host 209.165.201.12 eq 113
access-group acl_out in interface outside
static (inside, outside) 209.165.201.12 10.1.1.3 netmask 255.255.255.255 0 0
access-list acl_out permit tcp any host 209.165.201.12 eq smtp
access-list acl_out permit tcp any host 209.165.201.12 eq 113
access-group acl_out in interface outside
 

メール サーバが外部の多数のメール サーバと対話する必要があり、相手のメール サーバが問題の多い古い IDENT プロトコルを使用して接続する場合には、この access-list コマンド文を使用すると、メール送信の速度が向上します。 access-group コマンド文は、複数の access-list コマンド文を外部インターフェイスにバインドします。


 

例5-1に、ネットワークのサービスへのアクセスを設定するコマンド リストを示します。

例5-1 メール サーバ アクセスの設定

static (inside, outside) 209.165.201.12 10.1.1.3 netmask 255.255.255.255 0 0
access-list acl_out permit tcp any host 209.165.201.12 eq smtp
access-list acl_out permit tcp any host 209.165.201.12 eq 113
access-group acl_out in interface outside
static (inside, outside) 209.165.201.12 10.1.1.3 netmask 255.255.255.255 0 0
 

Voice Over IP(VoIP)

ここでは、VoIP(Voice over IP)アプリケーションとプロトコルに対する PIX Firewall によるサポート、および問題を解決するための fixup コマンドやその他のコマンドの使用方法について説明します。次の項目について説明します。

「CTIQBE」

「CU-SeeMe」

「H.323」

「MGCP」

「SCCP」

「SIP」

CTIQBE

Telephony Application Programming Interface(TAPI; テレフォニー アプリケーション プログラミング インターフェイス)と Java Telephony Application Programming Interface(JTAPI; Java テレフォニー アプリケーション プログラミング インターフェイス)は、多くの Cisco VoIP アプリケーションで使用されます。 PIX Firewall Version 6.3 では特定のプロトコル Computer Telephony Interface Quick Buffer Encoding(CTIQBE)がサポートされました。このプロトコルは Cisco TAPI Service Provider(TSP; TAPI サービス プロバイダー)が Cisco CallManager と通信するために使用します。

このプロトコルのサポートはデフォルト設定でディセーブルになっています。このプロトコルのサポートをイネーブルにするには、次のコマンドを入力します。

fixup protocol ctiqbe 2748
 

CTIQBE 接続のステータスを表示するには、次のコマンドを入力します。

show conn state ctiqbe
 

このコマンドを使用すると、CTIQBE フィックスアップ モジュールによって割り当てられたメディア接続に関する情報が表示されます。

出力には、CTIQBE フィックスアップ モジュールによって割り当てられたメディア接続が「C」フラグで示されます。

CTIQBE アプリケーション検査の使用時に適用される制限を次にまとめます。

CTIQBE アプリケーション検査では、alias コマンドを使用したコンフィギュレーションをサポートしていません。この方法は、外部 NAT が PIX Firewall Version 6.2 で導入されてからは推奨されていません。

CTIQBE コールのステートフル フェールオーバーはサポートされていません。

debug ctiqbe コマンドを使用すると、メッセージの伝送が遅れる場合があり、リアルタイム環境のパフォーマンスに影響することがあります。このデバッグまたはログをイネーブルにし、PIX Firewall を介して Cisco IP SoftPhone でコール セットアップを完了できない場合は、Cisco IP SoftPhone の動作するシステムで Cisco TSP 設定のタイムアウト値を増やしてください。

CTIQBE アプリケーション検査では、複数 TCP パケットのフラグメント化された CTIQBE メッセージをサポートしません。

次に、CTIQBE アプリケーション検査を特定の事例で使用する際に、特別に注意が必要な事項をまとめます。

2 つの Cisco IP SoftPhone が異なる Cisco CallManager に登録されていて、各 CallManager が PIX Firewall の異なるインターフェイスに接続されている場合、これら 2 つの電話間のコールは失敗します。

Cisco IP SoftPhone と比較して Cisco CallManager の方がセキュリティの高いインターフェイス上に配置されている状態で、NAT または外部 NAT が Cisco CallManager IP アドレスに必要な場合、マッピングはスタティックである必要があります。Cisco IP SoftPhone では Cisco CallManager IP アドレスを PC 上の Cisco TSP コンフィギュレーションで明示的に指定することが必要なためです。

PAT または外部 PAT を使用しているときに Cisco CallManager IP アドレスを変換する場合、TCP ポート 2748 を PAT (インターフェイス)アドレスの同一ポートに対してスタティックにマッピングする必要があります。これは Cisco IP SoftPhone の登録を成功させるためです。 CTIQBE 受信ポート(TCP 2748)は固定されていて、Cisco CallManager、Cisco IP SoftPhone、Cisco TSP のいずれにおいてもユーザによる設定はできません。

NAT または外部 NAT を Cisco IP SoftPhone アドレスに使用している場合は、Cisco CallManager で登録を受け入れる限り電話の登録は成功します。その IP アドレスが Cisco IP Softphone 用に Cisco CallManager 上ですでに設定されたアドレスと一致していなくても成功します。 これは Cisco CallManager 3.1(2c) および 3.2(2c) の動作であり、Cisco CallManager の今後のリリースで変更された場合には、この状況下での Cisco IP Softphone 登録は失敗する可能性があります。

PIX Firewall を通じて確立した CTIQBE セッションに関する情報を表示するには、次のコマンドを入力します。

show ctiqbe
 

このコマンドを使用して CTIQBE アプリケーション検査の問題を解決する場合の詳細については、『Cisco PIX Firewall Command Reference』の show ctiqbe コマンドのページを参照してください。

CU-SeeMe

CU-SeeMe クライアントを使用すると、1 ユーザが、個人間の音声、ビデオ、およびデータの連携運用のため、別のユーザ(CU-SeeMe または別の H.323 クライアント)に直接接続できます。
CU-SeeMe クライアントは、CU-SeeMe と他社製の H.323 準拠クライアントの両方から構成される混成クライアント環境で会議を実行できます。

CU-SeeMe クライアントは、背後では 2 つのまったく別のモードで動作します。CU-SeeMe クライアントは、別の CU-SeeMe クライアントまたは CU-SeeMe Conference Server に接続されると、CU-SeeMe モードで情報を送信します。

他社製の H.323 準拠テレビ会議クライアントに接続されると、CU-SeeMe クライアントは、H.323 モードで、H.323 標準形式を使用して通信を行います。

CU-SeeMe は、H.323 検査によりサポートされるとともに、UDP ポート 7648 上で動作する CU-SeeMe 制御ストリーム上で NAT を実行します。

H.323

ここでは、H.323 プロトコル群に対するアプリケーション検査を管理する方法について説明します。次の項目について説明します。

「概要」

「1 コール シグナリング接続における複数コール」

「接続ステータスの表示」

「技術的な背景説明」

概要

fixup コマンドを使用して、H.323 プロトコルに対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

[no] fixup protocol h323 h225 |ras port [-port]]
 

デフォルトの制御接続ポート割り当てを変更するには、 port オプションを使用します。デフォルトのポート割り当ては次のとおりです。

h323 h225 1720

h323 ras 1718-1719

一定範囲のポート番号に H.323 アプリケーション検査を適用するには、- port オプションを使用します。

fixup protocol h323 コマンドでは、H.323 準拠のエンドポイントがサポートされています。
PIX Firewall Version 5.3 ~ Version 6.2 では、H.323 Version 2 がサポートされます。 PIX Firewall Version 6.3 では、H.323 Version 3 と Version 4 がサポートされます。

H.323 は、ITU によって定義されている LAN を介したマルチメディア会議用のプロトコル群です。H.323 では、VoIP ゲートウェイと VoIP ゲートキーパがサポートされています。H.323 Version 2 からは、次の機能が追加されています。

高速コール セットアップのための Fast Connect または Fast Start Procedure

リソース保存、コール同期化、およびセットアップ時間短縮のための H.245 トンネリング

1 コール シグナリング接続における複数コール

PIX Firewall Version 6.3 では、H.323 Version 3 で導入された機能である同一コール シグナリング チャネルでの複数コールをサポートします。 この機能によってセットアップ時間が短縮し、PIX Firewall でのポート使用が減少します。 この機能の使用時に H.225 コール シグナリング チャネルをオープン状態にしておく時間を制御するため、新しい timeout コマンドが導入されました。このコマンドの構文は次のとおりです。

timeout h225 hh:mm:ss
 

hh には時間を指定し、mm には分を、ss には秒を指定します。デフォルト値は 1 時間です。 チャネルがタイムアウトされないでオープンしたままに保つには、次のコマンドを入力してタイマーを 0 に設定します。

timeout h225 00:00:00
 

すべてのコールがクリアされた後、すぐにタイマーをディセーブルにして TCP 接続を終了するには、次のようにタイムアウト値を 1 秒に設定します。

timeout h225 00:00:01
 

接続ステータスの表示

H.225 接続のステータスを表示するには、次のコマンドを入力します。

show conn state h225
 

技術的な背景説明

H.323 検査は、スタティック NAT またはダイナミック NAT をサポートします。 H.323 RAS は、PIX Firewall Version 6.2 以降で、 fixup コマンドを使用すると設定できます。


) H.323 に対する PAT サポートは、PIX Firewall Version 6.2 で導入されました。


H.323 のプロトコルのコレクションは、合計で最大 2 つの TCP 接続と 4 ~ 6 つの UDP 接続を使用できます。FastConnect は 1 つの TCP 接続だけを使用し、RAS は登録、アドミッション、およびステータス用に 1 つの UDP 接続を使用します。

H.323 クライアントは、最初に TCP ポート 1720 を使用して、H.323 サーバへの TCP 接続を確立し、Q.931 コール セットアップを要求します。H.323 端末は、コール セットアップ プロセスの一部として、H.245 TCP 接続に使用するため、クライアントに 1 つのポート番号を供給します。


) H.323 ゲートキーパが使用されている環境では、初期パケットは UDP を使用して送信されます。


H.323 検査は、Q.931 TCP 接続を監視して、H.245 ポート番号を決定します。H.323 端末が、FastConnect を使用していない場合は、PIX Firewall が H.225 メッセージの検査に基づいて、H.245 接続をダイナミックに割り当てます。

各 H.245 メッセージ内で、H.323 エンドポイントが、後続の UDP データ ストリームに使用するポート番号を交換します。H.323 検査は、H.245 メッセージを調査して、ポート番号を識別し、メディア交換用の接続をダイナミックに作成します。Real-Time Transport Protocol (RTP)は、ネゴシエートされたポート番号を使用する一方で、RTP Control Protocol (RTCP)は、次に大きいポート番号を使用します。

H.323 制御チャネルは、H.225、H.245、および H.323 RAS を処理します。H.323 検査では、次のポートが使用されます。

1718 :ゲートキーパ検出 UDP ポート

1719:RAS UDP ポート

1720:TCP 制御ポート

H.323 検査の 2 つの主要機能は次のとおりです。

H.225 と H.245 の両メッセージ内に埋め込まれている必要な IPv4 アドレスを NAT 処理します。H.323 メッセージは PER 符号化形式で符号化されているため、PIX Firewall では ASN.1 デコーダを使用して H.323 メッセージを復号化します。

ネゴシエートされた H.245 と RTP/RTCP 接続をダイナミックに割り当てます。

PIX Firewall 管理者は、H.225 通話シグナリング用に予約済みの H.323 ポート 1720 にコンジットを開く必要があります。ただし、H.245 シグナリング ポートは、H.225 シグナリングのエンドポイント間でネゴシエートされます。


) H.323 ゲートキーパの使用時には、PIX Firewall は、ACF メッセージの検査に基づいて、H.225 接続を開きます。


PIX Firewall は、H.225 メッセージの検査後、H.245 チャネルをダイナミックに割り当て、H.245 チャネルも「接続」してフィックスアップします。これは、埋め込み IP アドレスを NAT 処理し、ネゴシエートされたメディア チャネルを開くことによって、PIX Firewall を通過する H.245 メッセージはすべて、H.245 アプリケーション検査も通過することを意味します。

H.323 ITU 規準では、メッセージ長を定義する TPKT ヘッダーが最初に送信されてから、H.225 と H.245 が信頼できる接続上を送信されることが要求されています。TPKT ヘッダーは、必ずしも H.225/H.245 メッセージと同一の TCP パケット内で送信される必要はないため、PIX Firewall では、メッセージを正しく処理または復号化するために TPKT 長を記憶しておく必要があります。PIX Firewall は、各接続に対して、1 つのデータ構造体を維持します。そのデータ構造体には、次に期待されるメッセージに対する TPKT 長が含まれています。

PIX Firewall において、すべての IP アドレスを NAT 処理する必要がある場合、チェックサムと user-user information element (UUIE; ユーザ対ユーザ情報要素)の長さを変更する必要があります。また H.225 メッセージとともに TPKT が TCP パケット内に含まれているときは、この TPKT も変更する必要があります。TPKT が、別個の TCP パケットで送信された場合、PIX Firewall は、その TPKT に対する ACK (確認応答)を代理処理し、新しい長さの更新された TPKT を H.245 メッセージに追加します。


) PIX Firewall は、TPKT に対する ACK の代理処理では TCP オプションをサポートしていません。


H.323 検査を通過するパケットが通る各 UDP 接続は、H.323 接続としてマークされ、管理者が、 timeout コマンドを使用して設定した H.323 タイムアウト値でタイムアウトします。

MGCP

Cisco PIX Firewall Version 6.3 では、MGCP のアプリケーション検査がサポートされました。 ここでは、アプリケーション検査をイネーブルにする方法、およびアプリケーション検査情報の表示方法について説明します。次の項目について説明します。

「概要」

「MGCP アプリケーション検査のイネーブル化」

「複数の呼エージェントおよびゲートウェイのコンフィギュレーション」

「MGCP 情報の表示」

概要

MGCP は、メディア ゲートウェイ コントローラや呼エージェントという外部のコール制御要素からメディア ゲートウェイを制御するために使用します。 メディア ゲートウェイは一般に、電話回線を通じた音声信号と、インターネットまたは他のパケット ネットワークを通じたデータ パケットとの間の変換を行うネットワーク要素です。 メディア ゲートウェイの例は次のとおりです。

トランキング ゲートウェイ。電話ネットワークと Voice over IP ネットワークとの間のインターフェイスです。 このようなゲートウェイは通常、大量のデジタル回線を管理します。

住宅用ゲートウェイ。従来のアナログ(RJ11)インターフェイスを Voice over IP ネットワークに提供します。 住宅用ゲートウェイの例としては、ケーブル モデムやケーブル セットトップ ボックス、xDSL 装置、ブロードバンド ワイヤレス装置などがあります。

ビジネス ゲートウェイ。従来のデジタル PBX (構内交換機)インターフェイスまたは統合 soft PBX インターフェイスを Voice over IP ネットワークに提供します。

MGCP メッセージは UDP を介して送信されます。 応答はコマンドの発信元アドレス(IP アドレスと UDP ポート番号)に返送されますが、コマンド送信先と同じアドレスからの応答は到達しない場合があります。 これは、複数の呼エージェントがフェールオーバー コンフィギュレーションで使用されているときに、コマンドを受信した呼エージェントが制御をバックアップ呼エージェントに引き渡し、バックアップ呼エージェントから応答を送信する場合に起こる可能性があります。

MGCP アプリケーション検査のイネーブル化

MGCP に対するアプリケーション検査をイネーブルにするには、次のコマンドを入力します。

[no] fixup protocol mgcp [port[-port]]
 

MGCP のアプリケーション検査は、デフォルト設定でディセーブルになっています。 一般に、MGCP を使用するには少なくとも 2 つのポートを設定する必要があります。 ポートの 1 つはゲートウェイがコマンドを受信するために使用し、もう 1 つは呼エージェントがコマンドを受信するために使用します。 通常、呼エージェントはコマンドをポート 2427 に送信し、ゲートウェイはコマンドをポート 2727 に送信します。

PIX Firewall Version 6.3 以前では、NAT も PAT もサポートされていません。

デフォルト ポートを使用して呼エージェントおよびゲートウェイに対する MGCP アプリケーション検査をイネーブルにするには、次のコマンドを入力します。

fixup protocol mgcp 2427
fixup protocol mgcp 2727
 

MGCP 非アクティビティ タイマーの時間を設定するには、次のコマンドを入力します。

timeout mgcp <hh:mm:ss>
 

指定時間が経過すると、MGCP メディア ポートは閉じられます。デフォルトの設定値は5分です。

複数の呼エージェントおよびゲートウェイのコンフィギュレーション

複数の MGCP 呼エージェントおよびゲートウェイの使用をサポートするように PIX Firewall を設定するには、次のコマンドを使用します。

[no] mgcp call-agent ip_address group_id
[no] mgcp command-queue limit
[no] mgcp gateway ip_address group_id
 

1 つ以上のゲートウェイを管理できる呼エージェントのグループを指定するには、 mgcp call-agent コマンドを使用します。 この情報は、どの呼エージェントも応答を送信できるように、ゲートウェイがコマンドを送信する先以外の呼エージェントについて接続を開くために使用されます。 ip_address オプションで呼エージェントの IP アドレスを指定します。 group_id オプションは 0 ~ 4294967295 の数字です。 group_id が同じ呼エージェントは、同じグループに所属します。

応答を待つキューに入る MGCP コマンドの最大数を指定するには、 mgcp command-queue コマンドを使用します。 limit オプションに許可される値の範囲は、1 ~ 4294967295 です。 デフォルト値は 200 です。 限度に到達しているときに新しいコマンドが着信すると、最も長時間キューに入っているコマンドが削除されます。

特定のゲートウェイを管理している呼エージェントのグループを指定するには、 mgcp gateway コマンドを使用します。 ip_address オプションを使用して、ゲートウェイの IP アドレスを指定します。 group_id オプションは 0 ~ 4294967295 の数字です。 この数字は、ゲートウェイを管理している呼エージェントの group_id に対応している必要があります。

MGCP コンフィギュレーションをすべて削除してコマンドのキュー限度をデフォルトの 200 に設定するには、 clear mgcp コマンドを使用します。

次の例では、MGCP コマンドのキューが 150 コマンドに制限されていて、呼エージェント 10.10.11.5 と 10.10.11.6 がゲートウェイ 10.10.10.115 を制御でき、呼エージェント 10.10.11.7 と 10.10.11.8 がゲートウェイ 10.10.10.116 を制御できます。

mgcp call-agent 10.10.11.5 101
mgcp call-agent 10.10.11.6 101
mgcp call-agent 10.10.11.7 102
mgcp call-agent 10.10.11.8 102
mgcp command-queue 150
mgcp gateway 10.10.10.115 101
mgcp gateway 10.10.10.116 102

MGCP 情報の表示

MGCP に関する情報を表示するには、次のコマンドを入力します。

show mgcp commands | sessions [detail]
 

コマンド キュー内のコマンド リストを表示するには、 commands オプションを使用します。 既存の MGCP セッション リストを表示するには、 sessions オプションを使用します。 各コマンドまたはセッションに関する詳細情報のリストを表示するには、 detail オプションを使用します。

MGCP 接続の情報を表示するには、次のコマンドを入力します。

show conn detail |state mgcp
 

MGCP 接続に関する詳細情報を表示するには、detail オプションを使用します。 MGCP セッションに作成されたメディア接続を表示するには、 state オプションを使用します。

SCCP

Skinny (または Simple) Client Control Protocol (SCCP)は、VoIP ネットワークで使用される簡易プロトコルです。ここでは、SCCP の使用時におけるアプリケーション検査の機能と制限について説明します。次の項目について説明します。

「概要」

「SCCP での PAT の使用方法」

「高セキュリティ インターフェイス上での Cisco CallManager と SCCP の併用」

「フラグメント化された SCCP パケットで発生する問題」

「SCCP 情報の表示」

概要

SCCP を使用する Cisco IP Phone は、H.323 環境でも使用できます。Cisco CallManager と併用すると、SCCP クライアントは、H.323 準拠端末と同時使用できます。PIX Firewall におけるアプリケーション層機能では、SCCP Version 3.3 が認識されます。アプリケーション層ソフトウェアの機能により、SCCP シグナリング パケットの NAT が提供されるため、SCCP シグナリング パケットとメディア パケットのすべてが、ファイアウォールを通過することが保証されます。

fixup コマンドは、SCCP に対するデフォルトのポート割り当てを変更するために使用できます。コマンドの構文は次のとおりです。

[no] fixup protocol skinny [port[-port]]

SCCP プロトコルのバージョンには 2.4、3.0.4、3.1.1、3.2、および 3.3.2 の 5 つがあります。 PIX Firewall Version 6.3 では Version 3.3.2 までをサポートします。

SCCP のアプリケーション検査は、デフォルト設定でイネーブルになっています。デフォルトのポート割り当てを 2000 から変更するには、 port オプションを使用します。一定範囲のポート番号に SCCP アプリケーション検査を適用するには、- port オプションを使用します。

Cisco CallManager サーバのアドレスが別のアドレスまたはポートに対して NAT または PAT 用に設定されている場合に、TFTP を使用して外部電話をそのアドレスに登録すると、その接続は失敗します。これは、PIX Firewall が TFTP を使用して転送されたファイル内容の NAT または PAT をサポートしていないためです。 PIX Firewall は TFTP メッセージの NAT をサポートし、TFTP ファイル用にピンホールを開いてファイアウォールを通過できるようにしますが、電話の登録中に TFTP を使用して転送された Cisco IP Phone のコンフィギュレーション ファイルに埋め込まれた Cisco CallManager の IP アドレスおよびポートを変換することはできません。 この問題の回避方法については、「高セキュリティ インターフェイス上での Cisco CallManager と SCCP の併用」を参照してください。

PIX Firewall Version 6.2 では、DHCP オプションの 150 と 66 が導入されました。この導入により、
PIX Firewall は、TFTP サーバの位置を Cisco IP Phone などの DHCP クライアントに送信できます。この新機能の詳細については、「SOHO ネットワークにおける PIX Firewall の使用」「PIX Firewall DCHP サーバの使用方法」を参照してください。

SCCP での PAT の使用方法

PIX Firewall Version 6.3 では SCCP の PAT および NAT がサポートされました。 PAT は、IP 電話で使用するグローバル IP アドレスの数が限られている場合に必要です。 SCCP に対する現在のバージョンの PAT および NAT サポートに適用される制限は、次のとおりです。

PAT は alias コマンドを使用したコンフィギュレーションでは動作しない。

SCCP コールのステートフル フェールオーバーはサポートされていない。

debug skinny コマンドを使用すると、メッセージ送信の遅延を招く場合があり、リアルタイム環境のパフォーマンスに影響することがある。

フラグメント化された SCCP メッセージはサポートしない。

外部 NAT も PAT もサポートしない。

Cisco CallManager に PAT xlate が作成されてから clear xlate コマンドが入力された場合、SCCP コールを確立できません。Cisco CallManager の xlate が永続的に削除されるためです。 この状況にある場合、Cisco IP Phone を Cisco CallManager に再登録して PIX Firewall を通じたコールを確立する必要があります。

Cisco IP Phone と比較して Cisco CallManager の方がセキュリティの高いインターフェイスに配置されているトポロジにおいて、NAT が Cisco CallManager IP アドレスに必要な場合、マッピングはスタティックである必要があります。これは、Cisco IP Phone では Cisco CallManager IP アドレスをコンフィギュレーションで明示的に指定する必要があるためです。


) Cisco CallManager IP アドレスと SCCP ポートの両方を変換する必要がある場合、SCCP ポートは実際のアドレスと同じポートへスタティックにマッピングする必要があります。これは、Cisco IP Phone の登録を成功させるためです。


高セキュリティ インターフェイス上での Cisco CallManager と SCCP の併用

Cisco IP Phone では、TFTP サーバにアクセスして、Cisco CallManager サーバに接続するために必要な設定情報をダウンロードする必要があります。

TFTP サーバと比較して Cisco IP Phone の方がセキュリティの低いインターフェイス上にある場合は、アクセス リストを使用して UDP ポート 69 の保護された TFTP サーバに接続する必要があります。 TFTP サーバに対してはスタティック エントリが必要ですが、「識別」スタティック エントリにする必要はありません。 NAT を使用する場合、識別スタティック エントリは同じ IP アドレスにマッピングされます。 PAT を使用する場合は、同じ IP アドレスとポートにマッピングされます。

ただし、Cisco CallManager と比較して Cisco IP Phone の方がセキュリティの低いインターフェイスにある場合は、高セキュリティ インターフェイス上の Cisco CallManager で Cisco IP Phone からの登録を受け入れられるように識別スタティック エントリを作成することを推奨します。

TFTP サーバおよび Cisco CallManager と比較して Cisco IP Phone の方がセキュリティの高いインターフェイスにあるときは、Cisco IP Phone で接続を開始するためにアクセス リストもスタティック エントリも必要ありません。


) Cisco CallManager と Cisco IP Phone 間の通常のトラフィックでは SCCP が使用され、特別な設定がなくても SCCP 検査によるトラフィック処理が行われます。


フラグメント化された SCCP パケットで発生する問題

現在の時点では、PIX Firewall は、フラグメント化された SCCP パケットを正しく処理することはできません。たとえば、音声会議ブリッジの使用時、SCCP パケットはフラグメント化される可能性があり、その場合 PIX Firewall によって廃棄されます。これは、SCCP 検査が、各パケットをチェックし、不良パケットと推定されるものを廃棄するために起こります。1 つの SCCP パケットが複数の TCP パケットにフラグメント化されると、SCCP 検査機能によって、SCCP パケットフラグメント内の内部チェックサムが正しくないことが検出され、この SCCP パケットが廃棄されます。

SCCP 情報の表示

PIX Firewall を通じて確立した SCCP セッションに関する情報を表示するには、次のコマンドを入力します。

show skinny
 

このコマンドを使用して SCCP アプリケーション検査の問題を解決する場合の詳細については、『Cisco PIX Firewall Command Reference』の show skinny コマンドのページを参照してください。

SIP

Internet Engineering Task Force (IETF)で定義されている SIP により、特に 2 者間の電話会議などのコール処理セッションまたは「コール」が使用可能になります。ここでは、SIP に対するアプリケーション検査の動作について説明します。次の項目について説明します。

「概要」

「外部電話によって内部電話を保留状態にする」

「SIP 情報の表示」

「技術的な背景説明」

概要

SIP は、コール シグナリング用の Session Description Protocol (SDP)で動作します。SDPは、メ
ディア ストリーム用のポートを指定します。SIP を使用すると、PIX Firewall は、任意の SIP Voice over IP (VoIP)ゲートウェイと VoIP プロキシ サーバをサポートできます。SIP と SDP の定義は、次の RFC に記載されています。

SIP: Session Initiation Protocol、RFC 2543

SDP: Session Description Protocol、RFC 2327

fixup コマンドを使用して、SIP に対するデフォルトの TCP ポート割り当てを変更できます。コマンドの構文は次のとおりです。

[no] fixup protocol sip <udp> [port[-port]]
 

) SIP に対する PAT サポートは、PIX Firewall Version 6.2 以降で提供されます。 スタティック NAT と ダイナミック NAT だけは、以前のバージョンでサポートされています。


デフォルトのポート割り当てを 5060 から変更するには、 port オプションを使用します。一定範囲のポート番号に SIP アプリケーション検査を適用するには、- port オプションを使用します。

SIP 接続に対する現在のタイムアウト値を表示するには、次のコマンドを入力します。

show timeout sip
 

SIP 接続の状態を表示するには、次のコマンドを入力します。

show conn state sip
 

PIX Firewall 経由の SIP コールをサポートする場合は、シグナリング メッセージは予約済みの宛先ポート(UDP/TCP 5060)経由で送信され、メディア ストリームはダイナミックに割り当てられるため、メディア接続アドレスのシグナリング メッセージ、メディア ポート、およびメディアの初期接続を検査する必要があります。また、SIP は、IP パケットのユーザデータ部分に IP アドレスを埋め込みます。SIP 検査は、それらの埋め込まれた IP アドレスに NAT を適用します。

外部電話によって内部電話を保留状態にする

SIP を使用して IP 電話により発信コールを行い、外部電話から内部電話を保留状態にしようとすると、その操作は失敗します。これは、外部電話から INVITE パケットを送信するために、新しい接続が開始され、PIX Firewall がそのパケットを廃棄するためです。

この問題を解決するには、次のいずれかを実行します。

アクセス リストを設定して、ポート 5060 を使用し、Re-INVITE パケットが内部ゲートウェイに到着することを許可します。

次の例のように、 established コマンドを使用します。

established dup 5060 permitto udp 5060 permitfrom udp 0
 

外部電話から内部電話への UDP 接続がすでに存在する場合、このコマンド文により、PIX Firewall は、外部電話から新しい接続をポート 5060 上で開始することを許可します。通話は、SIP に対するタイムアウト間隔に指定された時間、保留状態にできます。このタイムアウト間隔は、必要に応じて、 timeout コマンドを使用して長くすることもできます。

SIP 情報の表示

PIX Firewall を通じて確立した SIP セッションに関する情報を表示するには、次のコマンドを入力します。

show sip
 

このコマンドを使用して CTIQBE アプリケーション検査の問題を解決する場合の詳細については、『Cisco PIX Firewall Command Reference』の show sip コマンドのページを参照してください。

技術的な背景説明

SIP 検査は、テキストベースの SIP メッセージを NAT 処理し、メッセージの SDP 部分の内容長を再計算した後、パケット長とチェックサムを再計算します。また、エンドポイントが受信すべきアドレスまたはポートとして、SIP メッセージの SDP 部分に指定されたポートに対するメディア接続をダイナミックに開きます。

SIP 検査には、発信元および宛先と同様に、通話を SIP ペイロードから識別するインデックス CALL_ID/FROM/TOSIP を持つデータベースがあります。このデータベースには、SDP メディア情報フィールドとメディア タイプに含まれていたメディア アドレスとメディア ポートが格納されます。1 つのセッションに対して、複数のメディア アドレスとポートが存在することが可能です。RTP/RTCP 接続は、これらのメディア アドレス/ポートを使用して、2 つのエンドポイント間に開かれます。 初期コール セットアップ(INVITE)メッセージでは、予約済みポート 5060 を使用する必要があります。 ただし、後続のメッセージにはこのポート番号がない場合もあります。SIP fixup はシグナリング接続のピンホールを開き、それらの接続を SIP 接続としてマークします。これは、SIP アプリケーションに到達し、NAT 処理すべきメッセージに対して行われます。

コールのセットアップ時に、SIP セッションは、着呼エンドポイントが受信する RTP ポートを示す応答メッセージにおいて、メディア アドレスとメディア ポートが受信されるまで「一時的な」状態にあるものとみなされます。1 分以内に、応答メッセージの受信に障害があった場合は、シグナリング接続は切断されます。

最終的なハンドシェイクが行われると、コール状態はアクティブに移行し、シグナリング接続は、BYE メッセージの受信まで継続されます。

内部エンドポイントが、外部エンドポイントに発呼した場合、メディア ホールが、外部インターフェイスに対して開き、内部エンドポイントから送信された INVITE メッセージで指定された内部エンドポイントのメディア アドレスとメディア ポートに、RTP/RTCP UDP パケットが流れることが許可されます。内部インターフェイスに対する要求外の RTP/RTCP UDP パケットは、PIX Firewall のコンフィギュレーションにより特別に許可されない限り、PIX Firewall を通過できません。

メディア接続は、接続がアイドル状態になってから 2 分以内に切断されます。ただし、これは設定可能なタイムアウトであり、時間間隔は変更することが可能です。

マルチメディア アプリケーション

ここでは、マルチメディアまたはビデオ オンデマンド アプリケーションとプロトコルに対する PIX Firewall によるサポート、および問題を解決するための fixup コマンドやその他のコマンドの使用方法について説明します。次の項目について説明します。

「Netshow」

「リアルタイム ストリーミング プロトコル(RTSP)」

「VDO LIVE」

Netshow

Netshow はストリーミング マルチメディア サービスであり、インターネットからの音声およびビデオ ストリームの受信を可能にします。ユーザは、マルチメディア ストリームを受信するため、Netshow サーバに接続の Windows メディア プレーヤーを使用して、Netshow コンテントを再生します。

ストリームの送信されるデータ チャネルは、制御チャネルでネゴシエートされます。 ここでは、異なるストリームについて次の項目で説明します。

「UDP ストリーム」

「TCP ストリーム」

UDP ストリーム

UDP ストリームは、次のように、Netshow と併用されます。

1. クライアントは、予約済みポート 1755 で、Netshow サーバと TCP 接続を行います。

2. 接続が確立されると、クライアントは、データを受信すると予測される UDP ポートを示す LVMConnectFunnel メッセージをNetshow サーバに送信します。

3. Netshow サーバは、1024 ~ 5000 の範囲で UDP ポートを選択して、クライアントに Netshow データをストリーム形式で送信します。

4. Netshow サーバは、ネゴシエートされたポートでストリームを送信します。

5. Netshow セッションは、TCP 接続を切断すると終了します。

TCP ストリーム

TCP ストリームは、次のように Netshow と併用されます。

1. クライアントは、予約済みポート 1755 で、Netshow サーバと TCP 接続を行います。

2. 接続が確立されると、クライアントは、 TCP 接続の使用を確認する LVMConnectFunnel メッセージをNetshow サーバに送信します。

3. Netshow サーバは、接続済みの TCP ポートでストリームを送信します。

4. Netshow セッションは、TCP 接続を切断すると終了します。

リアルタイム ストリーミング プロトコル(RTSP)

fixup コマンドを使用すると、RTSP に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

fixup rtsp [port]
 

fixup protocol rtsp コマンドで、PIX Firewall に RTSP パケットの通過を許可させることができます。RTSP は、RealAudio、RealNetworks、Apple QuickTime 4、RealPlayer、および Cisco IP/TV 接続によって使用されます。PIX Firewall はマルチキャスト RTSP をサポートしていません。

Cisco IP/TV を使用している場合、次のように RTSP TCP ポート 554 および TCP 8554 を指定します。

fixup protocol rtsp 554
fixup protocol rtsp 8554
 

fixup protocol rtsp コマンドには、次の制限が適用されます。

この PIX Firewall は、UDP ポートを通過する RTSP メッセージを修正しません。

PIX Firewall は、RealNetworks のマルチキャスト モード(x-real-rdt/mcast)をサポートしません。

fixup protocol rtsp コマンドは、PAT をサポートしません。

PIX Firewall は、RTSP メッセージが HTTP メッセージ内に隠される HTTP クローキングを認識する機能をもちません。

PIX Firewall は、埋め込み IPアドレスが、HTTP メッセージまたは RTSP メッセージの一部として SDP ファイル内に含まれているため、RTSP メッセージには NAT を実行できません。パケットはフラグメント化する可能性があり、PIX Firewall はフラグメント化されたパケットに対して NAT を実行できません。

Cisco IP/TV については、PIX Firewall がメッセージの SDP 部分に実行する NAT の回数は、Content Manager 内 のプログラム リストの数(各プログラム リストには少なくとも 6 つの埋め込み IP アドレスが存在する可能性がある)に比例します。

NAT を Apple QuickTime 4、または RealPlayer を使用するように設定できます。Cisco IP/TV は、ビューアと Content Manager が外部ネットワークにあり、サーバが内部ネットワークにあるときにだけ NAT を使用できます。

RealPlayer を使用するときは、転送モードを正しく設定することが重要です。PIX Firewall の場合は、サーバからクライアントに、またはその逆に access-list コマンド文を追加します。
RealPlayer については、 Options > Preferences > Transport > RTSP Settings を選択して、転送モードを変更します。

RealPlayer で TCP モードを使用する場合は、 Use TCP to Connect to Server チェックボックスおよび Attempt to use TCP for all content チェックボックスをオンにします。PIX Firewall では、フィックスアップの設定は不要です。

RealPlayer で UDP モードを使用する場合は、 Use TCP to Connect to Server チェックボックスおよび Attempt to use UDP for static content チェックボックス をオンにします。 PIX Firewall で、 fixup protocol rtsp port コマンド文を追加します。

RTSP アプリケーションは、制御チャネルとしての TCP (例外的に UDP)とともに予約済みポート 554 を使用します。PIX Firewall は、RFC 2326 に準拠して、TCP だけをサポートします。

この TCP 制御チャネルは、クライアント上で設定されているトランスポート モードに応じて、音声/ビデオ トラフィックの送信に使用されるデータ チャネルのネゴシエーションに使用されます。

サポートされている RDT トランスポートは、rtp/avp、rtp/avp/udp、x-real-rdt、x-real-rdt/udp、x-pn-tng/udp です。

PIX Firewall は、ステータス コード 200 の SETUP 応答メッセージの構文分析を行います。 SETUP 応答メッセージが、着信方向に移動している場合は、サーバは PIX Firewall との相対位置関係で外部に存在することになるため、サーバから着信する接続に対してダイナミック チャネルを開くことが必要になります。この応答メッセージが発信方向である場合、PIX Firewall は、ダイナミック チャネルを開く必要はありません。

RFC 2326 では、クライアント ポートとサーバ ポートが、SETUP 応答メッセージ内に含まれていることは必要でないため、PIX Firewall では、状態を維持し、SETUP メッセージ内のクライアント ポートを記憶する必要があります。QuickTime が、SETUP メッセージ内にクライアント ポートを設定すると、サーバは、サーバ ポートだけで応答します。

RTSP 検査は、PAT またはデュアル NAT をサポートしていません。 また、PIX Firewall は、RTSP メッセージが HTTP メッセージ内に隠される HTTP クローキングを認識できません。

VDO LIVE

VDO LIVE は、ストリーミング マルチメディア サービスであり、インターネットからの音声およびビデオ ストリームの受信を可能にします。

制御メッセージ用の TCP、およびストリーム用の UDP の 2 種類の接続があります。 TCP セッションでは、固定ポートの 7000 が使用され、UPD 発信元ポートには、常時、7001 が使用されます。 UDP ストリームでは、制御接続を介して、クライアントが提供する宛先ポートが使用されます。

PIX Firewall は、VDO Live TCP 制御セッションを監視し、応答型の UDP ポート経由によるクライアントとの通信を、発信元ポート 7001 上で VDO ライブ サーバ システムだけに許可します。 その間、TCP チャネルはアクティブである必要があります。一方の接続がダウン状態になると、PIX Firewall は、他方の接続を切断します。

PIX Firewall は、制御チャネルでネゴシエートされたポートを開くことによって、データ チャネルを迂回します。アプリケーション検査は、制御チャネルをスキャンし、ネゴシエートされたポートを開きます。

NAT が使用されている場合、ネゴシエートされた IP アドレスおよびポート番号が NAT 変換されます。つまり、ペイロードの修正が必要になります。

データベースとディレクトリのサポート

ここでは、データベースまたはディレクトリ サービスに対するアクセスを PIX Firewall 経由で許可する方法について説明します。次の項目について説明します。

「ILS と LDAP」

「ネットワーク ファイル システムと Sun RPC」

「Oracle SQL*Net (V1/V2)」

ILS と LDAP

Internet Locator Service (ILS)は、Lightweight Directory Access Protocol (LDAP; ライトウェイト ディレクトリ アクセス プロトコル)に基づき、LDAPv2 に準拠します。ILS は、NetMeeting、SiteServer、および Active Directory の各製品と使用するために、Microsoft 社によって独自に開発されたものです。

fixup コマンドを使用すると、ILS に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

[no] fixup protocol ils [port[-port]]
 

デフォルト ポート割り当てを 389 から変更するには、 port オプションを使用します。 一定範囲のポート番号に ILS 検査を適用するには、- port オプションを使用します。

ILS 検査の設定を表示するには、次のコマンドを入力します。

show fixup [protocol ils]
 

PIX Firewall Version 6.2 において、ILS の NAT サポートが導入されました。このサポートは、ILS または SiteServer Directory にエンドポイントを登録し、特定するために使用されます。LDAP データベースには、IP アドレスしか格納されていないため、PAT はサポートできません。

検索応答の場合、LDAP サーバが外部に位置するときは、外部 LDAP サーバに登録される一方で、内部ピアに対するローカル通信を許可するように、NAT の設定を考慮する必要があります。このような検索応答の場合、xlates が最初に検索され、次に、正しいアドレスを取得するために DNAT エントリが検索されます。両方の検索が失敗すると、アドレスは変更されません。NAT 0 (NAT なし)を使用し、DNAT のインタラクションを要求していないサイトに対しては、性能を向上させるため、フィックスアップをオフにすることを推奨します。

ILS サーバが、PIX Firewall 境界の内部に位置する場合は、追加設定が必要になることがあります。この設定では、通常 TCP 389 などの指定されたポート上にある LDAP サーバに外部クライアントがアクセスするためのホールが必要になります。

ILS/LDAP は、セッションが 1 つの TCP 接続を介して処理される、クライアント/サーバ モデルに従います。クライアントのアクションに応じて、上記のセッションが複数作成される場合があります。

接続ネゴシエーションの間、BIND PDU が、クライアントからサーバに送信されます。サーバからの BIND RESPONSE の受信が成功すると、その他の操作メッセージ(ADD、DEL、SEARCH、または MODIFY)が交換され、ILS Directory 上の操作が実行されます。ADD REQUEST および SEARCH RESPONSE PDU には、NetMeeting セッションを確立するために H.323 (SETUP メッセージと CONNECT メッセージ)によって使用される、NetMeeting ピアの IP アドレスが含まれる場合があります。ILS サポートは、Microsoft NetMeeting v2.X と v3.X で提供されています。

ILS 検査では、次の操作が実行されます。

BER 復号化機能による LDAP REQUEST/RESPONSE PDU の復号化

LDAP パケットの構文分析

IP アドレスの抽出

必要に応じた IP アドレスの変換

BER 符号化機能による変換後のアドレスによる PDU の符号化

新しく符号化された PDU を TCP パケットにコピーして戻す

増分 TCP チェックサムおよびシーケンス番号調節の実行

ILS 検査には、次の制限があります。

参照要求と応答はサポートされていない

複数のディレクトリ内のユーザを一元管理できない

複数のディレクトリ内に複数の識別情報をもつ単一ユーザを NAT で認識できない

ネットワーク ファイル システムと Sun RPC

Sun Remote Procedure Call (RPC)に対するポート割り当ては変更できません。Sun RPC は、NFS と Network Information Service (NIS; ネットワーク情報サービス)によって使用されます。

Sun RPC サービスは、システムの任意のポート上で実行できます。サーバ上の RPC サービスにアクセスしようとするクライアントは、そのサービスが実行されているポートを検出する必要があります。これは、予約済みポート 111 上で、ポートマッパ プロセスを照会して実行されます。

クライアントは、サービスの RPC プログラム番号を送信し、ポート番号を取得します。この時点から、クライアント プログラムは、取得した新しいポートに対してその RPC クエリーを送信します。

内部から外部に送信されるフレームだけが、検査されます(たとえば、内部サーバの 1 つで動作しているポートマッパ サービスが応答を送信した場合など)。ファイアウォール内部の(内部インターフェイス上の)サーバが、応答を送出する場合、PIX Firewall は、そのパケットを代行受信して、そのポート上で初期 TCP 接続と UDP 接続の両方を開きます。

RPC ペイロード情報の NAT または PAT はサポートされていません。

次に、図 5-3に示すネットワークに対して、NFS を実装する方法を具体的に示します。次のコマンドは、必要なファイアウォールの基本設定に追加して使用します。


ステップ 1 static コマンドのアクセス可能性は、 sunrpc リテラルを使用して、ポート 111 上で UDP ポートマッパを経由する Sun RPC を許可にすることによって調整します。

access-list acl_out permit udp host 209.165.201.2 host 209.165.201.11 eq sunrpc
 

詳細については、UNIX /etc/rpc ファイルおよび UNIX rpc(3N) コマンドのページを参照してください。

RPC 用の access-list コマンド文を作成すると、外部ホスト 209.165.201.2 から次のコマンドを使用して、RPC 150001 上の PCNFSD のアクティビティを追跡できます。

rpcinfo -u 209.165.201.11 150001
 

また、RPC の別の使用方法として、外部ネットワークから内部ネットワークへの NFS のマウントを許可する場合に、次のコマンドで、209.165.201.11 のエクスポートを表示することもできます。

showmount -e 209.165.201.11
 

NFS と同様に、RPC に基づくプロトコルの多くは安全ではないので、慎重に使用する必要があります。RPC へのアクセスを許可する前に、セキュリティ ポリシーを十分に検討してください。

ステップ 2 NFS アクセスを許可します。

access-list acl_out permit udp host 209.165.201.2 host 209.165.201.11 eq 2049
 

NFS アクセスは、ポート 2049 で実行され、ホスト 209.165.201.2 が、グローバル アドレス 209.165.201.11 を介して 10.1.1.11 をマウントできるように、外部と内部との間のアクセスを実現します。


 

図 5-3に示したネットワークのサービスへのアクセスを設定するコマンド リストを、例5-2に示します。

例5-2 NFS アクセスの設定

 

access-list acl_out permit udp host 209.165.201.2 host 209.165.201.11 eq sunrpc
access-list acl_out permit udp host 209.165.201.2 host 209.165.201.11 eq 2049
 

Oracle SQL*Net (V1/V2)

SQL*Net プロトコルは PIX Firewall が処理するさまざまなパケット タイプで構成され、ファイアウォールの両方の側にある Oracle アプリケーションに対してデータ ストリームに矛盾がないようにします。 fixup コマンドを使用して、Oracle SQL*Net に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

fixup protocol sqlnet [port[-port]]
 

デフォルト ポート割り当てを 1521 から変更するには、 port オプションを使用します。 この値は、SQL*Net に対して Oracle が使用する値ですが、Structured Query Language (SQL)に対する IANA ポート割り当てには適合しません。一定範囲のポート番号に SQL*Net 検査を適用するには、- port オプションを使用します。

PIX Firewall は、すべてのアドレスを NAT 処理して、すべての埋め込みポートを検出し、SQL*Net Version 1 に対して開きます。

SQL*Net Version 2 の場合、データ長がゼロの REDIRECT パケットの直後に続く DATA パケットまたは REDIRECT パケットは、すべて修正されます。

フィックスアップの必要なパケットには、次の形式の埋め込みホスト/ポート アドレスが含まれます。

(ADDRESS=(PROTOCOL=tcp)(DEV=6)(HOST=a.b.c.d)(PORT=a))
 

SQL*Net Version 2 の TNSFrame タイプ(Connect、Accept、Refuse、Resend、および Marker)については、NAT 処理対象のアドレスを検出するスキャンは行われません。また、検査プロセスも、パケット内の埋め込みポートに対して、ダイナミック接続を開きません。

SQL*Net Version 2 の TNSFrames、Redirect、および Data の各パケットの前に、ペイロードのデータ長がゼロの REDIRECT TNSFrame タイプがある場合、これらのパケットは開くポートおよび NAT 処理対象のアドレスの検出のためスキャンされます。データ長がゼロの Redirect メッセージが PIX Firewall を通過するときは、接続データ構造体内にフラグがセットされ、後続の Data メッセージまたは Redirect メッセージについては NAT 処理され、ポートについてはダイナミックに開かれることが要求されます。先行パラグラフ内の TNS フレームの 1 つが、Redirect メッセージの後に到着すると、フラグはリセットされます。

SQL*Net fixup は、チェックサムを再計算し、IP と TCP 長を変更し、新旧メッセージ長の差分を使用して、シーケンス番号と肯定応答番号を再調節します。

その他の場合では、SQL*Net Version 1 を前提としています。TNSFrame タイプ(Connect、Accept、Refuse、Resend、Marker、Redirect、および Data)およびすべてのパケットのポートとアドレスがスキャンされます。アドレスは NAT 処理され、ポート接続は開かれます。

管理プロトコル

ここでは、問題の解決のために、PIX Firewall が管理プロトコルをサポートする方法について説明します。次の項目について説明します。

「インターネット制御メッセージ プロトコル(ICMP)」

「Remote Shell」

「X Display Manager Control Protocol(XDMCP)」

インターネット制御メッセージ プロトコル(ICMP)

ICMP ペイロードは、元のパケットから 5 つのタプルを取得するためにスキャンされます。 ICMP 検査は、1 対 1 NAT と PAT の両方をサポートします。取得された 5 つのタプルを使用して、クライアントの元のアドレスを決定するため、ルックアップが実行されます。ICMP 検査は、ICMP パケットに対して、次の変更を行います。

IP ヘッダーで、NAT IP が、Client IP (Destination Address)に変更され、IP チェックサムが修正されます。

ICMP ヘッダーで、ICMP パケットの変更に従って、ICMP チェックサムが修正されます。

ペイロードでは、次の変更が行われます。

元のパケットの NAT IP が、Client IP に変更される

元のパケットの NAT ポート が、Client Port に変更される

元のパケットの IP チェックサムが更新される

Remote Shell

fixup コマンドを使用して、Remote Shell プロトコル(RSH; リモート シェル プロトコル)に対するデフォルトのポート割り当てを変更できます。コマンドの構文は次のとおりです。

fixup protocol rsh [514]
 

RSH プロトコルは、TCP ポート 514 上で、RSH クライアントから RSH サーバへの接続に TCP 接続を使用します。 クライアントとサーバ間では、クライアントが STDERR 出力ストリームを受信する TCP ポート番号をネゴシエートします。RSH 検査は、必要であれば、ネゴシエートされたポート番号に対する NAT をサポートします。

X Display Manager Control Protocol(XDMCP)

XDMCP に対するポート割り当ては設定できません。XDMCP は、X セッションをネゴシエートするために UDP ポート 177 を使用し、セッションが確立されると TCP を使用します。

ネゴシエーションの目的で、および Xwindows セッションの開始時に、PIX Firewall は、TCP バック接続を許可する必要があります。XDMCP がセッションをネゴシエートすると、1 つの初期接続が、初期 TCP 接続を処理するために作成されます。その後、確立されたルールが参照されます。

X Windows セッションの間、マネージャーは予約済みポート 6000 + n 上にあるディスプレイの Xserver と会話します。 各ディスプレイは、次の端末設定の結果として、Xserver とは別個の接続を持ちます。

setenv DISPLAY Xserver:n
 

n はディスプレイ番号です。

XDMCP の使用時には、ディスプレイは、PIX Firewall が必要に応じて NAT 処理できる IP アドレスを使用してネゴシエートします。XDCMP 検査は、PAT をサポートしません。