JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPRS トピックス＆コラム No.009
DNSに不正なデータを記憶させドメイン名の乗っ取りを図る「DNSキャッシュポイズニング」と呼ばれる攻撃の危険性が高まっています。
この攻撃の概要と対策について解説します。
キャッシュ機能とDNSキャッシュポイズニングDNSキャッシュポイズニングの仕組みDNSキャッシュポイズニングとTTL値の関係新たに発見された攻撃方法DNSキャッシュポイズニングの脅威DNSキャッシュポイズニングへの対策方法根本的な解決方法はDNSSECの導入攻撃の検知と防御―現時点における試み自分のDNSサーバをチェックするにはキャッシュ機能とDNSキャッシュポイズニング
DNSには、問い合わせによって得られたIPアドレスや権威DNSサーバ名などの情報を一時的に記憶し、名前解決の際にそれらを再利用することで処理の効率化を図る、という機能があります。これをDNSのキャッシュ機能といい、キャッシュDNSサーバや一部のDNSクライアントに実装されています。キャッシュ機能はDNSサーバへの問い合わせ数を大幅に減少させ、DNSやネットワークの負荷を全体に軽減させるという重要な役割を担っています。
しかし、この機能を悪用し、偽のデータをキャッシュに記憶させることでドメイン名の乗っ取りやフィッシングなどを図る「DNSキャッシュポイズニング（DNS cache poisoning）」と呼ばれる攻撃が知られています。
DNSキャッシュポイズニングの仕組み
DNSでは主要な通信プロトコルとしてUDPを使用します。UDPではTCPと異なり、相手との通信前の折衝やデータの到達確認を行いません。そのため、UDPはTCPに比べてデータ到達の信頼性は下がりますが、相手との通信に必要な手間が少ないため、一度のやりとりで通信が完了し、かつサーバにおいて数多くのクライアントからの要求をできる限り短時間で処理する必要のあるプロトコルに向いたものであるといえます（*1）。
しかし、UDPはその特性から、TCPに比べ通信データの偽造が容易であるという短所があります。そのためDNSでは、処理ごとに毎回異なった「ID」を付け、問い合わせ内容とともにIDの一致も併せてチェックすることにより、応答の正当性を確認しています。
しかし、現在のDNSプロトコルでは、悪意を持った第三者が、
① 発信元としてDNS サーバのIPアドレスを偽装し、
② 問い合わせに使われたUDPポートと同じポートに、
③ 問い合わせに使われたIDと同じIDを付け、
④ 本来のDNS応答よりも先に応答を返す
ことができた場合、問い合わせ元はそれが偽のデータであることを判別できないため、DNSキャッシュポイズニングが成立してしまうことになります。
DNSキャッシュポイズニングとTTL値の関係
ここまでで解説したDNSキャッシュポイズニングの脆弱性そのものは、以前から知られていました。従来のDNSキャッシュポイズニング攻撃では、通常のDNS応答、例えばwww.example.jpに対し攻撃を試みる場合、www.example.jpの問い合わせに対する応答そのものを偽造する形で行われていました。
この場合、DNSキャッシュポイズニングが成功する可能性は、該当するデータの有効時間（TTL:Time To Live）の設定値に依存します。つまり、キャッシュが有効である間は目的とする名前に対する外部への問い合わせが行われないため、権威DNSサーバ側で長いTTLを設定することにより、DNSキャッシュポイズニングに関する危険性をある程度軽減することができます。
新たに発見された攻撃方法
しかし、セキュリティ研究者のダン・カミンスキー氏が、DNSキャッシュポイズニングをより効率的に実行可能な新しい攻撃方法を発見し、その方法が2008年の7月に明らかにされたことから、DNSキャッシュポイズニング攻撃に対する危険性が従来に比べ急激に高まりました。この方法は「カミンスキー・アタック（Kaminsky Attack、あるいはKaminsky's attack）」と呼ばれています。
カミンスキー・アタックでは、攻撃対象の名前（例:www.example.jp）と同じドメイン名内の存在しない名前（例:001.example.jp）の問い合わせを攻撃目標となるキャッシュDNSサーバに対して送り（あるいは、その名前を検索させるように仕向け）、その直後に「私はその名前（001.example.jp）を知らないが、www.example.jpが知っている。そのIPアドレスはxxx.xxx.xxx.xxx（攻撃者が用意した偽のサーバのIPアドレス）である」という偽の応答情報を、IDを変化させながらキャッシュDNSサーバに大量に送り付けます（*2）。もし、この偽の応答が前節で解説した条件を満たしている場合、DNSキャッシュポイズニングが成立してしまいます。
現在のDNSプロトコル（RFC 1035）では、DNSのIDは16ビットと定められているため、IDは最大でも65,536通りとなります。この値は現状のインターネットにおいて総当たり攻撃に対し必ずしも十分な耐性を有しているとはいえません。
また、カミンスキー・アタックでは、攻撃者が問い合わせる名前を毎回変化させることにより、攻撃目標となる名前に対する攻撃を連続して繰り返し行うことができるようになります。従来のDNSキャッシュポイズニングではポイズニングが一度失敗した直後に同じ名前に対して即座に再攻撃を試みることは不可能でしたが、カミンスキー・アタックではそれが可能となります。
更に、一部のキャッシュDNSサーバの実装ではカミンスキー・アタックで攻撃を受けた場合、通常の名前検索で攻撃対象の名前が既にキャッシュされている場合であっても、それを無視する形で偽の情報が上書きされてしまうことから、攻撃対象データのTTLの設定値やキャッシュ情報の有無にかかわらず、外部からのDNSキャッシュポイズニングが成立してしまうことがあります。
DNSキャッシュポイズニングの脅威
DNSキャッシュポイズニングにより偽のデータを記憶させられてしまった場合、その被害はそのキャッシュDNSサーバを参照しているすべてのクライアントに及びます。また、DNSはほぼすべてのインターネットサービスが使用しているため、DNSキャッシュポイズニングはインターネット全体の安全性にかかわる問題です。
特に、今回のカミンスキー・アタックは危険性が非常に高く、インターネット全体にとって大きな脅威であり、早急な対策が必要になります。
次節では、カミンスキー・アタックを含む、DNSキャッシュポイズニングへの対策方法について解説します。
DNSキャッシュポイズニングへの対策方法
1. 問い合わせUDPポートのランダム化…必要に応じサーバソフトウェアのバージョンアップを
従来の主なキャッシュDNSサーバの実装では、問い合わせに使うUDPポートは一つに固定されているか、あるいは決められた範囲の限られたポートしか使用しないものがほとんどでした。これを問い合わせごとに毎回変える（ランダム化）ように変更することで、総当たり攻撃に対する耐性を高めることができます。そのため今回、問い合わせUDPポートをランダム化するための緊急パッチが、各開発元からリリースされました。
UDPポートをランダム化することにより、DNSキャッシュポイズニングが成功する確率を、IDのみがランダムでポートが固定である場合に比べ、大幅に低下させることができます。
カミンスキー・アタックでは問い合わせUDPポートが固定であった場合、数秒程度の攻撃でDNSキャッシュポイズニングを成立させることができます。キャッシュDNSサーバを運用されている方は現在使用しているサーバソフトウェアのバージョンを確認し、必要に応じ最新版に更新しておきましょう。
主な開発元における対応情報は、後述のCERT/CCのWebページにまとめられています。
2. オープンリゾルバは危険…適切なアクセスコントロールやフィルタリングの適用を
インターネット上のどこからのDNS再帰検索要求でも受け付ける状態になっているキャッシュDNSサーバを「オープンリゾルバ」といいます。オープンリゾルバはDNS Amp攻撃（*3）の踏み台に使われる危険性があるなど、本来好ましくない設定ですが、DNSキャッシュポイズニングの攻撃者から見た場合オープンリゾルバには、攻撃者が任意のタイミングで、任意のドメイン名に対するキャッシュポイズニング攻撃を始めることができるため、非常に危険な状態です。
また、DNSサーバでアクセスコントロールが適切に設定されていても、発信元IPアドレスを偽装したDNSデータが外部から到達可能であった場合、そのデータを受け取ったキャッシュDNSサーバが反復検索を始めてしまう恐れがあります。
そのため、DNSキャッシュポイズニングを防ぐためにはDNSサーバにおける対策だけでは不十分であり、内部ネットワークのIPアドレスを詐称したデータが外部から到達することがないよう、ネットワークにおいてもフィルタリングなどの適切な対策を取る必要があります。
3. 権威DNSサーバは狙われやすい…機能分割と反復検索機能の無効化を
権威DNSサーバは、それぞれのドメイン名を管理するためのサーバとしてインターネット上に広く公開されます。そして、公開が目的である権威DNSサーバのIPアドレスは誰でも簡単に知ることができるため、もし権威DNSサーバがオープンリゾルバの状態に設定されていた場合、非常に危険です。
本来、権威DNSサーバとキャッシュDNSサーバはDNSの構成上別の機能です。そのため、権威DNSサーバとキャッシュDNSサーバはできる限り別のサーバ（あるいは別のIPアドレス）に分割し、権威DNSサーバでは反復検索機能を無効に設定しておくことが推奨されています。
根本的な解決方法はDNSSECの導入
これまでに解説した方法は、DNSキャッシュポイズニングの危険性を確率的に下げるためのものです。
DNSキャッシュポイズニングを根本的に防ぎ、インターネットの安全性を向上させるためには、DNSプロトコル自体の改良が必要になります。そして、それを目的として開発されたDNSのセキュリティ拡張機能であるDNSSEC（*4）の導入が進められ始めています。
しかし、DNSSECを導入するためには、関連するDNSサーバ（権威DNSサーバ、キャッシュDNSサーバの双方）すべてをDNSSEC対応のものに更新する必要があるなど、インターネットを構成するさまざまな立場から対応を進めていく必要があります。このため、DNSSECの普及促進のための活動を今後どう進めていくかが、大きな課題となっています。
攻撃の検知と防御―現時点における試み
このように根本対策であるDNSSECの普及には今後ある程度の時間を要するため、DNSキャッシュポイズニング攻撃を効率良く検知し、効果的な防御を行うための手法が研究開発・発表され始めています。
カミンスキー・アタックを始めとするDNSキャッシュポイズニング攻撃では、通常の運用ではほとんど検出されない、問い合わせ時のIDやUDPポート番号と一致しない、不正なDNS応答が観測されます。これを効率良く検知することで攻撃をブロックしたり、必要に応じより信頼性の高いTCPでの再問い合わせを行ったりするなど、さまざまな対策が提案、実装されています。
根本対策であるDNSSECも、JPドメイン名を含むいくつかのTLDやRIRなどで導入が始まっています（*5）。
自分のDNSサーバをチェックするには
ICANN/IANAでは、DNSの管理者が権威DNSサーバの設定状況をチェックするためのWebページを開設しています。
このWebページでは、①指定するドメイン名の権威DNSサーバがオープンリゾルバになっていないか、②もしオープンリゾルバになっている場合、問い合わせUDPポートが固定されていないか、の2点をチェックすることができます。
また、DNSに関する調査・分析活動や情報交換の場を提供しているDNS-OARC（DNS Operations, Analysis, and Research Center）では、ユーザーが現在使っているキャッシュDNSサーバのIDとUDPポート番号が十分なランダム性を備えているかどうかを視覚的にチェックできるWebページを開設しています。
DNSが20年以上もの間その基本仕様を大きく変更することなく、急成長したインターネットを現在まで支え続けてこられたのは、通信プロトコルとしてコストの少ないUDPが採用されていたことが大きな要素の一つであった、といえるでしょう。
攻撃者は偽のサーバ上で、example.jpの偽の権威DNSサーバをあらかじめ動作させておきます。
DNS Amp攻撃の概要と対策については、JPRS トピックス&コラムNo.3「DDoSにあなたのDNSが使われる」をご参照ください。
DNSSECの概要と普及に向けた課題についてはJPRS トピックス&コラムNo.13「DNSSECの概要と今後の展開」をご参照ください。
JPRSでは2011年1月16日にDNSSECをJPドメイン名に導入しました。
掲載内容は2011年2月のものです。
Copyright©2001-2024 Japan Registry Services Co., Ltd.