JP2009049592A - Ｉｐフロー計測回路およびｉｐフロー計測方法 - Google Patents

Abstract

【課題】フローテーブルを小さく保持しながら、必要な情報のみ詳細にトラヒックフローモニタリングを行うことができるＩＰフロー計測回路およびＩＰフロー計測方法を提供する。
【解決手段】到着するＩＰパケット中の任意のデータを第１検索キー情報として抽出し、該第１検索キー情報と任意のデータを組として第２の検索キー情報を抽出するキー情報抽出部と、第１検索キー情報毎に、該第１検索キー情報を含むパケットが到着した回数を累積してカウントする累積カウンタと、第２検索キー情報を含むパケットが新規に到着した回数を累積してカウントする新規フローカウンタと、を格納するフローテーブルと、累積カウンタおよび新規フローカウンタのカウント動作を制御し、各カウント値と第１検索キー情報あるいは第２検索キー情報に基づいて異常トラヒックを検知する検索エンジンとを備える。
【選択図】図１

Description

本発明は、ＩＰ（Internet Protocol）ネットワークのトラヒックの状況把握をリアルタイムに可能とするトラヒックフローモニタリングなどのトラヒック計測技術に関する。

ＩＰネットワークのトラヒックを計測する技術に、流れる全てのパケットを取得し、膨大なパケットの情報をリアルタイムに解析するパケットキャプチャがある。パケットキャプチャは、到着するパケットの所属フローを識別するためのフローテーブルを備える。フローテーブルは、フロー毎に用意されたエントリとカウンタ、総パケット長からなる。

ＩＰパケットが到着するごとに、任意の監視フィールドの組合せからなる検索キーとフローテーブルに登録された何れかのフローエントリにマッチするかを比較し、一致するものはマッチ回数、総パケット長などの統計情報が更新される。比較の結果、任意の監視フィールドの組合せからなる検索キーがフローエントリにマッチしない場合には、検索キーがフローテーブルにフローエントリとして追加される。

フローテーブルにある、情報を参照することによりフロー毎のトラヒックを計測する。

近年、上記の処理をパケットヘッダの処理に特化したハードウェア（ネットワークプロセッサ）で行い、処理性能を高めている。

また、ネットワークの高速化・大容量化に対応するため、トラヒック計測をサンプリングにより行う技術が知られている。サンプリング技術は、特定の割合で取得したサンプルパケットの情報を統計学的手法により分析を行い、トラフィック情報を生成する技術である。

フロー統計情報の収集方式として、IP Flow Information eXport（ＩＰＦＩＸ）やPacket Sampling（Ｐｓａｍｐ）などThe Internet Engineering Task Force（ＩＥＴＦ）のRequest For Comments（ＲＦＣ）に記載されたフロー統計技術が知られている。上述の技術については、下記の非特許文献１、２を参照されたい。
http://www.ietf.org/html.charters/ipfix-charter.html http://www.ietf.org/html.charters/psamp-charter.html

このトラヒック計測技術において、従来の問題点は以下のようである。

パケットキャプチャにおいて、一般に、フロー識別を識別するには、同一コネクション上を流れるパケットの集合を１つのフローと考えるのが適当である。したがって、フロー識別情報を、送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル種別、送信元ポート番号、宛先ポート番号とした場合、１００ビット以上となる。このような、多数ビット情報を検索キーとしてフローテーブルに全てのフローを保持すると、フロー情報の精度は高まる一方、最大フロー数×最大カウンタ長の大きなテーブルの領域を消費してしまい高価となってしまう。

さらに、近年ネットワークレイヤの情報の他に、アプリケーションレイヤの情報も識別したマルチレイヤモニタリングのトラヒック計測を求められており、ますます検索キーのビットが多くなる。このため、フローテーブルに保持するフローも増加してしまい、所要メモリ量と処理時間が線形に増加し、大容量・高速リンクでの適用が困難となる。

サンプリング技術を用いて、ＤｏＳ攻撃（Denial of Service attack）など少数のフロー（エレファントフロー）が全体のトラヒック流量の大部分を占めるような異常トラヒックの原因となる端末を特定しようとした場合、サンプル数はフローレートに比例する。このため、サンプリング技術は高いレートのフローを特定する誤差が少ないため有効性を期待できる。

