JP2012186519A - 通信システム - Google Patents

通信システム Download PDF

Info

Publication number
JP2012186519A
JP2012186519A JP2011046190A JP2011046190A JP2012186519A JP 2012186519 A JP2012186519 A JP 2012186519A JP 2011046190 A JP2011046190 A JP 2011046190A JP 2011046190 A JP2011046190 A JP 2011046190A JP 2012186519 A JP2012186519 A JP 2012186519A
Authority
JP
Japan
Prior art keywords
node
server
attack
packet
address
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.)
Withdrawn
Application number
JP2011046190A
Other languages
English (en)
Inventor
Takamasa Isohara
隆将 磯原
Ayumi Kubota
歩 窪田
Masaru Miyake
優 三宅
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.)
KDDI Corp
Original Assignee
KDDI 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 KDDI Corp filed Critical KDDI Corp
Priority to JP2011046190A priority Critical patent/JP2012186519A/ja
Publication of JP2012186519A publication Critical patent/JP2012186519A/ja
Withdrawn legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】正規のトラヒックへの影響を抑えつつ、サーバを攻撃から防御することができる通信システムを提供する。
【解決手段】クライアント５からサーバ１の仮想IPアドレス宛てに送信されるパケットは、攻撃防御ノード２および攻撃検知ノード３をこの順に経由してサーバ１に到達する。攻撃検知ノード３は、特定のサーバ１への攻撃が検知された場合に、特定のサーバ１宛てのパケットに基づいて、パケットを送信したクライアント５毎にトラヒック量を検知し、検知したクライアント５毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＭ番目までのトラヒック量に基づいて、攻撃検知ノード３に適用するフィルタリングルールを決定する。
【選択図】図１

Description

