JP4800272B2 - ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム - Google Patents

ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム Download PDF

Info

Publication number
JP4800272B2
JP4800272B2 JP2007212293A JP2007212293A JP4800272B2 JP 4800272 B2 JP4800272 B2 JP 4800272B2 JP 2007212293 A JP2007212293 A JP 2007212293A JP 2007212293 A JP2007212293 A JP 2007212293A JP 4800272 B2 JP4800272 B2 JP 4800272B2
Authority
JP
Japan
Prior art keywords
sip
information
terminal
packet
number scanning
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007212293A
Other languages
English (en)
Other versions
JP2009049601A (ja
Inventor
哲也 楠本
エリック・チェン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2007212293A priority Critical patent/JP4800272B2/ja
Publication of JP2009049601A publication Critical patent/JP2009049601A/ja
Application granted granted Critical
Publication of JP4800272B2 publication Critical patent/JP4800272B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

この発明は、ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムに関する。
近年、SIP(Session Initiation Protocol)を用いたIP(Internet Protocol)電話サービスが普及しているが、IP電話は低コストで発信できることから、この点を悪用した「ナンバースキャンニング」と呼ばれる脅威が登場している。「ナンバースキャンニング」とは、ナンバースキャンニングを企てる業者(以下、ナンバースキャンニング業者)が、存在するか否かが不明な電話番号にランダムに発信し、その応答によって、発信した電話番号が存在するか否かを判定し、存在すると判定した電話番号を取得するものである。
以下に、「ナンバースキャンニング」について、具体的に例を挙げて説明する。図17の(A)は、ナンバースキャンニング業者が発信した電話番号が、存在する電話番号であった場合の例であり、図17の(B)は、存在しない電話番号であった場合の例である。図17の(A)に示すように、ナンバースキャンニング業者が、電話番号『111』を入力することで電話番号『111』に発信すると、SIPのメッセージ『INVITE 111』が、IP電話のSIPサーバに送信される(図17の(A)の(1)を参照)。SIPサーバは、電話番号『111』が存在する電話番号であるので、この『INVITE 111』を、電話番号『111』の電話機に転送する(図17の(A)の(2)を参照)。『INVITE 111』が転送されると、電話番号『111』の電話機は、SIPのメッセージ『Ringing』(電話番号『111』の電話機において着信音が鳴っていることを示す)を、SIPサーバに送信する(図17の(A)の(3)を参照)。すると、SIPサーバは、この『Ringing』を、ナンバースキャンニング業者に転送する(図17の(A)の(4)を参照)。この応答によって、ナンバースキャンニング業者は、電話番号『111』が存在することを判定し(図17の(A)の(5)を参照)、その後、電話を切る。
一方、図17の(B)に示すように、ナンバースキャンニング業者が、電話番号『888』を入力することで電話番号『888』に発信すると、SIPのメッセージ『INVITE 888』が、IP電話のSIPサーバに送信される(図17の(B)の(1)を参照)。SIPサーバは、電話番号『888』が存在しない電話番号であるので、存在しない電話番号であることを示す『404 NotFound』を、ナンバースキャンニング業者に送信する(図17の(B)の(2)を参照)。この応答によって、ナンバースキャンニング業者は、電話番号『888』が存在しないことを判定し(図17の(B)の(3)を参照)、その後、電話を切る。
なお、「ナンバースキャンニング」は、『Ringing』による応答ではなく、相手が出たこと(『200 OK』)による応答によって判定したり、電話番号を入力することで発信するのではなく、電話番号に発信するプログラムを利用することで発信することもある。後者の場合、「ナンバースキャンニング」は、正規のSIPトランザクション手順に従わずに電話を切ることができてしまう。
このような「ナンバースキャンニング」によってナンバースキャンニング業者に取得された電話番号は、例えば、ワン切り(相手の電話機に着信履歴を残すことによって相手に電話をかけ直させ、有害サイトへの勧誘などを行うこと)や、自動応答広告配信(発信した電話番号の相手が電話に出ると、自動音声の広告や有害サイトへの勧誘などを行うこと)に悪用される。このため、「ナンバースキャンニング」に対する対応策が急務となるが、ナンバースキャンニングを行う電話の電話番号(発信者番号)を予め特定することは難しく、着信拒否の方法を採ることはできない。なお、ナンバースキャンニングと同様の発信の特徴を持つ「ワン切り」に対する対応策として、例えば、特許文献1〜3に示すような対応策がある。
特許文献1には、特定のパケット(INVITEメッセージ、BYE/CANCELメッセージ)を規定時間内に受信した回数で、「ワン切り」を行う端末(ユーザ)を判定する対応策が開示されている。図18および19を用いて具体的に説明すると、ワン切り業者が電話番号『111』に発信すると、図17で説明した事例と同様、『INVITE 111』がSIPサーバに送信され(図18の(1)を参照)、『INVITE 111』が電話番号『111』の電話機に転送され(図18の(2)を参照)、『Ringing』がSIPサーバに送信され(図18の(3)を参照)、『Ringing』がワン切り業者に転送され(図18の(4)を参照)、ワン切り業者が、電話番号『111』が存在することを判定する(図18の(5)を参照)。その後、ワン切り業者は、SIPのメッセージ『CANCEL』(もしくは『BYE』。『CANCEL』は、着信音が鳴ったときに電話を切るメッセージ、『BYE』は、相手が電話に出てから電話を切るメッセージ)を、SIPサーバに送信することで電話を切り(図18の(6)を参照)、SIPサーバは、この『CANCEL』を、電話番号『111』の電話機に転送する(図18の(7)を参照)ことになる。ここで、特許文献1の対応策は、図19に示すように、(1)の『INVITE 111』を転送してから(7)の『CANCEL』(または『BYE』)を転送するまでの時間が規定時間内であった場合に、発信側端末について統計情報を収集し、「ワン切り」を行う端末を判定するなどする。
また、特許文献2には、発信側途中放棄呼(CANCELメッセージ)を受信した回数で、「ワン切り」を行う端末を判定する対応策が開示されている。具体的に説明すると、特許文献2の対応策は、発信側端末からSIPのメッセージ『INVITE』が送信され、その後、発信側端末から『CANCEL』が送信された場合に、発信側端末が断呼したと判断して発信側途中放棄呼数の統計情報を収集し、「ワン切り」を行う端末を判定するなどする。また、特許文献3には、単位時間あたりの発呼(INVITEメッセージ、REGISTERメッセージ)の回数や呼切断(BYEメッセージ)の回数で、「ワン切り」を行う端末を判定する対応策が開示されている。具体的に説明すると、特許文献3の対応策は、SIPサーバにおける『INVITE』や『REGISTER』各々の単位時間あたりの総数が閾値を上回った場合や、発信側端末が断呼した回数が閾値を上回った場合などに、「ワン切り」を行う端末を判定するなどする。
特開2005−20524号公報 特開2006−129294号公報 特開2007−60379号公報
ところで、上記した従来の技術では、以下に説明するように、ナンバースキャンニングを検知する際の負荷が高いという課題がある。すなわち、ナンバースキャンニングと同様の発信の特徴を持つ「ワン切り」に対する対応策を、ナンバースキャンニングに対する対応策に代用することを考え、これを検討してみると、特許文献1〜3に開示されている対応策のいずれも、発信呼(『INVITE』、『REGISTER』)や発信側途中放棄呼(『CANCEL』、『BYE』)に関する統計情報を収集する手法であることから、常に全ての端末について統計情報を収集し、管理し続けなければならず、ナンバースキャンニングを検知する際の負荷が高い。
また、上記した従来の技術では、以下に説明するように、ナンバースキャンニングを正確かつ確実に検知することができないという課題がある。すなわち、ナンバースキャンニングがプログラムによって行われ、不正なトランザクション手順によって発信側途中放棄呼が送信されない場合には、特許文献1〜3に開示されている対応策の内、発信側途中放棄呼に関する統計情報を収集する手法では、ナンバースキャンニングを正確かつ確実に検知することができない。また、特許文献1〜3に開示されている対応策のいずれも、発信側端末から送信されたSIPパケット(発信呼)をトリガーとして統計情報を収集する手法であることから、この点を衝いたDoS(Denial of Service)攻撃またはDDoS(Distributed DoS)攻撃を受けると、ナンバースキャンニングを検知する際に検知装置のリソースが利用され続け、検知装置がダウンしてしまうおそれもあることから、ナンバースキャンニングを正確かつ確実に検知することができない。
なお、上記した課題は、SIPを用いたIP電話サービスにおけるナンバースキャンニングに限られず、SIP以外の他のプロトコル(H.323など)を用いたIP電話におけるナンバースキャンニングにおいても同様に課題となる。また、上記した課題は、IP電話におけるナンバースキャンニングに限られず、公衆交換電話サービスにおけるナンバースキャンニングや、携帯電話サービスにおけるナンバースキャンニングなどにおいても、同様に課題となる。
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、ナンバースキャンニングを検知する際の負荷を低減することが可能なナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムを提供することを第一の目的とする。
また、この発明は、ナンバースキャンニングを正確かつ確実に検知することが可能なナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムを提供することを第二の目的とする。
上述した課題を解決し、目的を達成するため、発明は、発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、前記ナンバースキャンニングが疑われる情報であって前記SIPトランザクション処理が所定の状態にあることを示す状態情報を含むSIPパケットが送信されたことを検知する第一の検知手段と、前記第一の検知手段によって前記状態情報を含むSIPパケットが送信されたことが検知されたことを条件として、当該SIPパケットが送信される契機となった発信を行った発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始する情報取得開始手段と、前記情報取得開始手段によって情報の取得が開始されると、取得した情報を統計情報として収集する統計情報収集手段と、前記統計情報収集手段によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手段と、を備えたことを特徴とする。
また、発明は、上記の発明において、前記第一の検知手段は、前記状態情報を含むSIPパケットとして、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットが送信されたことを検知することを特徴とする。
また、発明は、上記の発明において、前記状態情報を含むSIPパケットとして、404 Not Foundメッセージを含むSIPパケットが送信されたことを検知することを特徴とする。
また、発明は、上記の発明において、前記統計情報収集手段は、前記統計情報として、SIPサーバから送信されるSIPパケットに関する情報のみを収集することを特徴とする。
また、発明は、上記の発明において、前前記統計情報収集手段は、前記統計情報として、404 Not Foundメッセージ、CANCELメッセージ、BYEメッセージのいずれか一つまたは複数を収集することを特徴とする。
また、発明は、上記の発明において、前記情報取得開始手段によって情報の取得が開始された前記発信側端末による前記SIPトランザクション処理が正規の手順で行われていないことを検知する第二の検知手段をさらに備え、前記統計情報収集手段は、前記統計情報として、前記発信側端末が前記SIPトランザクション処理を正規の手順で行わなかった回数を収集することを特徴とする。
また、発明は、上記の発明において、前記第二の検知手段は、前記情報取得開始手段によって情報の取得が開始された前記発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送されたこと、あるいは、前記発信側端末に対してSIPサーバから603 Declineが送信されたことから、当該発信側端末による前記SIPトランザクション処理が正規の手順で行われていないことを検知することを特徴とする。
また、発明は、上記の発明において、前記統計情報収集手段は、前記SIPトランザクション処理を正規の手順で行わなかった回数として、前記発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送された回数、および/または、前記発信側端末に対してSIPサーバから603 Declineが送信された回数を収集することを特徴とする。
また、発明は、上記の発明において、前記判定手段は、予め記憶部に記憶している所定の閾値と、前記統計情報収集手段によって収集された前記統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、前記発信側端末が前記ナンバースキャンニングを行う端末であると判定することを特徴とする。
また、発明は、上記の発明において、前記統計情報収集手段は、所定の発信側端末に関係して行われるSIPトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットすることを特徴とする。
また、発明は、上記の発明において、発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知方法をコンピュータに実行させるナンバースキャンニング検知プログラムであって、前記ナンバースキャンニングが疑われる情報であって前記SIPトランザクション処理が所定の状態にあることを示す状態情報を含むSIPパケットが送信されたことを検知する第一の検知手順と、前記第一の検知手順によって前記状態情報を含むSIPパケットが送信されたことが検知されたことを条件として、当該SIPパケットが送信される契機となった発信を行った発信側端末を特定し、特定した当該発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始する情報取得開始手順と、前記情報取得開始手順によって情報の取得が開始されると、取得した情報を統計情報として収集する統計情報収集手順と、前記統計情報収集手順によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手順と、をコンピュータに実行させることを特徴とする。
発明によれば、発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、ナンバースキャンニングが疑われる情報であってSIPトランザクション処理が所定の状態にあることを示す状態情報を含むSIPパケットが送信されたことを検知し、状態情報を含むSIPパケットが送信されたことが検知されたことを条件として、SIPパケットが送信される契機となった発信を行った発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始し、情報の取得が開始されると、取得した情報を統計情報として収集し、収集された統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定するので、ナンバースキャンニングを検知する際の負荷を低減することが可能になる。
また、発明によれば、状態情報を含むSIPパケットとして、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、状態情報を含むSIPパケットとして、404 Not Foundメッセージを含むSIPパケットが送信されたことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、統計情報として、SIPサーバから送信されるSIPパケットに関する情報のみを収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、統計情報として、404 Not Foundメッセージ、CANCELメッセージ、BYEメッセージのいずれか一つまたは複数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、情報の取得が開始された発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知し、統計情報として、発信側端末がSIPトランザクション処理を正規の手順で行わなかった回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、情報の取得が開始された発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送されたこと、あるいは、発信側端末に対してSIPサーバから603 Declineが送信されたことから、当該発信側端末によるSIPトランザクション処理が正規の手順で行われていないことを検知するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、SIPトランザクション処理を正規の手順で行わなかった回数として、発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送された回数、および/または、発信側端末に対してSIPサーバから603 Declineが送信された回数を収集するので、ナンバースキャンニングを正確かつ確実に検知することが可能になる。
また、発明によれば、予め記憶部に記憶している所定の閾値と、収集された統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、発信側端末がナンバースキャンニングを行う端末であると判定するので、上記の効果に加え、ナンバースキャンニングを適切に判定することが可能になる。
また、発明によれば、所定の発信側端末に関係して行われるSIPトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットするので、上記の効果に加え、ナンバースキャンニング検知装置を効率的に運用することが可能になる。
以下に添付図面を参照して、本発明に係るナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムの実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例1に係るナンバースキャンニング検知装置の概要および特徴、実施例1に係るナンバースキャンニング検知装置の構成および処理の流れ、実施例1の効果を順に説明し、次に、他の実施例を説明する。
[用語の説明]
まず最初に、以下の実施例で用いる主要な用語を説明する。「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トランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットするので、上記の効果に加え、ナンバースキャンニング検知装置を効率的に運用することが可能になる。
[他の実施例]
さて、これまで本発明の実施例について説明してきたが、本発明は上記の実施例以外にも、種々の異なる形態にて実施されてよいものである。
[システム構成等]
実施例1においては、ナンバースキャンニング装置が、SIPサーバおよびSIPクライアントの各々がIP電話網/インターネットに接続されている中間に、In-Line接続によって接続される接続形態について説明してきたが(図3を参照)、本発明の接続形態はこれに限られるものではない。例えば、図15に示すように、ナンバースキャンニング装置が、SIPサーバおよびSIPクライアントの各々がIP電話網/インターネットに接続されている中間に、Out-of-Line接続によって接続される接続形態においても、本発明を同様に適用することができる。このOut-of-Line接続によれば、In-Line接続同様、ナンバースキャンニング検知装置は、In-Line接続と同様に、既存のシステムに付加的に挿入されることが可能であり、また、In-Line接続と同様に、ナンバースキャンニングを行う端末を検知すると、当該端末からのSIPパケットを破棄する処理をナンバースキャンニング検知装置に持たせることも可能である。また、例えば、図16に示すように、SIPサーバにナンバースキャンニング検知プログラムを組み込む接続形態においても、本発明を同様に適用することができる。この接続形態によれば、ナンバースキャンニング検知プログラムは、SIPサーバと同じ装置の中で別のプロセスとして動作し、ネットワークインタフェースからSIPパケットに関する情報を取得することが可能であり、また、ナンバースキャンニングを行う端末を検知すると、実行中の対象となるプロセスに、当該端末からのSIPパケットを破棄する処理を即座に通知することが可能になる。
また、実施例1においては、ナンバースキャンニング検知装置が検知するSIPパケット(ナンバースキャンニングが疑われる状態情報を含むSIPパケット)として、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケット(例えば、『404 Not Found』)を検知する手法を例示したが、本発明はこれに限られるものではない。ナンバースキャンニングが疑われる状態情報を含むSIPパケットを検知し、これをトリガーとして統計情報の収集を開始する手法であれば、その他のSIPパケットを検知する手法にも、本発明を同様に適用することができる。
また、実施例1においては、統計情報として収集する情報は、SIPサーバから送信されるSIPパケットである手法を例示したが(図9、10、11、12など)、本発明はこれに限られるものではない。ナンバースキャンニングが疑われる状態情報を含むSIPパケットの検知をトリガーとして統計情報の収集を開始する手法であれば、その後統計情報として収集する情報が、SIPサーバから送信されるSIPパケットでない手法にも、本発明を同様に適用することができる。例えば、ナンバースキャンニング検知装置が、統計情報として、発信側端末からSIPサーバに向けて送信された『CANCEL』や『BYE』を収集する手法などにも、本発明を同様に適用することができる。
また、実施例1においては、SIPトランザクション処理が正規の手順で行われていないことを、『603 Decline』や『200 OK』の再送回数で検知すると、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットに関する情報(例えば、『603 Decline』、『200 OK』再送回数など)を、正規の手順で行われていない回数を示す統計情報として収集する手法を例示したが、本発明はこれに限られるものではない。例えば、ナンバースキャンニング検知装置が、『603 Decline』や『200 OK』の再送回数によってSIPトランザクション処理が正規の手順で行われていないことを検知するか否かに係らず、とりあえず、ナンバースキャンニング検知装置が、『603 Decline』や『200 OK』の再送回数を単なる統計情報の一項目(あるいは、SIPトランザクション処理が正規の手順で行われていないと疑われる状態情報の項目)として収集しておき、後に(オフラインなどで)、『603 Decline』や『200 OK』の再送回数の統計情報から、SIPトランザクション処理が正規の手順で行われていなかったのだと解析する場合にも、本発明を同様に適用することができる。
また、SIPトランザクション処理が正規の手順で行われていないことの検知が、『200 OK』の再送回数でなく、『BYE』の再送回数や、その他の手法によって行われる場合にも、本発明を同様に適用することができる。さらに、SIPトランザクション処理が正規の手順で行われていないことを検知した場合に、統計情報として収集する情報が、発信側端末から自発的に発信されるSIPパケット以外のSIPパケットであってSIPサーバから送信されるSIPパケットに関する情報でない場合にも、本発明を同様に適用することができる。
また、実施例1においては、ナンバースキャンニング検知装置が、統計情報の値が閾値以上になったか否かによって、発信側端末がナンバースキャンニングを行う端末であるか否かを判定する手法を例示したが、本発明はこれに限られるものではない。収集した統計情報に基づいて、発信側端末がナンバースキャンニングを行う端末であるか否かを判定する手法であれば、本発明を同様に適用することができる。
また、実施例1においては、本発明を、SIPを用いたIP電話サービスにおけるナンバースキャンニングに適用した場合について説明したが、本発明はこれに限られるものではない。例えば、SIP以外の他のプロトコル(H.323など)を用いたIP電話におけるナンバースキャンニングや、IP電話におけるナンバースキャンニングに限られず、公衆交換電話サービスにおけるナンバースキャンニングや、携帯電話サービスにおけるナンバースキャンニングなどにも、本発明を同様に適用することができる。すなわち、いずれのシステムにおいても、ネットワーク上で送受信される情報には、通信が所定の状態にあることを示す状態情報を含むはずである。また、いずれのシステムにおいても、このような状態情報の内、ナンバースキャンニングが疑われる状態情報(例えば、『発信側端末から発信された電話番号は存在しない』という状態にあることを示す状態情報)を含む情報が、ネットワーク上で送受信されるはずである。したがって、いずれのシステムにおいても、このような状態情報を含む情報を検知したことをトリガーに、統計情報の収集を開始し、発信側端末がナンバースキャンニングを行う端末であるか否かを判定することは可能であり、この意味で、本発明を同様に適用することが可能である。
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順(例えば、図13および14など)、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示(例えば、図2など)の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
なお、本実施例で説明したナンバースキャンニング検知方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、本発明に係るナンバースキャンニング検知装置およびナンバースキャンニング検知プログラムは、ナンバースキャンニングが行われる状況において、発信側端末を検知することに有用であり、特に、ナンバースキャンニングを検知する際の負荷を低減することに適する。
実施例1に係るナンバースキャンニング検知装置の概要および特徴を説明するための図である。 ナンバースキャンニング検知装置の構成を示すブロック図である。 ナンバースキャンニング検知装置の接続を示すネットワーク図である。 パケット検知ルール記憶部を説明するための図である。 ユーザ統計テーブル記憶部を説明するための図である。 閾値ルール記憶部を説明するための図である。 情報取得の開始について説明するための図である。 情報取得の開始について説明するための図である。 統計情報の収集について説明するための図である。 統計情報の収集について説明するための図である。 統計情報の収集について説明するための図である。 統計情報の収集について説明するための図である。 ナンバースキャンニング検知装置における個別ユーザ監視トリガーを示すフローチャートである。 ナンバースキャンニング検知装置における個別ユーザ監視を示すフローチャートである。 ナンバースキャンニング検知装置の他の接続を示すネットワーク図である。 ナンバースキャンニング検知装置の他の接続を示すネットワーク図である。 ナンバースキャンニングを説明するための図である。 従来技術を説明するための図である。 従来技術を説明するための図である。
符号の説明
1 IP電話網/インターネット
2 SIPサーバ
3 SIPクライアント
4 ナンバースキャンニング業者端末
10 ナンバースキャンニング検知装置
11 通信制御部
20 記憶部
21 パケット検知ルール記憶部
22 ユーザ統計テーブル記憶部
23 閾値ルール記憶部
30 制御部
31 パケット処理部
31a パケット監視部
31b パケット情報取得部
31c 特定パケット検知部
31d 統計取得起動部
32 統計取得部
32a 特定パケット統計取得部
32b ナンバースキャンニングユーザ検知部
33 ナンバースキャンニングユーザパケット処理部

Claims (9)

  1. 発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知装置であって、
    前記所定の電話番号に発信した発信側端末に対してSIPサーバが送信したSIPパケットのうち、接続先がないことを示す情報を含むSIPパケットを検知する第一の検知手段と、
    前記第一の検知手段によって前記接続先がないことを示す情報を含むSIPパケットが検知されたことを条件として、当該SIPパケットの送信先となる発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始する情報取得開始手段と、
    前記情報取得開始手段によってSIPトランザクション処理について情報の取得を開始された発信側端末に対して送信されるSIPパケットのうち、メッセージをSIPサーバに送信することなくSIPトランザクション処理を終了させたことを示す情報を含むSIPパケットを検知する第二の検知手段と、
    前記情報取得開始手段によって情報の取得が開始されると、取得した情報と前記第二の検知手段によるSIPパケットの検知回数とを統計情報として収集する統計情報収集手段と、
    前記統計情報収集手段によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手段と、
    を備えたことを特徴とするナンバースキャンニング検知装置。
  2. 前記第一の検知手段は、前記接続先がないことを示す情報を含むSIPパケットとして、404 Not Foundメッセージを含むSIPパケットが送信されたことを検知することを特徴とする請求項に記載のナンバースキャンニング検知装置。
  3. 前記統計情報収集手段は、前記統計情報として、SIPサーバから送信されるSIPパケットに関する情報のみを収集することを特徴とする請求項1又は2に記載のナンバースキャンニング検知装置。
  4. 前記統計情報収集手段は、前記統計情報として、404 Not Foundメッセージ、CANCELメッセージ、BYEメッセージのいずれか一つまたは複数を収集することを特徴とする請求項1〜のいずれか一つに記載のナンバースキャンニング検知装置。
  5. 前記第二の検知手段は、前記情報取得開始手段によって情報の取得が開始された前記発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送されたこと、あるいは、前記発信側端末に対してSIPサーバから603 Declineが送信されたことから、当該発信側端末による前記メッセージをSIPサーバに送信することなくSIPトランザクション処理を終了させたことを検知することを特徴とする請求項1〜4のいずれか一つに記載のナンバースキャンニング検知装置。
  6. 前記統計情報収集手段は、前記発信側端末による前記メッセージをSIPサーバに送信することなくSIPトランザクション処理を終了させた回数として、前記発信側端末に対して200 OKメッセージおよび/またはBYEメッセージがSIPサーバから繰り返し再送された回数、および/または、前記発信側端末に対してSIPサーバから603 Declineが送信された回数を収集することを特徴とする請求項1〜5のいずれか一つに記載のナンバースキャンニング検知装置。
  7. 前記判定手段は、予め記憶部に記憶している所定の閾値と、前記統計情報収集手段によって収集された前記統計情報とを比較し、当該統計情報の値が当該所定の閾値以上になった場合に、前記発信側端末が前記ナンバースキャンニングを行う端末であると判定することを特徴とする請求項1〜のいずれか一つに記載のナンバースキャンニング検知装置。
  8. 前記統計情報収集手段は、所定の発信側端末に関係して行われるSIPトランザクション処理についての情報を所定の時間収集しない場合に、当該発信側端末について収集してきた統計情報をリセットすることを特徴とする請求項1〜のいずれか一つに記載のナンバースキャニング検知装置。
  9. 発信側端末が所定の電話番号に発信したことを契機として行われるSIPトランザクション処理のSIPパケットから当該発信側端末が当該電話番号に関する情報を取得するナンバースキャンニングが行われる状況において、当該発信側端末を検知するナンバースキャンニング検知方法をコンピュータに実行させるナンバースキャンニング検知プログラムであって、
    前記所定の電話番号に発信した発信側端末に対してSIPサーバが送信したSIPパケットのうち、接続先がないことを示す情報を含むSIPパケットを検知する第一の検知手順と、
    前記第一の検知手順によって前記接続先がないことを示す情報を含むSIPパケットが検知されたことを条件として、当該SIPパケットの送信先となる発信側端末に関係して行われるSIPトランザクション処理について情報の取得を開始する情報取得開始手順と、
    前記情報取得開始手順によってSIPトランザクション処理について情報の取得を開始された発信側端末に対して送信されるSIPパケットのうち、メッセージをSIPサーバに送信することなくSIPトランザクション処理を終了させたことを示す情報を含むSIPパケットを検知する第二の検知手段と、
    前記情報取得開始手順によって情報の取得が開始されると、取得した情報と前記第二の検知手順によるSIPパケットの検知回数とを統計情報として収集する統計情報収集手順と、
    前記統計情報収集手順によって収集された前記統計情報に基づいて、前記発信側端末が前記ナンバースキャンニングを行う端末であるか否かを判定する判定手順と、
    をコンピュータに実行させることを特徴とするナンバースキャンニング検知プログラム。
JP2007212293A 2007-08-16 2007-08-16 ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム Expired - Fee Related JP4800272B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007212293A JP4800272B2 (ja) 2007-08-16 2007-08-16 ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007212293A JP4800272B2 (ja) 2007-08-16 2007-08-16 ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム

Publications (2)

Publication Number Publication Date
JP2009049601A JP2009049601A (ja) 2009-03-05
JP4800272B2 true JP4800272B2 (ja) 2011-10-26

Family

ID=40501410

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007212293A Expired - Fee Related JP4800272B2 (ja) 2007-08-16 2007-08-16 ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム

Country Status (1)

Country Link
JP (1) JP4800272B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6006691B2 (ja) * 2013-07-25 2016-10-12 日本電信電話株式会社 電話番号使用判定端末検出装置、電話番号使用判定端末検出装置の動作方法およびコンピュータプログラム
JP6114901B1 (ja) * 2016-05-24 2017-04-19 株式会社クローバー・ネットワーク・コム 電話番号調査装置、同方法、同プログラム、同情報提供システム、及び記録媒体

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3986871B2 (ja) * 2002-04-17 2007-10-03 株式会社エヌ・ティ・ティ・データ アンチプロファイリング装置およびアンチプロファイリングプログラム
JP2004104409A (ja) * 2002-09-09 2004-04-02 Matsushita Electric Ind Co Ltd 通信端末装置および通信システム
JP3974554B2 (ja) * 2003-05-19 2007-09-12 日本電信電話株式会社 ゲートウェイ
JP2005020524A (ja) * 2003-06-27 2005-01-20 Hitachi Information Technology Co Ltd サーバ装置および電話機
JP2006100873A (ja) * 2004-09-28 2006-04-13 Nippon Telegr & Teleph Corp <Ntt> Sipパケットフィルタリング装置およびネットワーク間接続装置およびsipサーバ
JP4409412B2 (ja) * 2004-10-29 2010-02-03 エヌ・ティ・ティ・コムウェア株式会社 トラフィック制御システム及び方法、輻輳検出装置、ならびに、コンピュータプログラム
JP2006237853A (ja) * 2005-02-23 2006-09-07 Mitsubishi Electric Corp Sipサーバ

Also Published As

Publication number Publication date
JP2009049601A (ja) 2009-03-05

Similar Documents

Publication Publication Date Title
EP1903745B1 (en) System and method for preventing spam over internet telephony
US8737594B2 (en) Emergency services for packet networks
US8973150B2 (en) Methods and apparatus to mitigate a denial-of-service attack in a voice over internet protocol network
WO2008131667A1 (fr) Procédé, dispositif d&#39;identification des flux de services et procédé, système de protection contre une attaque par déni de service
EP1931105A1 (fr) Procédé et système de gestion de sessions multimédia, permettant de contrôler l&#39;établissement de canaux de communication
CA2722377C (en) Statistical spam message detection
US9104874B2 (en) Method for detecting the hijacking of computer resources
KR101175081B1 (ko) 멀티미디어 시스템들에 대한 공격을 검출하기 위한 방법 및 공격 검출 기능을 갖는 멀티미디어 시스템
JP4800272B2 (ja) ナンバースキャンニング検知装置およびナンバースキャンニング検知プログラム
JP2007267151A (ja) 異常トラフィック検知装置、異常トラフィック検知方法および異常トラフィック検知プログラム
JP2006331015A (ja) サーバ装置保護システム
US20120060218A1 (en) System and method for blocking sip-based abnormal traffic
JP2003289337A (ja) 通信網およびルータおよび分散型サービス拒絶攻撃検出防御方法
Zhao et al. A chain reaction DoS attack on 3G networks: Analysis and defenses
JP5596626B2 (ja) DoS攻撃検出方法及びDoS攻撃検出装置
JPWO2006035928A1 (ja) Ip電話端末装置、呼制御サーバ、ワクチンサーバ、保守用装置、ip電話システム、これらの制御方法及びプログラム
KR101190816B1 (ko) SIP DoS 및 SPAM 공격 탐지 시스템 및 그 탐지 방법
JP4878630B2 (ja) 通信サーバおよびDoS攻撃防御方法
Hussain et al. A lightweight countermeasure to cope with flooding attacks against session initiation protocol
JP2008048047A (ja) 端末装置、セッション管理装置、システム、方法、及びプログラム
KR101379779B1 (ko) 발신 정보가 변조된 보이스 피싱 및 문자 피싱 공격을 탐지 및 차단하는 방법
JP2006023934A (ja) サービス拒絶攻撃防御方法およびシステム
CN111556013A (zh) 一种复杂大流量下VoIP恶意行为发现方法
Ahmedy et al. Using captchas to mitigate the VoIP spam problem
KR102322779B1 (ko) 불법통화검출방법 및 그 장치

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090722

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110510

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20110520

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20110520

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110630

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110726

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110803

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140812

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees