JP2011049745A - Dnsキャッシュ・ポイズニング攻撃を防御する装置 - Google Patents
Dnsキャッシュ・ポイズニング攻撃を防御する装置 Download PDFInfo
- Publication number
- JP2011049745A JP2011049745A JP2009195415A JP2009195415A JP2011049745A JP 2011049745 A JP2011049745 A JP 2011049745A JP 2009195415 A JP2009195415 A JP 2009195415A JP 2009195415 A JP2009195415 A JP 2009195415A JP 2011049745 A JP2011049745 A JP 2011049745A
- Authority
- JP
- Japan
- Prior art keywords
- inquiry
- packet
- response
- address
- dns
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】DNSキャッシュ・ポイズニング攻撃を簡単に防御できるようにする。
【解決手段】攻撃防御装置14は、DNSサーバ11とDNSキャッシュサーバ12との間に配置される。問い合わせ受信部は、DNSキャッシュサーバ12から送出されたDNSキャッシュサーバ12宛ての問い合わせパケットを受信する。問い合わせ送信部は、この問い合わせパケットをDNSサーバ11に転送する。応答受信部は、問い合わせパケットによるIPアドレスの問い合わせ時から一定時間の間に攻撃防御装置14に到達した当該問い合わせパケットに対応する応答パケットを受信する。応答判定部は、問い合わせパケットと一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったことをもって、当該応答パケットを正規応答パケットであると判定する。
【選択図】 図1
【解決手段】攻撃防御装置14は、DNSサーバ11とDNSキャッシュサーバ12との間に配置される。問い合わせ受信部は、DNSキャッシュサーバ12から送出されたDNSキャッシュサーバ12宛ての問い合わせパケットを受信する。問い合わせ送信部は、この問い合わせパケットをDNSサーバ11に転送する。応答受信部は、問い合わせパケットによるIPアドレスの問い合わせ時から一定時間の間に攻撃防御装置14に到達した当該問い合わせパケットに対応する応答パケットを受信する。応答判定部は、問い合わせパケットと一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったことをもって、当該応答パケットを正規応答パケットであると判定する。
【選択図】 図1
Description
本発明は、DNSキャッシュ・ポイズニング攻撃を防御する装置に関する。
一般に、インターネットのようなネットワーク環境では、“*.abcd.co.jp”などで表記されるドメイン名と、それに対応するIPアドレス(数字とドットで表記)が存在する。インターネット利用者がクライアント端末を利用して、当該クライアント端末からドメイン名が例えば“www.abcd.co.jp”のサーバにアクセスしたい場合、当該ドメイン名“www.abcd.co.jp”に対応付けられたIPアドレスを取得するために、次のような名前解決の手順が適用される。
(1)クライアント端末はドメイン名“www.abcd.co.jp”に対応付けられたIPアドレスをDNSキャッシュサーバに問い合わせる。このIPアドレスが問い合わせられるドメイン名を問い合わせドメイン名と呼ぶこともある。DNSキャッシュサーバは、以前にDNSサーバから取得したドメイン名とIPアドレスとの対応関係を示す情報を保持するキャッシュを有している。
DNS(Domain Name System)とは、ドメイン名とIPアドレスとを対応付けるためのプロトコルである。DNSでは、ルートサーバを親とするツリー構造(階層構造)でドメインの権限/委譲の関係で分散管理が行われる。ルートサーバは、例えば種々の*1〜*4の組み合わせからなる“*4.*3.*2.x1”(*1 = jp, kr, …)のような最上位の階層(第1階層)のドメインを自身が有するデータベースにより管理する第1のDNSサーバである。
DNSキャッシュサーバとルートサーバ(第1のDNSサーバ)との間には複数のDNSサーバが存在する。これらの複数のサーバは複数の第2のDNSサーバと、複数の第3のDNSサーバと、複数の第4のDNSサーバとを含む。
第2のDNSサーバは、種々の*1のうち当該第2のDNSサーバに固有のx1(x1はjp, kr, …のいずれか)と、種々の*2〜*4との組み合わせからなる、“*4.*3.*2.x1”のような第2階層のドメインを、自身が有するデータベースにより管理する。第3のDNSサーバは、種々の*1,*2のうち当該第3のDNSサーバに固有のx1,x2(x1はjp,kr…のいずれか、x2はco,ac…のいずれか)と、種々の*3,*4との組み合わせからなる、*4.*3.x2.x1”のような第3階層のドメインを、自身が有するデータベースにより管理する。第4のDNSサーバは、種々の*1〜*3のうち当該第3のDNSサーバに固有のx1〜x3(x1はjp,kr…のいずれか、x2はco,ac…のいずれか、x3はabcd,efgh…のいずれか)と、種々の*4との組み合わせからなる、*4.x3.x2.x1”のような第4階層のドメインを、自身が有するデータベースにより管理する。
(2)DNSキャッシュサーバは自身のキャッシュにドメイン名“www.abcd.co.jp”とIPアドレスとの対応関係を示す情報が存在するならば、それをクライアント端末からの問い合わせに対する回答として当該クライアント端末に返す。これに対し、この情報が存在しないならば、DNSキャッシュサーバは“*4.abcd.co.jp”(x3=abcd, x2=co, x1=jp)のようなドメインを管理する第4のDNSサーバに、ドメイン名“www.abcd.co.jp”と対応付けられたIPアドレスを問い合わせる。
DNSキャッシュサーバから第4のDNSサーバへの問い合わせ(クエリ)は、問い合わせのためのパケット(問い合わせパケット)を用いて行われる。問い合わせパケットはクエリパケットとも呼ばれ、送信先IPアドレス、送信元IPアドレス、問い合わせドメイン名(対応するIPアドレスに名前解決されるべきドメイン名)及び識別子(ID)を含む。送信先IPアドレスには第4のDNSサーバのIPアドレス(例えば、192.168.20.1)が用いられ、送信元IPアドレスにはDNSキャッシュサーバのIPアドレスが用いられる。IDは問い合わせ(問い合わせパケット)を識別するための情報(ID情報)であり、DNSキャッシュサーバによって生成される。
(3)第4のDNSサーバは、DNSキャッシュサーバからの問い合わせに応じて、ドメイン名“www.abcd.co.jp”と対応付けられているIPアドレス、つまりドメイン名が“www.abcd.co.jp”のwwwサーバのIPアドレス(例えば、10.0.0.1)を含む応答のためのパケット(つまり応答パケット)を返す。この応答パケットは、送信先IPアドレス、送信元IPアドレス、問い合わせドメイン名、ID及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられたIPアドレス、つまり問い合わせに対する回答となるIPアドレス(以下、応答IPアドレスと称する)を含む。
なお、第4のDNSサーバが“www.abcd.co.jp”と対応付けられているIPアドレスを管理していない場合、当該第4のDNSサーバから、*4.*3.co.jp”(x2=co, x1=jp)のようなドメインを管理する第3のDNSサーバに、当該“www.abcd.co.jp”と対応付けられているIPアドレスを問い合わせる。もし、第3のDNSサーバが“www.abcd.co.jp”と対応付けられているIPアドレスを管理しているならば、そのIPアドレスを含む応答パケットを第4のDNSサーバに返す。第4のDNSサーバは、“www.abcd.co.jp”と応答されたIPアドレスとの対応関係を示す情報を自身のデータベースに登録し、そのIPアドレスを含む応答パケットをDNSキャッシュサーバに返す。これに対し、第3のDNSサーバが“www.abcd.co.jp”と対応付けられているIPアドレスを管理していない場合、当該第3のDNSサーバから、*4.*3.*2.jp”(x1=jp)のようなドメインを管理する第2のDNSサーバに、当該“www.abcd.co.jp”と対応付けられているIPアドレスを問い合わせる。
このように、ドメイン名をIPアドレスに変換するための、いわゆる名前解決は、ルートサーバを含むツリー構造のDNSサーバを下位の階層から辿ることにより実現されるのが一般的である。しかし、以降の説明では簡略化のために、第4のDNSサーバによって名前解決が実現されるものとし、この第4のDNSサーバを単にDNSサーバと呼ぶ。
(4)DNSキャッシュサーバはDNSサーバから返された応答パケットを受信すると、当該パケットに含まれている送信元IPアドレス、ID及びドメイン名に基づき、当該応答パケットが正しいかを判定する。もし正しいならば、DNSキャッシュサーバは、応答パケットに含まれているIPアドレスを、クライアント端末からの問い合わせに対する回答として当該クライアント端末に転送する。これによりクライアント端末は、DNSキャッシュサーバから転送されたIPアドレス(10.0.0.1)を用いてドメイン名が“www.abcd.co.jp”のwwwサーバにアクセスできる。
しかし、上述のようなDNSプロトコルの仕組みでは以下に述べるようなプロトコル上の欠陥が存在する。
まず、上記手順(4)で説明したように、DNSキャッシュサーバはDNSサーバからの応答パケットが正しいかを判定するのに、
・送信元IPアドレス(つまりDNSサーバのIPアドレス)
・ID
・問い合わせドメイン名
という3つの要素を用いている。
まず、上記手順(4)で説明したように、DNSキャッシュサーバはDNSサーバからの応答パケットが正しいかを判定するのに、
・送信元IPアドレス(つまりDNSサーバのIPアドレス)
・ID
・問い合わせドメイン名
という3つの要素を用いている。
DNSの通信はUDP(User Datagram Protocol)上で行われる。UDPはセッションレスなプロトコルであり、セッションという概念がない。つまりUDPは、問い合わせ/応答の間に何ら紐付ける仕組みを用意していない。よって、DNSでは上述の3つの要素が応答パケットの正当性の判定に用いられる。この応答パケットの正当性を判定する要素が上述の3つに限られている点がDNSのプロトコル上の欠陥として指摘されている。
この欠陥をどのように攻撃に結びつけるかについて、例を挙げて説明する。
ある攻撃者が、ドメイン名が“www.abcd.co.jp”のIPアドレスを本来の“10.0.0.1”ではなく、攻撃者が準備した偽のサイトのIPアドレス“200.1.1.1”にクライアント端末(インターネット利用者)を誘導しようと試みたとする。この場合、クライアント端末が問い合わせを行うDNSキャッシュサーバがターゲットとされる。
ある攻撃者が、ドメイン名が“www.abcd.co.jp”のIPアドレスを本来の“10.0.0.1”ではなく、攻撃者が準備した偽のサイトのIPアドレス“200.1.1.1”にクライアント端末(インターネット利用者)を誘導しようと試みたとする。この場合、クライアント端末が問い合わせを行うDNSキャッシュサーバがターゲットとされる。
攻撃者は、応答パケットを偽造してDNSキャッシュサーバに送出する。この偽造された応答パケット(以下、偽応答パケットと称する)の送信先IPアドレス、送信元IPアドレス、ドメイン名、ID及び応答IPアドレスは、
・送信先IPアドレス:DNSキャッシュサーバのIPアドレス
・送信元IPアドレス:192.168.20.1(DNSサーバのIPアドレス)
・ドメイン名:www.abcd.co.jp
・ID:123
・応答IPアドレス:200.1.1.1
であるものとする。この偽応答パケットが、送信元IPアドレスとして、DNSサーバのIPアドレスを偽っていることに注意する。
・送信先IPアドレス:DNSキャッシュサーバのIPアドレス
・送信元IPアドレス:192.168.20.1(DNSサーバのIPアドレス)
・ドメイン名:www.abcd.co.jp
・ID:123
・応答IPアドレス:200.1.1.1
であるものとする。この偽応答パケットが、送信元IPアドレスとして、DNSサーバのIPアドレスを偽っていることに注意する。
DNSキャッシュサーバからDNSサーバ宛てに送出された問い合わせパケットに対して、当該DNSサーバからDNSキャッシュサーバに対して上記手順(3)で正規の応答パケット(正規応答パケット)が返された場合、DNSキャッシュサーバには、
・ドメイン名:www.abcd.co.jp
・IPアドレス:10.0.0.1
のような、ドメイン名とIPアドレスとの対応関係を示す情報が登録される。
・ドメイン名:www.abcd.co.jp
・IPアドレス:10.0.0.1
のような、ドメイン名とIPアドレスとの対応関係を示す情報が登録される。
しかし、偽応答パケットが正規応答パケットよりも先にDNSキャッシュサーバに到達すると、DNSキャッシュサーバには、
・ドメイン名:www.abcd.co.jp
・IPアドレス:200.1.1.1(偽のサイトのIPアドレス)
のような情報が登録されてしまう。
・ドメイン名:www.abcd.co.jp
・IPアドレス:200.1.1.1(偽のサイトのIPアドレス)
のような情報が登録されてしまう。
すると、クライアント端末からのドメイン名が“www.abcd.co.jp”のIPアドレスの問い合わせに対して、DNSキャッシュサーバは偽のサイトのIPアドレス“200.1.1.1”を当該クライアント端末に回答する。この回答を受け取ったクライアント端末は偽のサイトに誘導されることになる。
以上の説明から明らかなように、上述の攻撃が成立するためには、
(a)以下の3つの要素
・送信元(上位のDNSサーバ)のIPアドレス
・識別ID
・問い合わせドメイン名
が正規のDNS応答と同じであること
(b)ある問い合わせに対し、DNSサーバが正規応答パケットを返す前に偽応答パケットがDNSキャッシュサーバに到達する
という条件が必要である。
(a)以下の3つの要素
・送信元(上位のDNSサーバ)のIPアドレス
・識別ID
・問い合わせドメイン名
が正規のDNS応答と同じであること
(b)ある問い合わせに対し、DNSサーバが正規応答パケットを返す前に偽応答パケットがDNSキャッシュサーバに到達する
という条件が必要である。
これらの条件のうち、送信元(上位のDNSサーバ)のIPアドレス、問い合わせドメイン名は攻撃者のターゲットの情報であるため自ずと決まる。よって、攻撃者にとっては、IDと偽応答パケットの到達タイミングさえ合えば攻撃を成立させることが可能とある。IDは16ビットの長さを持つ情報であるが、DNSサーバの種別により容易に推測可能と言われている。また、推測できなくても高々16ビットの情報であれば、ランダムに送出し続けるだけで合致する確率は高いと言われている。偽応答パケットの到達タイミングについても、DNSキャッシュサーバにおける情報(ドメイン名とIPアドレスとの対応関係を示す情報)の保持期間(TTL値)は数時間〜1日が一般的であり、偽応答パケットを大量に送出し続けていれば合致してしまう可能性はある。このような攻撃手法がDNSキャッシュ・ポイズニングと呼ばれている。
例えば特許文献1は、このようなDNSキャッシュ・ポイズニングに相当する攻撃を防御するための手法(以下、便宜的にDNSキャッシュ・ポイズニング攻撃防御手法と称する)を開示している。この特許文献1に記載のDNSキャッシュ・ポイズニング攻撃防御手法によれば、認証用サーバは、DNSサーバと同様にドメイン名とIPアドレスとの対応関係を示す情報を記憶する。この認証サーバは、端末からのドメイン名に対応するIPアドレスの問い合わせに対して、DNSサーバと同様に、ドメイン名に対応するIPアドレスを当該端末に応答する。IPアドレスを問い合わせた端末は、DNSサーバ及び認証サーバの両サーバから応答されたIPアドレスを比較して、両者が一致していないならば、攻撃を受けているとして使用者に警告する
しかしながら、特許文献1に記載されたDNSキャッシュ・ポイズニング攻撃防御手法では、DNSサーバとは無関係の認証用サーバに、DNSサーバと同様にドメイン名とIPアドレスとの対応関係を示す情報を記憶する記憶部(IPアドレス記憶部)を備える必要があり、認証用サーバの構成が複雑となる。しかも、IPアドレスを問い合わせた端末が、DNSサーバ及び認証サーバの両サーバから応答されたIPアドレスを比較することによって、攻撃を受けているかを正しく判定するには、認証用サーバに、DNSサーバが記憶しているのと同一の情報を正しく記憶しなければならず、認証用サーバの管理が複雑となる。
本発明は上記事情を考慮してなされたものでその目的は、偽の情報をDNSキャッシュサーバにキャッシュさせるDNSキャッシュ・ポイズニング攻撃を簡単に防御することができる、DNSキャッシュ・ポイズニング攻撃を防御する装置を提供することにある。
本発明の1つの観点によれば、DNSサーバとDNSキャッシュサーバとの間に配置された、DNSキャッシュ・ポイズニング攻撃を防御する装置が提供される。この装置は、前記DNSキャッシュサーバから送出されたドメイン名に対応するIPアドレスを問い合わせるための前記DNSサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、前記受信された問い合わせパケットを前記DNSキャッシュサーバに代わって前記DNSサーバに転送する問い合わせ送信手段と、前記問い合わせパケットによるIPアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、前記正規応答パケットであると判定された応答パケットを前記DNSキャッシュサーバに返す応答送信手段とを具備する。
本発明によれば、DNSの仕組み上、ドメイン名に対応するIPアドレスをDNSキャッシュサーバからDNSサーバに問い合わせるための問い合わせパケットに対して、当該DNSサーバから返される正規応答パケットは必ず1つであることに着目して、問い合わせパケットと当該問い合わせパケットによるIPアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったことをもって、当該応答パケットを正規応答パケットであると判定することにより、偽の情報をDNSキャッシュサーバにキャッシュさせるDNSキャッシュ・ポイズニング攻撃を簡単に防御することができる。
以下、本発明の実施の形態につき図面を参照して説明する。
図1は本発明の一実施形態に係るDNSキャッシュ・ポイズニング攻撃防御装置(以下、攻撃防御装置と略称する)を含むネットワークシステムの構成を示すブロック図である。
図1は本発明の一実施形態に係るDNSキャッシュ・ポイズニング攻撃防御装置(以下、攻撃防御装置と略称する)を含むネットワークシステムの構成を示すブロック図である。
図1に示されるネットワークシステムは、DNSサーバ11、DNSキャッシュサーバ12、wwwサーバ13、攻撃防御装置14及びクライアント端末15を備えている。DNSサーバ11及びwwwサーバ13はTCP(Transmission Control Protocol)/IP(Internet Protocol)を適用するインターネットのようなグローバルネットワーク16に、例えばローカルエリアネットワーク及び中継装置(いずれも図示せず)を介して接続されている。
一方、DNSキャッシュサーバ12、攻撃防御装置14及びクライアント端末15は、TCP/IPを適用するローカルエリアネットワーク17に接続されている。グローバルネットワーク16とローカルエリアネットワーク17とは中継装置18及び攻撃防御装置14を介して接続されている。
上述したようにグローバルネットワーク16にはローカルエリアネットワーク及び中継装置を介してDNSサーバ11が接続され、ローカルエリアネットワーク17にはDNSキャッシュサーバ12が接続されている。したがって、グローバルネットワーク16とローカルエリアネットワーク17とが中継装置18及び攻撃防御装置14を介して接続されることにより、当該攻撃防御装置14は、DNSサーバ11とDNSキャッシュサーバ12との間に配置されることになる。
図1に示されるネットワークシステムの例では、wwwサーバ及びクライアント端末は、それぞれwwwサーバ13及びクライアント端末15だけである。しかし、wwwサーバ13を含む複数のwwwサーバと、クライアント端末15を含む複数のクライアント端末が存在しても構わない。またローカルエリアネットワーク17と同様の接続構成のネットワークがローカルエリアネットワーク17とは別に存在しても構わない。
DNSサーバ11は、ドメインを管理するDNSサーバである。DNSサーバ11は、例えばドメイン名が“ns1.abcd.co.jp”のIPアドレス“192.168.20.1”を持つ。DNSサーバ11は、*4を“www”のような任意のホスト名であるとすると、“*4.abcd.co.jp”(x3=abcd, x2=co, x1=jp)で表現されるドメイン名とIPアドレスとの対応関係を示す情報を保持するデータベース(以下、IPアドレス記憶部と称する)110を含む。
前述したようにDNSでは、ルートサーバを親とするツリー構造でドメインの権限/委譲の関係で分散管理が行われ、DNSキャッシュサーバ12とルートサーバとの間にはDNSサーバ11を含む複数のDNSサーバが存在する。しかし、図1のネットワークシステムの例では、説明の簡略化のためにDNSサーバ11以外のDNSサーバは省略されており、便宜的にDNSサーバ11のみで名前が解決(ドメイン名からIPアドレスへの変換)されるものとする。
DNSキャッシュサーバ12は、例えばクライアント端末15からのドメイン名に対応するIPアドレスの問い合わせに応じて、DNSサーバ11から当該ドメイン名に対応するIPアドレスを取得した場合に、当該ドメイン名とIPアドレスとの対応関係を示す情報を一定期間保持するキャッシュ120を有する。この一定期間を示す値はTTL値と呼ばれる。このTTL値は、DNSキャッシュサーバ12の設定に委ねられるものとする。DNSキャッシュサーバ12は、プロバイダや企業内ネットワークなどに配置される。
wwwサーバ13は、例えばドメイン名が“www.abcd.co.jp”のIPアドレス“10.0.0.1”を持つ。wwwサーバ13は、クライアント端末からIPアドレス“10.0.0.1”を用いてアクセスされることにより、自身が保持している情報を当該クライアント端末に提供する。
攻撃防御装置14は、前述したようにDNSキャッシュサーバ12とDNSサーバ11との間に配置される。これにより、DNSキャッシュサーバ12からドメイン名に対応するIPアドレスを問い合わせるためのDNSサーバ11宛ての問い合わせパケットがローカルエリアネットワーク17上に送出された場合に、当該問い合わせパケットは攻撃防御装置14に入力される。
図2は攻撃防御装置14の構成を示すブロック図である。攻撃防御装置14は、問い合わせ受信部141、問い合わせ送信部142、応答受信部143、管理情報記憶部144、管理部145、応答判定部146及び応答送信部147を含む。
問い合わせ受信部141は、攻撃防御装置14に入力される、DNSキャッシュサーバ12から送出されたDNSサーバ11宛ての問い合わせパケットを横取りして受信する。問い合わせ送信部142は、問い合わせ受信部141によって受信されたDNSサーバ11宛ての問い合わせパケットをDNSキャッシュサーバ12に代わって当該DNSサーバ11に転送するために、中継装置18を介してグローバルネットワーク16に送信する。
応答受信部143は、DNSサーバ11宛ての問い合わせパケットの転送に応じて、ある時間Tの間、当該問い合わせパケットに対応する応答パケットが攻撃防御装置14に到達するのを待つ。応答受信部143は、この時間Tの間に攻撃防御装置14に到達する応答パケットを全て受信する。
管理情報記憶部144はドメイン・IPアドレス管理テーブル144a、応答時間学習テーブル144b及びリトライ回数テーブル144cをそれぞれ格納するのに用いられる。管理情報記憶部144は例えばハードディスクドライブのような不揮発性の記憶装置を用いて実現されるものとする。
ドメイン・IPアドレス管理テーブル144aは、問い合わせ受信部141で受信される問い合わせパケット毎にドメイン・IPアドレス管理情報を保持するエントリを有する。
図3は、ドメイン・IPアドレス管理テーブル144aのデータ構造例を示す。ドメイン・IPアドレス管理テーブル144aの各エントリ(に保持されるドメイン・IPアドレス管理情報)は、IDフィールド、問い合わせドメイン名フィールド、問い合わせ先IPアドレスフィールド、問い合わせ時刻フィールド、応答IPアドレスフィールド及び応答時間フィールドを有する。
IDフィールド、問い合わせドメイン名フィールド及び問い合わせ先IPアドレスフィールドは、それぞれ、対応する問い合わせパケットに設定されている、ID(識別子)、問い合わせドメイン名及び問い合わせ先のDNSサーバのIPアドレス(つまり問い合わせ先IPアドレス)を保持するのに用いられる。問い合わせ時刻フィールドは、問い合わせパケットを受信した時刻(以下、問い合わせ時刻と称する)を示す問い合わせ時刻情報を保持するのに用いられる。応答IPアドレスフィールドは、問い合わせ先に問い合わせパケットを送信してから時間Tの間に応答受信部143によって受信された、当該問い合わせパケットとIDが同一の応答パケット(1つとは限らない)から得られたIPアドレス(以下、応答IPアドレスと称する)を保持するのに用いられる。応答時間フィールドは、応答パケットが応答受信部143によって受信されるまでの問い合わせ時刻からの経過時間(つまり応答時間)を示す応答時間情報を保持するのに用いられる。応答IPアドレスフィールド及び応答時間フィールドの組は、1エントリにつき1つとは限らない。
応答時間学習テーブル144bは、DNSサーバ毎に、当該DNSサーバへの問い合わせに対して当該DNSサーバから応答が返されるまでの最新の応答時間を示す情報を当該DNSサーバのIPアドレスに対応付けて保持するエントリを有する。この応答時間学習テーブル144bのデータ構造例を図4に示す。本実施形態では、応答時間学習テーブル144bにDNSサーバ毎に保持される応答時間を示す情報の初期値として、対応するDNSサーバに固有の予め定められた値が用いられる。
リトライ回数テーブル144cは、ドメイン名に対応するIPアドレスの問い合わせのリトライ回数を示すリトライ回数情報をドメイン名毎に保持するエントリを有する。リトライ回数情報の初期値は0である。
図5は、リトライ回数テーブル144cのデータ構造例を示す。リトライ回数テーブル144cの各エントリに保持されるリトライ回数情報は、ドメイン名、当該ドメイン名に対応するIPアドレスの問い合わせをリトライしたリトライ回数、初回登録日時を示す初回登録日時情報及び最終登録日時を示す最終登録日時情報を含む。
再び図1を参照すると、管理部145は、問い合わせ受信部141によって受信された問い合わせパケット、当該問い合わせパケットの受信時刻、応答受信部143によって受信された当該問い合わせパケットに対応する応答パケット、及び当該応答パケットの受信時刻に基づいて、ドメイン・IPアドレス管理テーブル144aにドメイン・IPアドレス管理情報を登録する。管理部145はまた、応答受信部143によって受信されたDNSサーバからの応答パケットが正規応答パケットであると応答判定部146によって判定された場合に、その応答パケットが返されるまでの応答時間を示す情報を当該DNSサーバのIPアドレスに対応付けて応答時間学習テーブル144bに登録する。管理部145は更に、リトライ回数情報のリトライ回数テーブル144cへの登録及びリトライ回数テーブル144cに登録されているリトライ回数情報の更新を行う。
応答判定部146は、ドメイン・IPアドレス管理テーブル144aに登録されているドメイン・IPアドレス管理情報に基づいて、時間Tの間に正規応答パケットが受信されたかを判定する。応答送信部147は、正規応答パケットが受信されたと判定された場合、DNSキャッシュサーバ12宛てに応答パケットを送信する。
次に、本実施形態における動作について、攻撃防御装置14の動作を中心に図6乃至図8を参照して説明する。図6は情報の流れを示す図、図7及び図8は攻撃防御装置の処理手順を示すフローチャートである。
今、インターネット利用者がクライアント端末15を操作することにより、当該クライアント端末15からドメイン名が“www.abcd.co.jp”のwwwサーバ13にアクセスしようとしているものとする。この場合、クライアント端末15は、ドメイン名“www.abcd.co.jp”に対応付けられたIPアドレスを、図6において矢印601で示すようにDNSキャッシュサーバ12に問い合わせる。
DNSキャッシュサーバ12は、クライアント端末15からのドメイン名“www.abcd.co.jp”に対応付けられたIPアドレスの問い合わせを受信する。するとDNSキャッシュサーバ12は、クライアント端末15から問い合わせられたドメイン名“www.abcd.co.jp”に対応付けてIPアドレスがキャッシュ120に登録されているかを判定する。
ここでは、DNSキャッシュサーバ12のキャッシュ120には、クライアント端末15から問い合わせられたドメイン名“www.abcd.co.jp”に対応付けてIPアドレスが登録されていないものとする。この場合、DNSキャッシュサーバ12は“www.abcd.co.jp”に対応付けられたIPアドレスを取得するために、DNSサーバ11宛ての問い合わせパケットQPを、図6において矢印602で示すように送出する。
図9は、DNSキャッシュサーバ12から送出されたDNSサーバ11宛ての問い合わせパケットQPの一例を示す。図9に示される問い合わせパケットQPは、送信先IPアドレスとしてDNSサーバ11のIPアドレス“192.168.20.1”を含み、送信元IPアドレスとしてDNSキャッシュサーバ12のIPアドレスを含む。また、問い合わせパケットQPは、問い合わせドメイン名(名前解決されるべきドメイン名)としてwwwサーバ13のドメイン名“www.abcd.co.jp”を含み、当該問い合わせパケットQPのIDとして“123”を含む。
DNSキャッシュサーバ12によって送出されたDNSサーバ11宛ての問い合わせパケットQPは、ローカルエリアネットワーク17を介して攻撃防御装置14に入力される。すると攻撃防御装置14の問い合わせ受信部141は、DNSキャッシュサーバ12から送出された問い合わせパケットQPを受信する(ステップ701)。この問い合わせパケットQPの受信時刻が“09:10:00:00”(9時10分00秒00)であるものとする。
管理部145は、問い合わせ受信部141によって受信された問い合わせパケットQP、及び当該問い合わせパケットの受信時刻に基づいて、ドメイン・IPアドレス管理テーブル144aのエントリにドメイン・IPアドレス管理情報を登録する(ステップ702)。このステップ702で登録されるドメイン・IPアドレス管理情報は、問い合わせパケットQPのID“123”、問い合わせドメイン名“www.abcd.co.jp”、問い合わせ先IPアドレス(DNSサーバ11のIPアドレス)“192.168.20.1”、及び問い合わせパケットQPの受信時刻に一致する問い合わせ時刻“09:10:00:00”の情報を含む。このときドメイン・IPアドレス管理情報の応答IPアドレスフィールド及び応答時間フィールドは空欄となっている。
また、ステップS702において管理部145は、リトライ回数テーブル144cにリトライ回数情報を登録する。このリトライ回数情報は、ドメイン名及びリトライ回数として、それぞれ、問い合わせパケットQPに含まれている問い合わせドメイン名“www.abcd.co.jp”及び初期値0を含む。リトライ回数情報は更に、現在の日時を示す初回登録日時情報を含む。このときリトライ回数情報の最終登録日時情報は有効な日時を示していない。なお、最終登録日時情報が現在の日時を示していてもよい。
管理部145は、問い合わせ受信部141によって受信された問い合わせパケットQPを問い合わせ送信部142に渡す。すると問い合わせ送信部142は、問い合わせパケットQPを、DNSキャッシュサーバ12に代わって、図6において矢印603で示すようにDNSサーバ11に転送する(ステップ703)。
一方管理部145は、応答受信部143がDNSサーバ11からの応答パケットを待つ時間Tを決定して、決定した時間Tを応答受信部143に通知する(704)。この時間Tは、DNSサーバ11のIPアドレスに対応付けて応答時間学習テーブル144bに格納されている応答時間情報の示す応答時間に基づいて決定される。時間Tの詳細な決定手法については、後述する。
DNSサーバ11は、攻撃防御装置14の問い合わせ送信部142によって転送されたDNSキャッシュサーバ12からの問い合わせパケットQPを受信すると、当該問い合わせパケットQPに含まれている問い合わせドメイン名“www.abcd.co.jp”に基づいてIPアドレス記憶部110を参照する。本実施形態ではIPアドレス記憶部110に、ドメイン名“www.abcd.co.jp”に対応付けてwwwサーバ13のIPアドレス“10.0.0.1”が登録されているものとする。この場合、DNSサーバ11はIPアドレス記憶部110から、ドメイン名“www.abcd.co.jp”に対応付けられているIPアドレス“10.0.0.1”を取得する。つまりDNSサーバ11は、IPアドレス記憶部110に基づいて、ドメイン名“www.abcd.co.jp”をIPアドレス“10.0.0.1”に変換(名前解決)する。
するとDNSサーバ11は、ドメイン名が“www.abcd.co.jp”のwwwサーバのIPアドレス“10.0.0.1”を含むDNSキャッシュサーバ12宛ての応答パケットTRPを、図6において矢印604で示すように送信する。応答パケットQPは、送信先IPアドレス、送信元IPアドレス、問い合わせドメイン名、ID及び応答内容を含む。応答内容は問い合わせドメイン名に対応付けられている、名前解決されたIPアドレス(応答IPアドレス)を含む。
図10は、DNSサーバ11から送信されたDNSキャッシュサーバ12宛ての応答パケットTRPの一例を示す。図10に示される応答パケットTRPは、送信先IPアドレスとしてDNSキャッシュサーバ12のIPアドレスを含み、送信元IPアドレスとしてDNSサーバ11のIPアドレス“192.168.20.1”を含む。また、応答パケットTRPは、問い合わせドメイン名としてwwwサーバ13のドメイン名“www.abcd.co.jp”を含み、IDとして対応する問い合わせパケットQRのID“123”を含む。応答パケットTRPは更に、応答IPアドレスとしてwwwサーバ13のIPアドレス“10.0.0.1”を含む。
DNSサーバ11から送信されたDNSキャッシュサーバ12宛ての応答パケットTRPは、グローバルネットワーク16及び中継装置18を介して、DNSサーバ11とDNSキャッシュサーバ12との間に配置された攻撃防御装置14に到達する。応答受信部143は、この攻撃防御装置14に到達した応答パケットTRPを受信する。本実施形態において応答受信部143は、管理部145から時間Tが通知されると(ステップ704)、その時点から時間Tの間に攻撃防御装置14に到達する当該DNSサーバ11からの応答パケットを全て受信する(ステップ705〜707)。この時間Tの間に応答受信部143によって受信される応答パケットは、DNSサーバ11からの正規応答パケットに限らない。例えば、送信元IPアドレスをDNSサーバ11のIPアドレスに偽装した、つまり送信元をDNSサーバ11に偽装した攻撃者からの偽応答パケットも、時間Tの間に応答受信部143によって受信される可能性がある。
管理部145は、時間Tの間に、応答受信部143によって応答パケットが受信される都度(ステップ707)、ドメイン・IPアドレス管理テーブル144aから、受信応答パケットに含まれているID、問い合わせドメイン名及び送信元IPアドレスが設定されたドメイン・IPアドレス管理情報が登録されているエントリを検索する(ステップ708)。つまり管理部145は、受信応答パケットと対応している問い合わせパケットの内容を登録したエントリをエントリをドメイン・IPアドレス管理テーブル144aから検索する。
そして管理部145は、検索されたドエントリの応答IPアドレスフィールド及び応答時間フィールドに、それぞれ、受信応答パケットに含まれている応答IPアドレス及び応答時間を示す情報を設定する(ステップ709)。ここで、応答時間は、検索されたドエントリの問い合わせ時刻フィールドによって示される問い合わせ時刻と受信応答パケットの受信時刻とから(受信時刻−問い合わせ時刻)の演算によって算出される。
明らかなように、問い合わせパケットを受信した時点(問い合わせ時刻)から期間Tの間に、当該問い合わせパケットに対応する複数の応答パケットが受信された場合、受信された応答パケットの数だけ、応答IPアドレス及び応答時間を示す情報の組が、検索されたドエントリに登録される。
ここで、例えば図6に示される攻撃者(の端末)60が、ドメイン名が“www.abcd.co.jp”のIPアドレスを本来の“10.0.0.1”ではなく、攻撃者60が準備した偽のサイトのIPアドレス“200.1.1.1”にクライアント端末15(インターネット利用者)を誘導しようと試みたとする。このような場合、攻撃者60は、例えば図6において矢印605で示すように、DNSキャッシュサーバ12宛ての多数の偽応答パケットFRPを送信する。
各偽応答パケットFRPの送信先IPアドレス及び送信元IPアドレスには、それぞれ、クライアント端末15が問い合わせを行うDNSキャッシュサーバ12のIPアドレス及びDNSサーバ11のIPアドレスが用いられる。つまり各偽応答パケットFRPは、送信元IPアドレスとして、DNSサーバ11のIPアドレスを偽装している。また、各偽応答パケットFRPの問い合わせドメイン名及び応答IPアドレスには、それぞれ、クライアント端末15が必要としているIPアドレスのドメイン名“www.abcd.co.jp”及び偽のサイトのIPアドレス“200.1.1.1”が用いられる。更に各偽応答パケットFRPのIDには、攻撃者60によって推測された、或いはランダムに生成される値が用いられる。
このような多数の偽応答パケットFRPのいずれかに、問い合わせパケットQRのID“123”に一致するIDが用いられていて、且つ、その偽応答パケットFRPが応答パケットTRP(つまり正規の応答パケット)よりも先にDNSキャッシュサーバ12に到達したならば、従来であれば、その偽応答パケットFRPが正規応答パケットと誤って判定される。
本実施形態では、このような不具合を防止するために、上述のようにDNSサーバ11とDNSキャッシュサーバ12との間に攻撃防御装置14が配置される。これによりDNSキャッシュサーバ12から送出されるDNSサーバ11宛ての問い合わせパケットは攻撃防御装置14に入力され、問い合わせ受信部141で受信される(ステップ701)。管理部145は、この問い合わせパケットの内容を、当該問い合わせパケットのID毎に、つまり問い合わせドメイン名毎に、ドメイン・IPアドレス管理テーブル144aに格納する(ステップ702)。問い合わせ送信部142は、問い合わせ受信部141によって受信された問い合わせパケット、つまりDNSキャッシュサーバ12から送出された問い合わせパケットを宛先のDNSサーバ11に転送する(ステップ703)。
さて、DNSの仕組み上、DNSキャッシュサーバ12からのDNSサーバ11に対する問い合わせに対し、当該DNSサーバ11からは必ず1つの応答が返る。仮にDNSサーバ11に対する問い合わせに対し、時間Tの間に2つ以上の応答が返ってきた場合で、且つ、問い合わせドメイン名に対応するIPアドレス(応答IPアドレス)がそれぞれ異なる場合、それは攻撃者が別サーバへ誘導することを意図した偽の応答が混入している可能性を意味する。
そこで本実施形態では、詳細を後述するように、問い合わせに対する時間Tにおける応答が1対1になることが攻撃防御装置14の応答判定部146で確認されるまで、つまり正規の応答が得られるまで、当該管理部145が問い合わせ送信部142を用いて問い合わせのリトライを繰り返す構成を適用する。応答判定部146は、問い合わせに対する時間Tにおける応答が1対1となった時点で、その応答を正規応答として応答送信部147によりDNSキャッシュサーバ12転送させる。
このような構成により、DNSキャッシュサーバ12は常に正規の応答情報をキャッシュすることになり、先に述べたDNSプロトコルの脆弱性を狙った攻撃を未然に回避することが可能となる。
ここで、時間Tがあまり長い時間に設定されると、DNSキャッシュサーバ12への転送が遅くなりDNS応答の遅延を招く。逆に時間Tが短い時間に設定されると、偽のDNS応答が正規と判断されてしまう可能性がある。そこで本実施形態では、時間Tを、DNSサーバ11から過去に応答が得られた際の応答時間(例えば直近の応答時間)に基づいて決定する手法を適用している。そのため本実施形態では。DNSサーバから応答が得られた際の応答時間を、当該DNSサーバのIPアドレスに対応付けて応答時間学習テーブル144bにより管理する。更に詳細に述べるならば、αを応答時間についての誤差を考慮した予め定められた余裕時間とすると、応答時間学習テーブル144bから取得される、DNSサーバ11から応答が得られた際の直近の応答時間にαを加えた時間が、DNSサーバ11からの応答パケットを待つ時間Tとして決定される。これにより、偽のDNS応答が正規と誤判断するのを防止しつつ、DNS応答時間の低下を防止できる。しかも、時間TをDNSサーバ毎に設定できることから、この効果は著しい。
以下、期間Tの間に受信された応答パケットが正規のものであるかを判定する手順について説明する。
応答受信部143は、問い合わせパケットQPの受信時刻から管理部145によって通知された時間Tが経過すると(ステップ705のYes)、その旨を管理部145に通知する。すると管理部145は、応答判定部146に制御を渡す。
応答受信部143は、問い合わせパケットQPの受信時刻から管理部145によって通知された時間Tが経過すると(ステップ705のYes)、その旨を管理部145に通知する。すると管理部145は、応答判定部146に制御を渡す。
応答判定部146は、ドメイン・IPアドレス管理テーブル144aに登録されている、問い合わせパケットQPに対応するドメイン・IPアドレス管理情報に基づいて、当該問い合わせパケットQPに対応する応答パケットが時間Tの間に受信された数をチェックする(ステップ801)。この数は、問い合わせパケットQPに対応するドメイン・IPアドレス管理情報に設定されている応答IPアドレス及び応答時間を示す情報の組の数に一致する。そして応答判定部146は、問い合わせパケットQPに対応する応答パケットが時間Tの間に受信された数から、問い合わせパケットQPと問い合わせパケットQPに対応する応答パケットとの組み合わせが1対1であるかを判定する(ステップ802)。 応答判定部146は、問い合わせパケットQPと対応する応答パケットとの組み合わせが1対1であるならば(ステップ802のYes)、つまり問い合わせパケットQPに対応する応答パケットが時間Tの間に1つだけ受信されたならば、その時間Tの間に受信されたただ1つの問い合わせパケットQPに対応する応答パケットは正規応答パケットであるとみなす(ステップ803)。即ち応答判定部146は、ステップ802の判定がYesの場合、問い合わせパケットQPに対応するただ1つの応答パケットを正規応答パケットであると判定する。このただ1つの応答パケットが応答パケットTRPであることは明らかである。
すると管理部145は、問い合わせパケットQPの送信先IPアドレス(つまり問い合わせ先のDNSサーバのIPアドレス)に対応付けて応答時間学習テーブル144bに登録されている応答時間情報を、正規応答パケットであると判定された応答パケットTRPが返されるまでに要した最新の時間を示すように更新する(ステップ804)。これにより、問い合わせパケットQPに対して問い合わせ先のDNSサーバ11から応答パケットTRPが返されるまでの応答時間が学習されたことになる、
次に管理部145は、正規応答パケットであると判定された応答パケットTRPの送信を応答送信部147に要求する。すると応答送信部147は、応答パケットTRPを、図6において矢印606で示すようにDNSキャッシュサーバ12に送信する(ステップ805)。DNSキャッシュサーバ12は、この応答パケットRPによって通知されたドメイン名“www.abcd.co.jp”のIPアドレス“10.0.0.1”を、当該ドメイン名“www.abcd.co.jp”に対応付けてキャッシュ120に登録する。またDNSキャッシュサーバ12は、ドメイン名“www.abcd.co.jp”のIPアドレス“10.0.0.1”を、クライアント端末15からの問い合わせに対する応答として、図6において矢印607で示すよう当該にクライアント端末15に返す。
次に管理部145は、正規応答パケットであると判定された応答パケットTRPの送信を応答送信部147に要求する。すると応答送信部147は、応答パケットTRPを、図6において矢印606で示すようにDNSキャッシュサーバ12に送信する(ステップ805)。DNSキャッシュサーバ12は、この応答パケットRPによって通知されたドメイン名“www.abcd.co.jp”のIPアドレス“10.0.0.1”を、当該ドメイン名“www.abcd.co.jp”に対応付けてキャッシュ120に登録する。またDNSキャッシュサーバ12は、ドメイン名“www.abcd.co.jp”のIPアドレス“10.0.0.1”を、クライアント端末15からの問い合わせに対する応答として、図6において矢印607で示すよう当該にクライアント端末15に返す。
これに対し、問い合わせパケットQPと対応する応答パケットとの組み合わせが1対1でないものとする(ステップ802のNo)。つまり時間Tの間に問い合わせパケットQPに対応する複数の応答パケットが受信されたものとする。このような場合、応答判定部146は、時間Tの間に受信された複数の応答パケットに正規応答パケットが含まれているとしても、その正規応答パケットを特定することができない。そこで管理部145は、問い合わせパケットQPと対応する応答パケットとの組み合わせが1対1でないと応答判定部146によって判定された場合(ステップ802のNo)、これらの応答パケットを偽応答パケットであると判定して破棄する(ステップ806)。
次に管理部145はリトライ回数テーブル144cから、問い合わせパケットQPに含まれている問い合わせドメイン名が設定されているリトライ回数情報を検索し、当該リトライ回数情報中のリトライ回数を1だけインクリメントする(ステップ807)。このとき管理部145は、リトライ回数情報中の最終登録日時情報を現在の日時を示すように更新する。
管理部145は、インクリメント後のリトライ回数が閾値を超えているかを判定する(ステップ808)。もし、超えていないならば(ステップ808のNo)、管理部145は問い合わせ送信部142によって問い合わせパケットQPをDNSサーバ11に再度転送させる(ステップ703)。つまり管理部145は、問い合わせ送信部142を用いて、問い合わせのリトライを行う。
このように本実施形態においては、問い合わせパケットQPと対応する応答パケットとの組み合わせが1対1になるまで、予め定められたリトライ回数を超えない範囲で、DNSサーバ11に当該問い合わせパケットQPをDNSキャッシュサーバ12に代わって転送する動作が繰り返される。
これに対し、インクリメント後のリトライ回数が閾値を超えているならば(ステップ808のYes)、管理部145は、これ以上の問い合わせのリトライは無駄であると判断する。この場合、管理部145はDNSキャッシュサーバ12からの問い合わせパケットQPに対する応答として、応答送信部147によりDNSキャッシュサーバ12にエラーを示す応答パケットを送信させる(ステップ809)。そして管理部145は、問い合わせパケットQPが攻撃防御装置14に入力された際の処理を終了する。
なお、エラーを示す応答パケットをDNSキャッシュサーバ12に返すことなく管理部145が処理を終了しても構わない。一般にDNSキャッシュサーバ12は、DNSサーバ11宛ての問い合わせパケットQPを送信すると、その問い合わせパケットQPに対する応答を、ある一定時間待っている。この時間内に、応答が返らない場合、DNSキャッシュサーバ12は問い合わせをリトライする。
さて本実施形態では、管理部145はリトライ回数テーブル144cを例えば定期的に参照し、問い合わせ回数が予め定められた値(以下、通知条件値と称する)を超えているドメイン名があるかを判定する。本実施形態において通知条件値は、1以上でかつ上記閾値以下の整数である。
管理部145は、問い合わせ回数が通知条件値を超えているドメイン名があるならば、予め登録されている管理者に対し例えば電子メールを用いて、当該ドメイン名が攻撃対象となっている旨(つまり当該ドメイン名に対応するIPアドレスを偽装する攻撃が行われている旨)を通知する。ここでは、リトライ回数テーブル144cに保持されている該当するリトライ回数情報、即ち攻撃対象となっているドメイン名、リトライ回数、初回登録日時情報及び最終登録日時が通知される。
一般的に管理者は、この種の攻撃を受けていることを検知しにくい。しかし本実施形態によれば、上述のような電子メールによる通知により、管理者はDNSサーバ側が攻撃対象となっていることがわかり、対象ドメインにアクセスするユーザに注意喚起を促し、攻撃者に対する防御策を行うことができる。ここで、上述の閾値、通知条件値及び電子メールの通知先となる管理者の電子メールアドレスは、管理情報記憶部144に予め登録されている。
なお、通知条件値として上記閾値を用いるならば、ステップ808でリトライ回数が閾値を超えていると判定された際に、対応するドメイン名が攻撃対象となっている旨を通知すればよく、必ずしもリトライ回数テーブル144cを定期的に参照する必要はない。また、この通知に、SNMP(Simple Network Management Protocol)など、電子メール以外の電子的な通信手段を用いてもよい。
上記実施形態では、ドメイン・IPアドレス管理テーブル144a、応答時間学習テーブル144b及びリトライ回数テーブル144cが格納される管理情報記憶部144は、磁気ディスクドライブのような不揮発性の記憶装置である。このためテーブル144a〜144cに高速にアクセスすることは難しい。そこで、テーブル144a〜144cをRAMのような高速の記憶装置に格納してもよい。この場合、電源遮断時にテーブル144a〜144cの内容が消失しないように、テーブル144a〜144cを適宜不揮発性の記憶装置に保存するとよい。なお、応答時間学習テーブル144bのみを不揮発性の記憶装置に保存する構成であっても構わない。
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、攻撃防御装置14が、DNSキャッシュサーバ12と共に同一コンピュータによって実現される構成であってもよく、中継装置18に設けられていても構わない。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
11…DNSサーバ、12…DNSキャッシュサーバ、13…wwwサーバ、14…攻撃防御装置(DNSキャッシュ・ポイズニング攻撃防御装置)、15…クライアント端末、16…グローバルネットワーク、17…ローカルエリアネットワーク、18…中継装置、141…問い合わせ受信部、142…問い合わせ送信部、143…応答受信部、144…管理情報記憶部、144a…ドメイン・IPアドレス管理テーブル、144b…応答時間学習テーブル、144c…リトライ回数テーブル、145…管理部、146…応答判定部、147…応答送信部。
Claims (5)
- DNSサーバとDNSキャッシュサーバとの間に配置された、DNSキャッシュ・ポイズニング攻撃を防御する装置であって、
前記DNSキャッシュサーバから送出されたドメイン名に対応するIPアドレスを問い合わせるための前記DNSサーバ宛の問い合わせパケットを受信する問い合わせ受信手段と、
前記受信された問い合わせパケットを前記DNSキャッシュサーバに代わって前記DNSサーバに転送する問い合わせ送信手段と、
前記問い合わせパケットによるIPアドレスの問い合わせ時から一定時間の間に前記装置に到達した当該問い合わせパケットに対応する応答パケットを受信する応答受信手段と、
前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったことをもって、当該応答パケットを正規応答パケットであると判定する応答判定手段と、
前記正規応答パケットであると判定された応答パケットを前記DNSキャッシュサーバに返す応答送信手段と
を具備することを特徴とするDNSキャッシュ・ポイズニング攻撃を防御する装置。 - 前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理する管理手段を更に具備し、
前記応答判定手段は前記管理手段によって管理される情報に基づいて、前記問い合わせパケットと前記一定時間の間に受信された当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になったかを判定することを特徴とする請求項1記載のDNSキャッシュ・ポイズニング攻撃を防御する装置。 - 前記管理手段は前記一定時間を更に管理し、前記問い合わせパケットによる前記DNSサーバへのIPアドレスの問い合わせ時から一定時間の間に受信された当該問い合わせパケットに対応する応答パケットが正規応答パケットであると判定された場合、次に前記DNSサーバへのIPアドレスの問い合わせ時に用いられる前記一定時間を、当該応答パケットが返されるのに要した応答時間に基づいて変更することを特徴とする請求項2記載のDNSキャッシュ・ポイズニング攻撃を防御する装置。
- 前記管理手段は前記問い合わせ送信手段による前記問い合わせパケットの転送のリトライを更に管理し、前記リトライを、予め定められた閾値の示すリトライ回数を超えない範囲で、前記問い合わせパケットと当該問い合わせパケットに対応する応答パケットとの組み合わせが1対1になるまで繰り返させることを特徴とする請求項2記載のDNSキャッシュ・ポイズニング攻撃を防御する装置。
- 前記問い合わせ受信手段によって受信された問い合わせパケット毎に、当該問い合わせパケットの示す問い合わせ内容及び当該問い合わせパケットに対応する応答パケットの示す応答内容を管理するのに用いられる管理情報を登録する管理情報記憶手段を更に具備し、
前記問い合わせパケットは、当該問い合わせパケットを識別するための識別子、問い合わせに用いられる問い合わせドメイン名及び問い合わせ先のDNSサーバのIPアドレスである問い合わせIPアドレスを含み、
前記応答パケットは、問い合わせドメイン名、当該問い合わせドメイン名に対応するIPアドレスである応答IPアドレス、応答元を示す送信元IPアドレス及び識別子を含み、
前記管理手段は、前記問い合わせ受信手段によって前記問い合わせパケットが受信された際に、当該問い合わせパケットに含まれている識別子、問い合わせドメイン名及び問い合わせIPアドレスを含む管理情報を前記管理情報記憶手段に登録し、前記問い合わせパケットによるIPアドレスの問い合わせ時から前記一定時間の間に前記応答受信手段によって応答パケットが受信された際に、当該応答パケットに含まれている識別子、問い合わせドメイン名及び送信元IPアドレスにそれぞれ一致する識別子、問い合わせドメイン名及び問い合わせIPアドレスを含む管理情報を前記管理情報記憶手段から検索して、当該管理情報に当該応答パケットに含まれている応答IPアドレスを追加設定する
ことを特徴とする請求項2乃至4のいずれかに記載のDNSキャッシュ・ポイズニング攻撃を防御する装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009195415A JP2011049745A (ja) | 2009-08-26 | 2009-08-26 | Dnsキャッシュ・ポイズニング攻撃を防御する装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009195415A JP2011049745A (ja) | 2009-08-26 | 2009-08-26 | Dnsキャッシュ・ポイズニング攻撃を防御する装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011049745A true JP2011049745A (ja) | 2011-03-10 |
Family
ID=43835651
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009195415A Pending JP2011049745A (ja) | 2009-08-26 | 2009-08-26 | Dnsキャッシュ・ポイズニング攻撃を防御する装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011049745A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013247674A (ja) * | 2012-05-24 | 2013-12-09 | Internatl Business Mach Corp <Ibm> | 不正ドメイン・ネーム・サービス(dns)サーバを識別するための方法、システムおよびコンピュータ・プログラム(受動監視を通じて不正ドメイン・ネーム・サービス・プロバイダの存在を検出するためのシステム) |
CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
WO2017039602A1 (en) * | 2015-08-31 | 2017-03-09 | Hewlett Packard Enterprise Development Lp | Collecting domain name system traffic |
KR101874815B1 (ko) * | 2016-07-06 | 2018-07-06 | 네이버 주식회사 | Dns 주소의 변조 진단 방법 및 이를 위한 단말 장치 |
JP2021099754A (ja) * | 2019-12-24 | 2021-07-01 | 富士通株式会社 | 制御方法、情報処理装置及び制御プログラム |
-
2009
- 2009-08-26 JP JP2009195415A patent/JP2011049745A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013247674A (ja) * | 2012-05-24 | 2013-12-09 | Internatl Business Mach Corp <Ibm> | 不正ドメイン・ネーム・サービス(dns)サーバを識別するための方法、システムおよびコンピュータ・プログラム(受動監視を通じて不正ドメイン・ネーム・サービス・プロバイダの存在を検出するためのシステム) |
CN103685168A (zh) * | 2012-09-07 | 2014-03-26 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
CN103685168B (zh) * | 2012-09-07 | 2016-12-07 | 中国科学院计算机网络信息中心 | 一种dns递归服务器的查询请求服务方法 |
WO2017039602A1 (en) * | 2015-08-31 | 2017-03-09 | Hewlett Packard Enterprise Development Lp | Collecting domain name system traffic |
CN107534690A (zh) * | 2015-08-31 | 2018-01-02 | 慧与发展有限责任合伙企业 | 采集域名系统流量 |
US10666672B2 (en) | 2015-08-31 | 2020-05-26 | Hewlett Packard Enterprise Development Lp | Collecting domain name system traffic |
KR101874815B1 (ko) * | 2016-07-06 | 2018-07-06 | 네이버 주식회사 | Dns 주소의 변조 진단 방법 및 이를 위한 단말 장치 |
JP2021099754A (ja) * | 2019-12-24 | 2021-07-01 | 富士通株式会社 | 制御方法、情報処理装置及び制御プログラム |
JP7352092B2 (ja) | 2019-12-24 | 2023-09-28 | 富士通株式会社 | 制御方法、情報処理装置及び制御プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10425379B2 (en) | Establishing unique sessions for DNS subscribers | |
US8484377B1 (en) | Systems and methods for prepending nonce labels to DNS queries to enhance security | |
US8219644B2 (en) | Requesting a service or transmitting content as a domain name system resolver | |
US7996475B2 (en) | Facilitating transmission of email by checking email parameters with a database of well behaved senders | |
US8156243B2 (en) | Request routing | |
US9264358B2 (en) | Alias resource record sets | |
JP4287456B2 (ja) | サービス不能攻撃を防止するサーバ装置、方法およびプログラム | |
US8726375B2 (en) | Method and device for preventing domain name system spoofing | |
US20100057895A1 (en) | Methods of Providing Reputation Information with an Address and Related Devices and Computer Program Products | |
EP3139576A1 (en) | Systems and methods for providing secure access to shared registration systems | |
JP2011049745A (ja) | Dnsキャッシュ・ポイズニング攻撃を防御する装置 | |
US11070513B2 (en) | DNS-based method of transmitting data | |
CN108768853B (zh) | 基于域名路由器的分布式混合域名系统及方法 | |
CN111600969B (zh) | 域名寻址方法、系统、域名服务器、电子设备及存储介质 | |
KR101645222B1 (ko) | 어드밴스드 도메인 네임 시스템 및 운용 방법 | |
JP5842128B2 (ja) | 通信システム、機器通信サーバ、クライアント機器 | |
JP2009212693A (ja) | 通信装置、プログラム、および記録媒体 | |
Brzozowski et al. | DHCPv6 Leasequery | |
CA2622310A1 (en) | System and method for provisioning an email account using mail exchange and address records | |
JP2019195128A (ja) | キャッシュdnsサーバ、改竄防止方法、及び改竄防止プログラム | |
van Zyl | A longitudinal study of DNS traffic: Understanding current DNS practice and abuse | |
JP2010278559A (ja) | Dnsメッセージ回送装置、dnsメッセージ回送システム、dnsメッセージ回送方法およびdnsメッセージ回送プログラム | |
Brzozowski et al. | RFC 5007: DHCPv6 Leasequery | |
Zeng et al. | Network Working Group J. Brzozowski Request for Comments: 5007 Comcast Cable Category: Standards Track K. Kinnear B. Volz | |
JP2009159042A (ja) | 名前解決装置、名前解決方法およびソケット管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110125 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110719 |