JP6652912B2 - ネットワーク装置および異常検知システム - Google Patents

Description

本発明は、ネットワーク上装置および異常検知システムに関するものである。

インターネットセキュリティにおける重要な課題の１つは、Ｄｉｓｔｒｉｂｕｔｅｄ Ｄｅｎｉａｌ ｏｆ Ｓｅｖｉｃｅ ａｔｔａｃｋ（ＤＤｏＳ）攻撃を検出することである。特に近年、リソース消費型ＤＤｏＳと呼ばれる攻撃が出現している。一般的なＤＤｏＳが、大量のトラフィックを攻撃対象に送信することで回線帯域を圧迫させるのに対し、リソース消費型ＤＤｏＳでは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＨＴＴＰ）ヘッダを偽装した大きなデータを小さく分割した上で間隔を開けて攻撃対象に送信したり、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）のウインドウサイズを極端に小さくして攻撃対象に送信したりする。

これによりＴＣＰコネクションの接続時間を引き延ばし、攻撃対象となるサーバの接続コネクション数を消費して、サービス妨害する攻撃である。リソース消費型ＤＤｏＳは一見正常に見えるトラフィックが低レートで送信されてくるため、攻撃の識別が困難である。
リソース消費型ＤＤｏＳを検知するアプローチとして、ネットワーク上の通信装置でネットワーク統計を収集し、収集した統計を分析サーバで解析することで攻撃を検知する方法がある。

しかし、リソース消費型ＤＤｏＳは非常に低レートの攻撃であるため、ネットワーク統計を欠落させることなく網羅的に採取する必要がある。一方で、ネットワーク上のトラフィックを網羅的に採取すると、フロー統計を管理するフローテーブルのサイズが肥大化し、メモリの消費が課題となる。

メモリを効率的に使用しつつフローテーブルを管理する技術として、特許文献１に記載の技術がある。特許文献１では、指定されたフロー、もしくは参照頻度の高いフローの情報を容量の小さい高速なメモリに配置し、それ以外のフローを容量の大きな低速なメモリに配置することで、フローテーブルに関する処理を高速化しており、メモリを効率的に使用しつつフローを管理する技術が開示されている。

米国特許出願公開第２０１６／０１８２３７３号明細書

特許文献１に記載の技術では、メモリにおける配置の優先度が、フローそのものが指定されるか、フローの情報への参照頻度が多い順に決まる。そのため、リソース消費型ＤＤｏＳのように、フローをあらかじめ指定できず、かつトラフィック量が小さいため情報への参照頻度が低いフローの統計情報は、優先度が低くなり、フローテーブルがメモリの容量を圧迫した場合に欠落し、リソース消費型ＤＤｏＳを検知するための統計情報を収集できない可能性がある。

そこで、本発明の目的は、ネットワークの統計情報を記憶するメモリの容量が小さい場合であっても、攻撃の性質に応じた統計情報の収集を可能にすることにある。

本発明に係る代表的なネットワーク装置は、ネットワークの統計情報を管理するネットワーク装置であって、前記ネットワークからパケットを受信する受信部と、前記受信部が受信したパケットの統計情報を第１のテーブルのエントリ単位で管理し、前記第１のテーブルのエントリの置換ルールと、置換されるエントリの統計情報の送信条件を第２のテーブルで管理し、前記第２のテーブルで管理される置換ルールに基づいて前記第１のテーブルのエントリを置換し、前記第２のテーブルで管理される送信条件に基づいて前記第１のテーブルのエントリの統計情報を送信するよう制御する管理部と、を備えたことを特徴とする。

本発明によれば、ネットワークの統計情報を記憶するメモリの容量が小さい場合であっても、攻撃の性質に応じた統計情報の収集が可能になる。

実施例１におけるネットワークを含むシステムの構成の例を示す図である。 分析サーバ及びルータの構成の例を図である。 異常検知管理情報の例を示す図である。 トラフィック統計処理部の例を示す図である。 統計テーブルの例を示す図である。 実施例１におけるフローテーブルの第１の例を示す図である。 実施例１におけるフローテーブルの第２の例を示す図である。 実施例１におけるフローテーブルの第３の例を示す図である。 セットアソシエイティブのテーブルの例の例を示す図である。 実施例１におけるエントリ更新方法管理情報の第１の例を示す図である。 実施例１のシステムにおける動作シーケンスの例を示す図である。 エントリ更新のフローチャートの例を示す図である。 統計収集サーバを備えた例を示す図である。 実施例１におけるエントリ更新方法管理情報の第２の例を示す図である。 競合管理情報の例を示す図である。 実施例２におけるネットワークを含むシステムの構成の例を示す図である。 実施例２におけるフローテーブルの例を示す図である。 実施例２におけるエントリ更新方法管理情報の例を示す図である。 実施例２のシステムにおける動作シーケンスの例を示す図である。

（システムの構成）
実施例１におけるネットワークを含むシステムの構成の例を図１に示す。実施例１のシステムは、ネットワークに接続し通信を行う複数の端末１０（端末１０ａ、１０ｂ、１０ｎのそれぞれを区別することなく代表的に端末を指し示す場合に端末１０と記載し、他の符号も同じ記載とする）及びサーバ２０と、ネットワークに配置されたルータ１００と、ルータ１００に接続する分析サーバ２００を備える。

ルータ１００は、各ルータ１００を通過する端末１０及びサーバ２０のネットワークトラフィックの統計をフロー毎に収集し、分析サーバ２００に通知する。図１の例ではルータ１００ｃが分析サーバに接続されているため、ルータ１００ａ、１００ｂはルータ１００ｃを経由して分析サーバ２００に通知してもよい。また、ルータ１００ａ、１００ｂも図示を省略した回線を通じて分析サーバ２００に通知してもよい。

分析サーバ２００はルータ１００から通知された統計を蓄積して学習し、学習した値の範囲から外れた統計値を異常判定する。また、実施例１の構成では、分析サーバ２００は管理端末としても動作し、管理者は分析サーバ２００を介してルータ１００や分析サーバ２００のパラメータを設定することが可能である。ただし、分析サーバ２００と管理端末は必ずしも同一の機器に実装される必要はなく、別々の装置として配置されてもよい。

