JP2005215935A - ファイアウォール - Google Patents

Abstract

【課題】 SIP/SDPに対応し、SDP記述の中身を精査して通信の許可・拒否を自動的に決定するファイアウォールまたは同等の機能を提供する。
【解決手段】 送信されたIPパケットからINVITEメソッドを検出するINVITEメソッド検出手段と、受信したIPパケットのIPヘッダから送信元アドレスと送信先アドレスを取得するとともに、IPパケットのSIPヘッダからコールIDを取得し、取得した送信元アドレスと送信先アドレスおよびコールIDをテーブルに記録するアドレスおよびID記録手段と、送信先から送信されたINVITEメソッドに応答して受信側から送信された応答コードに含まれるSDP記述から以後の通信で使用するポート番号を取得するとともに、取得したポート番号をテーブルに記録するポート番号記録手段とを備えて、取得した送信元アドレスと送信先アドレスで、取得したポート番号のみの通信を許可するようにしている。
【選択図】 図１

Description

本発明は設定されたルールに合致しない通信を遮断するファイアウォールに係り、特に、ＩＰ（Internet Protocol）ネットワーク上で送信クライアント（送信側通信機器）と受信クライアント（受信側通信機器）がＳＩＰ（Session Initiation Protocol）によりセッションを確立するとともに、ＳＤＰ（Session Description Protocol）により通信を行うようにした通信システムに用いられるファイアウォールに関するものである。

インターネットの急速の普及に伴って、コンピュータなどの端末やＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）のサーバなどを公衆網に接続する機会が増加した。このような背景から、公衆網側からの不正なアクセスから端末やサーバを守る技術が重要となり、特定種類のトラフィックを遮断する機能が必要となった。このため、この特定種類のトラフィックを遮断することによって、端末やサーバのセキュリティを向上させるファイアウォールが用いられるようになった。この種のファイアウォールにおいては、基本的には、通信の遮断はポート番号やネットワークトポロジーで判断されるため、動的にポート番号が変更されるような通信をファイアウォールでどのように扱うかは従来より問題となっていた。

そこで、特許文献１において、以下のようなファイアウォールが提案されるようになった。例えば、ＦＴＰファイル伝送におけるデータコネクションの確立を行なう場合、ＦＴＰクライアントは、データコネクション用ポートがオペレーティングシステムから割当てられると、そのポート番号をＦＴＰサーバに通知する前に、そのポートに対し外部ネットワークからのアクセスを許可するようにファイアウォールに通知しておき、そのポートでＦＴＰサーバからのコネクション確立要求を待つ。

ＦＴＰクライアントからの通知を受けたファイアウォールは、そのポート番号をテーブル登録等しておき、そのポートでのＦＴＰサーバからのコネクション確立要求を通し、ＦＴＰクライアントとＦＴＰサーバ間でのデータコネクションの確立を行う。
また、確立したデータコネクションを開放した場合、ＦＴＰクライアントは、そのポートに対し外部ネットワークからのアクセスを許可しないようにファイアウォールに通知し、以降の当該ポートでのアクセスを拒否させる。
特開２０００−３４９８２１号公報

ところで、近年、ＩＰネットワーク上で音声や画像などのマルチメディアセッションを確立・変更・終了させるためのプロトコルとしてＩＥＴＦ（Internet Engineering Task Force；インターネット国際技術標準化団体）によりＲＦＣ（Requests For Comment）３２６１として規定されているＳＩＰ（Session Initiation Protocol）が注目されるようになった。このようなＳＩＰにおいて、メディア情報の記述にＲＦＣ２３２７あるいはＲＦＣ３２６４として規定されているＳＤＰ（Session Description Protocol）が使用される。

しかしながら、ＳＩＰ／ＳＤＰにおいては、ＳＤＰによって通達される後続の通信をファイアウォールに許可させるためには、予めＳＤＰがどの通信を通達するかを調査、計画し、ファイアウォールにルールとして設定する以外にはないという問題があった。例えば、ＵＤＰ（User Datagram Protocol：ＴＣＰ／ＩＰプロトコルにおけるトランスポート層のプロトコル）５００４番、ＵＤＰ５００５番を用いる音声転送プロトコルをファイアウォールを越えて利用したい場合、ＵＤＰ５００４番、ＵＤＰ５００５番の通信を許可するようにファイアウォールを設定しなければならない。また、ファイアウォールに設定されない通信は、ＳＤＰに記述してもファイアウォールに遮断されて、通信が行えないようになされている。

