JP2005130121A - ネットワーク管理装置、ネットワーク管理方法、ネットワーク管理プログラム - Google Patents

Abstract

【課題】ＩＰネットワークにおけるＤｏＳ攻撃判定の精度を高め、経路検出時間の短縮を図り、更にはＩＰトレースバック逆探知パケットの送信数を軽減する。
【解決手段】サーバ１Ｂは、トラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、両値の差分が閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減をＤｏＳ攻撃判断条件として追加した第１の機能、ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度によりＤｏＳ攻撃の有無を判断する第２の機能、受信データのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能、自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能等の協働によりＤｏＳ攻撃の有無を判断する。
【選択図】 図１

Description

本発明は、例えばＩＰネットワークを管理する装置、方法、プログラムに係り、特にＤｏＳ攻撃の有無を判別して適宜ＩＰトレースバック逆探知パケットを送出するネットワーク管理装置、ネットワーク管理方法、ネットワーク管理プログラムに関する。

従来、大量のデータや不正なパケットを送信し、サービスの提供を困難にさせるサービス妨害（Dos；Denial of service）攻撃が問題となっている。このＤｏｓ攻撃では、特定のインターネットサーバに対して大量のパケットを送信することで、攻撃対象となるサーバをリソース不足に陥らせ、アクセス不能状態させるのが一般的な手法である。このＤｏＳ攻撃には、所定のツールが利用されるが、ツールにより攻撃対象や方法は異なる。

代表的なツールとして、ＩＣＭＰ(Internet Control Message Protocol)によるエコー要求を実施するSmurf DosやＳＹＮ(synchronous)技術を用いるＴＦＮ等がある。多くの場合では、分散型ＤｏＳ（DDos；Distributed Denial of service）攻撃と称される、異なるコンピュータからの攻撃を行うことから、攻撃元を特定するのは困難である。

このような問題に鑑みて、非特許文献１では、ＩＰトレースバック逆探知パケット方式のトラヒック量と攻撃経路再構成時間の性能評価における逆探知パケット方式が開示されている。この方式では、ＩＰオプショントレースバックにより、自律システム（AS；Autonomous System）単位で攻撃元と想定されるＩＰパケットを追跡し、通過ＡＳ情報をトレースパケットに格納し、その情報に基づいて攻撃元までの経路を構築している。

一方、特許文献１では、クライアント計算機から送られてくるアクセス要求パケットをサーバ計算機の代わりに受け付けるアクセス要求受付けと受け付けたアクセス要求パケットの正当性を検査し、正当性が認められた場合にのみサーバ計算機へパケットを転送する技術が開示されている。尚、この技術では、アクセス正当性検査手段として、アクセス要求パケットが一連の接続要求パケット、確認応答パケット及びデータ要求パケットであることを正当なアクセス要求条件として採用している。
特開２００３−１７３３００号公報 奈良先端大学化学技術大学院大学 澤井裕子、"ＩＰトレースバック逆探知パケット方式のトラヒック量と攻撃経路再構成時間の性能評価"、［on line］、［平成１５年１０月８日検索］、インターネット＜URL:http://www.ieice.org/cs/ia/ipn/conference/200207/presentation/Sawai.pdf＞

上記非特許文献１に開示の技術では、攻撃元を特定するために、確率Ｐでトレースパケットを送信している。この確率Ｐは、トレースパケット数や攻撃経路の検出時間に影響を与える。即ち、確率Ｐが大きくなるとトレースパケット数を増加させる反面、トラヒックが増加する為、輻輳を引き起こす可能性が高まる。一方、確率Ｐが小さくなると、攻撃経路の検出時間の増加を引き起こすことになる。検出時間の長期化によりサービス不能となる可能性が高まるため、攻撃元の特定や攻撃回避といった対応が困難となり、被害が拡大する。また、この技術では、ＤｏＳ攻撃か否かという判断は一切行われていない。

また、不特定のパケットにＩＰトレースバック逆探知パケットを送信することから精度には限界があり、精度を高める為にトレースパケットの生成確率を高めると、トレースパケット数が増加してしまい、輻輳を引き起こす可能性がある。

一方、上記特許文献１により開示された従来技術では、ＤｏＳ攻撃に係るパケットが一連の接続要求パケットや確認応答パケット、データ要求パケットであった場合には、ＤｏＳ攻撃の正当性を評価する事ができない点が問題となっている。