本発明は、仮想IPアドレスが割り当てられたサーバと、サーバ宛てのパケットを中継する中継端末とを有する通信システムに関する。
ネットワーク上の通信装置が受ける攻撃の一つに分散DoS（Denial of Service）攻撃がある。分散DoS攻撃とは、攻撃者となる複数の攻撃クライアントが結託して、攻撃対象のサーバに対して、サーバの処理能力を超える多量の不正パケットを送信することで、サーバが提供するサービスの停止を招く攻撃である。
従来、分散DoS攻撃の検知と防御を行う手法として、保護対象のサーバの近傍でサーバ宛のトラヒックを監視し、予め設定した閾値を越えるパケットの到来を検知した場合や、パケット量の急激な変動を検知した場合に、サーバ宛てのトラヒックを遮断する手法がある（例えば、特許文献１参照）。
特開２００６−６７０７８号公報
分散DoS攻撃の攻撃クライアントに近い上流側では、観測される不正パケットの量が少なく、正規なパケットとの見極めが困難であることから、分散DoS攻撃に対する従来の防御手法では、攻撃対象のサーバの近傍でサーバ宛てのトラヒックを全て遮断せざるを得ず、これによって正規のトラヒックも遮断されてしまうため、正規のトラヒックへの影響が大きかった。また、攻撃クライアントを的確に把握できたとしても、ファイアウォールに設定可能な防御ルールの数に制限があることから、攻撃クライアントの数が多数の場合も、サーバ宛のトラヒックを全体的に遮断せざるを得なかった。
本発明は、上述した課題に鑑みてなされたものであって、正規のトラヒックへの影響を抑えつつ、サーバを攻撃から防御することができる通信システムを提供することを目的とする。
本発明は、上記の課題を解決するためになされたもので、通信端末から、実IPアドレスおよび仮想IPアドレスを有するサーバの前記仮想IPアドレス宛てに送信されるパケットを中継する複数の第１の中継端末と、前記第１の中継端末によって中継されたパケットを受信し、受信したパケットを前記仮想IPアドレスに対応した前記実IPアドレス宛てのパケットに変換し、前記サーバとの間で確立されたVPN接続により前記サーバへ変換後のパケットを送信する複数の第２の中継端末と、を備えた通信システムであって、前記第１の中継端末は、パケットを削除するルールを示すルール情報を前記第２の中継端末から受信する受信部と、前記第２の中継端末から受信された前記ルール情報が示すルールに従って、前記第１の中継端末で受信されたパケットを削除するフィルタリング部と、を有し、前記第２の中継端末は、前記サーバ宛てのトラヒック量を検知し、検知したトラヒック量に基づいて、前記サーバ毎に攻撃を検知する検知部と、前記検知部によって特定のサーバへの攻撃が検知された場合に、前記第２の中継端末で受信されたパケットのうち前記特定のサーバ宛てのパケットに基づいて、当該パケットを送信した前記通信端末毎にトラヒック量を検知し、検知した前記通信端末毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＭ（Ｍ：自然数）番目までのトラヒック量に基づいて前記ルールを決定し、前記ルール情報を生成するルール決定部と、前記特定のサーバ宛てのパケットを中継した前記第１の中継端末へ前記ルール情報を送信する送信部と、を有することを特徴とする通信システムである。
また、本発明の通信システムにおいて、前記Ｍは、前記第１の中継端末で設定可能な前記ルールの数であることを特徴とする。
また、本発明の通信システムにおいて、前記ルール決定部は、前記特定のサーバ宛ての全てのトラヒック量と、前記１番目から前記Ｍ番目までのトラヒック量の合計とを比較した結果に基づいて前記ルールを決定することを特徴とする。
また、本発明の通信システムにおいて、前記ルール決定部は、前記１番目から前記Ｍ番目までのトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値以下である場合に、前記１番目から前記Ｍ番目までのトラヒック量に係るパケットを中継した前記第１の中継端末に設定する前記ルールとして、前記１番目から前記Ｍ番目までのトラヒック量に係るパケットを送信した前記通信端末からのパケットを削除するという前記ルールを決定することを特徴とする。
また、本発明の通信システムにおいて、前記ルール決定部は、前記１番目から前記Ｍ番目までの第１のトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値を超える場合に、前記第２の中継端末で受信されたパケットのうち前記特定のサーバ宛てのパケットに基づいて、当該パケットを中継した前記第１の中継端末毎にトラヒック量を検知し、検知した前記第１の中継端末毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＮ（Ｎ：自然数）番目までの第２のトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値以下であれば、前記第１のトラヒック量に係るパケットを中継した前記第１の中継端末に設定する前記ルールとして、前記第２のトラヒック量に係るパケットを中継した前記第１の中継端末で受信される全てのパケットを削除するという前記ルールを決定することを特徴とする。
本発明によれば、通信端末からサーバの仮想IPアドレス宛てに送信されるパケットは、第１の中継端末および第２の中継端末をこの順に経由してサーバに到達する。パケットの転送経路上でよりサーバに近い第２の中継端末が攻撃の検知を行うことによって、より的確に攻撃を検知することが可能となる。また、パケットの転送経路上でより攻撃元の通信端末に近い第１の中継端末がパケットのフィルタリングを行うことによって、攻撃元の通信端末から送信されたパケットの転送によるネットワーク資源の消費をより抑えることが可能となる。さらに、第２の中継端末で検知された通信端末毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＭ番目までのトラヒック量に基づいてルールを決定することによって、攻撃パケットの効率的なフィルタリングと、フィルタリングによる正規のトラヒックへの影響とのバランスをとったルールを決定することが可能となるので、正規のトラヒックへの影響を抑えつつ、サーバを攻撃から防御することができる。
本発明の一実施形態による通信システムの構成を示す構成図である。 本発明の一実施形態による通信システムの機能構成を示すブロック図である。 本発明の一実施形態における初期ノード起動手順を示すシーケンス図である。 本発明の一実施形態におけるノード加入手順を示すシーケンス図である。 本発明の一実施形態におけるノード脱退手順を示すシーケンス図である。 本発明の一実施形態におけるサーバ公開開始手順を示すシーケンス図である。 本発明の一実施形態におけるサーバ公開停止手順を示すシーケンス図である。 本発明の一実施形態における通信手順を示すシーケンス図である。 本発明の一実施形態による攻撃防御ノードと攻撃検知ノードの機能構成を示すブロック図である。 本発明の一実施形態における攻撃検知・防御手順を示すシーケンス図である。 本発明の一実施形態におけるログの構造を示す参考図である。 本発明の一実施形態における攻撃検知ノードの動作の手順を示すフローチャートである。 本発明の一実施形態における攻撃検知ノードの動作の手順を示すフローチャートである。 DHTネットワークにおけるハッシュ空間を示す参考図である。
以下、図面を参照し、本発明の実施形態を説明する。図１は、本発明の一実施形態による通信システムの構成を示している。本通信システムは、サーバを保護する機構を備えたオーバーレイネットワークを構成しており、サーバ１、攻撃防御ノード２（第１の中継端末）、攻撃検知ノード３（第２の中継端末）、管理ノード４、クライアント５（通信端末）を備える。図１に示す各装置の位置は、実際の物理ネットワーク上の位置とは必ずしも一致しない。
サーバ１は、FTP（File Transfer Protocol）サーバやWebサーバ等であり、所定のサービスを提供する。サーバ１には、実ネットワークで用いるIPアドレス（本明細書では実IPアドレスとする）と共に、仮想的なIPアドレス（本明細書では仮想IPアドレスとする）が割り当てられている。
攻撃防御ノード２は、クライアント５からサーバ１宛てに送信されるパケットを攻撃検知ノード３に中継する。また、攻撃防御ノード２は、サーバ１を攻撃から防御するためのパケットフィルタリングを行う。攻撃防御ノード２は、例えばISP（Internet Service Provider）毎のネットワークに設置されており、そのネットワーク内のクライアント５から送信されるパケットを中継する。
攻撃検知ノード３は、攻撃防御ノード２が中継したパケットをサーバ１に中継する。また、攻撃検知ノード３は、サーバ１に対する攻撃を検知する。管理ノード４は、サーバ１に対する仮想IPアドレスの割り当てと、攻撃防御ノード２および攻撃検知ノード３の状態を管理する。クライアント５は、例えばISP毎のネットワークに所属している。クライアント５がサーバ１の仮想IPアドレス宛てに送信したパケットは、ルーティングプロトコルに従って、クライアント５とネットワークとの接続点の位置に応じた攻撃検知ノード３に転送される。
サーバ１と攻撃検知ノード３との間ではVPN（Virtual Private Network）接続が確立される。これにより、サーバ１はネットワーク上の仮想的なセグメント（仮想セグメント）に収容される。サーバ１と攻撃検知ノード３との関係は１対１である、すなわちサーバ１は１つの攻撃検知ノード３のみとVPN接続を確立するため、特定のサーバ１宛てのパケットは、このサーバ１とVPN接続を確立している１つの攻撃検知ノード３を必ず経由する。サーバ１が全ての攻撃検知ノード３とVPN接続を確立する手法を用いてもよいが、上記のようにサーバ１が１つの攻撃検知ノード３のみとVPN接続を確立することによって、VPN接続を確立する処理負荷およびVPN接続の管理負荷が低減される。
サーバ１は、攻撃検知ノード３とVPN接続を確立する場合、特定の１つの攻撃検知ノード３に対してVPN接続の要求を行う。このVPN接続の要求と確立はサーバ１と攻撃検知ノード３との間で自律的に行われるため、１つの管理端末が全ての攻撃検知ノード３の状態を管理し、サーバ１からVPN接続の要求を受けて攻撃検知ノード３の情報を応答するような中央集権的な仕組みを必要としない。
攻撃防御ノード２と攻撃検知ノード３は、分散ハッシュテーブル（DHT： Distributed Hash Table）を利用したDHTネットワークを構成する。これにより、サーバ１と攻撃検知ノード３との対応関係を管理する負荷が攻撃防御ノード２および攻撃検知ノード３間で分散される。
攻撃検知ノード３には、同一のサーバ１に対するパケットが複数の攻撃防御ノード２から到来しうる。攻撃検知ノード３が、どの攻撃防御ノード２からのパケットであるのかを区別してサーバ１へのパケット量を監視し、攻撃を検知することで、攻撃パケットがどの攻撃防御ノード２から到来するのかを知ることができる。攻撃が検知された場合、複数の攻撃防御ノード２のうち攻撃パケットを中継した攻撃防御ノード２において、攻撃対象となったサーバ１の仮想IPアドレス宛てのパケットを削除するパケットフィルタリングを実施することで、サーバ１を攻撃から防御することができる。パケットフィルタリングを実施している攻撃防御ノード２以外の攻撃防御ノード２から到来するパケットは攻撃パケットではないとみなされ、サーバ１へ転送される。
本実施形態では、クライアント５からサーバ１の仮想IPアドレス宛てに送信されるパケットは、攻撃防御ノード２および攻撃検知ノード３をこの順に経由してサーバ１に到達する。分散DoS攻撃のように、個々の攻撃クライアントが送信するパケットは少量であるが多数の攻撃クライアントからのパケットが特定のサーバに集中する攻撃を検知するには、攻撃対象となるサーバの近傍で攻撃の検知を行うことが望ましい。本実施形態では、パケットの転送経路上でよりサーバ１に近い攻撃検知ノード３が攻撃の検知を行うことによって、より的確に攻撃を検知することが可能となる。さらに、サーバ１と攻撃検知ノード３との関係が１対１であるため、攻撃検知ノード３が各サーバ１へのトラヒックを一元的に監視することになり、サーバ１に対する攻撃をより的確に検知することができる。
また、多数の攻撃クライアントからのパケットがネットワーク上で転送されるとネットワーク資源を浪費するので、攻撃クライアントの近傍でパケットフィルタリングを実施することが望ましい。本実施形態では、パケットの転送経路上でより攻撃元のクライアント５に近い攻撃防御ノード２がパケットのフィルタリングを行うことによって、攻撃元のクライアント５から送信されたパケットの転送によるネットワーク資源の消費をより抑えることが可能となる。
図２は、パケットの中継に関する本通信システムの機能構成を示している。サーバ１は、サーバアプリケーション１０と、サーバ公開部１１とを有する。サーバアプリケーション１０は、クライアント５からの要求に応じてサービスを提供する。サーバ公開部１１は、サーバ１を収容する仮想セグメントを構築するためのサーバ公開に係る処理を行う。
攻撃防御ノード２は、中継部２０と、DHT管理部２１と、DHT記憶部２２と、広告部２３とを有する。中継部２０は、クライアント５から送信されたパケットを攻撃検知ノード３に中継する。DHT管理部２１は、DHTネットワークに参加するための処理を行い、DHT記憶部２２に記憶される情報を管理する。DHT記憶部２２は、サーバ１とVPN接続を確立している攻撃検知ノード３のIPアドレスとサーバ１の仮想IPアドレスとの対応関係を示す情報を記憶する。より具体的には、DHT記憶部２２は、サーバ１とVPN接続を確立している攻撃検知ノード３のIPアドレスと、サーバ１の仮想IPアドレスからSHA1（Secure Hash Algorithm 1）を用いて算出したハッシュ値とを関連付けて記憶する。DHTネットワークでは、この対応関係を示す情報は、サーバ１とVPN接続を確立している攻撃検知ノード３で管理されるとは限らず、DHTネットワークを構成する攻撃防御ノード２と攻撃検知ノード３のいずれかにおいて管理される。
広告部２３は、サーバ１の仮想IPアドレス宛てのパケットが攻撃防御ノード２に届くように、ルーティングプロトコルの一種であるOSPF（Open Shortest Path First）やBGP（Border Gateway Protocol）に従って、仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。クライアント５がサーバ１の仮想IPアドレス宛てのパケットを送信すると、この経路情報に従ってネットワーク上のルータが転送を行うことにより、クライアント５に最も近い攻撃防御ノード２にパケットが到着する。つまり、クライアント５が送信したパケットは、クライアント５とネットワークとの接続点の位置に応じた攻撃防御ノード２に到着する。
攻撃検知ノード３は、中継部３０と、サーバ公開部３１と、DHT管理部３２と、DHT記憶部３３と、広告部３４とを有する。中継部３０は、攻撃防御ノード２から送信されたパケットをサーバ１に中継する。サーバ公開部３１は、サーバ１を収容する仮想セグメントを構築するためのサーバ公開に係る処理を行う。DHT管理部３２は、DHTネットワークに参加するための処理を行い、DHT記憶部３３に記憶される情報を管理する。DHT記憶部３３はDHT記憶部２２と同様に、サーバ１とVPN接続を確立している攻撃検知ノード３のIPアドレスと、サーバ１の仮想IPアドレスからSHA1を用いて算出したハッシュ値とを関連付けて記憶する。
広告部３４は、OSPFに従って、エニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する。サーバ１が、サーバ公開に係るVPN接続を行う際にエニーキャストアドレス宛てに攻撃検知ノード３の検索要求を行うと、サーバ１に最も近い攻撃検知ノード３から応答が返される。サーバ記憶部３５は、サーバ１の仮想IPアドレスと実IPアドレスとを関連付けて記憶する。
管理ノード４は、仮想IPアドレス記憶部４０と、アドレス管理部４１と、設定情報記憶部４２と、ノード管理部４３と、ノードリスト記憶部４４とを有する。仮想IPアドレス記憶部４０は、サーバ１に割り当てられる仮想IPアドレスを記憶する。アドレス管理部４１は、サーバ１に対する仮想IPアドレスの割り当てを管理する。設定情報記憶部４２は、攻撃防御ノード２に通知する仮想IPアドレスの範囲や、攻撃検知ノード３に通知するエニーキャストアドレスの範囲等を含む設定情報を記憶する。各攻撃防御ノード２には共通の仮想IPアドレス範囲が通知される。また、各攻撃検知ノード３には共通のエニーキャストアドレス範囲が通知される。ノード管理部４３は、DHTネットワークを構成する攻撃防御ノード２および攻撃検知ノード３の情報を管理する。ノードリスト記憶部４４は、DHTネットワークを構成する攻撃防御ノード２および攻撃検知ノード３の一覧であるノードリストを記憶する。
クライアント５はクライアントアプリケーション５０を有する。クライアントアプリケーション５０はサーバ１に対してサービスの要求を行う。
次に、攻撃防御ノード２と攻撃検知ノード３によるDHTネットワークの構築と管理について説明する。DHTネットワークにおいては、ネットワークを構成するノードの加入と離脱が生じる。ノードが加入する場合、既にDHTネットワークを構成しているいずれかのノードに対して加入処理を行うことで、DHTネットワークへの加入を行う。一方、DHTネットワークからノードが離脱する場合、ルーティングテーブルの再構築が行われ、残りのノードにより通信が継続される。このとき、離脱したノードが所持していた情報はDHTネットワーク上で隣接するノードが同期を取るなどして保持される。なお、最初にDHTネットワークを構成するノードが起動する場合は、加入処理を行う対象のノードが存在しないため、初期ノード起動処理が行われる。以下、DHTネットワークを構築するアルゴリズムの一種であるChordを実装したプログラムを例に、それぞれの具体的な手法を説明する。
図３は、DHTネットワークを構成する最初のノードである初期ノード（攻撃防御ノード２または攻撃検知ノード３）が加入する場合のシーケンスを示している。初期ノードにおいて、DHT管理部２１（３２）は、ノードリストの取得要求を示すノードリスト要求を管理ノード４へ送信する（ステップＳ１００）。なお、管理ノード４のIPアドレスは既知であるものとする。管理ノード４においてノード管理部４３はノードリスト要求を受信し、ノードリスト記憶部４４内のノードリストにノードのIPアドレスが登録されているか否かを判定する（ステップＳ１１０）。
最初のノードが加入する場合、ノードリストにノードのIPアドレスが登録されていないため、管理ノード４は初期ノード起動処理が必要であると判定し、初期ノード起動処理の要求を示す初期ノード起動要求を、ノードリスト要求の送信元であるノードへ送信する（ステップＳ１２０）。初期ノード起動要求には、設定情報記憶部４２内の設定情報に基づく仮想IPアドレスの範囲とエニーキャストアドレスの範囲が含まれる。
初期ノードにおいて、DHT管理部２１（３２）は、初期ノード起動要求を受信し、初期ノード起動処理を実行する（ステップＳ１３０）。具体的には、次に示すようなブートストラップノードの起動コマンドを実行する。
start-dhash --root dhash-a -j sure.lcs.mit.edu:10000 -p 10000 &
初期ノード起動処理の実行により、DHT記憶部２２（３３）には分散ハッシュテーブルが作成される。前述したように、このテーブルの構成要素は、サーバ１とVPN接続を確立している攻撃検知ノード３のIPアドレスと、サーバ１の仮想IPアドレスからSHA1を用いて算出したハッシュ値とのペアである。初期ノード起動処理が完了した時点では、テーブルにはこれらの情報は格納されていない。また、初期ノード起動処理が完了した時点では、DHTネットワークの全てのノード（１個）の情報を初期ノードが単体で管理している状態となる。
初期ノード起動処理の実行後、DHT管理部２１（３２）は、初期ノードがDHTネットワークに加入したことを示すノード加入通知を管理ノード４へ送信することにより自身のIPアドレスを通知する（ステップＳ１４０）。管理ノード４においてノード管理部４３はノード加入通知を受信し、ノード加入通知により通知されたIPアドレスをノードリスト記憶部４４内のノードリストに追加する（ステップＳ１５０）。
初期ノードが攻撃防御ノード２である場合、初期ノード起動処理の実行後、攻撃防御ノード２の広告部２３は、初期ノード起動要求によって通知された範囲の仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。また、初期ノードが攻撃検知ノード３である場合、初期ノード起動処理の実行後、攻撃検知ノード３の広告部３４は、初期ノード起動要求によって通知された範囲のエニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する（ステップＳ１６０）。
なお、管理ノード４が初期ノードからノードリスト要求を受信してからノード加入通知を受信するまでの間に他のノードからノードリスト要求を受信した場合、ノードリスト要求の再送を示すメッセージが他のノードへ送信される。このため、初期ノードによるDHTネットワークが構築されるまで、他のノードからのノードリスト要求に対する処理は実行されない。
図４は、１以上のノードによりDHTネットワークが構成されている場合に新たなノード（攻撃防御ノード２または攻撃検知ノード３）が加入する場合のシーケンスを示している。新たに加入するノードにおいて、DHT管理部２１（３２）は、ノードリストの取得要求を示すノードリスト要求を管理ノード４へ送信する（ステップＳ２００）。なお、管理ノード４のIPアドレスは既知であるものとする。管理ノード４においてノード管理部４３はノードリスト要求を受信し、ノードリスト記憶部４４内のノードリストにノードのIPアドレスが登録されているか否かを判定する（ステップＳ２１０）。
既に他のノードが加入している場合、ノードリストにノードのIPアドレスが登録されているため、管理ノード４は、ノードリスト要求の送信元であるノードへノードリストを送信する（ステップＳ２２０）。このとき、設定情報記憶部４２内の設定情報に基づく仮想IPアドレスの範囲とエニーキャストアドレスの範囲がノードリストに付加される。新たに加入するノードにおいて、DHT管理部２１（３２）は、ノードリストを受信し、ノードリストに記載されているノードを対象としてノード加入処理を実行する（ステップＳ２３０）。具体的には、次に示すような既存ノードへの加入のコマンドを実行する。
start-dhash --root dhash-b -j sure.lcs.mit.edu:10000 &
ノード加入処理の実行により、DHT記憶部２２（３３）には分散ハッシュテーブルが作成される。ノード加入処理では、ノードリストに記載されたIPアドレスを有するノードと通信が行われ、DHTネットワークに加入するための設定が行われる。
ノード加入処理の実行後、DHT管理部２１（３２）は、新たにノードがDHTネットワークに加入したことを示すノード加入通知を管理ノード４へ送信することにより自身のIPアドレスを通知する（ステップＳ２４０）。管理ノード４においてノード管理部４３はノード加入通知を受信し、ノード加入通知により通知されたIPアドレスをノードリスト記憶部４４内のノードリストに追加する（ステップＳ２５０）。
新たに加入するノードが攻撃防御ノード２である場合、ノード加入処理の実行後、攻撃防御ノード２の広告部２３は、管理ノード４から通知された範囲の仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。また、新たに加入するノードが攻撃検知ノード３である場合、ノード加入処理の実行後、攻撃検知ノード３の広告部３４は、管理ノード４から通知された範囲のエニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する（ステップＳ２６０）。
以下、ステップＳ２３０において、DHTネットワークに加入する処理の詳細を説明する。DHTは、管理対象の情報のハッシュ値（以下、Keyとする）と、管理対象の情報（以下、Valueとする）とのペアを格納する分散ハッシュテーブルを複数のノードに分散させることによって、情報を効率的に管理する手法である。本実施形態では、サーバ１の仮想IPアドレスがKeyに該当し、攻撃検知ノード３のIPアドレスがValueに該当する。本実施形態では、DHTネットワークを構成する攻撃防御ノード２および攻撃検知ノード３が、自身のIPアドレスに基づいて、管理対象となる攻撃検知ノード３のIPアドレス（Value）を管理する。
本実施形態でDHTネットワークの実装アルゴリズムの一例として用いるChordでは、DHTネットワークを構成するノードが各ノードのIDに従って配置される。各ノードに割り当てられるIDは、具体的にはノード毎のIPアドレスからSHA-1を用いて算出したハッシュ値である。Chordでは２１６０のハッシュ空間が用いられ、各ノードは円周上の点として定義される。図１４は、簡単のためハッシュ空間を２４とした場合のIDの割り当てを示している。０から１５までの各IDを有するノードが配置されている。
Chordでは、DHTネットワークを構成する各ノードが、自身のノードIDから隣接するノードIDまでの間に位置するIDに対応するValueを管理する。図１４において、ノードIDが０、２、６、９、１１、１３、１４のノードがDHTネットワークに加入している場合、ノードIDが０のノード０は、ノードIDが１５と０に対応するKeyとValueのペアを管理する。
Chordでは、各ノードはSuccessor、Predecessor、Fingertableと呼ばれる３種類のルーティングテーブルを保持する。これらのルーティングテーブルは、各ノードがDHT記憶部２２（３３）の分散ハッシュテーブルに保持するKeyとValueのペア（サーバ１の仮想IPアドレスと転送ノードのIPアドレスのペア）とは異なる。各ルーティングテーブルはDHT記憶部２２（３３）に保持されるものとする。
Successorは、ノードIDが大きくなる方向に見て最近傍に位置するノードのIPアドレスを保持するルーティングテーブルであり、Predecessorは、ノードIDが小さくなる方向に見て最近傍に位置するノードのIPアドレスを保持するルーティングテーブルである。Fingertableは、2mのハッシュ空間において、以下の式に一致するIPアドレスを保持するルーティングテーブルである。
ノードのIPアドレス＝IPadress[next(Z)]、ただし、Z=(Node_ID+2i) mod2m、i=0〜m
上記の式のnext(Z)は、ハッシュ空間上でZから右回り（つまりノードIDが大きくなる方向）に見て次に存在するノードのIDを返す関数である。IPadress[X]はIDがXのノードのIPアドレスを返す関数である。
DHTネットワークに新たなノードが加入することは、円周上のノードが存在していない点の位置にノードが加わることを意味する。以下では、ID12のノード（ノード１２）とID18のノード（ノード１８）が存在しているDHTネットワークにID15のノード（ノード１５）が加入する場合を例として加入の手順を説明する。
ノード１５は、自身のIPアドレスからハッシュ値であるIDを算出する。続いて、ノード１５は、ノードリストに記載されているノードに対して、自身のIDを保持の対象としているノードのIPアドレスを要求する。要求を受けたノードは、ノード１５のIDを保持していれば応答し、保持していなければ他のノードに要求を行う。この結果、ノード１５はノード１８のIPアドレスを取得する。
続いて、ノード１５はノード１８にjoinメッセージを送信し、Successorにノード１８のIPアドレスを記録する。さらに、ノード１５はノード１８から、Predecessorに保持すべきノード１２のIPアドレスを通知され、Predecessorにノード１２のIPアドレスを記録する。
続いて、ノード１５は、それまでノード１８がFingertableに保持していたIPアドレスのうち、ノード１５が管理すべき部分に該当するIPアドレスをノード１８から受信し、Fingertableに記録する。また、ノード１５は、それまでノード１８がDHT記憶部２２（３３）の分散ハッシュテーブルに保持していたKeyとValueのペアのうち、ノード１５が管理すべき部分に該当するKeyとValueのペアをノード１８から受信し、DHT記憶部２２（３３）に記録する。ノード１５は、ノード１２に自身の加入を通知し、ノード１２は、ノード１５からの通知に基づいて、自身が保持しているSuccessorに記録されていたノード１８のIPアドレスをノード１５のIPアドレスに変更する。
図５は、DHTネットワークに加入しているノード（攻撃防御ノード２または攻撃検知ノード３）がDHTネットワークから脱退する場合のシーケンスを示している。DHTネットワークから脱退するノードにおいて、DHT管理部２１（３２）はノード脱退処理を実行する（ステップＳ３００）。続いて、DHT管理部２１（３２）は、DHTネットワークからの脱退を示すノード脱退通知を管理ノード４へ送信することにより自身のIPアドレスを通知する（ステップＳ３１０）。管理ノード４においてノード管理部４３はノード脱退通知を受信し、ノード脱退通知により通知されたIPアドレスをノードリスト記憶部４４内のノードリストから削除する（ステップＳ３２０）。
上記のようにしてノードが脱退した場合、ハッシュ空間上でこのノードに隣接するノードにおいて、Successor、Predecessor、Fingertableがそれぞれ更新される。このとき、脱退したノードが保持していた情報を引き継ぐための処理として、DHTでは近傍のノードに自身が保持するデータのコピーを配置するなどして情報の欠損を防いでいる。
次に、サーバ１を収容する仮想セグメントを構築するためのサーバ公開について説明する。サーバ１は予め管理ノード４から仮想IPアドレスを取得する。管理ノード４においてアドレス管理部４１は予め仮想IPアドレスを生成し、仮想IPアドレス記憶部４０に保存する。サーバ１のサーバ公開部１１は管理ノード４にアクセスし、仮想IPアドレスの割り当てに必要な情報の登録を行う。管理ノード４のアドレス管理部４１は、仮想IPアドレス記憶部４０から仮想IPアドレスを選択し、仮想IPアドレスをサーバ１に通知する。複数のサーバ１に対して同一の仮想IPアドレスが割り当てられないよう、アドレス管理部４１は仮想IPアドレスの割り当てを管理する。サーバ１に対する仮想IPアドレスの通知は公開鍵証明書の発行により行われるが、詳細な説明を省略する。この公開鍵証明書はサーバ１が攻撃検知ノード３にアクセスする際に使用されるが、本実施形態では、公開鍵証明書による公知の通信方法に係る説明を省略する。
図６は、仮想IPアドレスを取得したサーバ１の公開開始時のシーケンスを示している。サーバ１は、攻撃検知ノード３が使用するエニーキャストアドレスを予め知っているものとする。サーバ１のサーバ公開部１１は、エニーキャストアドレス宛てに攻撃検知ノード３の接続要求を送信する（ステップＳ４００）。この接続要求はサーバ１に最も近い攻撃検知ノード３に到着する。攻撃検知ノード３のサーバ公開部３１はサーバ１からの接続要求を受信し、自身のIPアドレスを通知する応答をサーバ１へ送信する（ステップＳ４１０）。
サーバ１のサーバ公開部１１は攻撃検知ノード３からの応答を受信し、その応答によって通知されたIPアドレス宛てに、VPN接続の要求を示すVPN接続要求を送信する（ステップＳ４２０）。このVPN接続要求によって、サーバ１の仮想IPアドレスおよび実IPアドレスが攻撃検知ノード３に通知される。この後、サーバ１と攻撃検知ノード３の双方においてVPN接続のための各種設定が行われるが、詳細な説明を省略する。
攻撃検知ノード３のサーバ公開部３１は、サーバ１から通知された仮想IPアドレスをDHT管理部３２に通知する。DHT管理部３２は仮想IPアドレスのハッシュ値を算出し、攻撃検知ノード３のIPアドレスとハッシュ値とを、DHTネットワークを構成する攻撃防御ノード２または攻撃検知ノード３のDHT記憶部２２（３３）内の分散ハッシュテーブルに登録する処理を行う（ステップＳ４３０）。具体的には、以下のような“put”コマンドを実行する。なお、(a)はハッシュ値を示し、(b)は攻撃検知ノードのIPアドレスを示す。
put <(a)> <(b)>
また、DHT管理部３２は、サーバ１の仮想IPアドレスと実IPアドレスとを組にしてサーバ記憶部３５に登録する（ステップＳ４４０）。
以下、ステップＳ４３０において攻撃検知ノード３のIPアドレスとサーバ１の仮想IPアドレスのハッシュ値のペアを分散ハッシュテーブルに登録する処理の詳細を説明する。DHT管理部３２は、サーバ１の仮想IPアドレスのハッシュ値をKeyとして管理すべきノードを検索する処理を行う。図１４に示すDHTネットワークにおいて、ノード０が検索を行う例を示す。サーバ１の仮想IPアドレスのハッシュ値が１２であるとすると、DHT管理部３２は、前述したnext関数によりnext(12)=13であるため、目的の情報を管理すべきノードがノード１３であることを求める。これに基づき、DHT管理部３２は、攻撃検知ノード３のIPアドレスとサーバ１の仮想IPアドレスのハッシュ値のペアを含み、ノード１３の検索を依頼するメッセージを生成し、中継部３０に渡す。
前述したFingertableの定義より、ノード０のFingertableに保持されるノードIDは、2(i=0,1[z=1,2])、6（i=2[z=4]）、9(i=3[z=8])となる。ノード１３のノードIDである13に関して、23<13<24であることから、ノード０は、i=3[z=8]のときのノードIDに対応するノード９にノード１３の検索を依頼する。すなわち、中継部３０はノード９宛てに上記のメッセージを送信する。
ノード９のFingertableに保持されるノードIDは、11(i=0,1[z=10,11])、13(i=2[z=13])、2(i=3[z=1])であることから、ノード９はノード１３の情報を保持している。したがって、ノード９からノード１３に、ノード０からのメッセージが転送される。ノード１３において中継部２０（３０）はメッセージを受信し、DHT管理部２１（３２）に渡す。DHT管理部２１は、メッセージに含まれる攻撃検知ノード３のIPアドレスとサーバ１の仮想IPアドレスのハッシュ値をDHT記憶部２２（３３）に設定する。
このように、DHTネットワークでは、はじめに大まかな検索を行い、検索対象に近づくに従って、徐々に細かい検索を行うことで、DHTネットワークを構成しているノードから隣接するノードを順番に辿る場合よりも効率的な検索を実現している。上記のようにして、攻撃検知ノード３のIPアドレスとサーバ１の仮想IPアドレスのハッシュ値のペアが、DHTネットワークを構成する攻撃防御ノード２または攻撃検知ノード３によって管理されるようになる。
図７は、サーバ１の公開停止時のシーケンスを示している。攻撃検知ノード３のサーバ公開部３１は、サーバ１からの明示的なVPN接続の解除通知あるいは障害等によるVPN接続の解除を検知することにより、VPN接続が切断されたことを検知し、DHT管理部３２に通知する（ステップＳ５００）。
DHT管理部３２は、サーバ公開部３１から通知を受けると、切断されたVPN接続の接続相手であるサーバ１の仮想IPアドレスと自身のIPアドレスのペアを分散ハッシュテーブルから削除するため、VPN接続を解除したサーバ１の仮想IPアドレスのハッシュ値をKeyとして管理しているノードを検索する処理を行う（ステップＳ５１０）。このとき、ステップＳ４３０の処理と同様にして検索が行われ、所望のノードにメッセージが転送される。メッセージを受信したノードにおいてDHT管理部２１（３３）は、メッセージに含まれるハッシュ値と一致するハッシュ値およびそれと関連付けられている攻撃検知ノード３のIPアドレスを分散ハッシュテーブルから削除する。
次に、サーバ１とクライアント５との通信について説明する。図８は、クライアント５がサーバ１と通信を行う際のシーケンスを示している。クライアント５は、例えばDNSサーバにサーバ１の名前解決を依頼し、その結果としてDNSサーバからサーバ１のIPアドレスを通知されることにより、サーバ１の仮想IPアドレス（IP_virtual）を取得することが可能である。クライアント５のクライアントアプリケーション５０は、クライアント５（IP_client）を送信元とし、サーバ１（IP_virtual）を宛先とするパケットを送信する（ステップＳ６００）。攻撃防御ノード２がIP_virtual宛ての経路を広告していることにより、クライアント５から送信されたパケットはクライアント５に最も近い攻撃防御ノード２に到着する。
攻撃防御ノード２の中継部２０は、クライアント５からのパケットを受信し、受信したパケットに含まれるサーバ１の仮想IPアドレス（IP_virtual）をDHT管理部２１に通知する。DHT管理部２１は、この仮想IPアドレス（IP_virtual）のハッシュ値を算出し、このハッシュ値をKeyとして管理しているノードを検索する処理を行う（ステップＳ６１０）。
このとき、ステップＳ４３０の処理と同様にして検索が行われ、所望のノードにメッセージが転送される。メッセージを受信したノードにおいてDHT管理部２１（３３）は、メッセージに含まれるハッシュ値と一致するハッシュ値を分散ハッシュテーブルから検索し、一致したハッシュ値と関連付けられている攻撃検知ノード３のIPアドレスを取得する。DHT管理部２１（３３）は、取得したIPアドレスを通知するための応答メッセージを生成し、中継部２０（３０）に渡す。中継部２０（３０）は、検索を要求した攻撃防御ノード２へ応答メッセージを送信する。検索を要求した攻撃防御ノード２において中継部２０はこの応答メッセージを受信し、所望の攻撃検知ノード３のIPアドレスを取得する。
中継部２０は、クライアント５から受信したパケットをカプセル化する（ステップＳ６２０）。このカプセル化では、クライアント５からのパケットに対してIPヘッダが付加される。このIPヘッダには、送信元のIPアドレスとして攻撃防御ノード２のIPアドレス（Rc）が記録され、宛先のIPアドレスとして攻撃検知ノード３のIPアドレス（Rs）が記録されている。したがって、クライアント５（IP_client）を送信元としサーバ１（IP_virtual）を宛先とするパケットが、カプセル化によって、攻撃防御ノード２（Rc）を送信元とし攻撃検知ノード３（Rs）を宛先とするパケットに変換される。中継部２０は、カプセル化したパケットを攻撃検知ノード３へ送信する（ステップＳ６３０）。
攻撃検知ノード３の中継部３０は、攻撃防御ノード２からのパケットを受信し、カプセル解除する（ステップＳ６４０）。このカプセル解除では、攻撃防御ノード２でパケットに付加されたIPヘッダが除去される。したがって、攻撃防御ノード２（Rc）を送信元とし攻撃検知ノード３（Rs）を宛先とするパケットが、カプセル解除によって、クライアント５（IP_client）を送信元としサーバ１（IP_virtual）を宛先とするパケットに変換される。
続いて、中継部３０は、パケットに含まれるサーバ１の仮想IPアドレス（IP_virtual）をキーにしてサーバ記憶部３５内の情報を検索し、サーバ１の仮想IPアドレス（IP_virtual）に対応する実IPアドレス（IP_real）を取得する（ステップＳ６５０）。さらに、中継部３０は、ステップＳ６４０でカプセル解除したパケットをカプセル化する（ステップＳ６６０）。このカプセル化では、送信元のIPアドレスとして攻撃検知ノード３のIPアドレス（Rs）が記録され、宛先のIPアドレスとしてサーバ１の実IPアドレス（IP_real）が記録されたIPヘッダが付加される。したがって、カプセル解除されたパケットが、カプセル化によって、攻撃検知ノード３（Rs）を送信元としサーバ１（IP_real）を宛先とするパケットに変換される。中継部３０は、カプセル化したパケットをサーバ１へ送信する（ステップＳ６７０）。
サーバ１のサーバアプリケーション１０は攻撃検知ノード３からのパケットを受信し、適宜処理する（ステップＳ６８０）。なお、受信されたパケットは、ミドルウェアによってカプセル解除される（図示せず）。サーバアプリケーション１０は、クライアント５への応答パケットを攻撃検知ノード３へ送信する（ステップＳ６９０）。この応答パケットは、サーバ１（IP_virtual）を送信元としクライアント５（IP_client）を宛先とするパケットに対して、カプセル化により、サーバ１（IP_virtual）を送信元とし攻撃検知ノード３（Rs）を宛先とするIPヘッダが付加されたものである。
攻撃検知ノード３の中継部３０はサーバ１からのパケットを受信し、カプセル解除する（ステップＳ７００）。このカプセル解除によって、サーバ１からのパケットは、サーバ１（IP_virtual）を送信元としクライアント５（IP_client）を宛先とするパケットに変換される。中継部３０は、カプセル解除したパケットをクライアント５へ送信する（ステップＳ７１０）。
上述したように、サーバ１は１つの攻撃検知ノード３のみとVPN接続を確立するため、サーバが全ての中継端末とVPN接続を確立する手法を用いる場合よりもVPN接続を確立する処理負荷およびVPN接続の管理負荷を低減することができる。また、VPN接続の要求と確立がサーバ１と攻撃検知ノード３との間で自律的に行われるため、１つの管理端末が全ての攻撃検知ノード３の状態を管理し、サーバ１からVPN接続の要求を受けて攻撃検知ノード３の情報を応答するような中央集権的な仕組みを必要としない。
また、攻撃防御ノード２と攻撃検知ノード３が、分散ハッシュテーブルを利用したDHTネットワークを構成することによって、サーバ１と攻撃検知ノード３との対応関係を管理する負荷を攻撃防御ノード２と攻撃検知ノード３間で分散することができる。
次に、本実施形態におけるサーバ１に対する攻撃の検知と防御について説明する。サーバ１宛てのパケットは、そのサーバ１を収容する仮想セグメントを構成する攻撃検知ノード３によってサーバ１へ転送されるので、攻撃検知ノード３においてサーバ１へのトラヒックを把握することが可能となる。図９は、攻撃の検知と防御に関する攻撃防御ノード２と攻撃検知ノード３の機能構成を示している。
攻撃防御ノード２は、前述した中継部２０を有する。中継部２０は、パケットの送信および受信を行う送受信部２０ａと、攻撃検知ノード３から通知されるフィルタリングルールを中継部２０に設定するフィルタリング設定部２０ｂと、攻撃検知ノード３から通知されるフィルタリングルールに従ってパケットを削除するフィルタリング部２０ｃとを有する。
攻撃検知ノード３は、前述した中継部３０と、ログ記憶部３６と、攻撃検知部３７と、ルール決定部３８とを有する。中継部３０は、パケットの送信および受信を行う送受信部３０ａと、サーバ１に中継したパケットの情報をログに記録するログ記録部３０ｂとを有する。ログ記憶部３６は、中継部３０がサーバ１に中継したパケットの情報を含むログを記憶する。攻撃検知部３７は、ログ記憶部３６に記憶されているログに基づいて攻撃を検知する。ルール決定部３８は、攻撃検知部３７によって攻撃が検知された場合に、その攻撃の防御を行うためのフィルタリングルールを決定する。
図１０は、サーバ１に対する攻撃の検知と防御時のシーケンスを示している。攻撃検知ノード３においてログ記録部３０ｂは、送受信部３０ａが攻撃防御ノード２からのパケットをサーバ１に中継した際に、そのパケットからIPアドレス等の情報を取得し、ログ記憶部３６内のログに追加する。図１１は、１パケット分のログの構造を示している。攻撃防御ノード２でカプセル化されたパケットに付加されているIPヘッダの情報と、カプセル解除したパケットのIPヘッダから、パケットを送信したクライアント５のIPアドレス、パケットの宛先であるサーバ１の仮想IPアドレス、パケットを中継した攻撃防御ノード２のIPアドレスを取得することができる。これらと攻撃検知ノード３のIPアドレスおよびパケットの受信時刻がログに記録される。
攻撃検知部３７はログ記憶部３６内のログに基づいて、攻撃防御ノード２からサーバ１へのトラヒックに関して、攻撃が発生したか否かの判定を行う（ステップＳ８００）。攻撃検知部３７によって攻撃が発生したと判定された場合、すなわち攻撃が検知された場合、ルール決定部３８はフィルタリングルールを決定すると共に、フィルタリングを行う攻撃防御ノード２を決定する。ルール決定部３８は、決定したフィルタリングルールを通知するルール情報を生成し、フィルタリングを行う攻撃防御ノード２を指定する情報と共にルール情報を中継部３０に通知する（ステップＳ８１０）。
中継部３０の送受信部３０ａは、ルール決定部３８によって指定された攻撃防御ノード２へルール情報を送信する（ステップＳ８２０）。攻撃防御ノード２において、送受信部２０ａは攻撃検知ノード３からのルール情報を受信する。フィルタリング設定部２０ｂは、ルール情報が示すフィルタリングルールに従って、特定の条件を満たすパケットを削除するようにフィルタリング部２０ｃにフィルタリングの設定を行う（ステップＳ８２０）。これ以降、フィルタリング部２０ｃは、設定された条件に従って、クライアント５から受信したパケットを削除する。送受信部２０ａは、削除されたパケットを送信しない。
次に、ステップＳ８００において攻撃を判定する処理の詳細を説明する。図１２は、ステップＳ８００における処理の詳細を示している。まず、攻撃検知部３７は、ログ記憶部３６内のログに記録されているサーバ１の仮想IPアドレスの数と同数のカウンタを各サーバ１の仮想IPアドレスと関連付け、各カウンタのカウント値が０となるように各カウンタをリセットする（ステップＳ９００）。このカウンタのカウント値は各サーバ１へのトラヒック量を示す。以下の説明では、説明を単純化するため、パケット数をトラヒック量とするが、パケットのデータ量（バイト数）等をトラヒック量としてもよい。
続いて、攻撃検知部３７は、ログ記憶部３６内のログに新たにパケットの情報が追加されたか否かを判定することにより、攻撃検知ノード３で新たにパケットが受信されたか否かを判定する（ステップＳ９０５）。ログ記憶部３６内のログに新たにパケットの情報が追加されていない場合、すなわち攻撃検知ノード３で新たにパケットが受信されていない場合、処理はステップＳ９１５に進む。
また、ログ記憶部３６内のログに新たにパケットの情報が追加された場合、すなわち攻撃検知ノード３で新たにパケットが受信された場合、攻撃検知部３７は、ログにおいて新たに追加されたパケットの情報からサーバ１の仮想IPアドレスを抽出し、その仮想IPアドレスと関連付けられているカウンタのカウント値を１増加させる（ステップＳ９１０）。このカウンタのカウント値はサーバ１宛てのパケットの数を示す。
続いて、攻撃検知部３７は、ステップＳ９００でカウンタをリセットしてから所定時間（例えば１秒）が経過したか否かを判定する（ステップＳ９１５）。所定時間が経過していない場合、処理はステップＳ９０５に戻る。また、所定時間が経過した場合、攻撃検知部３７は、サーバ１毎のカウンタのカウント値が所定値を超えているか否かを判定する（ステップＳ９２０）。この所定値は、サーバ１の能力に応じた値であり、サーバ１毎に異なる値であってもよい。
１以上のサーバ１のカウンタのカウント値が所定値を超えている場合、攻撃検知部３７は、攻撃が発生したと判断し、攻撃が発生しているサーバ１の仮想IPアドレスをルール決定部３８に通知する（ステップＳ９２５）。また、全てのサーバ１のカウンタのカウント値が所定値以下である場合、攻撃検知部３７は、攻撃が発生していないと判断する（ステップＳ９３０）。この場合、ルール決定部３８にサーバ１の仮想IPアドレスは通知されない。攻撃が発生したと判断された場合、攻撃が発生していないと判断された場合のいずれであっても、処理はステップＳ９００に戻る。上記の処理により、サーバ１への単位時間当たりのトラヒック量（この例ではパケット数に相当）が所定値を超えると攻撃が検知される。上記の処理は一例であり、攻撃を検知できる何らかの処理であればよい。
次に、ステップＳ８１０においてフィルタリングルールを決定し、ステップＳ８２０においてフィルタリングルールを通知する処理の詳細を説明する。図１３は、ステップＳ８１０，Ｓ８２０における処理の詳細を示している。図１２のステップＳ９２５において攻撃が発生したと判断された場合、図１３に示す処理が行われる。
図１３に示す処理の概要を説明する。各攻撃防御ノード２で個別に攻撃者のクライアント５のIPアドレスをフィルタリング対象（棄却対象）に指定するフィルタリングが攻撃の防御に有効な場合には、そのようなフィルタリングルールが生成される。一方で、攻撃防御ノード２でフィルタリング対象（棄却対象）として個別に指定可能なIPアドレスの数には限界があるため、攻撃者のクライアント５の数が多く、上記のフィルタリングが有効でない場合には、攻撃者のクライアント５からのパケットを中継する攻撃防御ノード２で全てのパケットをフィルタリング対象（棄却対象）に指定するフィルタリングルールが生成される。
以下、処理の詳細を説明する。まず、ルール決定部３８は、ログ記憶部３６内のログに記録されている、攻撃検知ノード３で受信された各パケットの情報のうち、パケットの宛先として記録されているIPアドレスが、攻撃の検知されたサーバ１の仮想IPアドレス（攻撃検知部３７から通知された仮想IPアドレス）と一致する情報を抽出する（ステップＳ１０００）。続いて、ルール決定部３８は、ステップＳ１０００で抽出した情報に基づいて、送信元のクライアント５毎にパケット数を算出する（ステップＳ１００５）。
ステップＳ１００５で算出されたクライアント５毎のパケット数は、各クライアント５から攻撃検知ノード３に到達する通信のトラヒック量に対応する。ステップＳ１００５で区別されるクライアント５の数は通常２以上であるが、攻撃パケットの送信を行ったクライアント５が１台だけの場合も対応可能である。また、ステップＳ１００５で算出されたクライアント５毎のパケット数はクライアント５のIPアドレスと関連付けられて攻撃検知ノード３内のログ記憶部３６に保持される。
続いて、ルール決定部３８は、ステップＳ１００５で算出したクライアント５毎のパケット数を数の多い順（または数の少ない順）に並べたときの多い方から順に１番目からｍ（ｍ：自然数）番目までのパケット数の合計Ｔｃを算出する（ステップＳ１０１０）。さらに、ルール決定部３８は、ステップＳ１００５で算出したクライアント５毎のパケット数の全ての合計Ｔａを算出する（ステップＳ１０１５）。ステップＳ１０１５で算出した合計Ｔａは、各クライアント５から攻撃検知ノード３に到達する通信のトラヒック量の合計に対応する。
続いて、ルール決定部３８は、ステップＳ１０１５で算出した合計ＴａからステップＳ１０１０で算出した合計Ｔｃを減算した値Ｔａ−Ｔｃと所定の閾値Ｔｈとを比較し、値Ｔａ−Ｔｃが閾値Ｔｈを上回っているか否かを判定する（ステップＳ１０２０）。本実施形態の閾値Ｔｈは、各攻撃検知ノード３がフィルタリング対象（棄却対象）として個別に指定可能なIPアドレスの数と同じ数に設定される。本実施形態では、各攻撃検知ノード３がフィルタリング対象（棄却対象）として個別に指定可能なIPアドレスの数が攻撃検知ノード３間で等しい（すなわち各攻撃検知ノード３のフィルタリング能力が等しい）ことを想定しているが、この数が攻撃検知ノード３間で異なる場合には、例えば各攻撃検知ノード３が個別に指定可能なIPアドレスの数の中で最小の数を閾値Ｔｈに設定してもよい。
値Ｔａ−Ｔｃが閾値Ｔｈ以下である場合、ルール決定部３８は、クライアント５毎のパケット数を数の多い順（または数の少ない順）に並べたときの多い方から順に１番目からｍ（ｍ：自然数）番目までのパケット数に係るｍ台のクライアント５からのパケットを棄却するフィルタリングルールを示すルール情報を生成する（ステップＳ１０６５）。このルール情報には、ｍ台のクライアント５のIPアドレスが含まれる。また、ルール決定部３８は、ステップＳ１０００で抽出した情報のうち、パケットの送信元として記録されているIPアドレスが上記のｍ台のクライアントのいずれかのIPアドレスと一致する情報を選択し、その情報から、パケットを中継した攻撃防御ノード２のIPアドレスを抽出する（ステップＳ１０７０）。抽出されたIPアドレスを有する攻撃防御ノード２が、フィルタリングを行う攻撃防御ノード２となる。ルール決定部３８は、ステップＳ１０６５で生成したルール情報と、ステップＳ１０７０で抽出した攻撃防御ノード２のIPアドレスとを中継部３０へ出力する。
中継部３０の送受信部３０ａは、ルール決定部３８から出力されたIPアドレスを有する攻撃防御ノード２へ、ルール決定部３８から出力されたルール情報を送信する（ステップＳ１０７５）。このルール情報を受信した攻撃防御ノード２のフィルタリング設定部２０ｂは、ルール情報が示すクライアント５のIPアドレスを送信元とするパケットを削除するようにフィルタリング部２０ｃにフィルタリングの設定を行う。フィルタリング部２０ｃは、送受信部２０ａが受信したパケットの送信元であるクライアント５のIPアドレスが、設定されたIPアドレスと一致した場合に、受信したパケットを削除する。
また、ステップＳ１０２０において、値Ｔａ−Ｔｃが閾値Ｔｈを上回っている場合、ルール決定部３８は、ステップＳ１０００で抽出した情報に基づいて、パケットを中継した攻撃防御ノード２毎にパケット数を算出する（ステップＳ１０２５）。ステップＳ１０２５で算出した攻撃防御ノード２毎のパケット数は、クライアント５から各攻撃防御ノード２に到達する通信のトラヒック量に対応する。ステップＳ１０２５で区別される攻撃防御ノード２の数は通常２以上であるが、攻撃パケットの中継を行った攻撃防御ノード２が１台だけの場合も対応可能である。また、ステップＳ１０２５で算出された攻撃防御ノード２毎のパケット数は攻撃防御ノード２のIPアドレスと関連付けられて攻撃検知ノード３内のログ記憶部３６に保持される。
続いて、ルール決定部３８は、処理用の変数ｎを初期化（値に１を設定）する（ステップＳ１０３０）。さらに、ルール決定部３８は、ステップＳ１０２５で算出した攻撃防御ノード２毎のパケット数を数の多い順（または数の少ない順）に並べたときの多い方から順に１番目からｎ番目までのパケット数の合計Ｔｎを算出する（ステップＳ１０３５）。
続いて、ルール決定部３８は、ステップＳ１０１５で算出した合計ＴａからステップＳ１０３５で算出した合計Ｔｎを減算した値Ｔａ−Ｔｎと所定の閾値Ｔｈとを比較し、値Ｔａ−Ｔｎが閾値Ｔｈを上回っているか否かを判定する（ステップＳ１０４０）。値Ｔａ−Ｔｎが閾値Ｔｈを上回っている場合、ルール決定部３８は変数ｎの値に１を加算する（ステップＳ１０４５）。続いて、処理はステップＳ１０３５に戻る。
また、値Ｔａ−Ｔｎが閾値Ｔｈ以下である場合、ルール決定部３８は、攻撃防御ノード２毎のパケット数を数の多い順（または数の少ない順）に並べたときの多い方から順に１番目からｎ番目までのパケット数に係るｎ台の攻撃防御ノード２で受信されるパケットのうち、攻撃が検知されたサーバ１の仮想IPアドレス（攻撃検知部３７から通知された仮想IPアドレス）宛ての全てのパケットを棄却するフィルタリングルールを示すルール情報を生成する（ステップＳ１０５０）。このルール情報には、攻撃が検知されたサーバ１の仮想IPアドレスが含まれる。また、ルール決定部３８は、ログ記憶部３６に格納されている、ステップＳ１０２５でパケット数を算出したｎ台の攻撃防御ノード２のIPアドレスを選択する（ステップＳ１０５５）。選択されたIPアドレスを有する攻撃防御ノード２が、フィルタリングを行う攻撃防御ノード２となる。ルール決定部３８は、ステップＳ１０５０で生成したルール情報と、ステップＳ１０５５で抽出した攻撃防御ノード２のIPアドレスとを中継部３０へ出力する。
中継部３０の送受信部３０ａは、ルール決定部３８から出力されたIPアドレスを有する攻撃防御ノード２へ、ルール決定部３８から出力されたルール情報を送信する（ステップＳ１０６０）。このルール情報を受信した攻撃防御ノード２のフィルタリング設定部２０ｂは、ルール情報が示す仮想IPアドレス宛ての全てのパケットを削除するようにフィルタリング部２０ｃにフィルタリングの設定を行う。フィルタリング部２０ｃは、送受信部２０ａが受信したパケットの宛先であるサーバ１の仮想IPアドレスが、設定されたIPアドレスと一致した場合に、受信したパケットを削除する。
本実施形態では、サーバ１が接続される攻撃検知ノード３の上流側に複数の攻撃防御ノード２を設けることで、攻撃検知ノード３において、パケットが到来する方向毎（攻撃防御ノード２毎）にサーバ１へのトラヒックを監視することができる。さらに、攻撃検知ノード３において攻撃が検知された場合に、攻撃パケットが経由する攻撃防御ノード２に対して、パケットを削除するフィルタリングルールが通知され、攻撃防御ノード２でフィルタリングが行われるので、攻撃に係るトラヒックを遮断することができる。このとき、他の攻撃防御ノード２を経由し、攻撃が検知されなかった正常なトラヒックは遮断されない。
ステップＳ１０６５で決定されたフィルタリングルールは、全トラヒックに対して特定の攻撃者のクライアント５からの攻撃トラヒックの占める割合が高い攻撃に対して有効である。このような攻撃が行われている状況において、ステップＳ１０６５で決定されたフィルタリングルールに従ってフィルタリングを行うことによって、攻撃パケットが到着する攻撃防御ノード２が中継する正規のパケットを棄却せずに攻撃パケットのみを効率的に棄却することができる。
また、ステップＳ１０５０で決定されたフィルタリングルールは、多数の攻撃者のクライアント５から分散して攻撃パケットが送信される攻撃に対して有効である。このような攻撃が行われている状況において、ステップＳ１０５０で決定されたフィルタリングルールに従ってフィルタリングを行うことによって、攻撃パケットが到着する攻撃防御ノード２では正規のパケットも棄却されるが、攻撃対象のサーバ１への攻撃パケットによる影響を最小限に低減することができる。
上述したように、本実施形態によれば、攻撃検知ノード３で検知されたクライアント５毎のトラヒック量を量順に並べたときの多いほうから順に１番目からｍ番目までのトラヒック量に基づいてフィルタリングルールを決定することによって、攻撃形態に応じて、攻撃パケットの効率的なフィルタリングと、フィルタリングによる正規のトラヒックへの影響とのバランスをとったフィルタリングルールを決定することが可能となる。したがって、正規のトラヒックへの影響を抑えつつ、サーバ１を攻撃から防御することができる。本実施形態の手法では、攻撃者のクライアント５がIPアドレスを詐称して攻撃を行う場合でも、IPトレースバックを行わずに攻撃パケットを的確に棄却することができる。
また、攻撃防御ノード２がフィルタリング対象（棄却対象）として個別に指定可能なIPアドレスの数をｍとし、上位ｍ件のトラヒック量に基づいてフィルタリングルールを決定することによって、攻撃形態と攻撃防御ノード２のフィルタリング能力とに応じた適切なフィルタリングを行うことができる。
また、攻撃が検知されたサーバ１宛ての全てのトラヒック量（Ｔａ）と、上位ｍ件のトラヒック量の合計（Ｔｃ）とを比較した結果に基づいてフィルタリングルールを決定することによって、攻撃形態に応じた適切なフィルタリングを行うことができる。
また、図１３のステップＳ１０６５で決定されたフィルタリングルールに従ってフィルタリングを行うことによって、攻撃パケットが到着する攻撃防御ノード２が中継する正規のパケットを棄却せずに攻撃パケットのみを効率的に棄却することができる。さらに、図１３のステップＳ１０５０で決定されたフィルタリングルールに従ってフィルタリングを行うことによって、攻撃対象のサーバ１への攻撃パケットによる影響を最小限に低減することができる。
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
１・・・サーバ、２・・・攻撃防御ノード、３・・・攻撃検知ノード、４・・・管理ノード、５・・・クライアント、１０・・・サーバアプリケーション、１１，３１・・・サーバ公開部、２０，３０・・・中継部、２０ａ，３０ａ・・・送受信部、２０ｂ・・・フィルタリング設定部、２０ｃ・・・フィルタリング部、２１，３２・・・DHT管理部、２２，３３・・・DHT記憶部、２３，３４・・・広告部、３０ｂ・・・ログ記録部、３５・・・サーバ記憶部、３６・・・ログ記憶部、３７・・・攻撃検知部、３８・・・ルール決定部、４０・・・仮想IPアドレス記憶部、４１・・・アドレス管理部、４２・・・設定情報記憶部、４３・・・ノード管理部、４４・・・ノードリスト記憶部、５０・・・クライアントアプリケーション