このため、後日、ＵＤＰ３２６７８番を用いる映像転送プロトコルを使ったアプリケーションを追加した場合、これもファイアウォールの設定に追加しなければならない。さらに、ＵＤＰ１０２４番以降の全てのポートを用いる可能性があり、実際に通信が開始されるまでどのポートを用いるか分からないようなマルチメディア通信プロトコルを利用する場合は、ＵＤＰ１０２４番以降の全てのポートを許可するようにファイアウォールに設定しなければならず、セキュリティ上、大いに問題がある設定となる。

このため、セッションの確立時にその後の通信内容を自由に設定できるというＳＩＰ／ＳＤＰの本来の性能を発揮することができず、ファイアウォールによる防御が一般的となっている現在のインターネット社会において、実質上ＳＩＰ／ＳＤＰを活用することは困難であった。

そこで、本発明は上記のような問題点を解決するためになされたものであって、ＳＩＰ（Session Initiation Protocol）／ＳＤＰ（Session Description Protocol）に対応し、ＳＤＰ記述の中身を精査して通信の許可・拒否を自動的に決定するファイアウォールまたは同等の機能を提供することを目的とする。

上記目的を達成するため、本発明のファイアウォールは、送信クライアント（送信側（送信元）通信機器）から送信されたＩＰパケットを受信し、受信したＩＰパケットからＩＮＶＩＴＥメソッドを検出するＩＮＶＩＴＥメソッド検出手段と、受信したＩＰパケットのＩＰヘッダから送信元アドレス（Ｓｒｃ（Ｓｏｕｒｃｅ）アドレス）と送信先アドレス（Ｄｓｔ（Ｄｅｓｔｉｎａｔｉｏｎ）アドレス）を取得するとともに、ＩＰパケットのＳＩＰヘッダからコールＩＤ（ｃａｌｌ−ＩＤ）を取得し、取得した送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）およびコールＩＤ（ｃａｌｌ−ＩＤ）をテーブルに記録するアドレスおよびＩＤ記録手段と、送信クライアント（送信側（送信元）通信機器）から送信されたＩＮＶＩＴＥメソッドに応答して受信クライアント（受信側（送信先）通信機器）から送信された応答コードに含まれるＳＤＰ記述から以後の通信で使用するポート番号を取得するとともに、取得したポート番号を送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）およびコールＩＤ（ｃａｌｌ−ＩＤ）に関連づけてテーブルに記録するポート番号記録手段とを備え、テーブルに記録された送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）で、当該テーブルに送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）に関連づけて記録されたポート番号に一致する通信のみを許可するようにしたことを特徴とする。

このように、取得したポート番号を送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）およびコールＩＤ（ｃａｌｌ−ＩＤ）に関連づけてテーブルに記録するようにすると、取得した送信元アドレス（Ｓｒｃアドレス）と送信先アドレス（Ｄｓｔアドレス）で、取得したポート番号のみの通信を許可することができるようになる。

この場合、ＩＮＶＩＴＥメソッドに対する最終確認のために送信クライアントから送信されたＡＣＫメソッドの通信内のＳＤＰ記述にポート番号が記述されている場合は、当該ＡＣＫメソッドの通信内のポート番号を新たに取得するとともに、テーブルに記録されたポート番号を新たに取得したポート番号に書き換えるようにするのが望ましい。
また、通信が許可された状態において、送信クライアントあるいは受信クライアントのどちらかより再ＩＮＶＩＴＥメソッドが送信された場合、当該再ＩＮＶＩＴＥメソッドに応答して送信された応答コードに含まれるＳＤＰ記述から以後の通信で使用するポート番号を取得するとともに、取得したポート番号をテーブルに記録するようにするのが望ましい。

