JP2010244134A - Urlフィルタリング装置およびurlフィルタリング方法 - Google Patents

Urlフィルタリング装置およびurlフィルタリング方法 Download PDF

Info

Publication number
JP2010244134A
JP2010244134A JP2009089423A JP2009089423A JP2010244134A JP 2010244134 A JP2010244134 A JP 2010244134A JP 2009089423 A JP2009089423 A JP 2009089423A JP 2009089423 A JP2009089423 A JP 2009089423A JP 2010244134 A JP2010244134 A JP 2010244134A
Authority
JP
Japan
Prior art keywords
packet
url
tcp
http
passage determination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009089423A
Other languages
English (en)
Other versions
JP5219903B2 (ja
Inventor
Masahide Nishikawa
雅英 西川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2009089423A priority Critical patent/JP5219903B2/ja
Publication of JP2010244134A publication Critical patent/JP2010244134A/ja
Application granted granted Critical
Publication of JP5219903B2 publication Critical patent/JP5219903B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

【課題】URLフィルタリング処理を実行しつつ高いスループットを得ることができるURLフィルタリング装置を得ること。
【解決手段】パケット転送処理部11が、TCP終端処理中に受信したパケットをTCP終端処理部16へ渡し、TCP終端処理中以外の期間に受信したパケットをTCP層パケット処理部12へ渡し、TCP層パケット処理部12はパケットのTCPデータ部を抽出してパケットを保持し、HTTP構文解析処理部13は、URLアクセス要求メッセージでない場合にTCP層パケット処理部12にそのパケットの送信許可を通知し、URLアクセス要求メッセージの場合には、要求URL通過判定処理部14にURL通過判定を依頼し、要求URL通過判定処理部14は、判定結果が不可である場合にはTCP終端処理の開始を指示し、可である場合には保持されたパケットの送信許可を通知する。
【選択図】 図1

Description

本発明は、URL(Uniform Resource Locator)のフィルタリングを行うURLフィルタリング装置およびURLフィルタリング方法に関する。
従来のURLフィルタリング方式の1つとして、HTTP(HyperText Transfer Protocol)プロキシサーバが、HTTPコネクションを中継する際に要求URLに基づいてフィルタリングする方式がある(たとえば、下記特許文献1、下記非特許文献1および下記非特許文献2参照)。この方式では、HTTPクライアントは、HTTPプロキシを使用するよう設定し、URLフィルタリング機能を付加したHTTPプロキシサーバを介してHTTPアクセスを実施する。また、HTTPプロキシは、HTTPメッセージの中継時に、メッセージからHTTPクライアントがアクセスを要求する要求URLを抽出し、URLフィルタリングを実行する。以下、このようにHTTPプロキシサーバを用いたURLフィルタリングをHTTPプロキシ方式とよぶこととする。
また、HTTPクライアントがHTTPプロキシを使用するよう設定していない場合でも、HTTPクライアント−HTTPサーバ間の中継経路上にHTTPプロキシサーバを設置してフィルタリングする方法がある(たとえば、下記非特許文献3参照)。この方式では、HTTPクライアントからHTTPサーバへのパケットの中継経路上のHTTPプロキシサーバが、そのパケットのTCP(Transmission Control Protocol)/IP(Internet Protocol)のアドレス・ポート番号を書き換える着NAPT(Network Address Port Translation)動作によりHTTPプロキシに着信させ、強制的にHTTPプロキシを経由する動作とする。そして、HTTPプロキシサーバが、URLフィルタリングを実行する。以下、このような方式を透過型プロキシ方式とよぶこととする。
上記の透過型プロキシ方式は、結局HTTPプロキシサーバを経由することでTCPを一旦終端する方式である。これに対し、HTTPプロキシサーバを経由せず、HTTPクライアント−HTTPサーバ間のTCPパケットの終端処理をせずにTCPパケット内のHTTP要求を直接参照し、要求URLを含むTCPパケットがフィルタリング対象で無い場合そのまま通過させ、フィルタリング対象である場合にはアクセス拒否応答を返すようにする方式も提案されている(たとえば、下記特許文献2参照)。
特開平11−242639号公報 特開2006−293708号公報 "Squid:optimising Web Delivery",http://www.squid-cache.org/ "SquidGuard",http://www.squidguard.org/ "squid による透過型プロキシ",http://www.linux(登録商標).or.jp/JF/JFdocs/TransparentProxy.html
しかしながら、上記従来のHTTPプロキシ方式では、HTTPクライアントがHTTPプロキシを使用する設定をしている場合に、HTTPプロキシサーバがURLフィルタリングを行う。したがって、HTTPクライアントがHTTPプロキシを使用する設定を行っていない場合にはURLフィルタリングを行うことができない、という問題がある。
また、上記従来の透過型プロキシ方式では、HTTPプロキシサーバがTCPセッションを一旦終端して、一方(HTTPクライアントまたはHTTPサーバ)からのHTTPメッセージ部のみを抽出し、もう片方(HTTPサーバまたはHTTPクライアント)へ中継する。そのため、HTTP層(L7)ではTCP層(L4)の処理を考慮せず簡便にURLの判定を実行できるという利点がある。一方で、TCPセッションの終端処理は複雑であり、一般的ソフトウェアによる処理が必要となる、という問題がある。また、2つのTCPセッションを一旦終端するために生じる処理、および、一方のTCPセッションから得たTCPメッセージをもう片方のTCPセッションに中継するために生じる処理が必要となるが、これらの処理は、複雑でありソフトウェアで実施する必要がある、という問題がある。
近年アクセス回線の光化が進展しアクセス回線速度は向上しているが、URLフィルタリングを上記の従来の透過型プロキシ方式により実施すると、上述のように、URLフィルタリングの処理をソフトウェアで実行しなければならず、アクセス回線速度に応じた高いスループットを得ることが難しくなる、という問題がある。
一方、上述の従来のHTTPクライアント−HTTPサーバ間のTCPパケットを終端処理せずに、直接その内部のHTTPメッセージ部を直接参照し、URLフィルタリングを実施する方法では、TCPセッションを終端しないため、終端処理を省いた高速転送ができる可能性がある。しかし、URLフィルタリング処理でTCP層(L4)も考慮して処理する必要がある、という問題がある。
たとえば、この方法で、URLフィルタリング動作の対象となる要求URLを含むTCPパケットを検出した場合、URLフィルタリング判定処理のためにそのパケットを長期間保留すると、HTTPクライアントのTCPレイヤはそのパケットに関するACK応答をHTTPサーバから受信できない。このため、TCPレイヤの処理では、そのパケットが廃棄されたと判定しそのパケットを再送するとともに、輻輳回避動作により自身の送信レートを低下させ、TCPレベルのスループットが低下する可能性がある、という問題がある。
また、アクセス回線上に設置されるホームゲートウェイのような装置でURLフィルタリング動作を実現する場合、URLフィルタリング判定に使用するURLフィルタデータを装置内に持たせると、装置が備えるべきメモリ量・CPU処理能力などが増大してしまう。ホームゲートウェイのような装置では、ハードウェア資源が限られていることが多いため、このような装置で行う処理は要求URLを抽出する程度に留め、URLフィルタリングの判定処理は外部のサーバに委託して実施する方が効率的と考えられる。ところが、外部のサーバにURLフィルタリング判定を委託する場合、外部サーバとの間でパケットが往復するための遅延、外部サーバでのURL判定処理に伴う遅延、外部サーバが複数のクライアントからの処理を受け付ける場合それらの処理待ちに伴う遅延などが発生し、長期間応答が得られない可能性がある。その結果、外部のサーバにURLフィルタリング判定を委託する場合、TCPレベルのスループットが低下する可能性がある、という問題がある。
本発明は、上記に鑑みてなされたものであって、URLフィルタリング処理を実行しつつ高いスループットを得ることができるURLフィルタリング装置およびURLフィルタリング方法を得ることを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、前記クライアントから送信されるURLアクセス要求メッセージに基づいて、要求されるURLへのアクセスの可否の判定であるURL通過判定を行うURL通過判定手段と、所定のTCP層の処理を行うTCP層処理手段と、所定のTCP終端処理を行うTCP終端処理手段と、受信したパケットのHTTP構文解析を行うHTTP構文解析手段と、を備え、前記パケット転送手段は、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットを前記TCP終端処理手段へ渡し、TCP終端処理中以外の期間に受信したパケットを前記TCP層処理手段へ渡し、前記TCP層処理手段は、前記パケット転送手段から受け取ったパケットのTCPデータ部を抽出するとともに、そのパケットを保持し、前記HTTP構文解析手段は、前記TCPデータ部に基づいて、前記TCP層処理手段に保持されているパケットがURLアクセス要求メッセージでないと判断した場合には、前記TCP層処理手段にそのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼し、前記URL通過判定手段は、前記依頼に基づいてURL通過判定を実施し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理手段に保持されたパケットの送信許可を通知し、前記TCP終端処理手段は、TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力し、前記TCP層処理手段は、送信許可が通知されたパケットを前記パケット転送手段に出力し、前記パケット転送手段は、前記TCP層処理手段から出力されたパケットおよび前記TCP終端処理手段から出力されたパケットをそれぞれのパケットの送信先に送信することを特徴とする。
この発明によれば、通常時は、TCP終端処理を行わず、受信パケットからHTTPデータを抽出し、HTTPデータにURLへのアクセス要求が含まれると判断した場合には、URLの通過/アクセス拒否の判定を実施し、アクセス拒否の判定結果であった場合にTCP終端処理を実施するようにしたので、高いスループットを得ることができる、という効果を奏する。
以下に、本発明にかかるURLフィルタリング装置およびURLフィルタリング方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
実施の形態1.
図1は、本発明にかかるURLフィルタリング装置の実施の形態1の機能構成例を示す図である。図1に示すように本実施の形態のURLフィルタリング装置2は、一般的なパケットルーティング機能を有するパケット転送処理部11と、TCP層の処理を行うTCP層パケット処理部12と、HTTP構文解析処理部13と、要求URL通過判定処理部14と、HTTP応答作成処理部15と、TCP終端処理部16と、で構成される。また、URLフィルタリング装置2は、HTTPクライアントであるPC(Personal Computer)端末1と、HTTPサーバとしての機能を有するwebサーバ3と、URLアクセス制御サーバとしての機能を有するACS(Access Control Server)サーバ4と、に接続している。
また、上り通信パケット通常経路21は、PC端末1−URLフィルタリング装置2間の上り方向の通常の通信時のパケットの経路を示し、下り通信パケット通常経路22は、URLフィルタリング装置2−PC端末1間の下り方向の通常の通信時のパケットの経路を示す。また、上り通信パケット終端経路23は、PC端末1−URLフィルタリング装置2間の上り方向の終端処理を行う場合のパケットの経路を示し、下り通信パケット終端経路24は、URLフィルタリング装置2−PC端末1間の下り方向の終端処理を行う場合のパケットの経路を示す。
つづいて、本実施の形態の動作について説明する。まず、パケットの通過を許可する通過動作について説明する。図2は、本実施の形態のURLフィルタリング方法のうち、パケットの通過動作の一例を示すシーケンス図である。図2では、簡単のため、PC端末1を端末、URLフィルタリング装置2をHGW、WEBサーバ3をWEB、ACSサーバ4をACSとして記載している。
PC端末1がWEBサーバ3にHTTPによるアクセスを要求する場合、まず、3way-handshakeの処理として、PC端末1は、接続要求を意味するSYNパケットをURLフィルタリング装置2経由でWEBサーバ3に送信する(ステップS11,ステップS12)。WEBサーバ3は、接続許可を意味するACKパケットと接続要求のSYNパケットを組み合わせたパケットをURLフィルタリング装置2経由で端末1に送る(ステップS13,ステップS14)。PC端末1は、ACKパケットをURLフィルタリング装置2経由でWEBサーバ3に送り(ステップS15,ステップS16)、PC端末1−WEBサーバ3間のコネクションが確立される。
この際、URLフィルタリング装置2のパケット転送処理部11は、ステップS11でPC端末1から受信したSYNパケットの着ポート番号が、あらかじめ規定されたHTTPサービスポート番号であることを確認し、上位プロトコルがHTTPであるTCPセッションの開始を検出する。ここで、パケット転送処理部11は、一般的なIPルータのIPスタックの機能、すなわちIPパケット転送処理機能と、HTTP/TCPパケットの抽出機能と、を持つこととする。パケット転送処理部11は、これ以降受信するパケットのプロトコル種別・IPアドレス・ポート番号に基づいてHTTPセッションに属するTCPパケットを判別し、判別したTCPパケットをTCP層パケット処理部12に通知することとする。
TCP層パケット処理部12は、ステップS11,ステップS15でそれぞれ送信されたパケットをパケット転送処理部11から受け取り、そのパケットが3way-handshakeのためのパケットであることを検出すると、そのまま(素通し処理)、転送するパケットとしてパケット転送処理部11に出力し、パケット転送処理部11がそのパケットをWEBサーバ3へ転送する(ステップS12,ステップS16)。また、ステップS13で送信されたパケットをパケット転送処理部11から受け取り、そのパケットが3way-handshakeのためのパケットであることを検出すると、そのまま、転送するパケットとしてパケット転送処理部11に出力し、パケット転送処理部11がそのパケットをPC端末1に転送する(ステップS14)。
このように、通常のパケットは、パケット転送処理部11からTCP層パケット処理部12を経由する上り通信パケット通常経路21および下り通信パケット通常経路22を経由する。
ステップS11〜ステップS16の3way-handshake処理の後に、PC端末1は、アクセスを要求するHTTPメソッドおよびURLを含むHTTP/TCPパケットを送信する(ステップS17)。URLフィルタリング装置2は、以下に示すURL抽出処理を実施する(ステップS18)。
URL抽出処理としては、まず、URLフィルタリング装置2のパケット転送処理部11が、受信したHTTP/TCPパケットをTCPパケット層処理部12へ通知する。TCP層パケット処理部12は、HTTP/TCPパケットのデータ部からTCPデータ部をHTTPデータとして抽出し、抽出したHTTPデータをHTTP構文解析処理部13に通知する。また、このとき、TCP層パケット処理部12は、そのHTTP/TCPパケットを保持する。
HTTP構文解析処理部13は、通知されたHTTPデータをHTTP構文フォーマットに従い構文解析(パース)処理を実行し、HTTPアクセス要求であるかを判定する。なお、HTTP構文解析処理部13は、各HTTP/TCPパケットに含まれるHTTPデータを全て順序どおりに連結し、TCPデータバイト列を完全に再生して構文解析を実施する処理としても良い。この場合、TCP層パケット処理部12は、受信したHTTP/TCPパケットの順序制御処理を行う。すなわち、受信したHTTP/TCPパケットの送信シーケンス番号をチェックし、欠落したパケットが無いかをチェックし、欠落している場合は、その欠落しているパケットが再送されるまで待ち合わせを行う。
また、HTTP構文解析処理部13の処理は、もう少し処理を簡略化して、HTTPアクセス要求のメッセージ境界とTCPパケット中のTCPデータの境界が揃っていると仮定し、各HTTP/TCPパケット単位でHTTP構文解析を実施する処理としても良い。ただし、この場合、各HTTP/TCPパケットに完全なHTTP構文が含まれない場合、問題が発生する可能性がある。
つぎに、HTTP構文解析処理部13は、構文解析処理により受信したHTTP/TCPパケットがHTTPアクセス要求を含まないと判定した場合、または、受信したHTTP/TCPパケットに基づいてHTTPアクセス許可を判定するのが適当でないと判断した場合、そのHTTP/TCPパケットの送信許可をTCP層パケット処理部12に通知する。TCP層パケット処理部12は、保持しているHTTP/TCPパケットの送信許可の通知を受け取ると、そのパケットを送信するパケットとしてパケット転送処理部11に出力する。そして、パケット転送処理部11が、WEBサーバ3へそのパケットを転送する。たとえば、HTTPアクセス許可を判定するのが適当でないと判断する場合の一例として、各TCPパケットに完全なHTTP構文が含まれない場合がある。この場合、パケット転送処理部11は、完全なHTTP構文を構成する最後のTCPデータを含むTCPパケットを保持対象としても良い。
一方、HTTP構文解析処理部13が、構文解析処理により受信したHTTP/TCPパケットがHTTPアクセス要求を含むと判定した場合、アクセスを要求するHTTPデータからURL部を抽出し、要求URL通過判定処理部14に抽出したURLを通知する。なお、図2では、HTTPアクセス要求を含むと判定した例を示している。要求URL通過判定処理部14は、通知されたURLを自装置が保持しているURL許可情報に基づいて判定し、通過許可と判定した場合は、パケットの送信許可をTCP層パケット処理部12に通知する。または、外部のACSサーバ4がURL通過判定を行う場合には、ACSサーバ4に問い合わせを行う。具体的には、たとえば、抽出したURL情報の判定を依頼するパケットを送信し(ステップS19)、ACSサーバ4が保持しているURL許可情報に基づいて判定する。そして、ACSサーバ4は、判定結果として許可となった場合はURL許可応答を返送する(ステップS20)。要求URL通過判定処理部14は、一定時間内にACSサーバ4からURLアクセス許可応答を受信した場合、パケットの送信許可をTCP層パケット処理部12に通知する。なお、ACSサーバ4を用いない場合には、ステップS19、S20を実施せず、上述のようにURLフィルタリング装置2内で判定を行う。
そして、TCP層パケット処理部12は、保持しているHTTP/TCPパケットのうち送信許可されたパケットをWEBサーバ3に転送する(ステップS21)。その後は、後続パケットとして、WEBサーバ3からURLフィルタリング装置2経由でPC端末1にデータを送信するためのHTTP/TCPパケットが送信され(ステップS22,23)、PC端末1からURLフィルタリング装置2経由でWEBサーバ3にACKパケットが送信される(ステップS24,25)。以降、同様に、ステップS26〜ステップS33により、WEBサーバ3からPC端末1へのデータの送信とPC端末1からWEBサーバ3へのACKパケットの送信が繰り返され、PC端末1はHTTPアクセスを続行する。
つぎに、パケットの通過を許可しない遮断動作について説明する。図3は、本実施の形態のURLフィルタリング方法のうち、パケットの遮断動作の一例を示すシーケンス図である。まず、図2で説明した通過動作の場合と同様に、ステップS11〜ステップS18が実施される。図2の通過動作の場合は、ステップS18のURL抽出処理により、要求URL通過判定処理部14が、通過許可と判定した場合を示したが、ここでは通過許可でない(アクセス拒否)と判定されたとする。
なお、外部のACSサーバ4がURL通過判定を行う場合には、上述のように、ステップS19、ステップS20を実施し、ステップS20で、アクセス拒否応答が送信される。
要求URL通過判定処理部14は、自身がアクセス拒否と判定した場合、または、ACSサーバ4からアクセス拒否応答を一定時間内に受信した場合、HTTP応答作成処理部15へアクセス拒否の判定結果を通知するとともにTCP終端処理開始を指示する。HTTP応答作成処理部15は通知されたアクセス拒否に対応する応答メッセージ(403 forbiddenなど)を作成し、TCP終端処理部16にTCP終端処理の開始を通知するとともに応答メッセージを渡す。
TCP終端処理部16は、TCP終端処理に必要な情報をTCP層パケット処理部12から収集し、PC端末1との通信の経路を上り通信パケット終端経路23に変更し、WEBサーバ3との通信を下り通信パケット終端経路24に変更する。そして、TCP終端処理部16は、クライアント側TCP終端処理を開始する(ステップS41)。まず、TCP終端処理部16は、HTTP応答作成処理部15が生成したアクセス拒否応答を示す応答メッセージ(403 forbidden)を含むHTTP/TCPパケットをPC端末1へ送信する(ステップS42)。そして、TCP終端処理部16は、クライアント側TCP終端処理として、FIN/ACKパケットをPC端末1に送信し(ステップS43)、PC端末1がFIN/ACKパケットを返送し(ステップS44)、さらに、TCP終端処理部16が、ACKパケットをPC端末1に送信する(ステップS45)。
クライアント側終端処理の実施後、TCP終端処理部16は、サーバ側TCP終端処理を開始する(ステップS46)。そして、サーバ側TCP終端処理として、FIN/ACKパケットをWEBサーバ3に送信し(ステップS47)、WEBサーバ3がFIN/ACKパケットを返送し(ステップS48)、さらに、TCP終端処理部16が、ACKパケットをWEBサーバ3に送信する(ステップS49)。以上の処理により、PC端末1とWEBサーバ間のTCPセッションを遮断する。
つぎに、HTTPリダイレクト応答処理について説明する。図4は、本実施の形態のHTTPリダイレクト応答処理の手順の一例を示すシーケンス図である。ステップS11〜ステップS19の処理は、図2の通過動作の場合と同様である。ただし、ここでは、ACSサーバ4を用いる場合を示したが、ACSサーバ4を用いない場合に、ステップS18のURL抽出処理が所定の時間内に終了しない場合も同様である。
PC端末1では、ステップS17でクセスを要求するHTTPメソッドおよびURLを含むHTTP/TCPパケットを送信してから所定の時間経過してもそのパケットに対する応答がなかった場合、タイムアウトのためそのパケットの再送が必要と判断し(ステップS51)、ステップS17で送信したパケットを再送する(ステップS52)。TCP層パケット処理部12は、パケット転送処理部11経由で受信したそのパケットが再送パケットであることを検出すると、URLの判定処理が遅延していると判断して、HTTP応答作成処理部15にリダイレクト処理を要求するリダイレクト処理要求を通知し、HTTP応答作成処理部15は、リダイレクトにより再度同一のURLにアクセスを要求するようなHTTP応答メッセージを生成する(ステップS53)。
この際、たとえば、HTTP応答作成処理部15は、PC端末1が通常のHTML構文を解釈する場合には、再度同一のURLへのアクセスを要求するHTTP 302応答を含む応答メッセージを生成し、その際に、再度アクセスさせるURLを302応答で規定されるLocation:フィールドに記載する。また、PC端末1がHTML構文中に埋め込まれたスクリプトまたはプログラムを解釈可能であり、該スクリプトまたはプログラムに従い動作する場合、そのスクリプトまたはプログラムとしてPC端末1に一定時間後に再度同一URLへアクセスさせる動作を記述した内容を含む応答メッセージとしてもよい。なお、PC端末1がどのようなHTTP応答を解釈可能かの判定は、HTTP要求メッセージのオプションフィールドから判定することができる。
つぎに、HTTP応答作成処理部15は、生成した応答メッセージとともに、TCP終端処理の開始をTCP終端処理部16に通知する。TCP終端処理部16は、その応答メッセージをPC端末1に送信し(ステップS54)、ステップS43〜ステップS45と同様にTCPセッションを切断するTCP終端処理を実施する(ステップS55〜ステップS57)。そして、WEBサーバ3側のTCP終端処理として、ステップS47〜ステップS49と同様にTCPセッションを切断するTCP終端処理を実施する(ステップS58〜ステップS60)。
以上のように、TCPセッション切断後、PC端末1は、ステップS54で送信された応答メッセージに基づいて、リダイレクト処理としてステップS17で要求したURLと同一のURLへの再度アクセスを行うための処理を実行する(ステップS62)。そして、ステップS11〜ステップS17を再度実施する。
一方、URLフィルタリング装置2は、PC端末1がリダイレクト処理を実行している間に、ステップS19で送信した判定依頼に対する応答を、ACSサーバ4から受信する(ステップS61)と、その判定結果をたとえばTCP層パケット処理部12が保持しておく。なお、ACSサーバ4に問い合わせをせずに、自身がURL判定を実施する場合には、要求URL通過判定処理部14が処理を終了し、処理結果をTCP層パケット処理部12に通知し、TCP層パケット処理部12がその結果を保持すればよい。
TCP層パケット処理部12は、リダイレクト処理によるステップS17のパケットを受信すると、すでにそのパケットが要求するURLの判定結果を保持しているため、その結果に基づいて以降の処理を実施する。以降の処理は、図3の通過動作の判定後の処理、図4の遮断動作の判定後の処理と同様であるが、遮断判定の場合、たとえば、その結果が遮断判定であった場合には、アクセス拒否応答を含むHTTP/TCPパケット(たとえば、403 forbidden)を送信してもよい(ステップS64)。
つぎに、本実施の形態のTCP終端処理について詳細に説明する。図5−1〜5−3は、図4のシーケンス図で送受信されるTCPパケットの送信シーケンス番号、ACKシーケンス番号、TCPメッセージ長の一例を示す図である。なお、図5−1では、3way-handshake処理とHTTP要求メッセージ(再送も含む)について、図5−2では、クライアント側のTCP終端処理について、図5−3では、サーバ側のTCP終端処理について示している。
図5−1〜5−3では、左の欄から順に、図4のステップ番号、そのパケットの送信方向である方向、送信シーケンス番号、ACKシーケンス番号、TCPメッセージ長を示している。方向の欄では、クライアントであるPC端末1をCと表記し、WEBサーバ3をSと表記し、URLフィルタリング装置2をUと表記している。また、ISNcはPC端末1の初期シーケンス番号(Initial Sequence Number:以下ISN)であり、ISNsはWEBサーバ3の初期シーケンス番号である。
なお、TCPでは、SYNビット・FINビットは、送信シーケンス番号を+1増加させるため、ここでは、便宜上TCPメッセージ長の欄に(1)として示している。
ステップS11〜ステップS17のTCPの3way-handshake処理の後、PC端末1は、要求URLを含むHTTP要求メッセージを送信し、また、ステップS52で再送する。TCP層パケット処理部12は、受信するメッセージ(パケット)の送信シーケンス番号、ACKシーケンス番号を監視している。
URLフィルタリング装置2が、TCP終端処理を開始する(ステップS55)と、TCP終端処理部16は、TCP層パケット処理部12からPC端末1−WEBサーバ3間で使用している最新の送信シーケンス番号およびACKシーケンス番号を取得する。つぎに、TCP終端処理部16は、ステップS54で送信する応答メッセージを送信する際の送信シーケンス番号およびACKシーケンス番号は、図5−1の最下段の情報に基づいて生成する。具体的には、送信シーケンス番号は、図5−1の最下段の値(ステップS17で送信されたメッセージの値)と同一とし、ACKシーケンス番号は、図5−1の最下段の値に再下段のTCPメッセージ長(HTTPr)を加えて生成する。このように、URLフィルタリング装置2とPC端末1間の通信では、TCPメッセージ長を考慮して、図5−2に示すようなACKシーケンス番号を生成する。
また、URLフィルタリング装置2とWEBサーバ3間の通信では、図5−3に示すように、図5−1の最下段の値と送信シーケンス番号、ACKシーケンス番号ともに、同一とする。
TCP終端処理部16は、上記のように、URLフィルタリング装置2とPC端末1間の送信シーケンス番号およびACKシーケンス番号と、URLフィルタリング装置2とWEBサーバ3間の送信シーケンス番号およびACKシーケンス番号と、を個別に管理する。
なお、本実施の形態では、上述のリダイレクト応答処理を3way-handshake処理によりTCPセッションが確立された後の、最初のURLアクセス要求に対して実施する例を示したが、これに限らず、たとえば、HTTP1.1で記述されるHTTP keep-alive機能によってPC端末1から通知される、後続のHTTPのURL要求に対してもリダイレクト応答を返すようにしてもよい。
以上のように、本実施の形態では、URLフィルタリング装置2が、通常時は、TCP層パケット処理部12が、TCP終端処理を行わずに、HTTPデータを抽出し、HTTP構文解析処理部13がHTTPデータにURLへのアクセス要求が含まれると判断した場合には、要求URL通過判定処理部14がURLの通過/アクセス拒否の判定を実施し(または、ACSサーバ4からURLの判定の問い合わせを行い)、アクセス拒否の判定結果であった場合には、TCP終端処理を実施するようにした。そのため、通常処理時には、従来のHTTPプロキシ動作や透過型プロキシ動作で必要となるTCPセッション終端を行う必要がない。したがって、TCP終端処理をソフトウェア処理で実行することによるスループットの低下を回避し、アクセス回線速度に応じたTCPレベルスループットを提供できる。
また、一定時間内に要求URLに対する判定結果が得られない場合、新しいTCPセッションに張り替えるリダイレクト処理を実行するようにしている。このため、要求URLを含むTCPパケットの送信が長時間保留された場合も、TCPセッション切断の誤検出やTCPレベルスループットの低下を回避できる。また、TCPパケットの送信を長時間保留できるので、逆に要求URLに対して判定結果を応答するまでの時間を長くすることができる。
また、上記のように判定結果を応答するまでの時間を長くすることが可能なので、URLフィルタリング装置2が内部でURL判定を実施する場合に、装置の演算処理装置の処理能力が低い場合や比較対照するURL情報量が多い場合でも、URL判定を実施することができる。
また、上記のように判定結果を応答するまでの時間を長くすることが可能なので、外部のACSサーバ4にURL判定を依頼する場合、判定を依頼されるACSサーバ4はURL判定結果を即座に応答する必要がなくなる。そのため、ACSサーバ4が、複数のURLフィルタリング装置からのURL判定要求を受け付ける場合、1台のACS4が、より多くのURLフィルタリング装置を収容できる。さらに、その結果、ACSサーバ4の提供者は、用意すべきACSサーバ数を削減でき、ACSサーバの機器コストや運用コストを削減することができる、という効果がある。
実施の形態2.
図6は、本発明にかかるURLフィルタリング装置の実施の形態2の機能構成例を示す図である。図6に示すように本実施の形態のURLフィルタリング装置2aは、実施の形態1のURLフィルタリング装置2にネットワークプロセッサのようなハードウェアで固定的に転送処理を実行する固定転送処理部17を追加する以外は、実施の形態1のURLフィルタリング装置2と同様である。実施の形態1と同一の機能を有する構成要素は、実施の形態1と同一の符号を付して説明を省略する。
本実施の形態では、実施の形態1に比べ、パケット転送に要するソフトウェア処理を軽減した処理を実施する。図6の下り通信パケット通常経路22aは、本実施の形態の下り方向の通常パケットの経路を示している。
つづいて、本実施の形態の動作について説明する。本実施の形態では、パケット転送処理部11は、上り方向パケットのみTCP層パケット処理部12に通知する。下り方向のパケットは、固定転送処理部17が、固定的な転送処理により転送処理を実施する。このため、本実施の形態ではパケット転送処理部11は、上り方向のパケットのみをシーケンス番号の監視対象とする。
すなわち、たとえば、実施の形態1のステップS13で受信したパケットは、固定転送処理部17が、固定的な処理によりPC端末1へ転送を実施する。上り方向のパケットについては、実施の形態1と同様の処理を実施する。
この構成では、図4を例にすると、TCP層パケット処理部12は、TCP終端処理の開始前に、送信シーケンス番号およびACKシーケンス番号をステップS11,ステップS15,ステップS52で送信されたパケットからしか得られない。しかし、TCP終端処理時の最初のPC端末1−URLフィルタリング装置2間の送信パケットであるステップS54で送信するパケットについて考えると、このパケットの送信時に必要とされる送信シーケンス番号およびACKシーケンス番号はステップS17またはステップS52で送信されたパケットから得られるため問題ない。また、TCP終端処理時の最初のURLフィルタリング装置2−WEBサーバ3間の送信パケットであるステップS58で送信するパケットについても同様である。
なお、TCP終端処理開始後の処理は、上りパケットについても、実施の形態1と同様に下り通信パケット終端経路24の経路を経由する処理とする。以上説明した以外の本実施の形態の動作は実施の形態1と同様である。
以上のように、本実施の形態では、通常の(TCP終端処理を行わない)上り方向のパケットは、実施の形態1と同様の処理とし、通常の下り方向のパケットは、固定転送処理部17が、ハードウェアによる固定的な処理により実施するようにした。そのため、下り方向のスループットを実施の形態1に比べ向上させることができる。
実施の形態3.
図7は、本発明にかかるURLフィルタリング装置の実施の形態3の機能構成例を示す図である。図7に示すように本実施の形態のURLフィルタリング装置2bは、実施の形態2のURLフィルタリング装置2aのTCP終端処理部16をTCP簡易終端処理部16aに変更する以外は、実施の形態2のURLフィルタリング装置2aと同様である。実施の形態2と同一の機能を有する構成要素は、実施の形態2と同一の符号を付して説明を省略する。
図8は、本実施の形態のTCP終端処理手順の一例を示すシーケンス図である。まず、図4で説明した実施の形態1の動作と同様に、ステップS11〜ステップS19,ステップS52,S53の処理を実施する。そして、その後、TCP簡易終端処理部16aは、ステップS54と同様の処理により送信した応答メッセージとTCP終端処理としてのFIN/ACKとを含むパケットを送信し、このパケットがPC端末1に到着しなかったとする(ステップS71)。
PC端末1は、ステップS52でパケットを送信してから所定の時間が経過してもそのパケットに対する応答が無い場合、タイムアウトによる再送処理を開始し、ステップS17で送信したパケットを再送する(ステップS73)。
TCP簡易終端処理部16aは、ステップS73で送信されたパケットを受信すると、ステップS71で送信したパケットと同様のパケットを再送する(ステップS74)。そして、今後は、PC端末1が、ステップS74で送信したパケットを受信し、FIN/ACKパケットを送信し(ステップS75)、TCP簡易終端処理部16aは、ステップS75で送信されたパケットを受信すると、ACKパケットを送信する(ステップS76)。
実施の形態1のTCP終端処理部16の場合、たとえば、ステップS71で送信したパケットに対する応答が所定の時間内に到着しない場合には、自身がタイムアウトを判断し、パケットを再送する。これに対し、本実施の形態のTCP簡易終端処理部16aは、このように、自身の送信パケットのタイムアウトの監視はせず、通信相手からパケットを受信した場合にその応答となるTCPパケットを送信するように簡略化している。
そして、TCP簡易終端処理部16aは、サーバ側のTCP終端処理として、FIN/ACKパケットを送信し、このパケットがWEBサーバ3に所定の時間内に到着しなかったとする(ステップS77)。WEBサーバ3は、所定の時間が経過してもURLフィルタリング処理装置2bからパケットが送信されない場合、再送が必要であると判断し(ステップS78)、ACKパケットを再送する(ステップS79)。
TCP簡易終端処理部16aは、WEBサーバ3からACKパケットを受信した場合には、ステップS77で送信したパケットが到着していないと判断し、ステップS77で送信したFIN/ACKパケットを再送する(ステップS80)。そして、WEBサーバ3が、URLフィルタリング装置2bへFIN/ACKパケットを送信し(ステップS81)、URLフィルタリング装置2bのTCP簡易終端処理部16aは、ACKパケットをWEBサーバ3へ送信する(ステップS82)。
以上説明した以外の本実施の形態の動作は実施の形態2と同様である。なお、本実施の形態では、実施の形態2のURLフィルタリング装置2aのTCP終端処理部16をTCP簡易終端処理部16aに替えた構成としているが、実施の形態1のURLフィルタリング装置2のTCP終端処理部16をTCP簡易終端処理部16aに替え、上述のTCP簡易終端処理部16aの処理を実施するようにしてもよい。
以上のように、本実施の形態では、TCP簡易終端処理部16aは、通信相手(PC端末1またはWEBサーバ3)からTCPパケットを受信した場合にその応答となるTCPパケットを送信するようにした。このため、通常のTCP終端処理で必要になる再送タイマ処理や輻輳回避などの複雑なTCP処理動作を実施することなく、TCPセッションを終端することができる。そのため、実施の形態1、2に比べ、TCP簡易終端処理部16aの処理を軽減することができる。
以上のように、本発明にかかるURLフィルタリング装置およびURLフィルタリング方法は、URLのフィルタリングを行う通信システムに有用であり、特に、高いスループットを実現する通信システムに適している。
本発明にかかるURLフィルタリング装置の実施の形態1の機能構成例を示す図である。 実施の形態1のパケットの通過動作の一例を示すシーケンス図である。 実施の形態1のパケットの遮断動作の一例を示すシーケンス図である。 実施の形態1のHTTPリダイレクト応答処理の手順の一例を示すシーケンス図である。 TCPパケットの送信シーケンス番号、ACKシーケンス番号、TCPメッセージ長の一例を示す図である。 TCPパケットの送信シーケンス番号、ACKシーケンス番号、TCPメッセージ長の一例を示す図である。 TCPパケットの送信シーケンス番号、ACKシーケンス番号、TCPメッセージ長の一例を示す図である。 実施の形態2のURLフィルタリング装置の機能構成例を示す図である。 実施の形態3のURLフィルタリング装置の機能構成例を示す図である。 実施の形態3のTCP終端処理手順の一例を示すシーケンス図である。
1 PC端末
2,2a,2b URLフィルタリング装置
3 WEBサーバ
4 ACSサーバ
11 パケット転送処理部
12 TCP層パケット処理部
13 HTTP構文解析処理部
14 要求URL通過判定処理部
15 HTTP応答作成処理部
16 TCP終端処理部
16a TCP簡易終端処理部
17 固定転送処理部
21 上り通信パケット通常経路
22,22a 下り通信パケット通常経路
23 上り通信パケット終端経路
24 下り通信パケット終端経路

Claims (14)

  1. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、
    前記クライアントから送信されるURLアクセス要求メッセージに基づいて、要求されるURLへのアクセスの可否の判定であるURL通過判定を行うURL通過判定手段と、
    所定のTCP層の処理を行うTCP層処理手段と、
    所定のTCP終端処理を行うTCP終端処理手段と、
    受信したパケットのHTTP構文解析を行うHTTP構文解析手段と、
    を備え、
    前記パケット転送手段は、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットを前記TCP終端処理手段へ渡し、TCP終端処理中以外の期間に受信したパケットを前記TCP層処理手段へ渡し、
    前記TCP層処理手段は、前記パケット転送手段から受け取ったパケットのTCPデータ部を抽出するとともに、そのパケットを保持し、
    前記HTTP構文解析手段は、前記TCPデータ部に基づいて、前記TCP層処理手段に保持されているパケットがURLアクセス要求メッセージでないと判断した場合には、前記TCP層処理手段にそのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼し、
    前記URL通過判定手段は、前記依頼に基づいてURL通過判定を実施し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理手段に保持されたパケットの送信許可を通知し、
    前記TCP終端処理手段は、TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力し、
    前記TCP層処理手段は、送信許可が通知されたパケットを前記パケット転送手段に出力し、
    前記パケット転送手段は、前記TCP層処理手段から出力されたパケットおよび前記TCP終端処理手段から出力されたパケットをそれぞれのパケットの送信先に送信することを特徴とするURLフィルタリング装置。
  2. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、
    前記クライアントから送信されるURLアクセス要求メッセージに基づいて、要求されたURLを含ませたURL判定依頼を、URLへのアクセスの可否の判定であるURL通過判定を実施する外部装置へ送信し、その応答として、前記外部装置から判定結果を取得するURL通過判定手段と、
    所定のTCP層の処理を行うTCP層処理手段と、
    所定のTCP終端処理を行うTCP終端処理手段と、
    受信したパケットのHTTP構文解析を行うHTTP構文解析手段と、
    を備え、
    前記パケット転送手段は、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットを前記TCP終端処理手段へ渡し、TCP終端処理中以外の期間に受信したパケットを前記TCP層処理手段へ渡し、
    前記TCP層処理手段は、前記パケット転送手段から受け取ったパケットのTCPデータ部を抽出するとともに、そのパケットを保持し、
    前記HTTP構文解析手段は、前記TCPデータ部に基づいて、前記TCP層処理手段に保持されているパケットがURLアクセス要求メッセージでないと判断した場合には、前記TCP層処理手段にそのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼し、
    前記URL通過判定手段は、前記依頼に基づいて前記URLアクセス要求メッセージに含まれるURLを含ませたURL判定依頼を前記外部装置へ送信し、その依頼に対する応答としてURL通過判定結果を取得し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理手段に保持されたパケットの送信許可を通知し、
    前記TCP終端処理手段は、TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力し、
    前記TCP層処理手段は、送信許可が通知されたパケットを前記パケット転送手段に出力し、
    前記パケット転送手段は、前記TCP層処理手段から出力されたパケットおよび前記TCP終端処理手段から出力されたパケットをそれぞれのパケットの送信先へ送信することを特徴とするURLフィルタリング装置。
  3. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、
    前記クライアントから送信されるURLアクセス要求メッセージに基づいて、要求されたURLへのアクセスの可否の判定であるURL通過判定を行うURL通過判定手段と、
    所定のTCP層の処理を行うTCP層処理手段と、
    所定のTCP終端処理を行うTCP終端処理手段と、
    受信したパケットのHTTP構文解析を行うHTTP構文解析手段と、
    所定の転送処理を行う簡易転送手段と、
    を備え、
    前記パケット転送手段は、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットを前記TCP終端処理手段へ渡し、TCP終端処理中以外の期間に前記クライアントから受信したパケットを前記TCP層処理手段へ渡し、
    前記TCP層処理手段は、前記パケット転送手段から受け取ったパケットのTCPデータ部を抽出するとともに、そのパケットを保持し、
    前記HTTP構文解析手段は、前記TCPデータ部に基づいて、前記TCP層処理手段に保持されているパケットがURLアクセス要求メッセージでないと判断した場合には、前記TCP層処理手段にそのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼し、
    前記URL通過判定手段は、前記依頼に基づいてURL通過判定を実施し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理手段に保持されたパケットの送信許可を通知し、
    前記TCP終端処理手段は、TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力し、
    前記TCP層処理手段は、送信許可が通知されたパケットを前記パケット転送手段に出力し、
    前記パケット転送手段は、前記TCP層処理手段から出力されたパケットおよび前記TCP終端処理手段から出力されたパケットをそれぞれのパケットの送信先に送信し、
    前記簡易転送手段は、TCP終端処理中以外の期間に前記サーバから受信したパケットを前記クライアントへ転送することを特徴とするURLフィルタリング装置。
  4. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、
    前記クライアントから送信されるURLアクセス要求メッセージに基づいて、そのメッセージで要求されたURLを含ませたURL判定依頼を、URLへのアクセスの可否の判定であるURL通過判定を実施する外部装置へ送信し、その応答として、前記外部装置から判定結果を取得するURL通過判定手段と、
    所定のTCP層の処理を行うTCP層処理手段と、
    所定のTCP終端処理を行うTCP終端処理手段と、
    受信したパケットのHTTP構文解析を行うHTTP構文解析手段と、
    所定の転送処理を行う簡易転送手段と、
    を備え、
    前記パケット転送手段は、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットを前記TCP終端処理手段へ渡し、TCP終端処理中以外の期間に前記クライアントから受信したパケットを前記TCP層処理手段へ渡し、
    前記TCP層処理手段は、前記パケット転送手段から受け取ったパケットのTCPデータ部を抽出するとともに、そのパケットを保持し、
    前記HTTP構文解析手段は、前記TCPデータ部に基づいて、前記TCP層処理手段に保持されているパケットがURLアクセス要求メッセージでないと判断した場合には、前記TCP層処理手段にそのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼し、
    前記URL通過判定手段は、前記依頼に基づいて前記URLアクセス要求メッセージに含まれるURLを含ませたURL判定依頼を前記外部装置へ送信し、その依頼に対する応答としてURL通過判定結果を取得し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理手段に保持されたパケットの送信許可を通知し、
    前記TCP終端処理手段は、TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力し、
    前記TCP層処理手段は、送信許可が通知されたパケットを前記パケット転送手段に出力し、
    前記パケット転送手段は、前記TCP層処理手段から出力されたパケットおよび前記TCP終端処理手段から出力されるパケットをそれぞれのパケットの送信先に送信し、
    前記簡易転送手段は、TCP終端処理中以外の期間に前記サーバから受信したパケットを前記クライアントへ転送することを特徴とするURLフィルタリング装置。
  5. 前記TCP終端処理を前記クライアントに対するセッションと前記サーバに対するセッションとの2つに分割して実施することを特徴とする請求項1〜4のいずれか1つに記載のURLフィルタリング装置。
  6. HTTP応答を生成するHTTP応答手段、
    をさらに備え、
    前記TCP層処理手段は、前記クライアントから送信されたURLアクセス要求メッセージのパケットが再送パケットであると判断した場合は、そのセッションを終了させるためのTCP終端処理の開始を指示するとともに、前記クライアントに再度同一URLへのアクセスの要求を行わせるための応答であるリダイレクト応答の生成を指示し、
    前記HTTP応答手段は、前記指示に基づいてリダイレクト応答を生成し、生成したリダイレクト応答を前記クライアントに送信することを特徴とする請求項1〜5のいずれか1つに記載のURLフィルタリング装置。
  7. 前記TCP層処理手段は、前記URL通過判定結果を保持することとし、前記再送パケットに対応するURLのURL通過判定結果を保持している場合は、保持しているURL通過判定結果を、その再送パケットに対するURL通過判定結果とすることを特徴とする請求項6に記載のURLフィルタリング装置。
  8. 前記リダイレクト応答を「HTTP 302」応答とし、前記「HTTP 302」応答のLocationフィールドに前記URLアクセス要求メッセージでアクセスを要求されたURLを含ませることを特徴とする請求項6または7に記載のURLフィルタリング装置。
  9. 前記リダイレクト応答のHTTPデータ部に、所定の時間経過後に前記URLアクセス要求メッセージでアクセスを要求されたURLへ再度アクセスを要求する動作を、前記クライアントが解釈可能なスクリプトまたはプログラムで記述することを特徴とする請求項6または7に記載のURLフィルタリング装置。
  10. 前記リダイレクト応答を、HTTP1.1で記述されるHTTP keep-alive機能によって前記クライアントから通知される後続のURLアクセス要求セッッセージに対してもリダイレクト応答を返すことを特徴とする請求項6〜9のいずれか1つに記載のURLフィルタリング装置。
  11. 前記TCP終端処理を、前記クライアントまたは前記サーバから所定のパケットを受信した際にその応答となるパケットを送信する処理、とすることを特徴とする請求項1〜10のいずれか1つに記載のURLフィルタリング装置。
  12. 前記TCP終端処理手段は、受信したパケットの応答パケットのACKシーケンス番号を、その受信したパケットのACKシーケンス番号にTCPデータ長を加算した値とすることを特徴とする請求項11に記載のURLフィルタリング装置。
  13. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、前記クライアントから送信されるURLアクセス要求メッセージに基づいて、要求されたURLへのアクセスの可否の判定であるURL通過判定を行うURL通過判定手段と、を備えるURLフィルタリング装置におけるURLフィルタリング方法であって、
    前記パケット転送手段が、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットをTCP終端処理対象とし、TCP終端処理中以外の期間に受信したパケットをTCP層処理対象とするパケット判別ステップと、
    TCP層処理対象のパケットのTCPデータ部を抽出するとともに、そのパケットを保持するTCP層処理ステップと、
    前記TCPデータ部に基づいて、前記TCP層処理ステップで保持されたパケットがURLアクセス要求メッセージでないと判断した場合には、そのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼するHTTP構文解析ステップと、
    前記URL通過判定手段が、前記依頼に基づいてURL通過判定を実施し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理ステップにて保持されたパケットの送信許可を通知するURL通過判定ステップと、
    TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力するTCP終端処理ステップと、
    送信許可が通知されたパケットを前記パケット転送手段に出力する送信許可パケット出力ステップと、
    前記パケット転送手段が、前記TCP層処理ステップの実行により出力されたパケットおよび前記TCP終端処理ステップの実行により出力されたパケットをそれぞれのパケットの送信先に送信する送信ステップと、
    を含むことを特徴とするURLフィルタリング方法。
  14. HTTPプロトコルを用いた通信を行うクライアントとサーバとの間で送受信されるパケットを中継するパケット転送手段と、前記クライアントから送信されるURLアクセス要求メッセージに基づいて、そのメッセージで要求されたURLを含ませたURL判定依頼を、URLへのアクセスの可否の判定であるURL通過判定を実施する外部装置へ送信し、その応答として、前記外部装置から判定結果を取得するURL通過判定手段と、を備えるURLフィルタリング装置におけるURLフィルタリング方法であって、
    前記パケット転送手段が、TCP終端処理の開始が指示されてからそのTCP終端処理が終了するまでのTCP終端処理中に受信したパケットをTCP終端処理対象とし、TCP終端処理中以外の期間に受信したパケットをTCP層処理対象とするパケット判別ステップと、
    TCP層処理対象のパケットのTCPデータ部を抽出するとともに、そのパケットを保持するTCP層処理ステップと、
    前記TCPデータ部に基づいて、前記TCP層処理ステップで保持されたパケットがURLアクセス要求メッセージでないと判断した場合には、そのパケットの送信許可を通知し、一方、URLアクセス要求メッセージであると判断した場合には、前記URL通過判定手段にそのURLアクセス要求メッセージのURL通過判定を依頼するHTTP構文解析ステップと、
    前記URL通過判定手段が、前記依頼に基づいて前記URLアクセス要求メッセージに含まれるURLを含ませたURL判定依頼を前記外部装置へ送信し、その依頼に対する応答としてURL通過判定結果を取得し、URL通過判定結果がアクセス不可である場合には、TCP終端処理の開始を指示し、URL通過判定結果がアクセス可である場合には、前記TCP層処理ステップにて保持されたパケットの送信許可を通知するURL通過判定ステップと、
    TCP終端処理の開始が指示されるとセッションを終了させるためのTCP終端処理を行い、TCP終端処理によって生成したパケットを前記パケット転送手段に出力するTCP終端処理ステップと、
    送信許可が通知されたパケットを前記パケット転送手段に出力する送信許可パケット出力ステップと、
    前記パケット転送手段が、前記TCP層処理ステップの実行により出力されたパケットおよび前記TCP終端処理ステップの実行により出力されたパケットをそれぞれのパケットの送信先に送信する送信ステップと、
    を含むことを特徴とするURLフィルタリング方法。
JP2009089423A 2009-04-01 2009-04-01 Urlフィルタリング装置およびurlフィルタリング方法 Active JP5219903B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009089423A JP5219903B2 (ja) 2009-04-01 2009-04-01 Urlフィルタリング装置およびurlフィルタリング方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009089423A JP5219903B2 (ja) 2009-04-01 2009-04-01 Urlフィルタリング装置およびurlフィルタリング方法

Publications (2)

Publication Number Publication Date
JP2010244134A true JP2010244134A (ja) 2010-10-28
JP5219903B2 JP5219903B2 (ja) 2013-06-26

Family

ID=43097114

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009089423A Active JP5219903B2 (ja) 2009-04-01 2009-04-01 Urlフィルタリング装置およびurlフィルタリング方法

Country Status (1)

Country Link
JP (1) JP5219903B2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2590379A2 (en) 2011-11-04 2013-05-08 Hitachi Ltd. Filtering system and filtering method
JP2013186873A (ja) * 2012-03-12 2013-09-19 Nippon Telegraph & Telephone West Corp パケット転送装置
JP2013191958A (ja) * 2012-03-13 2013-09-26 Nippon Telegraph & Telephone West Corp Urlフィルタリング装置
JP2013207675A (ja) * 2012-03-29 2013-10-07 Nippon Telegraph & Telephone West Corp 中継装置
WO2016117776A1 (ko) * 2015-01-23 2016-07-28 주식회사 플랜티넷 라우터 기반의 유해 차단 시스템 및 그 방법
RU2599949C1 (ru) * 2015-04-16 2016-10-20 Федеральное государственное бюджетное учреждение науки Институт автоматики и электрометрии Сибирского отделения Российской академии наук (ИАиЭ СО РАН) Способ фильтрации потока нттр-пакетов на основе пост-анализа запросов к интернет-ресурсу и устройство фильтрации для его реализации
KR20180076174A (ko) * 2016-12-27 2018-07-05 한국인터넷진흥원 모바일 장치 기반의 악성 스크립트 탐지 방법 및 그 장치

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11242639A (ja) * 1998-02-24 1999-09-07 Nec Corp プロキシサーバ
JP2006060599A (ja) * 2004-08-20 2006-03-02 Nippon Telegr & Teleph Corp <Ntt> アプリケーションサービス拒絶攻撃防御方法及びシステム並びにプログラム
JP2006293708A (ja) * 2005-04-11 2006-10-26 Nec Access Technica Ltd コンテンツアクセス制御装置、コンテンツアクセス制御方法およびコンテンツアクセス制御プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11242639A (ja) * 1998-02-24 1999-09-07 Nec Corp プロキシサーバ
JP2006060599A (ja) * 2004-08-20 2006-03-02 Nippon Telegr & Teleph Corp <Ntt> アプリケーションサービス拒絶攻撃防御方法及びシステム並びにプログラム
JP2006293708A (ja) * 2005-04-11 2006-10-26 Nec Access Technica Ltd コンテンツアクセス制御装置、コンテンツアクセス制御方法およびコンテンツアクセス制御プログラム

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2590379A2 (en) 2011-11-04 2013-05-08 Hitachi Ltd. Filtering system and filtering method
CN103095676A (zh) * 2011-11-04 2013-05-08 株式会社日立制作所 过滤系统以及过滤方法
US8935419B2 (en) 2011-11-04 2015-01-13 Hitachi, Ltd. Filtering device for detecting HTTP request and disconnecting TCP connection
JP2013186873A (ja) * 2012-03-12 2013-09-19 Nippon Telegraph & Telephone West Corp パケット転送装置
JP2013191958A (ja) * 2012-03-13 2013-09-26 Nippon Telegraph & Telephone West Corp Urlフィルタリング装置
JP2013207675A (ja) * 2012-03-29 2013-10-07 Nippon Telegraph & Telephone West Corp 中継装置
WO2016117776A1 (ko) * 2015-01-23 2016-07-28 주식회사 플랜티넷 라우터 기반의 유해 차단 시스템 및 그 방법
RU2599949C1 (ru) * 2015-04-16 2016-10-20 Федеральное государственное бюджетное учреждение науки Институт автоматики и электрометрии Сибирского отделения Российской академии наук (ИАиЭ СО РАН) Способ фильтрации потока нттр-пакетов на основе пост-анализа запросов к интернет-ресурсу и устройство фильтрации для его реализации
KR20180076174A (ko) * 2016-12-27 2018-07-05 한국인터넷진흥원 모바일 장치 기반의 악성 스크립트 탐지 방법 및 그 장치
KR102001814B1 (ko) * 2016-12-27 2019-07-19 한국인터넷진흥원 모바일 장치 기반의 악성 스크립트 탐지 방법 및 그 장치

Also Published As

Publication number Publication date
JP5219903B2 (ja) 2013-06-26

Similar Documents

Publication Publication Date Title
JP5219903B2 (ja) Urlフィルタリング装置およびurlフィルタリング方法
US9832169B2 (en) Method and system for communicating over a segmented virtual private network (VPN)
EP1333642B1 (en) Method and system for integrating performance enhancing functions in a virtual private network (VPN)
US7389533B2 (en) Method and system for adaptively applying performance enhancing functions
US7596802B2 (en) Method and system for providing connection handling
US7673048B1 (en) Methods and apparatus for establishing a computerized device tunnel connection
US7990866B2 (en) Server device, method for controlling a server device, and method for establishing a connection using the server device
EP1443731A2 (en) Method and system for providing security in performance enhanced network
EP1443713A2 (en) Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network
Shen et al. On TCP-based SIP server overload control
WO2006133651A1 (en) Communication method between communication devices and communication apparatus
US20110320589A1 (en) Method and device for processing data in a network
US8543807B2 (en) Method and apparatus for protecting application layer in computer network system
TWI701920B (zh) 封包傳送方法以及系統
JP6444988B2 (ja) Httpを利用する通信システム
JP2017118545A5 (ja)
JPWO2007039942A1 (ja) 端末装置及びサーバ装置及び指令装置
CN1898649A (zh) 防止网络重置拒绝服务攻击
CN114465742B (zh) 网络安全防护方法以及防护设备
JP4285101B2 (ja) リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法
JP3648211B2 (ja) パケット中継プログラム、パケット中継装置および記録媒体
CN114553446B (zh) 网络安全防护方法以及防护设备
JP5147819B2 (ja) コンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置
US20220030011A1 (en) Demand management of sender of network traffic flow

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120124

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121219

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130205

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130305

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160315

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5219903

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250