[用語の説明]
まず最初に、以下の実施例で用いる主要な用語を説明する。「SIP(Session Initiation Protocol)トランザクション処理」とは、端末間でSIPを用いてセッションを確立する際の一連のトランザクションのことである。ここで、一つのトランザクションは、一般的に、SIPクライアントがSIPサーバに対して送信したリクエストから、当該SIPサーバが当該SIPクライアントに対して送信した最終応答までのメッセージのことである。「トランザクション処理」は、このような一つのトランザクションであることも、あるいは、複数のトランザクションであることもある。具体的に例を挙げて説明すると、発信側端末が着信側端末とセッションを確立することを要求して送信する『INVITE』メッセージと、発信側端末が着信側端末との間のセッションを切断することを要求して送信する『BYE』メッセージとは異なるトランザクションであるが、以下の実施例において「SIPトランザクション処理のSIPパケット」とは、これらのトランザクションにおいて発信側端末と着信側端末との間で送受信される一連の「SIPパケット」のことを意味する。かかる「SIPトランザクション処理」は、上記した例の他に、『404 Not Found』メッセージまでの一連の「SIPパケット」となるケースや、『CANCEL』メッセージまでの一連の「SIPパケット」となるケースなど、様々なケースがある。
ところで、近年、SIPを用いたIP電話サービスが普及しているが、IP電話は低コストで発信できることから、この点を悪用した「ナンバースキャンニング」と呼ばれる脅威が登場している。「ナンバースキャンニング」とは、ナンバースキャンニング業者が、存在するか否かが不明な電話番号にランダムに発信し、その応答によって、発信した電話番号が存在するか否かを判定し、存在すると判定した電話番号を取得するものである。具体的に例を挙げて説明すると、「ナンバースキャンニング」とは、発信側端末が、存在するか否かが不明な電話番号に『INVITE』メッセージを発信し、これを契機としてSIPトランザクション処理が行われ、発信側端末が、当該SIPトランザクション処理のSIPパケットとして『404 Not Found』メッセージを受信すると、発信した電話番号で識別される端末が存在しないという情報を取得するというものである。
このような「ナンバースキャンニング」によってナンバースキャンニング業者に取得された電話番号は、例えば、ワン切りや自動応答広告配信に悪用されることから、「ナンバースキャンニング」に対する対応策が急務となるが、ナンバースキャンニングを行う発信側端末を予め特定することは難しい。そこで、本発明に係る「ナンバースキャンニング検知装置」は、かかる「ナンバースキャンニング」を行う発信側端末を検知しようとするものである。
[実施例1に係るナンバースキャンニング検知装置の概要および特徴]
まず最初に、図1を用いて、実施例1に係るナンバースキャンニング検知装置の概要および特徴を説明する。図1は、実施例1に係るナンバースキャンニング検知装置の概要および特徴を説明するための図である。
実施例1に係るナンバースキャンニング検知装置は、ナンバースキャンニングが行われる状況において、発信側端末を検知することを概要とし、ナンバースキャンニングを検知する際の負荷を低減することを主たる特徴とするものである。
この主たる特徴について簡単に説明すると、図1に示すように、ナンバースキャンニング検知装置は、ルール記憶部に、ナンバースキャンニングが疑われる状態情報を規定したルールと、この場合に統計情報として収集すべき情報を規定したルールと、どのような場合にナンバースキャンニングを行う端末であると判定するかを規定したルールとを記憶している。
例えば、ナンバースキャンニング検知装置は、ナンバースキャンニングが疑われる情報として、『404 Not Found』を記憶している。ここで、『404 Not Found』は、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報として、SIPサーバから発信側端末に送信されるSIPパケットに含まれる情報である。また、例えば、ナンバースキャンニング検知装置は、統計情報として収集すべき情報を規定したルールとして、『404 Not Found』、『CANCEL』および『BYE』を記憶している。ここで、『CANCEL』は、『着信側端末を呼んでいる間(Ringing)に、発信側端末から電話を切った』という状態であり、『BYE』は、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態である。また、例えば、ナンバースキャンニング検知装置は、閾値ルールとして、1分間に10回以上『404 Not Found』を受信した場合には、ナンバースキャンニングを行う端末であると判定するとするルールである。なお、図1は、ルール記憶部に記憶されている情報を、概念的に示すものである。
このような構成のもと、実施例1に係るナンバースキャンニング検知装置は、ナンバースキャンニングが疑われる情報であって、SIPトランザクション処理が所定の状態にあることを示す状態情報を含むSIPパケットが送信されたことを検知する(図1の(A)の(1)を参照)。例えば、ナンバースキャンニング検知装置は、『404 Not Found』を含むSIPパケットが送信されたことを検知する。
すると、ナンバースキャンニング検知装置は、所定の状態情報を含むSIPパケットが送信されたことが検知されたことを条件として、当該SIPパケットが送信される契機となった発信を行った発信側端末を特定する(図1の(A)の(2)を参照)。例えば、ナンバースキャンニング検知装置は、『404 Not Found』を含むSIPパケットが送信されたことが検知されたことを条件として、当該SIPパケットが送信される契機となった発信を行った発信側端末を特定する。
次に、ナンバースキャンニング検知装置は、特定した発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始する(図1の(B)の(3)を参照)。
そして、ナンバースキャンニング検知装置は、情報の取得が開始されると、取得した情報を統計情報として収集する(図1の(B)の(4)を参照)。例えば、ナンバースキャンニング検知装置は、『404 Not Found』、『CANCEL』および『BYE』を統計情報として収集する。
すると、ナンバースキャンニング検知装置は、収集した統計情報に基づいて、特定した発信側端末がナンバースキャンニングを行う端末であるか否かを判定する(図1の(C)の(5)を参照)。例えば、ナンバースキャンニング検知装置は、1分間に10回以上『404 Not Found』を受信した場合に、特定した発信側端末がナンバースキャンニングを行う端末であると判定する。
このようなことから、ナンバースキャンニング検知装置は、常に全ての端末について統計情報を収集し、管理し続けなければならない従来の手法とは異なり、ナンバースキャンニングが疑われる状態情報を含むSIPパケットが送信されたことを検知したことをトリガーとして、ナンバースキャンニングを行う端末であると疑われる発信側端末についてのみ統計情報を収集するものであることから、従来の手法に比較して、リソース消費も少なく、負荷を低減することが可能になる。
なお、実施例1に係るナンバースキャンニング検知装置は、上記した主たる特徴の他に、情報の取得が開始された発信側端末によるSIPトランザクション処理が正規の手順で行われていないことも検知し(『603 Declilne』、『200 OK』の再送回数、あるいは、『BYE』の再送回数などで検知)、統計情報として、正規の手順で行われなかった回数(『603 Declilne』の送信回数、『200 OK』の再送回数、あるいは、『BYE』の再送回数など)も収集するものである。この点については、実施例1に係るナンバースキャンニング検知装置の構成等を説明する際に詳述する。
[実施例1に係るナンバースキャンニング検知装置の構成]
次に、図2〜12を用いて、実施例1に係るナンバースキャンニング検知装置の構成を説明する。図2は、ナンバースキャンニング検知装置の構成を示すブロック図であり、図3は、ナンバースキャンニング検知装置の接続を示すネットワーク図であり、図4は、パケット検知ルール記憶部を説明するための図であり、図5は、ユーザ統計テーブル記憶部を説明するための図であり、図6は、閾値ルール記憶部を説明するための図であり、図7および図8は、情報取得の開始について説明するための図であり、図9〜12は、統計情報の収集について説明するための図である。
図2に示すように、実施例1に係るナンバースキャンニング検知装置10は、通信制御部11と、記憶部20と、制御部30とから構成される。
通信制御部11は、ナンバースキャンニング検知装置10によって行われる通信を制御する。具体的には、通信制御部11は、ナンバースキャンニング検知装置10が、ネットワーク上のSIPパケットを処理する際や、ネットワークを介してその他の装置と通信する際などに、その通信を制御する。
ここで、ナンバースキャンニング検知装置10の接続について説明すると、ナンバースキャンニング検知装置10は、実施例1において、図3のように接続する。すなわち、ナンバースキャンニング検知装置10は、SIPサーバ2およびSIPクライアント3(ナンバースキャンニング業者端末4を含む)の各々がIP電話網/インターネット1に接続されている中間に、In-Line接続によって接続される。このIn-Line接続によれば、ナンバースキャンニング検知装置10は、既存のシステムに付加的に挿入されることが可能である。なお、図3においては、SIPサーバ2、SIPクライアント3およびナンバースキャンニング業者端末4を各々1台ずつ示すのみであるが、ナンバースキャンニング検知装置10を適用する上で、各々の構成は1台であっても複数台であってもよい。
かかる接続において、通信制御部11は、ナンバースキャンニング検知装置10が、IP電話網/インターネット1上のSIPパケットを処理する際や、IP電話網/インターネット1を介してSIPサーバ2やSIPクライアント3と通信する際などに、その通信を制御する。
記憶部20は、制御部30による各種処理に用いるデータを記憶し、特に本発明に密接に関連するものとしては、図2に示すように、パケット検知ルール記憶部21と、ユーザ統計テーブル記憶部22と、閾値ルール記憶部23とを備える。
パケット検知ルール記憶部21は、ナンバースキャンニング検知装置10が検知すべきSIPパケットについて規定したルールを記憶する。具体的には、パケット検知ルール記憶部21は、ナンバースキャンニングが疑われる状態情報を規定したルールを記憶し、記憶したルールは、後述する特定パケット検知部31cによる処理に利用されるなどする。また、パケット検知ルール記憶部21は、統計情報として収集する情報を規定したルールを記憶し、記憶したルールは、特定パケット検知部31cによる処理に利用されるなどする。なお、パケット検知ルール記憶部21は、これらのルールを、ナンバースキャンニング検知装置10において検知処理を開始する前などに、運用者によって入力されることなどで記憶する。
例えば、パケット検知ルール記憶部21は、図4に示すようなルールを記憶する。図4は、ナンバースキャンニングが疑われる状態情報を規定したルールと、この場合に統計情報として収集すべき情報を規定したルールとを示すものである。図4の例について説明すると、『404 Not Found』は、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報として、SIPサーバから発信側端末に送信されるSIPパケットに含まれる情報である。ナンバースキャンニングは、電話番号が存在するか否かを判定することを目的として、存在するか否かが不明な電話番号にランダムに発信するものであることから、この結果として、『404 Not Found』が含まれるSIPパケットが送信される可能性も高いと考えられる。もっとも、『発信側端末から発信された電話番号は存在しない』という状態は、ナンバースキャンニングでなくとも、単なる電話番号の押し間違いや記憶違いなどによっても発生し得る。したがって、『404 Not Found』を含むSIPパケットが送信されたことを検知したからといって、必ずしも当該SIPパケットが送信される契機となった発信を行った発信側端末が、ナンバースキャンニング業者の端末であると決めつけることはできない。実施例1においては、『404 Not Found』を、少なくとも、ナンバースキャンニングが疑われる状態情報であると考え、ルールに規定している。
なお、『404 Not Found』は、単にナンバースキャンニングが疑われる状態情報であるという他に、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであるという点において、意味がある。すなわち、発信側端末から自発的に発信されるSIPパケットとしては、例えば、『INVITE』があるが、このような発信呼をトリガーとして統計情報を収集しようとすると、この点を衝いたDoS攻撃またはDDoS攻撃(例えば、『INVITE』の大量送信)を受けた場合に、ナンバースキャンニング検知装置10がDoS攻撃またはDDoS攻撃の影響を受けてダウンしてしまうおそれがある。すなわち、『INVITE』を起点とした従来の手法では、DoS攻撃またはDDoS攻撃をする端末が『INVITE』を送信すれば、検知装置の検知ロジックが『INVITE』に反応して統計情報の取得を開始することになるが、DoS攻撃またはDDoS攻撃をする端末が送信者をランダムに偽って『INVITE』を大量に送信した場合、統計情報の取得を開始しなければならない端末の数が膨大になってしまい、検知装置は処理し切れなくなってしまう。この点、『404 Not Found』をトリガーとして統計情報を収集するのであれば、ナンバースキャンニング検知装置10は、認証に成功したユーザからのSIPパケットに対してのみ『404 Not Found』を送信(返信)し、ランダムに作成したユーザ(ユーザ名)に対しては『404 Not Found』を送信(返信)することはない。そうであるとすると、仮に、DoS攻撃またはDDoS攻撃をする端末が『INVITE』を大量に送信した場合であっても、『404 Not Found』が大量に送信(返信)されるわけではないので、ナンバースキャニング検知装置10は、むやみにランダムに偽装された端末について統計情報の取得を開始することはなく、DoSまたはDDoS攻撃に対してリソースを消費することもない。なお、認証に成功した同一の端末(ユーザ名)から『INVITE』を大量に送信された場合には、ナンバースキャンニング検知装置10は統計情報を取得することになるが、閾値を超えた時点で遮断することができるので、問題とはならない。
また、パケット検知ルール記憶部21は、検知すべき状態情報を規定したルールとして、『603 Decline』および『200 OK(BYE)の再送』を記憶している。図4においては、これらの情報は、ナンバースキャンニングが疑われる状態情報の欄に記載されているが、正確には、ナンバースキャンニングが疑われる状態情報として利用されるというよりは、これらが検知された場合、ナンバースキャンニング検知装置10は、発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知する。
ここで、『603 Decline』は、『着信側端末を呼んでいたが(Ringing)、発信側端末が電話を切ることもないので(着信側端末の電話が鳴りっぱなしになる)、SIPサーバ側からエラー切断する』という状態にあることを示す状態情報として、ある一定の時間着信側端末の電話が鳴りっぱなしになった場合に、SIPサーバから発信側端末に送信されるSIPパケットに含まれる情報である。すなわち、ナンバースキャンニングが、電話番号に発信するプログラムを利用することで行われた場合には、発信側端末は、『CANCEL』や『BYE』などをSIPサーバに送信することなく電話を切るという不正な手順で、SIPトランザクション処理を終了させるおそれがある。したがって、正規の手順で行われていないナンバースキャンニングの結果(着信側端末の電話が鳴りっぱなしになった時の結果)として、『603 Decline』が含まれるSIPパケットが送信される可能性は極めて高い。また、『200 OK(BYE)の再送』も同様に、正規の手順で行われていないナンバースキャンニングの結果(着信側端末の相手方が電話に出た時の結果)として、SIPサーバから発信側端末に『200 OK』もしくは『BYE』が繰り返し送信される可能性が極めて高いことに着目して規定されているものである。ナンバースキャンニングがこのような不正な手順で行われる場合には、『404 Not Found』の他に収集する情報として『CANCEL』や『BYE』を収集するのみでは不十分であるとも考えられる。このため、パケット検知ルール記憶部21は、発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知し、その回数をカウントすることを目的として、『603 Decline』や『200 OK(BYE)の再送』を記憶している。
一方、図4の例では、『404 Not Found』が送信されたことが検知された場合に統計情報として収集すべき情報を規定したルールとして、『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』および『200 OK(BYE)再送回数』が示されている。これらについて説明すると、まず、『404 Not Found』は、上記したように、単なる電話番号の押し間違いや記憶違いなどによっても発生し得ることから、ナンバースキャンニングを行う端末であるか否かを判定すべく、『404 Not Found』を含むSIPパケットが送信された回数を、統計情報として引き続き収集しようとするものである。
また、『CANCEL』は、『着信側端末を呼んでいる間(Ringing)に、発信側端末から電話を切った』という状態にあることを示す状態情報として、発信側端末から送信されるSIPパケットに含まれる情報である。『404 Not Found』と同様、ナンバースキャンニングの結果として、『CANCEL』が含まれるSIPパケットが送信される可能性も高いと考えられるが、『着信側端末を呼んでいる間(Ringing)に、発信側端末から電話を切った』という状態は、ナンバースキャンニングでなくとも通常の状態として発生し得るものである。したがって、『CANCEL』を含むSIPパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
また、『BYE』は、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態にあることを示す状態情報として、発信側端末から送信されるSIPパケットに含まれる情報である。『404 Not Found』と同様、ナンバースキャンニングの結果として、『BYE』が含まれるSIPパケットが送信される可能性も高いと考えられるが、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態は、ナンバースキャンニングでなくとも通常の状態として発生し得るものである。したがって、『BYE』を含むSIPパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
なお、図4では明示していないが、実施例1においては、『CANCEL』および『BYE』を収集するにあたり、発信側端末からSIPサーバ2に向けて送信された『CANCEL』および『BYE』を統計情報として収集するのではなく、SIPサーバ2から着信側端末に向けて送信される『CANCEL』および『BYE』を統計情報として収集することが望ましいと考えている。すなわち、仮に、ナンバースキャンニング検知装置10が、発信側端末からSIPサーバ2に向けて送信された『CANCEL』および『BYE』を統計情報として収集するものであるとすると、この点を衝いたDoS攻撃またはDDoS攻撃を受けた場合に、ナンバースキャンニング検知装置10がダウンしてしまうおそれがあるからである。すなわち、ナンバースキャンニング検知装置10は、認証に成功したユーザについてのみ『CANCEL』や『BYE』を転送し、ランダムに作成したユーザ(ユーザ名)のように認証に成功していないユーザについては『CANCEL』や『BYE』を転送することはない。そうであるとすると、仮に、DoS攻撃またはDDoS攻撃をする端末が大量に送信した場合であっても、『CANCEL』や『BYE』が大量に転送されるわけではないので、ナンバースキャニング検知装置10は、DoS攻撃またはDDoS攻撃に対してリソースを消費することもない。なお、認証に成功した同一の端末(ユーザ名)から大量に送信された場合には、ナンバースキャンニング検知装置10は統計情報を取得することになるが、閾値を超えた時点で遮断することができるので、問題とはならない。
また、『603 Decline』や『200 OK(BYE)の再送』が送信されたことが検知された場合、ナンバースキャンニング検知装置10は、正規の手順で行われなかった回数として、『603 Decline』や『200 OK(BYE)の再送回数』をカウントアップする(統計情報のカウンタを1増やす)。上記したように、正規の手順で行われていないナンバースキャンニングの結果として、『603 Decline』が含まれるSIPパケットが送信される可能性は極めて高いと考えられるが、『着信側端末を呼んでいたが(Ringing)、発信側端末が電話を切ることもないので、SIPサーバ側からエラー切断する』という状態は、ナンバースキャンニングでなくとも通常の状態として決して発生しないとも言い切れないものである。したがって、『603 Decline』を含むSIPパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
また、『200 OK(BYE)再送回数』についても同様に、正規の手順で行われていないナンバースキャンニングの結果として、『200 OK(BYE)』の再送が行われる可能性は極めて高いと考えられるが、ナンバースキャンニングでなくとも通常の状態として決して発生しないとも言い切れないものである。したがって、『200 OK(BYE)』の再送回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
なお、『603 Decline』および『200 OK(BYE)再送回数』のいずれも、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであるという点において、意味がある。すなわち、『CANCEL』や『BYE』のように、発信側端末から自発的に発信されるSIPパケットを統計情報として収集しようとすると、結局、SIPトランザクション処理が正規の手順で行われない場合に、収集すべき情報が収集されないおそれがある。この点、『603 Decline』および『200 OK(BYE)再送回数』のように、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるパケットを統計情報として収集するのであれば、SIPトランザクション処理が正規の手順で行われない場合であっても、収集すべき情報を正確かつ確実に収集することができる。
ユーザ統計テーブル記憶部22は、ナンバースキャンニング検知装置10が取得した情報を統計情報として収集し、記憶する。具体的には、ユーザ統計テーブル記憶部22は、後述する特定パケット統計取得部32aによって取得された情報を統計情報として収集して記憶し、記憶した統計情報は、後述するナンバースキャンニングユーザ検知部32bによる処理に利用されるなどする。なお、ユーザ統計テーブル記憶部22は、これらの統計情報を、特定パケット統計取得部32aによって取得された情報を、その都度記憶するなどする。また、ユーザ統計テーブル記憶部22は、特定パケット統計取得部32aによって所定の時間情報が収集されず、特定パケット統計取得部32aによってリセットされた場合には、所定の時間情報が収集されなかったユーザに対応づけて記憶していた情報を消去するなどしてもよい。このようにすることで、たまたま間違い電話をしてしまったユーザの統計情報を取り続けることを避けることができる。すなわち、たまたま間違い電話をしてしまったユーザの統計情報を取り続けて放置すると、長時間運用すると全てのユーザの統計を持っていることになりかねず、ナンバースキャンニング検知装置10のリソースを消費してしまうからである。
例えば、ユーザ統計テーブル記憶部22は、図5に示すような統計情報を記憶する。図5の例について説明すると、ユーザ統計テーブル記憶部22は、SIPトランザクションにおいて端末を識別する識別子である『SIP−URI(Uniform Resource Identifier)』と、特定パケット統計取得部32aによって取得される情報(特定のパケット)とが状態情報別に対応づけられているものである。なお、図5に示す具体的な数字等も、単なる例示にすぎない。
実施例1において、ナンバースキャンニング検知装置10は、『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』および『200 OK(BYE)の再送回数』を統計情報として収集し、SIPトランザクション処理が正規の手順で行われていない場合(不正の手順で行われている場合)には、『603 Decline』および『200 OK(BYE)の再送回数』を、正規の手順で行われなかった回数(不正の手順で行われた回数)を示す統計情報として収集するものであり、図5は、その収集結果を例示するものである。
閾値ルール記憶部23は、ナンバースキャンニング検知装置10がナンバースキャンニングを行う端末であるか否かを判定する際のルールを記憶する。具体的には、閾値ルール記憶部23は、ユーザ統計テーブル記憶部22に記憶されている統計情報に基づいて、どのような場合にナンバースキャンニングを行う端末であると判定するかを規定したルールを記憶し、記憶したルールは、後述するナンバースキャンニングユーザ検知部32bによる処理に利用されるなどする。なお、閾値ルール記憶部23は、これらのルールを、ナンバースキャンニング検知装置10において検知処理を開始する前などに、運用者によって入力されることなどで記憶する。
例えば、閾値ルール記憶部23は、図6に示すようなルールを記憶する。図6の例について説明すると、閾値ルール記憶部23は、状態情報ごとに、当該状態情報が単位時間あたりに収集された回数で示される閾値を記憶している。例えば、SIPトランザクション処理が正規の手順で行われた場合について、状態情報『404 Not Found』に関する閾値について説明すると、『10回/分』とある。これは、ナンバースキャンニングが疑われる発信側端末として特定された発信側端末に対して、SIPサーバが、1分間に10回以上『404 Not Found』を発信した場合には、当該発信側端末がナンバースキャンニングを行う端末であると判定すべきとする閾値ルールを意味するものである。
制御部30は、ナンバースキャンニング検知装置10を制御して各種処理を実行し、特に本発明に密接に関連するものとしては、図2に示すように、パケット処理部31と、統計取得部32と、ナンバースキャンニングユーザパケット処理部33とを備える。
パケット処理部31は、SIPパケットを検知したり、情報の取得を開始させる。パケット処理部31は、特に本発明に密接に関連するものとしては、図2に示すように、パケット監視部31aと、パケット情報取得部31bと、特定パケット検知部31cと、統計取得起動部31dとを備える。なお、パケット監視部31aとパケット情報取得部31bと特定パケット検知部31cとが、特許請求の範囲に記載の「検知手段」および「第二の検知手段」に対応する機能を備え、統計取得起動部31dが、特許請求の範囲に記載の「情報取得開始手段」に対応する機能を備える。
ところで、実施例1において、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cは、一連の検知処理の中で2度ずつ動作するものとして説明する。すなわち、これらの部による処理は、大きく2つに分類される。第一は、ナンバースキャンニング検知装置10が監視対象としているSIPクライアント3(ナンバースキャンニング業者端末4を含む)全てについて行う処理であり、第二は、ナンバースキャンニング検知装置10が個別の監視対象としているSIPクライアント3(ナンバースキャンニングを行う端末であることが疑われる発信側端末)についてのみ行う処理である。
実施例1においては、まず、SIPサーバ2とSIPクライアント3全てとの間で送受信されるSIPパケットについて、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cが各々の処理を行い(SIPパケットに、ナンバースキャンニングが疑われる状態情報が含まれるか否かを振り分け、必要に応じてクライアント30を個別の監視対象にするまでの第一の処理)、次に、SIPサーバ2と個別の監視対象としているSIPクライアント3との間で送受信されるSIPパケットについて、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cが各々の処理を行う(個別の監視対象とされているSIPクライアント3について、収集すべき統計情報を収集したり、SIPトランザクション処理が正規の手順で行われたか否かの確認する第二の処理)ものであるとする。
パケット監視部31aは、ナンバースキャンニング検知装置10が監視対象とするSIPパケットを監視する。具体的には、パケット監視部31aは、ナンバースキャンニング検知装置10が監視対象としているSIPサーバ2とSIPクライアント3(ナンバースキャンニング業者端末4を含む)との間で行われるSIPトランザクション処理のSIPパケットを抽出し、抽出したSIPパケットは、パケット情報取得部31bによる処理に利用される。
例えば、第一の処理の場合、実施例1におけるナンバースキャンニング検知装置10は、図3に示したように、In-Line接続によって接続されているので、パケット監視部31aは、監視対象とするSIPサーバ2と当該SIPサーバ2配下のSIPクライアント3全てとの間で行われるSIPトランザクション処理のSIPパケットを、モニタリングするなどして抽出する。
また、例えば、第二の処理の場合、パケット監視部31aは、監視対象とするSIPサーバ2と個別の監視対象としているSIPクライアント3との間で行われるSIPトランザクション処理のSIPパケットのみを、モニタリングするなどして抽出する。
パケット情報取得部31bは、監視したSIPパケットから情報(SIPトランザクション処理の状態情報など)を取得する。具体的には、パケット情報取得部31bは、パケット監視部31aによって抽出されたSIPパケットについて、当該SIPパケットのヘッダ情報から、当該SIPパケットの送信先に関する情報や状態情報などを取得し、取得した情報は、特定パケット検知部31cによる処理に利用される。
具体的に例を挙げて説明すると、SIPパケットのヘッダの中には、複数のヘッダフィールドがあり、『To』は、リクエストの送信先を示す情報であり、『From』は、リクエストの送信元を示す情報である。パケット情報取得部31bは、これらの情報から、当該SIPパケットの送信先に関する情報を取得することができる。また、SIPパケットの1行目(スタートライン)には、『リクエスト・ライン』あるいは『ステータス・ライン』が記述される。『リクエスト・ライン』には、例えば、セッションの開始を要求することを要求する『INVITE』が記述されたり、端末の登録を意味する『REGISTER』が記述される。これに対して『ステータス・ライン』には、例えば、暫定応答を示す100番台の番号や、成功応答を示す200番台の番号、あるいは、エラーを示す400〜600番台の番号などが記述される。パケット情報取得部31bは、これらの情報から、状態情報を取得することができる。
特定パケット検知部31cは、監視したSIPパケットから取得した情報から、当該SIPパケットが特定のSIPパケットであるか否かを検知する。具体的には、特定パケット検知部31cは、パケット情報取得部31bによって取得された情報と、パケット検知ルール記憶部21に記憶されているルールとに基づいて、当該情報が取得されたSIPパケットが、ナンバースキャンニングが疑われる状態情報を含むSIPパケットであるか否か、統計情報として収集すべきSIPパケットであるか否か(同時に、SIPトランザクション処理が正規の手順で行われているか否か)を検知し、検知した結果は、統計取得起動部31dによる処理や特定パケット統計取得部32aによる処理に利用されるなどする。
例えば、第一の処理の場合、特定パケット検知部31cは、パケット検知ルール記憶部21に記憶されているルールに、『404 Not Found』があることから、パケット情報取得部31bによって取得された情報が、「『ステータス・ライン』が『404 Not Found』である」との情報であるか否かを判定する。判定の結果、パケット情報取得部31bによって取得された情報が、「『ステータス・ライン』が『404 Not Found』である」との情報である場合には(図7を参照)、特定パケット検知部31cは、『404 Not Found』を含むSIPパケットが送信されたことを検知したこと、および、当該SIPパケットの送信先に関する情報(発信側端末を識別するSIP−URIなど)を、統計取得起動部31dに伝達する。ここで、この『404 Not Found』が送信される契機となった発信を行った発信側端末について、すでに統計情報の収集が開始されているのであれば、統計取得起動部31dに伝達された検知は無視されることになる。
また、例えば、第二の処理の場合、特定パケット検知部31cは、パケット検知ルール記憶部21に記憶されているルールに、『404 Not Found』(図9を参照)、『CANCEL』(図10を参照)、『200 OK』(図11を参照)、『603 Decline』(図12を参照)および『200 OK(BYE)再送回数』(図8を参照)があることから、パケット情報取得部31bによって取得された情報が、これらの情報であるか否かを判定する。判定の結果、パケット情報取得部31bによって取得された情報がこれらの情報に該当する場合には、パケット検知ルール記憶部21は、これらの情報、および、当該SIPパケットの送信先に関する情報(発信側端末を識別するSIP−URIなど)を、特定パケット統計取得部32aに伝達する。
ここで、第二の処理の場合、特定パケット検知部31cは、パケット情報取得部31bによって取得された情報が、『603 Decline』であるか否か、あるいは、『200 OK(BYE)』が繰り返し再送されているか否かを判定し、これらのパケットであると検知(判定)すると、SIPトランザクション処理が正規の手順で行われなかったことを検知している。したがって、これらの情報、および、当該SIPパケットの送信先に関する情報)を受信した特定パケット統計取得部32aでは、これらの情報を、正規の手順で行われなかった回数としてカウントすることになる。なお、再送を判定するにあたっては、特定パケット検知部31cは、一時的に情報を収集することになるが、これは、特定パケット統計取得部32aによる統計情報の収集とは異なるものであり、一時的に判定するものにすぎない。
統計取得起動部31dは、特定のSIPパケットが送信される契機となった発信を行ったユーザ(発信側端末)に関係して行われるSIPトランザクション処理について、統計の取得が開始されていない場合、そのユーザについて情報の取得を開始する。また、統計取得起動部31dは、統計の取得がすでに開始されているユーザ(個別の監視対象となっている発信側端末)であって、SIPトランザクション処理が正規の手順で行われていない発信側端末に関係して行われるSIPトランザクション処理について、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバ2から送信されるSIPパケットに関する情報の取得を開始する。
具体的には、統計取得起動部31dは、特定パケット検知部31cから、ナンバースキャンニングが疑われる状態情報を含むSIPパケットが取得されたこと、あるいは、SIPトランザクション処理が正規の手順で行われていないことを受信すると、受信した内容に応じて、後述する特定パケット統計取得部32aを起動したり、特定パケット統計取得部32aに収集させる統計情報を追加・変更するなどする。
統計取得部32は、取得した情報を統計情報として収集し、収集した統計情報に基づいて、ナンバースキャンニングを行う端末であるか否かを検知する。統計取得部32は、特に本発明に密接に関連するものとしては、図2に示すように、特定パケット統計取得部32aと、ナンバースキャンニングユーザ検知部32bとを備える。なお、特定パケット統計取得部32aが、特許請求の範囲に記載の「統計情報収集手段」に対応する機能を備え、ナンバースキャンニングユーザ検知部32bが、特許請求の範囲に記載の「判定手段」に対応する機能を備える。
特定パケット統計取得部32aは、取得した統計情報を収集する。具体的には、特定パケット統計取得部32aは、統計取得起動部31dによって起動されると、指定された発信側端末について、統計情報を収集し、ユーザ統計テーブル記憶部22に記憶させる。また、特定パケット統計取得部32aは、統計取得起動部31dによって、統計情報の追加や変更を指定されると、指定された発信側端末について、統計情報の追加や変更を行った上で統計情報を収集し、ユーザ統計テーブル記憶部22に記憶させる。また、特定パケット統計取得部32aは、特定パケット検知部31cによって情報を伝達されると、これらの情報を、指定された発信側端末についてユーザ統計テーブル記憶部22に記憶させる。
ナンバースキャンニングユーザ検知部32bは、収集した統計情報に基づいて、ナンバースキャンニングを行う端末であるか否かを検知する。具体的には、ナンバースキャンニングユーザ検知部32bは、閾値ルール記憶部23に記憶されている閾値ルールと、ユーザ統計テーブル記憶部22に記憶されている統計情報とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定し、判定結果は、ナンバースキャンニングユーザパケット処理部33による処理に利用されるなどする。
例えば、ナンバースキャンニングユーザ検知部32bは、図5の一行目に示すように、『404 Not Found』の回数が『15』となっている場合に、図6の一行目に示すように、『10回/分』の閾値ルールと比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合であるとして、SIP−URIが『0x0−1111−1111』の発信側端末がナンバースキャンニングを行う端末であると判定する。
なお、実施例1においては、上記したように、閾値ルール記憶部23が、状態情報ごとの閾値ルールを記憶しており(例えば、『404 Not Found』について『10回/分』など)、ナンバースキャンニングユーザ検知部32bが、所定の端末について、状態情報ごとの閾値ルールと当該状態情報に該当する統計情報(例えば、『404 Not Found』の回数が『15』である、など)とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法について説明したが、本発明はこれに限られるものではない。
例えば、閾値ルール記憶部23が、状態情報ごとに区別することなく複数の状態情報に対して一つの閾値ルールを記憶しており(例えば、『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』および『200 OK再送回数』の合計について、『20回/分』など)、ナンバースキャンニング検知部32bが、所定の端末について、この閾値ルールと統計情報の合計値(例えば、『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』および『200 OK再送回数』の統計情報の合計回数が『24』である、など)とを比較し、統計情報の合計値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法などにも、本発明を同様に適用することができる。
また、例えば、閾値ルール記憶部23が、状態情報ごとに重み付けをした上で計算された一つの閾値ルールを記憶しており(例えば、ナンバースキャンニングとして顕著な状態情報である『404 Not Found』は重み付けを重くし、『BYE』は重み付けを軽くするなど)、ナンバースキャニング検知部32bが、所定の端末について、この閾値ルールと、閾値ルールの重み付けに従って計算された統計情報の合計値とを比較し、統計情報の合計値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法などにも、本発明を同様に適用することができる。
このように、本発明において、閾値ルール記憶部23がどのような閾値ルールを記憶し、ナンバースキャニングユーザ検知部32bがどのようにナンバースキャンニングを行う端末であると検知するかに関する具体的な手法は、特定の手法に限定されるものではない。収集された統計情報に基づいて判定する手法であれば、ナンバースキャンニング検知装置10が運用されるシステムの状況などに応じて、適宜変更されたり選択されたりするものである。
ナンバースキャンニングユーザパケット処理部33は、ナンバースキャンニングを行う端末のSIPパケットを遮断する。具体的には、ナンバースキャンニングユーザパケット処理部33は、ナンバースキャンニングユーザ検知部32bによって、ナンバースキャンニングを行う端末であると判定された発信側端末について、当該発信側端末から発信されたSIPパケットを遮断するなどする。ナンバースキャンニングは、発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから、当該発信側端末が当該電話番号に関する情報を取得するものであるので、ナンバースキャンニングユーザパケット処理部33によって、当該発信側端末から発信されたSIPパケットが遮断されれば、発信側端末は、当該電話番号に関する情報を取得することができなくなり、ナンバースキャンニングできない結果となる。
なお、実施例1においては、ナンバースキャンニング検知装置10が、ナンバースキャンニングユーザパケット処理部33を備え、ナンバースキャンニングを行う端末として判定した端末のSIPパケットについては遮断する、という対応策を行う事例について説明したが、本発明において、当該対応策を採ることが必須であるという意味ではない。例えば、ナンバースキャンニングを行う端末として判定した端末について、当面はSIPパケットを遮断するなどの直接的な行為に移らず、当該端末のSIP−URIを単にブラックリストに管理するなどの対応策を行ってもよい。
[実施例1に係るナンバースキャンニング検知装置による処理の流れ]
次に、図13および14を用いて、実施例1に係るナンバースキャンニング検知装置10による処理の流れについて例示する。図13は、ナンバースキャンニング検知装置における個別ユーザ監視トリガーを示すフローチャートであり、図14は、ナンバースキャンニング検知装置における個別ユーザ監視を示すフローチャートである。
なお、上記したように、実施例1においては、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cは、2度ずつ動作するものとして説明する。第一の処理は、SIPサーバ2とSIPクライアント3全てとの間で送受信されるSIPパケットについて、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cが各々行う処理(個別ユーザ監視トリガー)、第二の処理は、SIPサーバ2と個別の監視対象としているSIPクライアント3との間で送受信されるSIPパケットについて、パケット監視部31a、パケット情報取得部31bおよび特定パケット検知部31cが各々行う処理(個別ユーザ監視)である。なお、本発明はこのような処理手法に限られるものではなく、その他の処理手法によっても、本発明を同様に適用することができる。
[個別ユーザ監視トリガー]
まず、パケット監視部31aが、監視端末に関わるパケットを抽出する(ステップS101)。具体的には、パケット監視部31aが、監視対象としているSIPサーバ2とSIPクライアント3全てとの間で行われるSIPトランザクション処理のSIPパケットを、モニタリングするなどして抽出する。
次に、パケット情報取得部31bが、IPヘッダにより受信あるいは送信パケットを判断する(ステップS102)。具体的には、パケット情報取得部31bが、パケット監視部31aによって抽出されたSIPパケットについて、当該SIPパケットのヘッダ情報から、当該SIPパケットの送信先に関する情報などを取得する。
続いて、パケット情報取得部31bは、パケットのSIPヘッダ部分を取り出す(ステップS103)。具体的には、パケット情報取得部31bは、パケット監視部31aによって抽出されたSIPパケットについて、当該SIPパケットのヘッダ情報から、状態情報などを取得する。
そして、特定パケット検知部31cが、『404 Not Found』パケットであるか否かを判定する(ステップS104)。具体的には、特定パケット検知部31cは、パケット検知ルール記憶部21に記憶されているルールに、『404 Not Found』があることから、パケット情報取得部31bによって取得された情報が、「『ステータス・ライン』が『404 Not Found』である」との情報であるか否かを判定する。判定の結果、「『ステータス・ライン』が『404 Not Found』である」との情報でない場合には(ステップS104否定)、ナンバースキャンニング検知装置10は、処理を終了する。
一方、「『ステータス・ライン』が『404 Not Found』である」との情報である場合には(ステップS104肯定)、特定パケット検知部31cは、『404 Not Found』を含むSIPパケットが送信されたことを検知したこと、および、当該SIPパケットの送信先に関する情報を、統計取得起動部31dに伝達する。
すると、統計取得起動部31dは、個別監視対象のユーザへのパケットであるか否かを判定する(ステップS105)。具体的には、統計取得起動部31dは、特定パケット検知部31cから、ナンバースキャンニングが疑われる状態情報(『404 Not Found』)を含むSIPパケットが取得されたことを受信すると、当該SIPパケットが、すでに特定パケット統計取得部32aによって統計情報の取得が開始されている個別監視対象のユーザへのパケットであるか否かを判定する。判定の結果、このようなユーザである場合には(ステップS105肯定)、ナンバースキャンニング検知装置10は、このまま処理を終了する。
一方、このようなユーザでない場合には(ステップS105否定)、すなわち、特定パケット統計取得部32aによって統計情報の取得が開始されていないユーザである場合には、統計取得起動部31dは、監視対象のユーザとして加え、そのユーザの監視を始める(ステップS106)。具体的には、特定パケット統計取得部32aを起動し、パケット監視部31aによる個別監視の対象ユーザに加える。
[個別ユーザ監視]
続いて、個別ユーザ監視のフローチャートについて説明すると、パケット監視部31aが、監視端末に関わるパケットを再び抽出する(ステップS201)。具体的には、パケット監視部31aが、監視対象としているSIPサーバ2と個別の監視対象としているSIPクライアント3との間で行われるSIPトランザクション処理のSIPパケットを、モニタリングするなどして抽出する。
次に、パケット情報取得部31bが、IPヘッダにより受信あるいは送信パケットを判断する(ステップS202)。具体的には、パケット情報取得部31bが、パケット監視部31aによって抽出されたSIPパケットについて、当該SIPパケットのヘッダ情報から、当該SIPパケットの送信先に関する情報などを取得する。
続いて、パケット情報取得部31bは、パケットのSIPヘッダ部分を取り出す(ステップS203)。具体的には、パケット情報取得部31bは、パケット監視部31aによって抽出されたSIPパケットについて、当該SIPパケットのヘッダ情報から、状態情報などを取得する。
そして、特定パケット検知部31cは、統計情報として収集する特定のSIPパケットであるか否かを判定する(ステップS204)。具体的には、特定パケット検知部31cは、パケット情報取得部31bによって取得された情報が、パケット検知ルール記憶部21に記憶されているルールで指定されている情報(『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』、あるいは『200 OK(BYE)の再送』)であるか否かを判定する。パケット検知ルール記憶部21に記憶されているルールで指定されている情報でない場合(ステップS204否定)、ナンバースキャンニング検知装置10は、処理を終了する。
一方、パケット検知ルール記憶部21に記憶されているルールで指定されている情報(『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』、あるいは『200 OK(BYE)の再送』)である場合(ステップS204肯定)、特定パケット検知部31cは、これらの情報、および、当該SIPパケットの送信先に関する情報を、特定パケット統計取得部32aに伝達する。なお、実施例1における特定パケット検知部31cは、ここで、同時に、特定のパケットが、『603 Decline』もしくは『200 OK(BYE)の再送』であるか否かについても検知している。これらの情報である場合には、ナンバースキャンニング検知装置10は、発信側端末がSIPトランザクション処理を行っていないと検知(判定)するので、特定パケット統計取得部32aに、これらの情報を正規の手順で行われなかった回数として収集させる(カウントアップさせる)ことになる。
そして、特定パケット統計取得部32aは、統計情報を収集する(ステップS205)。具体的には、特定パケット統計取得部32aは、指定された発信側端末について、統計情報(『404 Not Found』、『CANCEL』、『BYE』、『603 Decline』、あるいは『200 OK(BYE)の再送』)を収集し、ユーザ統計テーブル記憶部22に記憶させる。なお、特定のパケットが『603 Decline』もしくは『200 OK(BYE)の再送』である場合には、特定パケット統計取得部32aは、これらの情報を、正規の手順で行われなかった回数として収集する。
続いて、ナンバースキャンニングユーザ検知部32bが、閾値を超過したか否かを判定する(ステップS206)。具体的には、ナンバースキャンニングユーザ検知部32bは、閾値ルール記憶部23に記憶されている閾値ルールと、ユーザ統計テーブル記憶部22に記憶されている統計情報とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に(ステップS206肯定)、発信側端末がナンバースキャンニングを行う端末であると判定し、ナンバースキャンニングを検出し(ステップS207)、ナンバースキャンニングユーザパケット処理部33に当該検出結果を伝達するなどする。
一方、ステップS206において、閾値を超過していない場合には(ステップS206否定)、監視期間を延長するなどして(ステップS208)、処理を終了する。
なお、本発明はこのような処理の手順に限られるものではなく、その他の処理の手順によっても、同様に適用することができる。例えば、まず、全てのSIPパケットについて、個別の監視対象としているSIPクライアント3のSIPパケットであるか否かの振り分けを行い、次に、個別の監視対象となっていないSIPクライアント3のSIPパケットについては、ナンバースキャンニングが疑われる状態情報が含まれるかという振り分けや、SIPトランザクション処理が正規の手順で行われているか否かの振り分けを行い、個別の監視対象となっているSIPクライアント3のSIPパケットについては、収集すべき統計情報を収集するなど、処理の手順は、運用形態などに併せて適宜変更できるものである。
[実施例1の効果]
上記してきたように、実施例1によれば、発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、ナンバースキャンニングが疑われる情報であってSIPトランザクション処理が所定の状態にあることを示す状態情報を含むSIPパケットが送信されたことを検知し、状態情報を含むSIPパケットが送信されたことが検知されたことを条件として、SIPパケットが送信される契機となった発信を行った発信側端末を特定し、特定した当該発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始し、情報の取得が開始されると、取得した情報を統計情報として収集し、収集された統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定するので、ナンバースキャンニングを検知する際の負荷を低減することが可能になる。
すなわち、本発明によれば、ナンバースキャンニング検知装置は、常に全ての端末について統計情報を収集し、管理し続けなければならない従来の手法とは異なり、ナンバースキャンニングが疑われる状態情報を含むSIPパケットが送信されたことを検知したことをトリガーとして、ナンバースキャンニングを行う端末であると疑われる発信側端末についてのみ統計情報を収集するものであることから、従来の手法に比較して、全てのユーザの統計を取得する必要がなく、リソース消費も少なく、負荷を低減することが可能になる。
また、実施例1によれば、状態情報を含むSIPパケットとして、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
すなわち、従来の手法は、発信側端末から送信されたSIPパケット(発信呼)をトリガーとして統計情報を収集する手法であることから、この点を衝いたDoS攻撃またはDDoS攻撃(例えば、『INVITE』の大量送信)を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれがあった。これに対して、本発明によれば、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットをトリガーとして統計情報を収集することになるので(なお、SIPサーバは、認証されたユーザ(発信側端末)のSIPパケットにしか返答しない)、DoS攻撃またはDDoS攻撃の影響を受けることもなく、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、状態情報を含むSIPパケットとして、404 Not Foundメッセージを含むSIPパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、統計情報として、SIPサーバから送信されるSIPパケットに関する情報のみを収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
すなわち、従来の手法は、発信側端末から送信されたSIPパケットを統計情報として収集する手法であることから、この点を衝いたDoS攻撃またはDDoS攻撃を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれがあった。これに対して、本発明によれば、SIPサーバから送信されるSIPパケットのみを統計情報として収集することになるので、DoS攻撃またはDDoS攻撃の影響を受けることもなく、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、情報の取得が開始された発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知し、統計情報として、検知された発信側端末がSIPトランザクション処理を正規の手順で行わなかった回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
すなわち、従来の手法のように、発信側途中放棄呼に関する統計情報を収集する手法では、不正なトランザクション手順によって発信側途中放棄呼が送信されない場合には、ナンバースキャンニングを正確かつ確実に検知することができない。これに対して、本発明によれば、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットに関する情報(例えば、『603 Decline』など)を統計情報として収集するので、発信側途中放棄呼が送信されない場合にも、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、情報の取得が開始された発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送されたこと、あるいは、発信側端末に対してSIPサーバから603 Declineが送信されたことから、当該発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、SIPトランザクション処理を正規の手順で行わなかった回数として、発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送された回数、および/または、発信側端末に対してSIPサーバから603 Declineが送信された回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、実施例1によれば、予め記憶部に記憶している所定の閾値と、収集された統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定するので、上記の効果に加え、ナンバースキャンニングを適切に判定することが可能になる。
また、実施例1によれば、所定の発信側端末に関係して行われるSIPトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットするので、上記の効果に加え、ナンバースキャンニング検知装置を効率的に運用することが可能になる。