しかし、ワームや機械的不完了呼（ワンギリ）や電番スキャンなど、単位時間に多くの新規端末と通信をしようとする性質のものは、生成する個々のフローが小さいため、サンプリングされる確立が低く１パケットもサンプルされないフローが多数存在し、統計学に基づいた解析では精度よく攻撃端末を特定することは困難であるという問題がある。

サンプリング技術において生成する個々のフローが小さい場合においても、精度を高める方法として、フローレートが小さいパケットを特定し、特定したフローについてのみリアルタイムに収集する時間やサンプリングレートを変更することにより、この問題は回避できる。

しかしながら、フローレートが小さいものを特定するためには、フローテーブルに全てのフローを保持する必要があり、フロー数の増加に伴い所要メモリ量と処理時間が線形に増大するため、大容量リンクでの適用が困難であり、現実的でない。

本発明は、フローテーブルを小さく保持しながら、必要な情報のみ詳細にトラヒックフローモニタリングを行うことができるＩＰフロー計測回路およびＩＰフロー計測方法を提供することを目的とする。

本発明のＩＰフロー計測回路は、到着するＩＰパケット中の任意のデータを第１検索キー情報として抽出し、該第１検索キー情報と任意のデータを組として第２の検索キー情報を抽出するキー情報抽出部と、
前記第１検索キー情報毎に、該第１検索キー情報を含むパケットが到着した回数を累積してカウントする累積カウンタと、前記第２検索キー情報を含むパケットが新規に到着した回数を累積してカウントする新規フローカウンタと、を格納するフローテーブルと、
前記累積カウンタおよび前記新規フローカウンタのカウント動作を制御し、各カウント値と前記第１検索キー情報あるいは前記第２検索キー情報に基づいて異常トラヒックを検知する検索エンジンとを備える。

この場合、検索エンジンは、第１検索キー情報を含まないパケットが到着した場合には、フローテーブルに到着したパケットの第１検索キー情報をエントリとして登録するとしてもよい。

また、検索エンジンは、累積カウンタと新規フローカウンタが保持するカウント数或いはバイト数について予め定められた閾値を超えたかを判定し、所定の時間後に閾値を超えなかった第１検索キー情報については、フローテーブルから削除するとしてもよい。

また、検索エンジンは、累積カウンタと新規フローカウンタが保持するカウンタ数或いはバイト数がフローテーブルの上位Ｎ番目以内かを判定し、上位Ｎ番目以外の第１検索キー情報については、フローテーブルから削除するとしてもよい。

また、検索エンジンは、フローテーブルから削除する第１検索キー情報についてはフラグを立て、所定時間後に、フラグが立てられたフローを削除するとしてもよい。

また、検索エンジンは、キー情報抽出部にて抽出される任意のキー情報を、適用するポリシーサービスの種類によりＩＰパケット中の任意データからさまざまなパラメータを指定するとしてもよい。

また、検索エンジンは、累積カウンタと新規フローカウンタのカウント結果に基づいて、前記累積カウンタの任意のキー情報や前記新規フローカウンタの任意のキー情報を変更するとしてもよい。

また、第２の検索キーを用いた新規フロー判定のための検索エンジンは、０に設定されたｎビットのハッシュ空間を持つｋ個のハッシュ値と２ⁿビットのビットマップを具備し、パケットが到着するごとに任意のキーを入力値としてｋ個の異なるハッシュ関数Ｈを用いたｋ個のハッシュ値を得、このｋ個のハッシュ値に対応するビットマップ上のビットを調べ、１つ以上０ビットが存在する場合に前記第２検索キー情報を含むパケットが新規に到着したと判断し、ｋ個のハッシュ値に対応するビットマップ上のビットを１ビットを設定するとしてもよい。

また、検索エンジンは、任意のキー情報に応じてフローテーブルに保持したカウンタ値に係数を掛けるとしてもよい。

