JP2009182573A

JP2009182573A - 監視分析装置、方法、及び、プログラム

Info

Publication number: JP2009182573A
Application number: JP2008018798A
Authority: JP
Inventors: Takahide Sugita; 貴英杉田
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2008-01-30
Filing date: 2008-01-30
Publication date: 2009-08-13
Anticipated expiration: 2028-01-30
Also published as: JP4985435B2; US20090193115A1

Abstract

【課題】事象を検出した際に、その発生要因を推定することができる監視分析装置を提供する。
【解決手段】
受信部１１は、サーバからクライアントに送信される所定プロトコルのデータを受信する。抽出部１２は、受信データからステータスコードを抽出する。分類部１３は、抽出されたステータスコードを、種別に応じて第１の分類及び第２の分類に分類する。判定部１４は、第１の分類のステータスコードの受信率と第２の分類のステータスコードの受信率とを求め、第１の分類のステータスコードの受信率と第１の分類のステータスコード受信率のしきい値、及び、第２の分類のステータスコードの受信率と第２の分類のステータスコード受信率のしきい値をそれぞれ比較する。判定部１４は、比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する。
【選択図】図１

Description

本発明は、監視分析装置、方法、及び、プログラムに関し、更に詳しくは、サーバからクライアントに送信される所定プロトコルのデータを受信し解析する監視分析装置、方法、及び、プログラムに関する。また、本発明は、そのような監視分析装置を含む通信システムに関する。

ＶｏＩＰ（Voice over Internet Protocol）の呼処理プロトコルの１つとして、ＳＩＰ（Session Initiation Protocol,RFC3261）が利用されている。通常、呼処理にはＳＩＰサーバを利用する。ＳＩＰサーバは、広域からのリクエストを受け付ける必要があるため、攻撃のターゲットになりやすいことが予想される。また、ＳＩＰは、ＨＴＴＰ（Hyper Text Transport Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を参考に設計されており、ＳＭＴＰに関連して発生している脅威が、ＳＩＰにおいても同様に起こる可能性があると考えられる。例えば、ＳＩＰでは、悪意のある者がサーバからＳＩＰＵＲＩ（Uniform Resource Identifier）を収集し、ＶｏＩＰを使って迷惑電話をかける行為であるＳＰＩＴ（SPam over Internet Telephony）を行う場合があると言われている。これは、ＳＭＴＰにおける、ハーベスティングによりアドレスを収集しＳｐａｍを送信する行為に似ている。

ＩＴＵ−ＴＹ．１５３０では、特定のプロトコルに限定しない呼処理品質が示されており、ＶｏＩＰ推進協議会では、ＩＴＵ−ＴＹ．１５３０をＳＩＰ等へ適用する議論が行われている。ＳＩＰに対応した呼処理品質の指標の１つとして、ＳＩＰの各ステータスコードの受信率が提案されている（非特許文献１参照）。品質指標には、４００番台のステータスコード（以下、４ｘｘ）を受信した率、５００番台と６００番台のステータスコード（以下、５ｘｘ、６ｘｘ）を受信した率を用いられる。４ｘｘは、リクエストに誤りが含まれているためにサーバでリクエストの処理を実行できなかった場合に発行される。５ｘｘや６ｘｘは、例えばサーバの負荷が高いためリクエストの処理に失敗した場合に発行される。

ここで、ＤｏＳ（Denial of Services）攻撃を検出する技術としては、特許文献１に記載の技術がある。特許文献１では、まず、パケットを、プロトコル種別やフラグ等に基づいてｋ通り（ｋ：自然数）に分類し、分類ごとに一定時間ごとのパケット数を測定する。次いで、測定したパケット数に基づいて、ｋ通りの分類を要素とするｋ次元ベクトルを生成する。続いて、主成分軸と生成したｋ次元ベクトルとの間の距離を測定する。主成分軸とは、ネットワークが正常な状態におけるｋ次元特徴空間を形成する各成分間の相関関係を示すものである。その後、測定した距離に基づいて、異常の有無、すなわち、ＤｏＳ攻撃の有無を判定する。
http://www.telesa.or.jp/committee/voip/pdf/0507_IPCall_protocol_ver1.pdf 特開２００７−６０２３３号公報

５ｘｘや６ｘｘを多く発行するサーバは、高負荷状態であることが考えられる。しかし、５ｘｘや６ｘｘの受信率を参照しても、負荷上昇が、正常トラヒックに起因するのか、異常トラヒックに起因するのかを判断することは困難である。ここでの異常トラヒックとは、ＳＰＩＴやＤｏＳなどによるトラヒックを指す。負荷上昇の要因が不明であると、サーバ管理者は、サーバ増強が必要であるのか、セキュリティ施策の検討が必要であるかを判断することができず、有効な手立てを打つことができない。特許文献１では、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Data Protocol）、ＩＣＭＰ（Internet Control Message Protocol）のプロトコルレベル、又は、ＴＣＰのフラグレベルの情報に基づいてパケットを分類している。特許文献１では、レイヤ３、レイヤ４に注目しているに過ぎないため、レイヤ３、レイヤ４で異常が見られないもののアプリケーションレベルで異常があるケースについては、異常を検出することはできない。

本発明は、事象を検出した際に、その発生要因を推定することができる監視分析装置、方法、及び、プログラムを提供することを目的とする。

上記目的を達成するために、本発明の監視分析装置は、サーバからクライアントに送信される所定プロトコルのデータを受信する受信部と、前記受信したデータからステータスコードを抽出する抽出部と、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類部と、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求め、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較し、該比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定部とを備えることを特徴とする。

