JP2013191958A - Ｕｒｌフィルタリング装置 - Google Patents

Abstract

【課題】ＵＲＬフィルタリングシステムとしてゲートウェイを用いる際に、アップリンクダウンリンクの区別無く、汎用的にファストパスを活用してゲートウェイにおける転送処理を高速化する。
【解決手段】ＨＴＴＰ通信の前に送信されるＤＮＳ要求を受けた段階で、それに含まれるＦＱＤＮを、ＦＱＤＮ及びＩＰアドレスごとの安全性を記録したＡＣサーバへ問い合わせ、当該ＩＰアドレスにある全てのコンテンツが安全であると保証されるのであれば、そのＩＰアドレスへのＴＣＰセッションは全て安全としてファストパス処理する。ＨＴＴＰセッションの確立前に予め問い合わせを行うため、速やかなファストパス登録ができる。
【選択図】図１

Description

この発明は、ＵＲＬフィルタリングの高速化に向けたパケット転送装置に関する。

ユーザ端末がネットワークにアクセスするにあたり、ウイルスやワームが仕掛けられたサイトや、フィッシングサイト、成人向けサイトといった規制対象サイトにアクセスしないように、規制対象となるサイトへのアクセスをＵＲＬごとに遮断するＵＲＬフィルタリングが一般に行われている。家庭用ホームゲートウェイなどのゲートウェイにおいてＵＲＬフィルタリングする場合には、ユーザ端末から送信されるＨＴＴＰリクエストの中のＵＲＬアクセスメッセージを検出し、当該ＵＲＬへのアクセスの可否を、規制対象サイトのＵＲＬ一覧をデータベースとして保持するサーバに問い合わせて確認し、ＨＴＴＰリクエストを通過させるか遮断するかを判断している。

ゲートウェイ上でユーザ端末から送信されるＨＴＴＰリクエスト中のＵＲＬアクセスメッセージを検出するには、例えば次のような方法が挙げられる。まず第一の方法としては、ゲートウェイ上でＨＴＴＰプロキシを提供し、ＨＴＴＰ通信を一旦ゲートウェイ上で終端中継する。しかしこの方法は、ゲートウェイ上でＨＴＴＰ／ＴＣＰ通信を一旦終端し、ＨＴＴＰヘッダ情報の修正などの処理を行う必要がある。また、ユーザ端末から送信された全てのＨＴＴＰ通信に対してＵＲＬフィルタリングを行うため、正常なウェブサーバ、すなわちサーバ上にあるページが全て無害かつ正常なページであるサーバに対するダウンロード、アップロードに対しても必ずＵＲＬフィルタリングを行う。このため、ゲートウェイにかかる処理負担が大きく、転送性能は大きく劣化してしまう。

これに対して第二の方法として、ＨＴＴＰ／ＴＣＰ通信をゲートウェイ上で終端させることなく、中継するパケットのペイロード内容を解析し、パケット中のＨＴＴＰヘッダ情報を読み取って、リクエストを通過させるか否かを判断させる方法がある。しかし、ホームゲートウェイなどに用いるＣＰＵに搭載されている、高速パケット転送用の機構である「ファストパス」は、ＩＰ、ＴＣＰヘッダのビットのみを読み取って処理することで高速化するものであり、ヘッダより先のペイロードを解析しなければならないこの第二の方法では「ファストパス」が利用できない。そのため、この方法でも転送速度の低下を招くことになる。

特許文献１には、上記の第二の方法において、ダウンリンクのみファストパスを適用し、転送性能を改善する方式が提案されている。これは、受信したパケットのＴＣＰヘッダを解析してＵＲＬアクセス要求メッセージでない、すなわちダウンロードされるファイルのパケットについては、それを要求するＨＴＴＰリクエストの段階で遮断すべきか否かの判断が既に終わって通過が認められたものであると判断して、ファストパスで処理するようにしたものである。

また、特許文献２には、ＶＰＮ（ＶｉｒｔｕａｌＰｒｉｖａｔｅＮｅｔｗｏｒｋ）におけるＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）ゲートウェイにおいて、ＶｏＩＰパケットをファストパス処理することが記載されている。

特開２０１０−２４４１３４号公報 特開２０１１−１１４３９１号公報

しかしながら、特許文献１の方法では、あくまで要求を確認した後のダウンリンクのみしかファストパスを適用できず、クラウドを利用するようなアップリンクも多いケースでは十分にファストパスを活用できなかった。

また、特許文献２に記載の方法ではＶｏＩＰやそれに類似するストリーミング形式のデータパケットに対してしかファストパスを活用できなかった。

そこでこの発明は、ＵＲＬフィルタリングシステムとしてゲートウェイを用いる際に、アップリンクダウンリンクの区別無く、汎用的にファストパスを活用してゲートウェイにおける転送処理を高速化することを目的とする。