本発明のＩＰフロー計測方法は、到着するＩＰパケット中の任意のデータを第１検索キー情報として抽出し、該第１検索キー情報と任意のデータを組として第２の検索キー情報を抽出するキー情報抽出ステップと、
前記第１検索キー情報を含むパケットが到着した回数を累積してカウントする累積カウントステップと、
前記第２検索キー情報を含むパケットが新規に到着した回数を累積してカウントする新規フローカウントステップと、
前記累積カウントステップおよび前記新規フローカウントステップにおける各カウント値に基づいて異常トラヒックを検知する検索ステップとを備える。

本発明によれば、フローテーブルを小さく保持しながら、ネットワークのリアルタイムの詳細なトラヒックフローモニタリングを行うことができるＩＰフロー計測回路および方法を提供することができる。

次に、本発明の実施例について図面を参照して説明する。

（第１実施例）
図１は、本発明による第１の実施例のＩＰフロー計測回路の構成を示すブロック図、図２は図１中のフローテーブル３の構成を示す図である。

本実施例は、キー情報抽出部１と、検索エンジン２と、フローテーブル３から構成され、フローテーブル３は、図２に示されるように、フロー識別キーと累積カウンタと新規フローカウンタとから構成されている。

キー情報抽出部１は、到着するＩＰパケットから任意のキー情報を抽出し、検索エンジン２へ送出する。検索エンジン２はキー情報抽出部１から送られてきたキー情報とフローテーブル３を構成するフロー識別キー及び図７に示されるように、ビットマップと比較する。

図３は本実施例のＩＰフロー計測回路の動作を示すフローチャートであり、以下に、図３を参照して本実施例のＩＰフロー計測回路の動作について説明する。

ＩＰパケットが到着すると、キー情報抽出部１は、到着したＩＰパケットから任意のキー情報を第１検索キー情報として抽出し（ステップＳ３０１）、検索エンジン２へ送出する。

検索エンジン２は、キー情報抽出部１から送られてきた第１検索キー情報とフローテーブル３を構成するフロー識別キーとを比較し、一致するものの有無を確認する（ステップＳ３０２）。

ステップＳ３０２において、一致するものが有ることが確認された場合には、これを所属フローとして累積カウンタのカウント値を１つインクリメントする（ステップＳ３０３）。ステップＳ３０２において、一致するものがないことが確認された場合には、第１検索キー情報をフロー識別キーとしてフローテーブルに登録する（ステップＳ３０５）。

検索エンジン２のステップＳ３０２における動作としては、図２に示したフローテーブル３を構成するフロー識別キーと到着したＩＰパケットから抽出した任意のキー情報との一致確認（exact match）を行う。例えば、フロー識別キーを送信元ＩＰアドレスとした場合、１９２．１６８．１０．１のパケットが初めて到着した場合、すなわち、テーブルに存在しないＩＰアドレスを持ったパケットが到着した場合には、これをフロー識別キーとしてあらたなフローテーブル３を生成し、以降、１９２．１６８．１０．１が到着する度に累積カウンタをインクリメントする。また、このフローテーブル３は一定時間でリセット（クリア）される。

図２に示す例では、送信元ＩＰアドレス１９２．１６８．１０．１のパケットのある単位時間当たりのレートが１００であることがわかる。

本実施例においては、上述した第１検索キー情報に基づく動作と平行して、第２検索キーに基づく動作が行われる。

ＩＰパケットが到着すると、キー情報抽出部１は、新規フローカウンタでの識別として、第１検索キー情報と任意のキー情報を組とした第２検索キー情報として抽出し（ステップＳ３０６）、検索エンジン２へ送出する。

検索エンジン２は、キー情報抽出部１から送られてきた第２検索キー情報が、図７記載のビットマップにあるかを確認することにより新規フローであるかの判定を行い（ステップＳ３０７）、新規フローである場合は、累積カウンタで指定したキー（第１検索キー情報）に対応する新規フローカウンタのカウント値を１つインクリメントする（ステップＳ３０８）。ステップＳ３０７において、一致するものがあることが確認された場合には終了する。

検索エンジン２の具体的な動作例として、例えば、第１検索キー情報を宛先ＩＰアドレス、第２検索キー情報を宛先ＩＰアドレスと送信元ＩＰアドレスの組として説明する。