本発明は、上記問題に鑑みてなされたもので、その目的とするところは、複数のエージェントの異なるポリシーによる総合的な判断により、ＩＰネットワークにおけるＤｏＳ攻撃判定の精度を高め、経路検出時間の短縮を図り、更にはＩＰトレースバック逆探知パケットの送信数を軽減することでトラヒックへの影響を軽減することにある。

上記目的を達成するために、本発明の第１の態様では、複数の端末装置と共に情報通信網に接続され、当該端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置において、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理するトラヒック情報管理手段と、上記トラヒック情報管理手段により管理されているトラヒック情報と現在のトラヒック情報とを比較するトラヒック情報比較手段と、上記トラヒック情報比較手段により比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断するＤｏＳ判断手段と、上記ＤｏＳ判断手段によりＤｏＳ攻撃と判断された場合に逆探知用パケットを送出する逆パケット送出手段と、を有することを特徴とするネットワーク管理装置が提供される。

本発明の第２の態様では、上記第１の態様において、上記閾値は、伝送レートに応じた定数であることを更に特徴とするネットワーク管理装置が提供される。

本発明の第３の態様では、複数の端末装置と情報通信網を介して接続され、当該端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置において、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断するＤｏＳ判断手段を有することを特徴とするネットワーク管理装置が提供される。

本発明の第４の態様では、上記代３の態様において、上記ＤｏＳ判断手段は、上記第１乃至第４の機能による判断結果をコスト値に変換するコスト値変換手段と、上記各コスト値に、ＩＰアドレス、ポート番号又はアプリケーションに応じた定数を乗算した値の総和を総数として算出する総数算出手段と、を更に有し、上記総数に応じてＤｏＳ攻撃を判断することを更に特徴とするネットワーク管理装置が提供される。

本発明の第５の態様では、上記第３又は第４の態様において、上記ＤｏＳ判断手段は、 上記トラヒック情報管理手段により管理されているトラヒック情報と現在のトラヒック情報を比較し、両値の差分が予め定められた閾値以上の場合、外部装置に現在及びそれ以降のトラヒック情報を管理させる手段を更に有し、当該外部装置にてＤｏＳ攻撃を判断することを更に特徴とするネットワーク管理装置が提供される。

本発明の第６の態様では、情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置によるネットワーク管理方法において、上記ネットワーク管理装置が、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報とを比較し、比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断し、逆探知用パケットを送出することを特徴とするネットワーク管理方法が提供される。

本発明の第７の態様では、情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置によるネットワーク管理方法において、上記ネットワーク管理装置が、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断することを特徴とするネットワーク管理方法が提供される。

本発明の第８の態様では、情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置に用いるネットワーク管理プログラムにおいて、上記ネットワーク管理装置が、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報とを比較し、比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断し、逆探知用パケットを送出する、ためのネットワーク管理プログラムが提供される。

本発明の第９の態様では、情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置に用いるネットワーク管理プログラムにおいて、上記ネットワーク管理装置が、上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断するためのネットワーク管理プログラムが提供される。

本発明によれば、複数のエージェントの異なるポリシーによる総合的な判断により、ＩＰネットワークにおけるＤｏＳ攻撃判定の精度を高め、経路検出時間の短縮を図り、更にはＩＰトレースバック逆探知パケットの送信数を軽減することでトラヒックへの影響を軽減するネットワーク管理装置及びネットワーク管理方法を提供することができる。

以下、図面を参照して、本発明の一実施の形態について説明する。

先ず、図１には、本発明の一実施の形態に係るネットワーク管理装置の概念図を示し説明する。尚、ネットワーク管理装置は、サーバ１Ａ又は１Ｂに相当する。

図１に示されるように、ＡＳ４内では、複数のルータ３Ａ乃至３Ｄが通信自在に接続されている。これらルータ３Ａ乃至３Ｄのうち、エッジノードであるルータ３Ａは外部の情報通信網（ネットワーク）５に接続されており、当該ルータ３Ａにはトラヒック情報を監視するサーバ１Ａが通信自在に接続されている。サーバ１Ａは、周期的に収集されたトラヒック情報をトラヒックパターンとして格納する為のデータベース（以下、これをＤＢと略記する）２Ａと接続されている。ルータ３Ａは、ネットワークドメイン内部又は外部のサーバ１Ｂとも通信自在に接続されている。当該サーバ１ＢはＤｏＳ攻撃対象候補となったトラヒック情報を格納するＤＢ２Ｂと接続されている。本実施の形態では、サーバ１Ｂには、ＤｏＳ攻撃の特定やＤＢ２Ｂに格納されたトラヒック情報の対処を決定するＤｏＳ攻撃判別エージェントが常駐している。このエージェントについては後述する。