この発明の第一の実施手段としては、ＵＲＬフィルタリング装置に、
上記ユーザ端末と上記ウェブサーバとの間で送受信されるパケットを中継するパケット転送処理部と、パケット転送処理部を通過するＴＣＰパケットのヘッダ部分を読み取りＴＣＰ層の処理を行うＴＣＰ層パケット処理部と、上記ＴＣＰパケットのデータ部分に含まれるＨＴＴＰ構文を読み取り解析を行うＨＴＴＰ構文解析処理部と、上記の解析されたＨＴＴＰ構文に含まれるＵＲＬへのアクセスを通過させるか否かを判定処理する要求ＵＲＬ通過判定処理部とともに、
上記ファストパス機能によってファストパスを行うか否かの条件を一時的に保持するファストパス判断テーブルと、
ユーザ端末からウェブサーバへの接続を実施する前に上記ウェブサーバのＦＱＤＮ（Fully Qualified Domain Name）の名前を解決するために上記ユーザ端末から送信されるＤＮＳ要求を受けＤＮＳサーバに問い合わせてＩＰアドレスを取得するＤＮＳ−ｐｒｏｘｙ処理部と、
上記ＤＮＳ要求に含まれるＦＱＤＮ及び前記取得したＩＰアドレスの少なくとも一方で指定されるアドレスを、外部に設けたＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとの安全性を記録し返答可能なＡＣサーバへ問い合わせる要求ドメイン通過判定処理部とを
備えさせ、
上記ＴＣＰ層パケット処理部は、上記のＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとの安全性の記録を参照して、安全であるとの返答を得ているＦＱＤＮで指定されるアドレスへの通信セッションを上記ファストパス機能によって行う条件を上記ファストパス判断テーブルへ登録するファストパス登録機能を実行し、
上記パケット転送処理部は、受信したパケットについて上記ファストパス判断テーブルのファストパス条件に合致するパケットをファストパスさせるファストパス判断機能を実行するものとすることで、上記の課題を解決したのである。

この発明は、ユーザ端末がウェブサーバにアクセスしようとする際には、ＩＰアドレスを直接打ち込むといった極めて限定的な場合を除いて、ほとんどの場合ＦＱＤＮを用いてアドレスを指定することを利用している。ＦＱＤＮを用いる場合、ウェブサーバへのアクセスを行う前に、ＤＮＳサーバへアクセスして、ＦＱＤＮからＩＰアドレスを取得する名前の解決を行う必要があるが、この発明にかかるＵＲＬフィルタリング装置であるパケット転送装置は、そのＤＮＳ要求を受けた段階又はその前段階で、そのＦＱＤＮを含んで指定されるアドレスの安全性を上記ＡＣサーバに問い合わせる。ＤＮＳ要求を解決する前であればＦＱＤＮのみで問い合わせ、ＤＮＳ要求を解決した後ならばＩＰアドレスのみ、又はＦＱＤＮとＩＰアドレスとを併せて問い合わせる。上記ＡＣサーバは、ＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとに、その接続対象のウェブサーバが健全、すなわち全てのコンテンツが安全であると確認されているものを記録しており、問い合わせに対して、そのアドレスで指定されるウェブサーバが安全であるか否かの情報を返答する。この返答を受けたＵＲＬフィルタリング装置は、ユーザ端末にＩＰアドレスを返答するとともに、そのＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスが安全であることを、内部のデータベース（ＩＰフィルタリング可否テーブル）に登録しておくとよい。ＦＱＤＮとＩＰアドレスとの両方で登録しておいてもよい。

引き続いてユーザ端末から、当該ＩＰアドレスへのアクセス要求がＩＰフィルタリング装置へ送信された際には、ＴＣＰ層パケット処理部は、ＩＰフィルタリング可否テーブルを参照し、その要求先のＦＱＤＮ及びＩＰアドレスが安全であると登録されている場合は、当該アクセス要求によって始まるＴＣＰセッションについては、ファストパスでパケット転送を行う条件を満たすものとして、ファストパス判断テーブルに登録する。当該ＦＱＤＮ及びＩＰアドレスで指定されるウェブサーバの全てのコンテンツが安全であると保証されているため、個々のアドレスをチェックするまでもなく、ファストパスで処理して問題ないためである。これにより、当該セッションにおけるアクセス要求は、パケット転送処理部がファストパスで処理することにより、安全性を維持しつつ高い転送性能を発揮できる。

また、ＩＰアドレスへの直接的なアクセス要求の前に送信される名前の解決の段階でＡＣサーバに問い合わせ始めるため、アクセス要求を受けてからフィルタリングのチェックをする従来の方法に比べて、タイムラグを短縮でき、この点でも転送性能を高めることができる。

なお、ＡＣサーバへの問い合わせは、必ずしもＩＰアドレスが必須ではない。このため、ＡＣサーバがＦＱＤＮについて登録されているのであれば、ＤＮＳの名前の解決より先に、ＦＱＤＮの安全性をＡＣサーバに問い合わせてもよい。この場合、要求ドメイン通過判定処理部での問い合わせの後に、ＤＮＳ−ｐｒｏｘｙ処理部２０へＤＮＳ要求を解決するための指示を出すことになる。

上記のＩＰフィルタリング可否テーブルへの登録は、それが安全であると回答できる有効期限情報を有していてもよい。ウェブサーバの更新によって安全性が失われる場合があるためである。有効期限が切れた情報については、要求ドメイン通過判定処理部が再びＡＣサーバへ問い合わせて、ステータス及び有効期限を更新するとよい。

なお、ＦＱＤＮとＩＰアドレスによる判定だけでなく、従来通りＵＲＬごとに判断するフィルタリング機能を備えていてもよい。ＦＱＤＮ及びＩＰアドレスごと安全であるとは判断されず、一部に安全性が不明瞭なページが存在するようなＩＰアドレスへのアクセスにあたっては、従来通りのフィルタリング機能を発揮させるべきだからである。逆に、ＦＱＤＮ及びＩＰアドレスがまるごと危険であると登録して、当該ＩＰアドレスへのアクセスを最初から全て遮断してもよい。

なお、ファストパスで処理せず、フィルタリングの結果として規制されたアドレスへのアクセスであることが判明した場合、単純にアクセスを遮断するだけでなく、アラートを表示させたり、一部内容の差し替えなどを行ってもよい。