本発明の通信システムは、ネットワークを介して相互に接続され、所定プロトコルに従って通信を行うサーバ及びクライアントと、前記ネットワークに接続され、前記サーバからクライアントに送信される所定プロトコルのデータを受信する受信部と、前記受信したデータからステータスコードを抽出する抽出部と、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類部と、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求め、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較し、該比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定部とを有する監視分析装置を備えることを特徴とする。

本発明の監視分析方法は、サーバからクライアントに送信される所定プロトコルのデータを受信し解析する監視分析装置における監視分析方法であって、前記監視分析装置が、前記受信したデータからステータスコードを抽出する抽出ステップと、前記監視分析装置が、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類ステップと、前記監視分析装置が、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求める受信率演算ステップと、前記監視分析装置が、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較する比較ステップと、前記監視分析装置が、前記比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定ステップとを有することを特徴とする。

本発明のプログラムは、情報処理装置に、サーバからクライアントに送信される所定プロトコルのデータを受信し解析する処理を実行させるプログラムであって、前記情報処理装置に、前記受信したデータからステータスコードを抽出する処理と、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する処理と、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求める処理と、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較する処理と、前記比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する処理とを実行させることを特徴とする。

本発明の監視分析装置、方法、及び、プログラムでは、事象を検出した際に、その発生要因を推定することができる。

はじめに、本発明の概要を説明する。図１に、本発明の監視分析装置を示す。監視分析装置は、受信部１１、抽出部１２、分類部１３、及び、判定部１４を有する。受信部１１は、サーバからクライアントに送信される所定プロトコルのデータを受信する。抽出部１２は、受信部１１が受信したデータからステータスコードを抽出する。分類部１３は、抽出部１２が抽出したステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する。

判定部１４は、第１の分類のステータスコードの受信率を求め、求めた第１の分類のステータスコードの受信率としきい値とを比較する。また、第２の分類のステータスコードの受信率を求め、求めた第２の分類のステータスコードの受信率としきい値を比較する。判定部１４は、比較後、比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する。

本発明では、ステータスコードを、種別に応じて、第１及び第２の分類に分類する。第１及び第２の分類のステータスコードの受信率を求め、これらをそれぞれしきい値と比較し、第１の分類に対応する事象と第２の分類に対応する事象とがそれぞれ正常範囲であるか否かを判断する。一方の事象が正常範囲から外れた際に、他方の事象の状況を調べることで、その一方の事象が正常範囲から外れた要因を推定することができる。

特に、分類部１３にて、クライアントからのリクエストに問題があることに起因してサーバでリクエストが実行できない旨を示すステータスコードを第１の分類に分類し、リクエストは正常であるもののサーバ側の原因でサーバがリクエストを実行できなかった旨を示すステータスコードを第２の分類に分類した場合、第２の分類のステータスコードの受信率によってサーバ負荷を把握でき、第１の分類のステータスコードの受信率によって不正リクエストの発生状況を把握できる。従って、両者を用いることで、サーバの負荷が上昇した際に、それが正常トラヒックによるものであるか異常トラヒックによるものであるかを判定することが可能となる。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図２は、本発明の第１実施形態の開始分析装置を含む通信システムを示している。監視分析装置５０は、複数のクライアント（５１〜５３）及びサーバ５４と、ネットワークを介して接続されている。監視分析装置５０は、同一セグメント上に流れているＳＩＰパケットを受信する。これは、一般的なネットワークインタフェースカードでは、プロミスカスモードと呼ばれる設定で実現できる。監視分析装置５０は、クライアント５１〜５３、サーバ５４のレイヤ７（ＯＳＩモデル第７層：以下「Ｌ７」）を監視分析する。監視分析装置５０は、監視分析結果をログへ記録する。

図３に、監視分析装置５０の構成を示す。監視分析装置５０は、Ｌ２，Ｌ３，Ｌ４終端処理部１１０、プロトコル識別部１１１、ＳＩＰセッション管理部１１２、ステータスコード行抽出部１１３、ステータスコード検索部１１４、計数部１１５、判定部１１６、ＳＩＰセッション管理テーブル２１０、サーバリスト２１１、ステータスコードリスト２１２、計数テーブル２１３、及び、しきい値テーブル２１４を有する。監視分析装置５０では、情報処理装置に所定のプログラムを実行させることで、各部の機能を実現してもよい。Ｌ２，Ｌ３，Ｌ４終端処理部１１０、プロトコル識別部１１１、及び、ＳＩＰセッション管理部１１２は、図１における受信部１１に相当する。ステータスコード行抽出部１１３は、抽出部１２に相当し、ステータスコード検索部１１４は、分類部１３に相当する。計数部１１５及び判定部１１６は、判定部１４に相当する。

Ｌ２，Ｌ３，Ｌ４終端処理部１１０は、レイヤ２（Ｌ２）、レイヤ３（Ｌ３）、レイヤ４（Ｌ４）の終端処理を行う。ＳＩＰは、ＴＣＰ、ＵＤＰ、ＳＣＴＰ（Stream Control Transmission Protocol,RFC2960）を利用できる。Ｌ２，Ｌ３，Ｌ４終端処理部１１０は、ＴＣＰやＳＣＴＰパケットが入力された場合は、ストリーム再構築を行う。プロトコル識別部１１１は、ＳＩＰパケットを識別し、ＳＩＰパケットを、後段のＳＩＰセッション管理部１１２に渡す。ＳＩＰパケットであるか否かは、ポート番号（５０６０）により識別できる。ＳＩＰ以外のパケットは、廃棄する。