このような実施の形態に係るネットワーク管理装置は、例えばサーバ１Ａ，１Ｂ等が以下のような作用を奏する。即ち、より具体的には、例えばサーバ１Ａ又は１Ｂのいずれかにおいて、ネットワーク５を介して接続された外部の端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報とを比較し、比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断した場合には、逆探知用パケットを送出する。

尚、この閾値は、伝送レートに応じた定数であることとしてもよい。

或いは、例えばサーバ１Ａ又は１Ｂのいずれかにおいて、ネットワーク５を介して接続された端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加したリンクエージェント機能と、ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断するFrequenyエージェント機能と、上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断するAppcheckエージェント機能と、自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断するSrvrMonitorエージェント機能と、の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断する。

さらに、詳細は後述するが、サーバ１Ａ又は１Ｂのいずれかにおいて、これら機能による判断結果をコスト値に変換し、上記各コスト値に、ＩＰアドレス、ポート番号又はアプリケーションに応じた定数を乗算した値の総和を総数として算出し、上記総数に応じてＤｏＳ攻撃を判断する。また、一のサーバ（例えばサーバ１Ａ）で管理されているトラヒック情報と現在のトラヒック情報を比較し、両値の差分が予め定められた閾値以上の場合には、外部装置としての他のサーバ（例えばサーバ１Ｂ）に現在及びそれ以降のトラヒック情報を管理させ、当該外部装置にてＤｏＳ攻撃を判断する。以上のような作用は、ネットワーク管理装置としてのサーバ１Ａ，１Ｂ、或いは不図示の他のサーバにより単独で、或いは複数のサーバが協働して奏するものであることは勿論である。

次に、図２，３には、サーバ１Ａ，１Ｂの構成を更に具現化して示し説明する。

尚、以下に説明する各サーバ１Ａ，１Ｂの有する機能は、説明の便宜上、一例として特定したに過ぎず、互いの機能を入れ換えたり、一部機能を協働させることもできる。

先ず、図２に示されるように、このサーバ１Ａは、トラヒック収集機能１１、トラヒック比較機能１２、トラヒックパターン作成機能１３、トラヒックパターン収集・格納機能１４、通信機能１５、トラヒック判断機能１６を有している。

トラヒック収集機能１１及びトラヒックパターン収集・格納機能１４は、ＤＢ２Ａと通信可能である。通信機能１５は、サーバ１Ｂ、外部のネットワーク５を介して不図示の複数の端末装置と通信可能である。

このような構成において、トラヒック収集機能１１は、ＩＰアドレス毎のトラヒック情報を周期的に収集する。トラヒックパターン作成機能１３は、この収集したトラヒック情報について、日、週、月、年毎の伝送レートの変化をＩＰアドレス毎にトラヒックパターンとして作成する。トラヒックパターン収集・格納機能１４は、当該トラヒックパターンをＤＢ２Ａに格納する。トラヒック比較機能１２は、サーバ１Ａが収集した送信元アドレス毎の伝送レートとＤＢ２Ａに格納されたトラヒックパターンとを比較する。トラヒック判断機能１６は、この判断の結果を受け、両者の間に所定値以上の差が発生した場合には、更にＤｏｓ攻撃の有無を判断するために、通信機能１５を介してＩＰパケットを自ネットワークドメイン内／外に設置されたサーバ１Ｂを経由してＤＢ２Ｂに格納する。このとき、即ち、Ｄｏｓ攻撃であると判断した場合に、ＩＰトレースバック逆探知用パケットを送出するようにすることも可能である。尚、上記所定値とは、伝送レートに応じて予め決められた定数であるが、これに限定されないことは勿論である。

ここで、請求項に記載のトラヒック情報管理手段とはトラヒック収集機能１１、トラヒックパターン作成機能１３、トラヒック収集・格納機能１４等に相当し、トラヒック情報比較手段とはトラヒック比較機能１２に相当し、Ｄｏｓ判断手段とはトラヒック判断機能１６等に相当し、逆パケット送出手段とは通信機能１５等に相当する。但し、これら関係には限定されないことは勿論である。