この発明により、アップロード及びダウンロードの区別なく、FQDNとIPアドレスが安全であると保証されたウェブサーバへのアクセスに対して、ファストパスで処理できるパケットの数を増やし、ＵＲＬフィルタリング装置の転送処理性能を向上させることができる。安全の前提となるＡＣサーバへの問い合わせは、IPアドレスによるアクセス要求よりも早く行われるため、フィルタリングのための問い合わせにかかる待ち時間も従来より短縮され、体感的な転送性能も向上させることができる。

この発明にかかるＵＲＬフィルタリング装置の機能ブロック図 この発明にかかるＵＲＬフィルタリング装置の初期のフロー例の図 ＩＰフィルタリング可否テーブルへの登録可否を得る際のフロー例の図 ＩＰフィルタリング可否テーブルの例図 この発明にかかるＵＲＬフィルタリング装置の機能フロー例の前半図 この発明にかかるＵＲＬフィルタリング装置の機能フロー例の後半図 ファストパス登録機能を実行する際のフロー図

以下、この発明について具体的な実施形態の例を挙げて詳細に説明する。
図１は、この発明にかかるＵＲＬフィルタリング装置１１の機能ブロック図及びそれと通信する装置について示す構成図である。

ＵＲＬフィルタリング装置１１は、ユーザ端末１２と、ウェブサーバ１３との間にある中継装置であり、例えば家庭用ルータなどのホームゲートウェイのようなゲートウェイとして機能する装置である。具体的には、ユーザ端末１２からのＨＴＴＰ通信と、ウェブサーバ１３からのＨＴＴＰ通信を中継するとともに、別途運営されているアクセス規制対象となるＵＲＬリストのデータベースを保有するセキュリティサーバ１４に当該ＨＴＴＰ通信のアクセス要求先へのアクセスが規制されているか否かを確認し、規制されている場合にはそのアクセスを遮断する装置である。

ユーザ端末１２は、パソコン、スマートフォン、タブレット端末など、ＦＱＤＮを利用して通信するプロトコルを使用する端末であれば特に限定されない。ここでは、ＨＴＴＰ通信機能４５を例として説明するが、ＨＴＴＰＳやＦＴＰなど、実際のプロトコルは特に限定されない。このＨＴＴＰ通信機能４５とは、例えばインターネットブラウザや、その他のネット接続機能を有するプログラムが挙げられる。

ウェブサーバ１３は、ユーザ端末１２からのリクエストに応じてコンテンツを送信するＨＴＴＰサーバ機能を有するサーバである。図１中では一つであるが、実際には多数のサーバがインターネット上に存在しており、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）によって指定される。

セキュリティサーバ１４は、アクセスを規制するページのアドレスを保有するデータベースを有し、ＵＲＬフィルタリング装置１１からの照会に対して、それがフィルタリングで遮断すべきページか否かを応答可能なサーバである。例えば、セキュリティ会社などが運営するものであったり、会社内で独自に用意するものであったりしてもよい。

ＤＮＳサーバ１５は、ユーザ端末１２で普段入力されるＦＱＤＮ（ドメイン名）に対応するＩＰアドレスを調べて、ユーザ端末１２からの問い合わせに対して名前の解決を行い、ＩＰアドレスを返すことができるＤＮＳキャッシュサーバである。サーバ自身が記録しているＦＱＤＮとＩＰアドレスとの組み合わせから検索して応答するだけでなく、他のＤＮＳキャッシュサーバへリクエストを中継して、名前を解決する場合もある。

ＡＣサーバ１６は、ＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとに、そのアドレスで指定されるウェブサーバに含まれる全てのコンテンツが安全であれば、接続が安全である旨を記録し、問い合わせに対してその旨を返答可能なサーバである。逆に、当該ウェブサーバにある全てのコンテンツが安全であると保証できなければ、ＮＧを返す。なお、安全であるとの返答については、その安全性を保証する有効時間を設定してあることが好ましい。ウェブサーバ１３上の情報は刻々と変化するため、以前安全だったウェブサーバ１３が永続的に安全であるとは限らないからである。上記のセキュリティサーバ１４と同様に、セキュリティ会社などが運営するものであったり、会社内で独自に用意するものであったりしてもよい。
なお、ＡＣサーバ１６とセキュリティサーバ１４とは、物理的には同一のサーバがそれぞれの機能を有するものであってもよい。

これらの装置間での通信に対して、ＵＲＬフィルタリング装置１１は、通過するパケットに対してルーティング機能４１を発揮するパケット転送処理部２１と、パケットのＴＣＰ層の処理を行う処理を行うＴＣＰ層パケット処理部２２と、パケットのデータ部内にあるＨＴＴＰ構文を解析するＨＴＴＰ構文解析処理部２３と、セキュリティサーバ１４に照会して接続要求先のアドレスが遮断されるべきものか否かを判定する要求アドレス通過判定処理部２４と、遮断する際のエラーメッセージや代替テキストを供給するＨＴＴＰ応答作成処理部２５と、ＴＣＰ終端処理を行うＴＣＰ終端処理部２６と、後述するファストパス機能４２を実行してファストパスを行うか否かの条件を一時的に保持するファストパス判断テーブル２７と、
ユーザ端末１２からのＤＮＳ要求に含まれるＦＱＤＮをＤＮＳサーバ１５に問い合わせて名前の解決を行うＤＮＳ−ｐｒｏｘｙ処理部２０と、
ＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとの安全性をＡＣサーバ１６へ問い合わせ、安全であると判明したＩＰアドレスを登録させる要求ドメイン通過判定処理部２８と、
上記の要求アドレス通過判定処理部２４により、安全との返答を得たサーバのアドレスを登録し、照会に対して回答可能なＩＰフィルタリング可否テーブル２９とを有する。