ＳＩＰセッション管理部１１２は、監視分析装置５０に入力されたＳＩＰセッションを管理する。ＳＩＰセッション管理部１１２は、入力されたＳＩＰパケットから、ＳＩＰセッション管理テーブル２１０に登録すべき情報を抽出し、抽出した情報を、ＳＩＰセッション管理テーブル２１０に登録する。ＳＩＰセッション管理テーブル２１０の一例を図４に示す。ＳＩＰセッション管理テーブル２１０は、送信元ＩＰアドレス、送信先ＩＰアドレス、ＣａｌｌＩＤ、送信元ＳＩＰＵＲＩ、送信先ＳＩＰＵＲＩなどの項目を有する。

サーバリスト２１１には、監視分析装置５０が監視分析対象とするサーバのＩＰアドレスが記録されている。図５に、サーバリスト２１１の記録内容の一例を示す。ＳＩＰセッション管理部１１２は、サーバリスト２１１を参照して、送信元ＩＰアドレスがサーバリスト２１１のＩＰアドレスと一致するＳＩＰパケットを、後段のステータスコード行抽出部１１３に渡す。ステータスコード行抽出部１１３は、ＳＩＰセッション管理部１１２からＳＩＰパケットを受け取ると、ＳＩＰパケットの１行目に含まれるステータスコードを抽出し、ステータスコード検索部１１４に渡す。

ステータスコードリスト２１２には、計数対象となるステータスコードが格納されている。ステータスコード検索部１１４は、ステータスコード行抽出部１１３が抽出したステータスコードをステータスコードリスト２１２と比較し、一致するステータスコードがあるか否かを調べる。ある場合は、どのステータスコードが受信されたかを示す情報を、計数部１１５に通知する。具体的には、ステータスコード検索部１１４は、４００番台（４ｘｘ）、５００番台（５ｘｘ）、６００番台（６ｘｘ）のステータスコードを検索し、どのステータスコードが受信されたかを計数部１１５に通知する。計数部１１５は、各ステータスコードが受信された回数をカウントする。

図６に、ステータスコードリスト２１２に格納されたステータスコードリストの一例を示す。この例では、ステータスコードリスト２１２は、４ｘｘのステータスコードのリスト、５ｘｘのステータスコードのリスト、及び、６ｘｘのステータスコードのリストを有する。例えば、ステータスコード行抽出部１１３から受け取ったステータスコードが「４０１」であるときは、このステータスコードは４ｘｘのステータスコードのリストに記述されているので、ステータスコード検索部１１４は、計数部１１５に、４ｘｘのステータスコードが受信された旨を通知する。また、ステータスコード行抽出部１１３から受け取ったステータスコードが「５０１」のときは、計数部１１５に、５ｘｘのステータスコードが受信された旨を通知する。

なお、４ｘｘのステータスコードは、クライアント・エラー応答を意味しており、リクエストに誤りが含まれている、或いは、指定したサーバではリクエストを実行できないことを表すステータスコードである。つまり、４ｘｘは、クライアントからのリクエストに起因してサーバでリクエストが実行できない旨を表すステータスコードである。また、５ｘｘのステータスコードは、サーバ・エラー応答を意味しており、サーバがリクエストの実行に失敗したことを表すステータスコードである。６ｘｘのステータスコードは、グローバル・エラー応答を意味しており、リクエストがどのサーバでも実行できなかったことを表すステータスコードである。つまり、５ｘｘ及び６ｘｘは、リクエスト自体は正常であるものの、サーバ側の原因でサーバがリクエストを実行できなかったことを表すステータスコードである。

上記では、ステータスコードリスト２１２が、４００番台、５００番台、６００番台の３つのステータスコードのリストを有するとしたが、ステータスコードが何百番台かを調べるだけであれば、ステータスコードの百の位の値を調べれば済むので、ステータスコードリスト２１２を用意しておく必要はない。ステータスコードリスト２１２を用意しておく理由は、エラーを示すステータスコードの要因規定の捉え方が開発者によって異なり、意図した通りにステータスコードが発行されないことも想定されるためである。例えば、ＩＮＶＩＴＥリクエスト数が一定値を超えたときに“４８０”のステータスコードを応答するサーバがあるとする。監視分析装置では、その事象の発生を、サーバ・エラー応答（５ｘｘ）として検出したいとする。その場合には、ステータスコードリスト２１２を用意しておき、５ｘｘのリストへ“４８０”を記述しておくことで、ステータスコード“４８０”を５ｘｘとして検出できる。

計数部１１５は、ステータスコード検索部１１４からステータスコードが検出された旨の通知を受けると、ステータスコードを送信したサーバのＩＰアドレスごとに、ステータスコードの受信数をカウントする。また、このとき、計数部１１５は、ステータスコードを受信するクライアントのＩＰアドレスごとにも、ステータスコードの受信数をカウントする。計数テーブル２１３は、サーバ及びクライアントごとに、各ステータスコードのカウント値を保持する。

図７に、計数テーブル２１３の一例を示す。計数テーブル２１３は、種別、ＩＰアドレス、総数、４ｘｘ、５ｘｘ、６ｘｘの列（項目）を有する。種別は、サーバとクライアントとを区別するための情報であり、“１”がサーバを、“０”がクライアントを表している。例えば、図７の１行目を参照すると、ＩＰアドレス「１０．１０．１０．１」で識別されるサーバが受信するステータスコードの総数は「５００」であり、４ｘｘの数は「５０」、５ｘｘの数は「２０」、６ｘｘの数は「０」であることがわかる。２行目以降は、ＩＰアドレス「１０．１０．１０．１」のサーバと通信しているクライアントごとのカウント値を表している。計数テーブル２１３のカウント値は、周期的に更新される。