次に図３に示されるように、サーバ１Ｂは、トラヒック収集・格納機能２１、リンクエージェント機能２２、フリクエンシ(以下、Frequencyとする)エージェント機能２３、アプリケーションチェック（以下、Appcheckとする）エージェント機能２４、サーバモニタ（以下、SrvrMonitorとする）エージェント機能２５、通信機能２６、ランキング／コスト値決定機能２７、補正値決定機能２８を有する。即ち、サーバ１Ｂは、ＤｏＳ攻撃を判断する為に、協働する各種のエージェント機能２２乃至２５を有している。

このような構成において、トラヒック収集・格納機能２１は、ＩＰアドレス毎のトラヒック情報を周期的に収集し、ＤＢ２Ｂに格納する。ランキング／コスト値決定機能２７は、詳細は後述するが、ランキングとコスト値とを対応付けたテーブルを参照して、ランキングに対応するコスト値を決定する。リンクエージェント機能２２は、定期的に収集されたリンクパターンの変化やリンク数により規定値の信頼性を判断する。Frequencyエージェント機能２３は、過去にＤｏＳ攻撃を仕掛けてきたＩＰアドレスを記録し、一定期間におけるＤｏＳ攻撃の頻度によりＤｏＳ攻撃の可能性を判断する。

そして、Appcheckエージェント機能２４は、上記サーバ１Ａより収集されたＩＰパケットのペイロードの記述内容によりＤｏＳ攻撃の可能性を判断する。SrvrMonitorエージェント機能２５は、自ドメイン内の攻撃対象となり得るＷｅｂサーバやＦＴＰサーバ、メールサーバのリソースを管理し、ＤｏＳ攻撃の可能性を判断する。そして、補正値決定機能２８は、前述したような各種エージェント２２乃至２５の判断結果に基づいて、詳細は後述するが、コスト補正用定数（補正値）、総数を決定する。

尚、請求項に記載の第１の機能とはリンクエージェント機能２２等に相当し、第２の機能とはFrequencyエージェント機能２３等に相当し、第３の機能とはAppcheckエージェント機能２４等に相当し、第４の機能とはSrvrMonitorエージェント機能２５等に相当する。そして、Ｄｏｓ判断手段とは、ランキング／コスト値決定機能２７、補正値決定機能２８等を含む広い概念である。さらに、請求項に記載のコスト値変換手段とはランキング／コスト値決定機能２７等に相当し、総数算出手段とは補正値決定機能２８等に相当するものである。但し、これらの関係には限定されない。

以下、図４のフローチャートを参照して、上記構成による作用を詳述する。

これは、本実施の形態に係るネットワーク管理方法に相当する。或いは、本実施の形態に係るネットワーク管理プログラムのアルゴリズムに相当する。

先ず、サーバ１Ａは、外部のネットワーク５に接続されているエッジノードにて、トラヒック収集機能１１により、ＩＰアドレス毎のトラヒック情報を周期的に収集する（ステップＳ１）。このサーバ１Ａが収集する情報には、例えば、日、月、周、年毎のトラヒック情報がある。そして、このトラヒック情報には、例えば図７に示されるように、送信元アドレス、宛先アドレス、測定時刻、伝送レート等が含まれている。

そして、サーバ１Ａは、トラヒックパターン作成機能１３により、収集した各種情報を基にして、日、週、月、年毎の伝送レートの変化をＩＰアドレス毎にトラヒックパターンとして作成し、トラヒックパターン収集・格納機能１４により、ＤＢ２Ａに格納する（ステップＳ２）。トラヒックパターンは、例えば図８に示される通りであり、送信元アドレス、宛先アドレス、トラヒックの変化（１日、週、月、年）、Ｄｏｓ攻撃の可能性を判断するための閾値を含んでいる。但し、これには限定されない。