このうち各部（２０〜２６、２８）は独立したチップでもよいし、ソフトウェア上で実現するものでもよい。ＵＲＬフィルタリング装置１１は、これらを実現するための処理部たるプロセッサと、記憶部たる揮発性メモリ及び不揮発性メモリを有する。このうち、プロセッサはパケットのヘッダ部分のみを読み取って高速で転送処理を行う、いわゆる「ファストパス」機能を有するものである必要がある。また、ファストパス判断テーブル２７及びＩＰフィルタリング可否テーブル２９は、記憶部に存在するテーブルデータである。

ＵＲＬフィルタリング装置１１は、ユーザ端末１２からウェブサーバ１３へ向かうアップリンクのデータの経路であるアップパケット経路５１と、ウェブサーバ１３からユーザ端末１２へのダウンリンクのデータ経路であるダウンパケット経路５２とを有する。
なお、アップパケット終端経路５３はユーザ端末１２からＵＲＬフィルタリング装置１１への上り方向の終端処理を行う場合の経路であり、ダウンパケット終端経路５４は、ウェブサーバ１３からＵＲＬフィルタリング装置１１への下り方向の終端処理を行う場合の経路である。
そして、後述する工程を経てファストパスでの通過を行うと判断されたパケットは、ＴＣＰ層パケット処理部２２を通らずに、パケット転送処理部２１を高速で転送処理される、アップパケットファストパス経路５５及びダウンパケットファストパス経路５６を有する。なお、図１中では表記上、５５と５６をまとめる。

本願発明において、ファストパス機能４２を発揮させてアップパケットファストパス経路５５及びダウンパケットファストパス経路５６で通過させるか否かの判断は、上記の経路のうち、アップパケット経路５１と、ダウンパケット経路５２を通るパケットに対して実行する。

これらの構成を有するＵＲＬフィルタリング装置１１の動作を、図２を用いて、情報処理の流れに沿って説明する。まず（Ｓ１００）、ユーザ端末１２のＨＴＴＰ通信機能４５は、ＨＴＴＰ通信を行うＴＣＰセッションの確立の前に、ＤＮＳによるＦＱＤＮの名前の解決を行うべく、ＤＮＳ要求をＵＲＬフィルタリング装置１１へ送信する（Ｓ１０１）。ＵＲＬフィルタリング装置１１のパケット転送処理部２１は、このＤＮＳ要求をＤＮＳ−ｐｒｏｘｙ処理部２０へ転送するＤＮＳ要求転送機能４３を実行する（Ｓ１０２）。

ＤＮＳ−ｐｒｏｘｙ処理部２０は、転送されてきたＤＮＳ要求に含まれるＦＱＤＮを、ＤＮＳサーバ１５へ問い合わせるＤＮＳ要求問合機能３１を実行する（Ｓ１０３）。なお、図示しないが、ＵＲＬフィルタリング装置がＤＮＳキャッシュ機能を有しているのであれば、そのキャッシュを参照してＤＮＳの名前の解決を行ってもよい。ＤＮＳサーバ１５は、自身が保有する情報を検索するか、又は他のＤＮＳキャッシュサーバに問い合わせて、問い合わせされたＦＱＤＮに対応するＩＰアドレスを求める名前の解決を行い、ＵＲＬフィルタリング装置１１のＤＮＳ−ｐｒｏｘｙ処理部２０へ返答するＤＮＳ要求返答機能３２を実行する（Ｓ１０４）。返答されたＩＰアドレスを受信したＤＮＳ−ｐｒｏｘｙ処理部２０は、要求のあったユーザ端末１２へ当該ＦＱＤＮの名前の解決としてＩＰアドレスを送信するＤＮＳ要求回答機能３３を実行する（Ｓ１０５）。このＩＰアドレスを受信したユーザ端末１２は、後述するセッションの確立へ移る（Ｓ１０８）。また、それと前後して、ＤＮＳ−ｐｒｏｘｙ処理部２０は、当該ＦＱＤＮ及び解決されたＩＰアドレスを、要求ドメイン通過判定処理部２８へ転送するネームアドレス転送機能３４を実行する（Ｓ１０６〜Ｓ１０７）。

要求ドメイン通過判定処理部２８の処理を、図３を用いて説明する。まず、ＤＮＳ−ｐｒｏｘｙ処理部２０からＦＱＤＮ及びＩＰアドレスを受信する（Ｓ１０７〜Ｓ１１１）。この受信した情報を、ＡＣサーバ１６へ送信し、当該ＩＰアドレスで示されるサーバから送信されるページが全て安全なものと保証されているか、そうでないかを問い合わせるネームアドレス問合機能３６を実行する（Ｓ１１２）。これに対してＡＣサーバ１６は、当該ＦＱＤＮ及びＩＰアドレスで指定されるサーバが健全である、すなわち、送信されるすべてのコンテンツが安全であると確認されている場合にはＯＫを、そうでない場合にはＮＧを返す。このとき、ＡＣサーバ１６はＯＫ又はＮＧの結果とともに、その判定を保証する有効期限を送信するものであると好ましい。実際にはウェブサーバ１３上のファイルは刻々と変化するため、長期間に亘って安全性を保証できるものではないからである。

ＡＣサーバ１６からの返答がＮＧであるとＯＫであるとに関わらず、要求ドメイン通過判定処理部２８は、その結果をＩＰフィルタリング可否テーブル２９に登録するネームアドレス登録機能３７を実行する（Ｓ１１３）。このテーブルの例を図４に示す。ＦＱＤＮ及びＩＰアドレスとの対応とともに、ＩＰフィルタリング可否テーブル２９への登録時間と、有効期限、判定結果を記録してあり、その判定の残り時間が刻々と更新される。この登録でDNS要求に対する処理は一旦終了し、その後、通常のTCPセッションの処理へ移る（１１４）。