（分析サーバ２００及びルータ１００の構成）
分析サーバ２００及びルータ１００の構成の例を図２に示す。分析サーバ２００は、コレクタ処理部２２０と、異常検知部２１０と、入力部２３０を備える。コレクタ処理部２２０は、ルータ１００から送信される統計パケットを受信し、統計情報を蓄積する。入力部２３０は、管理端末としての動作し、管理者が入力したルータ１００と分析サーバ２００への設定情報を受け付け、分析サーバ２００内では異常検知部２１０への設定情報、ルータ１００への設定情報を通知する。

異常検知部２１０は、コレクタ処理部２２０により収集した統計情報を機械学習により解析し、正常な通信と攻撃の通信とを判定する。機械学習にはＳｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ（ＳＶＭ）、あるいはクラスタ解析などを用いてもよいが、これらの機械学習の内容は実施例１の特徴ではなく、一般的に知られ実施されているため、詳しい説明を省略する。また、異常検知部２１０は、異常検知の分析手段を管理するための異常検知管理情報１００１を保持する。

異常検知管理情報１００１の例を図３に示す。異常検知管理情報１００１は検知対象１０１１と検知条件１０１２の対応情報を持つ。検知対象１０１１には例えばリソース消費型ＤＤｏＳといった攻撃の種別が格納される。検知条件１０１２には、機械学習や異常判定に使用する統計情報の項目や、重み付けのパラメータが格納される。

管理者により、入力部２３０を介して検知対象１０１１に格納された種別のいずれかが指定され、異常検知部２１０は、指定された検知対象１０１１に対応する検知条件１０１２に従って、実行すべき異常検知の条件を設定する。

図３の例では、検知対象１０１１のリソース消費型ＤＤｏＳを検知するための検知条件１０１２として、後述するフローテーブルＡ、Ｂ、Ｃ（名称Ａ、Ｂ、Ｃで識別されるフローテーブル）の異なり数及びパケット送信間隔（ルータ１００でのパケットの受信間隔）が閾値以上のパケット数、統計の採取時間を機械学習の入力として使用することを示す。また、図３の例では、理解しやすいように言葉の説明で表現したが、実際の異常検知管理情報１００１は、それらの内容を表すプログラムであってもよいし、テーブルとして保持される値であって、それらの内容を表す特定の値であってもよい。

なお、これらの統計情報はリソース消費型ＤＤｏＳの検知に特に有効な統計情報の例であるが、他に機械学習の入力として、パケット数と、パケットサイズの合計と、ＴＣＰフラグのカウント数と、パケットサイズの分布と、パケットの送信間隔（受信間隔）の分布などの統計情報の中の１つまたは複数が検知条件１０１２として含まれてもよい。

図２に示した分析サーバ２００のコレクタ処理部２２０と、異常検知部２１０と、入力部２３０は、専用のハードウェアで実現されてもよいし、分析サーバ２００のコンピュータとしてのプロセッサのプログラムを実行する処理により実現されてもよい。また、専用のハードウェアと、プロセッサのプログラムを実行する処理との組み合わせにより実現されてもよい。

ルータ１００は、制御部１１０と、受信パケット処理部１２０と、検索処理部１６０と、ルーティングテーブル１７０と、送信パケット処理部１３０と、トラフィック統計処理部１４０と、統計テーブル１５０を備える。パケットを中継する一般的なルータの処理を含み、受信パケット処理部１２０は、入力ポートを経由してパケットを受信し、検索処理部１６０へとパケットのヘッダ情報を出力する。

検索処理部１６０は入力されたヘッダ情報を用いてルーティングテーブル１７０を検索し、ネクストホップと出力ポートを決定し、受信パケット処理部１２０へと通知する。受信パケット処理部１２０は、ネクストホップと出力ポート及びパケットを送信パケット処理部１３０へと出力する。

送信パケット処理部１３０は、パケットのＭｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）ヘッダと（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ＩＰヘッダのＴｉｍｅ Ｔｏ Ｌｉｖｅ（ＴＴＬ）などの書き換えを行い、決定された出力ポートからパケットを送信する。以上が一般的なルータとしての動作であるが、これら以外に一般的なルータの処理を含んでもよい。

制御部１１０は、ルーティングプロトコルに基づいて他のルータ１００とルーティングテーブル１７０の経路情報を交換したり、分析サーバ２００と通信して、管理者により入力された設定情報を受信したりする。そして、制御部１１０は、受信パケット処理部１２０、送信パケット処理部１３０、検索処理部１６０、トラフィック統計処理部１４０へ、管理者により設定される各種パラメータを変更する。

トラフィック統計処理部１４０は、受信パケット処理部１２０からパケットのヘッダ情報を入力し、入力されたヘッダ情報に基づいてトラフィックの統計情報を生成する。統計テーブル１５０は、トラフィック統計処理部１４０が生成した統計情報を後述するフローテーブルの形式で保持する。

トラフィック統計処理部１４０の例を図４に示す。トラフィック統計処理部１４０は、ヘッダ情報蓄積部１４２と、統計テーブル管理部１４３と、統計パケット生成部１４１を備える。各部の処理を実行するための各種パラメータは、制御部１１０を介してあらかじめ設定される。

ヘッダ情報蓄積部１４２は、パケットのヘッダ情報を受信パケット処理部１２０から受け取り、統計テーブル管理部１４３に出力する。統計テーブル管理部１４３は、後述するエントリ更新方法管理情報３００１を備え、ヘッダ情報蓄積部１４２から入力されたヘッダ情報とエントリ更新方法管理情報３００１に従って統計テーブル１５０を更新する。

統計テーブル１５０のエントリが統計パケット生成の条件を満たした場合、統計テーブル管理部１４３は、統計パケット生成部１４１へ条件を満たしたエントリの統計情報を出力する。統計パケット生成部１４１は、入力されたエントリの統計情報を送信するためのフォーマットに変換し、ルータ１００の送信パケット処理部１３０に出力する。

なお、統計パケットの送信先である分析サーバ２００のアドレス及び統計パケットを生成する条件は、管理者によって制御部１１０を介して事前に設定される。統計パケットを生成する条件の例として、統計情報に含まれる特定の項目に対する閾値や、統計情報を採取し始めてからの経過時間、統計情報が最後に更新されてからの経過時間などが設定されてもよい。

統計テーブル１５０の例を図５に示す。統計テーブル１５０は、トラフィックの統計情報をフロー毎に管理するためのフローテーブル５００１を少なくとも１つ以上備え、統計テーブル１５０に備えられたフローテーブル５００１は制御部１１０を介して管理者によってあらかじめ設定される。フローテーブル５００１ａにはＡ、フローテーブル５００１ｂにはＢ、フローテーブル５００１ｃにはＣ、フローテーブル５００１ｎにはＮというような名称（識別情報）が付けられる。