判定部１１６は、計数テーブル２１３を参照して、各サーバの５ｘｘのカウント値と６ｘｘのカウント値との和を求め、その和を受信ステータスコードの総数で除した値を求める。これを５ｘｘ、６ｘｘの受信率と呼ぶ。また、４ｘｘのカウント値を、受信ステータスコードの総数で除した値を求める。これを、４ｘｘの受信率と呼ぶ。判定部１１６は、４ｘｘの受信率を求めると、所定の観測時間における受信率の最大値を求め、その最大値を図示しない記憶装置内に保持する。図８に、観測時間に４ｘｘの受信率の最大値の一例を示す。

判定部１１６は、求めた各ステータスコードの受信率と、しきい値テーブル２１４に格納された各ステータスコードの受信率のしきい値とに基づいて、サーバ負荷が上昇しているか否かや、サーバ負荷上昇が異常トラヒックによるものか正常トラヒックによるものかを判定する。判定部１１６は、５ｘｘ、６ｘｘの受信率がしきい値テーブル２１４に格納されたしきい値以上であり、かつ、観測時間内における４ｘｘの受信率の最大値がしきい値テーブル２１４に格納されたしきい値以上であると判断すると、異常トラヒックによりサーバ負荷が上昇していると判定する。また、５ｘｘ、６ｘｘの受信率がしきい値以上であり、かつ、観測時間内における４ｘｘの受信率の最大値がしきい値よりも小さいときは、正常トラヒックによりサーバ負荷が上昇していると判定する。

図９に、しきい値テーブル２１４の一例を示す。しきい値テーブル２１４は、「種別」、「ＩＰアドレス」、「５ｘｘ、６ｘｘのしきい値」、「４ｘｘのしきい値」、「観測時間」の列（項目）を有する。５ｘｘ、６ｘｘのしきい値は、５ｘｘ、６ｘｘの受信率と比較されるしきい値である。４ｘｘのしきい値は、観測時間における４ｘｘの受信率の最大値と比較されるしきい値である。観測時間は、４ｘｘの受信率の最大値を求める際に、過去どれだけの時間分の最大値とするかを定める。例えば、観測時間を１分とするときは、判定部１１６は、過去１分間の４ｘｘの受信率のうちの最大値を保持する（図８）。

悪意のある者は、異常トラヒックを送信する場合、その準備として、ＳＩＰＵＲＩの情報等を取得するため、サーバに対してスキャンをかける。スキャンを受けたサーバは、クライアント・エラー応答である４ｘｘをクライアントに対して送信する。次に、悪意のある者が、得た情報を使ってサーバへ異常トラヒックを送信すると、サーバは、サーバ・エラー応答である５ｘｘをクライアントに対して送信する。このとき、ネットワークを監視すると、サーバから大量の４ｘｘが送信された後に、大量の５ｘｘが送信されるように見える。判定部１１６は、この振る舞いを検出し、サーバ負荷上昇の要因判定を行う。また、このとき、サーバ負荷上昇要因となったトラヒックを発生したクライアントは、サーバから４ｘｘ、５ｘｘ、６ｘｘを受信していると考えられるので、これらの受信率が大きいクライアントを調べることで、負荷上昇要因となるクライアントを特定することができる。

なお、上記では、ステータスコード検索部１１４にてステータスコードが４ｘｘ、５ｘｘ、６ｘｘの３つの何れであるかを検出し、計数部１１５にてそれらの受信数をカウントしたが、判定部１１６は、５ｘｘと６ｘｘとを合算した後に受信率を計算するので、これらの受信数を個別に求める必要はない。従って、ステータスコード検索部１１４にて検出するステータスコードの分類は、４ｘｘ（第１の分類）と、５ｘｘ及び６ｘｘ（第２の分類）との２つでよい。この場合は、ステータスコードリスト２１２（図６）には、５ｘｘのリストと６ｘｘのリストとを１つにまとめて、５ｘｘ及び６ｘｘのリストを用意しておけばよい。

図１０に、監視分析装置の処理手順を示す。監視分析装置５０は、ネットワーク上を流れるパケットを受信する。Ｌ２，Ｌ３，Ｌ４終端処理部１１０は、監視分析装置５０が受信したパケットについて終端処理を行う（ステップＳ１）。終端処理では、ＴＣＰやＳＣＴＰパケットの場合は、ストリーム再構築を行う。プロトコル識別部１１１は、ポート番号を参照して、ポート番号が５０６０であるパケットを、ＳＩＰセッション管理部１１２に渡す（ステップＳ２）。プロトコル識別部１１１は、ポート番号が５０６０以外のパケットについては破棄する。ポート番号５０６０は、ＳＩＰパケットを表しているので、プロトコル識別部１１１は、ＳＩＰパケットのみを、ＳＩＰセッション管理部１１２に処理対象として渡す。

ＳＩＰセッション管理部１１２は、ＳＩＰパケットを受け取ると、ＳＩＰパケットのＩＰヘッダの送信元ＩＰ、送信先ＩＰ、ＳＩＰＵＲＩ等を参照し、ＳＩＰセッション管理テーブル２１０（図４）を用いて、セッション管理を行う（ステップＳ３）。また、このとき、サーバリスト２１１（図５）を参照して、送信元ＩＰアドレスがサーバリスト２１１のＩＰアドレスと一致するパケットを、ステータスコード行抽出部１１３に渡す。ステータスコード行抽出部１１３は、送信元ＩＰアドレスがサーバリスト２１１のＩＰアドレスと一致するＳＩＰパケットを受け取ると、ＳＩＰパケットのステータスコードを抜き出し、ステータスコード検索部１１４へ渡す（ステップＳ４）。

