コンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置
【課題】コンピュータネットワークシステムにおいてウェブサービスのようなアプリケーションレイヤのサービスを妨害する分散サービス妨害（ＤＤｏＳ）攻撃を正確に探知し、防御できるコンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置を提供する。
【解決手段】本発明のコンピュータネットワークシステムのアプリケーションレイヤを保護する方法は、クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階とを含む。
【解決手段】本発明のコンピュータネットワークシステムのアプリケーションレイヤを保護する方法は、クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータネットワークシステムのアプリケーションレイヤ（ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）を攻撃する分散サービス妨害（Ｄｉｓｔｒｉｂｕｔｅ Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ、ＤＤｏＳ）攻撃に対する対応技術に関し、特に、コンピュータネットワークシステムが正常なサービスを提供できないようにする分散サービス妨害攻撃を探知し、これを遮断するコンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置に関する。
【背景技術】
【０００２】
近年、ネットワーク、電子技術などの発展に伴い、ウェブなどの多様なサービスの提供を容易に受けてはいるが、技術の発展と共に、多様なハッキングツールの登場によってコンピュータネットワークシステムで提供されるサービスを妨害したり、ハッキングする行為も益々頻繁になっている。
【０００３】
また、このようなコンピュータネットワークシステムのハッキングは、金銭的な利益を得るための多様な攻撃形態に変化しており、特に、分散サービス妨害（ＤＤｏＳ）攻撃はウェブなどを介した正常なサービスが不可能なようにする攻撃であって、ゾンビ（ｚｏｍｂｉｅ）ＰＣなどのネットワークグループであるボットネット（ｂｏｔｎｅｔ）などを悪用して激しさが増している傾向にある。
【０００４】
このような分散サービス妨害攻撃に対応するために、幾つかの探知及び対応技法が開発されてはいるが、大部分の分散サービス妨害攻撃に対する対応技法がネットワーク水準（ｎｅｔｗｏｒｋ ｌｅｖｅｌ）のＳＹＮフラッディング（ＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）ｆｌｏｏｄｉｎｇ）などを探知し、遮断する方法に限られており、ウェブサーバなどのアプリケーションレイヤサービスを妨害する分散サービス妨害攻撃に対する探知及び対応方法としては、伝送率制限（ｒａｔｅ ｌｉｍｉｔ）のようにウェブサーバに入力されるパケットを低減する攻撃緩和技法が殆どであり、アプリケーションレイヤの分散サービス妨害攻撃パケットやソースＩＰを探して対応する技術は存在しない。
【０００５】
現在、アプリケーションレイヤの分散サービス妨害攻撃を探知し対応するために、伝送率制限などの技術を活用するので、緩和された攻撃パケットがそのままサーバに伝達されてサーバの負荷が発生するフォールスネガティブ（ｆａｌｓｅ ｎｅｇａｔｉｖｅ）現象と、正常にサービスを要請したユーザのパケットが遮断されるフォールスポジティブ（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ）の発生リスクを同時に有している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特開２００８−０２７１１４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、本発明は上記事情に鑑みてなされたものであって、その目的は、コンピュータネットワークシステムにおいてウェブサービスのようなアプリケーションレイヤのサービスを妨害する分散サービス妨害（ＤＤｏＳ）攻撃を正確に探知し、防御できるコンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の課題を解決するための一態様によれば、コンピュータネットワークシステムのアプリケーションレイヤを保護する方法は、クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階とを含むことを特徴とする。
【０００９】
本発明の他の様態によれば、コンピュータネットワークシステムのアプリケーションレイヤを保護する装置は、クライアントからのセッション連結要請に従ってネットワークを介して前記クライアントとのセッションを設定し、前記クライアントのデータ要請に応答してデータパケットを前記ネットワークを介して前記クライアントに伝送するように構成されたデータ提供サーバと、前記ネットワークを介して前記クライアントと前記データ提供サーバとのセッションが設定された状態で、前記データ要請に対して前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知するように構成されたアプリケーションレイヤ保護サービスサーバとを含むことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、正常なサービス要請と明確に区分される攻撃者特徴であるゲット（ＧＥＴ）パケットの発生後、即座にフィン（ＦＩＮ）パケットを発生したＩＰ又はパケットに対する直接的な探知及び対応が可能であるので、誤り警報（ｆａｌｓｅ ａｌａｒｍ）を発生せず、分散サービス妨害攻撃者を探し、対応できるという効果を奏する。また、従来は伝送率制限機能を行うために多くのリソースを要求するが、本発明ではアプリケーションレイヤの分散サービス妨害パケットを発生する攻撃者を直接探して対応できるため、リソースが節約される。更に、本発明では、クライアントの連結終了要請の後、サービス応答に対するクライアントの応答であるアック（ＡＣＫ）パケットの有無でも攻撃者を探すことができる。また、ゲット（ＧＥＴ）パケットの後にフィン（ＦＩＮ）が続くかを確認し、パケット単位で対応する場合、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を用いるネットワークで正常なユーザとゾンビＰＣのトラフィックが混在している場合にも対応が可能である。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態が適用されるコンピュータネットワークシステムのブロック構成図である。
【図２】アプリケーションレイヤにおけるクライアントとデータ提供サーバ間のウェブサービスを行う過程を示す図である。
【図３】分散サービス妨害攻撃の動作を示す図である。
【図４】本発明の実施形態によるコンピュータネットワークシステムのアプリケーションレイヤ保護方法を示すフローチャートである。
【発明を実施するための形態】
【００１２】
本発明ではコンピュータネットワークシステムのアプリケーションレイヤに対する分散サービス妨害（ＤＤｏＳ）攻撃を探知し、対応する方法を提示する。このようなアプリケーションレイヤの攻撃に対する探知及び対応方法を詳細に記述するために、代表的なアプリケーションサービスであるウェブサービスを例に挙げて説明する。
【００１３】
ホストでＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信プログラムを作成するためには、ソケット（ｓｏｃｋｅｔ）を用いる。ソケットは、ＴＣＰ／ＩＰレイヤとアプリケーションレイヤとを連結する一種のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。一部のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）では安全性の問題などにより、ソケットを介さないネットワーク階層の接続を許容しないので、大部分の通信プログラムはソケットを活用している。
【００１４】
このようなソケットを介した通信プログラムのうち、ＴＣＰを利用するプログラムの場合は、セッション（ｓｅｓｓｉｏｎ）を形成した後、アプリケーションレイヤのデータ通信が可能であり、データ通信が終了した後にセッションを終了する過程で通信が行われる。
【００１５】
本発明は、クライアント（ｃｌｉｅｎｔ）とサーバ（ｓｅｒｖｅｒ）間のセッションが連結された状態で、クライアントからサーバにデータが要請され、既に設定された時間内に（又はデータ要請後、即座に）セッション終了が要請された場合、或いはクライアントのソケットがクライアントとサーバとの間のセッションを既に終了したため、サーバがクライアントに伝送した応答パケット（Ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）に対してクライアントがサーバに確認パケット（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ ｐａｃｋｅｔ、以下「ＡＣＫパケット」という）を発生しない場合に、該当クライアントを分散サービス妨害攻撃者であると認識して該当クライアントとサーバとの連結を遮断するように構成される。
【００１６】
以下、添付する図面を参照して本発明の実施形態について具体的に説明する。
【００１７】
まず、図１は、本発明の実施形態が適用され得るコンピュータネットワークシステムのブロック構成図である。コンピュータネットワークシステムは、クライアント１００、通信ネットワーク１０２、アプリケーションレイヤ保護サービスサーバ１０４、データ提供サーバ１０６を含む。
【００１８】
図１に示すように、クライアント１００は、ネットワーク１０２に接続してアプリケーションレイヤサービスなどの提供を受けるユーザ側端末、例えば、デスクトップ（ｄｅｓｋ-ｔｏｐ）、ラップトップ（ｌａｐ-ｔｏｐ）などを称するものであって、通信ネットワーク１０２を介してデータ提供サービス、アプリケーションレイヤサービスなどをユーザに提供できる。このようなクライアント１００は、デスクトップ、ラップトップだけでなく、アプリケーションレイヤのサービスを妨害するゾンビＰＣも含むことができる。また、図１には１つのクライアント１００を示したが、これは説明の便宜のためのものであって、通信ネットワーク１０２上には多数のクライアントが連結され得ることが本発明の技術分野における通常の知識を有する者であれば、容易に分かる。
【００１９】
通信ネットワーク１０２は、例えば、有/無線インターネットのような、開放型コンピュータネットワーク構造を意味し、クライアント１００にネットワーク接続環境を提供できる。
【００２０】
アプリケーションレイヤ保護サービスサーバ１０４は、ウェブサービスのようなアプリケーションレイヤのサービスを妨害する攻撃形態、例えば、ＤＤｏＳ攻撃を探知し防御する役割を果す。このようなアプリケーションレイヤ保護サービスサーバ１０４は、例えばＩＤＳ（Ｉｎｔｅｒｎｅｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）、ＩＰＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｖｉｄｅｒ Ｓｅｃｕｒｉｔｙ）、ＦＷ（Ｆｉｒｅｗａｌｌ）、ウェブＦＷ又はＤＤｏＳ専用装備の形態で実現されることも可能である。
【００２１】
データ提供サーバ１０６は、ＴＣＰ／ＩＰプロトコル及びその上位階層に存在する多様なサービス、即ち、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、テルネット（Ｔｅｌｎｅｔ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｅｒｖｉｃｅ）、ＮＩＳ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）を提供する。このようなデータ提供サーバ１０６は通信ネットワーク１０２を通じてクライアント１００にデータ、例えば、ウェブページ及び／又はコンテンツなどのサービスを提供するウェブサーバ又はコンテンツサーバとしての役割を果す。
【００２２】
図１ではアプリケーションレイヤ保護サービスサーバ１０４とデータ提供サーバ１０６をそれぞれ別個のサーバとして示したが、これは説明の便宜上、１つの実施形態として示しただけで、アプリケーションレイヤ保護サービスサーバ１０４とデータ提供サーバ１０６が単一のサーバに統合運営されることもできることを周知する必要がある。
【００２３】
アプリケーションレイヤ保護サービスサーバ１０４は、通信ネットワーク１０２を介してデータ提供サーバ１０６とクライアント１００とのセッションが設定された状態で、クライアント１００からのデータ要請に続いて（又はデータ要請後、即座に）セッション終了が要請される場合に、クライアント１００をアプリケーションレイヤを攻撃するクライアント（即ち、ＤＤｏＳ攻撃者）と見なしてクライアント１００から要請されたデータのパケットを遮断することで、ＨＴＴＰ ＧＥＴフラッディング又はキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）などのようなＤＤｏＳ攻撃からアプリケーションレイヤを保護できる。
【００２４】
また、アプリケーションレイヤ保護サービスサーバ１０４は、データ提供サーバ１０６とクライアント１００とのセッションが既に終了されたためアプリケーションレイヤ保護サービスサーバ１０４の応答パケットに対してクライアント１００がＡＣＫパケットを発生しなければ、クライアント１００をアプリケーションレイヤを攻撃するクライアント（即ち、ＤＤｏＳ攻撃者）として認識してクライアント１００とデータ提供サーバ１０６間の連結を遮断することで、ＨＴＴＰ ＧＥＴフラッディング又はＣＣフラッディングなどのようなＤＤｏＳ攻撃からアプリケーションレイヤを保護できる。このようなアプリケーションレイヤ保護サービスサーバ１０４の連結遮断は、例えば、クライアント１００のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を遮断することで実現され得る。
【００２５】
図２は、このようなアプリケーションレイヤにおけるネットワークサービス、例えば、クライアント１００とデータ提供サーバ１０６間のウェブサービスを行う過程を示す図である。
【００２６】
まず、クライアント１００は、サービス要請のためにデータ提供サーバ１０６にセッション連結を要請する（Ｓ２００）。このようなセッションの連結要請は、例えば、クライアント１００からデータ提供サーバ１０６に同期シーケンス番号（ＳＹＮ）パケット（Ｓｙｎｃｈｒｏｎｉｚｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ ｐａｃｋｅｔ、以下、「ＳＹＮパケット」という）を伝送するものとして実現され得る。
【００２７】
このとき、データ提供サーバ１０６のリソースが許容される場合には、データ提供サーバ１０６はクライアント１００のセッション連結の要請に応答する（Ｓ２０２）。このようなセッション連結要請の応答は、例えば（ＳＹＮ＋ＡＣＫ）パケットを伝送するものとして実現され得る。
【００２８】
（ＳＹＮ＋ＡＣＫ）パケットを受信したクライアント１００は、再びデータ提供サーバ１０６にＡＣＫパケットを伝送することによって、これらの間のセッションが連結され得る（Ｓ２０４）。
【００２９】
このように、クライアント１００とデータ提供サーバ１０６間のセッションが連結された状態で、クライアント１００は所望のデータ、例えば、ウェブページ又はコンテンツをデータ提供サーバ１０６に要請できる（Ｓ２０６）。このようなデータの要請は、例えば、クライアント１００からデータ提供サーバ１０６にＧＥＴパケットを伝送するものとして実現され得る。
【００３０】
ＧＥＴパケットを受信したデータ提供サーバ１０６は、クライアント１００から要請されたデータをパケット形態でクライアント１００に伝送する（Ｓ２０８）。
【００３１】
要請されたデータがデータ提供サーバ１０６からクライアント１００に伝送されれば、クライアント１００はデータ提供サーバ１０６からのパケットのデータの受信を応答する（Ｓ２１０）。このようなデータ受信応答は、例えば、クライアント１００からデータ提供サーバ１０６にＡＣＫパケットを伝送するものとして実現され得る。
【００３２】
その後、全てのパケットを伝送したデータ提供サーバ１０６は、クライアント１００に連結終了を要請できる（Ｓ２１２）。このような連結終了要請は、例えば、データ提供サーバ１０６からクライアント１００に終了パケット（ＦＩＮｉｓｈ Ｐａｃｋｅｔ、以下、「ＦＩＮパケット」という）を伝送するものとして実現され得る。
【００３３】
このとき、データ提供サーバ１０６でキープアライブ（ｋｅｅｐ ａｌｉｖｅ）値をオフした場合には最終のデータを伝達した後、即座に、又は最終のデータと同時にＦＩＮパケットをクライアント１００に伝送できる。データ提供サーバ１０６でキープアライブ値をオンした場合にはデータ提供サーバ１０６のキープアライブ時間（ｋｅｅｐ ａｌｉｖｅ ｔｉｍｅ）を超えれば、ＦＩＮパケットをクライアント１００に伝送できる。
【００３４】
その後、クライアント１００はセッション終了要請のためのＦＩＮパケットをデータ提供サーバ１０６に伝送し（Ｓ２１４）、リセットパケット（ＲｅＳｅＴ ｐａｃｋｅｔ、以下、「ＲＳＴパケット」という）によりクライアント１００とデータ提供サーバ１０６間のセッションが終了し得る。
【００３５】
図３は、ＤＤｏＳ攻撃ツール、例えば、ネットボット（ｎｅｔｂｏｔ）で発生し得るトラフィック特徴を示す図である。
【００３６】
まず、クライアント１００は、サービス要請のためにデータ提供サーバ１０６にセッション連結を要請する（Ｓ３００）。このようなセッション連結要請は、例えば、クライアント１００からデータ提供サーバ１０６にＳＹＮパケットを伝送するものとして実現され得る。
【００３７】
このとき、データ提供サーバ１０６のリソースが許容される場合には、データ提供サーバ１０６はクライアント１００のセッション連結の要請に応答できる（Ｓ３０２）。このようなセッション連結応答は、例えば（ＳＹＮ＋ＡＣＫ）パケットを伝送するものとして実現され得る。
【００３８】
（ＳＹＮ＋ＡＣＫ）パケットを受信したクライアント１００は再びデータ提供サーバ１０６にＡＣＫパケットを伝送することによって、これらの間のセッションが連結され得る（Ｓ３０４）。
【００３９】
このように、クライアント１００とデータ提供サーバ１０６間のセッションが連結された状態で、クライアント１００は所望のデータ、例えば、ウェブページをデータ提供サーバ１０６に要請できる（Ｓ３０６）。このようなデータの要請は、例えば、クライアント１００からデータ提供サーバ１０６にＧＥＴパケットを伝送するものとして実現され得る。
【００４０】
前述した過程は図２のアプリケーションレイヤにおけるサービス、例えば、クライアント１００とデータ提供サーバ１０６間のウェブサービスの実行過程と同一である。
【００４１】
しかし、アプリケーションレイヤを攻撃しようとする場合には、クライアント１００が即座にＦＩＮパケットを発生してデータ提供サーバ１０６にセッション終了を要請できる（Ｓ３０８）。
【００４２】
従って、クライアント１００のデータサービス要請の過程（Ｓ３０６）とデータ提供サーバ１０６の応答パケット（ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）伝送の過程（Ｓ３１０）との間でクライアント１００がセッション終了を要請すると、データ提供サーバ１０６はまず受信されたクライアント１００からのＧＥＴパケットに対する応答として応答パケット（ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）を発生してクライアント１００に伝送し（Ｓ３１０）、後に次いでＲＳＴパケットを発生してセッションを終了する（Ｓ３１２）。
【００４３】
このような過程は、以下の通り解釈され得る。
【００４４】
まず、ボットネットもソケットプログラムで作成されているので、多くのアプリケーションレイヤサービスの要求が発生するためにはサービス要請が完了したセッションは必ず終了しなければならない。なぜならば、セッションを終了しなければ、クライアントのソケットリソースが枯渇してしまい、持続的なパケットの発生が不可能であるためである。
【００４５】
例えば、図３の段階（Ｓ３０８）でクライアントがＦＩＮパケットを発生せず、新たなセッションを継続して生成すれば、クライアントのソケットリソースの枯渇によりこれ以上通信が不可能になる。
【００４６】
それで、クライアントで持続的に攻撃パケットを発生するためには必ずセッションを終了しなければならない。また、攻撃者の場合にサーバから送られるデータは関心の対象でないため、これらを受信する必要はない。仮に図２に示されているように、正常にセッションを持続する場合、攻撃者が所望の量のセッションとパケットを発生できず、サーバが攻撃を受ける状況ではサーバの負荷によって段階（Ｓ２１４）のセッション終了要請が遅れて攻撃者もパケットを発生できない状況を経験できる。しかし、ＤＤｏＳ攻撃者はサーバがサービスを提供できないようにすることが目的であるため、図３の段階（Ｓ３０８）でのように、セッション終了要請を即座に行わざるを得ない。
【００４７】
ウェブサービスの場合にＨＴＴＰ１.０標準文書には以下の通り記述している。
【００４８】
「実験的なアプリケーションプログラムを除いた実際のアプリケーションにおいて各要求メッセージの伝達に先立ち、クライアントにより連結がまず設立されなければならず、サーバが応答を先に送り、連結を切るようにしなければならない。このとき、クライアントとサーバはユーザの動作や自動的なタイムアウト、又はプログラム誤りにより、どちらであれ、途中で連結を解除する可能性もあるということが分からなければならず、適切な対応動作が可能でなければならない。どの場合であっても、何れか一方又は両方ともの連結解除は常に現在の要求に対する削除を意味する。」
【００４９】
ＨＴＴＰ１.０標準文書ではサーバがデータ通信を完了した後、セッションを終了することが正常なサービス終了であると規定しており、異常なセッション終了は、以下の３つに規定している。
１．ユーザの動作による終了
２．自動的なタイムアウトによる終了
３．プログラム誤りによる終了
【００５０】
図３の状況が発生し得る場合を上記誤りの状況と比較すると、以下のような結論が得られる。
【００５１】
まず、実際、ネットボットとソケットプログラムで確認した結果、段階（Ｓ３０６）のＧＥＴパケットと段階（Ｓ３０８）のＦＩＮパケットが発生する時間間隔が、例えば、数十マイクロ秒（μｓｅｃ）以内、具体的に、１０〜９０マイクロ秒（μｓｅｃ）の間であって、極めて短いことが確認でき、このように短時間内で２つのパケットが発生する理由は最大限に多くの攻撃パケットを生成するためである。
【００５２】
このとき、上述したユーザの動作による終了は、その発生可能性が非常に低いと見られる。仮に、ユーザがウェブブラウザを通じてウェブサービス要請であるＧＥＴパケットを発生し、即座にＦＩＮパケットを発生するためには、数十マイクロ秒（μｓｅｃ）以内にウェブブラウザを閉じなければならないが、現実的にこのように速くユーザがウェブブラウザを閉じることは不可能である。
【００５３】
第２に、自動タイムアウトにより終了する場合、一般に、タイムアウトは数秒、例えば、２〜５秒に設定されており、数十マイクロ秒（μｓｅｃ）と比較すれば、非常に大きい時間であるため、自動タイムアウトによる終了も現実的には不可能であることが分かる。
【００５４】
最後に、プログラム誤りにより終了する場合、これは明確にクライアントプログラムの誤りであると解析され得るため、異常なセッション終了を規定する仮定では除外する。
【００５５】
従って、本実施形態では、図３でのようにクライアント１００がＧＥＴパケットが発生した後、即座にＦＩＮパケットを発生する場合、該当クライアント１００をＤＤｏＳ攻撃者であると判断してクライアント１００へのデータパケット伝送を遮断できる。
【００５６】
また、段階（Ｓ３０６）のＧＥＴパケットと段階（Ｓ３０８）のＦＩＮパケットは数十マイクロ秒（μｓｅｃ）の差で発生するが、段階（Ｓ３１０）の ＡＣＫ パケットは数ミリ秒（ｍｓｅｃ）以後に発生し得る。
【００５７】
従って、本実施形態では、このように正常なセッション設定が完了した後、クライアント１００のデータ（サービス）要請（Ｓ３０６）とデータ提供サーバ１０６の ＡＣＫ パケット伝送（Ｓ３１０）との間にクライアント１００のセッション終了要請（Ｓ３０８）が発生する場合に、クライアント１００を攻撃者であると判断してクライアント１００とデータ提供サーバ１０６との連結を遮断できる。このとき、段階（Ｓ３０８）のセッション終了パケットは、ＦＩＮパケットの代わりに、ＲＳＴパケットが用いられてもよい。
【００５８】
また、本実施形態では、段階（Ｓ３１０）のサービス応答に対してクライアント１００のソケットが活性化されている場合に、クライアント１００はＡＣＫパケットを発生して応答を正常に受け取ったことをサーバに通知しなければならないが、攻撃者の場合に段階（Ｓ３０８）のセッション終了要請によりソケットが終了するので、段階（Ｓ３１０）の応答パケットに対するＡＣＫパケットが発生しない。従って、データ提供サーバ１０６の応答パケット（Ｓ３１０）に対してクライアント１００のＡＣＫパケットが発生しない場合にもクライアント１００を攻撃者として判断できる。
【００５９】
以下では、本実施形態によるネットワーク上のアプリケーションレイヤ保護方法、具体的に、クライアント１００とアプリケーションレイヤ保護サービスサーバ１０４及びデータ提供サーバ１０６間のサービス過程を図４の状態遷移図（ｓｔａｔｅ ｍａｃｈｉｎｅ）を参照して例示的に説明する。
【００６０】
図４の状態遷移図はウェブサービスに対してそれぞれのセッション毎に１つずつ生成され得る。
【００６１】
まず、状態Ｓ０はクライアント１００が新たなセッションを要請するかをモニタリングする過程であって、クライアント１００のＳＹＮパケットがモニタリングされれば、アプリケーションレイヤ保護サービスサーバ１０４は状態Ｓ０を状態Ｓ１に変更し、データ提供サーバ１０６の（ＳＹＮ＋ＡＣＫ）パケットを待機する。
【００６２】
このとき、データ提供サーバ１０６から（ＳＹＮ＋ＡＣＫ）パケットが伝送されれば、アプリケーションレイヤ保護サービスサーバ１０４は状態Ｓ１を状態Ｓ２に変更し、クライアント１００がＡＣＫパケットを伝送してセッションが完成するかをモニタリングして状態Ｓ２を状態Ｓ３に変更する。
【００６３】
状態Ｓ３でアプリケーションレイヤ保護サービスサーバ１０４はクライアント１００がＧＥＴパケットを発生する場合、攻撃を探知する状態Ｓ４に移動できる。
【００６４】
状態Ｓ４でアプリケーションレイヤ保護サービスサーバ１０４は、データ提供サーバ１０６の応答が先にモニタリングされる場合に現在の状態を状態Ｓ６に変化させ、正常連結が終了する経路に再び状態Ｓ０にフィードバックする。
【００６５】
このとき、状態Ｓ６から状態Ｓ０に遷移する過程には、クライアント１００とデータ提供サーバ１０６が多くのパケットをやり取りするが、これは正常なプロトコルで進められるため、本実施形態におけるアプリケーションレイヤ保護方法では除外する。
【００６６】
また、状態Ｓ４で、クライアント１００がＦＩＮパケット又はＲＳＴパケットを発生する場合、アプリケーションレイヤ保護サービスサーバ１０４は現在のクライアントをアプリケーションレイヤ攻撃クライアントとして判断し、状態Ｓ５に遷移して攻撃に対応する動作を行う。このような攻撃に対応する動作は、例えば、該当クライアントのＩＰを即座に遮断するか、又は該当ＩＰをＩＰＳ、ＦＷなどに伝達して遮断する動作が含まれ得る。
【００６７】
更に、状態Ｓ５から状態Ｓ０に遷移しながらクライアント１００とデータ提供サーバ１０６間で数回パケットをやり取りするが、これは本実施形態のアプリケーションレイヤ保護方法と関係ない部分であるため、詳細な説明を省略する。
【００６８】
また、状態Ｓ３で探知を避けるためにクライアント１００がＧＥＴパケット以外の他のパケットを伝達する場合には状態Ｓ３を持続でき、セッション連結を終了する場合には現在の状態を状態Ｓ０に遷移できる。
【００６９】
そして、状態Ｓ０を除いた残りの状態ではプロトコルにより正常／異常連結終了行為が可能であるが、これは本実施形態のアプリケーションレイヤ保護方法と関係ないため、具体的な説明は省略する。
【００７０】
以上でＨＴＴＰプロトコルを例に挙げてアプリケーションレイヤに対するＤＤｏＳ攻撃を探知し対応する方法を説明したが、他のアプリケーションプログラムの場合にもセッションを開け、サービス要求と共にセッション終了を要請するクライアントはサービス要請に対する応答を参照しないため、このようなクライアントをサービス妨害攻撃者として探知し対応できる。特に、サーバのキープアライブオプションをオフした場合にサーバは１つのセッションで１つのＧＥＴパケットを受信した後、即座にセッションを終了するので、更に効果的に攻撃を防御できる。
【００７１】
以上のように、本発明は図３で説明した攻撃者の行為を示すＩＰを探し、これを遮断するか、又はＧＥＴパケットと同時に、ＦＩＮパケットが発生するＧＥＴパケットを遮断してＤＤｏＳ攻撃を探知し対応することを特徴とする。また、ＦＩＮパケットの代わりに、ＲＳＴパケットを用いてセッションを終了する場合も含む。
【００７２】
本発明では図２の正常なサービス要請と明確に区分される図３の攻撃者の特徴であるＧＥＴパケットの発生後、即座にＦＩＮパケットを発生したＩＰ又はパケットに対する直接的な探知及び対応が可能であるので、誤り警報を発生せず、ＤＤｏＳ攻撃者を探し対応できる。また、既存の方法は伝送率制限機能を行うために多くのリソースを要求するが、本実施形態による方法はアプリケーションレイヤＤＤｏＳパケットを発生する攻撃者を直接探して対応できるため、リソースが節約される。更に、サービス応答に対するクライアントの応答であるＡＣＫパケットの有無でも攻撃者を探すことができる。また、ＧＥＴパケットに次いでＦＩＮパケットが続くかを確認し、パケット単位で対応する場合、ＮＡＴを用いるネットワークで正常なユーザとゾンビＰＣのトラフィックが混在している場合にも対応が可能である。
【技術分野】
【０００１】
本発明はコンピュータネットワークシステムのアプリケーションレイヤ（ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）を攻撃する分散サービス妨害（Ｄｉｓｔｒｉｂｕｔｅ Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ、ＤＤｏＳ）攻撃に対する対応技術に関し、特に、コンピュータネットワークシステムが正常なサービスを提供できないようにする分散サービス妨害攻撃を探知し、これを遮断するコンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置に関する。
【背景技術】
【０００２】
近年、ネットワーク、電子技術などの発展に伴い、ウェブなどの多様なサービスの提供を容易に受けてはいるが、技術の発展と共に、多様なハッキングツールの登場によってコンピュータネットワークシステムで提供されるサービスを妨害したり、ハッキングする行為も益々頻繁になっている。
【０００３】
また、このようなコンピュータネットワークシステムのハッキングは、金銭的な利益を得るための多様な攻撃形態に変化しており、特に、分散サービス妨害（ＤＤｏＳ）攻撃はウェブなどを介した正常なサービスが不可能なようにする攻撃であって、ゾンビ（ｚｏｍｂｉｅ）ＰＣなどのネットワークグループであるボットネット（ｂｏｔｎｅｔ）などを悪用して激しさが増している傾向にある。
【０００４】
このような分散サービス妨害攻撃に対応するために、幾つかの探知及び対応技法が開発されてはいるが、大部分の分散サービス妨害攻撃に対する対応技法がネットワーク水準（ｎｅｔｗｏｒｋ ｌｅｖｅｌ）のＳＹＮフラッディング（ＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）ｆｌｏｏｄｉｎｇ）などを探知し、遮断する方法に限られており、ウェブサーバなどのアプリケーションレイヤサービスを妨害する分散サービス妨害攻撃に対する探知及び対応方法としては、伝送率制限（ｒａｔｅ ｌｉｍｉｔ）のようにウェブサーバに入力されるパケットを低減する攻撃緩和技法が殆どであり、アプリケーションレイヤの分散サービス妨害攻撃パケットやソースＩＰを探して対応する技術は存在しない。
【０００５】
現在、アプリケーションレイヤの分散サービス妨害攻撃を探知し対応するために、伝送率制限などの技術を活用するので、緩和された攻撃パケットがそのままサーバに伝達されてサーバの負荷が発生するフォールスネガティブ（ｆａｌｓｅ ｎｅｇａｔｉｖｅ）現象と、正常にサービスを要請したユーザのパケットが遮断されるフォールスポジティブ（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ）の発生リスクを同時に有している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特開２００８−０２７１１４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、本発明は上記事情に鑑みてなされたものであって、その目的は、コンピュータネットワークシステムにおいてウェブサービスのようなアプリケーションレイヤのサービスを妨害する分散サービス妨害（ＤＤｏＳ）攻撃を正確に探知し、防御できるコンピュータネットワークシステムのアプリケーションレイヤ保護方法及び装置を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の課題を解決するための一態様によれば、コンピュータネットワークシステムのアプリケーションレイヤを保護する方法は、クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階とを含むことを特徴とする。
【０００９】
本発明の他の様態によれば、コンピュータネットワークシステムのアプリケーションレイヤを保護する装置は、クライアントからのセッション連結要請に従ってネットワークを介して前記クライアントとのセッションを設定し、前記クライアントのデータ要請に応答してデータパケットを前記ネットワークを介して前記クライアントに伝送するように構成されたデータ提供サーバと、前記ネットワークを介して前記クライアントと前記データ提供サーバとのセッションが設定された状態で、前記データ要請に対して前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知するように構成されたアプリケーションレイヤ保護サービスサーバとを含むことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、正常なサービス要請と明確に区分される攻撃者特徴であるゲット（ＧＥＴ）パケットの発生後、即座にフィン（ＦＩＮ）パケットを発生したＩＰ又はパケットに対する直接的な探知及び対応が可能であるので、誤り警報（ｆａｌｓｅ ａｌａｒｍ）を発生せず、分散サービス妨害攻撃者を探し、対応できるという効果を奏する。また、従来は伝送率制限機能を行うために多くのリソースを要求するが、本発明ではアプリケーションレイヤの分散サービス妨害パケットを発生する攻撃者を直接探して対応できるため、リソースが節約される。更に、本発明では、クライアントの連結終了要請の後、サービス応答に対するクライアントの応答であるアック（ＡＣＫ）パケットの有無でも攻撃者を探すことができる。また、ゲット（ＧＥＴ）パケットの後にフィン（ＦＩＮ）が続くかを確認し、パケット単位で対応する場合、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を用いるネットワークで正常なユーザとゾンビＰＣのトラフィックが混在している場合にも対応が可能である。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態が適用されるコンピュータネットワークシステムのブロック構成図である。
【図２】アプリケーションレイヤにおけるクライアントとデータ提供サーバ間のウェブサービスを行う過程を示す図である。
【図３】分散サービス妨害攻撃の動作を示す図である。
【図４】本発明の実施形態によるコンピュータネットワークシステムのアプリケーションレイヤ保護方法を示すフローチャートである。
【発明を実施するための形態】
【００１２】
本発明ではコンピュータネットワークシステムのアプリケーションレイヤに対する分散サービス妨害（ＤＤｏＳ）攻撃を探知し、対応する方法を提示する。このようなアプリケーションレイヤの攻撃に対する探知及び対応方法を詳細に記述するために、代表的なアプリケーションサービスであるウェブサービスを例に挙げて説明する。
【００１３】
ホストでＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信プログラムを作成するためには、ソケット（ｓｏｃｋｅｔ）を用いる。ソケットは、ＴＣＰ／ＩＰレイヤとアプリケーションレイヤとを連結する一種のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。一部のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）では安全性の問題などにより、ソケットを介さないネットワーク階層の接続を許容しないので、大部分の通信プログラムはソケットを活用している。
【００１４】
このようなソケットを介した通信プログラムのうち、ＴＣＰを利用するプログラムの場合は、セッション（ｓｅｓｓｉｏｎ）を形成した後、アプリケーションレイヤのデータ通信が可能であり、データ通信が終了した後にセッションを終了する過程で通信が行われる。
【００１５】
本発明は、クライアント（ｃｌｉｅｎｔ）とサーバ（ｓｅｒｖｅｒ）間のセッションが連結された状態で、クライアントからサーバにデータが要請され、既に設定された時間内に（又はデータ要請後、即座に）セッション終了が要請された場合、或いはクライアントのソケットがクライアントとサーバとの間のセッションを既に終了したため、サーバがクライアントに伝送した応答パケット（Ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）に対してクライアントがサーバに確認パケット（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ ｐａｃｋｅｔ、以下「ＡＣＫパケット」という）を発生しない場合に、該当クライアントを分散サービス妨害攻撃者であると認識して該当クライアントとサーバとの連結を遮断するように構成される。
【００１６】
以下、添付する図面を参照して本発明の実施形態について具体的に説明する。
【００１７】
まず、図１は、本発明の実施形態が適用され得るコンピュータネットワークシステムのブロック構成図である。コンピュータネットワークシステムは、クライアント１００、通信ネットワーク１０２、アプリケーションレイヤ保護サービスサーバ１０４、データ提供サーバ１０６を含む。
【００１８】
図１に示すように、クライアント１００は、ネットワーク１０２に接続してアプリケーションレイヤサービスなどの提供を受けるユーザ側端末、例えば、デスクトップ（ｄｅｓｋ-ｔｏｐ）、ラップトップ（ｌａｐ-ｔｏｐ）などを称するものであって、通信ネットワーク１０２を介してデータ提供サービス、アプリケーションレイヤサービスなどをユーザに提供できる。このようなクライアント１００は、デスクトップ、ラップトップだけでなく、アプリケーションレイヤのサービスを妨害するゾンビＰＣも含むことができる。また、図１には１つのクライアント１００を示したが、これは説明の便宜のためのものであって、通信ネットワーク１０２上には多数のクライアントが連結され得ることが本発明の技術分野における通常の知識を有する者であれば、容易に分かる。
【００１９】
通信ネットワーク１０２は、例えば、有/無線インターネットのような、開放型コンピュータネットワーク構造を意味し、クライアント１００にネットワーク接続環境を提供できる。
【００２０】
アプリケーションレイヤ保護サービスサーバ１０４は、ウェブサービスのようなアプリケーションレイヤのサービスを妨害する攻撃形態、例えば、ＤＤｏＳ攻撃を探知し防御する役割を果す。このようなアプリケーションレイヤ保護サービスサーバ１０４は、例えばＩＤＳ（Ｉｎｔｅｒｎｅｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）、ＩＰＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｖｉｄｅｒ Ｓｅｃｕｒｉｔｙ）、ＦＷ（Ｆｉｒｅｗａｌｌ）、ウェブＦＷ又はＤＤｏＳ専用装備の形態で実現されることも可能である。
【００２１】
データ提供サーバ１０６は、ＴＣＰ／ＩＰプロトコル及びその上位階層に存在する多様なサービス、即ち、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、テルネット（Ｔｅｌｎｅｔ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｅｒｖｉｃｅ）、ＮＩＳ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）を提供する。このようなデータ提供サーバ１０６は通信ネットワーク１０２を通じてクライアント１００にデータ、例えば、ウェブページ及び／又はコンテンツなどのサービスを提供するウェブサーバ又はコンテンツサーバとしての役割を果す。
【００２２】
図１ではアプリケーションレイヤ保護サービスサーバ１０４とデータ提供サーバ１０６をそれぞれ別個のサーバとして示したが、これは説明の便宜上、１つの実施形態として示しただけで、アプリケーションレイヤ保護サービスサーバ１０４とデータ提供サーバ１０６が単一のサーバに統合運営されることもできることを周知する必要がある。
【００２３】
アプリケーションレイヤ保護サービスサーバ１０４は、通信ネットワーク１０２を介してデータ提供サーバ１０６とクライアント１００とのセッションが設定された状態で、クライアント１００からのデータ要請に続いて（又はデータ要請後、即座に）セッション終了が要請される場合に、クライアント１００をアプリケーションレイヤを攻撃するクライアント（即ち、ＤＤｏＳ攻撃者）と見なしてクライアント１００から要請されたデータのパケットを遮断することで、ＨＴＴＰ ＧＥＴフラッディング又はキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）などのようなＤＤｏＳ攻撃からアプリケーションレイヤを保護できる。
【００２４】
また、アプリケーションレイヤ保護サービスサーバ１０４は、データ提供サーバ１０６とクライアント１００とのセッションが既に終了されたためアプリケーションレイヤ保護サービスサーバ１０４の応答パケットに対してクライアント１００がＡＣＫパケットを発生しなければ、クライアント１００をアプリケーションレイヤを攻撃するクライアント（即ち、ＤＤｏＳ攻撃者）として認識してクライアント１００とデータ提供サーバ１０６間の連結を遮断することで、ＨＴＴＰ ＧＥＴフラッディング又はＣＣフラッディングなどのようなＤＤｏＳ攻撃からアプリケーションレイヤを保護できる。このようなアプリケーションレイヤ保護サービスサーバ１０４の連結遮断は、例えば、クライアント１００のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を遮断することで実現され得る。
【００２５】
図２は、このようなアプリケーションレイヤにおけるネットワークサービス、例えば、クライアント１００とデータ提供サーバ１０６間のウェブサービスを行う過程を示す図である。
【００２６】
まず、クライアント１００は、サービス要請のためにデータ提供サーバ１０６にセッション連結を要請する（Ｓ２００）。このようなセッションの連結要請は、例えば、クライアント１００からデータ提供サーバ１０６に同期シーケンス番号（ＳＹＮ）パケット（Ｓｙｎｃｈｒｏｎｉｚｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ ｐａｃｋｅｔ、以下、「ＳＹＮパケット」という）を伝送するものとして実現され得る。
【００２７】
このとき、データ提供サーバ１０６のリソースが許容される場合には、データ提供サーバ１０６はクライアント１００のセッション連結の要請に応答する（Ｓ２０２）。このようなセッション連結要請の応答は、例えば（ＳＹＮ＋ＡＣＫ）パケットを伝送するものとして実現され得る。
【００２８】
（ＳＹＮ＋ＡＣＫ）パケットを受信したクライアント１００は、再びデータ提供サーバ１０６にＡＣＫパケットを伝送することによって、これらの間のセッションが連結され得る（Ｓ２０４）。
【００２９】
このように、クライアント１００とデータ提供サーバ１０６間のセッションが連結された状態で、クライアント１００は所望のデータ、例えば、ウェブページ又はコンテンツをデータ提供サーバ１０６に要請できる（Ｓ２０６）。このようなデータの要請は、例えば、クライアント１００からデータ提供サーバ１０６にＧＥＴパケットを伝送するものとして実現され得る。
【００３０】
ＧＥＴパケットを受信したデータ提供サーバ１０６は、クライアント１００から要請されたデータをパケット形態でクライアント１００に伝送する（Ｓ２０８）。
【００３１】
要請されたデータがデータ提供サーバ１０６からクライアント１００に伝送されれば、クライアント１００はデータ提供サーバ１０６からのパケットのデータの受信を応答する（Ｓ２１０）。このようなデータ受信応答は、例えば、クライアント１００からデータ提供サーバ１０６にＡＣＫパケットを伝送するものとして実現され得る。
【００３２】
その後、全てのパケットを伝送したデータ提供サーバ１０６は、クライアント１００に連結終了を要請できる（Ｓ２１２）。このような連結終了要請は、例えば、データ提供サーバ１０６からクライアント１００に終了パケット（ＦＩＮｉｓｈ Ｐａｃｋｅｔ、以下、「ＦＩＮパケット」という）を伝送するものとして実現され得る。
【００３３】
このとき、データ提供サーバ１０６でキープアライブ（ｋｅｅｐ ａｌｉｖｅ）値をオフした場合には最終のデータを伝達した後、即座に、又は最終のデータと同時にＦＩＮパケットをクライアント１００に伝送できる。データ提供サーバ１０６でキープアライブ値をオンした場合にはデータ提供サーバ１０６のキープアライブ時間（ｋｅｅｐ ａｌｉｖｅ ｔｉｍｅ）を超えれば、ＦＩＮパケットをクライアント１００に伝送できる。
【００３４】
その後、クライアント１００はセッション終了要請のためのＦＩＮパケットをデータ提供サーバ１０６に伝送し（Ｓ２１４）、リセットパケット（ＲｅＳｅＴ ｐａｃｋｅｔ、以下、「ＲＳＴパケット」という）によりクライアント１００とデータ提供サーバ１０６間のセッションが終了し得る。
【００３５】
図３は、ＤＤｏＳ攻撃ツール、例えば、ネットボット（ｎｅｔｂｏｔ）で発生し得るトラフィック特徴を示す図である。
【００３６】
まず、クライアント１００は、サービス要請のためにデータ提供サーバ１０６にセッション連結を要請する（Ｓ３００）。このようなセッション連結要請は、例えば、クライアント１００からデータ提供サーバ１０６にＳＹＮパケットを伝送するものとして実現され得る。
【００３７】
このとき、データ提供サーバ１０６のリソースが許容される場合には、データ提供サーバ１０６はクライアント１００のセッション連結の要請に応答できる（Ｓ３０２）。このようなセッション連結応答は、例えば（ＳＹＮ＋ＡＣＫ）パケットを伝送するものとして実現され得る。
【００３８】
（ＳＹＮ＋ＡＣＫ）パケットを受信したクライアント１００は再びデータ提供サーバ１０６にＡＣＫパケットを伝送することによって、これらの間のセッションが連結され得る（Ｓ３０４）。
【００３９】
このように、クライアント１００とデータ提供サーバ１０６間のセッションが連結された状態で、クライアント１００は所望のデータ、例えば、ウェブページをデータ提供サーバ１０６に要請できる（Ｓ３０６）。このようなデータの要請は、例えば、クライアント１００からデータ提供サーバ１０６にＧＥＴパケットを伝送するものとして実現され得る。
【００４０】
前述した過程は図２のアプリケーションレイヤにおけるサービス、例えば、クライアント１００とデータ提供サーバ１０６間のウェブサービスの実行過程と同一である。
【００４１】
しかし、アプリケーションレイヤを攻撃しようとする場合には、クライアント１００が即座にＦＩＮパケットを発生してデータ提供サーバ１０６にセッション終了を要請できる（Ｓ３０８）。
【００４２】
従って、クライアント１００のデータサービス要請の過程（Ｓ３０６）とデータ提供サーバ１０６の応答パケット（ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）伝送の過程（Ｓ３１０）との間でクライアント１００がセッション終了を要請すると、データ提供サーバ１０６はまず受信されたクライアント１００からのＧＥＴパケットに対する応答として応答パケット（ｒｅｓｐｏｎｓｅ ｐａｃｋｅｔ）を発生してクライアント１００に伝送し（Ｓ３１０）、後に次いでＲＳＴパケットを発生してセッションを終了する（Ｓ３１２）。
【００４３】
このような過程は、以下の通り解釈され得る。
【００４４】
まず、ボットネットもソケットプログラムで作成されているので、多くのアプリケーションレイヤサービスの要求が発生するためにはサービス要請が完了したセッションは必ず終了しなければならない。なぜならば、セッションを終了しなければ、クライアントのソケットリソースが枯渇してしまい、持続的なパケットの発生が不可能であるためである。
【００４５】
例えば、図３の段階（Ｓ３０８）でクライアントがＦＩＮパケットを発生せず、新たなセッションを継続して生成すれば、クライアントのソケットリソースの枯渇によりこれ以上通信が不可能になる。
【００４６】
それで、クライアントで持続的に攻撃パケットを発生するためには必ずセッションを終了しなければならない。また、攻撃者の場合にサーバから送られるデータは関心の対象でないため、これらを受信する必要はない。仮に図２に示されているように、正常にセッションを持続する場合、攻撃者が所望の量のセッションとパケットを発生できず、サーバが攻撃を受ける状況ではサーバの負荷によって段階（Ｓ２１４）のセッション終了要請が遅れて攻撃者もパケットを発生できない状況を経験できる。しかし、ＤＤｏＳ攻撃者はサーバがサービスを提供できないようにすることが目的であるため、図３の段階（Ｓ３０８）でのように、セッション終了要請を即座に行わざるを得ない。
【００４７】
ウェブサービスの場合にＨＴＴＰ１.０標準文書には以下の通り記述している。
【００４８】
「実験的なアプリケーションプログラムを除いた実際のアプリケーションにおいて各要求メッセージの伝達に先立ち、クライアントにより連結がまず設立されなければならず、サーバが応答を先に送り、連結を切るようにしなければならない。このとき、クライアントとサーバはユーザの動作や自動的なタイムアウト、又はプログラム誤りにより、どちらであれ、途中で連結を解除する可能性もあるということが分からなければならず、適切な対応動作が可能でなければならない。どの場合であっても、何れか一方又は両方ともの連結解除は常に現在の要求に対する削除を意味する。」
【００４９】
ＨＴＴＰ１.０標準文書ではサーバがデータ通信を完了した後、セッションを終了することが正常なサービス終了であると規定しており、異常なセッション終了は、以下の３つに規定している。
１．ユーザの動作による終了
２．自動的なタイムアウトによる終了
３．プログラム誤りによる終了
【００５０】
図３の状況が発生し得る場合を上記誤りの状況と比較すると、以下のような結論が得られる。
【００５１】
まず、実際、ネットボットとソケットプログラムで確認した結果、段階（Ｓ３０６）のＧＥＴパケットと段階（Ｓ３０８）のＦＩＮパケットが発生する時間間隔が、例えば、数十マイクロ秒（μｓｅｃ）以内、具体的に、１０〜９０マイクロ秒（μｓｅｃ）の間であって、極めて短いことが確認でき、このように短時間内で２つのパケットが発生する理由は最大限に多くの攻撃パケットを生成するためである。
【００５２】
このとき、上述したユーザの動作による終了は、その発生可能性が非常に低いと見られる。仮に、ユーザがウェブブラウザを通じてウェブサービス要請であるＧＥＴパケットを発生し、即座にＦＩＮパケットを発生するためには、数十マイクロ秒（μｓｅｃ）以内にウェブブラウザを閉じなければならないが、現実的にこのように速くユーザがウェブブラウザを閉じることは不可能である。
【００５３】
第２に、自動タイムアウトにより終了する場合、一般に、タイムアウトは数秒、例えば、２〜５秒に設定されており、数十マイクロ秒（μｓｅｃ）と比較すれば、非常に大きい時間であるため、自動タイムアウトによる終了も現実的には不可能であることが分かる。
【００５４】
最後に、プログラム誤りにより終了する場合、これは明確にクライアントプログラムの誤りであると解析され得るため、異常なセッション終了を規定する仮定では除外する。
【００５５】
従って、本実施形態では、図３でのようにクライアント１００がＧＥＴパケットが発生した後、即座にＦＩＮパケットを発生する場合、該当クライアント１００をＤＤｏＳ攻撃者であると判断してクライアント１００へのデータパケット伝送を遮断できる。
【００５６】
また、段階（Ｓ３０６）のＧＥＴパケットと段階（Ｓ３０８）のＦＩＮパケットは数十マイクロ秒（μｓｅｃ）の差で発生するが、段階（Ｓ３１０）の ＡＣＫ パケットは数ミリ秒（ｍｓｅｃ）以後に発生し得る。
【００５７】
従って、本実施形態では、このように正常なセッション設定が完了した後、クライアント１００のデータ（サービス）要請（Ｓ３０６）とデータ提供サーバ１０６の ＡＣＫ パケット伝送（Ｓ３１０）との間にクライアント１００のセッション終了要請（Ｓ３０８）が発生する場合に、クライアント１００を攻撃者であると判断してクライアント１００とデータ提供サーバ１０６との連結を遮断できる。このとき、段階（Ｓ３０８）のセッション終了パケットは、ＦＩＮパケットの代わりに、ＲＳＴパケットが用いられてもよい。
【００５８】
また、本実施形態では、段階（Ｓ３１０）のサービス応答に対してクライアント１００のソケットが活性化されている場合に、クライアント１００はＡＣＫパケットを発生して応答を正常に受け取ったことをサーバに通知しなければならないが、攻撃者の場合に段階（Ｓ３０８）のセッション終了要請によりソケットが終了するので、段階（Ｓ３１０）の応答パケットに対するＡＣＫパケットが発生しない。従って、データ提供サーバ１０６の応答パケット（Ｓ３１０）に対してクライアント１００のＡＣＫパケットが発生しない場合にもクライアント１００を攻撃者として判断できる。
【００５９】
以下では、本実施形態によるネットワーク上のアプリケーションレイヤ保護方法、具体的に、クライアント１００とアプリケーションレイヤ保護サービスサーバ１０４及びデータ提供サーバ１０６間のサービス過程を図４の状態遷移図（ｓｔａｔｅ ｍａｃｈｉｎｅ）を参照して例示的に説明する。
【００６０】
図４の状態遷移図はウェブサービスに対してそれぞれのセッション毎に１つずつ生成され得る。
【００６１】
まず、状態Ｓ０はクライアント１００が新たなセッションを要請するかをモニタリングする過程であって、クライアント１００のＳＹＮパケットがモニタリングされれば、アプリケーションレイヤ保護サービスサーバ１０４は状態Ｓ０を状態Ｓ１に変更し、データ提供サーバ１０６の（ＳＹＮ＋ＡＣＫ）パケットを待機する。
【００６２】
このとき、データ提供サーバ１０６から（ＳＹＮ＋ＡＣＫ）パケットが伝送されれば、アプリケーションレイヤ保護サービスサーバ１０４は状態Ｓ１を状態Ｓ２に変更し、クライアント１００がＡＣＫパケットを伝送してセッションが完成するかをモニタリングして状態Ｓ２を状態Ｓ３に変更する。
【００６３】
状態Ｓ３でアプリケーションレイヤ保護サービスサーバ１０４はクライアント１００がＧＥＴパケットを発生する場合、攻撃を探知する状態Ｓ４に移動できる。
【００６４】
状態Ｓ４でアプリケーションレイヤ保護サービスサーバ１０４は、データ提供サーバ１０６の応答が先にモニタリングされる場合に現在の状態を状態Ｓ６に変化させ、正常連結が終了する経路に再び状態Ｓ０にフィードバックする。
【００６５】
このとき、状態Ｓ６から状態Ｓ０に遷移する過程には、クライアント１００とデータ提供サーバ１０６が多くのパケットをやり取りするが、これは正常なプロトコルで進められるため、本実施形態におけるアプリケーションレイヤ保護方法では除外する。
【００６６】
また、状態Ｓ４で、クライアント１００がＦＩＮパケット又はＲＳＴパケットを発生する場合、アプリケーションレイヤ保護サービスサーバ１０４は現在のクライアントをアプリケーションレイヤ攻撃クライアントとして判断し、状態Ｓ５に遷移して攻撃に対応する動作を行う。このような攻撃に対応する動作は、例えば、該当クライアントのＩＰを即座に遮断するか、又は該当ＩＰをＩＰＳ、ＦＷなどに伝達して遮断する動作が含まれ得る。
【００６７】
更に、状態Ｓ５から状態Ｓ０に遷移しながらクライアント１００とデータ提供サーバ１０６間で数回パケットをやり取りするが、これは本実施形態のアプリケーションレイヤ保護方法と関係ない部分であるため、詳細な説明を省略する。
【００６８】
また、状態Ｓ３で探知を避けるためにクライアント１００がＧＥＴパケット以外の他のパケットを伝達する場合には状態Ｓ３を持続でき、セッション連結を終了する場合には現在の状態を状態Ｓ０に遷移できる。
【００６９】
そして、状態Ｓ０を除いた残りの状態ではプロトコルにより正常／異常連結終了行為が可能であるが、これは本実施形態のアプリケーションレイヤ保護方法と関係ないため、具体的な説明は省略する。
【００７０】
以上でＨＴＴＰプロトコルを例に挙げてアプリケーションレイヤに対するＤＤｏＳ攻撃を探知し対応する方法を説明したが、他のアプリケーションプログラムの場合にもセッションを開け、サービス要求と共にセッション終了を要請するクライアントはサービス要請に対する応答を参照しないため、このようなクライアントをサービス妨害攻撃者として探知し対応できる。特に、サーバのキープアライブオプションをオフした場合にサーバは１つのセッションで１つのＧＥＴパケットを受信した後、即座にセッションを終了するので、更に効果的に攻撃を防御できる。
【００７１】
以上のように、本発明は図３で説明した攻撃者の行為を示すＩＰを探し、これを遮断するか、又はＧＥＴパケットと同時に、ＦＩＮパケットが発生するＧＥＴパケットを遮断してＤＤｏＳ攻撃を探知し対応することを特徴とする。また、ＦＩＮパケットの代わりに、ＲＳＴパケットを用いてセッションを終了する場合も含む。
【００７２】
本発明では図２の正常なサービス要請と明確に区分される図３の攻撃者の特徴であるＧＥＴパケットの発生後、即座にＦＩＮパケットを発生したＩＰ又はパケットに対する直接的な探知及び対応が可能であるので、誤り警報を発生せず、ＤＤｏＳ攻撃者を探し対応できる。また、既存の方法は伝送率制限機能を行うために多くのリソースを要求するが、本実施形態による方法はアプリケーションレイヤＤＤｏＳパケットを発生する攻撃者を直接探して対応できるため、リソースが節約される。更に、サービス応答に対するクライアントの応答であるＡＣＫパケットの有無でも攻撃者を探すことができる。また、ＧＥＴパケットに次いでＦＩＮパケットが続くかを確認し、パケット単位で対応する場合、ＮＡＴを用いるネットワークで正常なユーザとゾンビＰＣのトラフィックが混在している場合にも対応が可能である。
【特許請求の範囲】
【請求項１】
コンピュータネットワークシステムのアプリケーションレイヤを保護する方法であって、
クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、
前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階と
を含むことを特徴とするコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項２】
前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに伝送した前記応答パケットに対して前記クライアントからの確認パケット（ＡＣＫ ｐａｃｋｅｔ）が発生しなければ、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知する段階を更に含むことを特徴とする請求項１に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項３】
前記アプリケーションレイヤ攻撃クライアントは、分散サービス妨害（ＤＤｏＳ）攻撃を実行するクライアントであることを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項４】
前記分散サービス妨害攻撃は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ゲットフラッディング(ＧＥＴ ｆｌｏｏｄｉｎｇ)攻撃及びキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）攻撃を含むことを特徴とする請求項３に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項５】
前記クライアントが前記アプリケーションレイヤ攻撃クライアントであると探知される時、前記クライアントと前記データ提供サーバとの連結を遮断する段階を更に含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項６】
前記データ要請は、前記クライアントから前記データ提供サーバにＧＥＴパケット（ＧＥＴ ｐａｃｋｅｔ）を伝送することを含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項７】
前記セッション終了要請は、前記クライアントから前記データ提供サーバに終了パケット（ＦＩＮ ｐａｃｋｅｔ）又はリセットパケット（ＲＳＴ ｐａｃｋｅｔ）を伝送することを含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項８】
前記コンピュータネットワークシステムは、ＴＣＰ／ＩＰプロトコルに基づくことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項９】
コンピュータネットワークシステムのアプリケーションレイヤを保護する装置であって、
クライアントからのセッション連結要請に従ってネットワークを介して前記クライアントとのセッションを設定し、前記クライアントのデータ要請に応答してデータパケットを前記ネットワークを介して前記クライアントに伝送するように構成されたデータ提供サーバと、
前記データ要請に対して前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知するように構成されたアプリケーションレイヤ保護サービスサーバと
を含むことを特徴とするコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１０】
前記アプリケーションレイヤ攻撃クライアントは、分散サービス妨害（ＤＤｏＳ）攻撃を実行するクライアントであることを特徴とする請求項９に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１１】
前記分散サービス妨害攻撃は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ゲットフラッディング(ＧＥＴ ｆｌｏｏｄｉｎｇ)攻撃及びキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）攻撃を含むことを特徴とする請求項１０に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１２】
前記アプリケーションレイヤ保護サービスサーバは追加で前記クライアントの前記データ要請に従って前記データ提供サーバから前記クライアントに伝送した前記応答パケットに対して前記クライアントからの確認パケット（ＡＣＫ ｐａｃｋｅｔ）が受信されなければ、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知するように構成されることを特徴とする請求項９に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１３】
前記アプリケーションレイヤ保護サービスサーバは、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知する時、前記クライアントと前記データ提供サーバとの連結を遮断するように構成されることを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１４】
前記データ要請は、前記クライアントから前記データ提供サーバにＧＥＴパケットを伝送することを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１５】
前記セッション終了要請は、前記クライアントから前記データ提供サーバに終了パケット（ＦＩＮ ｐａｃｋｅｔ）又はリセットパケット（ＲＳＴ ｐａｃｋｅｔ）を伝送することを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１６】
前記コンピュータネットワークシステムは、ＴＣＰ／ＩＰプロトコルに基づくことを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１】
コンピュータネットワークシステムのアプリケーションレイヤを保護する方法であって、
クライアントからのセッション連結要請に応答してネットワークを介して前記クライアントとデータ提供サーバ間のセッションを設定する段階と、
前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知する段階と
を含むことを特徴とするコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項２】
前記クライアントから前記データ提供サーバへのデータ要請に従って前記データ提供サーバから前記クライアントに伝送した前記応答パケットに対して前記クライアントからの確認パケット（ＡＣＫ ｐａｃｋｅｔ）が発生しなければ、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知する段階を更に含むことを特徴とする請求項１に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項３】
前記アプリケーションレイヤ攻撃クライアントは、分散サービス妨害（ＤＤｏＳ）攻撃を実行するクライアントであることを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項４】
前記分散サービス妨害攻撃は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ゲットフラッディング(ＧＥＴ ｆｌｏｏｄｉｎｇ)攻撃及びキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）攻撃を含むことを特徴とする請求項３に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項５】
前記クライアントが前記アプリケーションレイヤ攻撃クライアントであると探知される時、前記クライアントと前記データ提供サーバとの連結を遮断する段階を更に含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項６】
前記データ要請は、前記クライアントから前記データ提供サーバにＧＥＴパケット（ＧＥＴ ｐａｃｋｅｔ）を伝送することを含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項７】
前記セッション終了要請は、前記クライアントから前記データ提供サーバに終了パケット（ＦＩＮ ｐａｃｋｅｔ）又はリセットパケット（ＲＳＴ ｐａｃｋｅｔ）を伝送することを含むことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項８】
前記コンピュータネットワークシステムは、ＴＣＰ／ＩＰプロトコルに基づくことを特徴とする請求項１又は２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護方法。
【請求項９】
コンピュータネットワークシステムのアプリケーションレイヤを保護する装置であって、
クライアントからのセッション連結要請に従ってネットワークを介して前記クライアントとのセッションを設定し、前記クライアントのデータ要請に応答してデータパケットを前記ネットワークを介して前記クライアントに伝送するように構成されたデータ提供サーバと、
前記データ要請に対して前記データ提供サーバから前記クライアントに応答パケットを伝送する前、前記クライアントからセッション終了要請が発生すれば、前記クライアントをアプリケーションレイヤ攻撃クライアントとして探知するように構成されたアプリケーションレイヤ保護サービスサーバと
を含むことを特徴とするコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１０】
前記アプリケーションレイヤ攻撃クライアントは、分散サービス妨害（ＤＤｏＳ）攻撃を実行するクライアントであることを特徴とする請求項９に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１１】
前記分散サービス妨害攻撃は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ゲットフラッディング(ＧＥＴ ｆｌｏｏｄｉｎｇ)攻撃及びキャッシュコントロールフラッディング（Ｃａｃｈｅ-Ｃｏｎｔｒｏｌ（ＣＣ）ｆｌｏｏｄｉｎｇ）攻撃を含むことを特徴とする請求項１０に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１２】
前記アプリケーションレイヤ保護サービスサーバは追加で前記クライアントの前記データ要請に従って前記データ提供サーバから前記クライアントに伝送した前記応答パケットに対して前記クライアントからの確認パケット（ＡＣＫ ｐａｃｋｅｔ）が受信されなければ、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知するように構成されることを特徴とする請求項９に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１３】
前記アプリケーションレイヤ保護サービスサーバは、前記クライアントを前記アプリケーションレイヤ攻撃クライアントとして探知する時、前記クライアントと前記データ提供サーバとの連結を遮断するように構成されることを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１４】
前記データ要請は、前記クライアントから前記データ提供サーバにＧＥＴパケットを伝送することを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１５】
前記セッション終了要請は、前記クライアントから前記データ提供サーバに終了パケット（ＦＩＮ ｐａｃｋｅｔ）又はリセットパケット（ＲＳＴ ｐａｃｋｅｔ）を伝送することを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【請求項１６】
前記コンピュータネットワークシステムは、ＴＣＰ／ＩＰプロトコルに基づくことを特徴とする請求項９又は１２に記載のコンピュータネットワークシステムのアプリケーションレイヤ保護装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１１−２２９８５（Ｐ２０１１−２２９８５Ａ）
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願番号】特願２００９−２９２１２４（Ｐ２００９−２９２１２４）
【出願日】平成２１年１２月２４日（２００９．１２．２４）
【出願人】（５９６１８００７６）韓國電子通信研究院 (733)
【氏名又は名称原語表記】Ｅｌｅｃｔｒｏｎｉｃｓ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ
【住所又は居所原語表記】１６１ Ｋａｊｏｎｇ−ｄｏｎｇ， Ｙｕｓｏｎｇ−ｇｕ， Ｔａｅｊｏｎ ｋｏｒｅａ
【Ｆターム（参考）】
【公開日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願日】平成２１年１２月２４日（２００９．１２．２４）
【出願人】（５９６１８００７６）韓國電子通信研究院 (733)
【氏名又は名称原語表記】Ｅｌｅｃｔｒｏｎｉｃｓ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ
【住所又は居所原語表記】１６１ Ｋａｊｏｎｇ−ｄｏｎｇ， Ｙｕｓｏｎｇ−ｇｕ， Ｔａｅｊｏｎ ｋｏｒｅａ
【Ｆターム（参考）】
[ Back to top ]