(57)【要約】【課題】ネットワーク上のトラヒック量の監視に係るコストを低減することができる通信システムを提供する。【解決手段】パケット集約ノード２は、クライアント５からサーバ１宛てに送信されるパケットをパケット転送ノード３に中継する。パケット転送ノード３は、パケット集約ノード２が中継したパケットをサーバ１に中継する。サーバ１は１つのパケット転送ノード３のみとVPN接続を確立するため、特定のサーバ１宛てのパケットは、このサーバ１とVPN接続を確立している１つのパケット転送ノード３を必ず経由する。パケット転送ノード３は、パケットを中継したパケット集約ノード２のIPアドレスおよびサーバ１の仮想IPアドレスを組としてトラヒック量を検知する。【選択図】図１
2011193379.tif 000002
【特許請求の範囲】
【請求項１】
実IPアドレスおよび仮想IPアドレスを有するサーバと、通信端末から前記サーバ宛てに送信されるパケットを中継する複数の第１の中継端末と、前記第１の中継端末によって中継されたパケットを受信し、前記サーバとの間で確立されたVPN接続により前記サーバへパケットを送信する複数の第２の中継端末とを備えた通信システムであって、
前記第１の中継端末は、
前記通信端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスを宛先とするパケットを受信する第１の受信手段と、
前記第１の受信手段によって受信されたパケットをカプセル化によって、前記第１の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する前記第２の中継端末のIPアドレスを宛先とするパケットに変換する第１の変換手段と、
前記第１の変換手段によってカプセル化されたパケットを送信する第１の送信手段とを有し、
前記第２の中継端末は、
前記第１の中継端末からのパケットを受信する第２の受信手段と、
前記第２の受信手段によって受信されたパケットをカプセル解除によって、カプセル化される前のパケットに変換し、変換後のパケットをカプセル化によって、前記第２の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する実IPアドレスを宛先とするパケットに変換する第２の変換手段と、
前記第２の変換手段によってカプセル化されたパケットを送信する第２の送信手段と、
前記第２の変換手段によってカプセル解除されたパケットから前記第１の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを取得する取得手段と、
前記取得手段によって取得された前記第１の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第１の検知手段とを有し、
前記サーバは、前記第２の中継端末からのパケットを受信する第３の受信手段を有する
ことを特徴とする通信システム。
【請求項２】
前記第１の検知手段はさらに、検知したトラヒック量に基づいて、前記第１の中継端末から前記サーバへのトラヒック毎に攻撃を検知することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記第１の中継端末はさらに、
前記第１の受信手段によって受信されたパケットの宛先が、前記第２の中継端末から通知される前記サーバの仮想IPアドレスと一致するパケットを削除するフィルタリング手段を有し、
前記第１の受信手段はさらに、前記サーバの仮想IPアドレスを通知する情報を前記第２の中継端末から受信し、
前記第２の送信手段はさらに、前記第１の検知手段によって攻撃が検知された場合に、攻撃が検知されたトラヒックに係るパケットを中継した前記第１の中継端末に対して、攻撃が検知されたトラヒックに係る前記サーバの仮想IPアドレスを通知する情報を送信する
ことを特徴とする請求項２に記載の通信システム。
【請求項４】
前記通信システムはさらに、前記第２の中継端末が中継したパケットの情報を記録したログを解析するログ解析装置を備え、
前記第２の中継端末はさらに、
前記サーバへ送信されたパケットの情報をログとして記憶するログ記憶手段を備え、
前記第２の送信手段はさらに、前記ログの情報を前記ログ解析装置へ送信し、
前記ログ解析装置は、
前記第２の中継端末から前記ログの情報を受信する第４の受信手段と、
前記第４の受信手段によって受信された前記ログの情報に基づいて、前記第１の中継端末のIPアドレス、前記第２の中継端末のIPアドレス、および前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第２の検知手段とを有する
ことを特徴とする請求項２または請求項３に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想IPアドレスが割り当てられたサーバと、サーバ宛てのパケットを中継する中継端末とを有する通信システムに関する。
【背景技術】
【０００２】
物理的なサーバ上に複数の仮想マシンを生成し、大規模なシステムの簡便な構築を実現する、クラウド・コンピューティングが普及している。一般的に、クラウド上で稼働するサーバは、ネットワークを介したサービスの提供を行うため、DDoS攻撃などの脅威からサーバを保護する手法が必要となる。
【０００３】
従来、攻撃者が攻撃トラヒックの送信元IPアドレスを詐称することを考慮して、トレースバック技術を用いて、攻撃の到来方向や量に関する正確な情報を収集するための取り組みが行われている。非特許文献１では、パケットを監視してそのハッシュ値を生成する装置をネットワーク上に配置しておき、装置に蓄積されたハッシュ値を、トラヒックの上流に位置する装置に問い合わせる動作を繰り返すことで、送信元IPアドレスを詐称したパケットの追跡を行うことが提案されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, S. T. Kent, and W. T. Strayer, “Hash-Based IP Traceback”, Proceeding of Sigcomm 2001, August, 2001.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載されたトレースバック技術を利用してパケット毎に追跡を行い、判明した各パケットの転送経路をもとにトラヒックの到来方向や量を知ることができる。しかし、非特許文献１に記載されたトレースバック技術は、正確な追跡を行うために多量の装置をネットワーク上に配置する必要がある。なぜなら、下流側の装置から上流側の装置へ次々にハッシュ値を問い合わせる動作を繰り返す手法をとることにより、この手法のためにプログラムされていない装置があると、パケットの追跡が停止してしまうからである。したがって、上記の手法は、実施にあたって多大なコストを要する。
【０００６】
本発明は、上述した課題に鑑みてなされたものであって、ネットワーク上のトラヒック量の監視に係るコストを低減することができる通信システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、上記の課題を解決するためになされたもので、実IPアドレスおよび仮想IPアドレスを有するサーバと、通信端末から前記サーバ宛てに送信されるパケットを中継する複数の第１の中継端末と、前記第１の中継端末によって中継されたパケットを受信し、前記サーバとの間で確立されたVPN接続により前記サーバへパケットを送信する複数の第２の中継端末とを備えた通信システムであって、前記第１の中継端末は、前記通信端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスを宛先とするパケットを受信する第１の受信手段と、前記第１の受信手段によって受信されたパケットをカプセル化によって、前記第１の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する前記第２の中継端末のIPアドレスを宛先とするパケットに変換する第１の変換手段と、前記第１の変換手段によってカプセル化されたパケットを送信する第１の送信手段とを有し、前記第２の中継端末は、前記第１の中継端末からのパケットを受信する第２の受信手段と、前記第２の受信手段によって受信されたパケットをカプセル解除によって、カプセル化される前のパケットに変換し、変換後のパケットをカプセル化によって、前記第２の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する実IPアドレスを宛先とするパケットに変換する第２の変換手段と、前記第２の変換手段によってカプセル化されたパケットを送信する第２の送信手段と、前記第２の変換手段によってカプセル解除されたパケットから前記第１の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを取得する取得手段と、前記取得手段によって取得された前記第１の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第１の検知手段とを有し、前記サーバは、前記第２の中継端末からのパケットを受信する第３の受信手段を有することを特徴とする通信システムである。
【０００８】
また、本発明の通信システムにおいて、前記第１の検知手段はさらに、検知したトラヒック量に基づいて、前記第１の中継端末から前記サーバへのトラヒック毎に攻撃を検知することを特徴とする。
【０００９】
また、本発明の通信システムにおいて、前記第１の中継端末はさらに、前記第１の受信手段によって受信されたパケットの宛先が、前記第２の中継端末から通知される前記サーバの仮想IPアドレスと一致するパケットを削除するフィルタリング手段を有し、前記第１の受信手段はさらに、前記サーバの仮想IPアドレスを通知する情報を前記第２の中継端末から受信し、前記第２の送信手段はさらに、前記第１の検知手段によって攻撃が検知された場合に、攻撃が検知されたトラヒックに係るパケットを中継した前記第１の中継端末に対して、攻撃が検知されたトラヒックに係る前記サーバの仮想IPアドレスを通知する情報を送信することを特徴とする。
【００１０】
また、本発明の通信システムはさらに、前記第２の中継端末が中継したパケットの情報を記録したログを解析するログ解析装置を備え、前記第２の中継端末はさらに、前記サーバへ送信されたパケットの情報をログとして記憶するログ記憶手段を備え、前記第２の送信手段はさらに、前記ログの情報を前記ログ解析装置へ送信し、前記ログ解析装置は、前記第２の中継端末から前記ログの情報を受信する第４の受信手段と、前記第４の受信手段によって受信された前記ログの情報に基づいて、前記第１の中継端末のIPアドレス、前記第２の中継端末のIPアドレス、および前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第２の検知手段とを有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、第２の中継端末において、第１の中継端末のIPアドレスおよびサーバの仮想IPアドレスを組としたトラヒックの到来方向（第１の中継端末から第２の中継端末への方向）毎にトラヒック量を把握することが可能となる。本発明では、多量の第１の中継端末および第２の中継端末をネットワーク上に配置しなくてもよいので、ネットワーク上のトラヒック量の監視に係るコストを低減することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態による通信システムの構成を示す構成図である。
【図２】本発明の一実施形態による通信システムの機能構成を示すブロック図である。
【図３】本発明の一実施形態における初期ノード起動手順を示すシーケンス図である。
【図４】本発明の一実施形態におけるノード加入手順を示すシーケンス図である。
【図５】本発明の一実施形態におけるノード脱退手順を示すシーケンス図である。
【図６】本発明の一実施形態におけるサーバ公開開始手順を示すシーケンス図である。
【図７】本発明の一実施形態におけるサーバ公開停止手順を示すシーケンス図である。
【図８】本発明の一実施形態における通信手順を示すシーケンス図である。
【図９】本発明の一実施形態によるパケット集約ノードとパケット転送ノードと監視ノードの機能構成を示すブロック図である。
【図１０】本発明の一実施形態における攻撃検知・防御手順を示すシーケンス図である。
【図１１】本発明の一実施形態におけるログの構造を示す参考図である。
【図１２】本発明の一実施形態における攻撃検知方法を説明するための参考図である。
【図１３】本発明の一実施形態におけるログ解析方法を説明するための参考図である。
【図１４】DHTネットワークにおけるハッシュ空間を示す参考図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照し、本発明の実施形態を説明する。図１は、本発明の一実施形態による通信システムの構成を示している。本通信システムは、サーバ１、パケット集約ノード２（第１の中継端末）、パケット転送ノード３（第２の中継端末）、管理ノード４、クライアント５（通信端末）、監視ノード６を備える。
【００１４】
サーバ１は、FTP（File Transfer Protocol）サーバやWebサーバ等であり、所定のサービスを提供する。サーバ１には、実ネットワークで用いるIPアドレス（本明細書では実IPアドレスとする）と共に、仮想的なIPアドレス（本明細書では仮想IPアドレスとする）が割り当てられている。
【００１５】
パケット集約ノード２は、クライアント５からサーバ１宛てに送信されるパケットをパケット転送ノード３に中継する。パケット転送ノード３は、パケット集約ノード２が中継したパケットをサーバ１に中継する。管理ノード４は、サーバ１に対する仮想IPアドレスの割り当てと、パケット集約ノード２およびパケット転送ノード３の状態を管理する。監視ノード６は、各パケット転送ノード３が管理するログを収集し、ネットワーク上のトラヒックを監視する。
【００１６】
サーバ１とパケット転送ノード３との間ではVPN接続が確立される。これにより、サーバ１はネットワーク上の仮想的なセグメント（仮想セグメント）に収容される。サーバ１とパケット転送ノード３との関係は１対１である、すなわちサーバ１は１つのパケット転送ノード３のみとVPN接続を確立するため、特定のサーバ１宛てのパケットは、このサーバ１とVPN接続を確立している１つのパケット転送ノード３を必ず経由する。上記のようにサーバ１は１つのパケット転送ノード３のみとVPN接続を確立するため、サーバが全ての中継端末とVPN接続を確立する手法を用いる場合よりもVPN接続を確立する処理負荷およびVPN接続の管理負荷が低減される。
【００１７】
パケット転送ノード３には、同一のサーバ１に対するパケットが複数のパケット集約ノード２から到来しうる。パケット転送ノード３が、どのパケット集約ノード２からのパケットであるのかを区別してサーバ１へのパケット量を監視し、攻撃を検知することで、攻撃パケットがどのパケット集約ノード２から到来するのかを知ることができる。攻撃が検知された場合、複数のパケット集約ノード２のうち攻撃パケットを中継したパケット集約ノード２において、攻撃対象となったサーバ１の仮想IPアドレス宛てのパケットを削除するパケットフィルタリングを実施することで、サーバ１を攻撃から防御することができる。パケットフィルタリングを実施しているパケット集約ノード２以外のパケット集約ノード２から到来するパケットは攻撃パケットではないとみなされ、サーバ１へ転送される。
【００１８】
サーバ１は、パケット転送ノード３とVPN接続を確立する場合、特定の１つのパケット転送ノード３に対してVPN接続の要求を行う。このVPN接続の要求と確立はサーバ１とパケット転送ノード３との間で自律的に行われるため、１つの管理端末が全てのパケット転送ノード３の状態を管理し、サーバ１からVPN接続の要求を受けてパケット転送ノード３の情報を応答するような中央集権的な仕組みを必要としない。
【００１９】
パケット集約ノード２とパケット転送ノード３は、分散ハッシュテーブル（DHT： Distributed Hash Table）を利用したDHTネットワークを構成する。これにより、サーバ１とパケット転送ノード３との対応関係を管理する負荷がパケット集約ノード２およびパケット転送ノード３間で分散される。
【００２０】
図２は、パケットの中継に関する本通信システムの機能構成を示している。サーバ１は、サーバアプリケーション１０と、サーバ公開部１１とを有する。サーバアプリケーション１０は、クライアント５からの要求に応じてサービスを提供する。サーバ公開部１１は、サーバ１を収容する仮想セグメントを構築するためのサーバ公開に係る処理を行う。
【００２１】
パケット集約ノード２は、中継部２０と、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）に従って、仮想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ネットワークに加入しているノードのIPアドレスを含むメッセージを受信する。ノード記憶部６１は、管理ノード４から受信されたメッセージに含まれるIPアドレスを記憶する。
【００２８】
次に、パケット集約ノード２とパケット転送ノード３による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ネットワークに加入した初期ノードの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ネットワークに加入したノードの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アドレスをノードリスト記憶部４４内のノードリストから削除する（ステップＳ３２０）。
【００５３】
また、ノード管理部４３は、脱退したノードのIPアドレスを通知するメッセージを監視ノード６へ送信する（ステップＳ３３０）。監視ノード６において送受信部６０はこのメッセージを受信し、メッセージに含まれる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）を宛先とするパケットに変換される。中継部３０は、カプセル解除したパケットをクライアント５へ送信する（ステップＳ７１０）。
【００７４】
次に、本実施形態におけるサーバ１に対する攻撃の検知と防御について説明する。サーバ１宛てのパケットは、そのサーバ１を収容する仮想セグメントを構成するパケット転送ノード３によってサーバ１へ転送されるので、パケット転送ノード３においてサーバ１へのトラヒックを把握することが可能となる。図９は、攻撃の検知と防御に関するパケット集約ノード２とパケット転送ノード３と監視ノード６の機能構成を示している。
【００７５】
パケット集約ノード２は、前述した中継部２０を有する。中継部２０は、パケットの送信および受信を行う送受信部２０ａと、パケット転送ノード３から通知されるフィルタリングルールを中継部２０に設定するフィルタリング設定部２０ｂと、パケット転送ノード３から通知されるフィルタリングルールに従ってパケットを削除するフィルタリング部２０ｃとを有する。
【００７６】
パケット転送ノード３は、前述した中継部３０と、ログ記憶部３６と、攻撃検知部３７とを有する。中継部３０は、パケットの送信および受信を行う送受信部３０ａと、サーバ１に中継したパケットの情報をログに記録するログ記録部３０ｂとを有する。ログ記憶部３６は、中継部３０がサーバ１に中継したパケットの情報を含むログを記憶する。攻撃検知部３７は、ログ記憶部３６に記憶されているログに基づいて攻撃を検知する。
【００７７】
監視ノード６は、送受信部６０と、ノード記憶部６１と、ログ記憶部６２と、ログ解析部６３と、表示部６４とを有する。送受信部６０は、複数のパケット転送ノード３から送信されたログを受信する。ノード記憶部６１は、管理ノード４から通知されたノードの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ネットワークに加入しているパケット集約ノード２とパケット転送ノード３によって受信されるが、パケット転送ノード３のみが応答する。パケット転送ノード３の送受信部３０ａは、ログ記憶部３６に記憶されているログを監視ノード６へ送信する（ステップＳ８４０）。監視ノード６の送受信部６０は、複数のパケット転送ノード３からログを受信する。受信されたログはログ記憶部６２に記憶される。ログ解析部６３は、ログ記憶部６２内のログを解析する（ステップＳ８５０）。
【００８４】
より具体的には、ログ解析部６３は、時刻とサーバ１の仮想IPアドレスとパケット集約ノード２のIPアドレスとパケット転送ノード３のIPアドレスとを組としてログから取得し、ログから取得した情報を時系列に整列する。さらに、ログ解析部６３は、サーバ１の仮想IPアドレスとパケット集約ノード２のIPアドレスとパケット転送ノード３のIPアドレスとの全てが同一のものを攻撃検知の単位としてパケット数（トラヒック量）を集計し、１秒当たりのパケット数を算出する。
【００８５】
図１３は解析結果を示している。サーバ１の仮想IPアドレス、パケット集約ノード２のIPアドレス、およびパケット転送ノード３のIPアドレス中の「サーバＡ」や、「パケット集約ノードＸ」、「パケット転送ノードＰ」は実際にはサーバ１の仮想IPアドレスや、パケット集約ノード２のIPアドレス、パケット転送ノード３のIPアドレスである。図１３では、内容を理解しやすくするため、IPアドレスをサーバ等の名称に置き換えている。
【００８６】
表示部６４は、ログ解析部６３が行った解析の結果を表示する（ステップＳ８６０）。このとき、例えば、ネットワークのトポロジと通信経路を視覚化し、パケット数に応じて通信経路を強調表示するなどの表示処理が行われる。これによって、管理者はネットワーク上の攻撃トラヒックの状況を把握することができる。
【００８７】
上述したように、本実施形態によれば、パケット転送ノード３において、パケット集約ノード２のIPアドレスおよびサーバ１の仮想IPアドレスを組としたトラヒックの到来方向（パケット集約ノード２からパケット転送ノード３への方向）毎にトラヒック量を把握することが可能となる。本実施形態では、非特許文献１に記載されている手法と比較して、多量のパケット集約ノード２およびパケット転送ノード３をネットワーク上に配置しなくてもよいので、ネットワーク上のトラヒック量の監視に係るコストを低減することができる。
【００８８】
また、非特許文献１に記載されたトレースバック技術を利用してパケット毎に追跡を行い、判明した各パケットの転送経路をもとにトラヒックの到来方向や量を知る手法では、専用のプログラムをルータ機器に組み込む必要があることから、トラヒック監視を実施する事業者は、自身が管理するルータ機器については、専用のプログラムを組み込むことによりルータ機器から情報を収集できるが、他の事業者が管理するルータ機器からは情報を収集できない。これに対して、本実施形態では、トラヒック監視を実施する事業者は、自身が管理するパケット集約ノード２とパケット転送ノード３を用いてトラヒックの監視が可能となる。また、攻撃パケットの送信者が送信元のIPアドレスを詐称する場合でも、パケット集約ノード２の位置に基づいて攻撃の到来方向を正確に把握することができる。
【００８９】
また、サーバ１は１つのパケット転送ノード３のみとVPN接続を確立するため、サーバが全ての中継端末とVPN接続を確立する手法（例えば、文献（磯原隆将、窪田歩、三宅優、“IPトレースバックを用いないDDoS攻撃防御手法の提案”、2009年3月、電子情報通信学会 総合大会）に記載の手法）を用いる場合よりもVPN接続を確立する処理負荷およびVPN接続の管理負荷を低減することができる。また、VPN接続の要求と確立がサーバ１とパケット転送ノード３との間で自律的に行われるため、１つの管理端末が全てのパケット転送ノード３の状態を管理し、サーバ１からVPN接続の要求を受けてパケット転送ノード３の情報を応答するような中央集権的な仕組みを必要としない。
【００９０】
また、サーバ１が接続されるパケット転送ノード３の上流側に複数のパケット集約ノード２を設けていることで、パケット転送ノード３において、パケットが到来する方向毎（パケット集約ノード２毎）にサーバ１へのトラヒックを監視することができる。さらに、パケット転送ノード３において攻撃が検知された場合に、攻撃に係るパケットが経由するパケット集約ノード２に対して、サーバ１の仮想IPアドレス宛てのパケットを削除するフィルタリングルールが通知され、パケット集約ノード２でフィルタリングが行われるので、攻撃に係るトラヒックを遮断することができる。このとき、他のパケット集約ノード２を経由し、攻撃が検知されなかった正常なトラヒックは遮断されない。
【００９１】
また、パケット集約ノード２とパケット転送ノード３が、分散ハッシュテーブルを利用したDHTネットワークを構成することによって、サーバ１とパケット転送ノード３との対応関係を管理する負荷をパケット集約ノード２とパケット転送ノード３間で分散することができる。
【００９２】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【符号の説明】
【００９３】
１・・・サーバ、２・・・パケット集約ノード、３・・・パケット転送ノード、４・・・管理ノード、５・・・クライアント、６・・・監視ノード、１０・・・サーバアプリケーション、１１，３１・・・サーバ公開部、２０，３０・・・中継部、２０ａ，３０ａ，６０・・・送受信部、２０ｂ・・・フィルタリング設定部、２０ｃ・・・フィルタリング部、２１，３２・・・DHT管理部、２２，３３・・・DHT記憶部、２３，３４・・・広告部、３０ｂ・・・ログ記録部、３５・・・サーバ記憶部、３６，６２・・・ログ記憶部、３７・・・攻撃検知部、４０・・・仮想IPアドレス記憶部、４１・・・アドレス管理部、４２・・・設定情報記憶部、４３・・・ノード管理部、４４・・・ノードリスト記憶部、５０・・・クライアントアプリケーション、６１・・・ノード記憶部、６３・・・ログ解析部、６４・・・表示部
【図１】
2011193379.tif 000003
【図２】
2011193379.tif 000004
【図３】
2011193379.tif 000005
【図４】
2011193379.tif 000006
【図５】
2011193379.tif 000007
【図６】
2011193379.tif 000008
【図７】
2011193379.tif 000009
【図８】
2011193379.tif 000010
【図９】
2011193379.tif 000011
【図１０】
2011193379.tif 000012
【図１１】
2011193379.tif 000013
【図１２】
2011193379.tif 000014
【図１３】
2011193379.tif 000015
【図１４】
2011193379.tif 000016