ステータスコード検索部１１４は、ステータスコードリスト２１２（図６）を参照し、各リストに一致するステータスコードがあるときは、どのリストに一致したかを示す情報を、計数部１１５に通知する（ステップＳ５）。計数部１１５は、ステータスコード検索部１１４からの通知にしたがって、対応するステータスコードの受信数をサーバごとにカウントし、計数テーブル２１３（図７）を更新する（ステップＳ６）。また、ステップＳ６では、サーバが送信したＳＩＰパケットを受信するクライアントについても、対応するステータスコードの受信数をカウントする。

判定部１１６は、所定の周期で、計数テーブル２１３を参照し、５ｘｘのカウント値と６ｘｘのカウント値とから、５ｘｘ、６ｘｘの受信率を求める。また、４ｘｘのカウント値から、４ｘｘの受信率を求め、しきい値テーブル２１４（図９）に格納された観測時間における４ｘｘの受信率の最大値（図８）を更新する。判定部１１６は、各サーバについて、求めた５ｘｘ、６ｘｘの受信率と、しきい値テーブル２１４に格納された５ｘｘ、６ｘｘの受信率のしきい値とを比較し、求めた受信率がしきい値以上であるか否かを判断する（ステップＳ７）。つまり、サーバ負荷が高い状態であるか否かを判断する。しきい値よりも小さいときは、処理を終了する。

判定部１１６は、ステップＳ７でしきい値以上であると判断したときは、観測時間における４ｘｘの受信率の最大値と、しきい値テーブル２１４に格納された４ｘｘの受信率のしきい値とを比較し、観測時間における受信率の最大値がしきい値以上であるか否かを判断する（ステップＳ８）。判定部１１６は、しきい値以上の場合は、異常トラヒックによるサーバ負荷上昇と判定する（ステップＳ９）。しきい値をよりも小さい場合は、正常トラヒックによるサーバ負荷上昇と判定する（ステップＳ１０）。

図１１（ａ）及び（ｂ）に、それぞれ５ｘｘ、６ｘｘの受信率及び４ｘｘの受信率の変化の様子を示す。サーバとしては、ＩＰアドレス「１０．１０．１０．１」のサーバを考える。図９を参照すると、このサーバについての５ｘｘ、６ｘｘの受信率のしきい値は「０．３」、４ｘｘの受信率のしきい値は「０．３」であり、観測時間は「１分」である。判定部１１６は、ステップＳ７で、５ｘｘ、６ｘｘの受信率と、しきい値「０．３」とを比較する。比較の結果、時刻ｔで、５ｘｘ、６ｘｘの受信率がしきい値「０．３」を超えたとする（図１１（ａ））。

判定部１１６は、５ｘｘ、６ｘｘの受信率がしきい値「０．３」以上であると判断すると、ステップＳ８で、観測時間における４ｘｘの受信率の最大値と４ｘｘの受信率のしきい値「０．３」とを比較する。観測時間は１分であるので、ステップＳ８では、時刻ｔより１分前の時刻から、時刻ｔまでの間における４ｘｘの受信率の最大値と、しきい値「０．３」とを比較する。図１１（ｂ）では、時刻ｔにおける４ｘｘの受信率はしきい値「０．３」よりも小さいが、時刻ｔより１分前の時刻から時刻ｔまでの間にしきい値「０．３」以上となる時点があるので、ステップＳ８では、観測時間における４ｘｘの受信率の最大値はしきい値以上であると判断される。その結果、ステップＳ９で、異常トラヒックによりサーバ負荷が上昇したと判断される。

図１２に、４ｘｘと５ｘｘ、６ｘｘとの関係を示す。同図では、５ｘｘ、６ｘｘの受信率がしきい値以上となる状態を第一象限及び第四象限に割り当て、しきい値よりも小さい状態を第二象限及び第三象限に割り当てている。また、観測時間における４ｘｘの受信率の最大値がしきい値以上となる状態を第一象限及び第二象限に割り当て、しきい値よりも小さい状態を第三象限及び第四象限に割り当てている。

５ｘｘ、６ｘｘの受信率がしきい値以上となる場合の例としては、ＳＰＩＴなど大量トラヒックの発生により、サーバが処理用スレッドに割り当てるメモリ確保に失敗した結果として、５ｘｘを発行している状態が考えられる。また、観測時間における４ｘｘの受信率の最大値がしきい値以上となる場合の例としては、悪意のある者が、ＳＰＩＴ実行準備としてＳＩＰ−ＵＲＩを取得することを目的としてＳＩＰのＯＰＴＩＯＮＳリクエストを送信し、サーバが、該当するＳＩＰ−ＵＲＩがないために４ｘｘ（４０４ＮｏｔＦｏｕｎｄなど）を発行している状態が考えられる。

第一象限は、過去に不正なリクエストが発生し、かつ、大量トラヒックが発生した状況であり、異常トラヒックによりサーバ負荷が上昇したと判定できる。第四象限は、大量トラヒックが発生しているが、過去に不正なリクエストは発生していない状況であり、正常トラヒックによりサーバ負荷が上昇した状況であると判定できる。第二象限は、過去に不正なリクエストが発生したが、大量トラヒックはまだ発生していない状況である。不正なリクエストにより収集した情報を利用し、大量トラヒックがこれから発生する可能性があると考えることができる。第三象限は、４ｘｘや５ｘｘ，６ｘｘの何れもしきい値以上ではないので、正常トラヒックが発生していると思われる。

図１０に戻り、判定部１１６は、計数テーブル２１３（図７）を参照して、該当サーバに接続するクライアントの４ｘｘの受信率、５ｘｘ、６ｘｘの受信率を求める（ステップＳ１１）。該当サーバに接続するクライアントの受信率は、計数テーブル２１３における種別“０”の行の各項目の値を参照することで計算できる。受信率が大きいクライアントは、サーバ負荷上昇の要因となるトラヒックを多く発生していると考えることができる。