Claims (5)

  1. 通信端末から、実IPアドレスおよび仮想IPアドレスを有するサーバの前記仮想IPアドレス宛てに送信されるパケットを中継する複数の第１の中継端末と、
    前記第１の中継端末によって中継されたパケットを受信し、受信したパケットを前記仮想IPアドレスに対応した前記実IPアドレス宛てのパケットに変換し、前記サーバとの間で確立されたVPN接続により前記サーバへ変換後のパケットを送信する複数の第２の中継端末と、
    を備えた通信システムであって、
    前記第１の中継端末は、
    パケットを削除するルールを示すルール情報を前記第２の中継端末から受信する受信部と、
    前記第２の中継端末から受信された前記ルール情報が示すルールに従って、前記第１の中継端末で受信されたパケットを削除するフィルタリング部と、
    を有し、
    前記第２の中継端末は、
    前記サーバ宛てのトラヒック量を検知し、検知したトラヒック量に基づいて、前記サーバ毎に攻撃を検知する検知部と、
    前記検知部によって特定のサーバへの攻撃が検知された場合に、前記第２の中継端末で受信されたパケットのうち前記特定のサーバ宛てのパケットに基づいて、当該パケットを送信した前記通信端末毎にトラヒック量を検知し、検知した前記通信端末毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＭ（Ｍ：自然数）番目までのトラヒック量に基づいて前記ルールを決定し、前記ルール情報を生成するルール決定部と、
    前記特定のサーバ宛てのパケットを中継した前記第１の中継端末へ前記ルール情報を送信する送信部と、
    を有することを特徴とする通信システム。
  2. 前記Ｍは、前記第１の中継端末で設定可能な前記ルールの数であることを特徴とする請求項１に記載の通信システム。
  3. 前記ルール決定部は、前記特定のサーバ宛ての全てのトラヒック量と、前記１番目から前記Ｍ番目までのトラヒック量の合計とを比較した結果に基づいて前記ルールを決定することを特徴とする請求項２に記載の通信システム。
  4. 前記ルール決定部は、前記１番目から前記Ｍ番目までのトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値以下である場合に、前記１番目から前記Ｍ番目までのトラヒック量に係るパケットを中継した前記第１の中継端末に設定する前記ルールとして、前記１番目から前記Ｍ番目までのトラヒック量に係るパケットを送信した前記通信端末からのパケットを削除するという前記ルールを決定することを特徴とする請求項３に記載の通信システム。
  5. 前記ルール決定部は、前記１番目から前記Ｍ番目までの第１のトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値を超える場合に、前記第２の中継端末で受信されたパケットのうち前記特定のサーバ宛てのパケットに基づいて、当該パケットを中継した前記第１の中継端末毎にトラヒック量を検知し、検知した前記第１の中継端末毎のトラヒック量を量順に並べたときの多いほうから順に１番目からＮ（Ｎ：自然数）番目までの第２のトラヒック量の合計を前記特定のサーバ宛ての全てのトラヒック量から減算した値が所定値以下であれば、前記第１のトラヒック量に係るパケットを中継した前記第１の中継端末に設定する前記ルールとして、前記第２のトラヒック量に係るパケットを中継した前記第１の中継端末で受信される全てのパケットを削除するという前記ルールを決定することを特徴とする請求項３または請求項４に記載の通信システム。
