JP2011193379A - 通信システム - Google Patents
通信システム Download PDFInfo
- Publication number
- JP2011193379A JP2011193379A JP2010059695A JP2010059695A JP2011193379A JP 2011193379 A JP2011193379 A JP 2011193379A JP 2010059695 A JP2010059695 A JP 2010059695A JP 2010059695 A JP2010059695 A JP 2010059695A JP 2011193379 A JP2011193379 A JP 2011193379A
- Authority
- JP
- Japan
- Prior art keywords
- node
- address
- packet
- server
- virtual
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ネットワーク上のトラヒック量の監視に係るコストを低減することができる通信システムを提供する。
【解決手段】パケット集約ノード2は、クライアント5からサーバ1宛てに送信されるパケットをパケット転送ノード3に中継する。パケット転送ノード3は、パケット集約ノード2が中継したパケットをサーバ1に中継する。サーバ1は1つのパケット転送ノード3のみとVPN接続を確立するため、特定のサーバ1宛てのパケットは、このサーバ1とVPN接続を確立している1つのパケット転送ノード3を必ず経由する。パケット転送ノード3は、パケットを中継したパケット集約ノード2のIPアドレスおよびサーバ1の仮想IPアドレスを組としてトラヒック量を検知する。
【選択図】図1
【解決手段】パケット集約ノード2は、クライアント5からサーバ1宛てに送信されるパケットをパケット転送ノード3に中継する。パケット転送ノード3は、パケット集約ノード2が中継したパケットをサーバ1に中継する。サーバ1は1つのパケット転送ノード3のみとVPN接続を確立するため、特定のサーバ1宛てのパケットは、このサーバ1とVPN接続を確立している1つのパケット転送ノード3を必ず経由する。パケット転送ノード3は、パケットを中継したパケット集約ノード2のIPアドレスおよびサーバ1の仮想IPアドレスを組としてトラヒック量を検知する。
【選択図】図1
Description
本発明は、仮想IPアドレスが割り当てられたサーバと、サーバ宛てのパケットを中継する中継端末とを有する通信システムに関する。
物理的なサーバ上に複数の仮想マシンを生成し、大規模なシステムの簡便な構築を実現する、クラウド・コンピューティングが普及している。一般的に、クラウド上で稼働するサーバは、ネットワークを介したサービスの提供を行うため、DDoS攻撃などの脅威からサーバを保護する手法が必要となる。
従来、攻撃者が攻撃トラヒックの送信元IPアドレスを詐称することを考慮して、トレースバック技術を用いて、攻撃の到来方向や量に関する正確な情報を収集するための取り組みが行われている。非特許文献1では、パケットを監視してそのハッシュ値を生成する装置をネットワーク上に配置しておき、装置に蓄積されたハッシュ値を、トラヒックの上流に位置する装置に問い合わせる動作を繰り返すことで、送信元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.
非特許文献1に記載されたトレースバック技術を利用してパケット毎に追跡を行い、判明した各パケットの転送経路をもとにトラヒックの到来方向や量を知ることができる。しかし、非特許文献1に記載されたトレースバック技術は、正確な追跡を行うために多量の装置をネットワーク上に配置する必要がある。なぜなら、下流側の装置から上流側の装置へ次々にハッシュ値を問い合わせる動作を繰り返す手法をとることにより、この手法のためにプログラムされていない装置があると、パケットの追跡が停止してしまうからである。したがって、上記の手法は、実施にあたって多大なコストを要する。
本発明は、上述した課題に鑑みてなされたものであって、ネットワーク上のトラヒック量の監視に係るコストを低減することができる通信システムを提供することを目的とする。
本発明は、上記の課題を解決するためになされたもので、実IPアドレスおよび仮想IPアドレスを有するサーバと、通信端末から前記サーバ宛てに送信されるパケットを中継する複数の第1の中継端末と、前記第1の中継端末によって中継されたパケットを受信し、前記サーバとの間で確立されたVPN接続により前記サーバへパケットを送信する複数の第2の中継端末とを備えた通信システムであって、前記第1の中継端末は、前記通信端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスを宛先とするパケットを受信する第1の受信手段と、前記第1の受信手段によって受信されたパケットをカプセル化によって、前記第1の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する前記第2の中継端末のIPアドレスを宛先とするパケットに変換する第1の変換手段と、前記第1の変換手段によってカプセル化されたパケットを送信する第1の送信手段とを有し、前記第2の中継端末は、前記第1の中継端末からのパケットを受信する第2の受信手段と、前記第2の受信手段によって受信されたパケットをカプセル解除によって、カプセル化される前のパケットに変換し、変換後のパケットをカプセル化によって、前記第2の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する実IPアドレスを宛先とするパケットに変換する第2の変換手段と、前記第2の変換手段によってカプセル化されたパケットを送信する第2の送信手段と、前記第2の変換手段によってカプセル解除されたパケットから前記第1の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを取得する取得手段と、前記取得手段によって取得された前記第1の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第1の検知手段とを有し、前記サーバは、前記第2の中継端末からのパケットを受信する第3の受信手段を有することを特徴とする通信システムである。
また、本発明の通信システムにおいて、前記第1の検知手段はさらに、検知したトラヒック量に基づいて、前記第1の中継端末から前記サーバへのトラヒック毎に攻撃を検知することを特徴とする。
また、本発明の通信システムにおいて、前記第1の中継端末はさらに、前記第1の受信手段によって受信されたパケットの宛先が、前記第2の中継端末から通知される前記サーバの仮想IPアドレスと一致するパケットを削除するフィルタリング手段を有し、前記第1の受信手段はさらに、前記サーバの仮想IPアドレスを通知する情報を前記第2の中継端末から受信し、前記第2の送信手段はさらに、前記第1の検知手段によって攻撃が検知された場合に、攻撃が検知されたトラヒックに係るパケットを中継した前記第1の中継端末に対して、攻撃が検知されたトラヒックに係る前記サーバの仮想IPアドレスを通知する情報を送信することを特徴とする。
また、本発明の通信システムはさらに、前記第2の中継端末が中継したパケットの情報を記録したログを解析するログ解析装置を備え、前記第2の中継端末はさらに、前記サーバへ送信されたパケットの情報をログとして記憶するログ記憶手段を備え、前記第2の送信手段はさらに、前記ログの情報を前記ログ解析装置へ送信し、前記ログ解析装置は、前記第2の中継端末から前記ログの情報を受信する第4の受信手段と、前記第4の受信手段によって受信された前記ログの情報に基づいて、前記第1の中継端末のIPアドレス、前記第2の中継端末のIPアドレス、および前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第2の検知手段とを有することを特徴とする。
本発明によれば、第2の中継端末において、第1の中継端末のIPアドレスおよびサーバの仮想IPアドレスを組としたトラヒックの到来方向(第1の中継端末から第2の中継端末への方向)毎にトラヒック量を把握することが可能となる。本発明では、多量の第1の中継端末および第2の中継端末をネットワーク上に配置しなくてもよいので、ネットワーク上のトラヒック量の監視に係るコストを低減することができる。
以下、図面を参照し、本発明の実施形態を説明する。図1は、本発明の一実施形態による通信システムの構成を示している。本通信システムは、サーバ1、パケット集約ノード2(第1の中継端末)、パケット転送ノード3(第2の中継端末)、管理ノード4、クライアント5(通信端末)、監視ノード6を備える。
サーバ1は、FTP(File Transfer Protocol)サーバやWebサーバ等であり、所定のサービスを提供する。サーバ1には、実ネットワークで用いるIPアドレス(本明細書では実IPアドレスとする)と共に、仮想的なIPアドレス(本明細書では仮想IPアドレスとする)が割り当てられている。
パケット集約ノード2は、クライアント5からサーバ1宛てに送信されるパケットをパケット転送ノード3に中継する。パケット転送ノード3は、パケット集約ノード2が中継したパケットをサーバ1に中継する。管理ノード4は、サーバ1に対する仮想IPアドレスの割り当てと、パケット集約ノード2およびパケット転送ノード3の状態を管理する。監視ノード6は、各パケット転送ノード3が管理するログを収集し、ネットワーク上のトラヒックを監視する。
サーバ1とパケット転送ノード3との間ではVPN接続が確立される。これにより、サーバ1はネットワーク上の仮想的なセグメント(仮想セグメント)に収容される。サーバ1とパケット転送ノード3との関係は1対1である、すなわちサーバ1は1つのパケット転送ノード3のみとVPN接続を確立するため、特定のサーバ1宛てのパケットは、このサーバ1とVPN接続を確立している1つのパケット転送ノード3を必ず経由する。上記のようにサーバ1は1つのパケット転送ノード3のみとVPN接続を確立するため、サーバが全ての中継端末とVPN接続を確立する手法を用いる場合よりもVPN接続を確立する処理負荷およびVPN接続の管理負荷が低減される。
パケット転送ノード3には、同一のサーバ1に対するパケットが複数のパケット集約ノード2から到来しうる。パケット転送ノード3が、どのパケット集約ノード2からのパケットであるのかを区別してサーバ1へのパケット量を監視し、攻撃を検知することで、攻撃パケットがどのパケット集約ノード2から到来するのかを知ることができる。攻撃が検知された場合、複数のパケット集約ノード2のうち攻撃パケットを中継したパケット集約ノード2において、攻撃対象となったサーバ1の仮想IPアドレス宛てのパケットを削除するパケットフィルタリングを実施することで、サーバ1を攻撃から防御することができる。パケットフィルタリングを実施しているパケット集約ノード2以外のパケット集約ノード2から到来するパケットは攻撃パケットではないとみなされ、サーバ1へ転送される。
サーバ1は、パケット転送ノード3とVPN接続を確立する場合、特定の1つのパケット転送ノード3に対してVPN接続の要求を行う。このVPN接続の要求と確立はサーバ1とパケット転送ノード3との間で自律的に行われるため、1つの管理端末が全てのパケット転送ノード3の状態を管理し、サーバ1からVPN接続の要求を受けてパケット転送ノード3の情報を応答するような中央集権的な仕組みを必要としない。
パケット集約ノード2とパケット転送ノード3は、分散ハッシュテーブル(DHT: Distributed Hash Table)を利用したDHTネットワークを構成する。これにより、サーバ1とパケット転送ノード3との対応関係を管理する負荷がパケット集約ノード2およびパケット転送ノード3間で分散される。
図2は、パケットの中継に関する本通信システムの機能構成を示している。サーバ1は、サーバアプリケーション10と、サーバ公開部11とを有する。サーバアプリケーション10は、クライアント5からの要求に応じてサービスを提供する。サーバ公開部11は、サーバ1を収容する仮想セグメントを構築するためのサーバ公開に係る処理を行う。
パケット集約ノード2は、中継部20と、DHT管理部21と、DHT記憶部22と、広告部23とを有する。中継部20は、クライアント5から送信されたパケットをパケット転送ノード3に中継する。DHT管理部21は、DHTネットワークに参加するための処理を行い、DHT記憶部22に記憶される情報を管理する。DHT記憶部22は、サーバ1とVPN接続を確立しているパケット転送ノード3のIPアドレスとサーバ1の仮想IPアドレスとの対応関係を示す情報を記憶する。より具体的には、DHT記憶部22は、サーバ1とVPN接続を確立しているパケット転送ノード3のIPアドレスと、サーバ1の仮想IPアドレスからSHA1(Secure Hash Algorithm 1)を用いて算出したハッシュ値とを関連付けて記憶する。DHTネットワークでは、この対応関係を示す情報は、サーバ1とVPN接続を確立しているパケット転送ノード3で管理されるとは限らず、DHTネットワークを構成するパケット集約ノード2とパケット転送ノード3のいずれかにおいて管理される。
広告部23は、サーバ1の仮想IPアドレス宛てのパケットがパケット集約ノード2に届くように、ルーティングプロトコルの一種であるOSPF(Open Shortest Path First)に従って、仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。クライアント5がサーバ1の仮想IPアドレス宛てのパケットを送信すると、この経路情報に従ってネットワーク上のルータが転送を行うことにより、クライアント5に最も近いパケット集約ノード2にパケットが到着する。
パケット転送ノード3は、中継部30と、サーバ公開部31と、DHT管理部32と、DHT記憶部33と、広告部34とを有する。中継部30は、パケット集約ノード2から送信されたパケットをサーバ1に中継する。サーバ公開部31は、サーバ1を収容する仮想セグメントを構築するためのサーバ公開に係る処理を行う。DHT管理部32は、DHTネットワークに参加するための処理を行い、DHT記憶部33に記憶される情報を管理する。DHT記憶部33はDHT記憶部22と同様に、サーバ1とVPN接続を確立しているパケット転送ノード3のIPアドレスと、サーバ1の仮想IPアドレスからSHA1を用いて算出したハッシュ値とを関連付けて記憶する。
広告部34は、OSPFに従って、エニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する。サーバ1が、サーバ公開に係るVPN接続を行う際にエニーキャストアドレス宛てにパケット転送ノード3の検索要求を行うと、サーバ1に最も近いパケット転送ノード3から応答が返される。サーバ記憶部35は、サーバ1の仮想IPアドレスと実IPアドレスとを関連付けて記憶する。
管理ノード4は、仮想IPアドレス記憶部40と、アドレス管理部41と、設定情報記憶部42と、ノード管理部43と、ノードリスト記憶部44とを有する。仮想IPアドレス記憶部40は、サーバ1に割り当てられる仮想IPアドレスを記憶する。アドレス管理部41は、サーバ1に対する仮想IPアドレスの割り当てを管理する。設定情報記憶部42は、パケット集約ノード2に通知する仮想IPアドレスの範囲や、パケット転送ノード3に通知するエニーキャストアドレスの範囲等を含む設定情報を記憶する。各パケット集約ノード2には共通の仮想IPアドレス範囲が通知される。また、各パケット転送ノード3には共通のエニーキャストアドレス範囲が通知される。ノード管理部43は、DHTネットワークを構成するパケット集約ノード2およびパケット転送ノード3の情報を管理する。ノードリスト記憶部44は、DHTネットワークを構成するパケット集約ノード2およびパケット転送ノード3の一覧であるノードリストを記憶する。
クライアント5はクライアントアプリケーション50を有する。クライアントアプリケーション50はサーバ1に対してサービスの要求を行う。
監視ノード6は、送受信部60と、ノード記憶部61とを有する。送受信部60は、管理ノード4から送信された、DHTネットワークに加入しているノードのIPアドレスを含むメッセージを受信する。ノード記憶部61は、管理ノード4から受信されたメッセージに含まれるIPアドレスを記憶する。
次に、パケット集約ノード2とパケット転送ノード3によるDHTネットワークの構築と管理について説明する。DHTネットワークにおいては、ネットワークを構成するノードの加入と離脱が生じる。ノードが加入する場合、既にDHTネットワークを構成しているいずれかのノードに対して加入処理を行うことで、DHTネットワークへの加入を行う。一方、DHTネットワークからノードが離脱する場合、ルーティングテーブルの再構築が行われ、残りのノードにより通信が継続される。このとき、離脱したノードが所持していた情報はDHTネットワーク上で隣接するノードが同期を取るなどして保持される。なお、最初にDHTネットワークを構成するノードが起動する場合は、加入処理を行う対象のノードが存在しないため、初期ノード起動処理が行われる。以下、DHTネットワークを構築するアルゴリズムの一種であるChordを実装したプログラムを例に、それぞれの具体的な手法を説明する。
図3は、DHTネットワークを構成する最初のノードである初期ノード(パケット集約ノード2またはパケット転送ノード3)が加入する場合のシーケンスを示している。初期ノードにおいて、DHT管理部21(32)は、ノードリストの取得要求を示すノードリスト要求を管理ノード4へ送信する(ステップS100)。なお、管理ノード4のIPアドレスは既知であるものとする。管理ノード4においてノード管理部43はノードリスト要求を受信し、ノードリスト記憶部44内のノードリストにノードのIPアドレスが登録されているか否かを判定する(ステップS110)。
最初のノードが加入する場合、ノードリストにノードのIPアドレスが登録されていないため、管理ノード4は初期ノード起動処理が必要であると判定し、初期ノード起動処理の要求を示す初期ノード起動要求を、ノードリスト要求の送信元であるノードへ送信する(ステップS120)。初期ノード起動要求には、設定情報記憶部42内の設定情報に基づく仮想IPアドレスの範囲とエニーキャストアドレスの範囲が含まれる。
初期ノードにおいて、DHT管理部21(32)は、初期ノード起動要求を受信し、初期ノード起動処理を実行する(ステップS130)。具体的には、次に示すようなブートストラップノードの起動コマンドを実行する。
start-dhash --root dhash-a -j sure.lcs.mit.edu:10000 -p 10000 &
start-dhash --root dhash-a -j sure.lcs.mit.edu:10000 -p 10000 &
初期ノード起動処理の実行により、DHT記憶部22(33)には分散ハッシュテーブルが作成される。前述したように、このテーブルの構成要素は、サーバ1とVPN接続を確立しているパケット転送ノード3のIPアドレスと、サーバ1の仮想IPアドレスからSHA1を用いて算出したハッシュ値とのペアである。初期ノード起動処理が完了した時点では、テーブルにはこれらの情報は格納されていない。また、初期ノード起動処理が完了した時点では、DHTネットワークの全てのノード(1個)の情報を初期ノードが単体で管理している状態となる。
初期ノード起動処理の実行後、DHT管理部21(32)は、初期ノードがDHTネットワークに加入したことを示すノード加入通知を管理ノード4へ送信することにより自身のIPアドレスを通知する(ステップS140)。管理ノード4においてノード管理部43はノード加入通知を受信し、ノード加入通知により通知されたIPアドレスをノードリスト記憶部44内のノードリストに追加する(ステップS150)。
初期ノードがパケット集約ノード2である場合、初期ノード起動処理の実行後、パケット集約ノード2の広告部23は、初期ノード起動要求によって通知された範囲の仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。また、初期ノードがパケット転送ノード3である場合、初期ノード起動処理の実行後、パケット転送ノード3の広告部34は、初期ノード起動要求によって通知された範囲のエニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する(ステップS160)。
一方、管理ノード4においてノード管理部43は、DHTネットワークに加入した初期ノードのIPアドレスを通知するメッセージを監視ノード6へ送信する(ステップS170)。監視ノード6において送受信部60はこのメッセージを受信し、メッセージに含まれるIPアドレスをノード記憶部61に記録する。
なお、管理ノード4が初期ノードからノードリスト要求を受信してからノード加入通知を受信するまでの間に他のノードからノードリスト要求を受信した場合、ノードリスト要求の再送を示すメッセージが他のノードへ送信される。このため、初期ノードによるDHTネットワークが構築されるまで、他のノードからのノードリスト要求に対する処理は実行されない。
図4は、1以上のノードによりDHTネットワークが構成されている場合に新たなノード(パケット集約ノード2またはパケット転送ノード3)が加入する場合のシーケンスを示している。新たに加入するノードにおいて、DHT管理部21(32)は、ノードリストの取得要求を示すノードリスト要求を管理ノード4へ送信する(ステップS200)。なお、管理ノード4のIPアドレスは既知であるものとする。管理ノード4においてノード管理部43はノードリスト要求を受信し、ノードリスト記憶部44内のノードリストにノードのIPアドレスが登録されているか否かを判定する(ステップS210)。
既に他のノードが加入している場合、ノードリストにノードのIPアドレスが登録されているため、管理ノード4は、ノードリスト要求の送信元であるノードへノードリストを送信する(ステップS220)。このとき、設定情報記憶部42内の設定情報に基づく仮想IPアドレスの範囲とエニーキャストアドレスの範囲がノードリストに付加される。新たに加入するノードにおいて、DHT管理部21(32)は、ノードリストを受信し、ノードリストに記載されているノードを対象としてノード加入処理を実行する(ステップS230)。具体的には、次に示すような既存ノードへの加入のコマンドを実行する。
start-dhash --root dhash-b -j sure.lcs.mit.edu:10000 &
start-dhash --root dhash-b -j sure.lcs.mit.edu:10000 &
ノード加入処理の実行により、DHT記憶部22(33)には分散ハッシュテーブルが作成される。ノード加入処理では、ノードリストに記載されたIPアドレスを有するノードと通信が行われ、DHTネットワークに加入するための設定が行われる。
ノード加入処理の実行後、DHT管理部21(32)は、新たにノードがDHTネットワークに加入したことを示すノード加入通知を管理ノード4へ送信することにより自身のIPアドレスを通知する(ステップS240)。管理ノード4においてノード管理部43はノード加入通知を受信し、ノード加入通知により通知されたIPアドレスをノードリスト記憶部44内のノードリストに追加する(ステップS250)。
新たに加入するノードがパケット集約ノード2である場合、ノード加入処理の実行後、パケット集約ノード2の広告部23は、管理ノード4から通知された範囲の仮想IPアドレス宛ての経路に係る経路情報をネットワーク上に広告する。また、新たに加入するノードがパケット転送ノード3である場合、ノード加入処理の実行後、パケット転送ノード3の広告部34は、管理ノード4から通知された範囲のエニーキャストアドレス宛ての経路に係る経路情報をネットワーク上に広告する(ステップS260)。
一方、管理ノード4においてノード管理部43は、DHTネットワークに加入したノードのIPアドレスを通知するメッセージを監視ノード6へ送信する(ステップS270)。監視ノード6において送受信部60はこのメッセージを受信し、メッセージに含まれるIPアドレスをノード記憶部61に記録する。
以下、ステップS230において、DHTネットワークに加入する処理の詳細を説明する。DHTは、管理対象の情報のハッシュ値(以下、Keyとする)と、管理対象の情報(以下、Valueとする)とのペアを格納する分散ハッシュテーブルを複数のノードに分散させることによって、情報を効率的に管理する手法である。本実施形態では、サーバ1の仮想IPアドレスがKeyに該当し、パケット転送ノード3のIPアドレスがValueに該当する。本実施形態では、DHTネットワークを構成するパケット集約ノード2およびパケット転送ノード3が、自身のIPアドレスに基づいて、管理対象となるパケット転送ノード3のIPアドレス(Value)を管理する。
本実施形態でDHTネットワークの実装アルゴリズムの一例として用いるChordでは、DHTネットワークを構成するノードが各ノードのIDに従って配置される。各ノードに割り当てられるIDは、具体的にはノード毎のIPアドレスからSHA-1を用いて算出したハッシュ値である。Chordでは2160のハッシュ空間が用いられ、各ノードは円周上の点として定義される。図14は、簡単のためハッシュ空間を24とした場合のIDの割り当てを示している。0から15までの各IDを有するノードが配置されている。
Chordでは、DHTネットワークを構成する各ノードが、自身のノードIDから隣接するノードIDまでの間に位置するIDに対応するValueを管理する。図14において、ノードIDが0、2、6、9、11、13、14のノードがDHTネットワークに加入している場合、ノードIDが0のノード0は、ノードIDが15と0に対応するKeyとValueのペアを管理する。
Chordでは、各ノードはSuccessor、Predecessor、Fingertableと呼ばれる3種類のルーティングテーブルを保持する。これらのルーティングテーブルは、各ノードがDHT記憶部22(33)の分散ハッシュテーブルに保持するKeyとValueのペア(サーバ1の仮想IPアドレスと転送ノードのIPアドレスのペア)とは異なる。各ルーティングテーブルはDHT記憶部22(33)に保持されるものとする。
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アドレスを返す関数である。
ノードのIPアドレス=IPadress[next(Z)]、ただし、Z=(Node_ID+2i) mod2m、i=0〜m
上記の式のnext(Z)は、ハッシュ空間上でZから右回り(つまりノードIDが大きくなる方向)に見て次に存在するノードのIDを返す関数である。IPadress[X]はIDがXのノードのIPアドレスを返す関数である。
DHTネットワークに新たなノードが加入することは、円周上のノードが存在していない点の位置にノードが加わることを意味する。以下では、ID12のノード(ノード12)とID18のノード(ノード18)が存在しているDHTネットワークにID15のノード(ノード15)が加入する場合を例として加入の手順を説明する。
ノード15は、自身のIPアドレスからハッシュ値であるIDを算出する。続いて、ノード15は、ノードリストに記載されているノードに対して、自身のIDを保持の対象としているノードのIPアドレスを要求する。要求を受けたノードは、ノード15のIDを保持していれば応答し、保持していなければ他のノードに要求を行う。この結果、ノード15はノード18のIPアドレスを取得する。
続いて、ノード15はノード18にjoinメッセージを送信し、Successorにノード18のIPアドレスを記録する。さらに、ノード15はノード18から、Predecessorに保持すべきノード12のIPアドレスを通知され、Predecessorにノード12のIPアドレスを記録する。
続いて、ノード15は、それまでノード18がFingertableに保持していたIPアドレスのうち、ノード15が管理すべき部分に該当するIPアドレスをノード18から受信し、Fingertableに記録する。また、ノード15は、それまでノード18がDHT記憶部22(33)の分散ハッシュテーブルに保持していたKeyとValueのペアのうち、ノード15が管理すべき部分に該当するKeyとValueのペアをノード18から受信し、DHT記憶部22(33)に記録する。ノード15は、ノード12に自身の加入を通知し、ノード12は、ノード15からの通知に基づいて、自身が保持しているSuccessorに記録されていたノード18のIPアドレスをノード15のIPアドレスに変更する。
図5は、DHTネットワークに加入しているノード(パケット集約ノード2またはパケット転送ノード3)がDHTネットワークから脱退する場合のシーケンスを示している。DHTネットワークから脱退するノードにおいて、DHT管理部21(32)はノード脱退処理を実行する(ステップS300)。続いて、DHT管理部21(32)は、DHTネットワークからの脱退を示すノード脱退通知を管理ノード4へ送信することにより自身のIPアドレスを通知する(ステップS310)。管理ノード4においてノード管理部43はノード脱退通知を受信し、ノード脱退通知により通知されたIPアドレスをノードリスト記憶部44内のノードリストから削除する(ステップS320)。
また、ノード管理部43は、脱退したノードのIPアドレスを通知するメッセージを監視ノード6へ送信する(ステップS330)。監視ノード6において送受信部60はこのメッセージを受信し、メッセージに含まれるIPアドレスと一致するIPアドレスをノード記憶部61から削除する。
上記のようにしてノードが脱退した場合、ハッシュ空間上でこのノードに隣接するノードにおいて、Successor、Predecessor、Fingertableがそれぞれ更新される。このとき、脱退したノードが保持していた情報を引き継ぐための処理として、DHTでは近傍のノードに自身が保持するデータのコピーを配置するなどして情報の欠損を防いでいる。
次に、サーバ1を収容する仮想セグメントを構築するためのサーバ公開について説明する。サーバ1は予め管理ノード4から仮想IPアドレスを取得する。管理ノード4においてアドレス管理部41は予め仮想IPアドレスを生成し、仮想IPアドレス記憶部40に保存する。サーバ1のサーバ公開部11は管理ノード4にアクセスし、仮想IPアドレスの割り当てに必要な情報の登録を行う。管理ノード4のアドレス管理部41は、仮想IPアドレス記憶部40から仮想IPアドレスを選択し、仮想IPアドレスをサーバ1に通知する。複数のサーバ1に対して同一の仮想IPアドレスが割り当てられないよう、アドレス管理部41は仮想IPアドレスの割り当てを管理する。サーバ1に対する仮想IPアドレスの通知は公開鍵証明書の発行により行われるが、詳細な説明を省略する。この公開鍵証明書はサーバ1がパケット転送ノード3にアクセスする際に使用されるが、本実施形態では、公開鍵証明書による公知の通信方法に係る説明を省略する。
図6は、仮想IPアドレスを取得したサーバ1の公開開始時のシーケンスを示している。サーバ1は、パケット転送ノード3が使用するエニーキャストアドレスを予め知っているものとする。サーバ1のサーバ公開部11は、エニーキャストアドレス宛てにパケット転送ノード3の接続要求を送信する(ステップS400)。この接続要求はサーバ1に最も近いパケット転送ノード3に到着する。パケット転送ノード3のサーバ公開部31はサーバ1からの接続要求を受信し、自身のIPアドレスを通知する応答をサーバ1へ送信する(ステップS410)。
サーバ1のサーバ公開部11はパケット転送ノード3からの応答を受信し、その応答によって通知されたIPアドレス宛てに、VPN接続の要求を示すVPN接続要求を送信する(ステップS420)。このVPN接続要求によって、サーバ1の仮想IPアドレスおよび実IPアドレスがパケット転送ノード3に通知される。この後、サーバ1とパケット転送ノード3の双方においてVPN接続のための各種設定が行われるが、詳細な説明を省略する。
パケット転送ノード3のサーバ公開部31は、サーバ1から通知された仮想IPアドレスをDHT管理部32に通知する。DHT管理部32は仮想IPアドレスのハッシュ値を算出し、パケット転送ノード3のIPアドレスとハッシュ値とを、DHTネットワークを構成するパケット集約ノード2またはパケット転送ノード3のDHT記憶部22(33)内の分散ハッシュテーブルに登録する処理を行う(ステップS430)。具体的には、以下のような“put”コマンドを実行する。なお、(a)はハッシュ値を示し、(b)はパケット転送ノードのIPアドレスを示す。
put <(a)> <(b)>
put <(a)> <(b)>
また、DHT管理部32は、サーバ1の仮想IPアドレスと実IPアドレスとを組にしてサーバ記憶部35に登録する(ステップS440)。
以下、ステップS430においてパケット転送ノード3のIPアドレスとサーバ1の仮想IPアドレスのハッシュ値のペアを分散ハッシュテーブルに登録する処理の詳細を説明する。DHT管理部32は、サーバ1の仮想IPアドレスのハッシュ値をKeyとして管理すべきノードを検索する処理を行う。図14に示すDHTネットワークにおいて、ノード0が検索を行う例を示す。サーバ1の仮想IPアドレスのハッシュ値が12であるとすると、DHT管理部32は、前述したnext関数によりnext(12)=13であるため、目的の情報を管理すべきノードがノード13であることを求める。これに基づき、DHT管理部32は、パケット転送ノード3のIPアドレスとサーバ1の仮想IPアドレスのハッシュ値のペアを含み、ノード13の検索を依頼するメッセージを生成し、中継部30に渡す。
前述したFingertableの定義より、ノード0のFingertableに保持されるノードIDは、2(i=0,1[z=1,2])、6(i=2[z=4])、9(i=3[z=8])となる。ノード13のノードIDである13に関して、23<13<24であることから、ノード0は、i=3[z=8]のときのノードIDに対応するノード9にノード13の検索を依頼する。すなわち、中継部30はノード9宛てに上記のメッセージを送信する。
ノード9のFingertableに保持されるノードIDは、11(i=0,1[z=10,11])、13(i=2[z=13])、2(i=3[z=1])であることから、ノード9はノード13の情報を保持している。したがって、ノード9からノード13に、ノード0からのメッセージが転送される。ノード13において中継部20(30)はメッセージを受信し、DHT管理部21(32)に渡す。DHT管理部21は、メッセージに含まれるパケット転送ノード3のIPアドレスとサーバ1の仮想IPアドレスのハッシュ値をDHT記憶部22(33)に設定する。
このように、DHTネットワークでは、はじめに大まかな検索を行い、検索対象に近づくに従って、徐々に細かい検索を行うことで、DHTネットワークを構成しているノードから隣接するノードを順番に辿る場合よりも効率的な検索を実現している。上記のようにして、パケット転送ノード3のIPアドレスとサーバ1の仮想IPアドレスのハッシュ値のペアが、DHTネットワークを構成するパケット集約ノード2またはパケット転送ノード3によって管理されるようになる。
図7は、サーバ1の公開停止時のシーケンスを示している。パケット転送ノード3のサーバ公開部31は、サーバ1からの明示的なVPN接続の解除通知あるいは障害等によるVPN接続の解除を検知することにより、VPN接続が切断されたことを検知し、DHT管理部32に通知する(ステップS500)。
DHT管理部32は、サーバ公開部31から通知を受けると、切断されたVPN接続の接続相手であるサーバ1の仮想IPアドレスと自身のIPアドレスのペアを分散ハッシュテーブルから削除するため、VPN接続を解除したサーバ1の仮想IPアドレスのハッシュ値をKeyとして管理しているノードを検索する処理を行う(ステップS510)。このとき、ステップS430の処理と同様にして検索が行われ、所望のノードにメッセージが転送される。メッセージを受信したノードにおいてDHT管理部21(33)は、メッセージに含まれるハッシュ値と一致するハッシュ値およびそれと関連付けられているパケット転送ノード3のIPアドレスを分散ハッシュテーブルから削除する。
次に、サーバ1とクライアント5との通信について説明する。図8は、クライアント5がサーバ1と通信を行う際のシーケンスを示している。クライアント5は、例えばDNSサーバにサーバ1の名前解決を依頼し、その結果としてDNSサーバからサーバ1のIPアドレスを通知されることにより、サーバ1の仮想IPアドレス(IP_virtual)を取得することが可能である。クライアント5のクライアントアプリケーション50は、クライアント5(IP_client)を送信元とし、サーバ1(IP_virtual)を宛先とするパケットを送信する(ステップS600)。パケット集約ノード2がIP_virtual宛ての経路を広告していることにより、クライアント5から送信されたパケットはクライアント5に最も近いパケット集約ノード2に到着する。
パケット集約ノード2の中継部20は、クライアント5からのパケットを受信し、受信したパケットに含まれるサーバ1の仮想IPアドレス(IP_virtual)をDHT管理部21に通知する。DHT管理部21は、この仮想IPアドレス(IP_virtual)のハッシュ値を算出し、このハッシュ値をKeyとして管理しているノードを検索する処理を行う(ステップS610)。
このとき、ステップS430の処理と同様にして検索が行われ、所望のノードにメッセージが転送される。メッセージを受信したノードにおいてDHT管理部21(33)は、メッセージに含まれるハッシュ値と一致するハッシュ値を分散ハッシュテーブルから検索し、一致したハッシュ値と関連付けられているパケット転送ノード3のIPアドレスを取得する。DHT管理部21(33)は、取得したIPアドレスを通知するための応答メッセージを生成し、中継部20(30)に渡す。中継部20(30)は、検索を要求したパケット集約ノード2へ応答メッセージを送信する。検索を要求したパケット集約ノード2において中継部20はこの応答メッセージを受信し、所望のパケット転送ノード3のIPアドレスを取得する。
中継部20は、クライアント5から受信したパケットをカプセル化する(ステップS620)。このカプセル化では、クライアント5からのパケットに対してIPヘッダが付加される。このIPヘッダには、送信元のIPアドレスとしてパケット集約ノード2のIPアドレス(Rc)が記録され、宛先のIPアドレスとしてパケット転送ノード3のIPアドレス(Rs)が記録されている。したがって、クライアント5(IP_client)を送信元としサーバ1(IP_virtual)を宛先とするパケットが、カプセル化によって、パケット集約ノード2(Rc)を送信元としパケット転送ノード3(Rs)を宛先とするパケットに変換される。中継部20は、カプセル化したパケットをパケット転送ノード3へ送信する(ステップS630)。
パケット転送ノード3の中継部30は、パケット集約ノード2からのパケットを受信し、カプセル解除する(ステップS640)。このカプセル解除では、パケット集約ノード2でパケットに付加されたIPヘッダが除去される。したがって、パケット集約ノード2(Rc)を送信元としパケット転送ノード3(Rs)を宛先とするパケットが、カプセル解除によって、クライアント5(IP_client)を送信元としサーバ1(IP_virtual)を宛先とするパケットに変換される。
続いて、中継部30は、パケットに含まれるサーバ1の仮想IPアドレス(IP_virtual)をキーにしてサーバ記憶部35内の情報を検索し、サーバ1の仮想IPアドレス(IP_virtual)に対応する実IPアドレス(IP_real)を取得する(ステップS650)。さらに、中継部30は、ステップS640でカプセル解除したパケットをカプセル化する(ステップS660)。このカプセル化では、送信元のIPアドレスとしてパケット転送ノード3のIPアドレス(Rs)が記録され、宛先のIPアドレスとしてサーバ1の実IPアドレス(IP_real)が記録されたIPヘッダが付加される。したがって、カプセル解除されたパケットが、カプセル化によって、パケット転送ノード3(Rs)を送信元としサーバ1(IP_real)を宛先とするパケットに変換される。中継部30は、カプセル化したパケットをサーバ1へ送信する(ステップS670)。
サーバ1のサーバアプリケーション10はパケット転送ノード3からのパケットを受信し、適宜処理する(ステップS680)。なお、受信されたパケットは、ミドルウェアによってカプセル解除される(図示せず)。サーバアプリケーション10は、クライアント5への応答パケットをパケット転送ノード3へ送信する(ステップS690)。この応答パケットは、サーバ1(IP_virtual)を送信元としクライアント5(IP_client)を宛先とするパケットに対して、カプセル化により、サーバ1(IP_virtual)を送信元としパケット転送ノード3(Rs)を宛先とするIPヘッダが付加されたものである。
パケット転送ノード3の中継部30はサーバ1からのパケットを受信し、カプセル解除する(ステップS700)。このカプセル解除によって、サーバ1からのパケットは、サーバ1(IP_virtual)を送信元としクライアント5(IP_client)を宛先とするパケットに変換される。中継部30は、カプセル解除したパケットをクライアント5へ送信する(ステップS710)。
次に、本実施形態におけるサーバ1に対する攻撃の検知と防御について説明する。サーバ1宛てのパケットは、そのサーバ1を収容する仮想セグメントを構成するパケット転送ノード3によってサーバ1へ転送されるので、パケット転送ノード3においてサーバ1へのトラヒックを把握することが可能となる。図9は、攻撃の検知と防御に関するパケット集約ノード2とパケット転送ノード3と監視ノード6の機能構成を示している。
パケット集約ノード2は、前述した中継部20を有する。中継部20は、パケットの送信および受信を行う送受信部20aと、パケット転送ノード3から通知されるフィルタリングルールを中継部20に設定するフィルタリング設定部20bと、パケット転送ノード3から通知されるフィルタリングルールに従ってパケットを削除するフィルタリング部20cとを有する。
パケット転送ノード3は、前述した中継部30と、ログ記憶部36と、攻撃検知部37とを有する。中継部30は、パケットの送信および受信を行う送受信部30aと、サーバ1に中継したパケットの情報をログに記録するログ記録部30bとを有する。ログ記憶部36は、中継部30がサーバ1に中継したパケットの情報を含むログを記憶する。攻撃検知部37は、ログ記憶部36に記憶されているログに基づいて攻撃を検知する。
監視ノード6は、送受信部60と、ノード記憶部61と、ログ記憶部62と、ログ解析部63と、表示部64とを有する。送受信部60は、複数のパケット転送ノード3から送信されたログを受信する。ノード記憶部61は、管理ノード4から通知されたノードのIPアドレスを記憶する。ログ記憶部62は、送受信部60によって受信された各パケット転送ノード3のログを記憶する。ログ解析部63は、ログ記憶部62に記憶されているログを解析する。表示部64は、ログの解析結果を表示する。
図10は、サーバ1に対する攻撃の検知と防御時のシーケンスを示している。パケット転送ノード3においてログ記録部30bは、送受信部30aがパケット集約ノード2からのパケットをサーバ1に中継した際に、そのパケットからIPアドレス等の情報を取得し、ログ記憶部36内のログに追加する。図11は、1パケット分のログの構造を示している。パケット集約ノード2でカプセル化されたパケットに付加されているIPヘッダの情報と、カプセル解除したパケットのIPヘッダから、パケットを送信したクライアント5のIPアドレス、パケットの宛先であるサーバ1の仮想IPアドレス、パケットを中継したパケット集約ノード2のIPアドレスを取得することができる。これらとパケット転送ノード3のIPアドレスがログに記録される。
攻撃検知部37はログ記憶部36内のログに基づいて、パケット集約ノード2からサーバ1へのトラヒックに関して、攻撃が発生したか否かの判定を定期的に行う(ステップS800)。より具体的には、攻撃検知部37は、時刻とサーバ1の仮想IPアドレスとパケット集約ノード2のIPアドレスとを組としてログから取得し、ログから取得した情報を時系列に整列する。図12は、時系列に整列した情報の一例である。時刻中の「h1」等の文字は、時・分・秒に係る任意の数値を示している。また、複数の同じ文字が同じ数値を示すとは限らない。サーバ1の仮想IPアドレスおよびパケット集約ノード2のIPアドレス中の「サーバA」や「パケット集約ノードX」は実際にはサーバ1の仮想IPアドレスやパケット集約ノード2のIPアドレスである。図11では、内容を理解しやすくするため、IPアドレスをサーバ等の名称に置き換えている。
攻撃検知部37は、サーバ1の仮想IPアドレスとパケット集約ノード2のIPアドレスとの双方が同一のものを攻撃検知の単位としてパケット数(トラヒック量)を集計し、1秒当たりのパケット数を算出する。一例として、1秒当たりのパケット数が10未満であった場合、攻撃検知部37は攻撃が発生していないと判定し、1秒当たりのパケット数が10以上であった場合、攻撃検知部37は攻撃が発生していると判定する。図12では、パケット集約ノードYによって中継されたサーバAへのトラヒックが攻撃として検知される。上記の攻撃検知方法によれば、サーバ1へのパケットを中継するパケット集約ノード2毎にサーバ1へのトラヒックの監視と攻撃の検知を行うことができる。
攻撃を検知した場合、攻撃検知部37は、攻撃を検知したトラヒックに係るパケットを転送したパケット集約ノード2に対して、サーバ1の仮想IPアドレス宛てのパケットを削除するフィルタリングルールを通知する情報を生成し、中継部30に通知する。この情報には、サーバ1の仮想IPアドレスが含まれる。送受信部30aは、この情報を含むメッセージをパケット集約ノード2へ送信する(ステップS810)。図12に示す例では、パケット集約ノードYを経由するサーバAへのトラヒックが攻撃であると判定され、パケット集約ノードYに対して、サーバAの仮想IPアドレス宛てのパケットを削除するフィルタリングルールが通知される。
パケット集約ノード2において、送受信部20aはパケット転送ノード3からのメッセージを受信する。フィルタリング設定部20bは、メッセージに含まれるフィルタリングルールに従って、特定の仮想IPアドレス宛てのパケットを削除するようにフィルタリング部20cにフィルタリングの設定を行う(ステップS820)。これ以降、フィルタリング部20cは、送受信部20aがクライアント5から受信したパケットの宛先であるサーバ1の仮想IPアドレスが、ステップS820で設定された仮想IPアドレスと一致した場合に、クライアント5から受信したパケットを削除する。送受信部20aは、削除されたパケットを送信しない。
一方、監視ノード6の送受信部60は、ログの送信を要求するログ要求を、ノード記憶部61に記憶されている各ノードのIPアドレス宛てに送信する(ステップS830)。ログ要求は、DHTネットワークに加入しているパケット集約ノード2とパケット転送ノード3によって受信されるが、パケット転送ノード3のみが応答する。パケット転送ノード3の送受信部30aは、ログ記憶部36に記憶されているログを監視ノード6へ送信する(ステップS840)。監視ノード6の送受信部60は、複数のパケット転送ノード3からログを受信する。受信されたログはログ記憶部62に記憶される。ログ解析部63は、ログ記憶部62内のログを解析する(ステップS850)。
より具体的には、ログ解析部63は、時刻とサーバ1の仮想IPアドレスとパケット集約ノード2のIPアドレスとパケット転送ノード3のIPアドレスとを組としてログから取得し、ログから取得した情報を時系列に整列する。さらに、ログ解析部63は、サーバ1の仮想IPアドレスとパケット集約ノード2のIPアドレスとパケット転送ノード3のIPアドレスとの全てが同一のものを攻撃検知の単位としてパケット数(トラヒック量)を集計し、1秒当たりのパケット数を算出する。
図13は解析結果を示している。サーバ1の仮想IPアドレス、パケット集約ノード2のIPアドレス、およびパケット転送ノード3のIPアドレス中の「サーバA」や、「パケット集約ノードX」、「パケット転送ノードP」は実際にはサーバ1の仮想IPアドレスや、パケット集約ノード2のIPアドレス、パケット転送ノード3のIPアドレスである。図13では、内容を理解しやすくするため、IPアドレスをサーバ等の名称に置き換えている。
表示部64は、ログ解析部63が行った解析の結果を表示する(ステップS860)。このとき、例えば、ネットワークのトポロジと通信経路を視覚化し、パケット数に応じて通信経路を強調表示するなどの表示処理が行われる。これによって、管理者はネットワーク上の攻撃トラヒックの状況を把握することができる。
上述したように、本実施形態によれば、パケット転送ノード3において、パケット集約ノード2のIPアドレスおよびサーバ1の仮想IPアドレスを組としたトラヒックの到来方向(パケット集約ノード2からパケット転送ノード3への方向)毎にトラヒック量を把握することが可能となる。本実施形態では、非特許文献1に記載されている手法と比較して、多量のパケット集約ノード2およびパケット転送ノード3をネットワーク上に配置しなくてもよいので、ネットワーク上のトラヒック量の監視に係るコストを低減することができる。
また、非特許文献1に記載されたトレースバック技術を利用してパケット毎に追跡を行い、判明した各パケットの転送経路をもとにトラヒックの到来方向や量を知る手法では、専用のプログラムをルータ機器に組み込む必要があることから、トラヒック監視を実施する事業者は、自身が管理するルータ機器については、専用のプログラムを組み込むことによりルータ機器から情報を収集できるが、他の事業者が管理するルータ機器からは情報を収集できない。これに対して、本実施形態では、トラヒック監視を実施する事業者は、自身が管理するパケット集約ノード2とパケット転送ノード3を用いてトラヒックの監視が可能となる。また、攻撃パケットの送信者が送信元のIPアドレスを詐称する場合でも、パケット集約ノード2の位置に基づいて攻撃の到来方向を正確に把握することができる。
また、サーバ1は1つのパケット転送ノード3のみとVPN接続を確立するため、サーバが全ての中継端末とVPN接続を確立する手法(例えば、文献(磯原隆将、窪田歩、三宅優、“IPトレースバックを用いないDDoS攻撃防御手法の提案”、2009年3月、電子情報通信学会 総合大会)に記載の手法)を用いる場合よりもVPN接続を確立する処理負荷およびVPN接続の管理負荷を低減することができる。また、VPN接続の要求と確立がサーバ1とパケット転送ノード3との間で自律的に行われるため、1つの管理端末が全てのパケット転送ノード3の状態を管理し、サーバ1からVPN接続の要求を受けてパケット転送ノード3の情報を応答するような中央集権的な仕組みを必要としない。
また、サーバ1が接続されるパケット転送ノード3の上流側に複数のパケット集約ノード2を設けていることで、パケット転送ノード3において、パケットが到来する方向毎(パケット集約ノード2毎)にサーバ1へのトラヒックを監視することができる。さらに、パケット転送ノード3において攻撃が検知された場合に、攻撃に係るパケットが経由するパケット集約ノード2に対して、サーバ1の仮想IPアドレス宛てのパケットを削除するフィルタリングルールが通知され、パケット集約ノード2でフィルタリングが行われるので、攻撃に係るトラヒックを遮断することができる。このとき、他のパケット集約ノード2を経由し、攻撃が検知されなかった正常なトラヒックは遮断されない。
また、パケット集約ノード2とパケット転送ノード3が、分散ハッシュテーブルを利用したDHTネットワークを構成することによって、サーバ1とパケット転送ノード3との対応関係を管理する負荷をパケット集約ノード2とパケット転送ノード3間で分散することができる。
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
1・・・サーバ、2・・・パケット集約ノード、3・・・パケット転送ノード、4・・・管理ノード、5・・・クライアント、6・・・監視ノード、10・・・サーバアプリケーション、11,31・・・サーバ公開部、20,30・・・中継部、20a,30a,60・・・送受信部、20b・・・フィルタリング設定部、20c・・・フィルタリング部、21,32・・・DHT管理部、22,33・・・DHT記憶部、23,34・・・広告部、30b・・・ログ記録部、35・・・サーバ記憶部、36,62・・・ログ記憶部、37・・・攻撃検知部、40・・・仮想IPアドレス記憶部、41・・・アドレス管理部、42・・・設定情報記憶部、43・・・ノード管理部、44・・・ノードリスト記憶部、50・・・クライアントアプリケーション、61・・・ノード記憶部、63・・・ログ解析部、64・・・表示部
Claims (4)
- 実IPアドレスおよび仮想IPアドレスを有するサーバと、通信端末から前記サーバ宛てに送信されるパケットを中継する複数の第1の中継端末と、前記第1の中継端末によって中継されたパケットを受信し、前記サーバとの間で確立されたVPN接続により前記サーバへパケットを送信する複数の第2の中継端末とを備えた通信システムであって、
前記第1の中継端末は、
前記通信端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスを宛先とするパケットを受信する第1の受信手段と、
前記第1の受信手段によって受信されたパケットをカプセル化によって、前記第1の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する前記第2の中継端末のIPアドレスを宛先とするパケットに変換する第1の変換手段と、
前記第1の変換手段によってカプセル化されたパケットを送信する第1の送信手段とを有し、
前記第2の中継端末は、
前記第1の中継端末からのパケットを受信する第2の受信手段と、
前記第2の受信手段によって受信されたパケットをカプセル解除によって、カプセル化される前のパケットに変換し、変換後のパケットをカプセル化によって、前記第2の中継端末のIPアドレスを送信元とし、前記サーバの仮想IPアドレスに対応する実IPアドレスを宛先とするパケットに変換する第2の変換手段と、
前記第2の変換手段によってカプセル化されたパケットを送信する第2の送信手段と、
前記第2の変換手段によってカプセル解除されたパケットから前記第1の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを取得する取得手段と、
前記取得手段によって取得された前記第1の中継端末のIPアドレスおよび前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第1の検知手段とを有し、
前記サーバは、前記第2の中継端末からのパケットを受信する第3の受信手段を有する
ことを特徴とする通信システム。 - 前記第1の検知手段はさらに、検知したトラヒック量に基づいて、前記第1の中継端末から前記サーバへのトラヒック毎に攻撃を検知することを特徴とする請求項1に記載の通信システム。
- 前記第1の中継端末はさらに、
前記第1の受信手段によって受信されたパケットの宛先が、前記第2の中継端末から通知される前記サーバの仮想IPアドレスと一致するパケットを削除するフィルタリング手段を有し、
前記第1の受信手段はさらに、前記サーバの仮想IPアドレスを通知する情報を前記第2の中継端末から受信し、
前記第2の送信手段はさらに、前記第1の検知手段によって攻撃が検知された場合に、攻撃が検知されたトラヒックに係るパケットを中継した前記第1の中継端末に対して、攻撃が検知されたトラヒックに係る前記サーバの仮想IPアドレスを通知する情報を送信する
ことを特徴とする請求項2に記載の通信システム。 - 前記通信システムはさらに、前記第2の中継端末が中継したパケットの情報を記録したログを解析するログ解析装置を備え、
前記第2の中継端末はさらに、
前記サーバへ送信されたパケットの情報をログとして記憶するログ記憶手段を備え、
前記第2の送信手段はさらに、前記ログの情報を前記ログ解析装置へ送信し、
前記ログ解析装置は、
前記第2の中継端末から前記ログの情報を受信する第4の受信手段と、
前記第4の受信手段によって受信された前記ログの情報に基づいて、前記第1の中継端末のIPアドレス、前記第2の中継端末のIPアドレス、および前記サーバの仮想IPアドレスを組としてトラヒック量を検知する第2の検知手段とを有する
ことを特徴とする請求項2または請求項3に記載の通信システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010059695A JP2011193379A (ja) | 2010-03-16 | 2010-03-16 | 通信システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010059695A JP2011193379A (ja) | 2010-03-16 | 2010-03-16 | 通信システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011193379A true JP2011193379A (ja) | 2011-09-29 |
Family
ID=44797818
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010059695A Pending JP2011193379A (ja) | 2010-03-16 | 2010-03-16 | 通信システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011193379A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113556580A (zh) * | 2019-06-10 | 2021-10-26 | 西安万像电子科技有限公司 | 数据传输方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004328307A (ja) * | 2003-04-24 | 2004-11-18 | Mitsubishi Electric Corp | 攻撃防御システム、攻撃防御制御サーバおよび攻撃防御方法 |
JP2006067078A (ja) * | 2004-08-25 | 2006-03-09 | Nippon Telegr & Teleph Corp <Ntt> | ネットワークシステムおよび攻撃防御方法 |
JP2008301024A (ja) * | 2007-05-30 | 2008-12-11 | Fuji Xerox Co Ltd | 仮想ネットワーク接続システム及び装置 |
WO2009041686A1 (ja) * | 2007-09-28 | 2009-04-02 | Nippon Telegraph And Telephone Corporation | ネットワーク監視装置、ネットワーク監視方法およびネットワーク監視プログラム |
JP2009117929A (ja) * | 2007-11-02 | 2009-05-28 | Nippon Telegr & Teleph Corp <Ntt> | 不正アクセス監視装置およびその方法 |
-
2010
- 2010-03-16 JP JP2010059695A patent/JP2011193379A/ja active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004328307A (ja) * | 2003-04-24 | 2004-11-18 | Mitsubishi Electric Corp | 攻撃防御システム、攻撃防御制御サーバおよび攻撃防御方法 |
JP2006067078A (ja) * | 2004-08-25 | 2006-03-09 | Nippon Telegr & Teleph Corp <Ntt> | ネットワークシステムおよび攻撃防御方法 |
JP2008301024A (ja) * | 2007-05-30 | 2008-12-11 | Fuji Xerox Co Ltd | 仮想ネットワーク接続システム及び装置 |
WO2009041686A1 (ja) * | 2007-09-28 | 2009-04-02 | Nippon Telegraph And Telephone Corporation | ネットワーク監視装置、ネットワーク監視方法およびネットワーク監視プログラム |
JP2009117929A (ja) * | 2007-11-02 | 2009-05-28 | Nippon Telegr & Teleph Corp <Ntt> | 不正アクセス監視装置およびその方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113556580A (zh) * | 2019-06-10 | 2021-10-26 | 西安万像电子科技有限公司 | 数据传输方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5255653B2 (ja) | エニーキャストを介したマップレスグローバルトラフィック負荷のバランシング | |
US20050207349A1 (en) | System and method for measuring quality of communication | |
JP2015520959A (ja) | 情報中心ネットワークにおける名前ベースの近隣探索及びマルチホップサービス探索 | |
JP2008505531A (ja) | マルチドメイン仮想プライベートネットワークにおける接続経路の高速判定方法 | |
JP5949035B2 (ja) | ネットワーク機器設定装置、設定システム、設定方法及び設定プログラム | |
WO2013189414A2 (zh) | 网络拓扑自动获取方法及系统、网络查询及管理系统 | |
US8612626B2 (en) | Group member detection among nodes of a network | |
KR20130080626A (ko) | 컨텐츠 중심 네트워크를 위한 도메인들 간의 라우팅 방법 및 컨텐츠 중심 네트워크 | |
CN109802879A (zh) | 一种数据流路由方法及装置 | |
JP4391960B2 (ja) | リソース管理装置、システムおよび方法 | |
JP4344336B2 (ja) | マルチホーミング認証通信システム、マルチホーミング認証通信方法、および管理サーバ | |
CN102316004B (zh) | 在通信网络中用于确定节点间路由信息的方法及装置 | |
JP2011055236A (ja) | 通信システム、マッピング情報通知装置、マッピング情報通知方法及びプログラム | |
JP2012186519A (ja) | 通信システム | |
JP2011193379A (ja) | 通信システム | |
JP5726302B2 (ja) | トポロジサーバを用いた、通信アーキテクチャにわたって分散されたノードのネットワークに対する秘密または保護されたアクセス | |
JP5440574B2 (ja) | ノード装置、情報通信方法及びプログラム | |
JP2011193378A (ja) | 通信システム | |
JP5673268B2 (ja) | 通信装置、およびプログラム | |
JP2014068171A (ja) | マルチキャスト配信システム、マルチキャスト配信方法およびプログラム | |
JP2012186520A (ja) | 通信システム | |
JP2005244880A (ja) | 情報転送装置、情報転送システム及び情報転送方法 | |
JP2019049950A (ja) | 通信装置及び通信方法 | |
JP2012253681A (ja) | 通信ネットワークシステム | |
JP2008206028A (ja) | 機能分散型通信装置、構成要素結合制御方法、およびプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120907 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20120910 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20131029 |