(57)【要約】【解決手段】分散システムにおける要求処理のための方法は、複数のアプリケーションサーバにおいてイベント要求情報を取得し、該イベント要求情報の少なくとも一部は、クライアント端末から送信されユニフォームリソースロケータ（Uniform Resource Locator, URL）リソースに対応するリソースアクセス要求に関し、前記イベント要求情報をアンチ攻撃サーバに転送し、前記イベント要求情報の少なくとも一部に少なくとも部分的に基づいて、前記クライアント端末によって所定期間内になされた前記ＵＲＬリソースへのアクセス要求の総数を決定し、上記決定されたアクセス要求の総数及び所定のアクセスルールに少なくとも基づいて、上記クライアント端末によって異常なアクセス要求がなされたかどうかを判定することを含む。【選択図】図１
2012507065.tif 000002
【特許請求の範囲】
【請求項１】
分散システムにおける要求処理のための方法であって、
複数のアプリケーションサーバにおいてイベント要求情報を取得し、前記イベント要求情報の少なくとも一部は、クライアント端末から送信され、ユニフォームリソースロケータ（Uniform Resource Locator, URL）リソースに対応するリソースアクセス要求に関し、
前記イベント要求情報をアンチ攻撃サーバに転送し、
前記イベント要求情報の少なくとも一部に少なくとも部分的に基づいて、前記クライアント端末によって所定期間内になされた前記ＵＲＬリソースへのアクセス要求の総数を決定し、
前記決定されたアクセス要求の総数及び所定のアクセスルールに少なくとも基づいて、前記クライアント端末によって異常なアクセス要求がなされたか否かを判定すること、
を備える方法。
【請求項２】
請求項１に記載の方法であって、
前記イベント要求情報の少なくとも一部は、前記アクセス要求が受信されたときの時刻情報、目標ＵＲＬ、及び前記クライアント端末の識別情報を含む、方法。
【請求項３】
請求項１に記載の方法であって、
前記イベント要求情報の少なくとも一部は、前記アプリケーションサーバの少なくとも一部に格納された既知の悪意あるクライアント端末のブラックリストと比較される、方法。
【請求項４】
請求項１に記載の方法であって、
前記イベント要求情報の少なくとも一部に含まれる目標ＵＲＬが、保護下にある目標ＵＲＬのセットと比較される、方法。
【請求項５】
請求項１に記載の方法であって、
前記クライアント端末によって異常なアクセス要求がなされなかったと判定された場合に、前記方法は、更に、前記イベント要求情報の少なくとも一部を正常に処理することを備える方法。
【請求項６】
請求項１に記載の方法であって、
前記クライアント端末によって異常なアクセス要求がなされたと判定された場合に、前記方法は、更に、前記クライアント端末の識別情報をブラックリストに追加することを備える方法。
【請求項７】
請求項１に記載の方法であって、
前記クライアント端末によって異常なアクセス要求がなされたと判定する際に、前記方法は、更に、
前記異常なアクセス要求のための処理ルールを前記アプリケーションサーバに送信し、
前記アプリケーションサーバによって、前記処理ルールにしたがって前記異常なアクセス要求を処理すること、を備える方法。
【請求項８】
請求項２に記載の方法であって、
前記クライアント端末の前記識別子情報は、インターネットプロトコル（Internet Protocol, IP）アドレス、メディアアクセス制御（Media Access Control, MAC）アドレス、及びクッキー（COOKIE）データからなる群より選択される１つ又は複数を含む、方法。
【請求項９】
分散アプリケーションシステムであって、
複数のアプリケーションサーバと、
アンチ攻撃サーバと、
を備え、
前記複数のアプリケーションサーバは、
イベント要求情報を得るように構成され、前記イベント要求情報の少なくとも一部は、クライアント端末から送信されユニフォームリソースロケータ（Uniform Resource Locator, URL）リソースに対応するリソースアクセス要求に関し、
前記イベント要求情報を前記アンチ攻撃サーバに転送するように構成され、
前記アンチ攻撃サーバは、
前記イベント要求情報の少なくとも一部に少なくとも部分的に基づいて、前記クライアント端末によって所定期間内になされた前記ＵＲＬリソースへのアクセス要求の総数を決定するように構成され、
前記決定されたアクセス要求の総数及び所定のアクセスルールに少なくとも基づいて、前記クライアント端末によって異常なアクセス要求がなされたか否かを判定するように構成される、システム。
【請求項１０】
請求項９に記載のシステムであって、
前記イベント要求情報の少なくとも一部は、前記アクセス要求が受信されたときの時刻情報、目標ＵＲＬ、及び前記クライアント端末の識別情報を含む、システム。
【請求項１１】
請求項９に記載のシステムであって、
前記イベント要求情報の少なくとも一部は、前記アプリケーションサーバの少なくとも一部に格納された既知の悪意あるクライアント端末のブラックリストと比較される、システム。
【請求項１２】
請求項９に記載のシステムであって、
前記イベント要求情報の少なくとも一部に含まれる目標ＵＲＬが、保護下にある目標ＵＲＬのセットと比較される、システム。
【請求項１３】
請求項９に記載のシステムであって、
前記クライアント端末によって異常なアクセス要求がなされなかったと判定された場合に、前記複数のアプリケーションサーバは、更に、前記イベント要求情報の少なくとも一部を正常に処理するように構成される、システム。
【請求項１４】
請求項９に記載のシステムであって、
前記クライアント端末によって異常なアクセス要求がなされたと判定された場合に、前記複数のアプリケーションサーバは、更に、前記クライアント端末の識別情報をブラックリストに追加するように構成される、システム。
【請求項１５】
請求項９に記載のシステムであって、
前記クライアント端末によって異常なアクセス要求がなされたと判定する際に、前記アンチ攻撃サーバは、更に、前記異常なアクセス要求のための処理ルールを前記アプリケーションサーバに送信するように構成され、前記アプリケーションサーバは、更に、前記処理ルールにしたがって前記異常なアクセス要求を処理するように構成される、システム。
【請求項１６】
請求項１０に記載のシステムであって、
前記クライアント端末の前記識別子情報は、インターネットプロトコル（Internet Protocol, IP）アドレス、メディアアクセス制御（Media Access Control, MAC）アドレス、及びクッキー（COOKIE）データからなる群より選択される１つ又は複数を含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本出願は、２００８年９月１１日付けで出願され、発明の名称を「METHOD AND SYSTEM FOR PROCESSING ABNORMAL REQUEST IN DISTRIBUTED APPLICATION（分散アプリケーションにおいて異常要求を処理するための方法及びシステム）」とする中国特許出願第２００８１０２１１８４８．３号に基づく優先権を主張する。当該出願は、あらゆる目的のために参照によって本明細書に組み込まれる。
【０００２】
本発明は、インターネットセキュリティの分野に関し、特に、分散環境において異常要求を処理するための方法及びシステムに関する。
【背景技術】
【０００３】
インターネットの急速な発展に伴って、大規模なポータルウェブサイトは、セキュリティリスクの高まりに直面している。一の種類のリスクとして、サービス拒否（denial-of-service, DoS）攻撃が挙げられ、この攻撃では、複数のマシンによって同時に開始される複数の要求などの、多数の並列要求がなされる。ＤｏＳ攻撃は、サーバを大幅に低速化させ、あるいは、ウェブサイトを完全にクラッシュさせる恐れがある。他の種類のリスクとして、様々な検索エンジン、競合マシン、市販のデータ解析ウェブサイトなどからくるクローラプログラムに由来するものが挙げられる。ウェブクローラは、多数の要求を開始させて、サーバの性能に悪影響を及ぼす恐れがある。このような反復的で且つ高並列の異常なユーザ要求は、サーバリソースを容易に枯渇させて、正常なユーザ要求の処理を阻む。
【図面の簡単な説明】
【０００４】
以下の詳細な説明及び添付の図面において、本発明の様々な実施形態が開示される。
【０００５】
【図１】異常要求に対処するように構成されたシステムの一実施形態を示すブロック図である。
【０００６】
【図２】分散アプリケーションにおいて要求を処理するための方法の一実施形態を示すフローチャートである。
【０００７】
【図３】フィルタを用いた要求処理プロセスの一実施形態を示すフローチャートである。
【発明を実施するための形態】
【０００８】
本発明は、プロセス、装置、システム、合成物、コンピュータ読み取り可能記録媒体に盛り込まれたコンピュータプログラム製品、並びに／又は結合先のメモリに格納された命令及び／若しくは結合先のメモリによって提供される命令を実行するように構成されたプロセッサを含む、数々の形態で実現することができる。本明細書において、これらの実現の形態、又は本発明が取りえるその他の任意の形態は、技術と称されてよい。総じて、開示されたプロセスのステップの順序は、本発明の範囲内において変更されてよい。別途明記されない限り、タスクを実施するように構成されるものとして説明されるプロセッサ又はメモリなどのコンポーネントは、所定時にタスクを実施するように一時的に構成される汎用コンポーネント、又はタスクを実施するように製造された特殊コンポーネントとして導入されてよい。本明細書において使用される「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つ又は複数のデバイス、回路、及び／又は処理コアを意味するものとする。
【０００９】
本発明の原理を例示した添付の図面を伴って、以下において、本発明の１つ又は複数の実施形態に関する詳細な説明が提供される。本発明は、このような実施形態に関連して説明されるが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定され、数々の代替、変更、及び等価な形態を内包する。以下の説明では、本発明の完全な理解を可能にするために、数々の詳細が特定される。これらの詳細は、例示を目的として提供されるものであり、本発明は、これらの詳細の一部又は全部を伴わずとも、特許請求の範囲にしたがって実施されえる。明瞭さを期するため、本発明に関連した技術分野において知られている技術的構成要素は、本発明が不必要に不明瞭にされないように、詳細な説明を省略されている。
【００１０】
図１は、異常要求に対処するように構成されたシステムの一実施形態を示すブロック図である。この例では、システム１００は、複数のアプリケーションサーバ１１２、１１４、１１６、及び１１８を含む。例示の目的のために、４つのアプリケーションサーバが使用されているが、その他の実施形態では、異なる数のアプリケーションサーバが使用されてもよい。１０４及び１０６などのクライアントからのＵＲＬリソースアクセス要求が、アプリケーションサーバによって受信され、必要に応じてアンチ攻撃サーバ１０８に転送される。一部の実施形態では、イベント要求情報は、各アクセス要求が受信されたときの時刻情報、アクセス要求に関係する１つ又は複数の目標ＵＲＬ、及びアクセス要求に関係するクライアント端末の識別子情報を含む。
【００１１】
アンチ攻撃サーバは、個々のクライアントからのＵＲＬアクセスの統計を集め、特定のアクセス要求が異常であるかどうかについて判定を下す。一部の実施形態では、アンチ攻撃サーバは、アプリケーションサーバから受信されたイベント要求情報にしたがって、同じ識別子を持つクライアント端末によって同じＵＲＬリソースに対して単位時間内になされたアクセスの回数を数えるように、並びに数えられた結果及びＵＲＬリソースに対応する所定のアクセスルールにしたがって、異常アクセス要求を識別するように適応される。
【００１２】
一部の実施形態では、システムは、随意として、各アプリケーションサーバの識別子情報ブラックリストを読み出すように、及びもしクライアント端末の識別子情報がブラックリストに載っていない場合にイベント要求情報をアンチ攻撃サーバ２０４に送信するように適応されたフィルタ１２０を含む。
【００１３】
図２は、分散アプリケーションにおいて要求を処理するための方法の一実施形態を示すフローチャートである。プロセス２００は、１００で示すシステム上で実施されてよい。ステップ２０２では、アプリケーションサーバにおいて、イベント要求情報が受信される。イベント要求情報は、１つ又は複数のリソースアクセス要求に関する情報を含む。各リソースアクセス要求は、クライアント端末から送信され、ＵＲＬリソースに対応する。一部の実施形態では、イベント要求情報は、アクセス要求が受信されたときの時刻の情報、目標ＵＲＬ、及びアクセス要求を行ったクライアント端末の識別情報を含む。一部の実施形態では、クライアント端末のＩＰアドレスが、そのクライアント端末の識別子として機能する。一部の実施形態では、クライアント端末の識別情報は、そのクライアント端末のクッキー（COOKIE）データ及び／又はそのクライアント端末のメディアアクセス制御（Media Access Control, MAC）アドレスを含んでよい。
【００１４】
一実施例では、時刻ｔ１において、アプリケーションサーバ１１２が、ＩＰアドレス192.168.0.1を持つクライアント端末によって送信された、第１のＵＲＬ（ＵＲＬ１）を求めるアクセス要求を受信し、時刻ｔ２において、アプリケーションサーバ１１４が、ＩＰアドレス192.168.0.1を持つ同じクライアント端末によって送信された、第２のＵＲＬ（ＵＲＬ２）を求めるアクセス要求を受信し、時刻ｔ３において、アプリケーションサーバ１１６が、ＩＰアドレス192.168.0.2を持つクライアント端末によって送信された、ＵＲＬ１を求めるアクセス要求を受信し、時刻ｔ４において、アプリケーションサーバ１１８が、ＩＰアドレス192.168.0.1を持つクライアント端末によって送信された、ＵＲＬ１を求めるアクセス要求を受信する。アプリケーションサーバによって受信される要求数は、異なる数であってもよい。
【００１５】
アプリケーションサーバは、アクセス要求から関連する要求情報を抽出する。上記の実施例では、アプリケーションサーバ１１２は、受信されたアクセス要求から、受信時刻ｔ１、ＵＲＬ１、及びＩＰアドレス192.168.0.1を抽出する。アプリケーションサーバ１１４、１１６、及び１１８は、アプリケーションサーバ１１２と同様の動作を実施し、それぞれのアクセス要求から関連するイベント要求情報を抽出する。
【００１６】
ステップ２０４では、クライアント端末から送信されたリソースアクセス要求に関するイベント要求情報が、リソースアクセス要求に関する統計を蓄積するアンチ攻撃サーバに転送される。ステップ２０６では、ＵＲＬリソースを求めてクライアントによって所定期間内になされた、異なるアプリケーションサーバ上で受信されたアクセス要求を含むアクセス要求の総数が決定される。上記の実施例では、ｔ１〜ｔ４を含む時間内に192.168.0.1からＵＲＬ１を求めてなされたアクセス要求の総数が２であること、この時間内に192.168.0.1からＵＲＬ２を求めてなされたアクセス要求の総数が１であること、及びこの時間内に192.168.0.2からＵＲＬ１を求めてなされたアクセス要求の総数が１であることが決定される。
【００１７】
ステップ２０８では、アクセス要求の総数及び所定のアクセスルールに基づいて、クライアント端末によって異常なアクセス要求がなされたかどうかが判定される。一部の実施形態では、所定のアクセスルールは、回数閾値を設定し、この閾値を超えた場合に、アクセスが異常であることを示す。一部の実施形態では、アクセス要求の総数を時間で割ることによって、アクセス要求の頻度が計算される。所定のアクセスルールは、頻度閾値を設定し、この閾値を超えた場合に、アクセスが異常であることを示す。アクセスが異常であると見なされた場合、イベント要求情報を受信し転送したアプリケーションサーバは、通知を受ける。一部の実施形態では、要求は、これ以上処理されない。一部の実施形態では、通知は、異常なアクセス要求に対する特殊処理のための処理ルールを含む。しかしながら、要求が正常であることがわかった場合には、アプリケーションサーバは、通知を受け、要求は正常に処理される。
【００１８】
一部の実施形態では、アクセス要求が異常であると見なされた場合には、そのアクセス要求を送信したクライアント端末についての識別子（例えばＩＰアドレス）が、ブラックリストに追加される。一部の実施形態では、ブラックリストに載っているクライアント端末から送信されたリソースアクセス要求を識別するために、フィルタが使用される。一部の実施形態では、フィルタは、目標ＵＲＬが保護下にあるかどうかを判定するためにも使用される。フィルタは、ソフトウェアとして、ハードウェアとして、又は１つ若しくは複数のアプリケーションサーバ上、別個のデバイス上、若しくはそれらの組み合わせ上で実行される組み合わせとして実装されてよい。図３は、フィルタを用いた要求処理プロセスの一実施形態を示すフローチャートである。ステップ３０２では、複数のアプリケーションサーバにおいて、イベント要求情報が得られる。クライアント端末から送信された各リソースアクセス要求について、ステップ３０４では、その要求の発信元であるクライアント端末のＩＰアドレスがブラックリストに掲載されているか否かが判定される。掲載されている場合には、アプリケーションサーバは、アクセス要求を直ちに拒絶し、プロセスは終了する。掲載されていない場合には、プロセスは、ステップ３０６に進む。例えば、データベースフィルタがＩＰブラックリストを読み出し、ＩＰアドレス192.168.0.2がブラックリストに掲載されていることを発見した場合には、アプリケーションサーバは、ＩＰアドレス192.168.0.2を持つクライアント端末からのアクセス要求を拒絶する。フィルタは、ＩＰアドレス192.168.0.1がブラックリストに掲載されていないことを発見し、プロセスは、ステップ３０６に進む。
【００１９】
ステップ３０６では、フィルタは、１１２、１１４、及び１１８などのアプリケーションサーバによって受信されたアクセス要求のイベント要求情報から、ＵＲＬ１及びＵＲＬ２などの目標ＵＲＬを抽出する。また、リソースアクセス要求に関係する目標ＵＲＬが保護下にあるかどうかも判定される。目標ＵＲＬが保護下にある場合は、アクセス要求は拒絶され、プロセスは終了する。もし保護下にない場合には、プロセスは、ステップ３０８に進む。例えば、ＵＲＬ２が保護下にあると判定された場合、すなわち、ＵＲＬ２がアクセス不可である場合には、ＵＲＬ２に対するアクセス要求は拒絶される。このような処理の目的は、ＩＰアドレスのフィルタリング及びＵＲＬのフィルタリングの両方を含む多段階フィルタリングを実現することにある。ＵＲＬ１が保護下にない場合には、プロセスは、ステップ３０８に進む。
【００２０】
ステップ３０８では、ＵＲＬリソース情報及びクライアント端末ＩＰアドレスを含むイベント要求情報が、アンチ攻撃サーバに転送される。ステップ３１０では、アンチ攻撃サーバは、ＵＲＬリソースを求めてクライアント端末によって所定期間内になされた、異なるアプリケーションサーバによって受信された要求を含むアクセス要求の総数を決定する。
【００２１】
ステップ３１２では、ＵＲＬリソースを求めるクライアント端末からのアクセス要求のアクセス要求総数と、所定のアクセスルールとに基づいて、アクセスが異常であるかどうかが判定される。サービスアプリケーションの実際の状況に応じて、特定のＵＲＬについてのアクセスルールが設定される。例えば、ＵＲＬへのアクセス数が特定の時間内に既定の閾値を超える場合、又はＵＲＬが一部の許可ユーザによってのみアクセス可能であり、要求の発信者は許可されていない場合には、ルールは、そのＵＲＬがこの時点ではアクセス可能でないことを示す。
【００２２】
ステップ３１４では、異常なアクセス要求に対応するクライアント端末が、ブラックリストに追加される。ブラックリストへの追加は、システムの構成に応じて異なるやり方で実現されてよい。各サーバがそれぞれ自身のブラックリストを追跡している実施形態では、異常なクライアント端末の識別子は、それらの全てのフィルタに送信される。システム全体で、フィルタ上又はアンチ攻撃サーバ上のいずれかに１つのブラックリストのみが維持されている実施形態では、異常なクライアント端末の識別子は、ブラックリストを追跡しているデバイスに送信される。
【００２３】
例えば、ＩＰアドレス192.168.0.1の識別子情報を持つクライアント端末によって１分間になされたＵＲＬ１へのアクセス総数が１００であり、ＵＲＬ１に対応する所定のアクセスルールによって、同ＩＰアドレスの識別子情報を持つクライアント端末によって１分間になされるＵＲＬ１へのアクセス数が５０を超えてはならないと示されるとすると、アンチ攻撃サーバは、ＩＰアドレス192.168.0.1を持つクライアント端末からのＵＲＬ１に対するアクセス要求を異常であると判定する。一部の実施形態では、ＩＰアドレス192.168.0.1は、５分間にわたってロックされるとともに、アプリケーションサーバに戻され、当該アプリケーションサーバは、ＩＰブラックリストを更新し、ＩＰアドレス192.168.0.1をＩＰブラックリストに追加する。もしＩＰアドレス192.168.0.1を持つクライアント端末が５分以内にＵＲＬ１に対するアクセス要求を開始させた場合は、その要求は拒絶される。アンチ攻撃サーバは、既定の処理ルールを全てのアプリケーションサーバに送信する。各アプリケーションサーバは、既定の処理ルールにしたがって、ＩＰアドレス192.168.0.1からの全てのアクセスを拒絶するか、又はＩＰアドレス192.168.0.1からＵＲＬ１へのアクセスを拒絶するかを決定してよい。
【００２４】
ステップ３１６では、フィルタによるチェックを通った異常のないアクセス要求が、正常に処理される。このステップ、及びアンチ攻撃サーバによる異常要求の識別（ステップ３１０〜３１５）は、現アクセス要求に対するリアルタイムサービス処理を確実にするために、同期的に実施されてよい。また、このことは、現アクセス要求が悪意ある攻撃だと見なされた場合には、現アクセス要求のＩＰアドレスからの次のアクセス要求が既定の処理ルールにしたがって処理可能であることを保証する。
【００２５】
当業者ならば、本発明の趣旨及び範囲から逸脱することなく本発明に対して様々な変更及び変形をなしえることがわかる。したがって、もし本発明に対するこれらの変更及び変形が本発明の特許請求の範囲及びそれらの均等物の範囲内に入るならば、本発明は、これらの変更及び変形を全て含むことを意図する。
【００２６】
以上の実施形態は、理解を明瞭にする目的で幾らか詳細に説明されてきたが、本発明は、提供された詳細に限定されない。本発明を実現するには、多くの代替方法がある。開示された実施形態は、例示的なものであり、限定的なものではない。
【図１】
2012507065.tif 000003
【図２】
2012507065.tif 000004
【図３】
2012507065.tif 000005
【国際調査報告】
2012507065.tif 000006