続いて、サーバ１Ａは、ＤｏＳ攻撃の判別を行う。即ち、トラヒック比較機能１２により、サーバ１Ａが収集した送信元アドレス毎の伝送レートとＤＢ２Ａに格納されたトラヒックパターンとを比較し（ステップＳ３，Ｓ４）、両者の間に所定値（伝送レートに応じて予め決められた定数）以上の差が発生した場合には、通信機能１５により、ＩＰパケットを自ネットワークドメイン内／外に設置されたサーバ２Ａを経由してＤＢ２Ｂに格納する。ＤＢ２Ｂに格納するＩＰパケットは、自ネットワークドメイン内へ流入するトラヒック全て、一部或いは所定値以上の差が発生したＩＰアドレスである。

尚、サーバ１Ａが単独で処理する場合においては、上記比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断した場合に、所定の逆探知用パケットを送出するようにしてもよいことは勿論である。

次いで、通信機能２６及びトラヒック収集・格納機能２１によりＤＢ２Ｂに収集されたＩＰパケットに対して、サーバ１Ｂが有する、異なるポリシーを持つ複数のＤｏＳ攻撃判別エージェント機能２２乃至２５が協調し、上記ＤＢ２Ｂに格納されているトラヒックに対して、ＤｏＳ攻撃の判定を実施する（ステップＳ５乃至ステップＳ１１）。即ち、ＤｏＳ攻撃判別エージェントとしての、リンクエージェント機能２２、Frequencyエージェント機能２３、Appcheckエージェント機能２４、SrvrMonitorエージェント機能２５は、それぞれのアルゴリズムに基づいて、ＤｏＳ攻撃の可能性を判定する。

以下、各エージェント機能について更に詳細に説明する。

リンクエージェント機能２２は、インターネット上のＷｅｂページのリンク数及びリンク数の変化によりＤｏＳ攻撃に対する判定の信頼度をランキング化するものであり、過去のリンク数と現在のリンク数の変化が所定の閾値以下ならばＤｏＳ攻撃と判断する。一般に、トラヒックパターンと現行トラヒックの伝送レートに一定以上の差がある場合、ＤｏＳ攻撃の可能性がある反面、誤差或いはアクセス数の増加に起因するトラヒック増の可能性がある。そこで、リンクエージェント機能２２では、Ｗｅｂページのリンク数やリンク数の変化によりＤｏＳ攻撃の可能性を検討する。Ｗｅｂページに張られているリンク数は重要度／人気度を示すパラメータであり、リンク数が多い程その重要度／人気度は高くなる。インターネット上のＷｅｂページのリンク数やリンク数の変化を周期的に収集し、リンクパターンとしてＤＢ２Ｂに記録する。

このリンクパターンは、例えば図９に示される通りであり、送信元アドレス、宛先アドレス、測定時刻、リンクパターン（日、週、月、年）が含まれている。このようなリンクパターンより傾向を判断し、ＤｏＳ攻撃の可能性をランキングする。

ランキング換算表は、例えば図１０に示される通りであり、ランクＡ（ＤｏＳ攻撃の可能性大；コスト値Ａ）、ランクＢ（ＤｏＳ攻撃の可能性中；コスト値Ｂ）、ランクＣ（ＤｏＳ攻撃の可能性小；コスト値Ｃ）、及びランクＤ（ＤｏＳ攻撃の可能性極めて低い；コスト値Ｄ）に分けられる。即ち、リンクエージェント機能２２は、図８よりトラヒックの変化を検出し、平均的なトラヒックの変化との相対的な評価で予め定められた図９のランキング換算表を参照して、対応するコスト値を決定することになる。

一方、Frequencyエージェント機能２３は、過去に自ドメイン／他ドメインに対してＤｏＳ攻撃を仕掛けてきたＩＰアドレスを記録し、一定期間において自ドメイン／他ドメインに攻撃を仕掛けた頻度が閾値を超えた場合、ＤｏＳ攻撃と判断する。

一般に、ＤｏＳ攻撃を仕掛ける場合、インターネット上のコンピュータを踏み台とする場合が多く、踏み台とされるコンピュータはセキュリティレベルが低いと考えられる。セキュリティ管理には、高度な知識と技術が必要であり、これらが不足していると、頻繁に踏み台にされる可能性が高い。そこで、Frequencyエージェント機能２３は、過去の自ドメインに対する攻撃頻度をＩＰアドレス毎に記録し、一定期間におけるその頻度によりＤｏＳ攻撃の可能性を検討する。この過去の自ドメインに対する攻撃頻度は、例えば図１１に示される通りであり、送信元アドレス、宛先アドレス、測定期間、攻撃回数が対応付けられている。ランキング換算表は、図１２に示される通りであり、平均的な攻撃回数との相対的な評価で、段階的にランク及び対応するコスト値を予め定めている。