ただし、要求ドメイン通過判定処理部２８は、上記のＩＰフィルタリング可否テーブル２９の健全性を維持させるため、これを更新する必要がある。このため、要求ドメイン通過判定処理部２８は、定期的にＩＰフィルタリング可否テーブル２９に含まれるＦＱＤＮごとの各レコードについて、有効期限及び残り時間を確認するネームアドレス確認機能３８を実行する（Ｓ１１５）。有効期限を超過したレコードについては（Ｓ１１６）、ＦＱＤＮ及びＩＰアドレスをまとめて、再びネームアドレス問合機能３６を実行し（Ｓ１１２）、その結果をネームアドレス更新機能３９により更新する（Ｓ１１３）。

なお、要求ドメイン通過判定処理部２８とＤＮＳ−ｐｒｏｘｙ処理部２０との処理は逆でもよい。この場合、上記とは図２と図３とのフロー処理順が逆になる。すなわち、パケット転送処理部２１が、ＤＮＳ要求をＤＮＳ−ｐｒｏｘｙ処理部２０ではなく要求ドメイン通過判定処理部２８へ転送するＦＱＤＮ問合機能４７を実行し、要求ドメイン通過判定処理部２８はＤＮＳ要求に含まれるＦＱＤＮについてＡＣサーバ１６へ問い合わせるネームアドレス問合機能３６を実行する。ＯＫ又はＮＧの結果が返ってきたら、要求ドメイン通過判定処理部２８はＤＮＳ−ｐｒｏｘｙ処理部２０へＤＮＳ要求を解決すべく指示するＤＮＳ要求指示機能４０を実行し、ＤＮＳ−ｐｒｏｘｙ処理部２０は解決したＩＰアドレスを要求ドメイン通過判定処理部２８に返すネームアドレス転送機能３４を実行する。つまり順序が逆になってもこの発明は問題なく実行できる。

また、図示しないが、ＩＰフィルタリング可否テーブル２９のレコード数が過剰になると検索に支障が出るため、レコード数が一定数以上になったら、リスト登録時間が古いものから削除しておくとよい。

次に、ＴＣＰセッション以降のフローについて図５及び図６を用いて説明する。これは上記のＳ１０８（図２）、及びＳ１１４（図３）に引き続く処理である（Ｓ１２１）。ユーザ端末１２は、上記のＤＮＳ要求で得られたＩＰアドレスで指定されるウェブサーバ１３に対して、ＨＴＴＰ通信の前に、３ｗａｙ−ｈａｎｄｓｈａｋｅにより新規なTCPセッションを確立する（Ｓ１２２）。すなわち、ユーザ端末１２が、接続要求であるＳＹＮパケットをＵＲＬフィルタリング装置１１経由でウェブサーバ１３に送信し、ウェブサーバ１３は接続許可であるＡＣＫパケットと、接続要求であるＳＹＮパケットとを組み合わせてユーザ端末１２に返送する。これに対してユーザ端末１２がＡＣＫパケットを返答する。以上の三手順を経てユーザ端末１２とウェブサーバ１３との間のコネクションが確立する。より具体的には、このときパケット転送処理部２１は、受信するパケットのプロトコルの種別、宛先と送信元のＩＰアドレス及びポート番号等に基づいて、ＨＴＴＰセッションに属するＴＣＰパケットを判別し、ＨＴＴＰセッションであると判別されたＴＣＰパケットをＴＣＰ層パケット処理部２２に通知するセッションパケット抽出機能４６を実行する。ＴＣＰ層パケット処理部２２は、パケット転送処理部２１から受け取ったパケットが、３ｗａｙ−ｈａｎｄｓｈａｋｅのためのパケットであると判別したらこれをそのままパケット転送処理部２１へ出力する開始パケット経過機能６２を実行し、パケット転送処理部２１はルーティング機能４１によりこれをそれぞれの宛先（ユーザ端末１２又はウェブサーバ１３）へ向けて転送する。これが一往復半されて３ｗａｙ−ｈａｎｄｃｈａｋｅが成立する。

ＴＣＰセッションが確立した後、ユーザ端末１２は、ブラウザソフトその他のソフトが有するＨＴＴＰ通信機能４５により、アクセスを要求するＨＴＴＰメソッド及びＵＲＬを含むＴＣＰパケットを送信する（Ｓ１２３）。ＨＴＴＰメソッドは、一般的には、ダウンリンクであればＧＥＴであり、アップリンクであればＰＯＳＴである。このＴＣＰパケットを受信したＵＲＬフィルタリング装置１１は次のような処理を行う。

ＴＣＰパケットを受信したパケット転送処理部２１は、当該ＴＣＰパケットにかかるＴＣＰセッションが、なんらかの形でファストパスにて処理する対象としてファストパス判断テーブル２７に登録されているか否かを判断するファストパスチェック機能４４を実行する（Ｓ１２４）。なお、ファストパス判断テーブルには、送信元ＩＰアドレス、宛先ＩＰアドレスを記録しておくことが必要であり、プロトコルの種別やポート番号を備えていると、他の基準によるファストパス判断にも用いることができるので好ましい。既にファストパス処理するものであると登録されていれば（Ｓ１２４→Ｓ１３３）、当該ＴＣＰセッションについてそのままファストパス機能４２による処理を続ける（Ｓ１３４）。

まだファストパス判断テーブル２７に当該ＴＣＰセッションの判断が登録されていない場合（Ｓ１２４）、パケット転送処理部２１のセッションパケット抽出機能４６が、この受信したＴＣＰパケットをＴＣＰ層パケット処理部２２に転送する（Ｓ１２６）。