宛先ＩＰアドレスが１９２．１６８．１０．１で送信元ＩＰアドレスが１０．１．１．１のパケットが初めて到着した場合、ステップＳ３０２において、フローテーブルに一致するものがないことが確認され、第１検索キー情報である１９２．１６８．１０．１をフロー識別キーとしてフローテーブル３に登録し、累積カウンタの値を１とする。また、同時にステップS３０７において、第２検索キー情報である１９２．１６８．１０．１と１０．１．１．１の組からなるキーを入力値としてビットマップを用いた検索により新規フローと判定され、フローテーブルのフロー識別キーが１９２．１６８．１０．１の新規フローカウンタ値を１とし、第２検索キー情報である１９２．１６８．１０．１と１０．１．１．１の組からなるキーを入力値としてｋ個の異なるハッシュ関数Ｈを用いたｋ個のハッシュ値に対応するビットマップ上にビットを１ビット設定し登録する。

以降、宛先ＩＰアドレスが１９２．１６８．１０．１で送信元ＩＰアドレスが１０．１．１．１のパケットが再び受信された場合、ステップＳ３０２において、フローテーブル３に一致するものがあることが確認され、フローテーブル３のフロー識別キーが１９２．１６８．１０．１に対応する累積カウンタの値がインクリメントされる。しかし、ステップＳ３０７において、第２検索キー情報である１９２．１６８．１０．１と１０．１．１．１の組からなるキーを入力値としてビットマップを用いた検索により既に新規フローとして識別されているため、新規フローと判定されない。このため、フローテーブル３のフロー識別キーが１９２．１６８．１０．１に対応する新規フローカウンタの値はインクリメントされない。

以降、宛先ＩＰアドレスが１９２．１６８．１０．１で送信元ＩＰアドレスが異なる場合には、累積カウンタ、新規フローカウンタはともにインクリメントされる。

図２に示す例では、宛先ＩＰアドレスが１９２．１６８．１０．１へ通信を行っている送信元ＩＰアドレスが１００あることがわかる。また、宛先ＩＰアドレスが１９２．１６８．２５５．１へ通信を行っている送信元ＩＰアドレスが１しかなく、ある送信元から宛先ＩＰアドレスが１９２．１６８．２５５．１に対して１００パケット送られたことが分かる。

検索エンジン２は、異常検知を行う異常検知部（不図示）を含む。異常検知部では、フローテーブルの累積カウンタ値と、新規フローカウンタの値と、第１検索キー情報の条件、第２検索キーの条件、を参照することにより、ＤｏＳ攻撃、或いはワームであるかなどの攻撃種別を判断できる。

例えば、累積カウンタの任意のキー情報として送信元ＩＰアドレス、新規フローカウンタの任意のキー情報として送信元ＩＰアドレスと送信先アドレスを組みとした場合、高レートトラヒックの送信元は単位時間当たりの累積カウンタの値を見ることにより検知でき、新規フローカウンタ数を見ることにより、送信元ＩＰアドレスにおける通信先の端末数に注目した異常トラヒック検知を行うことができる。

また、フローテーブルの累積カウンタ値と、新規フローカウンタの値と、第１検索キー情報の条件、第２検索キーの条件、を参照することにより、異常トラヒックを発生させている端末がＤｏＳ攻撃を行っている端末であるのか、ワームに感染した端末であるのか識別できる。

ＤｏＳ（Distributed Denial of Service）攻撃は、インターネット上で行われるサービスを妨害する攻撃であるため、あるサーバ等に対して大量のパケットを送信する。このため、第１検索キー情報を送信元ＩＰアドレス、第２検索キー情報を送信元ＩＰアドレスと宛先ＩＰアドレスの組とした場合、累積カウンタ値は大きな値であるが、新規フローカウンタ値は１といったような小さい値となる。

一方、ワームはより多くの端末に感染しようとする性質を持つため多数の宛先にパケットを送信する。このため、第１検索キー情報を送信元ＩＰアドレス、第２検索キー情報を送信元ＩＰアドレスと宛先ＩＰアドレスの組とした場合、累積カウンタ値も新規フローカウンタ値も大きい値となる。

図２に示した例では、第１検索キー情報にかかる送信元ＩＰアドレス１９２．１６８．１０．１の累積カウンタが１００で、新規フローカウンタも１００であることから、１００個の宛先アドレスに対して、送信元ＩＰアドレスが１００個のパケットの送信を行っていることがわかる。ワームはより多くの端末に感染しようとするため多数の宛先ＩＰアドレスにパケットを送信する特徴がある。このため、累積カウンタ値も新規フローカウンタ値も大きい値となる。

