ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置
【課題】ＤＮＳキャッシュ・ポイズニング攻撃を簡単に防御できるようにする。
【解決手段】攻撃防御装置１４は、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置される。問い合わせ受信部は、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳキャッシュサーバ１２宛ての問い合わせパケットを受信する。問い合わせ送信部は、この問い合わせパケットをＤＮＳサーバ１１に転送する。応答受信部は、問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に攻撃防御装置１４に到達した当該問い合わせパケットに対応する応答パケットを受信する。応答判定部は、問い合わせパケットと一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する。
【解決手段】攻撃防御装置１４は、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置される。問い合わせ受信部は、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳキャッシュサーバ１２宛ての問い合わせパケットを受信する。問い合わせ送信部は、この問い合わせパケットをＤＮＳサーバ１１に転送する。応答受信部は、問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に攻撃防御装置１４に到達した当該問い合わせパケットに対応する応答パケットを受信する。応答判定部は、問い合わせパケットと一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置に関する。
【背景技術】
【０００２】
一般に、インターネットのようなネットワーク環境では、“*.abcd.co.jp”などで表記されるドメイン名と、それに対応するＩＰアドレス（数字とドットで表記）が存在する。インターネット利用者がクライアント端末を利用して、当該クライアント端末からドメイン名が例えば“ｗｗｗ.abcd.co.jp”のサーバにアクセスしたい場合、当該ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを取得するために、次のような名前解決の手順が適用される。
【０００３】
（１）クライアント端末はドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスをＤＮＳキャッシュサーバに問い合わせる。このＩＰアドレスが問い合わせられるドメイン名を問い合わせドメイン名と呼ぶこともある。ＤＮＳキャッシュサーバは、以前にＤＮＳサーバから取得したドメイン名とＩＰアドレスとの対応関係を示す情報を保持するキャッシュを有している。
【０００４】
ＤＮＳ（Domain Name System）とは、ドメイン名とＩＰアドレスとを対応付けるためのプロトコルである。ＤＮＳでは、ルートサーバを親とするツリー構造（階層構造）でドメインの権限／委譲の関係で分散管理が行われる。ルートサーバは、例えば種々の*1〜*4の組み合わせからなる“*4.*3.*2.x1”（*1 = jp, kr, …）のような最上位の階層（第１階層）のドメインを自身が有するデータベースにより管理する第１のＤＮＳサーバである。
【０００５】
ＤＮＳキャッシュサーバとルートサーバ（第１のＤＮＳサーバ）との間には複数のＤＮＳサーバが存在する。これらの複数のサーバは複数の第２のＤＮＳサーバと、複数の第３のＤＮＳサーバと、複数の第４のＤＮＳサーバとを含む。
【０００６】
第２のＤＮＳサーバは、種々の*1のうち当該第２のＤＮＳサーバに固有のx１(x1はjp, kr, …のいずれか）と、種々の*2〜*4との組み合わせからなる、“*4.*3.*2.x1”のような第２階層のドメインを、自身が有するデータベースにより管理する。第３のＤＮＳサーバは、種々の*1，*2のうち当該第３のＤＮＳサーバに固有のx１，x2(x1はjp，kr…のいずれか、x2はco，ac…のいずれか）と、種々の*3，*4との組み合わせからなる、*4.*3.x2.x1”のような第３階層のドメインを、自身が有するデータベースにより管理する。第４のＤＮＳサーバは、種々の*1〜*3のうち当該第３のＤＮＳサーバに固有のx1〜x3(x1はjp，kr…のいずれか、x2はco，ac…のいずれか、x3はabcd,efgh…のいずれか）と、種々の*4との組み合わせからなる、*4.x3.x2.x1”のような第４階層のドメインを、自身が有するデータベースにより管理する。
【０００７】
（２）ＤＮＳキャッシュサーバは自身のキャッシュにドメイン名“ｗｗｗ.abcd.co.jp”とＩＰアドレスとの対応関係を示す情報が存在するならば、それをクライアント端末からの問い合わせに対する回答として当該クライアント端末に返す。これに対し、この情報が存在しないならば、ＤＮＳキャッシュサーバは“*4.abcd.co.jp”（x3=abcd, x2=co, x1=jp）のようなドメインを管理する第４のＤＮＳサーバに、ドメイン名“ｗｗｗ.abcd.co.jp”と対応付けられたＩＰアドレスを問い合わせる。
【０００８】
ＤＮＳキャッシュサーバから第４のＤＮＳサーバへの問い合わせ（クエリ）は、問い合わせのためのパケット（問い合わせパケット）を用いて行われる。問い合わせパケットはクエリパケットとも呼ばれ、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名（対応するＩＰアドレスに名前解決されるべきドメイン名）及び識別子（ＩＤ）を含む。送信先ＩＰアドレスには第４のＤＮＳサーバのＩＰアドレス（例えば、192.168.20.1）が用いられ、送信元ＩＰアドレスにはＤＮＳキャッシュサーバのＩＰアドレスが用いられる。ＩＤは問い合わせ（問い合わせパケット）を識別するための情報（ＩＤ情報）であり、ＤＮＳキャッシュサーバによって生成される。
【０００９】
（３）第４のＤＮＳサーバは、ＤＮＳキャッシュサーバからの問い合わせに応じて、ドメイン名“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレス、つまりドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバのＩＰアドレス（例えば、10.0.0.1）を含む応答のためのパケット（つまり応答パケット）を返す。この応答パケットは、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名、ＩＤ及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられたＩＰアドレス、つまり問い合わせに対する回答となるＩＰアドレス（以下、応答ＩＰアドレスと称する）を含む。
【００１０】
なお、第４のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理していない場合、当該第４のＤＮＳサーバから、*4.*3.co.jp”（x2=co, x1=jp）のようなドメインを管理する第３のＤＮＳサーバに、当該“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを問い合わせる。もし、第３のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理しているならば、そのＩＰアドレスを含む応答パケットを第４のＤＮＳサーバに返す。第４のＤＮＳサーバは、“ｗｗｗ.abcd.co.jp”と応答されたＩＰアドレスとの対応関係を示す情報を自身のデータベースに登録し、そのＩＰアドレスを含む応答パケットをＤＮＳキャッシュサーバに返す。これに対し、第３のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理していない場合、当該第３のＤＮＳサーバから、*4.*3.*2.jp”（x1=jp）のようなドメインを管理する第２のＤＮＳサーバに、当該“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを問い合わせる。
【００１１】
このように、ドメイン名をＩＰアドレスに変換するための、いわゆる名前解決は、ルートサーバを含むツリー構造のＤＮＳサーバを下位の階層から辿ることにより実現されるのが一般的である。しかし、以降の説明では簡略化のために、第４のＤＮＳサーバによって名前解決が実現されるものとし、この第４のＤＮＳサーバを単にＤＮＳサーバと呼ぶ。
【００１２】
（４）ＤＮＳキャッシュサーバはＤＮＳサーバから返された応答パケットを受信すると、当該パケットに含まれている送信元ＩＰアドレス、ＩＤ及びドメイン名に基づき、当該応答パケットが正しいかを判定する。もし正しいならば、ＤＮＳキャッシュサーバは、応答パケットに含まれているＩＰアドレスを、クライアント端末からの問い合わせに対する回答として当該クライアント端末に転送する。これによりクライアント端末は、ＤＮＳキャッシュサーバから転送されたＩＰアドレス（10.0.0.1）を用いてドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバにアクセスできる。
【００１３】
しかし、上述のようなＤＮＳプロトコルの仕組みでは以下に述べるようなプロトコル上の欠陥が存在する。
まず、上記手順（４）で説明したように、ＤＮＳキャッシュサーバはＤＮＳサーバからの応答パケットが正しいかを判定するのに、
・送信元ＩＰアドレス（つまりＤＮＳサーバのＩＰアドレス）
・ＩＤ
・問い合わせドメイン名
という３つの要素を用いている。
【００１４】
ＤＮＳの通信はＵＤＰ（User Datagram Protocol）上で行われる。ＵＤＰはセッションレスなプロトコルであり、セッションという概念がない。つまりＵＤＰは、問い合わせ／応答の間に何ら紐付ける仕組みを用意していない。よって、ＤＮＳでは上述の３つの要素が応答パケットの正当性の判定に用いられる。この応答パケットの正当性を判定する要素が上述の３つに限られている点がＤＮＳのプロトコル上の欠陥として指摘されている。
【００１５】
この欠陥をどのように攻撃に結びつけるかについて、例を挙げて説明する。
ある攻撃者が、ドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスを本来の“10.0.0.1”ではなく、攻撃者が準備した偽のサイトのＩＰアドレス“200.1.1.1”にクライアント端末（インターネット利用者）を誘導しようと試みたとする。この場合、クライアント端末が問い合わせを行うＤＮＳキャッシュサーバがターゲットとされる。
【００１６】
攻撃者は、応答パケットを偽造してＤＮＳキャッシュサーバに送出する。この偽造された応答パケット（以下、偽応答パケットと称する）の送信先ＩＰアドレス、送信元ＩＰアドレス、ドメイン名、ＩＤ及び応答ＩＰアドレスは、
・送信先ＩＰアドレス：ＤＮＳキャッシュサーバのＩＰアドレス
・送信元ＩＰアドレス：192.168.20.1（ＤＮＳサーバのＩＰアドレス）
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＤ：123
・応答ＩＰアドレス：200.1.1.1
であるものとする。この偽応答パケットが、送信元ＩＰアドレスとして、ＤＮＳサーバのＩＰアドレスを偽っていることに注意する。
【００１７】
ＤＮＳキャッシュサーバからＤＮＳサーバ宛てに送出された問い合わせパケットに対して、当該ＤＮＳサーバからＤＮＳキャッシュサーバに対して上記手順（３）で正規の応答パケット（正規応答パケット）が返された場合、ＤＮＳキャッシュサーバには、
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＰアドレス：10.0.0.1
のような、ドメイン名とＩＰアドレスとの対応関係を示す情報が登録される。
【００１８】
しかし、偽応答パケットが正規応答パケットよりも先にＤＮＳキャッシュサーバに到達すると、ＤＮＳキャッシュサーバには、
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＰアドレス：200.1.1.1（偽のサイトのＩＰアドレス）
のような情報が登録されてしまう。
【００１９】
すると、クライアント端末からのドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスの問い合わせに対して、ＤＮＳキャッシュサーバは偽のサイトのＩＰアドレス“200.1.1.1”を当該クライアント端末に回答する。この回答を受け取ったクライアント端末は偽のサイトに誘導されることになる。
【００２０】
以上の説明から明らかなように、上述の攻撃が成立するためには、
（ａ）以下の３つの要素
・送信元（上位のＤＮＳサーバ）のＩＰアドレス
・識別ＩＤ
・問い合わせドメイン名
が正規のＤＮＳ応答と同じであること
（ｂ）ある問い合わせに対し、ＤＮＳサーバが正規応答パケットを返す前に偽応答パケットがＤＮＳキャッシュサーバに到達する
という条件が必要である。
【００２１】
これらの条件のうち、送信元（上位のＤＮＳサーバ）のＩＰアドレス、問い合わせドメイン名は攻撃者のターゲットの情報であるため自ずと決まる。よって、攻撃者にとっては、ＩＤと偽応答パケットの到達タイミングさえ合えば攻撃を成立させることが可能とある。ＩＤは１６ビットの長さを持つ情報であるが、ＤＮＳサーバの種別により容易に推測可能と言われている。また、推測できなくても高々１６ビットの情報であれば、ランダムに送出し続けるだけで合致する確率は高いと言われている。偽応答パケットの到達タイミングについても、ＤＮＳキャッシュサーバにおける情報（ドメイン名とＩＰアドレスとの対応関係を示す情報）の保持期間（ＴＴＬ値）は数時間〜１日が一般的であり、偽応答パケットを大量に送出し続けていれば合致してしまう可能性はある。このような攻撃手法がＤＮＳキャッシュ・ポイズニングと呼ばれている。
【００２２】
例えば特許文献１は、このようなＤＮＳキャッシュ・ポイズニングに相当する攻撃を防御するための手法（以下、便宜的にＤＮＳキャッシュ・ポイズニング攻撃防御手法と称する）を開示している。この特許文献１に記載のＤＮＳキャッシュ・ポイズニング攻撃防御手法によれば、認証用サーバは、ＤＮＳサーバと同様にドメイン名とＩＰアドレスとの対応関係を示す情報を記憶する。この認証サーバは、端末からのドメイン名に対応するＩＰアドレスの問い合わせに対して、ＤＮＳサーバと同様に、ドメイン名に対応するＩＰアドレスを当該端末に応答する。ＩＰアドレスを問い合わせた端末は、ＤＮＳサーバ及び認証サーバの両サーバから応答されたＩＰアドレスを比較して、両者が一致していないならば、攻撃を受けているとして使用者に警告する
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開２００７−２０００４号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
しかしながら、特許文献１に記載されたＤＮＳキャッシュ・ポイズニング攻撃防御手法では、ＤＮＳサーバとは無関係の認証用サーバに、ＤＮＳサーバと同様にドメイン名とＩＰアドレスとの対応関係を示す情報を記憶する記憶部（ＩＰアドレス記憶部）を備える必要があり、認証用サーバの構成が複雑となる。しかも、ＩＰアドレスを問い合わせた端末が、ＤＮＳサーバ及び認証サーバの両サーバから応答されたＩＰアドレスを比較することによって、攻撃を受けているかを正しく判定するには、認証用サーバに、ＤＮＳサーバが記憶しているのと同一の情報を正しく記憶しなければならず、認証用サーバの管理が複雑となる。
【００２５】
本発明は上記事情を考慮してなされたものでその目的は、偽の情報をＤＮＳキャッシュサーバにキャッシュさせるＤＮＳキャッシュ・ポイズニング攻撃を簡単に防御することができる、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置を提供することにある。
【課題を解決するための手段】
【００２６】
本発明の１つの観点によれば、ＤＮＳサーバとＤＮＳキャッシュサーバとの間に配置された、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置が提供される。この装置は、前記ＤＮＳキャッシュサーバから送出されたドメイン名に対応するＩＰアドレスを問い合わせるための前記ＤＮＳサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、前記受信された問い合わせパケットを前記ＤＮＳキャッシュサーバに代わって前記ＤＮＳサーバに転送する問い合わせ送信手段と、前記問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、前記正規応答パケットであると判定された応答パケットを前記ＤＮＳキャッシュサーバに返す応答送信手段とを具備する。
【発明の効果】
【００２７】
本発明によれば、ＤＮＳの仕組み上、ドメイン名に対応するＩＰアドレスをＤＮＳキャッシュサーバからＤＮＳサーバに問い合わせるための問い合わせパケットに対して、当該ＤＮＳサーバから返される正規応答パケットは必ず１つであることに着目して、問い合わせパケットと当該問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定することにより、偽の情報をＤＮＳキャッシュサーバにキャッシュさせるＤＮＳキャッシュ・ポイズニング攻撃を簡単に防御することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明の一実施形態に係る攻撃防御装置を含むネットワークシステムの構成を示すブロック図。
【図２】攻撃防御装置の構成を示すブロック図。
【図３】ドメイン・ＩＰアドレス管理テーブルのデータ構造例を示す図。
【図４】応答時間学習テーブルのデータ構造例を示す図。
【図５】リトライ回数テーブルのデータ構造例を示す図。
【図６】同実施形態における情報の流れを示す図。
【図７】同実施形態における攻撃防御装置の処理手順を示すフローチャート。
【図８】同実施形態における攻撃防御装置の処理手順を示すフローチャート。
【図９】問い合わせパケットの一例を示す図。
【図１０】応答パケットの一例を示す図。
【発明を実施するための形態】
【００２９】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るＤＮＳキャッシュ・ポイズニング攻撃防御装置（以下、攻撃防御装置と略称する）を含むネットワークシステムの構成を示すブロック図である。
【００３０】
図１に示されるネットワークシステムは、ＤＮＳサーバ１１、ＤＮＳキャッシュサーバ１２、ｗｗｗサーバ１３、攻撃防御装置１４及びクライアント端末１５を備えている。ＤＮＳサーバ１１及びｗｗｗサーバ１３はＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）を適用するインターネットのようなグローバルネットワーク１６に、例えばローカルエリアネットワーク及び中継装置（いずれも図示せず）を介して接続されている。
【００３１】
一方、ＤＮＳキャッシュサーバ１２、攻撃防御装置１４及びクライアント端末１５は、ＴＣＰ／ＩＰを適用するローカルエリアネットワーク１７に接続されている。グローバルネットワーク１６とローカルエリアネットワーク１７とは中継装置１８及び攻撃防御装置１４を介して接続されている。
【００３２】
上述したようにグローバルネットワーク１６にはローカルエリアネットワーク及び中継装置を介してＤＮＳサーバ１１が接続され、ローカルエリアネットワーク１７にはＤＮＳキャッシュサーバ１２が接続されている。したがって、グローバルネットワーク１６とローカルエリアネットワーク１７とが中継装置１８及び攻撃防御装置１４を介して接続されることにより、当該攻撃防御装置１４は、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置されることになる。
【００３３】
図１に示されるネットワークシステムの例では、ｗｗｗサーバ及びクライアント端末は、それぞれｗｗｗサーバ１３及びクライアント端末１５だけである。しかし、ｗｗｗサーバ１３を含む複数のｗｗｗサーバと、クライアント端末１５を含む複数のクライアント端末が存在しても構わない。またローカルエリアネットワーク１７と同様の接続構成のネットワークがローカルエリアネットワーク１７とは別に存在しても構わない。
【００３４】
ＤＮＳサーバ１１は、ドメインを管理するＤＮＳサーバである。ＤＮＳサーバ１１は、例えばドメイン名が“ns1.abcd.co.jp”のＩＰアドレス“192.168.20.1”を持つ。ＤＮＳサーバ１１は、*4を“www”のような任意のホスト名であるとすると、“*4.abcd.co.jp”（x3=abcd, x2=co, x1=jp）で表現されるドメイン名とＩＰアドレスとの対応関係を示す情報を保持するデータベース（以下、ＩＰアドレス記憶部と称する）１１０を含む。
【００３５】
前述したようにＤＮＳでは、ルートサーバを親とするツリー構造でドメインの権限／委譲の関係で分散管理が行われ、ＤＮＳキャッシュサーバ１２とルートサーバとの間にはＤＮＳサーバ１１を含む複数のＤＮＳサーバが存在する。しかし、図１のネットワークシステムの例では、説明の簡略化のためにＤＮＳサーバ１１以外のＤＮＳサーバは省略されており、便宜的にＤＮＳサーバ１１のみで名前が解決（ドメイン名からＩＰアドレスへの変換）されるものとする。
【００３６】
ＤＮＳキャッシュサーバ１２は、例えばクライアント端末１５からのドメイン名に対応するＩＰアドレスの問い合わせに応じて、ＤＮＳサーバ１１から当該ドメイン名に対応するＩＰアドレスを取得した場合に、当該ドメイン名とＩＰアドレスとの対応関係を示す情報を一定期間保持するキャッシュ１２０を有する。この一定期間を示す値はＴＴＬ値と呼ばれる。このＴＴＬ値は、ＤＮＳキャッシュサーバ１２の設定に委ねられるものとする。ＤＮＳキャッシュサーバ１２は、プロバイダや企業内ネットワークなどに配置される。
【００３７】
ｗｗｗサーバ１３は、例えばドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を持つ。ｗｗｗサーバ１３は、クライアント端末からＩＰアドレス“10.0.0.1”を用いてアクセスされることにより、自身が保持している情報を当該クライアント端末に提供する。
【００３８】
攻撃防御装置１４は、前述したようにＤＮＳキャッシュサーバ１２とＤＮＳサーバ１１との間に配置される。これにより、ＤＮＳキャッシュサーバ１２からドメイン名に対応するＩＰアドレスを問い合わせるためのＤＮＳサーバ１１宛ての問い合わせパケットがローカルエリアネットワーク１７上に送出された場合に、当該問い合わせパケットは攻撃防御装置１４に入力される。
【００３９】
図２は攻撃防御装置１４の構成を示すブロック図である。攻撃防御装置１４は、問い合わせ受信部１４１、問い合わせ送信部１４２、応答受信部１４３、管理情報記憶部１４４、管理部１４５、応答判定部１４６及び応答送信部１４７を含む。
【００４０】
問い合わせ受信部１４１は、攻撃防御装置１４に入力される、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳサーバ１１宛ての問い合わせパケットを横取りして受信する。問い合わせ送信部１４２は、問い合わせ受信部１４１によって受信されたＤＮＳサーバ１１宛ての問い合わせパケットをＤＮＳキャッシュサーバ１２に代わって当該ＤＮＳサーバ１１に転送するために、中継装置１８を介してグローバルネットワーク１６に送信する。
【００４１】
応答受信部１４３は、ＤＮＳサーバ１１宛ての問い合わせパケットの転送に応じて、ある時間Ｔの間、当該問い合わせパケットに対応する応答パケットが攻撃防御装置１４に到達するのを待つ。応答受信部１４３は、この時間Ｔの間に攻撃防御装置１４に到達する応答パケットを全て受信する。
【００４２】
管理情報記憶部１４４はドメイン・ＩＰアドレス管理テーブル１４４ａ、応答時間学習テーブル１４４ｂ及びリトライ回数テーブル１４４ｃをそれぞれ格納するのに用いられる。管理情報記憶部１４４は例えばハードディスクドライブのような不揮発性の記憶装置を用いて実現されるものとする。
【００４３】
ドメイン・ＩＰアドレス管理テーブル１４４ａは、問い合わせ受信部１４１で受信される問い合わせパケット毎にドメイン・ＩＰアドレス管理情報を保持するエントリを有する。
【００４４】
図３は、ドメイン・ＩＰアドレス管理テーブル１４４ａのデータ構造例を示す。ドメイン・ＩＰアドレス管理テーブル１４４ａの各エントリ（に保持されるドメイン・ＩＰアドレス管理情報）は、ＩＤフィールド、問い合わせドメイン名フィールド、問い合わせ先ＩＰアドレスフィールド、問い合わせ時刻フィールド、応答ＩＰアドレスフィールド及び応答時間フィールドを有する。
【００４５】
ＩＤフィールド、問い合わせドメイン名フィールド及び問い合わせ先ＩＰアドレスフィールドは、それぞれ、対応する問い合わせパケットに設定されている、ＩＤ（識別子）、問い合わせドメイン名及び問い合わせ先のＤＮＳサーバのＩＰアドレス（つまり問い合わせ先ＩＰアドレス）を保持するのに用いられる。問い合わせ時刻フィールドは、問い合わせパケットを受信した時刻（以下、問い合わせ時刻と称する）を示す問い合わせ時刻情報を保持するのに用いられる。応答ＩＰアドレスフィールドは、問い合わせ先に問い合わせパケットを送信してから時間Ｔの間に応答受信部１４３によって受信された、当該問い合わせパケットとＩＤが同一の応答パケット（１つとは限らない）から得られたＩＰアドレス（以下、応答ＩＰアドレスと称する）を保持するのに用いられる。応答時間フィールドは、応答パケットが応答受信部１４３によって受信されるまでの問い合わせ時刻からの経過時間（つまり応答時間）を示す応答時間情報を保持するのに用いられる。応答ＩＰアドレスフィールド及び応答時間フィールドの組は、１エントリにつき１つとは限らない。
【００４６】
応答時間学習テーブル１４４ｂは、ＤＮＳサーバ毎に、当該ＤＮＳサーバへの問い合わせに対して当該ＤＮＳサーバから応答が返されるまでの最新の応答時間を示す情報を当該ＤＮＳサーバのＩＰアドレスに対応付けて保持するエントリを有する。この応答時間学習テーブル１４４ｂのデータ構造例を図４に示す。本実施形態では、応答時間学習テーブル１４４ｂにＤＮＳサーバ毎に保持される応答時間を示す情報の初期値として、対応するＤＮＳサーバに固有の予め定められた値が用いられる。
【００４７】
リトライ回数テーブル１４４ｃは、ドメイン名に対応するＩＰアドレスの問い合わせのリトライ回数を示すリトライ回数情報をドメイン名毎に保持するエントリを有する。リトライ回数情報の初期値は０である。
【００４８】
図５は、リトライ回数テーブル１４４ｃのデータ構造例を示す。リトライ回数テーブル１４４ｃの各エントリに保持されるリトライ回数情報は、ドメイン名、当該ドメイン名に対応するＩＰアドレスの問い合わせをリトライしたリトライ回数、初回登録日時を示す初回登録日時情報及び最終登録日時を示す最終登録日時情報を含む。
【００４９】
再び図１を参照すると、管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケット、当該問い合わせパケットの受信時刻、応答受信部１４３によって受信された当該問い合わせパケットに対応する応答パケット、及び当該応答パケットの受信時刻に基づいて、ドメイン・ＩＰアドレス管理テーブル１４４ａにドメイン・ＩＰアドレス管理情報を登録する。管理部１４５はまた、応答受信部１４３によって受信されたＤＮＳサーバからの応答パケットが正規応答パケットであると応答判定部１４６によって判定された場合に、その応答パケットが返されるまでの応答時間を示す情報を当該ＤＮＳサーバのＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂに登録する。管理部１４５は更に、リトライ回数情報のリトライ回数テーブル１４４ｃへの登録及びリトライ回数テーブル１４４ｃに登録されているリトライ回数情報の更新を行う。
【００５０】
応答判定部１４６は、ドメイン・ＩＰアドレス管理テーブル１４４ａに登録されているドメイン・ＩＰアドレス管理情報に基づいて、時間Ｔの間に正規応答パケットが受信されたかを判定する。応答送信部１４７は、正規応答パケットが受信されたと判定された場合、ＤＮＳキャッシュサーバ１２宛てに応答パケットを送信する。
【００５１】
次に、本実施形態における動作について、攻撃防御装置１４の動作を中心に図６乃至図８を参照して説明する。図６は情報の流れを示す図、図７及び図８は攻撃防御装置の処理手順を示すフローチャートである。
【００５２】
今、インターネット利用者がクライアント端末１５を操作することにより、当該クライアント端末１５からドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバ１３にアクセスしようとしているものとする。この場合、クライアント端末１５は、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを、図６において矢印６０１で示すようにＤＮＳキャッシュサーバ１２に問い合わせる。
【００５３】
ＤＮＳキャッシュサーバ１２は、クライアント端末１５からのドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスの問い合わせを受信する。するとＤＮＳキャッシュサーバ１２は、クライアント端末１５から問い合わせられたドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてＩＰアドレスがキャッシュ１２０に登録されているかを判定する。
【００５４】
ここでは、ＤＮＳキャッシュサーバ１２のキャッシュ１２０には、クライアント端末１５から問い合わせられたドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてＩＰアドレスが登録されていないものとする。この場合、ＤＮＳキャッシュサーバ１２は“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを取得するために、ＤＮＳサーバ１１宛ての問い合わせパケットＱＰを、図６において矢印６０２で示すように送出する。
【００５５】
図９は、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳサーバ１１宛ての問い合わせパケットＱＰの一例を示す。図９に示される問い合わせパケットＱＰは、送信先ＩＰアドレスとしてＤＮＳサーバ１１のＩＰアドレス“192.168.20.1”を含み、送信元ＩＰアドレスとしてＤＮＳキャッシュサーバ１２のＩＰアドレスを含む。また、問い合わせパケットＱＰは、問い合わせドメイン名（名前解決されるべきドメイン名）としてｗｗｗサーバ１３のドメイン名“ｗｗｗ.abcd.co.jp”を含み、当該問い合わせパケットＱＰのＩＤとして“123”を含む。
【００５６】
ＤＮＳキャッシュサーバ１２によって送出されたＤＮＳサーバ１１宛ての問い合わせパケットＱＰは、ローカルエリアネットワーク１７を介して攻撃防御装置１４に入力される。すると攻撃防御装置１４の問い合わせ受信部１４１は、ＤＮＳキャッシュサーバ１２から送出された問い合わせパケットＱＰを受信する（ステップ７０１）。この問い合わせパケットＱＰの受信時刻が“09:10:00:00”（９時１０分００秒００）であるものとする。
【００５７】
管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケットＱＰ、及び当該問い合わせパケットの受信時刻に基づいて、ドメイン・ＩＰアドレス管理テーブル１４４ａのエントリにドメイン・ＩＰアドレス管理情報を登録する（ステップ７０２）。このステップ７０２で登録されるドメイン・ＩＰアドレス管理情報は、問い合わせパケットＱＰのＩＤ“123”、問い合わせドメイン名“ｗｗｗ.abcd.co.jp”、問い合わせ先ＩＰアドレス（ＤＮＳサーバ１１のＩＰアドレス）“192.168.20.1”、及び問い合わせパケットＱＰの受信時刻に一致する問い合わせ時刻“09:10:00:00”の情報を含む。このときドメイン・ＩＰアドレス管理情報の応答ＩＰアドレスフィールド及び応答時間フィールドは空欄となっている。
【００５８】
また、ステップＳ７０２において管理部１４５は、リトライ回数テーブル１４４ｃにリトライ回数情報を登録する。このリトライ回数情報は、ドメイン名及びリトライ回数として、それぞれ、問い合わせパケットＱＰに含まれている問い合わせドメイン名“ｗｗｗ.abcd.co.jp”及び初期値０を含む。リトライ回数情報は更に、現在の日時を示す初回登録日時情報を含む。このときリトライ回数情報の最終登録日時情報は有効な日時を示していない。なお、最終登録日時情報が現在の日時を示していてもよい。
【００５９】
管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケットＱＰを問い合わせ送信部１４２に渡す。すると問い合わせ送信部１４２は、問い合わせパケットＱＰを、ＤＮＳキャッシュサーバ１２に代わって、図６において矢印６０３で示すようにＤＮＳサーバ１１に転送する（ステップ７０３）。
【００６０】
一方管理部１４５は、応答受信部１４３がＤＮＳサーバ１１からの応答パケットを待つ時間Ｔを決定して、決定した時間Ｔを応答受信部１４３に通知する（７０４）。この時間Ｔは、ＤＮＳサーバ１１のＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂに格納されている応答時間情報の示す応答時間に基づいて決定される。時間Ｔの詳細な決定手法については、後述する。
【００６１】
ＤＮＳサーバ１１は、攻撃防御装置１４の問い合わせ送信部１４２によって転送されたＤＮＳキャッシュサーバ１２からの問い合わせパケットＱＰを受信すると、当該問い合わせパケットＱＰに含まれている問い合わせドメイン名“ｗｗｗ.abcd.co.jp”に基づいてＩＰアドレス記憶部１１０を参照する。本実施形態ではＩＰアドレス記憶部１１０に、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてｗｗｗサーバ１３のＩＰアドレス“10.0.0.1”が登録されているものとする。この場合、ＤＮＳサーバ１１はＩＰアドレス記憶部１１０から、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられているＩＰアドレス“10.0.0.1”を取得する。つまりＤＮＳサーバ１１は、ＩＰアドレス記憶部１１０に基づいて、ドメイン名“ｗｗｗ.abcd.co.jp”をＩＰアドレス“10.0.0.1”に変換（名前解決）する。
【００６２】
するとＤＮＳサーバ１１は、ドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバのＩＰアドレス“10.0.0.1”を含むＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰを、図６において矢印６０４で示すように送信する。応答パケットＱＰは、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名、ＩＤ及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられている、名前解決されたＩＰアドレス（応答ＩＰアドレス）を含む。
【００６３】
図１０は、ＤＮＳサーバ１１から送信されたＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰの一例を示す。図１０に示される応答パケットＴＲＰは、送信先ＩＰアドレスとしてＤＮＳキャッシュサーバ１２のＩＰアドレスを含み、送信元ＩＰアドレスとしてＤＮＳサーバ１１のＩＰアドレス“192.168.20.1”を含む。また、応答パケットＴＲＰは、問い合わせドメイン名としてｗｗｗサーバ１３のドメイン名“ｗｗｗ.abcd.co.jp”を含み、ＩＤとして対応する問い合わせパケットＱＲのＩＤ“123”を含む。応答パケットＴＲＰは更に、応答ＩＰアドレスとしてｗｗｗサーバ１３のＩＰアドレス“10.0.0.1”を含む。
【００６４】
ＤＮＳサーバ１１から送信されたＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰは、グローバルネットワーク１６及び中継装置１８を介して、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置された攻撃防御装置１４に到達する。応答受信部１４３は、この攻撃防御装置１４に到達した応答パケットＴＲＰを受信する。本実施形態において応答受信部１４３は、管理部１４５から時間Ｔが通知されると（ステップ７０４）、その時点から時間Ｔの間に攻撃防御装置１４に到達する当該ＤＮＳサーバ１１からの応答パケットを全て受信する（ステップ７０５〜７０７）。この時間Ｔの間に応答受信部１４３によって受信される応答パケットは、ＤＮＳサーバ１１からの正規応答パケットに限らない。例えば、送信元ＩＰアドレスをＤＮＳサーバ１１のＩＰアドレスに偽装した、つまり送信元をＤＮＳサーバ１１に偽装した攻撃者からの偽応答パケットも、時間Ｔの間に応答受信部１４３によって受信される可能性がある。
【００６５】
管理部１４５は、時間Ｔの間に、応答受信部１４３によって応答パケットが受信される都度（ステップ７０７）、ドメイン・ＩＰアドレス管理テーブル１４４ａから、受信応答パケットに含まれているＩＤ、問い合わせドメイン名及び送信元ＩＰアドレスが設定されたドメイン・ＩＰアドレス管理情報が登録されているエントリを検索する（ステップ７０８）。つまり管理部１４５は、受信応答パケットと対応している問い合わせパケットの内容を登録したエントリをエントリをドメイン・ＩＰアドレス管理テーブル１４４ａから検索する。
【００６６】
そして管理部１４５は、検索されたドエントリの応答ＩＰアドレスフィールド及び応答時間フィールドに、それぞれ、受信応答パケットに含まれている応答ＩＰアドレス及び応答時間を示す情報を設定する（ステップ７０９）。ここで、応答時間は、検索されたドエントリの問い合わせ時刻フィールドによって示される問い合わせ時刻と受信応答パケットの受信時刻とから（受信時刻−問い合わせ時刻）の演算によって算出される。
【００６７】
明らかなように、問い合わせパケットを受信した時点（問い合わせ時刻）から期間Ｔの間に、当該問い合わせパケットに対応する複数の応答パケットが受信された場合、受信された応答パケットの数だけ、応答ＩＰアドレス及び応答時間を示す情報の組が、検索されたドエントリに登録される。
【００６８】
ここで、例えば図６に示される攻撃者（の端末）６０が、ドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスを本来の“10.0.0.1”ではなく、攻撃者６０が準備した偽のサイトのＩＰアドレス“200.1.1.1”にクライアント端末１５（インターネット利用者）を誘導しようと試みたとする。このような場合、攻撃者６０は、例えば図６において矢印６０５で示すように、ＤＮＳキャッシュサーバ１２宛ての多数の偽応答パケットＦＲＰを送信する。
【００６９】
各偽応答パケットＦＲＰの送信先ＩＰアドレス及び送信元ＩＰアドレスには、それぞれ、クライアント端末１５が問い合わせを行うＤＮＳキャッシュサーバ１２のＩＰアドレス及びＤＮＳサーバ１１のＩＰアドレスが用いられる。つまり各偽応答パケットＦＲＰは、送信元ＩＰアドレスとして、ＤＮＳサーバ１１のＩＰアドレスを偽装している。また、各偽応答パケットＦＲＰの問い合わせドメイン名及び応答ＩＰアドレスには、それぞれ、クライアント端末１５が必要としているＩＰアドレスのドメイン名“ｗｗｗ.abcd.co.jp”及び偽のサイトのＩＰアドレス“200.1.1.1”が用いられる。更に各偽応答パケットＦＲＰのＩＤには、攻撃者６０によって推測された、或いはランダムに生成される値が用いられる。
【００７０】
このような多数の偽応答パケットＦＲＰのいずれかに、問い合わせパケットＱＲのＩＤ“123”に一致するＩＤが用いられていて、且つ、その偽応答パケットＦＲＰが応答パケットＴＲＰ（つまり正規の応答パケット）よりも先にＤＮＳキャッシュサーバ１２に到達したならば、従来であれば、その偽応答パケットＦＲＰが正規応答パケットと誤って判定される。
【００７１】
本実施形態では、このような不具合を防止するために、上述のようにＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に攻撃防御装置１４が配置される。これによりＤＮＳキャッシュサーバ１２から送出されるＤＮＳサーバ１１宛ての問い合わせパケットは攻撃防御装置１４に入力され、問い合わせ受信部１４１で受信される（ステップ７０１）。管理部１４５は、この問い合わせパケットの内容を、当該問い合わせパケットのＩＤ毎に、つまり問い合わせドメイン名毎に、ドメイン・ＩＰアドレス管理テーブル１４４ａに格納する（ステップ７０２）。問い合わせ送信部１４２は、問い合わせ受信部１４１によって受信された問い合わせパケット、つまりＤＮＳキャッシュサーバ１２から送出された問い合わせパケットを宛先のＤＮＳサーバ１１に転送する（ステップ７０３）。
【００７２】
さて、ＤＮＳの仕組み上、ＤＮＳキャッシュサーバ１２からのＤＮＳサーバ１１に対する問い合わせに対し、当該ＤＮＳサーバ１１からは必ず１つの応答が返る。仮にＤＮＳサーバ１１に対する問い合わせに対し、時間Ｔの間に２つ以上の応答が返ってきた場合で、且つ、問い合わせドメイン名に対応するＩＰアドレス（応答ＩＰアドレス）がそれぞれ異なる場合、それは攻撃者が別サーバへ誘導することを意図した偽の応答が混入している可能性を意味する。
【００７３】
そこで本実施形態では、詳細を後述するように、問い合わせに対する時間Ｔにおける応答が１対１になることが攻撃防御装置１４の応答判定部１４６で確認されるまで、つまり正規の応答が得られるまで、当該管理部１４５が問い合わせ送信部１４２を用いて問い合わせのリトライを繰り返す構成を適用する。応答判定部１４６は、問い合わせに対する時間Ｔにおける応答が１対１となった時点で、その応答を正規応答として応答送信部１４７によりＤＮＳキャッシュサーバ１２転送させる。
【００７４】
このような構成により、ＤＮＳキャッシュサーバ１２は常に正規の応答情報をキャッシュすることになり、先に述べたＤＮＳプロトコルの脆弱性を狙った攻撃を未然に回避することが可能となる。
【００７５】
ここで、時間Ｔがあまり長い時間に設定されると、ＤＮＳキャッシュサーバ１２への転送が遅くなりＤＮＳ応答の遅延を招く。逆に時間Ｔが短い時間に設定されると、偽のＤＮＳ応答が正規と判断されてしまう可能性がある。そこで本実施形態では、時間Ｔを、ＤＮＳサーバ１１から過去に応答が得られた際の応答時間（例えば直近の応答時間）に基づいて決定する手法を適用している。そのため本実施形態では。ＤＮＳサーバから応答が得られた際の応答時間を、当該ＤＮＳサーバのＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂにより管理する。更に詳細に述べるならば、αを応答時間についての誤差を考慮した予め定められた余裕時間とすると、応答時間学習テーブル１４４ｂから取得される、ＤＮＳサーバ１１から応答が得られた際の直近の応答時間にαを加えた時間が、ＤＮＳサーバ１１からの応答パケットを待つ時間Ｔとして決定される。これにより、偽のＤＮＳ応答が正規と誤判断するのを防止しつつ、ＤＮＳ応答時間の低下を防止できる。しかも、時間ＴをＤＮＳサーバ毎に設定できることから、この効果は著しい。
【００７６】
以下、期間Ｔの間に受信された応答パケットが正規のものであるかを判定する手順について説明する。
応答受信部１４３は、問い合わせパケットＱＰの受信時刻から管理部１４５によって通知された時間Ｔが経過すると（ステップ７０５のＹｅｓ）、その旨を管理部１４５に通知する。すると管理部１４５は、応答判定部１４６に制御を渡す。
【００７７】
応答判定部１４６は、ドメイン・ＩＰアドレス管理テーブル１４４ａに登録されている、問い合わせパケットＱＰに対応するドメイン・ＩＰアドレス管理情報に基づいて、当該問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に受信された数をチェックする（ステップ８０１）。この数は、問い合わせパケットＱＰに対応するドメイン・ＩＰアドレス管理情報に設定されている応答ＩＰアドレス及び応答時間を示す情報の組の数に一致する。そして応答判定部１４６は、問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に受信された数から、問い合わせパケットＱＰと問い合わせパケットＱＰに対応する応答パケットとの組み合わせが１対１であるかを判定する（ステップ８０２）。 応答判定部１４６は、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１であるならば（ステップ８０２のＹｅｓ）、つまり問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に１つだけ受信されたならば、その時間Ｔの間に受信されたただ１つの問い合わせパケットＱＰに対応する応答パケットは正規応答パケットであるとみなす（ステップ８０３）。即ち応答判定部１４６は、ステップ８０２の判定がＹｅｓの場合、問い合わせパケットＱＰに対応するただ１つの応答パケットを正規応答パケットであると判定する。このただ１つの応答パケットが応答パケットＴＲＰであることは明らかである。
【００７８】
すると管理部１４５は、問い合わせパケットＱＰの送信先ＩＰアドレス（つまり問い合わせ先のＤＮＳサーバのＩＰアドレス）に対応付けて応答時間学習テーブル１４４ｂに登録されている応答時間情報を、正規応答パケットであると判定された応答パケットＴＲＰが返されるまでに要した最新の時間を示すように更新する（ステップ８０４）。これにより、問い合わせパケットＱＰに対して問い合わせ先のＤＮＳサーバ１１から応答パケットＴＲＰが返されるまでの応答時間が学習されたことになる、
次に管理部１４５は、正規応答パケットであると判定された応答パケットＴＲＰの送信を応答送信部１４７に要求する。すると応答送信部１４７は、応答パケットＴＲＰを、図６において矢印６０６で示すようにＤＮＳキャッシュサーバ１２に送信する（ステップ８０５）。ＤＮＳキャッシュサーバ１２は、この応答パケットＲＰによって通知されたドメイン名“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を、当該ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてキャッシュ１２０に登録する。またＤＮＳキャッシュサーバ１２は、ドメイン名“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を、クライアント端末１５からの問い合わせに対する応答として、図６において矢印６０７で示すよう当該にクライアント端末１５に返す。
【００７９】
これに対し、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１でないものとする（ステップ８０２のＮｏ）。つまり時間Ｔの間に問い合わせパケットＱＰに対応する複数の応答パケットが受信されたものとする。このような場合、応答判定部１４６は、時間Ｔの間に受信された複数の応答パケットに正規応答パケットが含まれているとしても、その正規応答パケットを特定することができない。そこで管理部１４５は、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１でないと応答判定部１４６によって判定された場合（ステップ８０２のＮｏ）、これらの応答パケットを偽応答パケットであると判定して破棄する（ステップ８０６）。
【００８０】
次に管理部１４５はリトライ回数テーブル１４４ｃから、問い合わせパケットＱＰに含まれている問い合わせドメイン名が設定されているリトライ回数情報を検索し、当該リトライ回数情報中のリトライ回数を１だけインクリメントする（ステップ８０７）。このとき管理部１４５は、リトライ回数情報中の最終登録日時情報を現在の日時を示すように更新する。
【００８１】
管理部１４５は、インクリメント後のリトライ回数が閾値を超えているかを判定する（ステップ８０８）。もし、超えていないならば（ステップ８０８のＮｏ）、管理部１４５は問い合わせ送信部１４２によって問い合わせパケットＱＰをＤＮＳサーバ１１に再度転送させる（ステップ７０３）。つまり管理部１４５は、問い合わせ送信部１４２を用いて、問い合わせのリトライを行う。
【００８２】
このように本実施形態においては、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１になるまで、予め定められたリトライ回数を超えない範囲で、ＤＮＳサーバ１１に当該問い合わせパケットＱＰをＤＮＳキャッシュサーバ１２に代わって転送する動作が繰り返される。
【００８３】
これに対し、インクリメント後のリトライ回数が閾値を超えているならば（ステップ８０８のＹｅｓ）、管理部１４５は、これ以上の問い合わせのリトライは無駄であると判断する。この場合、管理部１４５はＤＮＳキャッシュサーバ１２からの問い合わせパケットＱＰに対する応答として、応答送信部１４７によりＤＮＳキャッシュサーバ１２にエラーを示す応答パケットを送信させる（ステップ８０９）。そして管理部１４５は、問い合わせパケットＱＰが攻撃防御装置１４に入力された際の処理を終了する。
【００８４】
なお、エラーを示す応答パケットをＤＮＳキャッシュサーバ１２に返すことなく管理部１４５が処理を終了しても構わない。一般にＤＮＳキャッシュサーバ１２は、ＤＮＳサーバ１１宛ての問い合わせパケットＱＰを送信すると、その問い合わせパケットＱＰに対する応答を、ある一定時間待っている。この時間内に、応答が返らない場合、ＤＮＳキャッシュサーバ１２は問い合わせをリトライする。
【００８５】
さて本実施形態では、管理部１４５はリトライ回数テーブル１４４ｃを例えば定期的に参照し、問い合わせ回数が予め定められた値（以下、通知条件値と称する）を超えているドメイン名があるかを判定する。本実施形態において通知条件値は、１以上でかつ上記閾値以下の整数である。
【００８６】
管理部１４５は、問い合わせ回数が通知条件値を超えているドメイン名があるならば、予め登録されている管理者に対し例えば電子メールを用いて、当該ドメイン名が攻撃対象となっている旨（つまり当該ドメイン名に対応するＩＰアドレスを偽装する攻撃が行われている旨）を通知する。ここでは、リトライ回数テーブル１４４ｃに保持されている該当するリトライ回数情報、即ち攻撃対象となっているドメイン名、リトライ回数、初回登録日時情報及び最終登録日時が通知される。
【００８７】
一般的に管理者は、この種の攻撃を受けていることを検知しにくい。しかし本実施形態によれば、上述のような電子メールによる通知により、管理者はＤＮＳサーバ側が攻撃対象となっていることがわかり、対象ドメインにアクセスするユーザに注意喚起を促し、攻撃者に対する防御策を行うことができる。ここで、上述の閾値、通知条件値及び電子メールの通知先となる管理者の電子メールアドレスは、管理情報記憶部１４４に予め登録されている。
【００８８】
なお、通知条件値として上記閾値を用いるならば、ステップ８０８でリトライ回数が閾値を超えていると判定された際に、対応するドメイン名が攻撃対象となっている旨を通知すればよく、必ずしもリトライ回数テーブル１４４ｃを定期的に参照する必要はない。また、この通知に、ＳＮＭＰ（Simple Network Management Protocol）など、電子メール以外の電子的な通信手段を用いてもよい。
【００８９】
上記実施形態では、ドメイン・ＩＰアドレス管理テーブル１４４ａ、応答時間学習テーブル１４４ｂ及びリトライ回数テーブル１４４ｃが格納される管理情報記憶部１４４は、磁気ディスクドライブのような不揮発性の記憶装置である。このためテーブル１４４ａ〜１４４ｃに高速にアクセスすることは難しい。そこで、テーブル１４４ａ〜１４４ｃをＲＡＭのような高速の記憶装置に格納してもよい。この場合、電源遮断時にテーブル１４４ａ〜１４４ｃの内容が消失しないように、テーブル１４４ａ〜１４４ｃを適宜不揮発性の記憶装置に保存するとよい。なお、応答時間学習テーブル１４４ｂのみを不揮発性の記憶装置に保存する構成であっても構わない。
【００９０】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、攻撃防御装置１４が、ＤＮＳキャッシュサーバ１２と共に同一コンピュータによって実現される構成であってもよく、中継装置１８に設けられていても構わない。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【００９１】
１１…ＤＮＳサーバ、１２…ＤＮＳキャッシュサーバ、１３…ｗｗｗサーバ、１４…攻撃防御装置（ＤＮＳキャッシュ・ポイズニング攻撃防御装置）、１５…クライアント端末、１６…グローバルネットワーク、１７…ローカルエリアネットワーク、１８…中継装置、１４１…問い合わせ受信部、１４２…問い合わせ送信部、１４３…応答受信部、１４４…管理情報記憶部、１４４ａ…ドメイン・ＩＰアドレス管理テーブル、１４４ｂ…応答時間学習テーブル、１４４ｃ…リトライ回数テーブル、１４５…管理部、１４６…応答判定部、１４７…応答送信部。
【技術分野】
【０００１】
本発明は、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置に関する。
【背景技術】
【０００２】
一般に、インターネットのようなネットワーク環境では、“*.abcd.co.jp”などで表記されるドメイン名と、それに対応するＩＰアドレス（数字とドットで表記）が存在する。インターネット利用者がクライアント端末を利用して、当該クライアント端末からドメイン名が例えば“ｗｗｗ.abcd.co.jp”のサーバにアクセスしたい場合、当該ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを取得するために、次のような名前解決の手順が適用される。
【０００３】
（１）クライアント端末はドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスをＤＮＳキャッシュサーバに問い合わせる。このＩＰアドレスが問い合わせられるドメイン名を問い合わせドメイン名と呼ぶこともある。ＤＮＳキャッシュサーバは、以前にＤＮＳサーバから取得したドメイン名とＩＰアドレスとの対応関係を示す情報を保持するキャッシュを有している。
【０００４】
ＤＮＳ（Domain Name System）とは、ドメイン名とＩＰアドレスとを対応付けるためのプロトコルである。ＤＮＳでは、ルートサーバを親とするツリー構造（階層構造）でドメインの権限／委譲の関係で分散管理が行われる。ルートサーバは、例えば種々の*1〜*4の組み合わせからなる“*4.*3.*2.x1”（*1 = jp, kr, …）のような最上位の階層（第１階層）のドメインを自身が有するデータベースにより管理する第１のＤＮＳサーバである。
【０００５】
ＤＮＳキャッシュサーバとルートサーバ（第１のＤＮＳサーバ）との間には複数のＤＮＳサーバが存在する。これらの複数のサーバは複数の第２のＤＮＳサーバと、複数の第３のＤＮＳサーバと、複数の第４のＤＮＳサーバとを含む。
【０００６】
第２のＤＮＳサーバは、種々の*1のうち当該第２のＤＮＳサーバに固有のx１(x1はjp, kr, …のいずれか）と、種々の*2〜*4との組み合わせからなる、“*4.*3.*2.x1”のような第２階層のドメインを、自身が有するデータベースにより管理する。第３のＤＮＳサーバは、種々の*1，*2のうち当該第３のＤＮＳサーバに固有のx１，x2(x1はjp，kr…のいずれか、x2はco，ac…のいずれか）と、種々の*3，*4との組み合わせからなる、*4.*3.x2.x1”のような第３階層のドメインを、自身が有するデータベースにより管理する。第４のＤＮＳサーバは、種々の*1〜*3のうち当該第３のＤＮＳサーバに固有のx1〜x3(x1はjp，kr…のいずれか、x2はco，ac…のいずれか、x3はabcd,efgh…のいずれか）と、種々の*4との組み合わせからなる、*4.x3.x2.x1”のような第４階層のドメインを、自身が有するデータベースにより管理する。
【０００７】
（２）ＤＮＳキャッシュサーバは自身のキャッシュにドメイン名“ｗｗｗ.abcd.co.jp”とＩＰアドレスとの対応関係を示す情報が存在するならば、それをクライアント端末からの問い合わせに対する回答として当該クライアント端末に返す。これに対し、この情報が存在しないならば、ＤＮＳキャッシュサーバは“*4.abcd.co.jp”（x3=abcd, x2=co, x1=jp）のようなドメインを管理する第４のＤＮＳサーバに、ドメイン名“ｗｗｗ.abcd.co.jp”と対応付けられたＩＰアドレスを問い合わせる。
【０００８】
ＤＮＳキャッシュサーバから第４のＤＮＳサーバへの問い合わせ（クエリ）は、問い合わせのためのパケット（問い合わせパケット）を用いて行われる。問い合わせパケットはクエリパケットとも呼ばれ、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名（対応するＩＰアドレスに名前解決されるべきドメイン名）及び識別子（ＩＤ）を含む。送信先ＩＰアドレスには第４のＤＮＳサーバのＩＰアドレス（例えば、192.168.20.1）が用いられ、送信元ＩＰアドレスにはＤＮＳキャッシュサーバのＩＰアドレスが用いられる。ＩＤは問い合わせ（問い合わせパケット）を識別するための情報（ＩＤ情報）であり、ＤＮＳキャッシュサーバによって生成される。
【０００９】
（３）第４のＤＮＳサーバは、ＤＮＳキャッシュサーバからの問い合わせに応じて、ドメイン名“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレス、つまりドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバのＩＰアドレス（例えば、10.0.0.1）を含む応答のためのパケット（つまり応答パケット）を返す。この応答パケットは、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名、ＩＤ及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられたＩＰアドレス、つまり問い合わせに対する回答となるＩＰアドレス（以下、応答ＩＰアドレスと称する）を含む。
【００１０】
なお、第４のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理していない場合、当該第４のＤＮＳサーバから、*4.*3.co.jp”（x2=co, x1=jp）のようなドメインを管理する第３のＤＮＳサーバに、当該“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを問い合わせる。もし、第３のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理しているならば、そのＩＰアドレスを含む応答パケットを第４のＤＮＳサーバに返す。第４のＤＮＳサーバは、“ｗｗｗ.abcd.co.jp”と応答されたＩＰアドレスとの対応関係を示す情報を自身のデータベースに登録し、そのＩＰアドレスを含む応答パケットをＤＮＳキャッシュサーバに返す。これに対し、第３のＤＮＳサーバが“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを管理していない場合、当該第３のＤＮＳサーバから、*4.*3.*2.jp”（x1=jp）のようなドメインを管理する第２のＤＮＳサーバに、当該“ｗｗｗ.abcd.co.jp”と対応付けられているＩＰアドレスを問い合わせる。
【００１１】
このように、ドメイン名をＩＰアドレスに変換するための、いわゆる名前解決は、ルートサーバを含むツリー構造のＤＮＳサーバを下位の階層から辿ることにより実現されるのが一般的である。しかし、以降の説明では簡略化のために、第４のＤＮＳサーバによって名前解決が実現されるものとし、この第４のＤＮＳサーバを単にＤＮＳサーバと呼ぶ。
【００１２】
（４）ＤＮＳキャッシュサーバはＤＮＳサーバから返された応答パケットを受信すると、当該パケットに含まれている送信元ＩＰアドレス、ＩＤ及びドメイン名に基づき、当該応答パケットが正しいかを判定する。もし正しいならば、ＤＮＳキャッシュサーバは、応答パケットに含まれているＩＰアドレスを、クライアント端末からの問い合わせに対する回答として当該クライアント端末に転送する。これによりクライアント端末は、ＤＮＳキャッシュサーバから転送されたＩＰアドレス（10.0.0.1）を用いてドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバにアクセスできる。
【００１３】
しかし、上述のようなＤＮＳプロトコルの仕組みでは以下に述べるようなプロトコル上の欠陥が存在する。
まず、上記手順（４）で説明したように、ＤＮＳキャッシュサーバはＤＮＳサーバからの応答パケットが正しいかを判定するのに、
・送信元ＩＰアドレス（つまりＤＮＳサーバのＩＰアドレス）
・ＩＤ
・問い合わせドメイン名
という３つの要素を用いている。
【００１４】
ＤＮＳの通信はＵＤＰ（User Datagram Protocol）上で行われる。ＵＤＰはセッションレスなプロトコルであり、セッションという概念がない。つまりＵＤＰは、問い合わせ／応答の間に何ら紐付ける仕組みを用意していない。よって、ＤＮＳでは上述の３つの要素が応答パケットの正当性の判定に用いられる。この応答パケットの正当性を判定する要素が上述の３つに限られている点がＤＮＳのプロトコル上の欠陥として指摘されている。
【００１５】
この欠陥をどのように攻撃に結びつけるかについて、例を挙げて説明する。
ある攻撃者が、ドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスを本来の“10.0.0.1”ではなく、攻撃者が準備した偽のサイトのＩＰアドレス“200.1.1.1”にクライアント端末（インターネット利用者）を誘導しようと試みたとする。この場合、クライアント端末が問い合わせを行うＤＮＳキャッシュサーバがターゲットとされる。
【００１６】
攻撃者は、応答パケットを偽造してＤＮＳキャッシュサーバに送出する。この偽造された応答パケット（以下、偽応答パケットと称する）の送信先ＩＰアドレス、送信元ＩＰアドレス、ドメイン名、ＩＤ及び応答ＩＰアドレスは、
・送信先ＩＰアドレス：ＤＮＳキャッシュサーバのＩＰアドレス
・送信元ＩＰアドレス：192.168.20.1（ＤＮＳサーバのＩＰアドレス）
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＤ：123
・応答ＩＰアドレス：200.1.1.1
であるものとする。この偽応答パケットが、送信元ＩＰアドレスとして、ＤＮＳサーバのＩＰアドレスを偽っていることに注意する。
【００１７】
ＤＮＳキャッシュサーバからＤＮＳサーバ宛てに送出された問い合わせパケットに対して、当該ＤＮＳサーバからＤＮＳキャッシュサーバに対して上記手順（３）で正規の応答パケット（正規応答パケット）が返された場合、ＤＮＳキャッシュサーバには、
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＰアドレス：10.0.0.1
のような、ドメイン名とＩＰアドレスとの対応関係を示す情報が登録される。
【００１８】
しかし、偽応答パケットが正規応答パケットよりも先にＤＮＳキャッシュサーバに到達すると、ＤＮＳキャッシュサーバには、
・ドメイン名：ｗｗｗ.abcd.co.jp
・ＩＰアドレス：200.1.1.1（偽のサイトのＩＰアドレス）
のような情報が登録されてしまう。
【００１９】
すると、クライアント端末からのドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスの問い合わせに対して、ＤＮＳキャッシュサーバは偽のサイトのＩＰアドレス“200.1.1.1”を当該クライアント端末に回答する。この回答を受け取ったクライアント端末は偽のサイトに誘導されることになる。
【００２０】
以上の説明から明らかなように、上述の攻撃が成立するためには、
（ａ）以下の３つの要素
・送信元（上位のＤＮＳサーバ）のＩＰアドレス
・識別ＩＤ
・問い合わせドメイン名
が正規のＤＮＳ応答と同じであること
（ｂ）ある問い合わせに対し、ＤＮＳサーバが正規応答パケットを返す前に偽応答パケットがＤＮＳキャッシュサーバに到達する
という条件が必要である。
【００２１】
これらの条件のうち、送信元（上位のＤＮＳサーバ）のＩＰアドレス、問い合わせドメイン名は攻撃者のターゲットの情報であるため自ずと決まる。よって、攻撃者にとっては、ＩＤと偽応答パケットの到達タイミングさえ合えば攻撃を成立させることが可能とある。ＩＤは１６ビットの長さを持つ情報であるが、ＤＮＳサーバの種別により容易に推測可能と言われている。また、推測できなくても高々１６ビットの情報であれば、ランダムに送出し続けるだけで合致する確率は高いと言われている。偽応答パケットの到達タイミングについても、ＤＮＳキャッシュサーバにおける情報（ドメイン名とＩＰアドレスとの対応関係を示す情報）の保持期間（ＴＴＬ値）は数時間〜１日が一般的であり、偽応答パケットを大量に送出し続けていれば合致してしまう可能性はある。このような攻撃手法がＤＮＳキャッシュ・ポイズニングと呼ばれている。
【００２２】
例えば特許文献１は、このようなＤＮＳキャッシュ・ポイズニングに相当する攻撃を防御するための手法（以下、便宜的にＤＮＳキャッシュ・ポイズニング攻撃防御手法と称する）を開示している。この特許文献１に記載のＤＮＳキャッシュ・ポイズニング攻撃防御手法によれば、認証用サーバは、ＤＮＳサーバと同様にドメイン名とＩＰアドレスとの対応関係を示す情報を記憶する。この認証サーバは、端末からのドメイン名に対応するＩＰアドレスの問い合わせに対して、ＤＮＳサーバと同様に、ドメイン名に対応するＩＰアドレスを当該端末に応答する。ＩＰアドレスを問い合わせた端末は、ＤＮＳサーバ及び認証サーバの両サーバから応答されたＩＰアドレスを比較して、両者が一致していないならば、攻撃を受けているとして使用者に警告する
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開２００７−２０００４号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
しかしながら、特許文献１に記載されたＤＮＳキャッシュ・ポイズニング攻撃防御手法では、ＤＮＳサーバとは無関係の認証用サーバに、ＤＮＳサーバと同様にドメイン名とＩＰアドレスとの対応関係を示す情報を記憶する記憶部（ＩＰアドレス記憶部）を備える必要があり、認証用サーバの構成が複雑となる。しかも、ＩＰアドレスを問い合わせた端末が、ＤＮＳサーバ及び認証サーバの両サーバから応答されたＩＰアドレスを比較することによって、攻撃を受けているかを正しく判定するには、認証用サーバに、ＤＮＳサーバが記憶しているのと同一の情報を正しく記憶しなければならず、認証用サーバの管理が複雑となる。
【００２５】
本発明は上記事情を考慮してなされたものでその目的は、偽の情報をＤＮＳキャッシュサーバにキャッシュさせるＤＮＳキャッシュ・ポイズニング攻撃を簡単に防御することができる、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置を提供することにある。
【課題を解決するための手段】
【００２６】
本発明の１つの観点によれば、ＤＮＳサーバとＤＮＳキャッシュサーバとの間に配置された、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置が提供される。この装置は、前記ＤＮＳキャッシュサーバから送出されたドメイン名に対応するＩＰアドレスを問い合わせるための前記ＤＮＳサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、前記受信された問い合わせパケットを前記ＤＮＳキャッシュサーバに代わって前記ＤＮＳサーバに転送する問い合わせ送信手段と、前記問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、前記正規応答パケットであると判定された応答パケットを前記ＤＮＳキャッシュサーバに返す応答送信手段とを具備する。
【発明の効果】
【００２７】
本発明によれば、ＤＮＳの仕組み上、ドメイン名に対応するＩＰアドレスをＤＮＳキャッシュサーバからＤＮＳサーバに問い合わせるための問い合わせパケットに対して、当該ＤＮＳサーバから返される正規応答パケットは必ず１つであることに着目して、問い合わせパケットと当該問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定することにより、偽の情報をＤＮＳキャッシュサーバにキャッシュさせるＤＮＳキャッシュ・ポイズニング攻撃を簡単に防御することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明の一実施形態に係る攻撃防御装置を含むネットワークシステムの構成を示すブロック図。
【図２】攻撃防御装置の構成を示すブロック図。
【図３】ドメイン・ＩＰアドレス管理テーブルのデータ構造例を示す図。
【図４】応答時間学習テーブルのデータ構造例を示す図。
【図５】リトライ回数テーブルのデータ構造例を示す図。
【図６】同実施形態における情報の流れを示す図。
【図７】同実施形態における攻撃防御装置の処理手順を示すフローチャート。
【図８】同実施形態における攻撃防御装置の処理手順を示すフローチャート。
【図９】問い合わせパケットの一例を示す図。
【図１０】応答パケットの一例を示す図。
【発明を実施するための形態】
【００２９】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るＤＮＳキャッシュ・ポイズニング攻撃防御装置（以下、攻撃防御装置と略称する）を含むネットワークシステムの構成を示すブロック図である。
【００３０】
図１に示されるネットワークシステムは、ＤＮＳサーバ１１、ＤＮＳキャッシュサーバ１２、ｗｗｗサーバ１３、攻撃防御装置１４及びクライアント端末１５を備えている。ＤＮＳサーバ１１及びｗｗｗサーバ１３はＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）を適用するインターネットのようなグローバルネットワーク１６に、例えばローカルエリアネットワーク及び中継装置（いずれも図示せず）を介して接続されている。
【００３１】
一方、ＤＮＳキャッシュサーバ１２、攻撃防御装置１４及びクライアント端末１５は、ＴＣＰ／ＩＰを適用するローカルエリアネットワーク１７に接続されている。グローバルネットワーク１６とローカルエリアネットワーク１７とは中継装置１８及び攻撃防御装置１４を介して接続されている。
【００３２】
上述したようにグローバルネットワーク１６にはローカルエリアネットワーク及び中継装置を介してＤＮＳサーバ１１が接続され、ローカルエリアネットワーク１７にはＤＮＳキャッシュサーバ１２が接続されている。したがって、グローバルネットワーク１６とローカルエリアネットワーク１７とが中継装置１８及び攻撃防御装置１４を介して接続されることにより、当該攻撃防御装置１４は、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置されることになる。
【００３３】
図１に示されるネットワークシステムの例では、ｗｗｗサーバ及びクライアント端末は、それぞれｗｗｗサーバ１３及びクライアント端末１５だけである。しかし、ｗｗｗサーバ１３を含む複数のｗｗｗサーバと、クライアント端末１５を含む複数のクライアント端末が存在しても構わない。またローカルエリアネットワーク１７と同様の接続構成のネットワークがローカルエリアネットワーク１７とは別に存在しても構わない。
【００３４】
ＤＮＳサーバ１１は、ドメインを管理するＤＮＳサーバである。ＤＮＳサーバ１１は、例えばドメイン名が“ns1.abcd.co.jp”のＩＰアドレス“192.168.20.1”を持つ。ＤＮＳサーバ１１は、*4を“www”のような任意のホスト名であるとすると、“*4.abcd.co.jp”（x3=abcd, x2=co, x1=jp）で表現されるドメイン名とＩＰアドレスとの対応関係を示す情報を保持するデータベース（以下、ＩＰアドレス記憶部と称する）１１０を含む。
【００３５】
前述したようにＤＮＳでは、ルートサーバを親とするツリー構造でドメインの権限／委譲の関係で分散管理が行われ、ＤＮＳキャッシュサーバ１２とルートサーバとの間にはＤＮＳサーバ１１を含む複数のＤＮＳサーバが存在する。しかし、図１のネットワークシステムの例では、説明の簡略化のためにＤＮＳサーバ１１以外のＤＮＳサーバは省略されており、便宜的にＤＮＳサーバ１１のみで名前が解決（ドメイン名からＩＰアドレスへの変換）されるものとする。
【００３６】
ＤＮＳキャッシュサーバ１２は、例えばクライアント端末１５からのドメイン名に対応するＩＰアドレスの問い合わせに応じて、ＤＮＳサーバ１１から当該ドメイン名に対応するＩＰアドレスを取得した場合に、当該ドメイン名とＩＰアドレスとの対応関係を示す情報を一定期間保持するキャッシュ１２０を有する。この一定期間を示す値はＴＴＬ値と呼ばれる。このＴＴＬ値は、ＤＮＳキャッシュサーバ１２の設定に委ねられるものとする。ＤＮＳキャッシュサーバ１２は、プロバイダや企業内ネットワークなどに配置される。
【００３７】
ｗｗｗサーバ１３は、例えばドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を持つ。ｗｗｗサーバ１３は、クライアント端末からＩＰアドレス“10.0.0.1”を用いてアクセスされることにより、自身が保持している情報を当該クライアント端末に提供する。
【００３８】
攻撃防御装置１４は、前述したようにＤＮＳキャッシュサーバ１２とＤＮＳサーバ１１との間に配置される。これにより、ＤＮＳキャッシュサーバ１２からドメイン名に対応するＩＰアドレスを問い合わせるためのＤＮＳサーバ１１宛ての問い合わせパケットがローカルエリアネットワーク１７上に送出された場合に、当該問い合わせパケットは攻撃防御装置１４に入力される。
【００３９】
図２は攻撃防御装置１４の構成を示すブロック図である。攻撃防御装置１４は、問い合わせ受信部１４１、問い合わせ送信部１４２、応答受信部１４３、管理情報記憶部１４４、管理部１４５、応答判定部１４６及び応答送信部１４７を含む。
【００４０】
問い合わせ受信部１４１は、攻撃防御装置１４に入力される、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳサーバ１１宛ての問い合わせパケットを横取りして受信する。問い合わせ送信部１４２は、問い合わせ受信部１４１によって受信されたＤＮＳサーバ１１宛ての問い合わせパケットをＤＮＳキャッシュサーバ１２に代わって当該ＤＮＳサーバ１１に転送するために、中継装置１８を介してグローバルネットワーク１６に送信する。
【００４１】
応答受信部１４３は、ＤＮＳサーバ１１宛ての問い合わせパケットの転送に応じて、ある時間Ｔの間、当該問い合わせパケットに対応する応答パケットが攻撃防御装置１４に到達するのを待つ。応答受信部１４３は、この時間Ｔの間に攻撃防御装置１４に到達する応答パケットを全て受信する。
【００４２】
管理情報記憶部１４４はドメイン・ＩＰアドレス管理テーブル１４４ａ、応答時間学習テーブル１４４ｂ及びリトライ回数テーブル１４４ｃをそれぞれ格納するのに用いられる。管理情報記憶部１４４は例えばハードディスクドライブのような不揮発性の記憶装置を用いて実現されるものとする。
【００４３】
ドメイン・ＩＰアドレス管理テーブル１４４ａは、問い合わせ受信部１４１で受信される問い合わせパケット毎にドメイン・ＩＰアドレス管理情報を保持するエントリを有する。
【００４４】
図３は、ドメイン・ＩＰアドレス管理テーブル１４４ａのデータ構造例を示す。ドメイン・ＩＰアドレス管理テーブル１４４ａの各エントリ（に保持されるドメイン・ＩＰアドレス管理情報）は、ＩＤフィールド、問い合わせドメイン名フィールド、問い合わせ先ＩＰアドレスフィールド、問い合わせ時刻フィールド、応答ＩＰアドレスフィールド及び応答時間フィールドを有する。
【００４５】
ＩＤフィールド、問い合わせドメイン名フィールド及び問い合わせ先ＩＰアドレスフィールドは、それぞれ、対応する問い合わせパケットに設定されている、ＩＤ（識別子）、問い合わせドメイン名及び問い合わせ先のＤＮＳサーバのＩＰアドレス（つまり問い合わせ先ＩＰアドレス）を保持するのに用いられる。問い合わせ時刻フィールドは、問い合わせパケットを受信した時刻（以下、問い合わせ時刻と称する）を示す問い合わせ時刻情報を保持するのに用いられる。応答ＩＰアドレスフィールドは、問い合わせ先に問い合わせパケットを送信してから時間Ｔの間に応答受信部１４３によって受信された、当該問い合わせパケットとＩＤが同一の応答パケット（１つとは限らない）から得られたＩＰアドレス（以下、応答ＩＰアドレスと称する）を保持するのに用いられる。応答時間フィールドは、応答パケットが応答受信部１４３によって受信されるまでの問い合わせ時刻からの経過時間（つまり応答時間）を示す応答時間情報を保持するのに用いられる。応答ＩＰアドレスフィールド及び応答時間フィールドの組は、１エントリにつき１つとは限らない。
【００４６】
応答時間学習テーブル１４４ｂは、ＤＮＳサーバ毎に、当該ＤＮＳサーバへの問い合わせに対して当該ＤＮＳサーバから応答が返されるまでの最新の応答時間を示す情報を当該ＤＮＳサーバのＩＰアドレスに対応付けて保持するエントリを有する。この応答時間学習テーブル１４４ｂのデータ構造例を図４に示す。本実施形態では、応答時間学習テーブル１４４ｂにＤＮＳサーバ毎に保持される応答時間を示す情報の初期値として、対応するＤＮＳサーバに固有の予め定められた値が用いられる。
【００４７】
リトライ回数テーブル１４４ｃは、ドメイン名に対応するＩＰアドレスの問い合わせのリトライ回数を示すリトライ回数情報をドメイン名毎に保持するエントリを有する。リトライ回数情報の初期値は０である。
【００４８】
図５は、リトライ回数テーブル１４４ｃのデータ構造例を示す。リトライ回数テーブル１４４ｃの各エントリに保持されるリトライ回数情報は、ドメイン名、当該ドメイン名に対応するＩＰアドレスの問い合わせをリトライしたリトライ回数、初回登録日時を示す初回登録日時情報及び最終登録日時を示す最終登録日時情報を含む。
【００４９】
再び図１を参照すると、管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケット、当該問い合わせパケットの受信時刻、応答受信部１４３によって受信された当該問い合わせパケットに対応する応答パケット、及び当該応答パケットの受信時刻に基づいて、ドメイン・ＩＰアドレス管理テーブル１４４ａにドメイン・ＩＰアドレス管理情報を登録する。管理部１４５はまた、応答受信部１４３によって受信されたＤＮＳサーバからの応答パケットが正規応答パケットであると応答判定部１４６によって判定された場合に、その応答パケットが返されるまでの応答時間を示す情報を当該ＤＮＳサーバのＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂに登録する。管理部１４５は更に、リトライ回数情報のリトライ回数テーブル１４４ｃへの登録及びリトライ回数テーブル１４４ｃに登録されているリトライ回数情報の更新を行う。
【００５０】
応答判定部１４６は、ドメイン・ＩＰアドレス管理テーブル１４４ａに登録されているドメイン・ＩＰアドレス管理情報に基づいて、時間Ｔの間に正規応答パケットが受信されたかを判定する。応答送信部１４７は、正規応答パケットが受信されたと判定された場合、ＤＮＳキャッシュサーバ１２宛てに応答パケットを送信する。
【００５１】
次に、本実施形態における動作について、攻撃防御装置１４の動作を中心に図６乃至図８を参照して説明する。図６は情報の流れを示す図、図７及び図８は攻撃防御装置の処理手順を示すフローチャートである。
【００５２】
今、インターネット利用者がクライアント端末１５を操作することにより、当該クライアント端末１５からドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバ１３にアクセスしようとしているものとする。この場合、クライアント端末１５は、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを、図６において矢印６０１で示すようにＤＮＳキャッシュサーバ１２に問い合わせる。
【００５３】
ＤＮＳキャッシュサーバ１２は、クライアント端末１５からのドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスの問い合わせを受信する。するとＤＮＳキャッシュサーバ１２は、クライアント端末１５から問い合わせられたドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてＩＰアドレスがキャッシュ１２０に登録されているかを判定する。
【００５４】
ここでは、ＤＮＳキャッシュサーバ１２のキャッシュ１２０には、クライアント端末１５から問い合わせられたドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてＩＰアドレスが登録されていないものとする。この場合、ＤＮＳキャッシュサーバ１２は“ｗｗｗ.abcd.co.jp”に対応付けられたＩＰアドレスを取得するために、ＤＮＳサーバ１１宛ての問い合わせパケットＱＰを、図６において矢印６０２で示すように送出する。
【００５５】
図９は、ＤＮＳキャッシュサーバ１２から送出されたＤＮＳサーバ１１宛ての問い合わせパケットＱＰの一例を示す。図９に示される問い合わせパケットＱＰは、送信先ＩＰアドレスとしてＤＮＳサーバ１１のＩＰアドレス“192.168.20.1”を含み、送信元ＩＰアドレスとしてＤＮＳキャッシュサーバ１２のＩＰアドレスを含む。また、問い合わせパケットＱＰは、問い合わせドメイン名（名前解決されるべきドメイン名）としてｗｗｗサーバ１３のドメイン名“ｗｗｗ.abcd.co.jp”を含み、当該問い合わせパケットＱＰのＩＤとして“123”を含む。
【００５６】
ＤＮＳキャッシュサーバ１２によって送出されたＤＮＳサーバ１１宛ての問い合わせパケットＱＰは、ローカルエリアネットワーク１７を介して攻撃防御装置１４に入力される。すると攻撃防御装置１４の問い合わせ受信部１４１は、ＤＮＳキャッシュサーバ１２から送出された問い合わせパケットＱＰを受信する（ステップ７０１）。この問い合わせパケットＱＰの受信時刻が“09:10:00:00”（９時１０分００秒００）であるものとする。
【００５７】
管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケットＱＰ、及び当該問い合わせパケットの受信時刻に基づいて、ドメイン・ＩＰアドレス管理テーブル１４４ａのエントリにドメイン・ＩＰアドレス管理情報を登録する（ステップ７０２）。このステップ７０２で登録されるドメイン・ＩＰアドレス管理情報は、問い合わせパケットＱＰのＩＤ“123”、問い合わせドメイン名“ｗｗｗ.abcd.co.jp”、問い合わせ先ＩＰアドレス（ＤＮＳサーバ１１のＩＰアドレス）“192.168.20.1”、及び問い合わせパケットＱＰの受信時刻に一致する問い合わせ時刻“09:10:00:00”の情報を含む。このときドメイン・ＩＰアドレス管理情報の応答ＩＰアドレスフィールド及び応答時間フィールドは空欄となっている。
【００５８】
また、ステップＳ７０２において管理部１４５は、リトライ回数テーブル１４４ｃにリトライ回数情報を登録する。このリトライ回数情報は、ドメイン名及びリトライ回数として、それぞれ、問い合わせパケットＱＰに含まれている問い合わせドメイン名“ｗｗｗ.abcd.co.jp”及び初期値０を含む。リトライ回数情報は更に、現在の日時を示す初回登録日時情報を含む。このときリトライ回数情報の最終登録日時情報は有効な日時を示していない。なお、最終登録日時情報が現在の日時を示していてもよい。
【００５９】
管理部１４５は、問い合わせ受信部１４１によって受信された問い合わせパケットＱＰを問い合わせ送信部１４２に渡す。すると問い合わせ送信部１４２は、問い合わせパケットＱＰを、ＤＮＳキャッシュサーバ１２に代わって、図６において矢印６０３で示すようにＤＮＳサーバ１１に転送する（ステップ７０３）。
【００６０】
一方管理部１４５は、応答受信部１４３がＤＮＳサーバ１１からの応答パケットを待つ時間Ｔを決定して、決定した時間Ｔを応答受信部１４３に通知する（７０４）。この時間Ｔは、ＤＮＳサーバ１１のＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂに格納されている応答時間情報の示す応答時間に基づいて決定される。時間Ｔの詳細な決定手法については、後述する。
【００６１】
ＤＮＳサーバ１１は、攻撃防御装置１４の問い合わせ送信部１４２によって転送されたＤＮＳキャッシュサーバ１２からの問い合わせパケットＱＰを受信すると、当該問い合わせパケットＱＰに含まれている問い合わせドメイン名“ｗｗｗ.abcd.co.jp”に基づいてＩＰアドレス記憶部１１０を参照する。本実施形態ではＩＰアドレス記憶部１１０に、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてｗｗｗサーバ１３のＩＰアドレス“10.0.0.1”が登録されているものとする。この場合、ＤＮＳサーバ１１はＩＰアドレス記憶部１１０から、ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けられているＩＰアドレス“10.0.0.1”を取得する。つまりＤＮＳサーバ１１は、ＩＰアドレス記憶部１１０に基づいて、ドメイン名“ｗｗｗ.abcd.co.jp”をＩＰアドレス“10.0.0.1”に変換（名前解決）する。
【００６２】
するとＤＮＳサーバ１１は、ドメイン名が“ｗｗｗ.abcd.co.jp”のｗｗｗサーバのＩＰアドレス“10.0.0.1”を含むＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰを、図６において矢印６０４で示すように送信する。応答パケットＱＰは、送信先ＩＰアドレス、送信元ＩＰアドレス、問い合わせドメイン名、ＩＤ及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられている、名前解決されたＩＰアドレス（応答ＩＰアドレス）を含む。
【００６３】
図１０は、ＤＮＳサーバ１１から送信されたＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰの一例を示す。図１０に示される応答パケットＴＲＰは、送信先ＩＰアドレスとしてＤＮＳキャッシュサーバ１２のＩＰアドレスを含み、送信元ＩＰアドレスとしてＤＮＳサーバ１１のＩＰアドレス“192.168.20.1”を含む。また、応答パケットＴＲＰは、問い合わせドメイン名としてｗｗｗサーバ１３のドメイン名“ｗｗｗ.abcd.co.jp”を含み、ＩＤとして対応する問い合わせパケットＱＲのＩＤ“123”を含む。応答パケットＴＲＰは更に、応答ＩＰアドレスとしてｗｗｗサーバ１３のＩＰアドレス“10.0.0.1”を含む。
【００６４】
ＤＮＳサーバ１１から送信されたＤＮＳキャッシュサーバ１２宛ての応答パケットＴＲＰは、グローバルネットワーク１６及び中継装置１８を介して、ＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に配置された攻撃防御装置１４に到達する。応答受信部１４３は、この攻撃防御装置１４に到達した応答パケットＴＲＰを受信する。本実施形態において応答受信部１４３は、管理部１４５から時間Ｔが通知されると（ステップ７０４）、その時点から時間Ｔの間に攻撃防御装置１４に到達する当該ＤＮＳサーバ１１からの応答パケットを全て受信する（ステップ７０５〜７０７）。この時間Ｔの間に応答受信部１４３によって受信される応答パケットは、ＤＮＳサーバ１１からの正規応答パケットに限らない。例えば、送信元ＩＰアドレスをＤＮＳサーバ１１のＩＰアドレスに偽装した、つまり送信元をＤＮＳサーバ１１に偽装した攻撃者からの偽応答パケットも、時間Ｔの間に応答受信部１４３によって受信される可能性がある。
【００６５】
管理部１４５は、時間Ｔの間に、応答受信部１４３によって応答パケットが受信される都度（ステップ７０７）、ドメイン・ＩＰアドレス管理テーブル１４４ａから、受信応答パケットに含まれているＩＤ、問い合わせドメイン名及び送信元ＩＰアドレスが設定されたドメイン・ＩＰアドレス管理情報が登録されているエントリを検索する（ステップ７０８）。つまり管理部１４５は、受信応答パケットと対応している問い合わせパケットの内容を登録したエントリをエントリをドメイン・ＩＰアドレス管理テーブル１４４ａから検索する。
【００６６】
そして管理部１４５は、検索されたドエントリの応答ＩＰアドレスフィールド及び応答時間フィールドに、それぞれ、受信応答パケットに含まれている応答ＩＰアドレス及び応答時間を示す情報を設定する（ステップ７０９）。ここで、応答時間は、検索されたドエントリの問い合わせ時刻フィールドによって示される問い合わせ時刻と受信応答パケットの受信時刻とから（受信時刻−問い合わせ時刻）の演算によって算出される。
【００６７】
明らかなように、問い合わせパケットを受信した時点（問い合わせ時刻）から期間Ｔの間に、当該問い合わせパケットに対応する複数の応答パケットが受信された場合、受信された応答パケットの数だけ、応答ＩＰアドレス及び応答時間を示す情報の組が、検索されたドエントリに登録される。
【００６８】
ここで、例えば図６に示される攻撃者（の端末）６０が、ドメイン名が“ｗｗｗ.abcd.co.jp”のＩＰアドレスを本来の“10.0.0.1”ではなく、攻撃者６０が準備した偽のサイトのＩＰアドレス“200.1.1.1”にクライアント端末１５（インターネット利用者）を誘導しようと試みたとする。このような場合、攻撃者６０は、例えば図６において矢印６０５で示すように、ＤＮＳキャッシュサーバ１２宛ての多数の偽応答パケットＦＲＰを送信する。
【００６９】
各偽応答パケットＦＲＰの送信先ＩＰアドレス及び送信元ＩＰアドレスには、それぞれ、クライアント端末１５が問い合わせを行うＤＮＳキャッシュサーバ１２のＩＰアドレス及びＤＮＳサーバ１１のＩＰアドレスが用いられる。つまり各偽応答パケットＦＲＰは、送信元ＩＰアドレスとして、ＤＮＳサーバ１１のＩＰアドレスを偽装している。また、各偽応答パケットＦＲＰの問い合わせドメイン名及び応答ＩＰアドレスには、それぞれ、クライアント端末１５が必要としているＩＰアドレスのドメイン名“ｗｗｗ.abcd.co.jp”及び偽のサイトのＩＰアドレス“200.1.1.1”が用いられる。更に各偽応答パケットＦＲＰのＩＤには、攻撃者６０によって推測された、或いはランダムに生成される値が用いられる。
【００７０】
このような多数の偽応答パケットＦＲＰのいずれかに、問い合わせパケットＱＲのＩＤ“123”に一致するＩＤが用いられていて、且つ、その偽応答パケットＦＲＰが応答パケットＴＲＰ（つまり正規の応答パケット）よりも先にＤＮＳキャッシュサーバ１２に到達したならば、従来であれば、その偽応答パケットＦＲＰが正規応答パケットと誤って判定される。
【００７１】
本実施形態では、このような不具合を防止するために、上述のようにＤＮＳサーバ１１とＤＮＳキャッシュサーバ１２との間に攻撃防御装置１４が配置される。これによりＤＮＳキャッシュサーバ１２から送出されるＤＮＳサーバ１１宛ての問い合わせパケットは攻撃防御装置１４に入力され、問い合わせ受信部１４１で受信される（ステップ７０１）。管理部１４５は、この問い合わせパケットの内容を、当該問い合わせパケットのＩＤ毎に、つまり問い合わせドメイン名毎に、ドメイン・ＩＰアドレス管理テーブル１４４ａに格納する（ステップ７０２）。問い合わせ送信部１４２は、問い合わせ受信部１４１によって受信された問い合わせパケット、つまりＤＮＳキャッシュサーバ１２から送出された問い合わせパケットを宛先のＤＮＳサーバ１１に転送する（ステップ７０３）。
【００７２】
さて、ＤＮＳの仕組み上、ＤＮＳキャッシュサーバ１２からのＤＮＳサーバ１１に対する問い合わせに対し、当該ＤＮＳサーバ１１からは必ず１つの応答が返る。仮にＤＮＳサーバ１１に対する問い合わせに対し、時間Ｔの間に２つ以上の応答が返ってきた場合で、且つ、問い合わせドメイン名に対応するＩＰアドレス（応答ＩＰアドレス）がそれぞれ異なる場合、それは攻撃者が別サーバへ誘導することを意図した偽の応答が混入している可能性を意味する。
【００７３】
そこで本実施形態では、詳細を後述するように、問い合わせに対する時間Ｔにおける応答が１対１になることが攻撃防御装置１４の応答判定部１４６で確認されるまで、つまり正規の応答が得られるまで、当該管理部１４５が問い合わせ送信部１４２を用いて問い合わせのリトライを繰り返す構成を適用する。応答判定部１４６は、問い合わせに対する時間Ｔにおける応答が１対１となった時点で、その応答を正規応答として応答送信部１４７によりＤＮＳキャッシュサーバ１２転送させる。
【００７４】
このような構成により、ＤＮＳキャッシュサーバ１２は常に正規の応答情報をキャッシュすることになり、先に述べたＤＮＳプロトコルの脆弱性を狙った攻撃を未然に回避することが可能となる。
【００７５】
ここで、時間Ｔがあまり長い時間に設定されると、ＤＮＳキャッシュサーバ１２への転送が遅くなりＤＮＳ応答の遅延を招く。逆に時間Ｔが短い時間に設定されると、偽のＤＮＳ応答が正規と判断されてしまう可能性がある。そこで本実施形態では、時間Ｔを、ＤＮＳサーバ１１から過去に応答が得られた際の応答時間（例えば直近の応答時間）に基づいて決定する手法を適用している。そのため本実施形態では。ＤＮＳサーバから応答が得られた際の応答時間を、当該ＤＮＳサーバのＩＰアドレスに対応付けて応答時間学習テーブル１４４ｂにより管理する。更に詳細に述べるならば、αを応答時間についての誤差を考慮した予め定められた余裕時間とすると、応答時間学習テーブル１４４ｂから取得される、ＤＮＳサーバ１１から応答が得られた際の直近の応答時間にαを加えた時間が、ＤＮＳサーバ１１からの応答パケットを待つ時間Ｔとして決定される。これにより、偽のＤＮＳ応答が正規と誤判断するのを防止しつつ、ＤＮＳ応答時間の低下を防止できる。しかも、時間ＴをＤＮＳサーバ毎に設定できることから、この効果は著しい。
【００７６】
以下、期間Ｔの間に受信された応答パケットが正規のものであるかを判定する手順について説明する。
応答受信部１４３は、問い合わせパケットＱＰの受信時刻から管理部１４５によって通知された時間Ｔが経過すると（ステップ７０５のＹｅｓ）、その旨を管理部１４５に通知する。すると管理部１４５は、応答判定部１４６に制御を渡す。
【００７７】
応答判定部１４６は、ドメイン・ＩＰアドレス管理テーブル１４４ａに登録されている、問い合わせパケットＱＰに対応するドメイン・ＩＰアドレス管理情報に基づいて、当該問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に受信された数をチェックする（ステップ８０１）。この数は、問い合わせパケットＱＰに対応するドメイン・ＩＰアドレス管理情報に設定されている応答ＩＰアドレス及び応答時間を示す情報の組の数に一致する。そして応答判定部１４６は、問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に受信された数から、問い合わせパケットＱＰと問い合わせパケットＱＰに対応する応答パケットとの組み合わせが１対１であるかを判定する（ステップ８０２）。 応答判定部１４６は、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１であるならば（ステップ８０２のＹｅｓ）、つまり問い合わせパケットＱＰに対応する応答パケットが時間Ｔの間に１つだけ受信されたならば、その時間Ｔの間に受信されたただ１つの問い合わせパケットＱＰに対応する応答パケットは正規応答パケットであるとみなす（ステップ８０３）。即ち応答判定部１４６は、ステップ８０２の判定がＹｅｓの場合、問い合わせパケットＱＰに対応するただ１つの応答パケットを正規応答パケットであると判定する。このただ１つの応答パケットが応答パケットＴＲＰであることは明らかである。
【００７８】
すると管理部１４５は、問い合わせパケットＱＰの送信先ＩＰアドレス（つまり問い合わせ先のＤＮＳサーバのＩＰアドレス）に対応付けて応答時間学習テーブル１４４ｂに登録されている応答時間情報を、正規応答パケットであると判定された応答パケットＴＲＰが返されるまでに要した最新の時間を示すように更新する（ステップ８０４）。これにより、問い合わせパケットＱＰに対して問い合わせ先のＤＮＳサーバ１１から応答パケットＴＲＰが返されるまでの応答時間が学習されたことになる、
次に管理部１４５は、正規応答パケットであると判定された応答パケットＴＲＰの送信を応答送信部１４７に要求する。すると応答送信部１４７は、応答パケットＴＲＰを、図６において矢印６０６で示すようにＤＮＳキャッシュサーバ１２に送信する（ステップ８０５）。ＤＮＳキャッシュサーバ１２は、この応答パケットＲＰによって通知されたドメイン名“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を、当該ドメイン名“ｗｗｗ.abcd.co.jp”に対応付けてキャッシュ１２０に登録する。またＤＮＳキャッシュサーバ１２は、ドメイン名“ｗｗｗ.abcd.co.jp”のＩＰアドレス“10.0.0.1”を、クライアント端末１５からの問い合わせに対する応答として、図６において矢印６０７で示すよう当該にクライアント端末１５に返す。
【００７９】
これに対し、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１でないものとする（ステップ８０２のＮｏ）。つまり時間Ｔの間に問い合わせパケットＱＰに対応する複数の応答パケットが受信されたものとする。このような場合、応答判定部１４６は、時間Ｔの間に受信された複数の応答パケットに正規応答パケットが含まれているとしても、その正規応答パケットを特定することができない。そこで管理部１４５は、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１でないと応答判定部１４６によって判定された場合（ステップ８０２のＮｏ）、これらの応答パケットを偽応答パケットであると判定して破棄する（ステップ８０６）。
【００８０】
次に管理部１４５はリトライ回数テーブル１４４ｃから、問い合わせパケットＱＰに含まれている問い合わせドメイン名が設定されているリトライ回数情報を検索し、当該リトライ回数情報中のリトライ回数を１だけインクリメントする（ステップ８０７）。このとき管理部１４５は、リトライ回数情報中の最終登録日時情報を現在の日時を示すように更新する。
【００８１】
管理部１４５は、インクリメント後のリトライ回数が閾値を超えているかを判定する（ステップ８０８）。もし、超えていないならば（ステップ８０８のＮｏ）、管理部１４５は問い合わせ送信部１４２によって問い合わせパケットＱＰをＤＮＳサーバ１１に再度転送させる（ステップ７０３）。つまり管理部１４５は、問い合わせ送信部１４２を用いて、問い合わせのリトライを行う。
【００８２】
このように本実施形態においては、問い合わせパケットＱＰと対応する応答パケットとの組み合わせが１対１になるまで、予め定められたリトライ回数を超えない範囲で、ＤＮＳサーバ１１に当該問い合わせパケットＱＰをＤＮＳキャッシュサーバ１２に代わって転送する動作が繰り返される。
【００８３】
これに対し、インクリメント後のリトライ回数が閾値を超えているならば（ステップ８０８のＹｅｓ）、管理部１４５は、これ以上の問い合わせのリトライは無駄であると判断する。この場合、管理部１４５はＤＮＳキャッシュサーバ１２からの問い合わせパケットＱＰに対する応答として、応答送信部１４７によりＤＮＳキャッシュサーバ１２にエラーを示す応答パケットを送信させる（ステップ８０９）。そして管理部１４５は、問い合わせパケットＱＰが攻撃防御装置１４に入力された際の処理を終了する。
【００８４】
なお、エラーを示す応答パケットをＤＮＳキャッシュサーバ１２に返すことなく管理部１４５が処理を終了しても構わない。一般にＤＮＳキャッシュサーバ１２は、ＤＮＳサーバ１１宛ての問い合わせパケットＱＰを送信すると、その問い合わせパケットＱＰに対する応答を、ある一定時間待っている。この時間内に、応答が返らない場合、ＤＮＳキャッシュサーバ１２は問い合わせをリトライする。
【００８５】
さて本実施形態では、管理部１４５はリトライ回数テーブル１４４ｃを例えば定期的に参照し、問い合わせ回数が予め定められた値（以下、通知条件値と称する）を超えているドメイン名があるかを判定する。本実施形態において通知条件値は、１以上でかつ上記閾値以下の整数である。
【００８６】
管理部１４５は、問い合わせ回数が通知条件値を超えているドメイン名があるならば、予め登録されている管理者に対し例えば電子メールを用いて、当該ドメイン名が攻撃対象となっている旨（つまり当該ドメイン名に対応するＩＰアドレスを偽装する攻撃が行われている旨）を通知する。ここでは、リトライ回数テーブル１４４ｃに保持されている該当するリトライ回数情報、即ち攻撃対象となっているドメイン名、リトライ回数、初回登録日時情報及び最終登録日時が通知される。
【００８７】
一般的に管理者は、この種の攻撃を受けていることを検知しにくい。しかし本実施形態によれば、上述のような電子メールによる通知により、管理者はＤＮＳサーバ側が攻撃対象となっていることがわかり、対象ドメインにアクセスするユーザに注意喚起を促し、攻撃者に対する防御策を行うことができる。ここで、上述の閾値、通知条件値及び電子メールの通知先となる管理者の電子メールアドレスは、管理情報記憶部１４４に予め登録されている。
【００８８】
なお、通知条件値として上記閾値を用いるならば、ステップ８０８でリトライ回数が閾値を超えていると判定された際に、対応するドメイン名が攻撃対象となっている旨を通知すればよく、必ずしもリトライ回数テーブル１４４ｃを定期的に参照する必要はない。また、この通知に、ＳＮＭＰ（Simple Network Management Protocol）など、電子メール以外の電子的な通信手段を用いてもよい。
【００８９】
上記実施形態では、ドメイン・ＩＰアドレス管理テーブル１４４ａ、応答時間学習テーブル１４４ｂ及びリトライ回数テーブル１４４ｃが格納される管理情報記憶部１４４は、磁気ディスクドライブのような不揮発性の記憶装置である。このためテーブル１４４ａ〜１４４ｃに高速にアクセスすることは難しい。そこで、テーブル１４４ａ〜１４４ｃをＲＡＭのような高速の記憶装置に格納してもよい。この場合、電源遮断時にテーブル１４４ａ〜１４４ｃの内容が消失しないように、テーブル１４４ａ〜１４４ｃを適宜不揮発性の記憶装置に保存するとよい。なお、応答時間学習テーブル１４４ｂのみを不揮発性の記憶装置に保存する構成であっても構わない。
【００９０】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、攻撃防御装置１４が、ＤＮＳキャッシュサーバ１２と共に同一コンピュータによって実現される構成であってもよく、中継装置１８に設けられていても構わない。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【００９１】
１１…ＤＮＳサーバ、１２…ＤＮＳキャッシュサーバ、１３…ｗｗｗサーバ、１４…攻撃防御装置（ＤＮＳキャッシュ・ポイズニング攻撃防御装置）、１５…クライアント端末、１６…グローバルネットワーク、１７…ローカルエリアネットワーク、１８…中継装置、１４１…問い合わせ受信部、１４２…問い合わせ送信部、１４３…応答受信部、１４４…管理情報記憶部、１４４ａ…ドメイン・ＩＰアドレス管理テーブル、１４４ｂ…応答時間学習テーブル、１４４ｃ…リトライ回数テーブル、１４５…管理部、１４６…応答判定部、１４７…応答送信部。
【特許請求の範囲】
【請求項１】
ＤＮＳサーバとＤＮＳキャッシュサーバとの間に配置された、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置であって、
前記ＤＮＳキャッシュサーバから送出されたドメイン名に対応するＩＰアドレスを問い合わせるための前記ＤＮＳサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、
前記受信された問い合わせパケットを前記ＤＮＳキャッシュサーバに代わって前記ＤＮＳサーバに転送する問い合わせ送信手段と、
前記問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、
前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、
前記正規応答パケットであると判定された応答パケットを前記ＤＮＳキャッシュサーバに返す応答送信手段と
を具備することを特徴とするＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項２】
前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理する管理手段を更に具備し、
前記応答判定手段は前記管理手段によって管理される情報に基づいて、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったかを判定することを特徴とする請求項１記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項３】
前記管理手段は前記一定時間を更に管理し、前記問い合わせパケットによる前記ＤＮＳサーバへのＩＰアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットが正規応答パケットであると判定された場合、次に前記ＤＮＳサーバへのＩＰアドレスの問い合わせ時に用いられる前記一定時間を、当該応答パケットが返されるのに要した応答時間に基づいて変更することを特徴とする請求項２記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項４】
前記管理手段は前記問い合わせ送信手段による前記問い合わせパケットの転送のリトライを更に管理し、前記リトライを、予め定められた閾値の示すリトライ回数を超えない範囲で、前記問い合わせパケットと当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になるまで繰り返させることを特徴とする請求項２記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項５】
前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理するのに用いられる管理情報を登録する管理情報記憶手段を更に具備し、
前記問い合わせパケットは、当該問い合わせパケットを識別するための識別子、問い合わせに用いられる問い合わせドメイン名及び問い合わせ先のＤＮＳサーバのＩＰアドレスである問い合わせＩＰアドレスを含み、
前記応答パケットは、問い合わせドメイン名、当該問い合わせドメイン名に対応するＩＰアドレスである応答ＩＰアドレス、応答元を示す送信元ＩＰアドレス及び識別子を含み、
前記管理手段は、前記問い合わせ受信手段によって前記問い合わせパケットが受信された際に、当該問い合わせパケットに含まれている識別子、問い合わせドメイン名及び問い合わせＩＰアドレスを含む管理情報を前記管理情報記憶手段に登録し、前記問い合わせパケットによるＩＰアドレスの問い合わせ時から前記一定時間の間に前記応答受信手段によって応答パケットが受信された際に、当該応答パケットに含まれている識別子、問い合わせドメイン名及び送信元ＩＰアドレスにそれぞれ一致する識別子、問い合わせドメイン名及び問い合わせＩＰアドレスを含む管理情報を前記管理情報記憶手段から検索して、当該管理情報に当該応答パケットに含まれている応答ＩＰアドレスを追加設定する
ことを特徴とする請求項２乃至４のいずれかに記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項１】
ＤＮＳサーバとＤＮＳキャッシュサーバとの間に配置された、ＤＮＳキャッシュ・ポイズニング攻撃を防御する装置であって、
前記ＤＮＳキャッシュサーバから送出されたドメイン名に対応するＩＰアドレスを問い合わせるための前記ＤＮＳサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、
前記受信された問い合わせパケットを前記ＤＮＳキャッシュサーバに代わって前記ＤＮＳサーバに転送する問い合わせ送信手段と、
前記問い合わせパケットによるＩＰアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、
前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、
前記正規応答パケットであると判定された応答パケットを前記ＤＮＳキャッシュサーバに返す応答送信手段と
を具備することを特徴とするＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項２】
前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理する管理手段を更に具備し、
前記応答判定手段は前記管理手段によって管理される情報に基づいて、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になったかを判定することを特徴とする請求項１記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項３】
前記管理手段は前記一定時間を更に管理し、前記問い合わせパケットによる前記ＤＮＳサーバへのＩＰアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットが正規応答パケットであると判定された場合、次に前記ＤＮＳサーバへのＩＰアドレスの問い合わせ時に用いられる前記一定時間を、当該応答パケットが返されるのに要した応答時間に基づいて変更することを特徴とする請求項２記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項４】
前記管理手段は前記問い合わせ送信手段による前記問い合わせパケットの転送のリトライを更に管理し、前記リトライを、予め定められた閾値の示すリトライ回数を超えない範囲で、前記問い合わせパケットと当該問い合わせパケットに対応する応答パケットとの組み合わせが１対１になるまで繰り返させることを特徴とする請求項２記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【請求項５】
前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理するのに用いられる管理情報を登録する管理情報記憶手段を更に具備し、
前記問い合わせパケットは、当該問い合わせパケットを識別するための識別子、問い合わせに用いられる問い合わせドメイン名及び問い合わせ先のＤＮＳサーバのＩＰアドレスである問い合わせＩＰアドレスを含み、
前記応答パケットは、問い合わせドメイン名、当該問い合わせドメイン名に対応するＩＰアドレスである応答ＩＰアドレス、応答元を示す送信元ＩＰアドレス及び識別子を含み、
前記管理手段は、前記問い合わせ受信手段によって前記問い合わせパケットが受信された際に、当該問い合わせパケットに含まれている識別子、問い合わせドメイン名及び問い合わせＩＰアドレスを含む管理情報を前記管理情報記憶手段に登録し、前記問い合わせパケットによるＩＰアドレスの問い合わせ時から前記一定時間の間に前記応答受信手段によって応答パケットが受信された際に、当該応答パケットに含まれている識別子、問い合わせドメイン名及び送信元ＩＰアドレスにそれぞれ一致する識別子、問い合わせドメイン名及び問い合わせＩＰアドレスを含む管理情報を前記管理情報記憶手段から検索して、当該管理情報に当該応答パケットに含まれている応答ＩＰアドレスを追加設定する
ことを特徴とする請求項２乃至４のいずれかに記載のＤＮＳキャッシュ・ポイズニング攻撃を防御する装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−４９７４５（Ｐ２０１１−４９７４５Ａ）
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願番号】特願２００９−１９５４１５（Ｐ２００９−１９５４１５）
【出願日】平成２１年８月２６日（２００９．８．２６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願日】平成２１年８月２６日（２００９．８．２６）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]