本発明のようなファイアウォールを導入することにより、不必要な通信を許可することなく、安全にＳＩＰ通信を行うことができる。また、ＳＩＰによって開始されるメディア通信をあらかじめ計画してファイアウォールで手動許可する必要がなくなり、手間が省けると同時に、ＳＩＰ本来の自由度の高い通信を実現することができる。

ついで、本発明の一実施の形態を図１〜図４に基づいて説明するが、本発明はこの実施の形態に何ら限定されるものでなく、本発明の目的を変更しない範囲で適宜変更して実施することが可能である。なお、図１は本発明を実施するネットワークシステムの構成を模式的に示すブロック図である。また、図２はファイアウォールを介して送信クライアント（送信側（送信元）通信機器）と受信クライアント（受信側（送信先）通信機器）が通信する様子を示すシーケンス図である。また、図３は図１および図２に示されたファイアウォールの動作を示すフローチャートである。さらに、図４はセッション管理テーブルの一例を示すセッション管理テーブルである。

本発明を実施するネットワークシステム１０は、図１に示すように、ＳＩＰ（Session Initiation Protocol）送信クライアント（送信側（送信元）通信機器）１１と、ＩＰ（Internet Protocol）ネットワーク１２と、ＳＩＰ受信クライアント（受信側（送信先）通信機器）１３とで構成される。そして、ＳＩＰ受信クライアント１３はファイアウォール１４を介してＩＰネットワーク１２に接続される構成となっている。また、ＳＩＰ送信クライアント１１とＳＩＰ受信クライアント１３は、それぞれＩＰ電話をはじめとする携帯端末（携帯電話、ＰＤＰなど）や情報家電などのＳＩＰ（Session Initiation Protocol）が組み込まれた機器である。

ここで、ファイアウォール１４は、例えば、中央処理装置（Central Processing Unit：ＣＰＵ）と、ＲＯＭ（Read Only Memory）／ＲＡＭ（Random Access Memory）よりなるメモリと、信号処理部とを備えたコンピュータやルータや通信機器などからなる。そして、ＲＯＭ／ＲＡＭよりなるメモリにおいて、ＲＯＭにはＣＰＵが実行するファイアウォール機能プログラムが格納されており、ＣＰＵがファイアウォールのためのプログラムを実行することによりファイアウォール機能を実行されることとなる。また、ＲＡＭには各種のテーブルを格納するためのエリアが設定されている。

ついで、上述のファイアウォール１４の動作（ファイアウォール機能を実行するためのＣＰＵの動作を意味するが、ここでは単に、ファイアウォール１４という）を、図２のシーケンス図および図３のフローチャートに基づいて説明する。ここで、ＳＩＰ送信クライアント１１がＳＩＰ／ＳＤＰによりＳＩＰ受信クライアント１３に向けて送信（発呼）するものとする。すると、ＳＩＰ送信クライアント１１は、セッション参加リクエストを意味するＩＮＶＩＴＥメソッド（このＩＮＶＩＴＥメソッドにはＳＤＰオファーが書き込まれている）をＳＩＰ受信クライアント１３に送信する。この場合、ファイアウォール１４はＳＩＰの通過を許可（デフォルトではＴＣＰ／ＵＤＰ５０３０）するものとする。

ＳＩＰ送信クライアント１１がＩＮＶＩＴＥメソッドを送信すると、ファイアウォール１４は、このＩＮＶＩＴＥメソッドを検出（ステップＳ１０）するが、ＩＮＶＩＴＥメソッドを検出しない場合は、ＩＮＶＩＴＥメソッドを検出するまでステップＳ１０の処理を繰り返して実行する。一方、ＳＩＰ受信クライアント１３がＩＮＶＩＴＥメソッドを受信すると、ＳＩＰ受信クライアント１３はＳＩＰ送信クライアント１１に向けて、２つの暫定レスポンス（１００Ｔｒｙｉｎｇ，１８０Ｒｉｎｇｉｎｇ）に続き、最終レスポンス（２００ＯＫ：応答コード２００）を返送する。