本実施形態では、サーバが送信するＳＩＰパケットからステータスコードを抽出し、ステータスコードを、４ｘｘ（第１の分類）と、５ｘｘ、６ｘｘ（第２の分類）とに分類して、それぞれの受信率を求める。その後、５ｘｘ、６ｘｘの受信率と５ｘｘ、６ｘｘのしきい値とを比較することで、サーバの負荷が高い状態であるか否かを判断し、サーバ負荷が高いと判断されたときは、観測期間における４ｘｘの受信率の最大値と４ｘｘの受信率のしきい値とを比較して、サーバ負荷が上昇する前に、不正なリクエストが多数発行されたか否かを判断する。このようにすることで、サーバ負荷上昇が、異常トラヒックによって上昇したのか、正常トラヒックによって上昇したのかを推定することができ、負荷上昇の要因の切り分けが可能となる。

負荷上昇の要因の切り分けに関して、例えば、不正トラヒックの特徴を持つパターンを使った検知と、サーバのＣＰＵ、ディスク、メモリ使用率とを組み合わせて切り分けを実現する手法も考えられる。しかし、その場合は、ネットワークの状態とサーバ内部との２点を観測する必要があり、各情報の突合せも簡単ではない。また、不正トラヒックの特徴を持つ多くのパターンを事前に用意しておかなければならないという問題もある。本実施形態では、２つの種別のステータスコードの受信率に基づいて要因の切り分けを行うので、そのような問題はなく、簡易に、切り分けを実現できる。

続いて、本発明の第２実施形態について説明する。本実施形態の監視分析装置の構成は、図３に示す第１実施形態の監視分析装置５０の構成と同様である。本実施形態では、４ｘｘの受信率、及び、５ｘｘと６ｘｘの受信率に加えて、２ｘｘの受信率を用いて、サーバ負荷上昇の要因が異常トラヒックによるものか、正常トラヒックによるものかを判定する。つまり、本実施形態では、ステータスコードの分類を１つ増やし、４ｘｘ（第１の分類）のステータスコードの受信率、５ｘｘ、６ｘｘ（第２の分類）のステータスコードの受信率、及び、２ｘｘ（第３の分類）のステータスコードの受信率に基づいて、サーバ負荷上昇の要因が異常トラヒックによるものか、正常トラヒックによるものであるかを判定する。なお、２ｘｘは、成功応答を示すステータスコードである。

図１３に、２ｘｘのステータスコードのリストを示す。ステータスコードリスト２１２には、図６に示す４ｘｘのリスト、５ｘｘのリスト、６ｘｘのリストに加えて、図１３に示す２ｘｘのリストが格納される。ステータスコード検索部１１４は、ステータスコード行抽出部１１３が抽出したステータスコードが、２ｘｘのリストに存在するときは、２ｘｘが検出された旨を計数部１１５に通知する。図１４に、本実施形態における計数テーブル２１３の一例を示す。図７に示す第１実施形態における計数テーブル２１３との相違点は、２ｘｘの項目が追加されている点である。計数部１１５は、ステータスコード検索部１１４が２ｘｘを検出すると、２ｘｘの項目のカウント値をカウントアップする。判定部１１６は、計数テーブル２１３を参照して、２ｘｘのカウント値から２ｘｘの受信率を求める。

図１５に、本実施形態におけるしきい値テーブル２１４の一例を示す。図９に示す第１実施形態におけるしきい値テーブル２１４との相違点は、２ｘｘの受信率のしきい値が追加されている点である。判定部１１６は、５ｘｘ、６ｘｘの受信率がしきい値以上であるときは、４ｘｘの受信率と４ｘｘの受信率のしきい値、及び、２ｘｘの受信率と２ｘｘの受信率のしきい値とを比較し、比較結果に基づいて、負荷上昇が異常トラヒックによるものであるか、正常トラヒックによるものであるかを判定する。図１６に、判定表を示す。判定部１１６は、４ｘｘの受信率がしきい値以上で、かつ、２ｘｘの受信率がしきい値以下のときは、異常トラヒックによる負荷上昇と判定する。一方、４ｘｘの受信率がしきい値よりも小さく、かつ、２ｘｘの受信率がしきい値よりも大きいときは、正常トラヒックによる負荷上昇と判定する。

図１７に、本実施形態における監視分析装置の動作手順を示す。ステップＳ１〜ステップＳ６までは、図１０に示す第１実施形態における動作手順と同様である。判定部１１６は、しきい値テーブル２１４を参照して、５ｘｘ、６ｘｘの受信率と、５ｘｘ、６ｘｘの受信率ののしきい値とを比較し、５ｘｘ、６ｘｘの受信率がしきい値以上であるか否かを判断する（ステップＳ７）。しきい値よりも小さいときは、処理を終了する。

判定部１１６は、ステップＳ７で５ｘｘ、６ｘｘの受信率がしきい値以上と判断したときは、しきい値テーブル２１４を参照して、４ｘｘの受信率と４ｘｘの受信率のしきい値、及び、２ｘｘの受信率と２ｘｘの受信率のしきい値をそれぞれ比較し、４ｘｘの受信率がしきい値以上で、かつ、２ｘｘの受信率がしきい値以下であるか否かを判断する（ステップＳ１０１）。４ｘｘの受信率がしきい値以上で、かつ、２ｘｘの受信率がしきい値以下のときは、異常トラヒックによる負荷上昇と判定する（ステップＳ９）。その後、計数テーブル２１３を参照して、該当サーバに接続しているクライアント（種別“０”）について、４ｘｘの受信率、５ｘｘ、６ｘｘの受信率、２ｘｘの受信率を求める（ステップＳ１０３）。受信率が大きいクライアントは、サーバ負荷上昇要因となるトラヒックを多く発生していると考えられる。