フローテーブル５００１の例を図６Ａ〜６Ｃに示す。フローテーブル５００１は、５−ｔｕｐｐｌｅ（５タプル）すなわち送信元ＩＰアドレス（Ｓ−ＩＰ）、送信先ＩＰアドレス（Ｄ−ＩＰ）、送信元ポート番号（Ｓ−ＰＴ）、送信先ポート番号（Ｄ−ＰＴ）、プロトコル番号（ＰＣＬ）の５つから任意に選択された組み合わせをキー項目としたテーブルであり、その組み合わせは管理者によって設定される。

例えば図６Ａ〜６Ｃに示すように、キー項目の組み合わせとして、フローテーブル５００１には、フローテーブル５００１ａ（Ｓ−ＩＰ、ＰＣＬ）、フローテーブル５００１ｂ（Ｓ−ＩＰ、Ｄ−ＩＰ、ＰＣＬ）、フローテーブルＣ５００１ｃ（Ｓ−ＩＰ、Ｄ−ＩＰ、ＰＣＬ、Ｓ−ＰＴ、Ｄ−ＰＴ）などが定義される。

キー項目の内容（値）が１つでも異なれば、すなわちフローテーブル５００１ｂの送信元ＩＰアドレスの値と送信先ＩＰアドレスの値がそれぞれ同じ２つのフローであってもプロトコル番号が異なれば、異なるエントリとなる。統計テーブル管理部１４３は、ヘッダ情報蓄積部１４２から受信したヘッダ情報に基づいて、フローテーブル毎にエントリを検索し、一致するキー項目を持つエントリの統計情報を更新する。

各フローテーブル５００１ａ、５００１ｂ、５００１ｃが保持する統計情報には、パケット数と、統計パケット生成の条件を満たすまでの採取時間と、異なり数と、送信間隔（受信間隔）が閾値以上のパケットの数などが含まれる。また、送信元から送信先への統計情報に加えて、送信先から送信元への統計情報が含まれてもよい。

異なり数は、５−ｔｕｐｐｌｅのうち、キー項目に含まれない項目のユニークな組み合わせの数である。例えば、フローテーブル５００１ａにおける異なり数とは、キー項目（送信元ＩＰアドレスとプロトコル番号）に含まれない送信先ＩＰアドレス、送信元ポート番号、送信先ポート番号のユニークな組み合せの数である。

フローテーブル５００１ｂにおける異なり数とは、キー項目（送信元ＩＰアドレス、送信先ＩＰアドレス、プロトコル番号）に含まれない送信元ポート番号と送信先ポート番号のユニークな組み合せの数である。フローテーブル５００１ｃはキー項目として５−ｔｕｐｐｌｅの５項目を含むため、異なり数はない。

統計情報は、図６Ａ〜６Ｃの例に限定されるものではなく、この他の統計情報として、パケットサイズの合計と、ＴＣＰフラグのカウント数と、パケットサイズの分布と、パケットの送信間隔（受信間隔）の分布の中の１つまたは複数が含まれてもよい。また、フローの情報が置き換えられて破棄されるためのＬｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ（ＬＲＵ）の管理情報が含まれてもよい。

なお、実施例１でフローテーブル５００１は、いずれもセットアソシエイティブの形態をとる。セットアソシエイティブで構成されるテーブルのフォーマットの例を図７に示す。セットアソシエイティブのテーブル６００１は、１つのライン番号あたりにＮ個（Ｎは１以上の整数）のエントリ番号を保持する（Ｎ個の格納欄がある）。ここで、本実施例では図７でエントリ番号を保持する例を説明するが、図６Ａ〜６Ｃに示したエントリの内容そのものを保持してもよい。

図７の例ではライン番号あたり４つのエントリ番号を保持し、このようなテーブルは４−ｗａｙセットアソシエイティブのテーブルと呼ばれる。実施例１におけるセットアソシエイティブのテーブル６００１は、フローテーブル５００１ａとフローテーブル５００１ｂなどで区別されるフローテーブル５００１のそれぞれに対して設けられる。

キー項目の値が指定されてフローテーブル５００１が更新される場合、セットアソシエイティブのテーブル６００１においてエントリ番号を絞るため、まず、指定されたキー項目の値がハッシュ関数に入力され、ハッシュ値が算出される。ここでハッシュ関数は、一般的な、ハッシュ値の衝突をある程度許容するが計算処理の軽いＣｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ（ＣＲＣ）、ｃｉｔｙ−ｈａｓｈ、ｆａｒｍ−ｈａｓｈなどであってもよい。

算出されたハッシュ値はライン番号として、ライン番号に対応する１〜４つのエントリ番号がテーブル６００１から取得され、取得された１〜４つのエントリ番号にフローテーブル５００１でそれぞれ対応するキー項目の値が取得される。取得されたキー項目の値いずれかと指定されたキー項目の値が一致し、同一値のキー項目のエントリがある場合、フローテーブル５００１で該当エントリの統計情報が更新される。

同一値のキー項目を持つエントリがなく、かつテーブル６００１のエントリ番号の４つの格納欄に空きがある場合、エントリ番号が新たに付与されて、フローテーブル５００１にエントリが登録されて、テーブル６００１の空きに新たに付与されたエントリ番号が追加され、空きがない場合はエントリ番号の置換が行なわれる。

なお、セットアソシエイティブの構成において、エントリ番号の置換には、ＬＲＵや疑似ＬＲＵが用いられることが一般的である。ＬＲＵでは、ライン毎の複数のエントリ番号のうち、最も未使用の時間の長いエントリ番号が、優先的に置換される処理である。

また、ＬＲＵは処理時間が大きいために、セットアソシエイティブの構成で多くの場合は、処理を簡略化した疑似ＬＲＵが用いられる。この他にも、アクセスされた回数が小さいエントリから優先的に置換する方法も一般的である。

しかし、ＬＲＵ等の置換処理でフローテーブル５００１やセットアソシエイティブのテーブル６００１の更新を行った場合、リソース消費型ＤＤｏＳのようなトラフィック量の小さいフローのエントリは置換対象となりやすく、異常検知に必要な統計情報が欠落してしまう可能性がある。そのため、統計テーブル管理部１４３は、エントリ更新方法管理情報３００１を備える。