ＴＣＰ層パケット処理部２２は、ＴＣＰパケットを一旦保持したまま、ファストパス登録機能を実行するか否かを判断する（Ｓ１３１）。このＴＣＰ層パケット処理部２２におけるファストパス登録機能６１を実行するか否かを判断するファストパス判断フローを図７に示す。ＴＣＰセッションが確立（上記のＳ１２２にあたる）した後、ファストパス処理を行うとの登録をするか否かをチェックする。まず、本発明におけるＡＣサーバ１６と連携する以外の方法で、この時点でファストパス処理の対象と診断されるか否かを判断する既存ファストパスチェック機能６３を実行する（Ｓ２１１）。該当するのであれば、ファストパス判断テーブル２７に、当該ＴＣＰセッションはファストパスで処理する旨の登録をするファストパス登録機能６１を実行する（Ｓ２１２）。

次に、ＩＰフィルタリング可否テーブル２９に対して、当該ＴＣＰセッションに対応するＩＰアドレスについてのレコードの有無を問い合わせる、可否テーブル検索機能６４を実行する（Ｓ２１３）。このとき、該当するＩＰアドレスについてのレコードが存在しない場合、上記のＡＣサーバ１６への問い合わせを経たＩＰフィルタリング可否テーブル２９への登録が何らかの理由で失敗しているか、又は遅延している。そこで、ＴＣＰ層パケット処理部２２は、要求ドメイン通過判定処理部２８に対して、ネームアドレス問合機能３６（図３のＳ１１２）、及びネームアドレス登録機能３７（図３のＳ１１３）を実行するように、ＩＰアドレスとともに指示を出すネームアドレス再確認要求機能６５を実行する（Ｓ２１４）。要求後は所定の時間を待った上で（Ｓ２１５）、ＩＰフィルタリング可否テーブル２９へのＯＫ又はＮＧのレコードの登録を待ってフローを再開する（Ｓ２１３〜）。

なおここで、要求ドメイン通過判定処理部２８は、ＡＣサーバ１６からの返答後、ＩＰフィルタリング可否テーブル２９への登録を行う。

上記可否テーブル検索機能６４の実行により、ＩＰフィルタリング可否テーブル２９内にレコードが見つかり（Ｓ２１３→Ｓ２２１）、レコード中の判定結果がＯＫであれば、当該ＴＣＰセッションについてはファストパスで処理する旨をファストパス判断テーブル２７に登録するファストパス登録機能６１を実行する（Ｓ２１２）。一方、レコード中の判定結果がＮＧであれば、当該ＴＣＰセッションについてはファストパスではなくスローパスで処理するものとし、ファストパス判断テーブル２７に登録しない（Ｓ２２２）。

上記の登録か否かの判断が終わったら（図５のＳ１３１）、ＴＣＰ層パケット処理部２２は、そこまで保持していたＴＣＰパケットが、ファストパス判断テーブル２７に、ファストパスの対象として登録されているか否かを確認する判断テーブル検索機能６６を実行する。ファストパスの対象として登録されていれば、ＴＣＰ層パケット処理部２２は、保持していたパケットをパケット転送処理部２１へ返送するパケット返送機能６９を実行し（Ｓ１３３）、以後はアップパケット経路５１又はダウンパケット経路５２をファストパスで通過させるように登録する（Ｓ１３４）。

上記のように、ファストパスで通過させるように登録されたパケットが、パケット転送処理部２１に到達したら、パケット転送処理部２１はファストパス判断機能４８を実行して、ファストパス判断テーブル２７を参照し、それがファストパスの対象であるＴＣＰセッションのパケットならば、ファストパスで処理するアップパケットファストパス経路５５又はダウンパケットファストパス経路５６にて、速やかな転送処理を行うこととなる。

一方、ファストパスの対象として登録されていなければ、以下に続くフローにより、個別のＵＲＬフィルタリングを実行するとよい。ＴＣＰ層パケット処理部２２は、そのＴＣＰパケットを保持しながらＴＣＰパケットのデータ部（ペイロード）を抽出するペイロード抽出機能６７を実行し（Ｓ１４１）、抽出したペイロードをＨＴＴＰ構文解析処理部２３へ送るペイロード転送機能６８を実行する（Ｓ１４２）。

なおここで、ペイロードとしてＵＲＬを抽出した際には、そのＵＲＬについてキャッシュ３０に問い合わせるキャッシュ問合機能７０を実行するとよい。後述するように既に判定が終わっているＵＲＬへの二度目のアクセスである場合に、以下に記載のＨＴＴＰ構文解析処理部２３や要求アドレス通過判定処理部２４での処理を行うまでもなく、速やかに遮断すればよいからである。よって、問い合わせの結果、当該ＵＲＬへのアクセスが不可であれば、ＴＣＰ層パケット処理部２２は、ＨＴＴＰ応答作成処理部２５へ直接に、拒否対応指示機能８６（後述する８３と同様の内容）を実行すると速やかな処理ができる。

ＨＴＴＰ構文解析処理部２３では、まず受け取ったペイロードがＨＴＴＰであるか否かを判断するＨＴＴＰ判別機能７１を実行する（Ｓ１４３）。ペイロードがＨＴＴＰでなかったら、そのセッションの通信はＨＴＴＰではないということであり、以後そのセッションのデータは中身を解析しようがないので、ファストパスで処理すればよい。そこでＨＴＴＰ構文解析処理部２３のファストパス通達機能７２は、ＴＣＰ層パケット処理部２２へ、当該セッションをファストパスで処理するように通知する（Ｓ１４４）。ＴＣＰ層パケット処理部２２は、ファストパス登録機能６１を実行して、ファストパス判断テーブル２７に、当該セッションをファストパスで処理する旨を登録する（Ｓ１４５）。その上で、ＴＣＰ層パケット処理部２２は、保持していたパケットをパケット転送処理部２１へ返送するパケット返送機能６９を実行し（Ｓ１３３）、以後はアップパケット経路５１又はダウンパケット経路５２をファストパスで通過させるように登録する（Ｓ１３４）。