JP2011046190A 2011-03-03 2011-03-03 通信システム Withdrawn JP2012186519A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011046190A JP2012186519A (ja) 2011-03-03 2011-03-03 通信システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011046190A JP2012186519A (ja) 2011-03-03 2011-03-03 通信システム

Publications (1)

Publication Number Publication Date
JP2012186519A true JP2012186519A (ja) 2012-09-27

Family

ID=47016225

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011046190A Withdrawn JP2012186519A (ja) 2011-03-03 2011-03-03 通信システム

Country Status (1)

Country Link
JP (1) JP2012186519A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014112448A (ja) * 2014-03-19 2014-06-19 Ntt Communications Corp アクセス制御装置、アクセス制御方法、およびアクセス制御プログラム
JP2019047327A (ja) * 2017-09-01 2019-03-22 日本電信電話株式会社 異常検知装置および異常検知方法
JP7369892B1 (ja) 2023-03-03 2023-10-26 エヌ・ティ・ティ・コミュニケーションズ株式会社 情報処理装置、情報処理方法および情報処理プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014112448A (ja) * 2014-03-19 2014-06-19 Ntt Communications Corp アクセス制御装置、アクセス制御方法、およびアクセス制御プログラム
JP2019047327A (ja) * 2017-09-01 2019-03-22 日本電信電話株式会社 異常検知装置および異常検知方法
JP7369892B1 (ja) 2023-03-03 2023-10-26 エヌ・ティ・ティ・コミュニケーションズ株式会社 情報処理装置、情報処理方法および情報処理プログラム