ファイアウォール１４がＩＮＶＩＴＥメソッドを検出すると、ファイアウォール１４は、ステップＳ１２にて、受信したＩＰヘッダから「Ｓｒｃアドレス」（送信元アドレス）と「Ｄｓｔアドレス」（送信先アドレス）を取得し、受信したＳＩＰヘッダから「Ｃａｌｌ−ＩＤ」を取得して、これらのセッション（「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」）をテーブルに書き込む。ついで、ステップＳ１４に進み、ＩＮＶＩＴＥメソッドに対する応答コード２００、応答コード４００番台、応答コード５００番台、応答コード６００番台の検出を行う。

ここで、リクエストにエラーがあるため処理できなかったというクライアントエラーを意味する応答コード４００番台、サーバ側でエラーが発生したためリクエストを処理できなかったというサーバエラーを意味する応答コード５００番台、およびリクエスト処理に失敗したというグローバルエラーを意味する応答コード６００番台のいずれかを検出した場合、ステップＳ１４にて「Ｙｅｓ」と判定して、次のステップＳ１６に進める。ステップＳ１６において、ステップＳ１２にてテーブルに書き込まれた「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」などのセッションをテーブルから削除した後、このセッションを終了させる。

ＩＮＶＩＴＥメソッドに対する応答コード４００番台、応答コード５００番台、応答コード６００番台のいずれも検出しなかった場合は、ステップＳ１４にて「Ｎｏ」と判定してステップＳ１８に進め、応答コード２００（２００ＯＫ）を検出するまでこの処理を繰り返して実行する。応答コード２００を検出すると、ステップＳ１８にて「Ｙｅｓ」と判定してステップＳ２０に進める。ここで、ＩＮＶＩＴＥメソッドにＳＤＰオファが書き込まれていれば、応答コード２００の通信内にＳＤＰアンサーが書き込まれる。また、ＩＮＶＩＴＥメソッドにＳＤＰオファが書き込まれていなければ、応答コード２００の通信内にＳＤＰオファが書き込まれる。

そこで、ステップＳ２０において、応答コード２００（２００ＯＫ）の通信内のＳＤＰ記述（ＳＤＰアンサーあるいはＳＤＰオファ）を検査し、以後のメディア通信が使用するポート番号（図１に示すように、ポート番号は複数である場合もある）を取得する。ポート番号を取得すると、上述したテーブル内に書き込まれた該当セッション（「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」など）に関連づけて、これらの取得したポート番号が書き込まれることとなる。なお、応答コード２００の通信内のＳＤＰ記述にポート番号が記述されていない場合は、その後に来るＡＣＫ通信（ＡＣＫメソッド）の中からポート番号を取得する。

ここで、ＳＩＰ受信クライアント１３がＳＩＰ送信クライアント１１に応答コード２００（２００ＯＫ）を送信すると、ＳＩＰ送信クライアント１１は、ＩＮＶＩＴＥメソッドに対する最終応答の確認のためのＡＣＫメソッドをＳＩＰ受信クライアント１３に送信することとなる。これにより、ファイアウォール１４は、ステップＳ２２に進み、ＩＮＶＩＴＥメソッドに対する最終応答の確認のためのＡＣＫメソッドを検出したか否かの判定を行う。ファイアウォール１４がＡＣＫメソッドを検出すると、ステップＳ２２にて「Ｙｅｓ」と判定して、次のステップＳ２４に進める。

ファイアウォール１４がＡＣＫメソッドを検出しないと、ＡＣＫメソッドを検出するまでステップＳ２２の処理を繰り返して実行する。ここで、応答コード２００（２００ＯＫ）の通信内にＳＤＰオファが書き込まれていれば、このＡＣＫメソッドの通信内にＳＤＰアンサーが書き込まれていることとなる。ファイアウォール１４がＡＣＫメソッドを検出すると、ステップＳ２２にて「Ｙｅｓ」と判定してステップＳ２４に進める。ステップＳ２４に進むと、ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）を検査する。

ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）がある場合は、以後のメディア通信が使用するポート番号（ポート番号は複数である場合もある）を取得し、ステップＳ２４にて「Ｙｅｓ」と判定してステップＳ２６に進める。ステップＳ２６において、上述したテーブル内に書き込まれた該当セッション（「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」など）に関連づけて、これらの取得したポート番号に書き換える。ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）がない場合は、ステップＳ２４にて「Ｎｏ」と判定してステップＳ２８に進める。