また、送信元ＩＰアドレス１９２．１６８．２５５．１が１個の宛先ＩＰアドレスに対して送信元ＩＰアドレスが１００個のパケットの送信を行っていることがわかる。ＤｏＳ攻撃は、インターネット上のサービスを妨害するため、ある特定ＩＰアドレスに対して大量のパケットを送信する特徴がある。このため、累積カウンタ値は大きなカウンタ値だが新規フローカウンタ値は小さい値となる。

ステップＳ３０３における累積カウンタのカウントアップ、ステップＳ３０８における新規フローカウンタのカウントアップの後には、検索エンジン２の異常検知部は各カウンタのカウント値を比較し、第１検索キー情報、第２検索キー情報の条件を参照することにより種々の攻撃を検知する。第１検索キー情報が送信元ＩＰアドレスで第２検索キー情報が送信元ＩＰアドレスと宛先ＩＰアドレスである場合、累積カウンタ値が予め定められた第１の閾値以上であり、新規フローカウンタ値が予め定められた第２の閾値以下である場合にはＤｏＳ攻撃であると判断する。また、累積カウンタ値が予め定められた第３の閾値以上であり、新規フローカウンタ値が予め定められた第４の閾値以上である場合にはワームによる攻撃であると判断する。

上記はＩＰパケットヘッダを検索キーとした場合に、ネットワーク異常を検知する方法である。以降では、異常を検知したフローの内容に応じて、段階的にキー情報を変更して行き、より詳細なフロー情報を収集する方法について説明する。ここでは、アプリケーションレイヤの情報であるＩＰ電話の電話番号を検索キーとした場合を説明する。

図４はＩＰ電話で発生する機械的不完了呼（ワンギリ）を示す図である。ワンギリはより多くの電話に接続しようとするため、多数の宛先にパケットを送信する。例えば、第１検索キー情報を宛先ＩＰアドレスとした場合、図５に示すフロー識別キー１９２．１６８．１０．１について分析を行い、累積カウンタが大きい値で、新規フローカウンタが小さい値なので、１９２．１６８．１０．１に対してＤｏＳ攻撃が発生していることが分かる。その後、どのようなＤｏＳ攻撃が発生しているかについてより詳細な情報を取得するために、フローの内容に応じて、段階的に送信元ＩＰアドレスやＬ４ポート番号、アプリケーションレイヤの情報であるＩＰ電話の電話番号などを追加し、キー情報を変更して行く。これによりきめ細かな情報を取得するとともにフローテーブルの増大を防ぐことができる。

以降では、第１検索キー情報を宛先ＩＰアドレス、第２検索キー情報を宛先ＩＰアドレス、送信元ＩＰアドレスとした場合に、１９２．１６８．１０．１に対するＤｏＳ攻撃であると判明し、該当ＩＰアドレスはＳＩＰ（Session Initiation Protocol）サーバであったとする。

より詳細な情報を収集するために、第１検索キー情報として宛先ＩＰアドレス１９２．１６８．１０．１とＩＰ電話の発信電話番号（From）を組とし、第２検索キー情報として宛先ＩＰアドレス１９２．１６８．１０．１とＩＰ電話の着信電話番号（To）とＩＰ電話の発信電話番号（From）を組として図６におけるステップＳ４０９によりキー情報を変更する。その結果、図５に示すようなフロー識別キー１９２．１６８．１０．１と、０５０１２３４５６７の累積カウンタ値が４００で、新規フローカウンタ値が４００の結果が得られたとする。

第１検索キー情報は宛先ＩＰアドレス１９２．１６８．１０．１とＩＰ電話の発信電話番号（From）が組とされているため、０５０１２３４５６７はＩＰ電話の発信電話番号を指しており、０５０１２３４５６７の電話番号から４００台の電話機に対して電話をかけているワンギリが発生していることが分かる。このことから、１９２．１６８．１０．１に対するＤｏＳ攻撃検知だけでなく、０５０１２３４５６７の電話番号がワンギリを行っていることも検知できる。