エントリ更新方法管理情報３００１ａの例を図８に示す。エントリ更新方法管理情報３００１ａは、検知対象３０１１の種別に対応した、エントリ置換のルール３０２１の情報と、エントリ置換時の統計パケットの生成条件３０３１の情報と、これらのルールを適用するフローテーブル３０４１としてフローテーブル５００１ａ、５００１ｂ、５００１ｃを識別する名称とを備える。なお、エントリ更新時の統計パケットの生成条件が備えられてもよい。

統計テーブル管理部１４３は、管理者によってあらかじめ指定された検知対象３０１１種別に対応したルール３０２１と、生成条件３０３１と、適用するフローテーブル３０４１をエントリの更新に使用する。図８のエントリ更新方法管理情報３００１ａに示すエントリ置換時の統計パケットの生成条件３０３１は、前述した統計パケットの生成条件とは異なり、エントリ置換時にのみ適用される。詳細は後述のエントリ更新のフローチャートで説明する。

検知対象３０１１がリソース消費型ＤＤｏＳに対するエントリ置換のルール３０２１の例として、パケット送信間隔（受信間隔）が閾値以上のパケット数が少ないものから優先的に置換するというルールが設定される。また、エントリ置換時の統計パケットの生成条件３０３１の例として、エントリ置換時にパケット送信間隔（受信間隔）が閾値以上のパケット数が一定以上というルールが設定される。そして、適用するフローテーブル３０４１の例として、フローテーブル５００１の名称がＡ、Ｂ、Ｃであると設定される。

これにより、リソース消費型ＤＤｏＳの検知に必要な統計情報を優先的に残し、統計情報を欠落させることなく分析サーバ２００に通知することが可能となる。なお、エントリ置換のルール３０２１及び統計パケットの生成条件３０３１の情報としては、図８に示した例の他にも、統計情報に含まれる複数の項目及びその組み合せが設定されてもよい。

また、検知対象３０１１の種別が管理者によって指定されていない場合（指定なしと設定されている場合）、統計テーブル管理部１４３は、疑似ＬＲＵのような一般的な処理を用いて、テーブル６００１のエントリ番号の置換を行ってもよく、エントリ更新方法管理情報３００１ａの情報は、プログラムあるいはテーブルの値のいずれかであってもよい。

（システムの動作シーケンス）
実施例１のシステムにおける動作シーケンスの例を図９に示す。まず、管理者により分析サーバ２００の入力部２３０を介して、分析サーバ２００の異常検知管理情報１００１に対して検知対象（の種別）が指定され、フローテーブル５００１とエントリ更新方法管理情報３００１の設定情報及び分析サーバ２００のアドレスなどの設定情報が受け付けられて、ルータ１００に対して送信される（ステップＳ５０１）。

設定情報を受信したルータ１００は、制御部１１０を介してトラフィック統計処理部１４０の統計パケット生成部１４１、統計テーブル管理部１４３に設定を行い、統計収集処理を開始する（ステップＳ５０２）。トラフィックの統計収集を継続し、統計収集処理中に、統計パケットの生成条件を満たした場合、ルータ１００は、統計情報を含む統計パケットを分析サーバ２００に送信する（ステップＳ５０３）。

分析サーバ２００は、統計パケットを受信すると、統計パケットに含まれる統計情報を蓄積する（ステップＳ５０４）。分析サーバ２００は、管理者から与えられる学習指示を契機として、蓄積された統計情報を機械学習に入力し、正常か異常かを判定する判定器を作成する（ステップＳ５０５）。

以降もルータ１００は、トラフィックの統計収集を継続し、統計収集処理中に、統計パケットの生成条件を満たした場合、ルータ１００は、統計情報を含む統計パケットを分析サーバ２００に送信する（ステップＳ５０６）。分析サーバ２００は、ルータ１００から統計パケットを受信すると、統計パケットに含まれる統計情報を判定器へと入力して、正常か異常かの判定を行う（ステップＳ５０７）。

（統計テーブル１５０のエントリ更新のフローチャート）
統計テーブル管理部１４３が統計テーブル１５０を更新するフローチャートの例を図１０に示す。統計テーブル管理部１４３は、ヘッダ情報蓄積部１４２からパケットのヘッダ情報を受け取ると、統計テーブル１５０のエントリ更新処理を開始する（ステップＳ７０１）。なお、受信パケット処理部１２０がパケットを受信すると、トラフィック統計処理部１４０へ受信されたパケットのヘッダ情報を出力し、トラフィック統計処理部１４０の中では、ヘッダ情報蓄積部１４２がヘッダ情報を受け取る。

統計テーブル管理部１４３は、各フローテーブル５００１のキー項目に対応する５−ｔｕｐｐｌｅの情報をパケットのヘッダ情報から抽出し、ハッシュ関数に入力してライン番号を算出する（ステップＳ７０２）。そして、算出されたライン番号を基にセットアソシエイティブのテーブル６００１のラインにアクセスしてエントリ番号を取得し、エントリ番号を基にフローテーブル５００１にアクセスしてキー項目の情報が一致するエントリを検索する（ステップＳ７０３）。

一致するエントリがあり、ステップＳ７０３の検索にて見つかった場合、統計テーブル管理部１４３は、見つかったエントリの統計情報を更新する（ステップＳ７０４）。一致するエントリがない場合、統計テーブル管理部１４３は、ステップＳ７０２で算出されたライン番号のラインに空きがあるかを判定し（ステップＳ７０５）、空きがあると判定した場合は空きへ新規のエントリ番号を追加して、追加されたエントリ番号のエントリをフローテーブル５００１に追加し（ステップＳ７０６）、追加されたエントリの統計情報を更新する（ステップＳ７０４）。

ステップＳ７０４においてエントリの統計情報を更新した後、統計テーブル管理部１４３は、更新されたエントリが、図８では図示を省略したエントリ更新時の統計パケットの生成条件を満たすかを判定する（ステップＳ７０７）。生成条件を満たすと判定した場合、統計テーブル管理部１４３は、統計パケット生成部１４１にパケット生成を通知し（ステップＳ７０８）、エントリ更新処理を終了する（ステップＳ７０９）。

なお、ステップＳ７０８に応じてパケットが生成されると、パケットの生成に用いられたエントリはフローテーブル５００１から削除され、削除されたエントリのエントリ番号はセットアソシエイティブのテーブル６００１から削除される。ステップＳ７０７において生成条件を満たさないと判定した場合、統計テーブル管理部１４３のエントリ更新処理はそのまま終了する（ステップＳ７０９）。