即ち、図１２の例では、攻撃頻度が高いＩＰアドレスをランクＡ（コスト値Ａ）、攻撃頻度が中程度のＩＰアドレスをランクＢ（コスト値Ｂ）、攻撃頻度が低いＩＰアドレスをランクＣ（コスト値Ｃ）、及び過去に攻撃を仕掛けていないＩＰアドレスをランクＤ（コスト値Ｄ）としている。Frequencyエージェント機能２３は、図１１より攻撃頻度等を把握した上で、ランキング／コスト値決定機能２７を用いて、図１２のランキング換算表を参照して、コスト値を決定することになる。

Appcheckエージェント機能２４は、ＩＰアドレス全て或いは一部で取り出したＩＰアドレスに対して、ペイロードの記述内容の検査を実施し、ＤｏＳ攻撃を判別する。多くの場合、ＤｏＳ攻撃にＤｏＳ攻撃ツールが用いられるが、このようなルーツを利用したＤｏＳ攻撃の場合には、ペイロードを検査する（例えば、パターンマッチング等）ことで発見することができる。そこで、Appcheckエージェント機能２４は、ＤＢ２Ｂに格納されているＩＰアドレス全て或いは一部で取り出したＩＰアドレスに対してペイロードの検査を実施する。ＩＰｖ４ヘッダフォーマット、ＩＰｖ６ヘッダフォーマットの構成は、図５及び図６に示される通りであり、ＩＰｖ４であれば図５にデータ(Data)と示した部分を、ＩＰｖ６であれば図６にPayroad（データ）と示した部分を検査する。

尚、この各フォーマットは一般的であるので、これ以上の説明は省略する。

この検査の結果は、例えば図１３に示されるようになり、Ｄｏｓ攻撃タイプとＤｏｓ攻撃用判別パターンが対応付けられる。尚、ランキング換算表は、図１４に示され、ＤｏＳ攻撃用パケットと判断されたＩＰパケットはランクＡ（コスト値Ａ）とし、Ｄｏｓ攻撃用パケットではない場合はランクＤ（コスト値Ｄ）と予め定めている。

つまり、Appcheckエージェント機能２４は、図１３よりＤｏｓ攻撃タイプとＤｏｓ攻撃用判別パターンを検出し、ランキング／コスト値決定機能２７を用いて、図１４のランキング換算表を参照してコスト値を決定することになる。

SrvrMonitorエージェント機能２５は、自ドメイン内の攻撃対象となるサーバの状態を監視し、ＤｏＳ攻撃を判断する。より具体的には、ＴＣＰパケットに対するＳｙｎパケットの割合が閾値以上場合、或いは受信したＩＰアドレスに違法性（例えば、顧客以外のＩＰパケット）があると判断された場合、ＤｏＳ攻撃と判断する。一般に、Ｄｏｓ攻撃には、ＳＹＮ技術やＩＣＭＰエコー要求を利用したものがある。

サーバ１Ｂは、顧客ＩＰアドレスとポート番号の関係を図１５に示されるようなテーブルで管理している。サーバ１Ｂは、ＴＣＰパケットに対するＳｙｎパケットの割合の監視や顧客ＩＰアドレスと受信ＩＰアドレスの比較を実施し、図１６に示されるようなテーブルを作成する。そして、このテーブルよりＤｏｓ攻撃の可能性を判定する。ランキング換算表は、図１７に示される通りである。即ち、このランキングは、ランクＡ（Ｄｏｓ攻撃の可能性大；閾値Ａ、コスト値Ｅ）、ランクＢ（Ｄｏｓ攻撃の可能性中；閾値Ｂ、コスト値Ｆ）、ランクＣ（Ｄｏｓ攻撃の可能性小；閾値Ｃ、コスト値Ｇ）、及びランクＤ（Ｄｏｓ攻撃の可能性が極めて低い；閾値Ｄ、コスト値Ｈ）に分けられる。SrvrMonitorエージェント機能２５は、ランキング／コスト値決定機能２７を用いて、図１７のランキング換算表を参照してコスト値を決定する。