なお、検索エンジン２に、累積カウンタと新規フローカウンタが保持するカウント数或いはバイト数について、所定の閾値を超えたかを判定し、所定の時間後に閾値を超えなかったフローについては、フローテーブル３から削除するエージング手段を備えることとしてもよい。

上記のエージング手段は、フローテーブルから削除することを、削除するフローについてはフラグを立て、所定時間後に、フラグが立てられたフローを削除することとしてもよい。

さらに、エージング手段は、累積カウンタと新規フローカウンタが保持するカウンタ数或いはバイト数がフローテーブル３の上位Ｎ番目以内かを判定し、上位Ｎ番目以外のフローについては、フローテーブル３から削除することとしてもよい。

これにより、ＩＰフロー計測回路によってトラヒックフローモニタリングされるフローのうち、特に高レートフロー、或いはフローの異なり数が多いものに絞り込むことができ、低いフローレートのもの、或いは、フローの異なり数が少ないものをフローテーブル３から削除することができ、フローテーブル３の規模が大きくなることを防ぐことができる。

上記のように構成される本実施例においては、トラヒックフローモニタリングにおいて、累積カウンタと新規フローカウンタの２つのカウンタからなるフローテーブルを持ち、新規フローを判定するステップを具備し新規フローと判断された場合にのみ、累積カウンタで指定したキーに対応する新規フローカウンタを増加させることで、ワームや機械的不完了呼（ワンギリ）や電番スキャンなど、単位時間に多くの新規端末と通信をしようとする性質の端末や、ＤｏＳ攻撃など少数のフロー（エレファントフロー）が全体のトラヒック流量の大部分を占めるような異常トラヒックの検知を行えることを特徴とする。

次に、異常検知部の結果に応じて累積カウンタの任意のキー情報や新規フローカウンタの任意のキー情報の変更を行う動作について詳細に説明する。図４は累積カウンタの任意のキー情報や新規フローカウンタの任意のキー情報の変更を行う際の検索エンジン２の動作を示すフローチャートである。

図６におけるステップＳ４０１〜Ｓ４０３、Ｓ４０５〜Ｓ４０８の動作は、図３に示したステップＳ３０１〜Ｓ３０３、Ｓ３０５〜Ｓ３０８の動作と同様である。

本実施例において、検索エンジン２の異常検知部は、ステップＳ４０４において累積カウンタのカウント値と、新規フローカウンタのカウント値と、第１検索キー情報、第２検索キー情報の条件を参照することにより、異常であるかを確認し、異常であると判断した場合にはキー情報抽出部１により抽出されるキー情報の変更を行う（ステップＳ４０９）。

これにより、任意のキー情報は、適用するポリシーサービスの種類により、ＩＰパケット中の任意データからさまざまなパラメータを指定することができる。このため、ＩＰパケットヘッダ（例えば、ＩＰヘッダであれば送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル種別、送信元ポート番号、宛先ポート番号）、だけでなく高位レイヤの情報を解析することができる。

すなわち、フロー識別子としてＳＩＰ（Session Initiation Protocol）のＭｅｔｈｏｄやＳＩＰ−ＵＲＩ（Uniform Resource Identifier）やＳＩＰヘッダにあるＦｒｏｍやＴｏの情報をフロー識別情報キーとしてネットワークのリアルタイムの状況把握を可能とするトラヒックフローモニタリングを行うことができる。

また、異常検知部によって得られる詳細調査対象について、任意のキー情報を変えることにより、より詳細なトラヒックフローモニタリングすることができる。

例えば累積カウンタの任意のキー情報をＳＩＰサーバなどの宛先ＩＰアドレス、新規フローカウンタの任意のキー情報として宛先ＩＰアドレスと送信元ＩＰアドレスの組からなるフロー識別情報キーが設定されていた場合、累積カウンタによりＳＩＰサーバ向けトラヒックが多いかが検知でき、新規フローカウンタによりある一端末が大量に電話をかけているのか、多くのユーザが一斉に電話をしたためなのかが分かる。さらに、詳細に分析を行いたい場合は、新規フローカウンタの任意のキー情報を宛先ＩＰアドレスと送信元ＩＰアドレスとＳＩＰヘッダにあるＴｏの組からなるフロー識別情報キーに変更することで、多くのユーザが一斉に電話をした場合において、それがある特定の番号宛に電話をしようとしている企画型輻輳なのか、通話先の電話番号もランダムな輻輳なのかが判別できる。このように、調査対象を絞り込んでから、詳細分析を行うためフローテーブルの増大を防ぐことができる。