ステップＳ２８において、ファイアウォール１４は、送信側（送信元）がテーブルに記録されている「Ｓｒｃアドレス」であり、受信側（送信先）がテーブルに記録されている「Ｄｓｔアドレス」であり、かつテーブルに記録されているポート番号（例えば、図１に示すように、４９１７０（ａｕｄｉｏ），５１３７２（ｖｉｄｅｏ），３２４１６（ａｐｐｒｉｃａｔｉｏｎ））に一致する通信を全て許可することとなる。これにより、メディアセッション（メディアセッション１：例えば、テレビ電話）が確立されることとなる。

このように、メディアセッション（メディアセッション１）が確立された状態（例えば、テレビ電話中)）において、ＳＩＰ送信クライアント１１あるいはＳＩＰ受信クライアント１３のどちらかより、再度のＩＮＶＩＴＥメソッド（これを再ＩＮＶＩＴＥメソッドという）が送信された場合（この場合は、ＳＩＰ送信クライアント１１からＳＩＰ受信クライアント１３に再ＩＮＶＩＴＥメソッド（例えば、ゲームをしようというリクエスト）が送信されたものとする）、ファイアウォール１４はステップＳ３０にて「Ｙｅｓ」と判定する。

この場合、再ＩＮＶＩＴＥメソッドにはＳＤＰオファが書き込まれており、「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」などは、既にテーブルに記述されたものと同一であって、変更がないものである。そして、ＳＩＰ受信クライアント１３が再ＩＮＶＩＴＥメソッドを受信すると、ＳＩＰ受信クライアント１３はＳＩＰ送信クライアント１１に向けて、応答コード２００（２００ＯＫ）を返送する。ここで、ファイアウォール１４がステップＳ３２に進めて、応答コード２００を検出できないと、ステップＳ３２にて「Ｎｏ」と判定してステップＳ２８に戻り、メディアセッション（メディアセッション１）の確立を続行する。

一方、ファイアウォール１４がステップＳ３２に進めて、応答コード２００を検出するとステップＳ３２にて「Ｙｅｓ」と判定してステップＳ２０に戻る。このステップＳ２０においては、再ＩＮＶＩＴＥメソッドにＳＤＰオファが書き込まれていれば、応答コード２００（２００ＯＫ）の通信内にＳＤＰアンサーが書き込まれているので、このＳＤＰアンサーの記述に基づいて、以後のメディア通信が使用するポート番号（この場合もポート番号は１個以上である）を取得する。ポート番号を取得すると、上述したテーブル内に書き込まれた該当セッション（「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」など）に関連づけて、これらの取得したポート番号に書き換える。

ついで、ファイアウォール１４は、ステップＳ２２に進み、再ＩＮＶＩＴＥメソッドに対する最終応答の確認のためのＡＣＫメソッドを検出したか否かの判定を行う。ファイアウォール１４がＡＣＫメソッドを検出すると、ステップＳ２２にて「Ｙｅｓ」と判定して、次のステップＳ２４に進める。ファイアウォール１４がＡＣＫメソッドを検出しないと、ＡＣＫメソッドを検出するまでステップＳ２２の処理を繰り返して実行する。ステップＳ２４に進むと、ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）を検査する。

ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）がある場合は、以後のメディア通信が使用するポート番号（ポート番号は複数である場合もある）を取得し、ステップＳ２４にて「Ｙｅｓ」と判定してステップＳ２６に進める。ステップＳ２６において、上述したテーブル内に書き込まれた該当セッション（「Ｓｒｃアドレス」、「Ｄｓｔアドレス」、「Ｃａｌｌ−ＩＤ」など）に関連づけて、これらの取得したポート番号に書き換える。ＡＣＫメソッドの通信内にＳＤＰ記述（ＳＤＰアンサー）がない場合は、ステップＳ２４にて「Ｎｏ」と判定してステップＳ２８に進める。