以上のように、各エージェント機能２２乃至２５による各判定はランキングされ、それに対応したコスト値が決定される。そして、補正値決定機能２８は、図１８のテーブルを参照して、コスト補正用定数α，β，γ，θを算出し、各エージェント２２乃至２５の算出したコスト値の総和をＧとし、Ｇの値によりＩＰアドレスに対する処置を決定する。

ここで、総和Ｇは、
Ｇ＝αCost（リンクエージェント）＋βCost（Frequencyエージェント）
＋γCost（Appcheckエージェント）＋θCost（SrvrMonitorエージェント）
で表され、α、β、γ及びθは、例えばＩＰアドレス、ポート番号、アプリケーションの種類等により特定されるアクセス先（例えば、ＨＴＴＰサーバ、ＭａｉｌサーバあるいはＦＴＰサーバ等）により変化する定数（０を含む）である。

例えば、以下のような対処が考えられる。

Ｇ＝００〜２０：ＤＢ２Ｂに格納したトラヒックを自ネットワークに転送
Ｇ＝２１〜４０：ユーザ／管理者に対してＤｏＳ攻撃の可能性を通知
Ｇ＝４１〜８０：ユーザ／管理者への通知及びトレースパケットの送信
Ｇ＝８１ ：ユーザ／管理者への通知、トレースパケットの送信及び廃棄
一例として、ＤＢ２Ｂに格納されたＩＰアドレスに対して、リンクエージェントがコスト値３０（ランクＢ）、Frequencyエージェントがコスト値４０（ランクＡ）、Appcheckエージェントがコスト値０（ランクＤ）、SrvrMonitorエージェントがコスト値０（ランクＤ）と判断し、α＝β＝γ＝θ＝１である場合には、総数Ｇは、
Ｇ＝３０＋４０＋０＋０＝７０
となる。この場合には、上記対処に従い、サーバ１Ｂは、ユーザ／管理者への通知及びＩＰトレースバック逆探知パケットの送信を実施することになる。

このように、サーバ１Ｂは、このＤｏＳ攻撃判別エージェントの判定により、ＩＰトレースバック逆探知パケットの送信、管理者／ユーザへの通知、パケット廃棄のユーザへの送信を適宜実施する（ステップＳ１２乃至Ｓ１４）。

以上説明したように、本発明の実施の形態によれば、複数のポリシーによる総合的な判断により、ＤｏＳ攻撃判定の精度を高めることができる。また、ＤｏＳ攻撃の有無を判定してから、トレースパケットを生成するため、トレースパケットの送信数を軽減でき、ネットワークに対する負荷を小さくすることができる。

尚、本発明は、上記実施の形態に限定されることなく、その主旨を逸脱しない範囲で種々の改良・変更が可能であることは勿論である。例えば、Ｄｏｓ攻撃判定のために協働するエージェントは、前述したものには限定されない。

本発明の一実施の形態に係るネットワーク管理装置の概念図。 サーバ１Ａの構成を更に具現化して示した図。 サーバ１Ｂの構成を更に具現化して示した図。 本発明の一実施の形態に係るネットワーク管理装置によるＤｏｓ攻撃の有無の判断手順を説明するためのフローチャート。 ＩＰｖ４ヘッダフォーマットを示す図。 ＩＰｖ６ヘッダフォーマットを示す図。 トラヒック情報に係るテーブル。 トラヒックパターンに係るテーブル。 リンクパターンに係るテーブル。 リンクエージェント機能２２が用いるランキング換算表を示す図。 過去の自ドメインに対する攻撃頻度に係るテーブル。 Frequencyエージェント機能２３が用いるランキング換算表を示す図。 Ｄｏｓ攻撃タイプとＤｏｓ攻撃用判別パターンが対応付けたテーブル。 Appcheckエージェント機能２４が用いるランキング換算表を示す図。 顧客ＩＰアドレスとポート番号との関係に係るテーブル。 ＴＣＰパケット数に対するＳｙｎパケット数の割合等に係るテーブル。 SrvrMonitorエージェント機能２５が用いるランキング換算表を示す図。 コスト補正用定数に係るテーブル。

符号の説明