図５に示した例によれば、累積カウンタの任意のキー情報をＳＩＰサーバなどの宛先ＩＰアドレス、新規フローカウンタの任意のキー情報として宛先ＩＰアドレスと送信元ＩＰアドレスの組からなるフロー識別情報キーが設定されていた場合、累積カウンタによりＳＩＰサーバ１９２．１６８．１０．１向けトラヒックが５００と多いものであることを検知することができ、新規フローカウンタが１であることから、ある一端末が大量に電話を掛けていることが分かる。

また、累積カウンタによりＳＩＰサーバ１９２．１６８．２５５．１向けトラヒックが８００と多いかが検知でき、新規フローカウンタが７５０であることから、多くのユーザが一斉に電話をしたことが分かる。

さらに、ＳＩＰサーバ１９２．１６８．２５５．１向けトラヒックについて詳細に分析を行いたい場合は、新規フローカウンタの任意のキー情報を宛先ＩＰアドレスと送信元ＩＰアドレスとＳＩＰヘッダにあるＴｏの組からなるフロー識別情報キーに変更する。

変更後、新規フローカウンタが１である場合は、ある特定の番号宛に電話をしようとしている企画型輻輳であると分かる。また、変更後、新規フローカウンタが８００など大きな値である場合は、通話先の電話番号もランダムな輻輳であると判定できる。このように、トラヒック異常検知手段によって得られる詳細調査対象について、任意のキー情報を変えることにより、より詳細なトラヒックフローモニタリングすることができる。また、調査対象を絞り込んでから、新規フローカウンタの任意のキー情報を変更することで、フローテーブルの増大を防ぐことができる。

次に、検索エンジン２において、ステップＳ３０７，Ｓ４０７にて行われるフローが新規フローであるかの確認動作について詳細に説明する。フローが新規フローであるかの確認はハッシュ関数を用いて行われる。

検索エンジン２は、図７に示すように、０に設定されたｎビットのハッシュ空間を持つｋ個のハッシュ値と、２ⁿビットのビットマップを具備している。

検索エンジン２は、図８に示すように、ＩＰパケットが到着するごとに任意のキーを入力値として、ｋ個の異なるハッシュ関数Ｈを用いたｋ個のハッシュ値を得る。このｋ個のハッシュ値に対応するビットマップ上のビットを調べ、１つ以上０ビットが存在する場合には新規のフローと判断する。ビットマップ上のビットを調べ、全て１ビットが存在する場合は、既に該当フローが存在すると判断し、新規のフローであるとは判断しない。

新規のフローと判断した場合には、検索エンジン２は、図９に示すように、ｋ個のハッシュ値に対応するビットマップ上のビットを１ビットを設定する。

上記の構成を備える本実施例においては、少ないメモリ量で、あるキーが既に存在するかを判定することが可能である。

なお、以上の説明において、任意のキー情報に応じてフローテーブルに保持した各カウンタのカウント値に係数を掛けることとしてもよい。これにより、例えば、あるキー情報が代表番号であるときは、累積カウンタと新規フローカウンタが大きな値として見えてしまう。このため、カウンタ値に０．１など係数を掛けることにより、誤検を緩和することができる。

本発明の実施例のＩＰフロー計測回路の構成を示すブロック図である。 図１中のフローテーブル３の構成を示す図である。 第１の実施例のＩＰフロー計測回路の動作を示すフローチャートである。 輻輳状態を示す図である。 図１中のフローテーブル３の構成を示す図である。 ＩＰフロー計測回路の動作を示すフローチャートである。 新規フローを判定する回路としての、０に設定されたｎビットのハッシュ空間を持つｋ個のハッシュ値と２ⁿビットのビットマップを示す図である。 図７に示した回路によるフローの新規性を判断する動作を示す図である。 図７に示した回路により、新規フローと判断された場合に、ｋ個のハッシュ値に対応するビットマップ上にビット設定する状態を示す図である。