ステップＳ７０５においてラインに空きがないと判定した場合、統計テーブル管理部１４３は、エントリ更新方法管理情報３００１に設定された、エントリ置換のルール３０２１に基づいてエントリを置換し（ステップＳ７１０）、エントリの統計情報を更新する（ステップＳ７１１）。

すなわち、セットアソシエイティブのテーブル６００１において空きがないと判定されたラインの中からエントリ番号を、エントリ置換のルール３０２１に基づいて特定し、特定されたエントリ番号のエントリをフローテーブル５００１から削除し、特定されたエントリ番号をセットアソシエイティブのテーブル６００１から削除して、削除して空きとなった欄へ新たなエントリ番号とエントリを追加する。そして、追加されたエントリの統計情報を更新する。

その後、統計テーブル管理部１４３は、置換されるエントリがエントリ置換時の統計パケット生成条件３０３１を満たすかを判定し（ステップＳ７１２）、条件を満たすと判定した場合、統計パケット生成部１４１にパケット生成を通知し（ステップＳ７０８）、エントリ更新処理を終了する（ステップＳ７０９）。この際に生成される統計パケットには、エントリ置換時の統計パケット生成条件３０３１を満たしたことを示すフラグ情報が付加される。

なお、ステップＳ７０８に応じてパケットが生成されると、パケットの生成に用いられたエントリはフローテーブル５００１から削除され、削除されたエントリのエントリ番号はセットアソシエイティブのテーブル６００１から削除される。ステップＳ７１２において生成条件を満たさないと判定した場合、統計テーブル管理部１４３のエントリ更新処理はそのまま終了する（ステップＳ７０９）。

ステップＳ７１０において統計テーブル管理部１４３は、置換対象となって削除されるエントリの統計パケットを生成するように、統計パケット生成部１４１へ通知してもよい。また、削除されるエントリの情報があらかじめ設定された条件に適合するかを判定し、条件に適合すると判定した場合に、統計パケット生成部１４１へ通知してもよい。

（トラフィック統計処理部１４０と統計テーブル１５０の変形例）
以上の説明では、統計テーブル１５０のフローテーブル５００１がセットアソシエイティブの形態として、フローテーブル５００１のエントリへの処理を説明した。しかしながら、以上の説明の形態に限定されるものではなく、フローテーブル５００１の他の形態として、キー項目からライン番号を求める際に複数のハッシュ関数を使用して複数のライン番号の候補を求め、その中から対象となるエントリを求めるようにしてもよい。

また、図２を用いて、トラフィック統計処理部１４０及び統計テーブル１５０がルータ１００の内部に実装される例を説明したが、トラフィック統計処理部１４０及び統計テーブル１５０はルータ１００の外部に配置される統計収集サーバ３００に実装されてもよい。統計収集サーバ３００を含む構成の例を図１１に示す。

ルータ１００の制御部１１０と、検索処理部１６０と、ルーティングテーブル１７０と、分析サーバ２００は図２を用いて説明したとおりであるが、ルータ１００の受信パケット処理部１２０は、受信したパケットを複製して統計収集サーバ３００へと送信する。また、送信パケット処理部１３０は、統計収集サーバ３００から受信した統計パケットを分析サーバ２００へ送信する。

ここで、受信パケット処理部１２０は、受信したパケットのヘッダ情報を統計収集サーバ３００へ送信してもよく、このために、受信したパケットのヘッダ情報をデータとする新たなパケットを作成して統計収集サーバ３００へ送信してもよい。

統計収集サーバ３００のトラフィック統計処理部１４０と統計テーブル１５０は、図２、４〜１０を用いて説明したとおりであり、トラフィック統計処理部１４０は、統計収集サーバ３００が受信したパケットのヘッダ情報を入力し、統計情報を統計収集サーバ３００からルータ１００へ通知する。

なお、統計収集サーバ３００は、分析サーバ２００とも接続され、ルータ１００からは複製されたパケットを受信し、設定情報と統計情報を分析サーバ２００と直接に送受信してもよい。統計収集サーバ３００はプロセッサ３１０とメモリ３２０を備えた一般的なコンピュータでもよく、メモリ３２０に統計テーブル１５０とプログラム３３０が格納され、プログラム３３０をプロセッサ３１０が実行することにより、トラフィック統計処理部１４０となってもよく、図１０を用いて説明した処理を実現するプログラムがプログラム３３０に含まれてもよい。そして、ルータ１００はネットワークの一般的なスイッチあるいは一般的なルータに置き換えられてもよい。

（リソース消費型ＤＤｏＳ以外の攻撃への応用）
以上の説明では、リソース消費型ＤＤｏＳの検知における統計情報の欠落を課題とし、これを解決するための実施例を説明した。しかしながら、リソース消費型ＤＤｏＳの検知に限定されるものではなく、リソース消費型ＤＤｏＳ以外の攻撃を検知することも可能であり、特にＣｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ （Ｃ＆Ｃ）サーバ通信やスキャン活動、フラッディングなどを検知対象とすることができる。

ところで、複数の検知対象を同じ時間内で監視する場合、検知対象それぞれの動作が異なり、エントリ置換のルール３０２１の内容が異なるため、エントリ置換のルール３０２１の複数の内容が競合して、他の検知対象に必要なエントリを置換対象としてしまい、全ての検知対象に関する統計を欠落することなく採取できない場合がある。

これを防ぐため、ルータ１００の統計テーブル管理部１４３は、以下に示す競合管理情報７００１を保持し、競合管理情報７００１の情報に従ってエントリ置換のルール３０２１の内容が競合する検知対象に対し、検知対象毎にフローテーブル５００１を作成する。これにより、検知対象３０１１の第１の種別に対するエントリ置換のルール３０２１の内容を第１のフローテーブル５００１へ適用しても、検知対象３０１１の第２の種別のための第２のフローテーブル５００１へ影響しない。

検知対象を複数とした場合のエントリ更新方法管理情報３００１ｂの例を図１２に示す。この例では、リソース消費型ＤＤｏＳとＣ＆Ｃサーバのエントリ置換のルール３０２１は同じ内容のルールであり競合しないが、フラッディングとはエントリ置換のルール３０２１が異なる内容のルールであり、そのルールの内容からフローテーブルのＡ、Ｂにおいて競合する可能性がある。