判定部１１６は、ステップＳ１０１で、４ｘｘの受信率がしきい値以上で、かつ、２ｘｘの受信率がしきい値以下でないと判断したときは、４ｘｘの受信率がしきい値よりも小さく、かつ、２ｘｘの受信率がしきい値を超えるか否かを判断する（ステップＳ１０２）。４ｘｘの受信率がしきい値よりも小さく、かつ、２ｘｘの受信率がしきい値を超えるときは、正常トラヒックによる負荷上昇と判定する（ステップＳ１０）。その後、ステップＳ１０３へ移行し、４ｘｘの受信率、５ｘｘ、６ｘｘの受信率、２ｘｘの受信率を求める。ステップＳ１０２で、４ｘｘの受信率がしきい値以上である、又は、２ｘｘの受信率がしきい値以下であると判断したときは、処理を終了する。

本実施形態では、ステータスコードの分類を１つ追加し、ステータスコードを、４ｘｘ（第１の分類）と、５ｘｘ、６ｘｘ（第２の分類）と、２ｘｘ（第３の分類）とに分類する。２ｘｘの受信率を求めて、これを用いて負荷上昇の要因を判定することで、第１実施形態に比して、負荷上昇要因の推定の精度を上げることができる。

なお、上記各実施形態では、用いるプロトコルがＳＩＰの場合について説明したが、プロトコルは、ＳＩＰには限定されない。例えば、ＨＴＴＰでもよい。ＳＩＰに適用した場合と、ＨＴＴＰに適用した場合とで異なる点は、ＳＩＰでは６００番台のステータスコードがあるのに対して、ＨＴＴＰでは６００番台のステータスコードがないことである。ＨＴＴＰの場合は、５００番台のステータスコードを第２の分類に分類して、処理を行えばよい。ＨＴＴＰに適用する場合、リクエストの構文が間違った場合はサーバは「４００ＢａｄＲｅｑｕｅｓｔ」を発行し、サーバ負荷があがった場合は「５０３ＳｅｒｖｉｃｅＵｎａｖａｉｌａｂｌｅ」を発行するので、ステータスコード「５０３」が大量に発生した際に、その前に「４００」が大量に発生したか否かを調べることで、サーバの負荷上昇が正常トラヒックによるものであるか、異常トラヒックによるものであるかを識別ができると考えられる。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明の監視分析装置、方法、及び、プログラムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明の監視分析装置の構成を示すブロック図。監視分析装置を含む通信システムを示すブロック図。本発明の第１実施形態の監視分析装置を示すブロック図。ＳＩＰセッション管理テーブルの一例を示す図。サーバリストの一例を示す図。ステータスコードリストの一例を示す図。計数テーブルの一例を示す図。４ｘｘ受信率最大値の一例を示す図。しきい値テーブルの一例を示す図。動作手順を示すフローチャート。（ａ）は、５ｘｘ、６ｘｘ受信率の時間変化を示すグラフ、（ｂ）は、４ｘｘ受信率の時間変化を示すグラフ。５ｘｘ、６ｘｘ受信率と４ｘｘ受信率との関係を示す図。本発明の第２実施形態で用いるステータスコードリストの一例を示す図。第２実施形態における計数テーブルの一例を示す図。第２実施形態におけるしきい値テーブルの一例を示す図。判定表を示す図。第２実施形態における動作手順を示すフローチャート。

符号の説明

１１：受信部
１２：抽出部
１３：分類部
１４：判定部
５０監視分析装置
５１〜５３：クライアント
５４：サーバ
１１０：Ｌ２，Ｌ３，Ｌ４終端処理部
１１１：プロトコル識別部
１１２：ＳＩＰセッション管理部
１１３：ステータスコード行抽出部
１１４：ステータスコード検索部
１１５：計数部
１１６：判定部
２１０：ＳＩＰセッション管理テーブル
２１１：サーバリスト
２１２：ステータスコードリスト
２１３：計数テーブル
２１４：しきい値テーブル

Claims