なお、上記のフローのさらに例外として（Ｓ１４３）、ＴＣＰ層パケット処理部が受け取ったパケットが、ＴＣＰ層のヘッダまでしか存在せず、ペイロードが実質的に存在していない場合は、そのパケットをＴＣＰ層で終端するように、ＴＣＰ層終端処理部２６へ要求する終端処理指示機能９８を実行する。

上記のＨＴＴＰ判別機能７１での判断においてペイロードがＨＴＴＰであれば（Ｓ１４３）、ＨＴＴＰ構文解析処理部２３は、ＧＥＴ又はＰＯＳＴのＨＴＴＰメソッドとしてＨＴＴＰ構文の一行目に記載されているアドレスを、要求アドレス通過判定処理部２４へ転送する判定要求機能７３を実行する（Ｓ１５１）。なお、この判定要求機能７３はＨＴＴＰヘッダを全て受信してから実行してもよいが、アドレスはＨＴＴＰ構文の一行目にあるため、一行目を受信した段階でこの判定要求機能７３を実行してもよい。

要求アドレス通過判定処理部２４は、転送されてきたアドレスについて、規制対象となるアドレス群を記録した規制対象データベースを有するセキュリティサーバ１４に対して、規制対象のアドレスであるか否かを照会する接続可否問合機能８１を実行する（Ｓ１５２）。セキュリティサーバ１４はこの照会に対して、規制対象データベースを検索して、規制対象であるか否かを返答する接続可否返答機能８２を実行する（Ｓ１５３）。なお、規制対象データベースは必ずしも外部サーバに置いておく必要はなく、応答速度を優先するためにＵＲＬフィルタリング装置１１内に保持していてもよい。ただし、規制対象となるアドレスの更新等、装置への負担はかかる。

上記の接続可否返答機能８２による返答が、規制対象であるとの内容であった場合（Ｓ１５４→Ｓ１６１）、要求アドレス通過判定処理部２４は、ＨＴＴＰ応答作成処理部２５に対して、その結果を通知するとともにＴＣＰ終端処理の開始を指示する拒否対応指示機能８３を実行する（Ｓ１６２）。ＨＴＴＰ応答作成処理部２５は、通知された結果に対応する応答メッセージが含まれるＨＴＭＬドキュメントを生成するメッセージ生成機能９１を実行する（Ｓ１６３）。応答メッセージとしては、規制対象であることを示す「４０３ ｆｏｒｂｉｄｄｅｎ」であったり、それに関連する英語や日本語等の説明を加えたＨＴＭＬドキュメントであるとよい。またそれとともにＨＴＴＰ応答作成処理部２５は、ＴＣＰ終端処理部２６へＴＣＰ終端処理の開始を指示する終端処理指示機能９２を実行し（Ｓ１６４）、作成したＨＴＭＬドキュメントを送信する。

ＴＣＰ終端処理部２６は、ユーザ端末１２との通信経路を、アップパケット終端経路５３に変更させ、ウェブサーバ１３との通信経路をダウンパケット終端経路５４に変更する経路終端変更機能９３を実行する（Ｓ１６５）。その上で、ＨＴＴＰ応答作成処理部が生成したメッセージをユーザ端末１２へ送信するアクセス拒否通知機能９４を実行するとともに（Ｓ１６６）、ユーザ端末１２に対して当該ＴＣＰセッションの終端処理を行う端末切断機能９５を実行する（Ｓ１６７）。具体的には、ＦＩＮ／ＡＣＫパケットの往復による。さらに、ウェブサーバ１３に対しても、当該ＴＣＰセッションの終端処理を行うサーバ切断機能９６を実行する。これも具体的にはＦＩＮ／ＡＣＫパケットの往復による（Ｓ１６７）。その上で、当該ＵＲＬへのアクセスが不可である情報を、ＵＲＬ又はＨＴＴＰの構文情報とともにキャッシュ３０に記録するキャッシュ記録機能９７を実行する（Ｓ１６８）。キャッシュ３０は時間制限付きでこれらの情報をデータベースとして保持する。これで当該ＴＣＰセッションは終了する（Ｓ１６９）。なお、これらの終端処理とキャッシュ３０への書き込みとは順番が前後してもよい。

次に、上記の接続可否返答機能８２による返答が、規制対象ではないとの返答であった場合（Ｓ１６１）、要求アドレス通過判定処理部２４は、保持したままのパケットの転送許可をＴＣＰ層パケット処理部２２へ指示する許可対応指示機能８４を実行する（Ｓ１７１）。その上で、当該ＨＴＴＰメッセージの終わりまで、通常のルーティング機能４１で転送処理し（Ｓ１７２）、次のＨＴＴＰ通信が開始となったら同様の手順を繰り返す（Ｓ１７３→Ｓ１２３）。

