(57)【要約】【課題】不正アクセスを防御し、かつ、フィルタリングルールのルール数を削減して検索時間を短縮できるフィルタリングシステムを提供する。【解決手段】ＨＴＴＰ通信として定義されたポート番号を有するパケットのＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合に、ＵＲＩの解析処理を行う手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められない場合に、当該パケットを通過させる手段と、前記ＵＲＩの解析処理を行った後に、フィルタリングルールと比較する手段と、前記フィルタリングルールと比較した結果、通過と判定された場合に当該パケットを通過させ、あるいは、前記比較手段で前記フィルタリングルールと比較した結果、廃棄と判定された場合に当該パケットを廃棄させる手段とを具備する。【選択図】　　　　図１
2004145583.tif 000002
【特許請求の範囲】
【請求項１】
ＨＴＴＰ通信として定義されたポート番号を有するパケットのＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する手段と、
前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合に、ＵＲＩの解析処理を行う手段と、
前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められない場合に、当該パケットを通過させる手段と、
前記ＵＲＩの解析処理を行った後に、フィルタリングルールと比較する手段と、
前記フィルタリングルールと比較した結果、通過と判定された場合に当該パケットを通過させ、あるいは、前記比較手段で前記フィルタリングルールと比較した結果、廃棄と判定された場合に当該パケットを廃棄させる手段とを具備することを特徴とするフィルタリングシステム。
【請求項２】
ＨＴＴＰ通信として定義されたポート番号を有するパケットが、ＴＣＰボディを含まないＡＣＫパケットである場合に、当該パケットを通過させる手段と、
ＨＴＴＰ通信として定義されたポート番号を有するパケットが、ＴＣＰボディを含む場合、ＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する手段と、
前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合に、ＵＲＩの解析処理を行う手段と、
前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められない場合に、当該パケットを廃棄する手段と、
前記ＵＲＩの解析処理を行った後、フィルタリングルールと比較する手段と、
前記フィルタリングルールと比較した結果、通過と判定された場合に当該パケットを通過させ、あるいは、前記フィルタリングルールと比較した結果、廃棄と判定された場合に当該パケットを廃棄させる手段とを具備することを特徴とするフィルタリングシステム。
【請求項３】
前記リクエストラインを解析する手段は、リクエストラインがスペースによって３つの文字列に区分けられ、かつ、第３の文字列の終わりにリクエストラインの終わりを示す制御コードが付記され、かつ、第３の文字列が、「ＨＴＴＰ／」、「数字」、「．（ドット）」、「数字」により構成される場合に、リクエストライン構造と認めるとともに、第１の文字列をメソッド、第２の文字列をＵＲＩと定め、それ以外の場合はリクエストラインと認めないことを特徴とする請求項１または請求項２に記載のフィルタリングシステム。
【請求項４】
前記リクエストラインを解析する手段、または前記フィルタリングルールと比較する手段は、リクエストラインに記載されているメソッドが登録外の文字列であった場合に、当該パケットを廃棄する手段を備えることを特徴とする請求項１ないし請求項３のいずれか１項に記載のフィルタリングシステム。
【請求項５】
前記リクエストラインを解析する手段は、第１の文字列であるメソッドがＰＵＴまたはＰＯＳＴの場合、当該パケットの宛先および送信元アドレス、宛先および送信元ポート番号を保存する手段と、
これ以降に到着するパケットが前記保存した宛先および送信元アドレス、宛先および送信元ポート番号を有する場合、当該パケットを通過させる手段とを備えることを特徴とする請求項２ないし請求項４のいずれか１項に記載のフィルタリングシステム。
【請求項６】
前記ＵＲＩの解析処理を行う手段は、ＵＲＩが「／」から始まる場合に、ＵＲＩを、ａｂｓ＿ｐａｔｈと定めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【請求項７】
前記ＵＲＩの解析処理を行う手段は、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「＊」から始まる、または「＊」のみの場合に、ＵＲＩを、＊と定め、ａｂｓ＿ｐａｔｈと同様のフィルタリングルールに帰着させることを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【請求項８】
前記ＵＲＩの解析処理を行う手段は、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「ｈｔｔｐ：／／」から始まる場合に、ＵＲＩを、ａｂｓｏｌｕｔｅＵＲＩと定めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【請求項９】
前記ＵＲＩの解析処理を行う手段は、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「ｈｔｔｐ：／／」から始まらない場合に、ＵＲＩを、ａｕｔｈｏｒｉｔｙと定めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【請求項１０】
前記ＵＲＩの解析処理を行う手段は、ＵＲＩが「／」から始まる場合に、ＵＲＩを、ａｂｓ＿ｐａｔｈと定め、次に、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「＊」から始まる、または「＊」のみの場合に、ＵＲＩを、＊と定め、次に、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「ｈｔｔｐ：／／」から始まる場合に、ＵＲＩを、ａｂｓｏｌｕｔｅＵＲＩと定め、最後に、ＵＲＩが「／」から始まらない場合において、ＵＲＩが「ｈｔｔｐ：／／」から始まらない場合に、ＵＲＩを、ａｕｔｈｏｒｉｔｙと定めることにより、ａｂｓ＿ｐａｔｈ、「＊」、ａｂｓｏｌｕｔｅＵＲＩ、ａｕｔｈｏｒｉｔｙの４種類のＵＲＩを特定することを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【請求項１１】
前記ＵＲＩの解析処理を行う手段は、ａｂｓｏｌｕｔｅＵＲＩと定められたＵＲＩに対し、「ｈｔｔｐ：／／」をスキーム名と定め、「ｈｔｔｐ：／／」から最初に現れる「／」の直前までをホスト名と定め、最初に現れる「／」以降を、ａｂｓ＿ｐａｔｈと定め、ホスト名の中に「：」が現れた場合、「：」の後に続く数字列をポート番号と定めることを特徴とする請求項８に記載のフィルタリングシステム。
【請求項１２】
前記ＵＲＩの解析処理を行う手段は、ａｕｔｈｏｒｉｔｙと定められたＵＲＩの中に「：」が現れた場合、「：」の後に続く数字列をポート番号と定め、「：」より前の文字列をホスト名と定め、ａｕｔｈｏｒｉｔｙと定められたＵＲＩの中に「：」が現れない場合は、ＵＲＩをホスト名と定めることを特徴とする請求項９に記載のフィルタリングシステム。
【請求項１３】
前記フィルタリングルールと比較する手段は、前記フィルタリングルールの比較要素としてホスト名およびａｂｓ＿ｐａｔｈとを有し、
前記ＵＲＩを解析処理を行う手段によって、前記パケットから得られたホスト名またはａｂｓ＿ｐａｔｈ、またはその両方と、前記フィルタリングルールのホスト名およびａｂｓ＿ｐａｔｈとを比較することを特徴とする請求項１ないし請求項１２のいずれか１項に記載のフィルタリングシステム。
【請求項１４】
前記フィルタリングルールと比較する手段は、前記フィルタリングルールの比較要素としてメソッドを有し、
前記リクエストラインを解析する手段によって、前記パケットから得られたメソッドと、前記フィルタリングルールのメソッドとを比較することを特徴とする請求項１ないし請求項１３のいずれか１項に記載のフィルタリングシステム。
【請求項１５】
前記パケットは、ＲＴＳＰパケットであることを特徴とする請求項１ないし請求項１４のいずれか１項に記載のフィルタリングシステム。
【請求項１６】
前記パケットは、ＨＴＴＰと同じリクエストライン構造を有するパケットであることを特徴とする請求項１ないし請求項５のいずれか１項に記載のフィルタリングシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、フィルタリングシステムに係わり、特に、コンテンツを安全に配信するためのフィルタリングシステムに関する。
【０００２】
【従来の技術】
ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）を用いたコンテンツ配信において、ＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒｓ）はコンテンツを一義に特定する。したがって、従来技術のフィルタリングシステムでも、ＵＲＩを用いたフィルタリングが行われている。
以下に、従来技術のフィルタリングシステムを説明するために、ＨＴＴＰおよびＵＲＩの概要を説明する。
ＨＴＴＰは、コンテンツ取得等のリクエストを送信するクライアントと、クライアントからのリクエストに基づき、コンテンツ配信等のレスポンスを返信するサーバとの間でやり取りされるプロトコルである。
クライアントから送信されるＨＴＴＰの第１行目はリクエストラインと呼ばれ、図３に示す構造を持つ。
すなわち、メソッド、ＵＲＩ、ＨＴＴＰバージョンの３つの文字列がスペースによって区切られ、また行の最後を示すＣＲＬＦという制御コードが付加される。
【０００３】
メソッドには、例えば、ＧＥＴが上げられ、コンテンツの取得要求のために用いられる。その他にも、クライアントから情報を転送しつつ、コンテンツ取得要求を行う際に使用されるＰＯＳＴ、クライアントからコンテンツをアップロードする際に使用されるＰＵＴなど、ＨＴＴＰには計８つのメソッドが存在する。
クライアントで使用する通常のブラウザソフトにおいて使用されるのは、ＧＥＴとＰＯＳＴであり、その他のメソッドは限られた使用者によって用いられるのが通例である。
ＵＲＩには、ａｂｓ＿ｐａｔｈ、ａｂｓｏｌｕｔｅＵＲＩ、＊、ａｕｔｈｏｒｉｔｙの４つのタイプがある。ａｂｓ＿ｐａｔｈは、図３の例に示すように、パス（ディレクトリ）部分のみが記述されたものである。
ａｂｓｏｌｕｔｅＵＲＩは、図４（ａ）に示すように、スキーム名「ｈｔｔｐ：」から始まり、ホスト名、ａｂｓ＿ｐａｔｈ（パス）から構成される。
ａｂｓ−ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩの使われ方の違いは、図５（ｂ）に示すように、ａｂｓｏｌｕｔｅＵＲＩは、クライアント５０３とプロキシ５０４間で使用される。それ以外のプロキシを介さない場合のクライアント５０１とサーバ５０２間、また、プロキシを介す場合でも、プロキシ５０４とサーバ５０５間は、図５（ａ）、（ｂ）に示すように、ａｂｓ−ｐａｔｈが使用される。
【０００４】
このようにサーバ直前にフィルタリングシステムを設置する場合は、ａｂｓ＿ｐａｔｈが使用されるのが一般的である。
しかし、プロキシ５０４がサーバ５０５に向けて送出するＨＴＴＰリクエストのＵＲＩとして、ａｂｓｏｌｕｔｅＵＲＩを使用する場合もある。実際、インターネット標準ＲＦＣ２６１６にも、サーバは、ａｂｓｏｌｕｔｅＵＲＩを受信できるようにする必要があると記載されている。
このようにフィルタリングシステムは、サーバ手前に設置される場合、ａｂｓ＿ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩの両方に対するフィルタリングが必要となる。
なお、ａｂｓｏｌｕｔｅＵＲＩは、プロキシ５０４とサーバ５０５間のポート番号を特定の値に指定することが可能であり、この場合、図４（ａ）の２つ目の例に示されるように、ホスト名の後に「：」とポート番号の指定値を付与することによって表記される。
【０００５】
図４（ｂ）に示すように、＊は、メソッドＯＰＴＩＯＮＳの時に用いられ、クライアントが、サーバがどのようなメソッドをサポートするのかを確認するために用いられる。なお、＊は、プロキシを介在するしないに関係なく用いられる。
また、ａｕｔｈｏｒｉｔｙは、ＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔｓ　Ｌａｙｅｒ）によってＨＴＴＰを暗号化転送するとき、図５に示されるプロキシを介する場合のクライアント５０３とプロキシ５０４間のみにおいて、メソッドＣＯＮＮＥＣＴと共に用いられる。
例として、図４（ｃ）に示すように、ａｕｔｈｏｒｉｔｙはホスト名のみにより構成される。
なお、ａｂｓｏｌｕｔｅＵＲＩと同様に、プロキシ５０４とサーバ５０５間のポート番号を特定の値に指定することが可能であり、ホスト名の後に「：」とポート番号の指定値を付与することによって表記される。
以上のことから、フィルタリングシステムをサーバ直前に置く場合と、クライアントとプロキシ間におく場合の両方に対応するためには、上記４つのＵＲＩのタイプを全て考慮する必要がある。
【０００６】
以上の説明を踏まえ、従来技術に基づくフィルタリングシステムのアルゴリズムを図６に示す。
ＨＴＴＰ通信として定義されたポート番号を有するパケットが到着すると（ステップ６０１）、フィルタリングシステムは、当該パケットのＴＣＰボディ（ＴＣＰヘッダより後に添付されるデータ）の有無を判別し（ステップ６０２）、当該パケットがＴＣＰボディを含むか否かを判定する（ステップ６０３）。
ステップ６０３において、当該パケットがＴＣＰボディを含む場合、リクエストラインからＵＲＩを抽出する処理に移行する（ステップ６０４）。
ステップ６０３において、当該パケットがＴＣＰボディを含まない場合、これはＡＣＫパケットと呼ばれるパケットである。
ＡＣＫパケットは、ＨＴＴＰの下位レイヤに位置するＴＣＰのフロー制御を目的に生成される。
具体的に説明すると、図７に示すように、コンテンツサイズが１つのＨＴＴＰレスポンスパケットには収まらず、サーバから複数のＨＴＴＰレスポンスパケットが転送される場合において、ＴＣＰのフロー制御として、クライアントからＴＣＰパケットとしての送達確認を行うために、ＡＣＫパケットが送信される。
【０００７】
なお、このＡＣＫパケットとＨＴＴＰレスポンスパケットの比率はおよそ１：２から１：１である。
ＡＣＫパケットはＴＣＰのフロー制御に必須であるため、フィルタリングシステムにて廃棄してはならない。
したがって、ステップ６０３において、当該パケットがＴＣＰボディを含まない場合、当該パケットを通過させる（ステップ６０５）。
ＵＲＩ抽出処理（ステップ６０４）に移行したＴＣＰボディを含むパケットは、リクエストラインのメソッドの次に記述されるＵＲＩが抽出され（ステップ６０４）、ＵＲＩの抽出に成功したか否かが判定される（ステップ６０６）。
ステップ６０６において、ＵＲＩの抽出に成功した場合、抽出したＵＲＩと、フィルタリングルールに事前に設定されているＵＲＩとの比較を行い（ステップ６０８）、通過させるか否かを判定する（ステップ６０９）。
【０００８】
ステップ６０８での比較は、ＵＲＩ全体の一致、もしくは前方一致（抽出ＵＲＩの先頭からの記載文字列が、ルールに設定されるＵＲＩを含むことにより一致と判定）などにより行われる。
比較条件が合致するルールがあり、かつ該ルールに通過を許可する記載がある場合、当該パケットは、通過と判定され、フィルタリングシステムを通過し（ステップ６１０）、サーバに転送される。
また、比較条件が合致するルールがあり、かつ該ルールに通過を許可しない記載がある場合、該パケットはフィルタリングシステムにて廃棄される（ステップ６１１）。
なお、比較条件が合致するルールが無い場合は、フィルタリングシステム管理者のポリシに従い、例えば、該パケットは廃棄される（ステップ６１１）。
一方、ステップ６０６において、ＵＲＩの抽出に失敗した場合は、当該パケットを、ＨＴＴＰ通信として定義されたポート番号を有するにも関わらず、偽造ＨＴＴＰパケットとみなし、廃棄する（ステップ６０７）。
なお、平成　５年以降出願日までの出願公開公報について、所定の検索式に基づき検索したが、本願発明の先行技術となるものは検出されなかった。
【０００９】
【発明が解決しようとする課題】
前述した従来のフィルタリングシステムは、以下に説明する３つの課題がある。
第１の課題として、従来のフィルタリングシステムは、リクエストラインからＵＲＩの抽出（図６のステップ６０４）のみを行い、したがって、フィルタリングルールとの比較（図６のステップ６０８）もＵＲＩを用いるのみであった。
すなわち、メソッドに基づくフィルタリングができず、クライアントから通常のブラウザソフトを使ってコンテンツ要求を行う場合に不要となるＧＥＴやＰＯＳＴ以外のメソッドも、ＵＲＩさえ条件に合えば、フィルタリングシステムを通過しサーバにパケットが届くことになる。
これによって通常、サーバの管理者やコンテンツ配信者が使用するＰＵＴやＤＥＬＥＴＥ等のメソッドを、悪意クライアントが使用した場合にも該パケットがサーバに届くことになり、不正アクセスに繋がる可能性が生じる。
【００１０】
第２の課題として、従来のフィルタリングシステムは、ａｂｓ＿ｐａｔｈやａｂｓｏｌｕｔｅＵＲＩの区別は行わず、単なる文字列検索としてＵＲＩの比較を行う。
すなわち、フィルタリングルールに事前に設定されているＵＲＩが、ａｂｓ＿ｐａｔｈのとき、ＨＴＴＰパケットのリクエストラインから抽出されたＵＲＩが、ａｂｓｏｌｕｔｅＵＲＩだとすると、フィルタリングシステム管理者が、比較条件合致と見込んでいたにも関わらず、該当するフィルタリングルールが無いという扱いになってしまう。一方、これを回避するには、ａｂｓ＿ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩの両方をそれぞれ別ルールとして記述する方法があるが、ルール数の増大を招くとともに検索時間も増大する。
【００１１】
第３の課題は、ＨＴＴＰパケットのリクエストラインからＵＲＩの抽出が失敗した場合に、廃棄（図６のステップ６０７）が行われる動作が起因となって発生する。
サーバの管理者やコンテンツ配信者からＰＵＴを用い、１パケットで転送できない大きさのコンテンツのアップロードを行う場合、図８に示すようにコンテンツ８０１は複数のＨＴＴＰパケットにより転送される。
ただし、ＨＴＴＰヘッダが付与されるのは先頭パケット８０２のみであり、残りのパケット８０３〜パケット８０５にはＨＴＴＰヘッダが付与されない。
言い換えれば、リクエストラインも先頭パケット８０２のみに記載される。これにより、コンテンツのアップロードを行う場合、従来のフィルタリングシステムはパケット８０３〜パケット８０５に対し、ＵＲＩの抽出に失敗し、これらを廃棄する。したがって、その結果として、コンテンツのアップロードが行えないことになる。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、不正アクセスを防御し、かつ、フィルタリングルールのルール数を削減して検索時間を短縮でき、しかも、コンテンツのアップロードを正常に行うことが可能なるフィルタリングシステムを提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【００１２】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
即ち、本発明のフィルタリングシステムは、ＨＴＴＰ通信として定義されたポート番号を有するパケットのＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合に、ＵＲＩの解析処理を行う手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められない場合に、当該パケットを通過させる手段と、前記ＵＲＩの解析処理を行った後に、フィルタリングルールと比較する手段と、前記フィルタリングルールと比較した結果、通過と判定された場合に当該パケットを通過させ、あるいは、前記比較手段で前記フィルタリングルールと比較した結果、廃棄と判定された場合に当該パケットを廃棄させる手段とを具備することを特徴とする。
【００１３】
また、本発明のフィルタリングシステムは、ＨＴＴＰ通信として定義されたポート番号を有するパケットが、ＴＣＰボディを含まないＡＣＫパケットである場合に、当該パケットを通過させる手段と、ＨＴＴＰ通信として定義されたポート番号を有するパケットが、ＴＣＰボディを含む場合、ＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合に、ＵＲＩの解析処理を行う手段と、前記１行目を解析した結果、ＨＴＴＰのリクエストライン構造として認められない場合に、当該パケットを廃棄する手段と、前記ＵＲＩの解析処理を行った後、フィルタリングルールと比較する手段と、前記フィルタリングルールと比較した結果、通過と判定された場合に当該パケットを通過させ、あるいは、前記フィルタリングルールと比較した結果、廃棄と判定された場合に当該パケットを廃棄させる手段とを具備することを特徴とする。
また、本発明では、前記リクエストラインを解析する手段が、第１の文字列であるメソッドがＰＵＴまたはＰＯＳＴの場合、当該パケットの宛先および送信元アドレス、宛先および送信元ポート番号を保存する手段と、これ以降に到着するパケットが前記保存した宛先および送信元アドレス、宛先および送信元ポート番号を有する場合、当該パケットを通過させる手段とを備えることを特徴とする。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
なお、実施の形態を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
［実施の形態１］
図１は、本発明の実施の形態の１フィルタリングシステムのアルゴリズムを示すフローチャートである。
以下、図１を用いて、本実施の形態のフィルタリングシステムについて説明する。
ＨＴＴＰ通信として定義されたポート番号を有するパケットが到着すると（ステップ１０１）、フィルタリングシステムは、当該パケットのＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析し（ステップ１０２）、ＨＴＴＰのリクエストライン構造か否かの判定を行う（ステップ１０３）。
リクエストラインを解析した結果、ＨＴＴＰのリクエストライン構造として認められた場合はＵＲＩの解析処理を行う（ステップ１０４）。
ここで、ステップ１０３のＨＴＴＰのリクエストライン構造か否かの判定は、ステップ１０２でのリクエストライン解析の結果、ＴＣＰヘッダ直後の１行目が以下のように構成される場合に、リクエストライン構造として判定する。
【００１５】
（１）該１行目がスペースによって３つの文字列に区分けられる。
（２）第３の文字列の終わりにはリクエストラインの終わりを示す制御コードＣＲＬＦが付記される。
（３）第３の文字列が、「ＨＴＴＰ／」、「数字」、「．（ドット）」、「数字」により構成される。例えば、「ＨＴＴＰ／１．１」という文字列が該当する。
これにより、該１行目をリクエストライン構造と認め、第１の文字列をメソッド、第２の文字列をＵＲＩと定める。
また、上記（１）から（３）のうち当てはまらないものがあれば、リクエストラインと認めない。この場合は該パケットを通過させる（ステップ１０６）。
このステップ１０６により、前述の第３の課題を解決する。すなわち、複数のＨＴＴＰパケットの転送によりコンテンツのアップロードを行う場合、本発明のフィルタリングシステムはパケット８０３〜パケット８０５を通過させることができ、結果として、コンテンツのアップロードを正常に行える。
【００１６】
次に、ＨＴＴＰのリクエストライン構造として認められたパケットに対して行うＵＲＩの解析処理（ステップ１０４）を、図９を用いて説明する。
まず、ＵＲＩが「／」から始まるかどうかを判定する（ステップ９０２）。ＵＲＩが「／」から始まる場合、ＵＲＩを、ａｂｓ＿ｐａｔｈと判定し（ステップ９０３）、フィルタリングルールとの比較を行う（ステップ９１１）。なお、ステップ９１１におけるフィルタリングルールとの比較処理は後述する。
ＵＲＩが「／」から始まらない場合、次に、ＵＲＩが「＊」から始まる、あるいは「＊」のみかどうかを判定する（ステップ９０４）。ＵＲＩが「＊」から始まる、あるいは「＊」のみの場合、ＵＲＩを＊と判定し、ａｂｓ＿ｐａｔｈと同様のフィルタリングルールとの比較に帰着させる（ステップ９０５）。
ＵＲＩが「＊」から始まる、あるいは「＊」のみのどちらでもない場合、次に、ＵＲＩが「ｈｔｔｐ：／／」から始まるかどうかを判定する（ステップ９０６）。ＵＲＩが「ｈｔｔｐ：／／」から始まる場合、ＵＲＩをａｂｓｏｌｕｔｅＵＲＩと判定し（ステップ９０７）、フィルタリングルールとの比較を行う（ステップ９１２）。なお、ステップ９１２におけるフィルタリングルールとの比較処理は後述する。
【００１７】
ここで、ａｂｓｏｌｕｔｅＵＲＩと判定されたＵＲＩに対し、「ｈｔｔｐ：／／」をスキーム名、「ｈｔｔｐ：／／」から最初に現れる「／」の直前までをホスト名、最初に現れる「／」以降をａｂｓ＿ｐａｔｈと定める。また、ホスト名の中に「：」が現れた場合、「：」の後に続く数字列をポート番号と定める（ステップ９０８）。
ＵＲＩが「ｈｔｔｐ：／／」から始まらない場合、ＵＲＩをａｕｔｈｏｒｉｔｙと判定し（ステップ９０９）、フィルタリングルールとの比較を行う（ステップ９１３）。なお、ステップ９１３におけるフィルタリングルールとの比較処理は後述する。
ここで、ａｕｔｈｏｒｉｔｙと判定されたＵＲＩの中に「：」が現れた場合、「：」の後に続く数字列をポート番号と定め、「：」より前の文字列をホスト名と定める。また、ａｕｔｈｏｒｉｔｙと定められたＵＲＩの中に「：」が現れない場合は、ＵＲＩをホスト名と定める（ステップ９１０）。
以上のＵＲＩの解析処理１０４により、ＵＲＩを、ａｂｓ＿ｐａｔｈ、ａｂｓｏｌｕｔｅＵＲＩ、＊、ａｕｔｈｏｒｉｔｙの４つのタイプに分別することができる。
なお、図９を用いて説明した順番で処理を行うことにより、サーバ直前にフィルタリングシステムを設置する場合に、出現頻度の高いａｂｓ＿ｐａｔｈを先に処理することができ、処理ステップの削減に寄与することを追記する。
【００１８】
以上のＵＲＩの解析処理（ステップ１０４）を行った後、パケットから得られたメソッドおよびＵＲＩと、フィルタリングルールとを比較し（ステップ１０７）、当該パケットを通過させるか否かを判定する（ステップ１０８）。
フィルタリングルールに記載される比較要素として、ＵＲＩ（ホスト名およびａｂｓ＿ｐａｔｈ）およびメソッドがあり、フィルタリングルールは、例えば、図１０に示すような構成からなる。
図１０のフィルタリングルールは、図１１の構成に基づき作成されている。
すなわち、図１０のフィルタリングルールのルール１、およびルール２は、クライアント１１０１が、プロキシを介さずにサーバ１１０５に接続する際のルールを定めたものである。
また、図１０のフィルタリングルールのルール３、およびルール４は、サーバ管理者ｌ１０３が、プロキシを介さずにサーバ１１０５に接続する際のルールを定めたものである。
さらに、図１０のフィルタリングルールのルール５、およびルール６は、クライアント１１０２が、プロキシ１１０６を介しサーバ１１０７に接続する際のルールを定めたものである。
図１０のユーザ欄の各ユーザの識別は、例えば、クライアント１１０１、クライアント１１０２およびサーバ管理者１１０３の各ＩＰアドレスにより実施できる。
【００１９】
プロキシを介さないクライアント１１０１からのコンテンツ要求を想定する場合、ルール番号１やルール２に記載したように、ａｂｓ＿ｐａｔｈ欄のみに比較すべきａｂｓ＿ｐａｔｈ全体、あるいは前方からの一部を記載する。また、メソッドについてもＧＥＴおよびＰＵＴのみを記載する。
図１０の例では、ルール１の検索条件と一致したものは「通過」、ルール２の検索条件と一致したものは「廃棄」と動作欄に記述している。
実際、ＵＲＩの解析処理（ステップ１０４）を行った後、パケットから、ＵＲＩとして、ａｂｓ＿ｐａｔｈ「／ｅｘａｍｐｌｅ１／ｉｎｄｅｘ．ｈｔｍｌ」、メソッドとしてＧＥＴが抽出された場合、ルール１と検索条件が一致し、該パケットはフィルタリングシステムを通過することができる（ステップ９１１、ステップ１０８、ステップ１０９）。
また、パケットから、ＵＲＩとして、ａｂｓ＿ｐａｔｈ「／ｅｘａｍｐｌｅ２／ｃｏｎｔｅｎｔ２．ｈｔｍｌ」、メソッドとしてＧＥＴが抽出された場合、ルール２と検索条件が一致し、該パケットは、フィルタリングシステムにて廃棄される（ステップ９１１、ステップ１０８、ステップ１１０）。
【００２０】
ここでもし、パケットから、ＵＲＩとして、ａｂｓ＿ｐａｔｈ「／ｅｘａｍｐｌｅ１／ｉｎｄｅｘ．ｈｔｍｌ」が抽出されるものの、メソッドとしてＰＵＴが抽出された場合、ルール１と一致すると見なされず、また、他の全てのルールと一致しないと判定され（ルールＮが適用される）、該パケットは廃棄される（ステップ９１１、ステップ１０８、ステップ１１０）。
すなわち、本手段により、第１の課題を解決し、ＰＵＴやＤＥＬＥＴＥ等のメソッドを、悪意クライアントが使用した場合などの不正アクセスをサーバ手前のフィルタリングシステムにて排除することができる。
また、フィルタリングシステムは、プロキシを介さないクライアント１１０１からのコンテンツ要求を想定し、ルール１、およびルール２を作成したものの、実際のパケットがＵＲＩとして、ａｂｓｏｌｕｔｅＵＲＩ「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ／ｅｘａｍｐｌｅ１／ｉｎｄｅｘ．ｈｔｍｌ」、メソッドとしてＧＥＴを有する場合について言及する。
この場合、該パケットのＵＲＩは、図９のＵＲＩの解析処理により、ａｂｓｏｌｕｔｅＵＲＩと判定され（ステップ９０７）、「スキーム名，ホスト名，ポート番号，ａｂｓ＿ｐａｔｈの分離」（ステップ９０８）を通じ、ホスト名として「ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ」、ａｂｓ＿ｐａｔｈとして「／ｅｘａｍｐｌｅ１／ｉｎｄｅｘ．ｈｔｍｌ」、メソッドとしてＧＥＴが抽出される。
【００２１】
ルール１は、ＨＯＳＴ名を無記名（任意）、ａｂｓ＿ｐａｔｈは「／ｅｘａｍｐｌｅ１／ｉｎｄｅｘ．ｈｔｍｌ」、メソッドはＧＥＴあるいはＰＵＴである場合に、検索条件が一致とみなすがため、該パケットは、ルール１と検索条件が一致することになり、該パケットはフィルタリングシステムを通過することができる（ステップ９１２、ステップ１０８、ステップ１０９）。
すなわち、ホスト名と、ａｂｓ＿ｐａｔｈを分離し、それぞれに対し比較を行う本手段は、第２の課題を解決し、パケットに記載されるＵＲＩが、ａｂｓ−ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩのいずれの場合にも、１つのルールにて対応することができる。
次に、サーバ管理者１１０３については、サーバ１１０５の「／ｅｘａｍｐｌｅ１／」ディレクトリに、コンテンツのアップロードが行えるように、図１０のルール３のメソッド欄にＰＵＴを許可している。
また、ルール４には、＊をａｂｓ＿ｐａｔｈ欄、ＯＰＴＩＯＮＳをメソッドに記述させることにより、サーバ管理者１１０３がサーバ１１０５のサポートメソッドを確認できるようにしている。
実際、前述のステップ９０５の処理のように、フィルタリングルールパケットから抽出されたＵＲＩが「＊」から始まる、あるいは「＊」のみの場合に、ａｂｓ＿ｐａｔｈに帰着させることにより、ＵＲＩが「＊」から始まる、あるいは「＊」のみの場合に対するフィルタリングも、ａｂｓ＿ｐａｔｈと同様の処理で実行できる（ステップ９１１）。
【００２２】
最後に、クライアント１１０２については、サーバ１１０７に接続するにはプロキシ１１０６を介し、かつ、フィルタリングシステム１１０４がサーバ１１０７とプロキシ１１０６との間に位置するため、ａｂｓｏｌｕｔｅＵＲＩを想定し、ルール５において、ＨＯＳＴ名に「ｗｗｗ．ｅｘａｍｐｌｅ３．ｃｏｍ」を、ａｂｓ＿ｐａｔｈに「／ｅｘａｍｐｌｅ３／ｃｏｎｔｅｎｔ３．ｈｔｍｌ」を記載している。
また、ＳＳＬによるＨＴＴＰの暗号化転送に対するフィルタリングも行うため、ルール６において、ＨＯＳＴ名に「ｗｗｗ．ｅｘａｍｐｌｅ３．ｃｏｍ」を、メソッドにＣＯＮＮＥＣＴを記載している。
これにより、実際のパケットにおいて、ＵＲＩとして、ａｕｔｈｏｒｉｔｙ「ｗｗｗ．ｅｘａｍｐｌｅ３．ｃｏｍ：４４３」を有していた場合、図９のＵＲＩの解析処理により、ａｕｔｈｏｒｉｔｙと判定され（ステップ９０９）、「ホスト名とポート番号の分離」（ステップ９１０）を通じ、ホスト名として「ｗｗｗ．ｅｘａｍｐｌｅ３．ｃｏｍ」が抽出される。
これにより、フィルタリングシステムは、ルール６を検索条件として一致させることができ、該パケットはフィルタリングシステムを通過することができる（ステップ９１３、ステップ１０８、ステップ１０９）。
ここで、パケットから抽出したメソッドが、フィルタリングシステムに登録されていないメソッドであった場合に、リクエストライン解析処理（ステップ１０２）、あるいはフィルタリングルールとの比較処理（ステップ１０７）において該パケットを廃棄することを行ってもよいことを追記する。
【００２３】
［実施の形態２］
図２は、本発明の実施の形態の２フィルタリングシステムのアルゴリズムを示すフローチャートである。
以下、図２を用いて、本実施の形態のフィルタリングシステムについて説明する。
ＨＴＴＰ通信として定義されたポート番号を有するパケットが到着すると（ステップ２０１）、フィルタリングシステムは従来技術と同様、当該パケットのＴＣＰボディ（ＴＣＰヘッダより後に添付されるデータ）の有無を判別し（ステップ２０２）、当該パケットがＴＣＰボディを含むか否かを判定する（ステップ２０３）。
ステップ２０３において、当該パケットがＴＣＰボディを含むと判定された場合、フィルタリングシステムは、当該パケットのＴＣＰヘッダ直後の１行目に記述されるリクエストラインを解析する処理に移行し（ステップ２０５）、リクエストライン構造か否かを判定する（ステップ２０７）。
ステップ２０３において、当該パケットがＴＣＰボディを含まないと判定された場合は、これも従来技術と同様に該パケットを通過させる（ステップ２０６）。
【００２４】
ここで、ステップ２０２、ステップ２０３における、ＴＣＰボディの有無の判定方法は、例えば、以下の方法で行うことができる。
図１２に示すように、ＨＴＴＰの下位レイヤにはＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）があり、ＩＰヘッダ内にヘッダ長を示すＩＨＬ（▲１▼）、およびＩＰパケットの全長を示すＴｏｔａｌ　Ｌｅｎｇｔｈ（▲２▼）、ＴＣＰヘッダ内にはＴＣＰヘッダ長を示すデータオフセット（▲３▼）がある。
これにより計算式「▲２▼−（▲１▼＋▲３▼）×４」が０のとき、ＴＣＰボディ無しとみなせる。
リクエストライン解析（ステップ２０５）に移行したＴＣＰボディを含むパケットは、ＨＴＴＰのリクエストライン構造として認められた場合、ＵＲＩの解析処理を行う（ステップ２０８）。
ここでリクエストライン解析（ステップ２０５）は、前述の第１のアルゴリズムと同様の処理により、リクエストライン構造を認識し、メソッドおよびＵＲＩを抽出する。
一方、リクエストラインと認められない場合は、従来技術と同様、該パケットを、ＨＴＴＰ通信として定義されたポート番号を有するにも関わらず、偽造ＨＴＴＰパケットとみなし、廃棄する（ステップ２０９）。
ただし、第１の文字列であるメソッドがＰＵＴあるいはＰＯＳＴの場合、該パケットの宛先および送信元アドレス、宛先および送信元ポート番号を保存する。そして、これ以降に到着するパケットが、保存した宛先および送信元アドレス、宛先および送信元ポート番号を有する場合、該パケットを通過させることにより、１パケットで転送できない大きさのコンテンツのアップロードを行う場合にも、正常にパケットをサーバに転送することができる。
【００２５】
ここで、前述の実施の形態１のフィルタリングシステムと、本実施の形態のフィルタリングシステムとにおける第３の課題を解決する手段の違いについて説明する。
前述の実施の形態１では、ＴＣＰボディを含むパケットがＨＴＴＰのリクエストライン構造として認められない場合は、該パケットを通過させることにより、１パケットで転送できない大きさのコンテンツのアップロードを実現させた。したがって、前述の実施の形態１のフィルタリングシステムでは、偽造ＨＴＴＰパケットを区別することができない。それに対して、本実施の形態では、偽造ＨＴＴＰパケットを廃棄（ステップ２０９）することができる。
本点については、本実施の形態のフィルタリングシステムの方が優れた方式と言える。
ＨＴＴＰのリクエストライン構造として認められたパケットに対して行うＵＲＩの解析処理（ステップ２０８）、およびフィルタリングとの比較処理（ステップ２１０）は、第１のアルゴリズムと同様の動作である。
すなわち、第２のアルゴリズムにおいても、第１および第２の課題を解決する手段は、前述の実施の形態１のフィルタリングシステムと同様である。
【００２６】
［実施の形態３］
本実施の形態のフィルタリングシステムは、ストリーミング通信の制御信号として用いられるＲＴＳＰ（Ｒｅａｌ　Ｔｉｍｅ　Ｓｔｒｅａｍｉｎｇ　Ｐｒｏｔｏｃｏｌ）への適用例である。ＲＴＳＰもＨＴＴＰと同様、ＴＣＰの上位レイヤとして位置づけられ、ＲＴＳＰヘッダを有する。また、ＴＣＰヘッダ直後の１行目に記述されるリクエストライン構造は、図１３に示すように、ＨＴＴＰと同様の構造である。
ＲＴＳＰとＨＴＴＰとの違いは、使うメソッドが異なることと、ＵＲＩのタイプがＲＴＳＰの場合は、ａｂｓｏｌｕｔｅＵＲＩと、＊のみが使われること、バージョン名がＨＴＴＰではなくＲＴＳＰという文字列に置き換わる点である。
したがって、ＨＴＴＰに対する前述の実施の形態１のリクエストライン解析処理（ステップ１０２）、あるいは、前述の実施の形態２のリクエストライン解析処理（ステップ２０５）における「（３）第３の文字列が、「ＨＴＴＰ／」、「数字」、「．（ドット）」、「数字」により構成される」を、「（３）第３の文字列が、「ＲＴＳＰ／」、「数字」、「．（ドット）」、「数字」により構成される。」と置き換えるだけでＲＴＳＰに対するリクエストライン解析が行える。
また、ＨＴＴＰに対する前述の実施の形態１のＵＲＬの解析処理（ステップ１０４）、あるいは、前述の実施の形態２のＵＲＩの解析処理（ステップ２０８）、すなわち、図９のＵＲＩの解析処理のアルゴリズムは、全く変更することなしに、ＲＴＳＰに対するＵＲＩの解析処理およびＵＲＩに関するフィルタリングルールとの比較が行える。
また、メソッドに関するフィルタリングルールとの比較についても、フィルタリングシステムにＲＴＳＰで使用されるメソッドを登録するだけで、実施可能である。
【００２７】
［実施の形態４］
本実施の形態は、ＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ）通信等で用いられるＳＩＰ（Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）への適用例である。
ＳＩＰの場合、主に、ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）の上位レイヤとして位置づけられ点がＨＴＴＰと異なるが、ＨＴＴＰと同様にＳＩＰヘッダを有する。また、ＵＤＰヘッダ直後の１行目に記述されるリクエストライン構造は、図１４に示すように、ＨＴＴＰと同様の構造である。
ＳＩＰとＨＴＴＰとの違いは、使うメソッドが異なることと、ＵＲＩがＳＩＰの場合は「ｓｉｐ：」から始まるメールアドレス形態の文字列であること、バージョン名がＨＴＴＰではなくＳＩＰという文字列に置き換わる点である。
したがって、ＨＴＴＰに対する前述の実施の形態１のリクエストライン解析処理（ステップ１０２）、あるいは、前述の実施の形態２のリクエストライン解析処理（ステップ２０５）における「（３）第３の文字列が、「ＨＴＴＰ／」、「数字」、「．（ドット）」、「数字」により構成される」を、「（３）第３の文字列が、「ＳＩＰ／」、「数字」、「．（ドット）」、「数字」により構成される。」と置き換えるだけでＳＩＰに対するリクエストライン解析が行える。
【００２８】
また、ＳＩＰのＵＲＬの解析処理については、「＠」の前後を分離する手法が適用できる。
したがって、ＵＲＩに関するフィルタリングルールも「＠」の前後それぞれの文字列について比較検索を行う。また、メソッドに関するフィルタリングルールとの比較についても、フィルタリングシステムにＳＩＰで使用されるメソッドを登録するだけで、実施可能である。
このように、本発明のアルゴリズムは、メソッドやプロトコルバージョンの追加などにより、ＲＴＳＰやＳＩＰ等の他のプロトコルにも応用が効く。
以上、本発明者によってなされた発明を、前記実施の形態に基づき具体的に説明したが、本発明は、前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【００２９】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
（１）本発明によれば、リクエストライン解析時にメソッドを抽出し、メソッドによるフィルタリングを行うことにより、通常のブラウザソフトでは使わないＧＥＴやＰＯＳＴ以外のメソッドを排除し、悪意クライアントからの不正アクセスを防御することが可能となる。
（２）本発明によれば、ＵＲＩの解析処理において、ＨＯＳＴ名と、ａｂｓ＿ｐａｔｈを分離し、フィルタリングを、ＨＯＳＴ名とａｂｓ＿ｐａｔｈそれぞれに対し行うことにより、パケットに記載されるＵＲＩが、ａｂｓ＿ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩのいずれの場合にも、１つのルールにて対応することができ、ルール数の削減・検索時間の短縮に貢献することが可能となる。
【００３０】
（３）本発明によれば、リクエストライン構造と認められない場合に該パケットを通過させることにより、複数のＨＴＴＰパケットの転送によりコンテンツのアップロードを行う場合、ＨＴＴＰヘッダを有さない後続パケットをフィルタリングシステムにて通過させることができ、コンテンツのアップロードを正常に行うことが可能となる。
（４）本発明によれば、リクエストライン構造と認められない場合には、第１の文字列であるメソッドがＰＵＴあるいはＰＯＳＴの場合、該パケットの宛先および送信元アドレス、宛先および送信元ポート番号を保存し、これ以降に到着するパケットが、保存した宛先および送信元アドレス、宛先および送信元ポート番号を有する場合、該パケットを通過させることによって、コンテンツのアップロードを正常に行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１のフィルタリングシステムのアルゴリズムを示すフローチャートである。
【図２】本発明の実施の形態２のフィルタリングシステムのアルゴリズムを示すフローチャートである。
【図３】ＨＴＴＰリクエストラインの構造を説明するための図である。
【図４】ＵＲＩタイプを説明するための図である。
【図５】ａｂｓ−ｐａｔｈと、ａｂｓｏｌｕｔｅＵＲＩの使われ方の違いを説明するための図である。
【図６】従来技術に基づくフィルタリングシステムのアルゴリズムを示すフローチャートである。
【図７】ＡＣＫパケットの使用方法を説明するための図である。
【図８】コンテンツのアップロード時のＨＴＴＰパケット構成を示す図である。
【図９】本発明の各実施の形態のフィルタリングシステムにおけるＵＲＩの解析処理手順を示すフローチャートである。
【図１０】本発明の各実施の形態のフィルタリングシステムにおけるフィルタリングルールの一例を示す図である。
【図１１】図１０に示すフィルタリングルールを作成した際の、クライアント、サーバ、プロキシ、並びにフィルタリングシステムの構成例を示すブロック図である。
【図１２】本発明の各実施の形態のフィルタリングシステムにおけるＴＣＰボディの有無の判定方法を説明するための図である。
【図１３】ＲＴＳＰリクエストラインの構造を説明するための図である。
【図１４】ＳＩＰリクエストラインの構造を説明するための図である。
【符号の説明】
５０１，５０３，１１０１，１１０２…クライアント、５０２，５０５，１１０５，１１０７…サーバ、５０４，１１０６…プロキシ、８０１…コンテンツ、８０２〜８０５…パケット、１１０３…サーバ管理者、１１０４…フィルタリングシステム。
【図１】
2004145583.tif 000003
【図２】
2004145583.tif 000004
【図３】
2004145583.tif 000005
【図４】
2004145583.tif 000006
【図５】
2004145583.tif 000007
【図６】
2004145583.tif 000008
【図７】
2004145583.tif 000009
【図８】
2004145583.tif 000010
【図９】
2004145583.tif 000011
【図１０】
2004145583.tif 000012
【図１１】
2004145583.tif 000013
【図１２】
2004145583.tif 000014
【図１３】
2004145583.tif 000015
【図１４】
2004145583.tif 000016