符号の説明

１ キー情報抽出部
２ 検索エンジン
３ フローテーブル

Claims (10)

1. 到着するＩＰパケット中の任意のデータを第１検索キー情報として抽出し、該第１検索キー情報と任意のデータを組として第２の検索キー情報を抽出するキー情報抽出部と、
   前記第１検索キー情報毎に、該第１検索キー情報を含むパケットが到着した回数を累積してカウントする累積カウンタと、前記第２検索キー情報を含むパケットが新規に到着した回数を累積してカウントする新規フローカウンタと、を格納するフローテーブルと、
   前記累積カウンタおよび前記新規フローカウンタのカウント動作を制御し、各カウント値と前記第１検索キー情報あるいは前記第２検索キー情報に基づいて異常トラヒックを検知する検索エンジンとを備えるＩＰフロー計測回路。
2. 請求項１記載のＩＰフロー計測回路において、
   検索エンジンは、第１検索キー情報を含まないパケットが到着した場合には、フローテーブルに到着したパケットの第１検索キー情報をエントリとして登録するＩＰフロー計測回路。
3. 請求項１または請求項２記載のＩＰフロー計測回路において、
   検索エンジンは、累積カウンタと新規フローカウンタが保持するカウント数或いはバイト数について予め定められた閾値を超えたかを判定し、所定の時間後に閾値を超えなかった第１検索キー情報については、フローテーブルから削除するＩＰフロー計測回路。
4. 請求項１または請求項２記載のＩＰフロー計測回路において、
   検索エンジンは、累積カウンタと新規フローカウンタが保持するカウンタ数或いはバイト数がフローテーブルの上位Ｎ番目以内かを判定し、上位Ｎ番目以外の第１検索キー情報については、フローテーブルから削除するＩＰフロー計測回路。
5. 請求項３または請求項４記載のＩＰフロー計測回路において、
   検索エンジンは、フローテーブルから削除する第１検索キー情報についてはフラグを立て、所定時間後に、フラグが立てられたフローを削除するＩＰフロー計測回路。
6. 請求項１に記載のＩＰフロー計測回路において、
   検索エンジンは、キー情報抽出部にて抽出される任意のキー情報を、適用するポリシーサービスの種類によりＩＰパケット中の任意データからさまざまなパラメータを指定するＩＰフロー計測回路。
7. 請求項１に記載のＩＰフロー計測回路において、
   検索エンジンは、累積カウンタと新規フローカウンタのカウント結果に基づいて、前記累積カウンタの任意のキー情報や前記新規フローカウンタの任意のキー情報を変更するＩＰフロー計測回路。
8. 請求項１ないし請求項７のいずれかに記載のＩＰフロー計測回路において、
   第２の検索キーを用いた新規フロー判定のための検索エンジンは、０に設定されたｎビットのハッシュ空間を持つｋ個のハッシュ値と２ⁿビットのビットマップを具備し、パケットが到着するごとに任意のキーを入力値としてｋ個の異なるハッシュ関数Ｈを用いたｋ個のハッシュ値を得、このｋ個のハッシュ値に対応するビットマップ上のビットを調べ、１つ以上０ビットが存在する場合に前記第２検索キー情報を含むパケットが新規に到着したと判断し、ｋ個のハッシュ値に対応するビットマップ上のビットを１ビットを設定するＩＰフロー計測回路。
9. 請求項１ないし請求項８のいずれかに記載のＩＰフロー計測回路において、
   検索エンジンは、任意のキー情報に応じてフローテーブルに保持したカウンタ値に係数を掛けるＩＰフロー計測回路。
10. 到着するＩＰパケット中の任意のデータを第１検索キー情報として抽出し、該第１検索キー情報と任意のデータを組として第２の検索キー情報を抽出するキー情報抽出ステップと、
    前記第１検索キー情報を含むパケットが到着した回数を累積してカウントする累積カウントステップと、
    前記第２検索キー情報を含むパケットが新規に到着した回数を累積してカウントする新規フローカウントステップと、
    前記累積カウントステップおよび前記新規フローカウントステップにおける各カウント値に基づいて異常トラヒックを検知する検索ステップとを備えるＩＰフロー計測方法。

Images