このような競合の発生する可能性があるので、統計テーブル管理部１４３は、エントリ置換のルール３０２１が競合するかしないかを判定するために、競合管理情報７００１を参照する。競合管理情報７００１の例を図１３に示す。競合管理情報７００１には、検知対象ごとに、他のどの検知対象と競合しないかの情報が登録されている。図１３の例では、リソース消費型ＤＤｏＳとＣ＆Ｃサーバ通信は競合しないが、フラッディングは競合する可能性があることを示す。

管理者がエントリ更新方法管理情報３００１ｂと競合管理情報７００１を設定する契機で、あるいはエントリ更新方法管理情報３００１ｂと競合管理情報７００１が予め設定され、管理者がエントリ更新方法管理情報３００１ｂの検知対象３０１１の種別を指定する契機で、統計テーブル管理部１４３は、競合管理情報７００１を検索して競合を判定する。

判定の結果、競合しないと判定した場合、統計テーブル管理部１４３は、検知対象３０１１の複数の種別に対して、共通のフローテーブル５００１へエントリ置換のルール３０２１のそれぞれの内容のルールを適用し、共通のフローテーブル５００１を用いて統計情報を処理する。

判定の結果、競合する可能性があると判定した場合、統計テーブル管理部１４３は、競合する可能性があると判定された検知対象３０１１の種別に対応する、適用するフローテーブル３０４１の名称の一致を判定し、一致すると判定された名称のフローテーブル５００１を一致する個数作成する。ここで、適用するフローテーブル３０４１の名称を予め設定された期間だけ識別できるように変更してもよい。

例えば、検知対象３０１１のリソース消費型ＤＤｏＳとフラッディングとが競合する可能性があると判定した場合、リソース消費型ＤＤｏＳに対応する、適用するフローテーブル３０４１のＡ、ＢをそれぞれＡ１、Ｂ１に変更し、フラッディングに対応する、適用するフローテーブル３０４１のＡ、ＢをそれぞれＡ２、Ｂ２に変更し、名称がＡ１、Ｂ１、Ａ２、Ｂ２となる４つのフローテーブル５００１を作成してもよい。

そして、統計テーブル管理部１４３は、それぞれのフローテーブル５００１毎にエントリ置換のルール３０２１の内容のルールとエントリ置換時の統計パケット生成条件３０３１の内容の条件を適用する。なお、競合管理情報７００１は、検索可能な情報の形態であれば、プログラムによる情報であってもよいし、テーブルとして値が保持されてもよい。

以上で説明したように、統計情報を含むフローテーブルを欠落なく記憶できる容量のメモリが無く、フローテーブルを記憶するメモリの容量が小さい場合であっても、リソース消費型ＤＤｏＳのようなフローの統計情報を収集することが可能となる。また、逆にフローテーブルを記憶するメモリの容量を削減することが可能となる。

（システムの構成）
実施例１では分析サーバ２００で異常を検知する例を説明したが、実施例２では一般的なパケット解析装置でトラフィックを検閲する例を説明する。実施例２におけるネットワークを含むシステムの構成の例を図１４に示す。実施例１で説明した図１の例との違いは、ルータ１００ｃが新たにパケット解析装置４００と接続している点である。このため、端末１０とサーバ２０及びルータ１００ａ、１００ｂは図１を用いて説明したとおりであるが、ルータ１００ｃと分析サーバ２００は図１を用いた説明とは異なる。

パケット解析装置４００は具体的には、フォレンジックサーバやＤｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ（ＤＰＩ）装置などの解析装置である。分析サーバ２００がルータ１００から通知される統計情報を用いて異常を検知するのに対し、パケット解析装置４００はルータ１００からミラーリングやポリシーベースルーティングなどで送信されたパケットを受信して検閲する。

パケット解析装置４００は分析サーバ２００よりも詳細な情報を解析することが可能であるが、ルータ１００ｃとパケット解析装置４００との間の回線帯域の容量が限られるために、ルータ１００を経由する多量のトラフィックをパケット解析装置４００が受信して監視することはできない。

実施例２の図１４に示す分析サーバ２００は、トラフィックの統計情報を網羅的に解析して一次スクリーニングを実施し、パケット解析装置４００へと送信するフローを選択し、パケット解析装置４００へのトラフィックを絞り込む。これにより、ルータ１００とパケット解析装置４００との間の限られた回線帯域容量が効率的に使用され、検閲する価値のあるトラフィックが監視される。

このように、リソース消費型ＤＤｏＳをパケット解析装置４００で監視するためには、分析サーバ２００が、リソース消費型ＤＤｏＳの疑いのあるトラフィックの統計情報をそのトラフィックの開始から短時間で検知し、パケット解析装置４００へのパケット送信をルータ１００ｃへ指示する必要がある。

しかし、リソース消費型ＤＤｏＳは通信が低レートであり、実施例１で説明した統計パケットの生成条件を満たすまでに時間がかかるため、リソース消費型ＤＤｏＳが開始されてから、パケット解析装置４００でパケットを受信して検閲が始まるまでに時間がかかる。そのため、実施例２では、トラフィック統計処理部１４０のフローテーブル及びエントリ更新方法管理情報に後述する情報が追加されて、リソース消費型ＤＤｏＳの早期検知を図る。

（フローテーブル５００１ｄの構成）
実施例２におけるフローテーブル５００１ｄの例を図１５に示す。実施例１の図６を用いて説明したフローテーブル５００１ａ〜５００１ｃとの違いは、統計情報として、０か１の値をとる通知済フラグ５０１１の情報がエントリ毎に追加されている点である。通知済フラグ以外の統計情報と、エントリ番号と、キー項目は、既に説明したとおりである。図１５に示した例は、キー項目が図６Ａに相当するものであるが、図６Ｂ、６Ｃに相当するキー項目であってもよい。

通知済フラグ５０１１の値は、初期値が０であり、後述する早期検知パケットの生成条件が満たされた場合に１となる。いったん通知済フラグ５０１１が１になると、それ以後、１となったエントリに関する早期検知パケットは、早期検知パケットの生成条件が満たされても送信されない。

（エントリ更新方法管理情報３００１ｃの構成）
実施例２におけるエントリ更新方法管理情報３００１ｃの例を図１６に示す。実施例１の図８を用いて説明したエントリ更新方法管理情報３００１ａとの違いは、早期通知パケットの生成条件５０１２が追加されている点である。検知対象３０１１と、エントリ置換のルール３０２１と、エントリ置換時の統計パケット生成条件３０３１と、適用するフローテーブル３０４１は、既に説明したとおりである。