サーバからクライアントに送信される所定プロトコルのデータを受信する受信部と、
前記受信したデータからステータスコードを抽出する抽出部と、
前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類部と、
前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求め、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較し、該比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定部とを備える監視分析装置。
前記分類部は、クライアントからのリクエストに問題があることに起因してサーバでリクエストが実行できない旨を示すステータスコードを前記第１の分類に分類し、リクエストは正常であるもののサーバ側の原因でサーバがリクエストを実行できなかった旨を示すステータスコードを前記第２の分類に分類する、請求項１に記載の監視分析装置。
前記判定部は、サーバごとに各分類のステータスコードの受信率のしきい値を記憶するしきい値テーブルを参照して、各分類のステータスコードの受信率と前記受信率のしきい値とを比較する、請求項１又は２に記載の監視分析装置。
前記分類部は、各分類に分類されるべきステータスコードのリストを記憶するステータスコードリストを参照して、前記抽出されたステータスコードを分類する、請求項１乃至３の何れか一に記載の監視分析装置。
前記判定部は、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上で、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値以上のとき、サーバ負荷が異常トラヒックにより上昇したと判定する、請求項１乃至４の何れか一に記載の監視分析装置。
前記判定部は、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上で、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値よりも小さいとき、サーバ負荷が正常トラヒックにより上昇したと判定する、請求項１乃至４の何れか一に記載の監視分析装置。
前記分類部は、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１〜第３の分類に分類し、前記判定部は、前記第１〜第３の分類のステータスコードの受信率をそれぞれ求め、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値、及び、前記第３の分類のステータスコードの受信率と前記第３の分類のステータスコード受信率のしきい値をそれぞれ比較し、該比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する、請求項１乃至４の何れか一記載の監視分析装置。
前記分類部は、サーバがクライアントからのリクエストに成功した旨を示すステータスコードを前記第３の分類に分類する、請求項７に記載の監視分析装置。
前記判定部は、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上であり、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値以上で、前記第３の分類のステータスコードの受信率が前記第３の分類のステータスコード受信率のしきい値以下のとき、サーバ負荷が異常トラヒックにより上昇したと判定する、請求項７又は８に記載の監視分析装置。
前記判定部は、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上であり、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値よりも小さく、前記第３の分類のステータスコードの受信率が前記第３の分類のステータスコード受信率のしきい値よりも大きいとき、サーバ負荷が正常トラヒックにより上昇したと判定する、請求項７乃至９の何れか一に記載の監視分析装置。
前記所定プロトコルはＳＩＰ（Session Initiation Protocol）であり、前記分類部は、４００番台のステータスコードを前記第１の分類に分類し、５００番台及び６００番台のステータスコードを前記第２の分類に分類する、請求項１乃至１０の何れか一に監視分析装置。
前記所定プロトコルはＳＩＰ（Session Initiation Protocol）であり、前記分類部は、４００番台のステータスコードを前記第１の分類に分類し、５００番台及び６００番台のステータスコードを前記第２の分類に分類し、２００番台のステータスコードを前記第３の分類に分類する、請求項７乃至１０の何れか一に記載の監視分析装置。
ネットワークを介して相互に接続され、所定プロトコルに従って通信を行うサーバ及びクライアントと、
前記ネットワークに接続され、前記サーバからクライアントに送信される所定プロトコルのデータを受信する受信部と、前記受信したデータからステータスコードを抽出する抽出部と、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類部と、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求め、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較し、該比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定部とを有する監視分析装置を備える通信システム。
サーバからクライアントに送信される所定プロトコルのデータを受信し解析する監視分析装置における監視分析方法であって、
前記監視分析装置が、前記受信したデータからステータスコードを抽出する抽出ステップと、
前記監視分析装置が、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する分類ステップと、
前記監視分析装置が、前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求める受信率演算ステップと、
前記監視分析装置が、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較する比較ステップと、
前記監視分析装置が、前記比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する判定ステップとを有する監視分析方法。
前記監視分析装置は、前記分類ステップでは、クライアントからのリクエストに問題があることに起因してサーバでリクエストが実行できない旨を示すステータスコードを前記第１の分類に分類し、リクエストは正常であるもののサーバ側の原因でサーバがリクエストを実行できなかった旨を示すステータスコードを前記第２の分類に分類する、請求項１４に記載の監視分析方法。
前記監視分析装置は、前記比較ステップでは、サーバごとに各分類のステータスコードの受信率のしきい値を記憶するしきい値テーブルを参照して、各分類のステータスコードの受信率と前記受信率のしきい値とを比較する、請求項１４又は１５に記載の監視分析方法。
前記監視分析装置は、前記分類ステップでは、各分類に分類されるステータスコードのリストを記憶するステータスコードリストを参照して、前記抽出されたステータスコードを分類する、請求項１４乃至１６の何れか一に記載の監視分析方法。
前記監視分析装置は、前記判定ステップでは、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上で、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値以上のとき、サーバ負荷が異常トラヒックにより上昇したと判定する、請求項１４乃至１７の何れか一に記載の監視分析方法。
前記監視分析装置は、前記分類ステップでは、前記抽出されたステータスコードを、ステータスコードの種別に応じて第１〜第３の分類に分類し、前記受信率演算ステップでは、前記第１〜第３の分類のステータスコードの受信率を求め、前記比較ステップでは、前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値、及び、前記第３の分類のステータスコードの受信率と前記第３の分類のステータスコード受信率のしきい値をそれぞれ比較し、前記判定ステップでは、前記比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する、請求項１４乃至１７の何れか一記載の監視分析方法。
前記監視分析装置は、前記分類ステップでは、サーバがクライアントからのリクエストに成功した旨を示すステータスコードを前記第３の分類に分類する、請求項１９に記載の監視分析方法。
前記監視分析装置は、前記判定ステップでは、前記第２の分類のステータスコードの受信率が前記第２の分類のステータスコード受信率のしきい値以上であり、かつ、所定の観測時間における前記第１の分類のステータスコードの受信率の最大値が前記第１の分類のステータスコード受信率のしきい値以上で、前記第３の分類のステータスコードの受信率が前記第３の分類のステータスコード受信率のしきい値以下のとき、サーバ負荷が異常トラヒックにより上昇したと判定する、請求項１９又は２０に記載の監視分析方法。
情報処理装置に、サーバからクライアントに送信される所定プロトコルのデータを受信し解析する処理を実行させるプログラムであって、前記情報処理装置に、
前記受信したデータからステータスコードを抽出する処理と、
前記抽出されたステータスコードを、ステータスコードの種別に応じて第１の分類及び第２の分類に分類する処理と、
前記第１の分類のステータスコードの受信率と前記第２の分類のステータスコードの受信率とを求める処理と、
前記第１の分類のステータスコードの受信率と前記第１の分類のステータスコード受信率のしきい値、及び、前記第２の分類のステータスコードの受信率と前記第２の分類のステータスコード受信率のしきい値をそれぞれ比較する処理と、
前記比較結果に基づいて、サーバの負荷上昇が正常トラヒックによるものであるか異常トラヒックによるものであるかを判定する処理とを実行させるプログラム。