Similar Documents

Publication Publication Date Title
JP6080313B2 (ja) 仮想ネットワークを実装及び管理するシステム及び方法
CN102845027B (zh) 用于在diameter节点处提供优先级路由的方法、系统和装置
JP5757552B2 (ja) コンピュータシステム、コントローラ、サービス提供サーバ、及び負荷分散方法
Jen et al. APT: A practical tunneling architecture for routing scalability
WO2016094037A1 (en) Stateful load balancing in a stateless network
RU2558624C2 (ru) Устройство управления, система связи, способ связи и носитель записи, содержащий записанную на нем программу для связи
JP6364106B2 (ja) ＤｉａｍｅｔｅｒシグナリングルータにおいてＤｉａｍｅｔｅｒメッセージをルーティングするための方法、システムおよびコンピュータ読取可能媒体
JP2015520959A (ja) 情報中心ネットワークにおける名前ベースの近隣探索及びマルチホップサービス探索
US9160648B2 (en) Content-centric network and method of performing routing between domains therefor
WO2017012471A1 (zh) 负载均衡处理方法及装置
JP5966488B2 (ja) ネットワークシステム、スイッチ、及び通信遅延短縮方法
JP2012186519A (ja) 通信システム
WO2017028391A1 (zh) 虚拟网络通信的方法及装置
JP4391960B2 (ja) リソース管理装置、システムおよび方法
Kambhampati et al. Epiphany: A location hiding architecture for protecting critical services from DDoS attacks
JP2010193083A (ja) 通信システムおよび通信方法
JP2005005836A (ja) ネットワーク及びサーバの負荷低減ルータ
US8811179B2 (en) Method and apparatus for controlling packet flow in a packet-switched network
JP2012186520A (ja) 通信システム
JP2011193378A (ja) 通信システム
JP2011193379A (ja) 通信システム
JP6591619B1 (ja) 通信管理装置、中継装置、通信システム、通信方法及びコンピュータプログラム
WO2009062429A1 (fr) Procédé, nœud de réseau et système évitant des attaques dans un réseau p2p
JP2011035686A (ja) 経路情報管理システム、経路情報管理方法、およびプログラム
Oesterle et al. Challenges with BGPSec

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20140513