検知対象３０１１がリソース消費型ＤＤｏＳに対し、早期通知パケットの生成条件５０１２の内容となる条件として、例えば、パケットの送信間隔（受信間隔）が閾値以上のパケット数が一定数以上と設定される。ここで、パケット数を判定するために、送信間隔（受信間隔）の閾値とは関連のない一定数（閾値）と比較されてもよい。

そして、この一定数（閾値）として、十分に小さい値が設定されることにより、リソース消費型ＤＤｏＳのトラフィックの可能性を、そのトラフィックの開始から短時間で判定でき、パケット解析装置４００へのパケットの転送をルータ１００ｃへ指示することが可能となる。また、一定数（閾値）を十分に小さくすることで、Ｆａｌｓｅ Ｎｅｇａｔｉｖｅ Ｒａｔｅを小さくできる。なお、一定数（閾値）は、エントリ置換のルール３０２１のパケット数が少ないものより小さい値が望ましい。

早期通知パケットの生成条件５０１２は、図１０に示したフローチャートのステップＳ７０７において使用される。実施例２では、統計テーブル管理部１４３が、ステップＳ７０７において、実施例１と同様に更新されたエントリが、エントリ更新時の統計パケットの生成条件を満たすかを判定することに加え、早期通知パケットの生成条件５０１２の内容の条件を満たすかを判定する。

ステップＳ７０７において早期通知パケットの生成条件５０１２の内容の条件を満たすと判定した場合、統計テーブル管理部１４３は、フローテーブル５００１ｄの判定されたエントリの通知済フラグ５０１１を１に変更して、統計パケット生成部１４１に早期通知パケットの生成を通知する。

この通知に対して、統計パケット生成部１４１は、統計情報に加えて早期通知パケットであることを示すフラグと検知対象の情報を早期通知パケットに含める。なお、以上で説明した早期通知パケットの生成においては、早期通知パケットを生成した後も、通知に使用されたエントリはフローテーブル５００１ｄから削除されない。これにより、異なり数などの統計情報を、分析サーバ２００の方でも異常を検知するのに十分な量採取することが可能となる。

（システムの動作シーケンスの説明）
実施例２のシステムにおける動作シーケンスの例を図１５に示す。図１５に示すようにパケット解析装置４００の動作シーケンスが、図９に示した動作シーケンスに加わる。なお、ステップＳ９０１〜Ｓ９０５の説明は、実施例１における図９のステップＳ５０1〜５０５と同じ説明であるので、説明を省略する。

ルータ１００は、ステップＳ９０３でトラフィックの統計収集処理を開始した後、トラフィックの統計収集を継続し、早期通知パケットの生成条件５０１２を満たすと判定した場合、ルータ１００は早期通知パケットを分析サーバ２００に送信する（ステップＳ９０６）。

分析サーバ２００は早期通知パケットを受信すると、早期通知パケットに含まれるキー項目に一致するフローもしくはキー項目の一部を含むフローをパケット解析装置４００へとミラーリングするよう、ルータ１００へと設定指示を通知する（ステップＳ９０７）。ルータ１００は設定指示を受信すると、設定指示で指定されるフローをパケット解析装置４００へとミラーリングするよう、受信パケット処理部１２０及び送信パケット処理部１３０を制御する（ステップＳ９０８）。

このミラーリングのために、受信パケット処理部１２０と送信パケット処理部１３０にミラーリングのための回路が設けられてもよいし、制御部１１０がルーティングテーブル１７０にミラーリングするルートを設定してもよい。パケット解析装置４００は、ルータ１００から送信されたパケットを受信すると、パケットを検閲し、異常か正常かの判定を行う（ステップＳ９０９）。

以上で説明したように、リソース消費型ＤＤｏＳの攻撃の始まりを早期に検知し、フローを絞り込んでパケット解析装置４００で解析することが可能となり、ルータ１００とパケット解析装置４００の間の回線帯域容量を効率的に使用しつつ、トラフィックを漏れなく監視することが可能となる。

１００ ルータ
２００ 分析サーバ
３００ 統計収集サーバ
４００ パケット解析装置
１１０ 制御部
１２０ 受信パケット処理部
１３０ 送信パケット処理部
１４０ トラフィック統計処理部
１５０ 統計テーブル
１４１ 統計パケット生成部
１４３ 統計テーブル管理部

Claims (14)

1. ネットワークの統計情報を管理するネットワーク装置であって、
   前記ネットワークからパケットを受信する受信部と、
   前記受信部が受信したパケットの統計情報を第１のテーブルのエントリ単位で管理し、
   前記第１のテーブルのエントリの置換ルールと、置換されるエントリの統計情報の送信条件を第２のテーブルで管理し、
   前記第２のテーブルで管理される置換ルールに基づいて前記第１のテーブルのエントリを置換し、前記第２のテーブルで管理される送信条件に基づいて前記第１のテーブルのエントリの統計情報を送信するよう制御する管理部とを備え、
   前記第２のテーブルで管理される送信条件は、
   受信間隔が予め設定された閾値以上であり、パケット数が予め設定された一定数以上であるという情報を含み、
   前記管理部は、
   置換されると特定されたエントリの受信間隔の情報とパケット数の情報が、前記第２のテーブルで管理される送信条件を満たすか判定し、
   送信条件を満たすと判定すると、置換されると特定されたエントリの受信間隔の情報とパケット数の情報を含む統計情報を送信するよう制御すること
   を特徴とするネットワーク装置。
2. 請求項１に記載のネットワーク装置であって、
   前記第１のテーブルのエントリは、前記ネットワークのパケットの５タプルに含まれる値により識別されること
   を特徴とするネットワーク装置。
3. 請求項２に記載のネットワーク装置であって、
   前記管理部は、
   前記受信部で第１のパケットを受信すると、
   前記第１のパケットの５タプルに含まれる値と、前記第１のテーブルのエントリが識別される５タプルに含まれる値との一致により、前記第１のパケットに対応するエントリが前記第１のテーブルにあるかを判定すること
   を特徴とするネットワーク装置。
4. 請求項３に記載のネットワーク装置であって、
   前記第１のテーブルで管理される統計情報は、
   前記受信部で既に受信された第２のパケットの受信間隔の情報と予め設定された時間に受信されたパケット数の情報を、エントリ毎に含み、
   前記管理部は、
   前記第１のパケットに対応するエントリが前記第１のテーブルに有ると判定すると、
   前記第１のテーブルの有ると判定されたエントリの受信間隔の情報とパケット数の情報を、前記第１のパケットの情報で更新すること
   を特徴とするネットワーク装置。
