(57)【特許請求の範囲】
【請求項１】
発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、
前記所定の電話番号に発信した発信側端末に対してＳＩＰサーバが送信したＳＩＰパケットのうち、接続先がないことを示す情報を含むＳＩＰパケットを検知する第一の検知手段と、
前記第一の検知手段によって前記接続先がないことを示す情報を含むＳＩＰパケットが検知されたことを条件として、当該ＳＩＰパケットの送信先となる発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始する情報取得開始手段と、
前記情報取得開始手段によってＳＩＰトランザクション処理について情報の取得を開始された発信側端末に対して送信されるＳＩＰパケットのうち、メッセージをＳＩＰサーバに送信することなくＳＩＰトランザクション処理を終了させたことを示す情報を含むＳＩＰパケットを検知する第二の検知手段と、
前記情報取得開始手段によって情報の取得が開始されると、取得した情報と前記第二の検知手段によるＳＩＰパケットの検知回数とを統計情報として収集する統計情報収集手段と、
前記統計情報収集手段によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手段と、
を備えたことを特徴とするナンバースキャンニング検知装置。
【請求項２】
前記第一の検知手段は、前記接続先がないことを示す情報を含むＳＩＰパケットとして、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージを含むＳＩＰパケットが送信されたことを検知することを特徴とする請求項１に記載のナンバースキャンニング検知装置。
【請求項３】
前記統計情報収集手段は、前記統計情報として、ＳＩＰサーバから送信されるＳＩＰパケットに関する情報のみを収集することを特徴とする請求項１又は２に記載のナンバースキャンニング検知装置。
【請求項４】
前記統計情報収集手段は、前記統計情報として、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージ、ＣＡＮＣＥＬメッセージ、ＢＹＥメッセージのいずれか一つまたは複数を収集することを特徴とする請求項１〜３のいずれか一つに記載のナンバースキャンニング検知装置。
【請求項５】
前記第二の検知手段は、前記情報取得開始手段によって情報の取得が開始された前記発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送されたこと、あるいは、前記発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信されたことから、当該発信側端末による前記メッセージをＳＩＰサーバに送信することなくＳＩＰトランザクション処理を終了させたことを検知することを特徴とする請求項１〜４のいずれか一つに記載のナンバースキャンニング検知装置。
【請求項６】
前記統計情報収集手段は、前記発信側端末による前記メッセージをＳＩＰサーバに送信することなくＳＩＰトランザクション処理を終了させた回数として、前記発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送された回数、および／または、前記発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信された回数を収集することを特徴とする請求項１〜５のいずれか一つに記載のナンバースキャンニング検知装置。
【請求項７】
前記判定手段は、予め記憶部に記憶している所定の閾値と、前記統計情報収集手段によって収集された前記統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、前記発信側端末が前記ナンバースキャンニングを行う端末であると判定することを特徴とする請求項１〜６のいずれか一つに記載のナンバースキャンニング検知装置。
【請求項８】
前記統計情報収集手段は、所定の発信側端末に関係して行われるＳＩＰトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットすることを特徴とする請求項１〜７のいずれか一つに記載のナンバースキャニング検知装置。
【請求項９】
発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知方法をコンピュータに実行させるナンバースキャンニング検知プログラムであって、
前記所定の電話番号に発信した発信側端末に対してＳＩＰサーバが送信したＳＩＰパケットのうち、接続先がないことを示す情報を含むＳＩＰパケットを検知する第一の検知手順と、
前記第一の検知手順によって前記接続先がないことを示す情報を含むＳＩＰパケットが検知されたことを条件として、当該ＳＩＰパケットの送信先となる発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始する情報取得開始手順と、
前記情報取得開始手順によってＳＩＰトランザクション処理について情報の取得を開始された発信側端末に対して送信されるＳＩＰパケットのうち、メッセージをＳＩＰサーバに送信することなくＳＩＰトランザクション処理を終了させたことを示す情報を含むＳＩＰパケットを検知する第二の検知手段と、
前記情報取得開始手順によって情報の取得が開始されると、取得した情報と前記第二の検知手順によるＳＩＰパケットの検知回数とを統計情報として収集する統計情報収集手順と、
前記統計情報収集手順によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手順と、
をコンピュータに実行させることを特徴とするナンバースキャンニング検知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムに関する。
【背景技術】
【０００２】
近年、ＳＩＰ（Session  Initiation  Protocol）を用いたＩＰ（Internet  Protocol）電話サービスが普及しているが、ＩＰ電話は低コストで発信できることから、この点を悪用した「ナンバースキャンニング」と呼ばれる脅威が登場している。「ナンバースキャンニング」とは、ナンバースキャンニングを企てる業者（以下、ナンバースキャンニング業者）が、存在するか否かが不明な電話番号にランダムに発信し、その応答によって、発信した電話番号が存在するか否かを判定し、存在すると判定した電話番号を取得するものである。
【０００３】
以下に、「ナンバースキャンニング」について、具体的に例を挙げて説明する。図１７の（Ａ）は、ナンバースキャンニング業者が発信した電話番号が、存在する電話番号であった場合の例であり、図１７の（Ｂ）は、存在しない電話番号であった場合の例である。図１７の（Ａ）に示すように、ナンバースキャンニング業者が、電話番号『１１１』を入力することで電話番号『１１１』に発信すると、ＳＩＰのメッセージ『INVITE  111』が、ＩＰ電話のＳＩＰサーバに送信される（図１７の（Ａ）の（１）を参照）。ＳＩＰサーバは、電話番号『１１１』が存在する電話番号であるので、この『INVITE  111』を、電話番号『１１１』の電話機に転送する（図１７の（Ａ）の（２）を参照）。『INVITE  111』が転送されると、電話番号『１１１』の電話機は、ＳＩＰのメッセージ『Ringing』（電話番号『１１１』の電話機において着信音が鳴っていることを示す）を、ＳＩＰサーバに送信する（図１７の（Ａ）の（３）を参照）。すると、ＳＩＰサーバは、この『Ringing』を、ナンバースキャンニング業者に転送する（図１７の（Ａ）の（４）を参照）。この応答によって、ナンバースキャンニング業者は、電話番号『１１１』が存在することを判定し（図１７の（Ａ）の（５）を参照）、その後、電話を切る。
【０００４】
一方、図１７の（Ｂ）に示すように、ナンバースキャンニング業者が、電話番号『８８８』を入力することで電話番号『８８８』に発信すると、ＳＩＰのメッセージ『INVITE  888』が、ＩＰ電話のＳＩＰサーバに送信される（図１７の（Ｂ）の（１）を参照）。ＳＩＰサーバは、電話番号『８８８』が存在しない電話番号であるので、存在しない電話番号であることを示す『404  NotFound』を、ナンバースキャンニング業者に送信する（図１７の（Ｂ）の（２）を参照）。この応答によって、ナンバースキャンニング業者は、電話番号『８８８』が存在しないことを判定し（図１７の（Ｂ）の（３）を参照）、その後、電話を切る。
【０００５】
なお、「ナンバースキャンニング」は、『Ringing』による応答ではなく、相手が出たこと（『200  OK』）による応答によって判定したり、電話番号を入力することで発信するのではなく、電話番号に発信するプログラムを利用することで発信することもある。後者の場合、「ナンバースキャンニング」は、正規のＳＩＰトランザクション手順に従わずに電話を切ることができてしまう。
【０００６】
このような「ナンバースキャンニング」によってナンバースキャンニング業者に取得された電話番号は、例えば、ワン切り（相手の電話機に着信履歴を残すことによって相手に電話をかけ直させ、有害サイトへの勧誘などを行うこと）や、自動応答広告配信（発信した電話番号の相手が電話に出ると、自動音声の広告や有害サイトへの勧誘などを行うこと）に悪用される。このため、「ナンバースキャンニング」に対する対応策が急務となるが、ナンバースキャンニングを行う電話の電話番号（発信者番号）を予め特定することは難しく、着信拒否の方法を採ることはできない。なお、ナンバースキャンニングと同様の発信の特徴を持つ「ワン切り」に対する対応策として、例えば、特許文献１〜３に示すような対応策がある。
【０００７】
特許文献１には、特定のパケット（INVITEメッセージ、BYE/CANCELメッセージ）を規定時間内に受信した回数で、「ワン切り」を行う端末（ユーザ）を判定する対応策が開示されている。図１８および１９を用いて具体的に説明すると、ワン切り業者が電話番号『１１１』に発信すると、図１７で説明した事例と同様、『INVITE  111』がＳＩＰサーバに送信され（図１８の（１）を参照）、『INVITE  111』が電話番号『１１１』の電話機に転送され（図１８の（２）を参照）、『Ringing』がＳＩＰサーバに送信され（図１８の（３）を参照）、『Ringing』がワン切り業者に転送され（図１８の（４）を参照）、ワン切り業者が、電話番号『１１１』が存在することを判定する（図１８の（５）を参照）。その後、ワン切り業者は、ＳＩＰのメッセージ『CANCEL』（もしくは『BYE』。『CANCEL』は、着信音が鳴ったときに電話を切るメッセージ、『BYE』は、相手が電話に出てから電話を切るメッセージ）を、ＳＩＰサーバに送信することで電話を切り（図１８の（６）を参照）、ＳＩＰサーバは、この『CANCEL』を、電話番号『１１１』の電話機に転送する（図１８の（７）を参照）ことになる。ここで、特許文献１の対応策は、図１９に示すように、（１）の『INVITE  111』を転送してから（７）の『CANCEL』（または『BYE』）を転送するまでの時間が規定時間内であった場合に、発信側端末について統計情報を収集し、「ワン切り」を行う端末を判定するなどする。
【０００８】
また、特許文献２には、発信側途中放棄呼（CANCELメッセージ）を受信した回数で、「ワン切り」を行う端末を判定する対応策が開示されている。具体的に説明すると、特許文献２の対応策は、発信側端末からＳＩＰのメッセージ『INVITE』が送信され、その後、発信側端末から『CANCEL』が送信された場合に、発信側端末が断呼したと判断して発信側途中放棄呼数の統計情報を収集し、「ワン切り」を行う端末を判定するなどする。また、特許文献３には、単位時間あたりの発呼（INVITEメッセージ、REGISTERメッセージ）の回数や呼切断（BYEメッセージ）の回数で、「ワン切り」を行う端末を判定する対応策が開示されている。具体的に説明すると、特許文献３の対応策は、ＳＩＰサーバにおける『INVITE』や『REGISTER』各々の単位時間あたりの総数が閾値を上回った場合や、発信側端末が断呼した回数が閾値を上回った場合などに、「ワン切り」を行う端末を判定するなどする。
【０００９】
【特許文献１】特開２００５−２０５２４号公報
【特許文献２】特開２００６−１２９２９４号公報
【特許文献３】特開２００７−６０３７９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ところで、上記した従来の技術では、以下に説明するように、ナンバースキャンニングを検知する際の負荷が高いという課題がある。すなわち、ナンバースキャンニングと同様の発信の特徴を持つ「ワン切り」に対する対応策を、ナンバースキャンニングに対する対応策に代用することを考え、これを検討してみると、特許文献１〜３に開示されている対応策のいずれも、発信呼（『INVITE』、『REGISTER』）や発信側途中放棄呼（『CANCEL』、『BYE』）に関する統計情報を収集する手法であることから、常に全ての端末について統計情報を収集し、管理し続けなければならず、ナンバースキャンニングを検知する際の負荷が高い。
【００１１】
また、上記した従来の技術では、以下に説明するように、ナンバースキャンニングを正確かつ確実に検知することができないという課題がある。すなわち、ナンバースキャンニングがプログラムによって行われ、不正なトランザクション手順によって発信側途中放棄呼が送信されない場合には、特許文献１〜３に開示されている対応策の内、発信側途中放棄呼に関する統計情報を収集する手法では、ナンバースキャンニングを正確かつ確実に検知することができない。また、特許文献１〜３に開示されている対応策のいずれも、発信側端末から送信されたＳＩＰパケット（発信呼）をトリガーとして統計情報を収集する手法であることから、この点を衝いたＤｏＳ（Denial  of  Service）攻撃またはＤＤｏＳ（Distributed  ＤｏＳ）攻撃を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれもあることから、ナンバースキャンニングを正確かつ確実に検知することができない。
【００１２】
なお、上記した課題は、ＳＩＰを用いたＩＰ電話サービスにおけるナンバースキャンニングに限られず、ＳＩＰ以外の他のプロトコル（Ｈ．３２３など）を用いたＩＰ電話におけるナンバースキャンニングにおいても同様に課題となる。また、上記した課題は、ＩＰ電話におけるナンバースキャンニングに限られず、公衆交換電話サービスにおけるナンバースキャンニングや、携帯電話サービスにおけるナンバースキャンニングなどにおいても、同様に課題となる。
【００１３】
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、ナンバースキャンニングを検知する際の負荷を低減することが可能なナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムを提供することを第一の目的とする。
【００１４】
また、この発明は、ナンバースキャンニングを正確かつ確実に検知することが可能なナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムを提供することを第二の目的とする。
【課題を解決するための手段】
【００１５】
上述した課題を解決し、目的を達成するため、本発明は、発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、前記ナンバースキャンニングが疑われる情報であって前記ＳＩＰトランザクション処理が所定の状態にあることを示す状態情報を含むＳＩＰパケットが送信されたことを検知する第一の検知手段と、前記第一の検知手段によって前記状態情報を含むＳＩＰパケットが送信されたことが検知されたことを条件として、当該ＳＩＰパケットが送信される契機となった発信を行った発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始する情報取得開始手段と、前記情報取得開始手段によって情報の取得が開始されると、取得した情報を統計情報として収集する統計情報収集手段と、前記統計情報収集手段によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手段と、を備えたことを特徴とする。
【００１６】
また、本発明は、上記の発明において、前記第一の検知手段は、前記状態情報を含むＳＩＰパケットとして、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットが送信されたことを検知することを特徴とする。
【００１７】
また、本発明は、上記の発明において、前記状態情報を含むＳＩＰパケットとして、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージを含むＳＩＰパケットが送信されたことを検知することを特徴とする。
【００１８】
また、本発明は、上記の発明において、前記統計情報収集手段は、前記統計情報として、ＳＩＰサーバから送信されるＳＩＰパケットに関する情報のみを収集することを特徴とする。
【００１９】
また、本発明は、上記の発明において、前前記統計情報収集手段は、前記統計情報として、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージ、ＣＡＮＣＥＬメッセージ、ＢＹＥメッセージのいずれか一つまたは複数を収集することを特徴とする。
【００２０】
また、本発明は、上記の発明において、前記情報取得開始手段によって情報の取得が開始された前記発信側端末による前記ＳＩＰトランザクション処理が正規の手順で行われていないことを検知する第二の検知手段をさらに備え、前記統計情報収集手段は、前記統計情報として、前記発信側端末が前記ＳＩＰトランザクション処理を正規の手順で行わなかった回数を収集することを特徴とする。
【００２１】
また、本発明は、上記の発明において、前記第二の検知手段は、前記情報取得開始手段によって情報の取得が開始された前記発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送されたこと、あるいは、前記発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信されたことから、当該発信側端末による前記ＳＩＰトランザクション処理が正規の手順で行われていないことを検知することを特徴とする。
【００２２】
また、本発明は、上記の発明において、前記統計情報収集手段は、前記ＳＩＰトランザクション処理を正規の手順で行わなかった回数として、前記発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送された回数、および／または、前記発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信された回数を収集することを特徴とする。
【００２３】
また、本発明は、上記の発明において、前記判定手段は、予め記憶部に記憶している所定の閾値と、前記統計情報収集手段によって収集された前記統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、前記発信側端末が前記ナンバースキャンニングを行う端末であると判定することを特徴とする。
【００２４】
また、本発明は、上記の発明において、前記統計情報収集手段は、所定の発信側端末に関係して行われるＳＩＰトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットすることを特徴とする。
【００２５】
また、本発明は、上記の発明において、発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知方法をコンピュータに実行させるナンバースキャンニング検知プログラムであって、前記ナンバースキャンニングが疑われる情報であって前記ＳＩＰトランザクション処理が所定の状態にあることを示す状態情報を含むＳＩＰパケットが送信されたことを検知する第一の検知手順と、前記第一の検知手順によって前記状態情報を含むＳＩＰパケットが送信されたことが検知されたことを条件として、当該ＳＩＰパケットが送信される契機となった発信を行った発信側端末を特定し、特定した当該発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始する情報取得開始手順と、前記情報取得開始手順によって情報の取得が開始されると、取得した情報を統計情報として収集する統計情報収集手順と、前記統計情報収集手順によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手順と、をコンピュータに実行させることを特徴とする。
【発明の効果】
【００２６】
本発明によれば、発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、ナンバースキャンニングが疑われる情報であってＳＩＰトランザクション処理が所定の状態にあることを示す状態情報を含むＳＩＰパケットが送信されたことを検知し、状態情報を含むＳＩＰパケットが送信されたことが検知されたことを条件として、ＳＩＰパケットが送信される契機となった発信を行った発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始し、情報の取得が開始されると、取得した情報を統計情報として収集し、収集された統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定するので、ナンバースキャンニングを検知する際の負荷を低減することが可能になる。
【００２７】
また、本発明によれば、状態情報を含むＳＩＰパケットとして、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００２８】
また、本発明によれば、状態情報を含むＳＩＰパケットとして、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージを含むＳＩＰパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００２９】
また、本発明によれば、統計情報として、ＳＩＰサーバから送信されるＳＩＰパケットに関する情報のみを収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００３０】
また、本発明によれば、統計情報として、４０４ Ｎｏｔ Ｆｏｕｎｄメッセージ、ＣＡＮＣＥＬメッセージ、ＢＹＥメッセージのいずれか一つまたは複数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００３１】
また、本発明によれば、情報の取得が開始された発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知し、統計情報として、発信側端末がＳＩＰトランザクション処理を正規の手順で行わなかった回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００３２】
また、本発明によれば、情報の取得が開始された発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送されたこと、あるいは、発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信されたことから、当該発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００３３】
また、本発明によれば、ＳＩＰトランザクション処理を正規の手順で行わなかった回数として、発信側端末に対して２００ ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送された回数、および／または、発信側端末に対してＳＩＰサーバから６０３ Ｄｅｃｌｉｎｅが送信された回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【００３４】
また、本発明によれば、予め記憶部に記憶している所定の閾値と、収集された統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定するので、上記の効果に加え、ナンバースキャンニングを適切に判定することが可能になる。
【００３５】
また、本発明によれば、所定の発信側端末に関係して行われるＳＩＰトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットするので、上記の効果に加え、ナンバースキャンニング検知装置を効率的に運用することが可能になる。
【発明を実施するための最良の形態】
【００３６】
以下に添付図面を参照して、本発明に係るナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムの実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例１に係るナンバースキャンニング検知装置の概要および特徴、実施例１に係るナンバースキャンニング検知装置の構成および処理の流れ、実施例１の効果を順に説明し、次に、他の実施例を説明する。
【実施例１】
【００３７】
［用語の説明］
まず最初に、以下の実施例で用いる主要な用語を説明する。「ＳＩＰ（Session  Initiation  Protocol）トランザクション処理」とは、端末間でＳＩＰを用いてセッションを確立する際の一連のトランザクションのことである。ここで、一つのトランザクションは、一般的に、ＳＩＰクライアントがＳＩＰサーバに対して送信したリクエストから、当該ＳＩＰサーバが当該ＳＩＰクライアントに対して送信した最終応答までのメッセージのことである。「トランザクション処理」は、このような一つのトランザクションであることも、あるいは、複数のトランザクションであることもある。具体的に例を挙げて説明すると、発信側端末が着信側端末とセッションを確立することを要求して送信する『INVITE』メッセージと、発信側端末が着信側端末との間のセッションを切断することを要求して送信する『BYE』メッセージとは異なるトランザクションであるが、以下の実施例において「ＳＩＰトランザクション処理のＳＩＰパケット」とは、これらのトランザクションにおいて発信側端末と着信側端末との間で送受信される一連の「ＳＩＰパケット」のことを意味する。かかる「ＳＩＰトランザクション処理」は、上記した例の他に、『404  Not  Found』メッセージまでの一連の「ＳＩＰパケット」となるケースや、『CANCEL』メッセージまでの一連の「ＳＩＰパケット」となるケースなど、様々なケースがある。
【００３８】
ところで、近年、ＳＩＰを用いたＩＰ電話サービスが普及しているが、ＩＰ電話は低コストで発信できることから、この点を悪用した「ナンバースキャンニング」と呼ばれる脅威が登場している。「ナンバースキャンニング」とは、ナンバースキャンニング業者が、存在するか否かが不明な電話番号にランダムに発信し、その応答によって、発信した電話番号が存在するか否かを判定し、存在すると判定した電話番号を取得するものである。具体的に例を挙げて説明すると、「ナンバースキャンニング」とは、発信側端末が、存在するか否かが不明な電話番号に『INVITE』メッセージを発信し、これを契機としてＳＩＰトランザクション処理が行われ、発信側端末が、当該ＳＩＰトランザクション処理のＳＩＰパケットとして『404  Not  Found』メッセージを受信すると、発信した電話番号で識別される端末が存在しないという情報を取得するというものである。
【００３９】
このような「ナンバースキャンニング」によってナンバースキャンニング業者に取得された電話番号は、例えば、ワン切りや自動応答広告配信に悪用されることから、「ナンバースキャンニング」に対する対応策が急務となるが、ナンバースキャンニングを行う発信側端末を予め特定することは難しい。そこで、本発明に係る「ナンバースキャンニング検知装置」は、かかる「ナンバースキャンニング」を行う発信側端末を検知しようとするものである。
【００４０】
［実施例１に係るナンバースキャンニング検知装置の概要および特徴］
まず最初に、図１を用いて、実施例１に係るナンバースキャンニング検知装置の概要および特徴を説明する。図１は、実施例１に係るナンバースキャンニング検知装置の概要および特徴を説明するための図である。
【００４１】
実施例１に係るナンバースキャンニング検知装置は、ナンバースキャンニングが行われる状況において、発信側端末を検知することを概要とし、ナンバースキャンニングを検知する際の負荷を低減することを主たる特徴とするものである。
【００４２】
この主たる特徴について簡単に説明すると、図１に示すように、ナンバースキャンニング検知装置は、ルール記憶部に、ナンバースキャンニングが疑われる状態情報を規定したルールと、この場合に統計情報として収集すべき情報を規定したルールと、どのような場合にナンバースキャンニングを行う端末であると判定するかを規定したルールとを記憶している。
【００４３】
例えば、ナンバースキャンニング検知装置は、ナンバースキャンニングが疑われる情報として、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を記憶している。ここで、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』は、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報として、ＳＩＰサーバから発信側端末に送信されるＳＩＰパケットに含まれる情報である。また、例えば、ナンバースキャンニング検知装置は、統計情報として収集すべき情報を規定したルールとして、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』および『ＢＹＥ』を記憶している。ここで、『ＣＡＮＣＥＬ』は、『着信側端末を呼んでいる間（Ringing）に、発信側端末から電話を切った』という状態であり、『ＢＹＥ』は、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態である。また、例えば、ナンバースキャンニング検知装置は、閾値ルールとして、１分間に１０回以上『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を受信した場合には、ナンバースキャンニングを行う端末であると判定するとするルールである。なお、図１は、ルール記憶部に記憶されている情報を、概念的に示すものである。
【００４４】
このような構成のもと、実施例１に係るナンバースキャンニング検知装置は、ナンバースキャンニングが疑われる情報であって、ＳＩＰトランザクション処理が所定の状態にあることを示す状態情報を含むＳＩＰパケットが送信されたことを検知する（図１の（Ａ）の（１）を参照）。例えば、ナンバースキャンニング検知装置は、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信されたことを検知する。
【００４５】
すると、ナンバースキャンニング検知装置は、所定の状態情報を含むＳＩＰパケットが送信されたことが検知されたことを条件として、当該ＳＩＰパケットが送信される契機となった発信を行った発信側端末を特定する（図１の（Ａ）の（２）を参照）。例えば、ナンバースキャンニング検知装置は、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信されたことが検知されたことを条件として、当該ＳＩＰパケットが送信される契機となった発信を行った発信側端末を特定する。
【００４６】
次に、ナンバースキャンニング検知装置は、特定した発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始する（図１の（Ｂ）の（３）を参照）。
【００４７】
そして、ナンバースキャンニング検知装置は、情報の取得が開始されると、取得した情報を統計情報として収集する（図１の（Ｂ）の（４）を参照）。例えば、ナンバースキャンニング検知装置は、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』および『ＢＹＥ』を統計情報として収集する。
【００４８】
すると、ナンバースキャンニング検知装置は、収集した統計情報に基づいて、特定した発信側端末がナンバースキャンニングを行う端末であるか否かを判定する（図１の（Ｃ）の（５）を参照）。例えば、ナンバースキャンニング検知装置は、１分間に１０回以上『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を受信した場合に、特定した発信側端末がナンバースキャンニングを行う端末であると判定する。
【００４９】
このようなことから、ナンバースキャンニング検知装置は、常に全ての端末について統計情報を収集し、管理し続けなければならない従来の手法とは異なり、ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットが送信されたことを検知したことをトリガーとして、ナンバースキャンニングを行う端末であると疑われる発信側端末についてのみ統計情報を収集するものであることから、従来の手法に比較して、リソース消費も少なく、負荷を低減することが可能になる。
【００５０】
なお、実施例１に係るナンバースキャンニング検知装置は、上記した主たる特徴の他に、情報の取得が開始された発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことも検知し（『６０３  Ｄｅｃｌｉｌｎｅ』、『２００  ＯＫ』の再送回数、あるいは、『ＢＹＥ』の再送回数などで検知）、統計情報として、正規の手順で行われなかった回数（『６０３  Ｄｅｃｌｉｌｎｅ』の送信回数、『２００  ＯＫ』の再送回数、あるいは、『ＢＹＥ』の再送回数など）も収集するものである。この点については、実施例１に係るナンバースキャンニング検知装置の構成等を説明する際に詳述する。
【００５１】
［実施例１に係るナンバースキャンニング検知装置の構成］
次に、図２〜１２を用いて、実施例１に係るナンバースキャンニング検知装置の構成を説明する。図２は、ナンバースキャンニング検知装置の構成を示すブロック図であり、図３は、ナンバースキャンニング検知装置の接続を示すネットワーク図であり、図４は、パケット検知ルール記憶部を説明するための図であり、図５は、ユーザ統計テーブル記憶部を説明するための図であり、図６は、閾値ルール記憶部を説明するための図であり、図７および図８は、情報取得の開始について説明するための図であり、図９〜１２は、統計情報の収集について説明するための図である。
【００５２】
図２に示すように、実施例１に係るナンバースキャンニング検知装置１０は、通信制御部１１と、記憶部２０と、制御部３０とから構成される。
【００５３】
通信制御部１１は、ナンバースキャンニング検知装置１０によって行われる通信を制御する。具体的には、通信制御部１１は、ナンバースキャンニング検知装置１０が、ネットワーク上のＳＩＰパケットを処理する際や、ネットワークを介してその他の装置と通信する際などに、その通信を制御する。
【００５４】
ここで、ナンバースキャンニング検知装置１０の接続について説明すると、ナンバースキャンニング検知装置１０は、実施例１において、図３のように接続する。すなわち、ナンバースキャンニング検知装置１０は、ＳＩＰサーバ２およびＳＩＰクライアント３（ナンバースキャンニング業者端末４を含む）の各々がＩＰ電話網／インターネット１に接続されている中間に、In-Line接続によって接続される。このIn-Line接続によれば、ナンバースキャンニング検知装置１０は、既存のシステムに付加的に挿入されることが可能である。なお、図３においては、ＳＩＰサーバ２、ＳＩＰクライアント３およびナンバースキャンニング業者端末４を各々１台ずつ示すのみであるが、ナンバースキャンニング検知装置１０を適用する上で、各々の構成は１台であっても複数台であってもよい。
【００５５】
かかる接続において、通信制御部１１は、ナンバースキャンニング検知装置１０が、ＩＰ電話網／インターネット１上のＳＩＰパケットを処理する際や、ＩＰ電話網／インターネット１を介してＳＩＰサーバ２やＳＩＰクライアント３と通信する際などに、その通信を制御する。
【００５６】
記憶部２０は、制御部３０による各種処理に用いるデータを記憶し、特に本発明に密接に関連するものとしては、図２に示すように、パケット検知ルール記憶部２１と、ユーザ統計テーブル記憶部２２と、閾値ルール記憶部２３とを備える。
【００５７】
パケット検知ルール記憶部２１は、ナンバースキャンニング検知装置１０が検知すべきＳＩＰパケットについて規定したルールを記憶する。具体的には、パケット検知ルール記憶部２１は、ナンバースキャンニングが疑われる状態情報を規定したルールを記憶し、記憶したルールは、後述する特定パケット検知部３１ｃによる処理に利用されるなどする。また、パケット検知ルール記憶部２１は、統計情報として収集する情報を規定したルールを記憶し、記憶したルールは、特定パケット検知部３１ｃによる処理に利用されるなどする。なお、パケット検知ルール記憶部２１は、これらのルールを、ナンバースキャンニング検知装置１０において検知処理を開始する前などに、運用者によって入力されることなどで記憶する。
【００５８】
例えば、パケット検知ルール記憶部２１は、図４に示すようなルールを記憶する。図４は、ナンバースキャンニングが疑われる状態情報を規定したルールと、この場合に統計情報として収集すべき情報を規定したルールとを示すものである。図４の例について説明すると、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』は、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報として、ＳＩＰサーバから発信側端末に送信されるＳＩＰパケットに含まれる情報である。ナンバースキャンニングは、電話番号が存在するか否かを判定することを目的として、存在するか否かが不明な電話番号にランダムに発信するものであることから、この結果として、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』が含まれるＳＩＰパケットが送信される可能性も高いと考えられる。もっとも、『発信側端末から発信された電話番号は存在しない』という状態は、ナンバースキャンニングでなくとも、単なる電話番号の押し間違いや記憶違いなどによっても発生し得る。したがって、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信されたことを検知したからといって、必ずしも当該ＳＩＰパケットが送信される契機となった発信を行った発信側端末が、ナンバースキャンニング業者の端末であると決めつけることはできない。実施例１においては、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を、少なくとも、ナンバースキャンニングが疑われる状態情報であると考え、ルールに規定している。
【００５９】
なお、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』は、単にナンバースキャンニングが疑われる状態情報であるという他に、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであるという点において、意味がある。すなわち、発信側端末から自発的に発信されるＳＩＰパケットとしては、例えば、『ＩＮＶＩＴＥ』があるが、このような発信呼をトリガーとして統計情報を収集しようとすると、この点を衝いたＤｏＳ攻撃またはＤＤｏＳ攻撃（例えば、『ＩＮＶＩＴＥ』の大量送信）を受けた場合に、ナンバースキャンニング検知装置１０がＤｏＳ攻撃またはＤＤｏＳ攻撃の影響を受けてダウンしてしまうおそれがある。すなわち、『ＩＮＶＩＴＥ』を起点とした従来の手法では、ＤｏＳ攻撃またはＤＤｏＳ攻撃をする端末が『ＩＮＶＩＴＥ』を送信すれば、検知装置の検知ロジックが『ＩＮＶＩＴＥ』に反応して統計情報の取得を開始することになるが、ＤｏＳ攻撃またはＤＤｏＳ攻撃をする端末が送信者をランダムに偽って『ＩＮＶＩＴＥ』を大量に送信した場合、統計情報の取得を開始しなければならない端末の数が膨大になってしまい、検知装置は処理し切れなくなってしまう。この点、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』をトリガーとして統計情報を収集するのであれば、ナンバースキャンニング検知装置１０は、認証に成功したユーザからのＳＩＰパケットに対してのみ『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を送信（返信）し、ランダムに作成したユーザ（ユーザ名）に対しては『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を送信（返信）することはない。そうであるとすると、仮に、ＤｏＳ攻撃またはＤＤｏＳ攻撃をする端末が『ＩＮＶＩＴＥ』を大量に送信した場合であっても、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』が大量に送信（返信）されるわけではないので、ナンバースキャニング検知装置１０は、むやみにランダムに偽装された端末について統計情報の取得を開始することはなく、ＤｏＳまたはＤＤｏＳ攻撃に対してリソースを消費することもない。なお、認証に成功した同一の端末（ユーザ名）から『ＩＮＶＩＴＥ』を大量に送信された場合には、ナンバースキャンニング検知装置１０は統計情報を取得することになるが、閾値を超えた時点で遮断することができるので、問題とはならない。
【００６０】
また、パケット検知ルール記憶部２１は、検知すべき状態情報を規定したルールとして、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）の再送』を記憶している。図４においては、これらの情報は、ナンバースキャンニングが疑われる状態情報の欄に記載されているが、正確には、ナンバースキャンニングが疑われる状態情報として利用されるというよりは、これらが検知された場合、ナンバースキャンニング検知装置１０は、発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知する。
【００６１】
ここで、『６０３  Ｄｅｃｌｉｎｅ』は、『着信側端末を呼んでいたが（Ringing）、発信側端末が電話を切ることもないので（着信側端末の電話が鳴りっぱなしになる）、ＳＩＰサーバ側からエラー切断する』という状態にあることを示す状態情報として、ある一定の時間着信側端末の電話が鳴りっぱなしになった場合に、ＳＩＰサーバから発信側端末に送信されるＳＩＰパケットに含まれる情報である。すなわち、ナンバースキャンニングが、電話番号に発信するプログラムを利用することで行われた場合には、発信側端末は、『ＣＡＮＣＥＬ』や『ＢＹＥ』などをＳＩＰサーバに送信することなく電話を切るという不正な手順で、ＳＩＰトランザクション処理を終了させるおそれがある。したがって、正規の手順で行われていないナンバースキャンニングの結果（着信側端末の電話が鳴りっぱなしになった時の結果）として、『６０３  Ｄｅｃｌｉｎｅ』が含まれるＳＩＰパケットが送信される可能性は極めて高い。また、『２００  ＯＫ（ＢＹＥ）の再送』も同様に、正規の手順で行われていないナンバースキャンニングの結果（着信側端末の相手方が電話に出た時の結果）として、ＳＩＰサーバから発信側端末に『２００  ＯＫ』もしくは『ＢＹＥ』が繰り返し送信される可能性が極めて高いことに着目して規定されているものである。ナンバースキャンニングがこのような不正な手順で行われる場合には、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』の他に収集する情報として『ＣＡＮＣＥＬ』や『ＢＹＥ』を収集するのみでは不十分であるとも考えられる。このため、パケット検知ルール記憶部２１は、発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知し、その回数をカウントすることを目的として、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ（ＢＹＥ）の再送』を記憶している。
【００６２】
一方、図４の例では、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』が送信されたことが検知された場合に統計情報として収集すべき情報を規定したルールとして、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）再送回数』が示されている。これらについて説明すると、まず、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』は、上記したように、単なる電話番号の押し間違いや記憶違いなどによっても発生し得ることから、ナンバースキャンニングを行う端末であるか否かを判定すべく、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信された回数を、統計情報として引き続き収集しようとするものである。
【００６３】
また、『ＣＡＮＣＥＬ』は、『着信側端末を呼んでいる間（Ringing）に、発信側端末から電話を切った』という状態にあることを示す状態情報として、発信側端末から送信されるＳＩＰパケットに含まれる情報である。『４０４  Ｎｏｔ  Ｆｏｕｎｄ』と同様、ナンバースキャンニングの結果として、『ＣＡＮＣＥＬ』が含まれるＳＩＰパケットが送信される可能性も高いと考えられるが、『着信側端末を呼んでいる間（Ringing）に、発信側端末から電話を切った』という状態は、ナンバースキャンニングでなくとも通常の状態として発生し得るものである。したがって、『ＣＡＮＣＥＬ』を含むＳＩＰパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
【００６４】
また、『ＢＹＥ』は、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態にあることを示す状態情報として、発信側端末から送信されるＳＩＰパケットに含まれる情報である。『４０４  Ｎｏｔ  Ｆｏｕｎｄ』と同様、ナンバースキャンニングの結果として、『ＢＹＥ』が含まれるＳＩＰパケットが送信される可能性も高いと考えられるが、『着信側端末が電話に出ると、発信側端末から電話を切った』という状態は、ナンバースキャンニングでなくとも通常の状態として発生し得るものである。したがって、『ＢＹＥ』を含むＳＩＰパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
【００６５】
なお、図４では明示していないが、実施例１においては、『ＣＡＮＣＥＬ』および『ＢＹＥ』を収集するにあたり、発信側端末からＳＩＰサーバ２に向けて送信された『ＣＡＮＣＥＬ』および『ＢＹＥ』を統計情報として収集するのではなく、ＳＩＰサーバ２から着信側端末に向けて送信される『ＣＡＮＣＥＬ』および『ＢＹＥ』を統計情報として収集することが望ましいと考えている。すなわち、仮に、ナンバースキャンニング検知装置１０が、発信側端末からＳＩＰサーバ２に向けて送信された『ＣＡＮＣＥＬ』および『ＢＹＥ』を統計情報として収集するものであるとすると、この点を衝いたＤｏＳ攻撃またはＤＤｏＳ攻撃を受けた場合に、ナンバースキャンニング検知装置１０がダウンしてしまうおそれがあるからである。すなわち、ナンバースキャンニング検知装置１０は、認証に成功したユーザについてのみ『ＣＡＮＣＥＬ』や『ＢＹＥ』を転送し、ランダムに作成したユーザ（ユーザ名）のように認証に成功していないユーザについては『ＣＡＮＣＥＬ』や『ＢＹＥ』を転送することはない。そうであるとすると、仮に、ＤｏＳ攻撃またはＤＤｏＳ攻撃をする端末が大量に送信した場合であっても、『ＣＡＮＣＥＬ』や『ＢＹＥ』が大量に転送されるわけではないので、ナンバースキャニング検知装置１０は、ＤｏＳ攻撃またはＤＤｏＳ攻撃に対してリソースを消費することもない。なお、認証に成功した同一の端末（ユーザ名）から大量に送信された場合には、ナンバースキャンニング検知装置１０は統計情報を取得することになるが、閾値を超えた時点で遮断することができるので、問題とはならない。
【００６６】
また、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ（ＢＹＥ）の再送』が送信されたことが検知された場合、ナンバースキャンニング検知装置１０は、正規の手順で行われなかった回数として、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ（ＢＹＥ）の再送回数』をカウントアップする（統計情報のカウンタを１増やす）。上記したように、正規の手順で行われていないナンバースキャンニングの結果として、『６０３  Ｄｅｃｌｉｎｅ』が含まれるＳＩＰパケットが送信される可能性は極めて高いと考えられるが、『着信側端末を呼んでいたが（Ringing）、発信側端末が電話を切ることもないので、ＳＩＰサーバ側からエラー切断する』という状態は、ナンバースキャンニングでなくとも通常の状態として決して発生しないとも言い切れないものである。したがって、『６０３  Ｄｅｃｌｉｎｅ』を含むＳＩＰパケットが送信された回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
【００６７】
また、『２００  ＯＫ（ＢＹＥ）再送回数』についても同様に、正規の手順で行われていないナンバースキャンニングの結果として、『２００  ＯＫ（ＢＹＥ）』の再送が行われる可能性は極めて高いと考えられるが、ナンバースキャンニングでなくとも通常の状態として決して発生しないとも言い切れないものである。したがって、『２００  ＯＫ（ＢＹＥ）』の再送回数を統計情報として収集した上で、ナンバースキャンニングを行う端末であるか否かを判定しようとするものである。
【００６８】
なお、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）再送回数』のいずれも、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであるという点において、意味がある。すなわち、『ＣＡＮＣＥＬ』や『ＢＹＥ』のように、発信側端末から自発的に発信されるＳＩＰパケットを統計情報として収集しようとすると、結局、ＳＩＰトランザクション処理が正規の手順で行われない場合に、収集すべき情報が収集されないおそれがある。この点、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）再送回数』のように、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるパケットを統計情報として収集するのであれば、ＳＩＰトランザクション処理が正規の手順で行われない場合であっても、収集すべき情報を正確かつ確実に収集することができる。
【００６９】
ユーザ統計テーブル記憶部２２は、ナンバースキャンニング検知装置１０が取得した情報を統計情報として収集し、記憶する。具体的には、ユーザ統計テーブル記憶部２２は、後述する特定パケット統計取得部３２ａによって取得された情報を統計情報として収集して記憶し、記憶した統計情報は、後述するナンバースキャンニングユーザ検知部３２ｂによる処理に利用されるなどする。なお、ユーザ統計テーブル記憶部２２は、これらの統計情報を、特定パケット統計取得部３２ａによって取得された情報を、その都度記憶するなどする。また、ユーザ統計テーブル記憶部２２は、特定パケット統計取得部３２ａによって所定の時間情報が収集されず、特定パケット統計取得部３２ａによってリセットされた場合には、所定の時間情報が収集されなかったユーザに対応づけて記憶していた情報を消去するなどしてもよい。このようにすることで、たまたま間違い電話をしてしまったユーザの統計情報を取り続けることを避けることができる。すなわち、たまたま間違い電話をしてしまったユーザの統計情報を取り続けて放置すると、長時間運用すると全てのユーザの統計を持っていることになりかねず、ナンバースキャンニング検知装置１０のリソースを消費してしまうからである。
【００７０】
例えば、ユーザ統計テーブル記憶部２２は、図５に示すような統計情報を記憶する。図５の例について説明すると、ユーザ統計テーブル記憶部２２は、ＳＩＰトランザクションにおいて端末を識別する識別子である『ＳＩＰ−ＵＲＩ（Uniform  Resource  Identifier）』と、特定パケット統計取得部３２ａによって取得される情報（特定のパケット）とが状態情報別に対応づけられているものである。なお、図５に示す具体的な数字等も、単なる例示にすぎない。
【００７１】
実施例１において、ナンバースキャンニング検知装置１０は、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）の再送回数』を統計情報として収集し、ＳＩＰトランザクション処理が正規の手順で行われていない場合（不正の手順で行われている場合）には、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ（ＢＹＥ）の再送回数』を、正規の手順で行われなかった回数（不正の手順で行われた回数）を示す統計情報として収集するものであり、図５は、その収集結果を例示するものである。
【００７２】
閾値ルール記憶部２３は、ナンバースキャンニング検知装置１０がナンバースキャンニングを行う端末であるか否かを判定する際のルールを記憶する。具体的には、閾値ルール記憶部２３は、ユーザ統計テーブル記憶部２２に記憶されている統計情報に基づいて、どのような場合にナンバースキャンニングを行う端末であると判定するかを規定したルールを記憶し、記憶したルールは、後述するナンバースキャンニングユーザ検知部３２ｂによる処理に利用されるなどする。なお、閾値ルール記憶部２３は、これらのルールを、ナンバースキャンニング検知装置１０において検知処理を開始する前などに、運用者によって入力されることなどで記憶する。
【００７３】
例えば、閾値ルール記憶部２３は、図６に示すようなルールを記憶する。図６の例について説明すると、閾値ルール記憶部２３は、状態情報ごとに、当該状態情報が単位時間あたりに収集された回数で示される閾値を記憶している。例えば、ＳＩＰトランザクション処理が正規の手順で行われた場合について、状態情報『４０４  Ｎｏｔ  Ｆｏｕｎｄ』に関する閾値について説明すると、『１０回／分』とある。これは、ナンバースキャンニングが疑われる発信側端末として特定された発信側端末に対して、ＳＩＰサーバが、１分間に１０回以上『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を発信した場合には、当該発信側端末がナンバースキャンニングを行う端末であると判定すべきとする閾値ルールを意味するものである。
【００７４】
制御部３０は、ナンバースキャンニング検知装置１０を制御して各種処理を実行し、特に本発明に密接に関連するものとしては、図２に示すように、パケット処理部３１と、統計取得部３２と、ナンバースキャンニングユーザパケット処理部３３とを備える。
【００７５】
パケット処理部３１は、ＳＩＰパケットを検知したり、情報の取得を開始させる。パケット処理部３１は、特に本発明に密接に関連するものとしては、図２に示すように、パケット監視部３１ａと、パケット情報取得部３１ｂと、特定パケット検知部３１ｃと、統計取得起動部３１ｄとを備える。なお、パケット監視部３１ａとパケット情報取得部３１ｂと特定パケット検知部３１ｃとが、特許請求の範囲に記載の「検知手段」および「第二の検知手段」に対応する機能を備え、統計取得起動部３１ｄが、特許請求の範囲に記載の「情報取得開始手段」に対応する機能を備える。
【００７６】
ところで、実施例１において、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃは、一連の検知処理の中で２度ずつ動作するものとして説明する。すなわち、これらの部による処理は、大きく２つに分類される。第一は、ナンバースキャンニング検知装置１０が監視対象としているＳＩＰクライアント３（ナンバースキャンニング業者端末４を含む）全てについて行う処理であり、第二は、ナンバースキャンニング検知装置１０が個別の監視対象としているＳＩＰクライアント３（ナンバースキャンニングを行う端末であることが疑われる発信側端末）についてのみ行う処理である。
【００７７】
実施例１においては、まず、ＳＩＰサーバ２とＳＩＰクライアント３全てとの間で送受信されるＳＩＰパケットについて、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃが各々の処理を行い（ＳＩＰパケットに、ナンバースキャンニングが疑われる状態情報が含まれるか否かを振り分け、必要に応じてクライアント３０を個別の監視対象にするまでの第一の処理）、次に、ＳＩＰサーバ２と個別の監視対象としているＳＩＰクライアント３との間で送受信されるＳＩＰパケットについて、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃが各々の処理を行う（個別の監視対象とされているＳＩＰクライアント３について、収集すべき統計情報を収集したり、ＳＩＰトランザクション処理が正規の手順で行われたか否かの確認する第二の処理）ものであるとする。
【００７８】
パケット監視部３１ａは、ナンバースキャンニング検知装置１０が監視対象とするＳＩＰパケットを監視する。具体的には、パケット監視部３１ａは、ナンバースキャンニング検知装置１０が監視対象としているＳＩＰサーバ２とＳＩＰクライアント３（ナンバースキャンニング業者端末４を含む）との間で行われるＳＩＰトランザクション処理のＳＩＰパケットを抽出し、抽出したＳＩＰパケットは、パケット情報取得部３１ｂによる処理に利用される。
【００７９】
例えば、第一の処理の場合、実施例１におけるナンバースキャンニング検知装置１０は、図３に示したように、In-Line接続によって接続されているので、パケット監視部３１ａは、監視対象とするＳＩＰサーバ２と当該ＳＩＰサーバ２配下のＳＩＰクライアント３全てとの間で行われるＳＩＰトランザクション処理のＳＩＰパケットを、モニタリングするなどして抽出する。
【００８０】
また、例えば、第二の処理の場合、パケット監視部３１ａは、監視対象とするＳＩＰサーバ２と個別の監視対象としているＳＩＰクライアント３との間で行われるＳＩＰトランザクション処理のＳＩＰパケットのみを、モニタリングするなどして抽出する。
【００８１】
パケット情報取得部３１ｂは、監視したＳＩＰパケットから情報（ＳＩＰトランザクション処理の状態情報など）を取得する。具体的には、パケット情報取得部３１ｂは、パケット監視部３１ａによって抽出されたＳＩＰパケットについて、当該ＳＩＰパケットのヘッダ情報から、当該ＳＩＰパケットの送信先に関する情報や状態情報などを取得し、取得した情報は、特定パケット検知部３１ｃによる処理に利用される。
【００８２】
具体的に例を挙げて説明すると、ＳＩＰパケットのヘッダの中には、複数のヘッダフィールドがあり、『Ｔｏ』は、リクエストの送信先を示す情報であり、『Ｆｒｏｍ』は、リクエストの送信元を示す情報である。パケット情報取得部３１ｂは、これらの情報から、当該ＳＩＰパケットの送信先に関する情報を取得することができる。また、ＳＩＰパケットの１行目（スタートライン）には、『リクエスト・ライン』あるいは『ステータス・ライン』が記述される。『リクエスト・ライン』には、例えば、セッションの開始を要求することを要求する『INVITE』が記述されたり、端末の登録を意味する『REGISTER』が記述される。これに対して『ステータス・ライン』には、例えば、暫定応答を示す１００番台の番号や、成功応答を示す２００番台の番号、あるいは、エラーを示す４００〜６００番台の番号などが記述される。パケット情報取得部３１ｂは、これらの情報から、状態情報を取得することができる。
【００８３】
特定パケット検知部３１ｃは、監視したＳＩＰパケットから取得した情報から、当該ＳＩＰパケットが特定のＳＩＰパケットであるか否かを検知する。具体的には、特定パケット検知部３１ｃは、パケット情報取得部３１ｂによって取得された情報と、パケット検知ルール記憶部２１に記憶されているルールとに基づいて、当該情報が取得されたＳＩＰパケットが、ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットであるか否か、統計情報として収集すべきＳＩＰパケットであるか否か（同時に、ＳＩＰトランザクション処理が正規の手順で行われているか否か）を検知し、検知した結果は、統計取得起動部３１ｄによる処理や特定パケット統計取得部３２ａによる処理に利用されるなどする。
【００８４】
例えば、第一の処理の場合、特定パケット検知部３１ｃは、パケット検知ルール記憶部２１に記憶されているルールに、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』があることから、パケット情報取得部３１ｂによって取得された情報が、「『ステータス・ライン』が『４０４  Ｎｏｔ  Ｆｏｕｎｄ』である」との情報であるか否かを判定する。判定の結果、パケット情報取得部３１ｂによって取得された情報が、「『ステータス・ライン』が『４０４  Ｎｏｔ  Ｆｏｕｎｄ』である」との情報である場合には（図７を参照）、特定パケット検知部３１ｃは、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信されたことを検知したこと、および、当該ＳＩＰパケットの送信先に関する情報（発信側端末を識別するＳＩＰ−ＵＲＩなど）を、統計取得起動部３１ｄに伝達する。ここで、この『４０４  Ｎｏｔ  Ｆｏｕｎｄ』が送信される契機となった発信を行った発信側端末について、すでに統計情報の収集が開始されているのであれば、統計取得起動部３１ｄに伝達された検知は無視されることになる。
【００８５】
また、例えば、第二の処理の場合、特定パケット検知部３１ｃは、パケット検知ルール記憶部２１に記憶されているルールに、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』（図９を参照）、『ＣＡＮＣＥＬ』（図１０を参照）、『２００  ＯＫ』（図１１を参照）、『６０３  Ｄｅｃｌｉｎｅ』（図１２を参照）および『２００  ＯＫ（ＢＹＥ）再送回数』（図８を参照）があることから、パケット情報取得部３１ｂによって取得された情報が、これらの情報であるか否かを判定する。判定の結果、パケット情報取得部３１ｂによって取得された情報がこれらの情報に該当する場合には、パケット検知ルール記憶部２１は、これらの情報、および、当該ＳＩＰパケットの送信先に関する情報（発信側端末を識別するＳＩＰ−ＵＲＩなど）を、特定パケット統計取得部３２ａに伝達する。
【００８６】
ここで、第二の処理の場合、特定パケット検知部３１ｃは、パケット情報取得部３１ｂによって取得された情報が、『６０３  Ｄｅｃｌｉｎｅ』であるか否か、あるいは、『２００  ＯＫ（ＢＹＥ）』が繰り返し再送されているか否かを判定し、これらのパケットであると検知(判定)すると、ＳＩＰトランザクション処理が正規の手順で行われなかったことを検知している。したがって、これらの情報、および、当該ＳＩＰパケットの送信先に関する情報）を受信した特定パケット統計取得部３２ａでは、これらの情報を、正規の手順で行われなかった回数としてカウントすることになる。なお、再送を判定するにあたっては、特定パケット検知部３１ｃは、一時的に情報を収集することになるが、これは、特定パケット統計取得部３２ａによる統計情報の収集とは異なるものであり、一時的に判定するものにすぎない。
【００８７】
統計取得起動部３１ｄは、特定のＳＩＰパケットが送信される契機となった発信を行ったユーザ（発信側端末）に関係して行われるＳＩＰトランザクション処理について、統計の取得が開始されていない場合、そのユーザについて情報の取得を開始する。また、統計取得起動部３１ｄは、統計の取得がすでに開始されているユーザ（個別の監視対象となっている発信側端末）であって、ＳＩＰトランザクション処理が正規の手順で行われていない発信側端末に関係して行われるＳＩＰトランザクション処理について、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバ２から送信されるＳＩＰパケットに関する情報の取得を開始する。
【００８８】
具体的には、統計取得起動部３１ｄは、特定パケット検知部３１ｃから、ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットが取得されたこと、あるいは、ＳＩＰトランザクション処理が正規の手順で行われていないことを受信すると、受信した内容に応じて、後述する特定パケット統計取得部３２ａを起動したり、特定パケット統計取得部３２ａに収集させる統計情報を追加・変更するなどする。
【００８９】
統計取得部３２は、取得した情報を統計情報として収集し、収集した統計情報に基づいて、ナンバースキャンニングを行う端末であるか否かを検知する。統計取得部３２は、特に本発明に密接に関連するものとしては、図２に示すように、特定パケット統計取得部３２ａと、ナンバースキャンニングユーザ検知部３２ｂとを備える。なお、特定パケット統計取得部３２ａが、特許請求の範囲に記載の「統計情報収集手段」に対応する機能を備え、ナンバースキャンニングユーザ検知部３２ｂが、特許請求の範囲に記載の「判定手段」に対応する機能を備える。
【００９０】
特定パケット統計取得部３２ａは、取得した統計情報を収集する。具体的には、特定パケット統計取得部３２ａは、統計取得起動部３１ｄによって起動されると、指定された発信側端末について、統計情報を収集し、ユーザ統計テーブル記憶部２２に記憶させる。また、特定パケット統計取得部３２ａは、統計取得起動部３１ｄによって、統計情報の追加や変更を指定されると、指定された発信側端末について、統計情報の追加や変更を行った上で統計情報を収集し、ユーザ統計テーブル記憶部２２に記憶させる。また、特定パケット統計取得部３２ａは、特定パケット検知部３１ｃによって情報を伝達されると、これらの情報を、指定された発信側端末についてユーザ統計テーブル記憶部２２に記憶させる。
【００９１】
ナンバースキャンニングユーザ検知部３２ｂは、収集した統計情報に基づいて、ナンバースキャンニングを行う端末であるか否かを検知する。具体的には、ナンバースキャンニングユーザ検知部３２ｂは、閾値ルール記憶部２３に記憶されている閾値ルールと、ユーザ統計テーブル記憶部２２に記憶されている統計情報とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定し、判定結果は、ナンバースキャンニングユーザパケット処理部３３による処理に利用されるなどする。
【００９２】
例えば、ナンバースキャンニングユーザ検知部３２ｂは、図５の一行目に示すように、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』の回数が『１５』となっている場合に、図６の一行目に示すように、『１０回／分』の閾値ルールと比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合であるとして、ＳＩＰ−ＵＲＩが『０ｘ０−１１１１−１１１１』の発信側端末がナンバースキャンニングを行う端末であると判定する。
【００９３】
なお、実施例１においては、上記したように、閾値ルール記憶部２３が、状態情報ごとの閾値ルールを記憶しており（例えば、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』について『１０回／分』など）、ナンバースキャンニングユーザ検知部３２ｂが、所定の端末について、状態情報ごとの閾値ルールと当該状態情報に該当する統計情報（例えば、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』の回数が『１５』である、など）とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法について説明したが、本発明はこれに限られるものではない。
【００９４】
例えば、閾値ルール記憶部２３が、状態情報ごとに区別することなく複数の状態情報に対して一つの閾値ルールを記憶しており（例えば、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ再送回数』の合計について、『２０回／分』など）、ナンバースキャンニング検知部３２ｂが、所定の端末について、この閾値ルールと統計情報の合計値（例えば、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』および『２００  ＯＫ再送回数』の統計情報の合計回数が『２４』である、など）とを比較し、統計情報の合計値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法などにも、本発明を同様に適用することができる。
【００９５】
また、例えば、閾値ルール記憶部２３が、状態情報ごとに重み付けをした上で計算された一つの閾値ルールを記憶しており（例えば、ナンバースキャンニングとして顕著な状態情報である『４０４  Ｎｏｔ  Ｆｏｕｎｄ』は重み付けを重くし、『ＢＹＥ』は重み付けを軽くするなど）、ナンバースキャニング検知部３２ｂが、所定の端末について、この閾値ルールと、閾値ルールの重み付けに従って計算された統計情報の合計値とを比較し、統計情報の合計値が閾値ルールが規定する閾値以上になった場合に、ナンバースキャンニングを行う端末であると検知する手法などにも、本発明を同様に適用することができる。
【００９６】
このように、本発明において、閾値ルール記憶部２３がどのような閾値ルールを記憶し、ナンバースキャニングユーザ検知部３２ｂがどのようにナンバースキャンニングを行う端末であると検知するかに関する具体的な手法は、特定の手法に限定されるものではない。収集された統計情報に基づいて判定する手法であれば、ナンバースキャンニング検知装置１０が運用されるシステムの状況などに応じて、適宜変更されたり選択されたりするものである。
【００９７】
ナンバースキャンニングユーザパケット処理部３３は、ナンバースキャンニングを行う端末のＳＩＰパケットを遮断する。具体的には、ナンバースキャンニングユーザパケット処理部３３は、ナンバースキャンニングユーザ検知部３２ｂによって、ナンバースキャンニングを行う端末であると判定された発信側端末について、当該発信側端末から発信されたＳＩＰパケットを遮断するなどする。ナンバースキャンニングは、発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから、当該発信側端末が当該電話番号に関する情報を取得するものであるので、ナンバースキャンニングユーザパケット処理部３３によって、当該発信側端末から発信されたＳＩＰパケットが遮断されれば、発信側端末は、当該電話番号に関する情報を取得することができなくなり、ナンバースキャンニングできない結果となる。
【００９８】
なお、実施例１においては、ナンバースキャンニング検知装置１０が、ナンバースキャンニングユーザパケット処理部３３を備え、ナンバースキャンニングを行う端末として判定した端末のＳＩＰパケットについては遮断する、という対応策を行う事例について説明したが、本発明において、当該対応策を採ることが必須であるという意味ではない。例えば、ナンバースキャンニングを行う端末として判定した端末について、当面はＳＩＰパケットを遮断するなどの直接的な行為に移らず、当該端末のＳＩＰ−ＵＲＩを単にブラックリストに管理するなどの対応策を行ってもよい。
【００９９】
［実施例１に係るナンバースキャンニング検知装置による処理の流れ］
次に、図１３および１４を用いて、実施例１に係るナンバースキャンニング検知装置１０による処理の流れについて例示する。図１３は、ナンバースキャンニング検知装置における個別ユーザ監視トリガーを示すフローチャートであり、図１４は、ナンバースキャンニング検知装置における個別ユーザ監視を示すフローチャートである。
【０１００】
なお、上記したように、実施例１においては、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃは、２度ずつ動作するものとして説明する。第一の処理は、ＳＩＰサーバ２とＳＩＰクライアント３全てとの間で送受信されるＳＩＰパケットについて、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃが各々行う処理（個別ユーザ監視トリガー）、第二の処理は、ＳＩＰサーバ２と個別の監視対象としているＳＩＰクライアント３との間で送受信されるＳＩＰパケットについて、パケット監視部３１ａ、パケット情報取得部３１ｂおよび特定パケット検知部３１ｃが各々行う処理（個別ユーザ監視）である。なお、本発明はこのような処理手法に限られるものではなく、その他の処理手法によっても、本発明を同様に適用することができる。
【０１０１】
［個別ユーザ監視トリガー］
まず、パケット監視部３１ａが、監視端末に関わるパケットを抽出する（ステップＳ１０１）。具体的には、パケット監視部３１ａが、監視対象としているＳＩＰサーバ２とＳＩＰクライアント３全てとの間で行われるＳＩＰトランザクション処理のＳＩＰパケットを、モニタリングするなどして抽出する。
【０１０２】
次に、パケット情報取得部３１ｂが、ＩＰヘッダにより受信あるいは送信パケットを判断する（ステップＳ１０２）。具体的には、パケット情報取得部３１ｂが、パケット監視部３１ａによって抽出されたＳＩＰパケットについて、当該ＳＩＰパケットのヘッダ情報から、当該ＳＩＰパケットの送信先に関する情報などを取得する。
【０１０３】
続いて、パケット情報取得部３１ｂは、パケットのＳＩＰヘッダ部分を取り出す（ステップＳ１０３）。具体的には、パケット情報取得部３１ｂは、パケット監視部３１ａによって抽出されたＳＩＰパケットについて、当該ＳＩＰパケットのヘッダ情報から、状態情報などを取得する。
【０１０４】
そして、特定パケット検知部３１ｃが、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』パケットであるか否かを判定する（ステップＳ１０４）。具体的には、特定パケット検知部３１ｃは、パケット検知ルール記憶部２１に記憶されているルールに、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』があることから、パケット情報取得部３１ｂによって取得された情報が、「『ステータス・ライン』が『４０４  Ｎｏｔ  Ｆｏｕｎｄ』である」との情報であるか否かを判定する。判定の結果、「『ステータス・ライン』が『４０４  Ｎｏｔ  Ｆｏｕｎｄ』である」との情報でない場合には（ステップＳ１０４否定）、ナンバースキャンニング検知装置１０は、処理を終了する。
【０１０５】
一方、「『ステータス・ライン』が『４０４  Ｎｏｔ  Ｆｏｕｎｄ』である」との情報である場合には（ステップＳ１０４肯定）、特定パケット検知部３１ｃは、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』を含むＳＩＰパケットが送信されたことを検知したこと、および、当該ＳＩＰパケットの送信先に関する情報を、統計取得起動部３１ｄに伝達する。
【０１０６】
すると、統計取得起動部３１ｄは、個別監視対象のユーザへのパケットであるか否かを判定する（ステップＳ１０５）。具体的には、統計取得起動部３１ｄは、特定パケット検知部３１ｃから、ナンバースキャンニングが疑われる状態情報（『４０４  Ｎｏｔ  Ｆｏｕｎｄ』）を含むＳＩＰパケットが取得されたことを受信すると、当該ＳＩＰパケットが、すでに特定パケット統計取得部３２ａによって統計情報の取得が開始されている個別監視対象のユーザへのパケットであるか否かを判定する。判定の結果、このようなユーザである場合には（ステップＳ１０５肯定）、ナンバースキャンニング検知装置１０は、このまま処理を終了する。
【０１０７】
一方、このようなユーザでない場合には（ステップＳ１０５否定）、すなわち、特定パケット統計取得部３２ａによって統計情報の取得が開始されていないユーザである場合には、統計取得起動部３１ｄは、監視対象のユーザとして加え、そのユーザの監視を始める（ステップＳ１０６）。具体的には、特定パケット統計取得部３２ａを起動し、パケット監視部３１ａによる個別監視の対象ユーザに加える。
【０１０８】
［個別ユーザ監視］
続いて、個別ユーザ監視のフローチャートについて説明すると、パケット監視部３１ａが、監視端末に関わるパケットを再び抽出する（ステップＳ２０１）。具体的には、パケット監視部３１ａが、監視対象としているＳＩＰサーバ２と個別の監視対象としているＳＩＰクライアント３との間で行われるＳＩＰトランザクション処理のＳＩＰパケットを、モニタリングするなどして抽出する。
【０１０９】
次に、パケット情報取得部３１ｂが、ＩＰヘッダにより受信あるいは送信パケットを判断する（ステップＳ２０２）。具体的には、パケット情報取得部３１ｂが、パケット監視部３１ａによって抽出されたＳＩＰパケットについて、当該ＳＩＰパケットのヘッダ情報から、当該ＳＩＰパケットの送信先に関する情報などを取得する。
【０１１０】
続いて、パケット情報取得部３１ｂは、パケットのＳＩＰヘッダ部分を取り出す（ステップＳ２０３）。具体的には、パケット情報取得部３１ｂは、パケット監視部３１ａによって抽出されたＳＩＰパケットについて、当該ＳＩＰパケットのヘッダ情報から、状態情報などを取得する。
【０１１１】
そして、特定パケット検知部３１ｃは、統計情報として収集する特定のＳＩＰパケットであるか否かを判定する（ステップＳ２０４）。具体的には、特定パケット検知部３１ｃは、パケット情報取得部３１ｂによって取得された情報が、パケット検知ルール記憶部２１に記憶されているルールで指定されている情報（『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』、あるいは『２００  ＯＫ（ＢＹＥ）の再送』）であるか否かを判定する。パケット検知ルール記憶部２１に記憶されているルールで指定されている情報でない場合（ステップＳ２０４否定）、ナンバースキャンニング検知装置１０は、処理を終了する。
【０１１２】
一方、パケット検知ルール記憶部２１に記憶されているルールで指定されている情報（『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』、あるいは『２００  ＯＫ（ＢＹＥ）の再送』）である場合（ステップＳ２０４肯定）、特定パケット検知部３１ｃは、これらの情報、および、当該ＳＩＰパケットの送信先に関する情報を、特定パケット統計取得部３２ａに伝達する。なお、実施例１における特定パケット検知部３１ｃは、ここで、同時に、特定のパケットが、『６０３  Ｄｅｃｌｉｎｅ』もしくは『２００  ＯＫ（ＢＹＥ）の再送』であるか否かについても検知している。これらの情報である場合には、ナンバースキャンニング検知装置１０は、発信側端末がＳＩＰトランザクション処理を行っていないと検知（判定）するので、特定パケット統計取得部３２ａに、これらの情報を正規の手順で行われなかった回数として収集させる（カウントアップさせる）ことになる。
【０１１３】
そして、特定パケット統計取得部３２ａは、統計情報を収集する（ステップＳ２０５）。具体的には、特定パケット統計取得部３２ａは、指定された発信側端末について、統計情報（『４０４  Ｎｏｔ  Ｆｏｕｎｄ』、『ＣＡＮＣＥＬ』、『ＢＹＥ』、『６０３  Ｄｅｃｌｉｎｅ』、あるいは『２００  ＯＫ（ＢＹＥ）の再送』）を収集し、ユーザ統計テーブル記憶部２２に記憶させる。なお、特定のパケットが『６０３  Ｄｅｃｌｉｎｅ』もしくは『２００  ＯＫ（ＢＹＥ）の再送』である場合には、特定パケット統計取得部３２ａは、これらの情報を、正規の手順で行われなかった回数として収集する。
【０１１４】
続いて、ナンバースキャンニングユーザ検知部３２ｂが、閾値を超過したか否かを判定する（ステップＳ２０６）。具体的には、ナンバースキャンニングユーザ検知部３２ｂは、閾値ルール記憶部２３に記憶されている閾値ルールと、ユーザ統計テーブル記憶部２２に記憶されている統計情報とを比較し、統計情報の値が閾値ルールが規定する閾値以上になった場合に（ステップＳ２０６肯定）、発信側端末がナンバースキャンニングを行う端末であると判定し、ナンバースキャンニングを検出し（ステップＳ２０７）、ナンバースキャンニングユーザパケット処理部３３に当該検出結果を伝達するなどする。
【０１１５】
一方、ステップＳ２０６において、閾値を超過していない場合には（ステップＳ２０６否定）、監視期間を延長するなどして（ステップＳ２０８）、処理を終了する。
【０１１６】
なお、本発明はこのような処理の手順に限られるものではなく、その他の処理の手順によっても、同様に適用することができる。例えば、まず、全てのＳＩＰパケットについて、個別の監視対象としているＳＩＰクライアント３のＳＩＰパケットであるか否かの振り分けを行い、次に、個別の監視対象となっていないＳＩＰクライアント３のＳＩＰパケットについては、ナンバースキャンニングが疑われる状態情報が含まれるかという振り分けや、ＳＩＰトランザクション処理が正規の手順で行われているか否かの振り分けを行い、個別の監視対象となっているＳＩＰクライアント３のＳＩＰパケットについては、収集すべき統計情報を収集するなど、処理の手順は、運用形態などに併せて適宜変更できるものである。
【０１１７】
［実施例１の効果］
上記してきたように、実施例１によれば、発信側端末が所定の電話番号に発信したことを契機として行われるＳＩＰトランザクション処理のＳＩＰパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、ナンバースキャンニングが疑われる情報であってＳＩＰトランザクション処理が所定の状態にあることを示す状態情報を含むＳＩＰパケットが送信されたことを検知し、状態情報を含むＳＩＰパケットが送信されたことが検知されたことを条件として、ＳＩＰパケットが送信される契機となった発信を行った発信側端末を特定し、特定した当該発信側端末に関係して行われるＳＩＰトランザクション処理について情報の取得を開始し、情報の取得が開始されると、取得した情報を統計情報として収集し、収集された統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定するので、ナンバースキャンニングを検知する際の負荷を低減することが可能になる。
【０１１８】
すなわち、本発明によれば、ナンバースキャンニング検知装置は、常に全ての端末について統計情報を収集し、管理し続けなければならない従来の手法とは異なり、ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットが送信されたことを検知したことをトリガーとして、ナンバースキャンニングを行う端末であると疑われる発信側端末についてのみ統計情報を収集するものであることから、従来の手法に比較して、全てのユーザの統計を取得する必要がなく、リソース消費も少なく、負荷を低減することが可能になる。
【０１１９】
また、実施例１によれば、状態情報を含むＳＩＰパケットとして、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２０】
すなわち、従来の手法は、発信側端末から送信されたＳＩＰパケット（発信呼）をトリガーとして統計情報を収集する手法であることから、この点を衝いたＤｏＳ攻撃またはＤＤｏＳ攻撃（例えば、『ＩＮＶＩＴＥ』の大量送信）を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれがあった。これに対して、本発明によれば、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットをトリガーとして統計情報を収集することになるので（なお、ＳＩＰサーバは、認証されたユーザ（発信側端末）のＳＩＰパケットにしか返答しない）、ＤｏＳ攻撃またはＤＤｏＳ攻撃の影響を受けることもなく、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２１】
また、実施例１によれば、状態情報を含むＳＩＰパケットとして、４０４  Ｎｏｔ  Ｆｏｕｎｄメッセージを含むＳＩＰパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２２】
また、実施例１によれば、統計情報として、ＳＩＰサーバから送信されるＳＩＰパケットに関する情報のみを収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２３】
すなわち、従来の手法は、発信側端末から送信されたＳＩＰパケットを統計情報として収集する手法であることから、この点を衝いたＤｏＳ攻撃またはＤＤｏＳ攻撃を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれがあった。これに対して、本発明によれば、ＳＩＰサーバから送信されるＳＩＰパケットのみを統計情報として収集することになるので、ＤｏＳ攻撃またはＤＤｏＳ攻撃の影響を受けることもなく、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２４】
また、実施例１によれば、情報の取得が開始された発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知し、統計情報として、検知された発信側端末がＳＩＰトランザクション処理を正規の手順で行わなかった回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２５】
すなわち、従来の手法のように、発信側途中放棄呼に関する統計情報を収集する手法では、不正なトランザクション手順によって発信側途中放棄呼が送信されない場合には、ナンバースキャンニングを正確かつ確実に検知することができない。これに対して、本発明によれば、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットに関する情報（例えば、『６０３  Ｄｅｃｌｉｎｅ』など）を統計情報として収集するので、発信側途中放棄呼が送信されない場合にも、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２６】
また、実施例１によれば、情報の取得が開始された発信側端末に対して２００  ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送されたこと、あるいは、発信側端末に対してＳＩＰサーバから６０３  Ｄｅｃｌｉｎｅが送信されたことから、当該発信側端末によるＳＩＰトランザクション処理が正規の手順で行われていないことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２７】
また、実施例１によれば、ＳＩＰトランザクション処理を正規の手順で行わなかった回数として、発信側端末に対して２００  ＯＫメッセージおよび／またはＢＹＥメッセージがＳＩＰサーバから繰り返し再送された回数、および／または、発信側端末に対してＳＩＰサーバから６０３  Ｄｅｃｌｉｎｅが送信された回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
【０１２８】
また、実施例１によれば、予め記憶部に記憶している所定の閾値と、収集された統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定するので、上記の効果に加え、ナンバースキャンニングを適切に判定することが可能になる。
【０１２９】
また、実施例１によれば、所定の発信側端末に関係して行われるＳＩＰトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットするので、上記の効果に加え、ナンバースキャンニング検知装置を効率的に運用することが可能になる。
【実施例２】
【０１３０】
［他の実施例］
さて、これまで本発明の実施例について説明してきたが、本発明は上記の実施例以外にも、種々の異なる形態にて実施されてよいものである。
【０１３１】
［システム構成等］
実施例１においては、ナンバースキャンニング装置が、ＳＩＰサーバおよびＳＩＰクライアントの各々がＩＰ電話網／インターネットに接続されている中間に、In-Line接続によって接続される接続形態について説明してきたが（図３を参照）、本発明の接続形態はこれに限られるものではない。例えば、図１５に示すように、ナンバースキャンニング装置が、ＳＩＰサーバおよびＳＩＰクライアントの各々がＩＰ電話網／インターネットに接続されている中間に、Out-of-Line接続によって接続される接続形態においても、本発明を同様に適用することができる。このOut-of-Line接続によれば、In-Line接続同様、ナンバースキャンニング検知装置は、In-Line接続と同様に、既存のシステムに付加的に挿入されることが可能であり、また、In-Line接続と同様に、ナンバースキャンニングを行う端末を検知すると、当該端末からのＳＩＰパケットを破棄する処理をナンバースキャンニング検知装置に持たせることも可能である。また、例えば、図１６に示すように、ＳＩＰサーバにナンバースキャンニング検知プログラムを組み込む接続形態においても、本発明を同様に適用することができる。この接続形態によれば、ナンバースキャンニング検知プログラムは、ＳＩＰサーバと同じ装置の中で別のプロセスとして動作し、ネットワークインタフェースからＳＩＰパケットに関する情報を取得することが可能であり、また、ナンバースキャンニングを行う端末を検知すると、実行中の対象となるプロセスに、当該端末からのＳＩＰパケットを破棄する処理を即座に通知することが可能になる。
【０１３２】
また、実施例１においては、ナンバースキャンニング検知装置が検知するＳＩＰパケット（ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケット）として、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケット（例えば、『４０４  Ｎｏｔ  Ｆｏｕｎｄ』）を検知する手法を例示したが、本発明はこれに限られるものではない。ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットを検知し、これをトリガーとして統計情報の収集を開始する手法であれば、その他のＳＩＰパケットを検知する手法にも、本発明を同様に適用することができる。
【０１３３】
また、実施例１においては、統計情報として収集する情報は、ＳＩＰサーバから送信されるＳＩＰパケットである手法を例示したが（図９、１０、１１、１２など）、本発明はこれに限られるものではない。ナンバースキャンニングが疑われる状態情報を含むＳＩＰパケットの検知をトリガーとして統計情報の収集を開始する手法であれば、その後統計情報として収集する情報が、ＳＩＰサーバから送信されるＳＩＰパケットでない手法にも、本発明を同様に適用することができる。例えば、ナンバースキャンニング検知装置が、統計情報として、発信側端末からＳＩＰサーバに向けて送信された『ＣＡＮＣＥＬ』や『ＢＹＥ』を収集する手法などにも、本発明を同様に適用することができる。
【０１３４】
また、実施例１においては、ＳＩＰトランザクション処理が正規の手順で行われていないことを、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ』の再送回数で検知すると、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットに関する情報（例えば、『６０３  Ｄｅｃｌｉｎｅ』、『２００  ＯＫ』再送回数など）を、正規の手順で行われていない回数を示す統計情報として収集する手法を例示したが、本発明はこれに限られるものではない。例えば、ナンバースキャンニング検知装置が、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ』の再送回数によってＳＩＰトランザクション処理が正規の手順で行われていないことを検知するか否かに係らず、とりあえず、ナンバースキャンニング検知装置が、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ』の再送回数を単なる統計情報の一項目（あるいは、ＳＩＰトランザクション処理が正規の手順で行われていないと疑われる状態情報の項目）として収集しておき、後に（オフラインなどで）、『６０３  Ｄｅｃｌｉｎｅ』や『２００  ＯＫ』の再送回数の統計情報から、ＳＩＰトランザクション処理が正規の手順で行われていなかったのだと解析する場合にも、本発明を同様に適用することができる。
【０１３５】
また、ＳＩＰトランザクション処理が正規の手順で行われていないことの検知が、『２００  ＯＫ』の再送回数でなく、『ＢＹＥ』の再送回数や、その他の手法によって行われる場合にも、本発明を同様に適用することができる。さらに、ＳＩＰトランザクション処理が正規の手順で行われていないことを検知した場合に、統計情報として収集する情報が、発信側端末から自発的に発信されるＳＩＰパケット以外のＳＩＰパケットであってＳＩＰサーバから送信されるＳＩＰパケットに関する情報でない場合にも、本発明を同様に適用することができる。
【０１３６】
また、実施例１においては、ナンバースキャンニング検知装置が、統計情報の値が閾値以上になったか否かによって、発信側端末がナンバースキャンニングを行う端末であるか否かを判定する手法を例示したが、本発明はこれに限られるものではない。収集した統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定する手法であれば、本発明を同様に適用することができる。
【０１３７】
また、実施例１においては、本発明を、ＳＩＰを用いたＩＰ電話サービスにおけるナンバースキャンニングに適用した場合について説明したが、本発明はこれに限られるものではない。例えば、ＳＩＰ以外の他のプロトコル（Ｈ．３２３など）を用いたＩＰ電話におけるナンバースキャンニングや、ＩＰ電話におけるナンバースキャンニングに限られず、公衆交換電話サービスにおけるナンバースキャンニングや、携帯電話サービスにおけるナンバースキャンニングなどにも、本発明を同様に適用することができる。すなわち、いずれのシステムにおいても、ネットワーク上で送受信される情報には、通信が所定の状態にあることを示す状態情報を含むはずである。また、いずれのシステムにおいても、このような状態情報の内、ナンバースキャンニングが疑われる状態情報（例えば、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報）を含む情報が、ネットワーク上で送受信されるはずである。したがって、いずれのシステムにおいても、このような状態情報を含む情報を検知したことをトリガーに、統計情報の収集を開始し、発信側端末がナンバースキャンニングを行う端末であるか否かを判定することは可能であり、この意味で、本発明を同様に適用することが可能である。
【０１３８】
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順（例えば、図１３および１４など）、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１３９】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示（例えば、図２など）の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１４０】
なお、本実施例で説明したナンバースキャンニング検知方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
【産業上の利用可能性】
【０１４１】
以上のように、本発明に係るナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムは、ナンバースキャンニングが行われる状況において、発信側端末を検知することに有用であり、特に、ナンバースキャンニングを検知する際の負荷を低減することに適する。
【図面の簡単な説明】
【０１４２】
【図１】実施例１に係るナンバースキャンニング検知装置の概要および特徴を説明するための図である。
【図２】ナンバースキャンニング検知装置の構成を示すブロック図である。
【図３】ナンバースキャンニング検知装置の接続を示すネットワーク図である。
【図４】パケット検知ルール記憶部を説明するための図である。
【図５】ユーザ統計テーブル記憶部を説明するための図である。
【図６】閾値ルール記憶部を説明するための図である。
【図７】情報取得の開始について説明するための図である。
【図８】情報取得の開始について説明するための図である。
【図９】統計情報の収集について説明するための図である。
【図１０】統計情報の収集について説明するための図である。
【図１１】統計情報の収集について説明するための図である。
【図１２】統計情報の収集について説明するための図である。
【図１３】ナンバースキャンニング検知装置における個別ユーザ監視トリガーを示すフローチャートである。
【図１４】ナンバースキャンニング検知装置における個別ユーザ監視を示すフローチャートである。
【図１５】ナンバースキャンニング検知装置の他の接続を示すネットワーク図である。
【図１６】ナンバースキャンニング検知装置の他の接続を示すネットワーク図である。
【図１７】ナンバースキャンニングを説明するための図である。
【図１８】従来技術を説明するための図である。
【図１９】従来技術を説明するための図である。
【符号の説明】
【０１４３】
１  ＩＰ電話網／インターネット
２  ＳＩＰサーバ
３  ＳＩＰクライアント
４  ナンバースキャンニング業者端末
１０  ナンバースキャンニング検知装置
１１  通信制御部
２０  記憶部
２１  パケット検知ルール記憶部
２２  ユーザ統計テーブル記憶部
２３  閾値ルール記憶部
３０  制御部
３１  パケット処理部
３１ａ  パケット監視部
３１ｂ  パケット情報取得部
３１ｃ  特定パケット検知部
３１ｄ  統計取得起動部
３２  統計取得部
３２ａ  特定パケット統計取得部
３２ｂ  ナンバースキャンニングユーザ検知部
３３  ナンバースキャンニングユーザパケット処理部
【図１】
0004800272.tif 000002
【図２】
0004800272.tif 000003
【図３】
0004800272.tif 000004
【図４】
0004800272.tif 000005
【図５】
0004800272.tif 000006
【図６】
0004800272.tif 000007
【図７】
0004800272.tif 000008
【図８】
0004800272.tif 000009
【図９】
0004800272.tif 000010
【図１０】
0004800272.tif 000011
【図１１】
0004800272.tif 000012
【図１２】
0004800272.tif 000013
【図１３】
0004800272.tif 000014
【図１４】
0004800272.tif 000015
【図１５】
0004800272.tif 000016
【図１６】
0004800272.tif 000017
【図１７】
0004800272.tif 000018
【図１８】
0004800272.tif 000019
【図１９】
0004800272.tif 000020