ステップＳ２８において、ファイアウォール１４は、送信側（送信元）がテーブルに記録されている「Ｓｒｃアドレス」であり、受信側（送信先）がテーブルに記録されている「Ｄｓｔアドレス」であり、かつテーブルに記録されているポート番号（例えば、図４の一番上の行を例にすると、Ｓｒｃアドレスが「２０３．９０．３．１１１」で、Ｄｓｔアドレスが「７８．１８．２３３．９４」で、ポート番号が「４９１７０」または「５１３７２」または「３２４１６」）に一致する通信を全て許可することとなる。これにより、メディアセッション（メディアセッション２：例えば、ゲーム）が確立される。

このように、メディアセッション（メディアセッション２）が確立された状態（例えば、ゲーム中）において、再ＩＮＶＩＴＥメソッドを検出することなく、セッションの終了を意味するＢＹＥメソッドを検出すると、ステップＳ３４にて「Ｙｅｓ」と判定してこの処理を終了する。送信元ＩＰアドレスと送信先ＩＰアドレスのどちらかより、通信中の相手方に対してＢＹＥメソッドが送信されたことを検出した場合、該当セッションが終了したものとして、それまで許可していたテーブル内の該当ポート番号の許可を終了する。

本発明を実施するネットワークシステムの構成を模式的に示すブロック図である。 ファイアウォールを介して送信クライアント（送信側通信機器）と受信クライアント（受信側通信機器）が通信する様子を示すシーケンス図である。 図１および図２に示されたファイアウォールの動作を示すフローチャートである。 セッション管理テーブルの一例を示すセッション管理テーブルである。

符号の説明

１０…ネットワークシステム、１１…ＳＩＰ送信クライアント（送信側通信機器）、１２…ＩＰ（Internet Protocol）ネットワーク、１３…ＳＩＰ受信クライアント（受信側通信機器）、１４…ファイアウォール

Claims (3)

1. ＩＰ（Internet Protocol）ネットワーク上で送信クライアントと受信クライアントがＳＩＰ（Session Initiation Protocol）によりセッションを確立するとともに、ＳＤＰ（Session Description Protocol）により通信を行うようにした通信システムに用いられるファイアウォールであって、
   前記送信クライアントから送信されたＩＰパケットを受信し、受信したＩＰパケットからＩＮＶＩＴＥメソッドを検出するＩＮＶＩＴＥメソッド検出手段と、
   前記受信したＩＰパケットのＩＰヘッダから送信元アドレスと送信先アドレスを取得するとともに、同ＩＰパケットのＳＩＰヘッダからコールＩＤを取得し、取得した前記送信元アドレスと送信先アドレスおよび前記コールＩＤをテーブルに記録するアドレスおよびＩＤ記録手段と、
   送信クライアントから送信されたＩＮＶＩＴＥメソッドに応答して受信クライアントから送信された応答コードに含まれるＳＤＰ記述から以後の通信で使用するポート番号を取得するとともに、取得したポート番号を前記送信元アドレスと送信先アドレスおよび前記コールＩＤに関連づけて前記テーブルに記録するポート番号記録手段とを備え、
   前記テーブルに記録された前記送信元アドレスと送信先アドレスで、当該テーブルに前記送信元アドレスと送信先アドレスに関連づけて記録されたポート番号に一致する通信のみを許可するようにしたことを特徴とするファイアウォール。
2. 前記ＩＮＶＩＴＥメソッドに対する最終確認のために前記送信クライアントから送信されたＡＣＫメソッドの通信内のＳＤＰ記述にポート番号が記述されている場合は、当該ＡＣＫメソッドの通信内のポート番号を新たに取得するとともに、前記テーブルに記録された前記ポート番号を新たに取得したポート番号に書き換えるようにしたことを特徴とする請求項１に記載のファイアウォール。
3. 前記通信が許可された状態において、前記送信クライアントあるいは前記受信クライアントのどちらかより再ＩＮＶＩＴＥメソッドが送信された場合、当該再ＩＮＶＩＴＥメソッドに応答して送信された応答コードに含まれるＳＤＰ記述から以後の通信で使用するポート番号を取得するとともに、取得したポート番号を前記テーブルに記録するようにしたことを特徴とする請求項１または請求項２に記載のファイアウォール。
   

Images