１１ ＵＲＬフィルタリング装置
１２ ユーザ端末
１３ ウェブサーバ
１４ セキュリティサーバ
１５ ＤＮＳサーバ
１６ ＡＣサーバ
２０ ＤＮＳ−Ｐｒｏｘｙ処理部
２１ パケット転送処理部
２２ ＴＣＰ層パケット処理部
２３ ＨＴＴＰ構文解析処理部
２４ 要求アドレス通過判定処理部
２５ ＨＴＴＰ応答作成処理部
２６ ＴＣＰ終端処理部
２７ ファストパス判断テーブル
２８ 要求ドメイン通過判定処理部
２９ ＩＰフィルタリング可否テーブル
３０ キャッシュ
３１ ＤＮＳ要求問合機能
３２ ＤＮＳ要求返答機能
３３ ＤＮＳ要求回答機能
３４ ネームアドレス転送機能
３６ ネームアドレス問合機能
３７ ネームアドレス登録機能
３８ ネームアドレス確認機能
３９ ネームアドレス更新機能
４０ ＤＮＳ要求指示機能
４１ ルーティング機能
４２ ファストパス機能
４３ ＤＮＳ要求転送機能
４４ ファストパスチェック機能
４５ ＨＴＴＰ通信機能
４６ セッションパケット抽出機能
４７ ＦＱＤＮ問合機能
４８ ファストパス判断機能
５１ アップパケット経路
５２ ダウンパケット経路
５３ アップパケット終端経路
５４ ダウンパケット終端経路
５５ アップパケットファストパス経路
５６ ダウンパケットファストパス経路
６１ ファストパス登録機能
６２ 開始パケット経過機能
６３ 既存ファストパスチェック機能
６４ 可否テーブル検索機能
６５ ネームアドレス再確認要求機能
６６ 判断テーブル検索機能
６７ ペイロード抽出機能
６８ ペイロード転送機能
６９ パケット返送機能
７０ キャッシュ問合機能
７１ ＨＴＴＰ判別機能
７２ ファストパス通達機能
７３ 判定要求機能
８１ 接続可否問合機能
８２ 接続可否返答機能
８３ 拒否対応指示機能
８４ 許可対応指示機能
８６ 拒否対応指示機能
９１ メッセージ生成機能
９２ 終端処理指示機能
９３ 経路終端変更機能
９４ アクセス拒否通知機能
９５ 端末切断機能
９６ サーバ切断機能
９７ キャッシュ記録機能

Claims (5)

1. ユーザ端末とウェブサーバとのＨＴＴＰプロトコルを用いた通信に対してＵＲＬフィルタリングを行う、ファストパス機能を有するＵＲＬフィルタリング装置であって、
   上記ユーザ端末と上記ウェブサーバとの間で送受信されるパケットを中継するパケット転送処理部と、
   パケット転送処理部を通過するＴＣＰパケットのヘッダ部分を読み取りＴＣＰ層の処理を行うＴＣＰ層パケット処理部と、
   上記ファストパス機能によってファストパスを行うか否かの条件を一時的に保持するファストパス判断テーブルと、
   ユーザ端末からウェブサーバへの接続を実施する前に上記ウェブサーバのＦＱＤＮ（Fully Qualified Domain Name）の名前を解決するために上記ユーザ端末から送信されるＤＮＳ要求を受けＤＮＳサーバに問い合わせてＩＰアドレスを取得するＤＮＳ−ｐｒｏｘｙ処理部と、
   上記ＤＮＳ要求に含まれるＦＱＤＮ及び前記取得したＩＰアドレスの少なくとも一方で指定されるについて、外部に設けたＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとの安全性を記録し安全であればその旨を返答可能なＡＣサーバに対して、問い合わせを行う要求ドメイン通過判定処理部と
   を備えており、
   上記ＴＣＰ層パケット処理部は、上記のＦＱＤＮ及びＩＰアドレスの少なくとも一方で指定されるアドレスごとの安全性の記録を参照して、安全であるとの返答を得ているＩＰアドレスへの通信セッションを上記ファストパス機能によって行う条件を上記ファストパス判断テーブルへ登録するファストパス登録機能を実行し、
   上記パケット転送処理部は、受信したパケットについて上記ファストパス判断テーブルのファストパス条件に合致するパケットをファストパスさせるファストパス判断機能を実行するＵＲＬフィルタリング装置。
2. 上記要求ドメイン通過判定処理部が安全であるとの返答を受けたＩＰアドレスについて、そのＩＰアドレスへのアクセスが安全であることを記録したＩＰフィルタリング可否テーブルを有し、
   上記ファストパス登録機能は、上記ＩＰフィルタリング可否テーブルの記録を参照して上記ファストパス判断テーブルへの登録を行う、
   請求項１に記載のＵＲＬフィルタリング装置。
3. 上記要求ドメイン通過判定処理部は、上記ＩＰフィルタリング可否テーブルに安全であると記録したＩＰアドレスについて、上記ＡＣサーバへその安全性を問い合わせて、安全性が確認できれば記録を期限つきで更新し、安全性が確認できなければ上記ＩＰフィルタリング可否テーブルにおける当該ＩＰアドレスについてのレコードを無効にする、ネームアドレス更新機能を定期的に実行する、
   請求項２に記載のＵＲＬフィルタリング装置。
4. 上記ＴＣＰパケットのデータ部分に含まれるＨＴＴＰ構文を読み取り解析を行うＨＴＴＰ構文解析処理部と、
   上記の解析されたＨＴＴＰ構文に含まれるＵＲＬへのアクセスを通過させるか否かを判定処理する要求アドレス通過判定処理部とを有し、
   上記ファストパスをさせないＴＣＰパケットについて、個別にＵＲＬフィルタリングを行う、
   請求項１乃至３のいずれかに記載のＵＲＬフィルタリング装置。
5. 上記ユーザ端末と上記ウェブサーバとの間に設けた請求項１乃至４に記載のＵＲＬフィルタリング装置と、
   上記ＵＲＬフィルタリング装置と通信可能である上記ＤＮＳサーバ及び上記ＡＣサーバとからなる、
   ＵＲＬフィルタリングシステム。

Images