(57)【要約】【目的】  ワーム感染により引き起こされるネットワーク負荷の的確な予測を可能とするトラヒック監視装置を提供する。【構成】  複数のプロトコルのうちの少なくとも１つに各々が対応する複数のパケットが伝送されるパケットネットワークのトラヒック量を監視するトラヒック監視装置であり、該パケットを収集し、収集されたパケット群の各パケットを該プロトコルによって分類し、同一の分類先に属するパケットの数及びサイズのうちの少なくとも１つを該トラヒック量として検出する。【選択図】  図２
2006333089.tif 000002
【特許請求の範囲】
【請求項１】
複数のプロトコルのうちの少なくとも１つに各々が対応する複数のパケットが伝送されるパケットネットワークのトラヒック量を監視するトラヒック監視装置であって、
前記パケットを収集するパケット収集手段と、
収集されたパケット群の各パケットを前記プロトコルによって分類するパケット分類手段と、
同一の分類先に属するパケットの数及びサイズのうちの少なくとも１つを前記トラヒック量として検出するトラヒック量検出手段と、
を含むことを特徴とするトラヒック監視装置。
【請求項２】
前記パケット分類手段は、前記パケットに含まれるポート番号によってさらに分類することを特徴とする請求項１記載のトラヒック監視装置。
【請求項３】
前記パケット分類手段は、前記プロトコルがＴＣＰまたはＵＤＰである場合に、上がりパケットであるか下りパケットであるかによってさらに分類することを特徴とする請求項１記載のトラヒック監視装置。
【請求項４】
前記トラヒック量検出手段は、所定の時間区間毎に分類されるパケットに基づいて前記トラヒック量を検出することを特徴とする請求項１記載のトラヒック監視装置。
【請求項５】
指定時刻を含む表示要求に応じて、前記指定時刻を含む１つの時間区間内に分類されるパケットに基づいて得られるトラヒック量を表示するトラヒック量表示手段をさらに含むことを特徴とする請求項４記載のトラヒック監視装置。
【請求項６】
前記パケット収集手段により収集されたパケットに基づいて、前記パケットネットワークに接続される複数のコンピュータのうちの少なくとも１におけるワーム感染を検出し、前記ワーム感染の検出時刻を含むワーム感染告知情報を出力するワーム検出告知手段をさらに含むことを特徴とする請求項１記載のトラヒック監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰネットワークの如きパケットネットワークにおいて伝送されるパケットの数やサイズを集計して、これをトラヒック量を示す指標として監視するトラヒック監視装置に関する。
【背景技術】
【０００２】
ＩＰネットワークのトラヒックをモニタするトラヒック監視装置が知られている。該トラヒック監視装置は、ＩＰネットワーク上の任意の通信ノードにおけるパケットを計量することで、当該ＩＰネットワークのトラヒック状況の情報を出力する。
【０００３】
一方、インターネット等の外部ネットワークから企業等の内部ネットワークに侵入するコンピュータウイルスが問題となっている。広義のコンピュータウイルスには、文書等のファイルに侵入し該ファイルが実行される時に感染するタイプの狭義のウィルスと、ファイルの如き感染対象を必要とせずにコンピュータ内部に侵入して自己増殖活動行うタイプのワームとがある。コンピュータに侵入したワームは、ネットワークに繋がる他のコンピュータに多量の攻撃パケットを送出して自己増殖を図る。この多量の攻撃パケットが当該ネットワークの帯域を圧迫することで、ネットワークの通常機能を不全に陥らしめる危険がある。
【０００４】
図１に示されるように、複数のコンピュータ１ａ〜１ｈのうちの１つのコンピュータ１ｂが外部のインターネット６からゲートウェイ５、スイッチングハブ３及びシェアードハブ（以下、共用ハブと称する）２を介してワームに感染したとする。ワームは、自己を他のコンピュータに感染させるために攻撃パケットを多数のＩＰアドレスに向けて送信する。多量の攻撃パケットがスイッチングハブ３及び共用ハブ２を介して他のコンピュータ１ａ、１ｃ〜１ｈに送信され、内部ネットワークのトラヒックを増大せしめることになる。かような異常トラヒックの増大はトラヒック監視装置４によりモニタすることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、かかる従来のトラヒック監視装置では、ワーム自己増殖活動と想定される異常トラヒック増大を認識できるものの、かかるワーム自己増殖活動によりもたらされるネットワーク負荷増大等の波及的影響を的確にネットワーク管理者をして予測せしめるものではなかった。また、社会的に知られたワームについてはその性質がある程度判明していることでかかる予測が容易であるものの、新たなワームの出現に対してはその感染後のネットワーク負荷の予測を正確に行うことは困難であり、的確な対処を遅らせてしまう問題があった。
【０００６】
本発明の目的は、ワーム感染により引き起こされるネットワーク負荷の的確な予測を可能とするトラヒック監視装置を提供することである。
【課題を解決するための手段】
【０００７】
本発明によるトラヒック監視装置は、複数のプロトコルのうちの少なくとも１つに各々が対応する複数のパケットが伝送されるパケットネットワークのトラヒック量を監視するトラヒック監視装置であり、該パケットを収集するパケット収集手段と、収集されたパケット群の各パケットを該プロトコルによって分類するパケット分類手段と、同一の分類先に属するパケットの数及びサイズのうちの少なくとも１つを該トラヒック量として検出するトラヒック量検出手段とを含むことを特徴とする。
【発明の効果】
【０００８】
本発明によるトラヒック監視装置によれば、ＩＰネットワークの如きパケットネットワークにおいて伝送されるパケットを収集してプロトコル毎に分類した上でパケット数あるいはパケットサイズを集計してトラヒック量を監視する構成が与えられる。これにより、プロトコル毎にトラヒックを把握することが可能となり、ワーム感染により引き起こされるネットワーク負荷の的確な予測が可能となる。
【発明を実施するための最良の形態】
【０００９】
本発明の実施例について添付の図面を参照して詳細に説明する。
【００１０】
図２は、本発明の実施例を示し、トラヒック監視装置の構成を示している。トラヒック監視装置１００は、図１に示された如き通常のネットワーク環境下での使用が想定される。
【００１１】
トラヒック監視装置１００は、スイッチングハブ２００ａ及び共用ハブ２００ｂに接続される。スイッチングハブ２００ａのミラーポートがトラヒック監視装置１００に接続され、スイッチングハブ２００ａの各ポートに流れる全てのパケットが捕捉される。共有ハブ２００ｂの任意のポートがトラヒック監視装置１００に接続され、共有ハブ２００ｂに流れる全てのパケットが捕捉される。また、トラヒック監視装置１００は、通常のパーソナルコンピュータにより実現される管理端末３００に接続される。管理端末３００は、ＨＴＴＰ（HyperText Transfer Protocol）プロトコル及びＳＭＴＰ（Simple Mail Transfer Protocol）プロトコルによりトラヒック監視装置１００と通信する。
【００１２】
トラヒック監視装置１００は、ネットワークインタフェース部１１と、パケット収集部１２と、パケット記録部１３と、パケット統計情報収集部１４と、パケット情報ディスク１５と、ＧＵＩ表示機能部１７と、ワーム検出部２０と、ワーム検出結果通知部２１とを含む。
【００１３】
ネットワークインタフェース部１１は、監視対象となるＩＰネットワークに繋がるスイッチングハブ２００ａまたは共有ハブ２００ｂから、イーサネット（登録商標）パケットの全てを受信し取り込み、パケット記録部１３及びパケット統計情報収集部１４に受け渡す。パケット記録部１３は、全てのパケットをｒａｗパケット記録３１としてパケット情報ディスク１５に記録する。パケット統計情報収集部１４は、パケットの各ヘッダの情報を参照して、所定の分類項目（図４Ｂ参照）によって分類し、各分類先（エントリとも称する）毎にパケット数及びパケットサイズの累計を生成しパケット統計情報３２としてパケット情報ディスク１５に記録する。パケット統計情報３２は所定時間区間である５分間毎に生成される。該所定時間区間は５分間以外でも良く、例えば１時間または１日とすることができる。
【００１４】
ＧＵＩ表示機能部１７は、グラフ表示部１８と解析表示部１９とを含み、管理端末３００からの表示要求に応じてパケット統計情報をグラフや解析結果として出力する。ＧＵＩ表示機能部１７は、Ｗｅｂ上のサービスとして動作する。管理端末３００はＷｅｂブラウザを用いてＧＵＩ表示機能部１７にアクセスする。該アクセスの際に指定するＵＲＬには、ワーム検出時刻が埋め込めるようになっており、管理端末３００を操作する管理者はワーム検知結果通知メールに含まれるＵＲＬリンクを選択するだけで、当該ワームに関わるパケット統計情報を表示させることができる。
【００１５】
グラフ表示部１８は、パケット統計情報収集部１４が作成したパケット統計情報３２を基にグラフ表示を行う。グラフ表示の表示例が図５に示されている。該表示例では、プロトコル別のパケット数の時間変化がプロトコル別に色分けされて示される。これにより、どのプロトコルによるパケットが全トラヒック中でどのくらい占められているかを直感的に把握することができる。縦軸をプロトコル別のパケットサイズとしても良く、またはパケット数及びサイズの両方を表示するようにしても良い。該グラフにより色分けされる各プロトコルとしては、グラフ中の特定の時刻で、全プロトコル中で上位から所定数（例えば１０）のプロトコルについて色分けを行う。管理端末３００の管理者は、グラフ中の特定時刻をマウスで指定することより、その時刻で上位を占めるプロトコルを色分けして見ることができる。図５に示される例では、ワーム検出時刻前後の時間区間におけるパケットについて、ＴＣＰプロトコルのうちでポート番号４４５とポート番号８０であるものが異なるプロトコルのパケットであるとした集計表示がなされている。
【００１６】
解析表示部１９は、パケット記録部１３が作成したｒａｗパケット記録３１を参照し、パケットダンプ表示や上位ＩＰアドレス表示を行う。パケットダンプ表示は、パケットのヘッダ情報の解析結果表示や１６進ダンプを含む。上位ＩＰアドレス表示は、管理者が指定した時刻において記録されたパケットの送信元及び送信先のうちでパケット数またはパケットサイズが１番多いものから上位１０件の表示を行う。上位表示の数は１０件に限らず、管理者の指定により任意に変更しえる。
【００１７】
ワーム検出部２０は、パケット収集部１２から渡されたパケット情報を基にしてワーム感染の有無を検知する。ワームの検知方法は、例えば、スノート（snort）のプリプロセッサとして実現されているポートスキャン機能を用いることが考えられる。もちろん、ワームを検知できれば他の方法によっても良い。例えば、１定時間内に、所定閾値以上の数のＩＰアドレスに向けてパケットを送信している送信元ＩＰアドレスのコンピュータをワーム感染コンピュータとして検知する。該所定閾値としては、例えば、６０秒間に１００以上の異なる宛先ＩＰアドレスとすることが考えられる。
【００１８】
ワーム検出結果通知部２１は、ワーム検知部２１で検知されたワームの詳細情報をワーム検知結果通知メール５０として管理端末３００に通知する。ワーム検知結果通知メール５０の通知はＳＭＴＰを用いたメールにより実現され得る。図６を参照すると、ワーム検知結果通知メール５０の例が示されている。ここで、ワーム検知結果通知メール５０にはＧＵＩ表示機能部１７にアクセスするためのＵＲＬを含むアクセス情報５１が含まれる。アクセス情報５１には、ワーム検知時刻が含まれ得ることから、管理端末３００を操作する管理者はＵＲＬリンクを単純にマウスクリックすることで容易に当該ワーム検知時刻の時点を含むパケット統計情報を容易に参照することができる。ワーム検知結果通知メール５０は、さらに、ワーム感染が認められるコンピュータのＩＰアドレス、ワーム自己増殖活動の被害先のコンピュータのＩＰアドレス、ワーム自己増殖活動において用いられたポート番号（例えば、ＨＴＴＰＳ（Hyper Text Transfer Protocol over SSL）に割り当てられたＴＣＰ４４３ポート）、検出時刻等の情報が含まれ得る。
【００１９】
尚、図２に示される本実施例では、１つのスイッチングハブ２００ａ及び１つの共有ハブ２００ｂが示されたが、本発明によるトラヒック監視装置は、監視対象となるネットワークの規模に応じて、スイッチングまたは共有の各タイプに関わらず１つまたは複数のハブが接続され得る。
【００２０】
図３は、トラヒック監視装置とこれに協働する管理端末の処理手順を示している。ここで、トラヒック監視装置１００は、定常的に、スイッチングハブ及び共用ハブに流れるパケットを収集する（ステップＳ０１）。ここで、複数のパケットが所定時間（例えば、５分間）毎に収集され、各所定時間で分類されたパケット群を得る。次いで、該パケット群をｒａｗパケット記録として蓄積する（ステップＳ０２）。これに並行して、パケット統計情報の収集を行う（ステップＳ０３）。該パケット統計情報の収集においては、後述するパケット分類処理が実行される（図４Ａ及び４Ｂ参照）。
【００２１】
一方、管理者の操作に応じた管理端末３００は表示要求をトラヒック監視装置１００に送信し（ステップＳ０４）、該表示要求は表示対象のパケットの時刻または時刻範囲を指定することができる。これに応じて、トラヒック監視装置１００は、要求される時刻のパケット統計情報のグラフや解析結果を生成してＧＵＩ表示する（ステップＳ０５）。ここで、管理者の表示要求がパケットダンプ表示を要求している場合には、トラヒック監視装置１００は指示される時刻または時刻範囲のパケットをｒａｗパケット記録から抽出して、これを管理端末３００に向けてＧＵＩ出力することもできる。
【００２２】
一方、トラヒック監視装置１００のワーム検知部２０は、ワーム検知を定常的に実行する（ステップＳ０６）。ワーム検知の方法は、例えば、ｒａｗパケット記録から、一定時間内に所定閾値以上の数のＩＰアドレスに向けてパケットを送信しているコンピュータがあるか否かを監視し、もし該所定閾値を超えるコンピュータがあればこれをワーム感染コンピュータとして検知する。ここで、ワーム検知の有無を判定し（ステップＳ０７）、検知されない場合は検知を継続するが、もしワームか検知された場合には、ワーム検出時刻と共にワームを検出したことを告知するワーム検出結果通知メールを生成して、これを管理端末３００に向けて送信する（ステップＳ０８）。
【００２３】
該ワーム検出結果通知メールを受信した管理端末３００の管理者は、管理端末３００に対して、当該ワーム検出結果通知メールに含まれるアクセス情報であるＵＲＬリンクを指示することよりトラヒック監視装置１００に対して表示要求を行う（ステップＳ０９）。これに応じたトラヒック監視装置１００は、当該指定時刻のパケット統計情報のグラフや解析結果を生成してＧＵＩ表示する（ステップＳ１０）。これにより、管理者はワーム検出時刻前後のパケット統計情報を容易に参照することができる（図５参照）。
【００２４】
図４Ａは、パケット分類処理において基礎となる分類項目をまとめた表を示している。トラヒック監視装置に収集された多数のパケットは、本図に示された「項番」１〜１５に対応する各「項目名」の分類項目に従って分類されて、「カウント対象」に示されるパケット毎に統計処理のためのエントリが更新される。ここで、パケットのタイプがＴＣＰ及びＵＤＰである場合には、ポート番号の違い及び上がりと下りの違いをプロトコルの違いとしてパケット分類される。ポート番号の違いにより、ネットワーク階層においてＴＣＰ及びＵＤＰよりも上位にあるプロトコルが識別される。また、クライアントからサーバへの上がりパケットと、サーバからクライアントへの下りパケットの何れであるかが識別される。これは、単純にパケットの宛先ポートだけを参照していたのでは、上がりパケットと下りパケットが混在して統計処理されてしまい、生成されたパケット統計情報から有効な分析が行えないからである。
【００２５】
図４Ｂは、パケット分類処理の詳細な処理手順を示している。トラヒック監視装置１００は、収集されたパケット毎に以下の処理手順を実行する。トラヒック監視装置１０は、１つのパケットを読み込み（ステップＳ２１）、その内容を参照して、図４Ａに示された分類項目に従ってパケットを識別する（ステップＳ２２）。次いで、分類項目がＴＣＰまたはＵＤＰであるか否かを判定する（ステップＳ２３）。もし分類項目がＴＣＰまたはＵＤＰである場合にはステップＳ２５以降の上がり下り分類処理に進むが、それ以外は当該分類項目に従ったエントリを更新する。
【００２６】
パケットの分類項目がＴＣＰまたはＵＤＰである場合には、トラヒック監視装置１００は上がり下り分類処理を実行する。先ず、当該パケットについてパケット宛先ポートの番号を判定する（ステップＳ２５）。もし、該パケット宛先ポートの番号が１０２４未満である場合には、当該パケットは上がりパケットであると認識して、ＴＣＰ（宛先ポート）の統計情報エントリを更新する（ステップＳ３０）。
【００２７】
一方、宛先ポートの番号が１０２４以上である場合には、トラヒック監視装置１００は、さらにパケット宛先ポートの番号がサービスポート番号であるか否かを判定する（ステップＳ２６）。ここで、もしパケット宛先ポートの番号がサービスポート番号である場合にも、当該パケットは上がりパケットであると認識して、ＴＣＰ（宛先ポート）の統計情報エントリを更新する（ステップＳ３０）。
【００２８】
一方、パケット宛先ポートの番号がサービスポート番号でない場合には、トラヒック監視装置１００は、当該パケットの送信元ポートの番号を判別する（ステップＳ２７）。もし送信元ポートの番号が１０２４未満である場合には、当該パケットは下りパケットであると認識して、ＴＣＰ（送信元ポート）の統計情報エントリを更新する（ステップＳ２９）。
【００２９】
一方、送信元ポートの番号が１０２４以上である場合には、トラヒック監視装置１００は、さらにパケット送信ポートの番号がサービスポート番号であるか否かを判定する（ステップＳ２８）。ここで、もしパケット送信元ポートの番号がサービスポート番号である場合には、当該パケットは下りパケットであると認識して、ＴＣＰ（送信元ポート）の統計情報エントリを更新する（ステップＳ２９）。
【００３０】
一方、パケット送信元ポートの番号がサービスポート番号でない場合には、トラヒック監視装置１００は、当該パケットは上がりパケットであると見做して、ＴＣＰ（宛先ポート）の統計情報エントリを更新する（ステップＳ３０）。
【００３１】
以上の実施例から明らかなように、本発明によるトラヒック監視装置によれば、プロトコル別に作成されたパケット統計情報がグラフ表示され、管理者はワームが発生し時刻におけるトラヒックの詳細状態を参照することができる。これにより、ワームがネットワークに与える影響度、すなわちトラヒックの帯域圧迫をもたらす波及的影響を的確に予測することが可能となる。また、トラヒック監視装置に継続的にトラヒックの情報が蓄積されるために、ワーム検出時と、平常時のトラヒックの状況の比較を容易に行うことができる。併せて、ｒａｗパケット記録がトラヒック監視装置に蓄積されることによりワーム検出時の実トラヒックを事後解析することも可能となる。
【図面の簡単な説明】
【００３２】
【図１】ワームによるネットワーク被害を説明するための説明図である。
【図２】本発明の実施例を示し、トラヒック監視装置の構成を示しているブロック図である。
【図３】トラヒック監視装置とこれに協働する管理端末の処理手順を示しているシーケンス図である。
【図４Ａ】パケット分類処理において基礎となる分類項目をまとめた表を示している図である。
【図４Ｂ】パケット分類処理の詳細の処理手順を示しているフローチャートである。
【図５】管理端末において表示されるパケット統計情報の表示例を示している図である。
【図６】管理端末に通知されるワーム検知結果メールの内容例を示している図である。
【符号の説明】
【００３３】
１１  ネットワークインタフェース部
１２  パケット収集部
１３  パケット記録部
１４  パケット統計情報収集部
１５  パケット情報ディスク
１７  ＧＵＩ表示機能部
１８  グラフ表示部
１９  解析表示部
２０  ワーム検出部
２１  ワーム検出結果通知部
３１  ｒａｗパケット記録
３２  パケット統計情報
５０  ワーム検出結果通知メール
５１  アクセス情報
１００  トラヒック監視装置
２００ａ  スイッチングハブ
２００ｂ  共有ハブ
３００  管理端末
【図１】
2006333089.tif 000003
【図２】
2006333089.tif 000004
【図３】
2006333089.tif 000005
【図４Ａ】
2006333089.tif 000006
【図４Ｂ】
2006333089.tif 000007
【図５】
2006333089.tif 000008
【図６】
2006333089.tif 000009