１Ａ，１Ｂ・・・サーバ、２Ａ，２Ｂ・・・ＤＢ、３Ａ〜３Ｄ・・・ルータ、４・・・ＡＳ、５・・・ネットワーク、１１・・・トラヒック格納機能、１２・・・トラヒック比較機能、１３・・・トラヒックパターン作成機能、１４・・・トラヒックパターン収集・格納機能、１５・・・通信機能、２１・・・トラヒック収集・格納機能、２２・・・リンクエージェント機能、２３・・・Frequencyエージェント機能、２４・・・Appcheckエージェント機能、２５・・・SrvrMonitorエージェント機能、２６・・・通信機能、２７・・・ランキング／コスト値決定機能、２８・・・補正値決定機能。

Claims (9)

1. 複数の端末装置と共に情報通信網に接続され、当該端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置において、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理するトラヒック情報管理手段と、
   上記トラヒック情報管理手段により管理されているトラヒック情報と現在のトラヒック情報とを比較するトラヒック情報比較手段と、
   上記トラヒック情報比較手段により比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断するＤｏＳ判断手段と、
   上記ＤｏＳ判断手段によりＤｏＳ攻撃と判断された場合に逆探知用パケットを送出する逆パケット送出手段と、
   を有することを特徴とするネットワーク管理装置。
2. 上記閾値は、伝送レートに応じた定数であることを更に特徴とする請求項１に記載のネットワーク管理装置。
3. 複数の端末装置と情報通信網を介して接続され、当該端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置において、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、
   ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、
   上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、
   自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、
   の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断するＤｏＳ判断手段を有することを特徴とするネットワーク管理装置。
4. 上記ＤｏＳ判断手段は、
   上記第１乃至第４の機能による判断結果をコスト値に変換するコスト値変換手段と、
   上記各コスト値に、ＩＰアドレス、ポート番号又はアプリケーションに応じた定数を乗算した値の総和を総数として算出する総数算出手段と、
   を更に有し、上記総数に応じてＤｏＳ攻撃を判断することを更に特徴とする請求項３に記載のネットワーク管理装置。
5. 上記ＤｏＳ判断手段は、
   上記トラヒック情報管理手段により管理されているトラヒック情報と現在のトラヒック情報を比較し、両値の差分が予め定められた閾値以上の場合、外部装置に現在及びそれ以降のトラヒック情報を管理させる手段を更に有し、
   当該外部装置にてＤｏＳ攻撃を判断することを更に特徴とする請求項３又は４のいずれかに記載のネットワーク管理装置。
6. 情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置によるネットワーク管理方法において、
   上記ネットワーク管理装置が、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、
   この管理されているトラヒック情報と現在のトラヒック情報とを比較し、
   比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断し、逆探知用パケットを送出する、
   ことを特徴とするネットワーク管理方法。
7. 情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置によるネットワーク管理方法において、
   上記ネットワーク管理装置が、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、
   ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、
   上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、
   自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、
   の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断することを特徴とするネットワーク管理方法。
8. 情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置に用いるネットワーク管理プログラムにおいて、
   上記ネットワーク管理装置が、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、
   この管理されているトラヒック情報と現在のトラヒック情報とを比較し、
   比較した両値の差分が予め定められた閾値以上の場合にＤｏＳ攻撃であると判断し、逆探知用パケットを送出する、
   ためのネットワーク管理プログラム。
9. 情報通信網を介して接続された端末装置より送出されたデータのトラヒック情報を管理するネットワーク管理装置に用いるネットワーク管理プログラムにおいて、
   上記ネットワーク管理装置が、
   上記端末装置のトラヒック情報をＩＰアドレス毎に定期的に収集及び管理し、この管理されているトラヒック情報と現在のトラヒック情報を比較し、比較結果である両値の差分が予め定められた閾値以上である場合にＤｏＳ攻撃と判断する機能であって、自ホームページに対するリンク数の増減を更にＤｏＳ攻撃判断条件として追加した第１の機能と、
   ＤｏＳ攻撃の履歴をＩＰアドレス毎に管理し、一定期間におけるＤｏＳ攻撃の頻度により、ＤｏＳ攻撃の有無を判断する第２の機能と、
   上記端末装置から受信したデータのペイロードの記述内容によりＤｏＳ攻撃の有無を判断する第３の機能と、
   自ドメイン内の攻撃対象となり得るサーバのリソースを監視し、ＤｏＳ攻撃の有無を判断する第４の機能と、
   の少なくともいずれか一つの機能を用いてＤｏＳ攻撃の有無を判断するためのネットワーク管理プログラム。

Images