更新日：2008年10月16日
「DNSキャッシュポイズニング」とは、DNSのサービスを提供しているサーバ(DNSサーバ)へ偽の情報を送り込むことです。
みなさんが使用しているインターネットのあらゆるサービスは、DNSに依存しています。 DNSの役割はインターネット上の住所、ドメイン名とIPアドレスを紐付ける情報を提供しているサービスで、ブラウザからWebへのアクセスやメールの送受信もこのDNSサービスを使用しています。もし、DNSキャッシュポイズニングによって、偽の情報を送り込まれたとしたら、どんなことが起きるのでしょうか？
ここでは、DNSの仕組とDNSサーバのキャッシュポイズニング対策方法についてみなさんに紹介したいと思います。
DNSの役割を身近なところで紹介すると、ブラウザからwww.hitachi.co.jpへアクセスした際、DNSサーバは、ドメイン名 (www.hitachi.co.jp) をIPアドレス (133.145.224.19) へ変換しクライアントへ返します。クライアントはこのIPアドレスを使用してWebサーバwww.hitachi.co.jpにアクセスします。
図1：クライアントからの名前解決
このドメイン名とIPアドレスを変換するDNSサーバには、「コンテンツサーバ」と「キャッシュサーバ」という2種類の動作形態があり、これらが連携してDNSサービスを実現しています。
ドメインの (原本) 情報を管理するDNSサーバで、そのドメインの正規の情報を提供するDNSサーバです。
クライアントに代わってコンテンツサーバに問合せを行うDNSサーバです。問合せた結果を、複製として一時的に記憶 (キャッシュ) することから、キャッシュサーバと呼ばれています。ここで、クライアントから受信した問合せを他のDNSサーバに転送することを「再帰問合せ」と呼びます。
図2：DNSの仕組み
DNSキャッシュポイズニングは、DNSサービスを構成するサーバのうち、キャッシュサーバを対象とした攻撃活動です。具体的には、本物のコンテンツサーバからの回答 (③‘) よりも先に偽装した回答をキャッシュサーバに送り (③) 、偽情報を記憶させる (キャッシュさせる) ことによって攻撃が成功します。キャッシュサーバは、クライアントの問合せ (④) に対する回答(キャッシュされた偽の複製)を持っている場合には、その複製 (⑤) を回答します。結果として、クライアントは提供された偽の情報により、攻撃者が罠をはった偽サイト (⑥) に誘導されてしまうことになります。
図3：キャッシュポイズニングの概念図
DNSサーバの検査と対策では、自ドメインの原本情報を管理するコンテンツサーバの状態と対策方法について紹介します。
IANA (Internet Assigned Numbers Authority) から「Cross-Pollination Check」というページが公開されています[*1]。まず、このサイトにアクセスしてみましょう。ドメイン名を入力すると、コンテンツサーバを検出し、そのサーバの①再帰問合せの有無、②送信元ポートのランダム性有無を確認することが可能です。
再帰問合せが有効であるということは、検出されたコンテンツサーバがキャッシュサーバとしての機能を備えていることを意味します。また、送信元ポートのランダム性が無い場合には、キャッシュサーバとしての機能がDNSキャッシュポイズニングによる攻撃を受けやすいことを意味します。
図4 は、「example.com」ドメインを検査した結果です。このように結果が「Safe」と表示された場合は、再帰問合せが無効であり、よってキャッシュサーバとしての機能がないため、DNSキャッシュポイズニングによる攻撃そのものを回避することができます。
図4：example.comドメイン検査例
検査結果は、「Safe」の他に「Highly vulnerable」「Vulnerable」があります。後者2つであった場合、検出されたDNSサーバは、コンテンツサーバの機能だけでなくキャッシュサーバの機能が有効になっており、DNSキャッシュポイズニング攻撃の対象となる可能性があります。
特に「Highly vulnerable」の場合には、キャッシュサーバの機能が有効かつ、DNSキャッシュポイズニング攻撃により偽情報を記憶させられる可能性が高いので、早急な対応が必要です。
「Vulnerable」はDNSキャッシュポイズニングによる影響を低減するための機構が導入済みの場合に表示される結果ですが、キャッシュサーバの機能が有効ですので、DNSキャッシュポイズニングによる攻撃を完全に回避できるわけではありません。
図5：「Highly vulnerable」
図6：「Vulnerable」
検査結果が、「Highly vulnerable」「Vulnerable」であったDNSサーバは、図7のようにインターネットからの再帰問合せを受け付ける設定で運用されている状態です。これは、自ドメインの原本情報を管理するコンテンツサーバが、DNSキャッシュポイズニング攻撃を受ける可能性が高いということを表しています。
図7：コンテンツサーバとキャッシュサーバ機能を備えたDNSサーバ
テストは、意図した結果になりましたか？
自ドメインのコンテンツサーバは、コンテンツサーバの機能のみでよいか、コンテンツサーバ兼キャッシュサーバとして運用する必要があるか構成を検討し、各サーバ毎に次に説明する対策を実施してください。
*1) IANAのCross-Pollination Checkは、2010年から2011年にかけて終了しました。
推奨設定は、図8の通りです。自ドメインのDNSサーバを、コンテンツサーバの機能のみで動作させると、DNSキャッシュポイズニングの問題を根本的に回避できます。また、コンテンツサーバ兼キャッシュサーバとして運用する場合には、イントラネットからの再帰問合せのみを許可する設定にします。これで、インターネットからのキャッシュサーバへの攻撃を防ぐことができます。
図8：推奨設定
最後に、対策をまとめておきます。
各ベンダーから本脆弱性対策として、修正プログラム(パッチ)がリリースされていますので、修正プログラムを適用しましょう。 修正プログラムの情報は、日本で使用されているソフトウェアの脆弱性関連情報が掲載されているJVNサイト「複数の DNS 実装にキャッシュポイズニングの脆弱性(JVNVU#800113)」を参照してください。
再帰問合わせを無効にしましょう。 なお、設定変更する場合には、自ドメインのDNSサーバの利用状況を十分に把握した上で、実施しましょう。
インターネットからの再帰問合わせを拒否するように設定 (イントラネットからのみを許可する送信元の限定) しましょう。 コンテンツサーバとキャッシュサーバの分離を考えたいという方には、日本のドメイン名を運用管理しているJPRSサイト 「DNS の再帰的な問合せを使った DDoS 攻撃の対策について」 の資料が参考になります。
担当：沼田/HIRT
グローバルサイン：
重要な電子文書にデジタル署名。広報にも役立っています