5. 請求項４に記載のネットワーク装置であって、
   前記管理部は、
   前記第１のパケットに対応するエントリが前記第１のテーブルに無いと判定すると、
   前記第１のテーブルのエントリの空きを判定し、
   空きがないと判定すると、前記第２のテーブルで管理される置換ルールに基づいて置換すること
   を特徴とするネットワーク装置。
6. 請求項５に記載のネットワーク装置であって、
   前記管理部は、
   前記第２のテーブルで管理される置換ルールに基づいて置換するため、前記第１のテーブルで管理される統計情報に含まれる受信間隔の情報とパケット数の情報を、前記第２のテーブルで管理される置換ルールへ適用し、置換されるエントリを特定すること
   を特徴とするネットワーク装置。
7. 請求項６に記載のネットワーク装置であって、
   前記第２のテーブルで管理される置換ルールは、
   受信間隔が予め設定された閾値以上であり、パケット数が少ないエントリから置換するという情報を含むこと
   を特徴とするネットワーク装置。
8. 請求項７に記載のネットワーク装置であって、
   前記管理部は、
   置換されると特定されたエントリを、前記第１のパケットの５タプルに含まれる情報と、前記第１のパケットの受信間隔の情報とパケット数の情報で置換すること
   を特徴とするネットワーク装置。
9. 請求項８に記載のネットワーク装置であって、
   前記第１のテーブルで管理される統計情報は、
   さらに、ＴＣＰフラグの数、異なり数、採取時間、パケットサイズ、パケットサイズの分布、パケットの受信間隔の分布のいずれか１つ以上の情報を含むこと
   を特徴とするネットワーク装置。
10. 請求項９に記載のネットワーク装置であって、
    前記第２のテーブルは、
    複数種類の検知対象の情報と、検知対象それぞれに対応付けられた置換ルールの情報と送信条件の情報を含み、
    前記管理部は、
    異なる種類の検知対象の組み合わせにおいて、前記第２のテーブルに含まれる置換ルールが競合する組み合わせを第３のテーブルで管理し、
    検知対象の複数の指定を受け付け、
    受け付けられた指定が、前記第３のテーブルの組み合わせであるかを判定し、
    組み合わせであると判定すると、組み合わせに含まれる検知対象毎に前記第１のテーブルを生成すること
    を特徴とするネットワーク装置。
11. ネットワークの統計情報を用いる異常検知システムであって、
    統計情報を受信して機械学習により解析し、異常を検知するための判定器を生成する分析サーバと
    前記ネットワークからパケットを受信する受信部と、前記受信部が受信したパケットの統計情報を第１のテーブルのエントリ単位で管理し、前記第１のテーブルのエントリの置換ルールと、置換されるエントリの統計情報の送信条件を第２のテーブルで管理し、前記第２のテーブルで管理される置換ルールに基づいて前記第１のテーブルのエントリを置換
    し、前記第２のテーブルで管理される送信条件に基づいて前記第１のテーブルのエントリの統計情報を前記分析サーバへ送信するよう制御する管理部とを備えたネットワーク装置と、
    を備え、
    前記第２のテーブルで管理される送信条件は、
    受信間隔が予め設定された閾値以上であり、パケット数が予め設定された一定数以上であるという情報を含み、
    前記管理部は、
    置換されると特定されたエントリの受信間隔の情報とパケット数の情報が、前記第２のテーブルで管理される送信条件を満たすか判定し、
    送信条件を満たすと判定すると、置換されると特定されたエントリの受信間隔の情報とパケット数の情報を含む統計情報を送信するよう制御すること
    を特徴とする異常検知システム。
12. 請求項１１に記載の異常検知システムであって、
    パケット解析装置をさらに備え、
    前記ネットワーク装置は、前記ネットワーク装置の前記受信部で受信したパケットを送信する送信部をさらに備え、
    前記ネットワーク装置の前記管理部は、
    前記第２のテーブルで早期検知の情報の通知条件をさらに管理し、
    前記第２のテーブルで管理される通知条件に基づいて早期検知を前記分析サーバへ通知するように制御し、
    前記分析サーバは、
    早期検知が通知されると、前記ネットワーク装置へミラーリングの設定指示を通知し、
    前記ネットワーク装置の送信部は、ミラーリングの設定指示が通知されると、前記受信部で受信したパケットを前記パケット解析装置へ送信すること
    を特徴とする異常検知システム。
13. 請求項１２に記載の異常検知システムであって、
    前記ネットワーク装置の前記管理部は、
    前記第１のテーブルで早期検知の通知済みの情報をさらに管理し、
    前記第１のテーブルで管理される早期検知の通知済みの情報が、通知済みでないことを示すと判定すると、前記第２のテーブルで管理される通知条件に基づいて早期検知を前記分析サーバへ通知するように制御し、前記第１のテーブルで管理される早期検知の通知済みの情報を、通知済みに変更すること
    を特徴とする異常検知システム。
14. ネットワークの統計情報を用いる異常検知システムであって、
    前記ネットワークからパケットを受信し、受信されたパケットのパケットヘッダを出力する受信部と、受信されたパケットをルーティング先へ送信する送信部とを備えたルータと、
    パケットヘッダを入力して蓄積する蓄積部と、蓄積されたパケットヘッダに基づいて、前記受信部が受信したパケットの統計情報を第１のテーブルのエントリ単位で管理し、前記第１のテーブルのエントリの置換ルールと、置換されるエントリの統計情報の送信条件を第２のテーブルで管理し、前記第２のテーブルで管理される置換ルールに基づいて前記第１のテーブルのエントリを置換し、前記第２のテーブルで管理される送信条件に基づいて前記第１のテーブルのエントリの統計情報を送信するよう制御する管理部とを備えた統計収集サーバと、
    統計情報を受信して機械学習により解析し、異常を検知するための判定器を生成する分析サーバと
    を備え、
    前記第２のテーブルで管理される送信条件は、
    受信間隔が予め設定された閾値以上であり、パケット数が予め設定された一定数以上であるという情報を含み、
    前記管理部は、
    置換されると特定されたエントリの受信間隔の情報とパケット数の情報が、前記第２のテーブルで管理される送信条件を満たすか判定し、
    送信条件を満たすと判定すると、置換されると特定されたエントリの受信間隔の情報とパケット数の情報を含む統計情報を送信するよう制御すること
    を特徴とする異常検知システム。

Images