では、どのようにネームサーバに偽の回答をキャッシュさせるのだろうか。先のDNSの仕組みで紹介したように、DNSでは問い合わせと回答をセットで取り扱う。キャッシュサーバが別のネームサーバに問い合わせを実施した場合、その問い合わせへの回答を以下の6つの情報で識別する。

• 送信元IPアドレス
• 送信元ポート番号
• 送信先IPアドレス
• 送信先ポート番号
• 問い合わせ内容
• 問い合わせにおけるトランザクションID（TXID）

　逆を言うと、この6つの情報が問い合わせと同じであれば、キャッシュサーバが受け取った回答は正当なものであると判断され、キャッシュされてしまう。DNSの問い合わせ・回答はUDPでやりとりされるため、パケットの偽造が容易だ。このような要素を組み合わせることで、キャッシュポイズニングが実現する。

　悪意ある第三者が標的のキャッシュサーバに対して、再帰問い合わせを発生させ、前述の6つの情報を設定した偽の回答を標的キャッシュサーバに送信する。問い合わせ先のネームサーバから正規の回答が届く前に偽の回答が標的キャッシュサーバに届けば、偽の回答は正当なものとしてキャッシュされる（図2）。その後、キャッシュサーバに同じ問い合わせを実施してきたユーザーには偽の情報が回答されるわけだ。

図2●DNSキャッシュポイズニングの仕組み《クリックで拡大》

　キャッシュポイズニングは何も新しい手法ではなく、1990年代には既に存在が知られていたものである。ただし、これまでは実現の可能性が低いと考えられていた。だが、2008年7月にこの事情が変わった。セキュリティ研究者ダン・カミンスキー氏により発表された新手法（「Kaminsky Attack」と呼ばれる）では、キャッシュポイズニングが成功する可能性が非常に高くなったのだ。

　図2の手法では、一度キャッシュポイズニングに失敗した場合、回答に設定されたTTL（Time To Live：回答の有効時間）の秒数だけ待たなければならなかった。これは問い合わせの回答に偽の情報を設定しているためだ。しかしKaminsky Attackでは、問い合わせの回答ではなく、回答に付与するオプション情報（Addtional Recordと呼ぶ情報）に偽の情報を設定する。こうすることで、異なる問い合わせで同じ情報を設定できるため、事実上の総当たり攻撃が可能となった。

　Kaminsky Attackの公表から執筆時点（2008年3月）に至るまで、筆者が知る限りで公になったキャッシュポイズニング事例は、米AT&T、中国China Netcomの2つの事例だけだ。特にChina Netcomの事例では、誘導先のWebサイトにWebブラウザなどの脆弱性を狙った攻撃コードが仕込まれていた。日本では事例こそないものの、キャッシュポイズニングが成功する可能性があるネームサーバが多数存在することが報告されている。IPA（情報処理推進機構）のプレスリリースによると、2008年第4四半期（10～12月）において、計792件の脆弱なネームサーバの存在が報告されている。

　このように、Kaminsky Attack公表から早くも半年近くが経過しているにもかかわらず、脆弱なネームサーバが多数存在するのはなぜだろうか？　検索エンジンの検索結果から得られたドメインを幾つか無作為に調査したところ、脆弱なネームサーバが見つかった（※4）。脆弱なネームサーバが登録されていたドメインを調べてみると、ほかにも脆弱でないネームサーバ（対象ドメインに関係のないネームサーバ）が登録されていた。脆弱なネームサーバが数多く存在するのは、DNS運用を外部委託しているため、自社で運用しているネームサーバの管理が行き届いていないからだと考えられる。キャッシュポイズニングは“現在進行形”の脅威なのだ。

※4：ラックでは、発見した脆弱なネームサーバはしかるべき手順で報告する予定である。なお、脆弱なネームサーバを確認する際には、IPAが公開している確認手順を実施した（関連記事参照）。

DNSを守れ！　企業が実施すべきセキュリティ対策

　ファーミングの脅威に対抗するため、図3のような対策が考えられる。なお、本来であれば、キャッシュポイズニングへの対策にはDNSの拡張仕様である「DNSSEC（Domain Name System Security Extensions）」（※5）が最も有効だ。だが、DNSSECはDNS全体で実装されないと十分な効果を得られないため、執筆時点では現実的な対策ではないとして除外した。

図3●企業で実施するDNS脅威への対策例

※5：DNSの回答に電子署名を付与し、回答の完全性を維持するDNSのセキュリティ拡張仕様。

　まず何よりも実施すべきなのは、DNSサーバソフトウェアのバージョンアップ。だが、これだけでは不十分である。キャッシュポイズニングはDNSの仕様上の脆弱性であるため、サーバソフトウェアを最新バージョンにしたからといって、対策できるというものではない。実際に最新のDNSサーバソフトウェアへのキャッシュポイズニングの成功事例も報告されている。そこで、バージョンアップに続いて実施すべきなのは、DNSプロトコルでのアクセス制御である。具体的には以下の項目となる。

　IPAへ報告された脆弱なネームサーバは、インターネットから検査用ネームサーバへの再帰問い合わせを実施し、その回答から脆弱であると判断されたと考えられる。つまり、いまだインターネットからの再帰問い合わせを要求するネームサーバが数多く存在するというわけだ。再帰問い合わせが可能という時点で、キャッシュポイズニングが成功する可能性がある。

　コンテンツサーバについては、本来再帰問い合わせが必要ないため、再帰問い合わせを無効にすべきだ。可能ならば、コンテンツサーバ、キャッシュサーバを機能的に分離するのが望ましい。サーバ運用コストとの兼ね合いで分離が困難な場合、再帰問い合わせにはイントラネットからのみ許可するといった、DNSの設定によるアクセス制御を実施していただきたい。

　DNSのアクセス制御により、インターネットからのキャッシュポイズニングにはある程度対抗できるはずだが、イントラネットからキャッシュポイズニングへの対策とはなりにくい。内部からのキャッシュポイズニングについては、ネットワーク構成で偽装パケットを遮断するのがよいだろう。Kaminsky Attackでは大量の偽装パケットがネームサーバに対して送信される。もし内部に犯人がいた場合、内部犯が所属するネットワークとは異なるIPアドレスの偽装パケットが送信される。そこでネームサーバを独立したネットワークに設置し、途中経路にファイアウォールを設置すれば、偽装パケットを遮断することも可能だ。

セキュリティ機器による補助対策も有効

　こうしたDNSサーバソフトウェアの最新版へのバージョンアップ、コンテンツサーバ、キャッシュサーバの分離などの対策は必ずしもすぐに実施できるわけではないだろう。そのため、これまで紹介したセキュリティ対策とともに、DNSトラフィックのモニタリングの実施を提案したい。これは補助的な対策なので脅威自体を防ぐことはできないが、その発生を検知することができる。

　自社ネットワークに不正侵入検知システム（IDS：Intrusion Detection System）／不正侵入防御システム（IPS：Intrusion Prevention System）を既に導入している場合、製品によってはキャッシュポイズニングを検知するシグネチャ（※6）が用意されているので、これを利用する方法もある。これらのシグネチャを有効にすることで、キャッシュポイズニングの発生を検知できる。ただし、IDS／IPSのシグネチャはDNSの問い合わせや回答が一定数発生したら、キャッシュポイズニングの“可能性”があるとして警告を発するものだ。運用する際は、定常的に発生するDNSトラフィック量を把握し、どれだけのDNS問い合わせ／回答が発生したら「異常」と見なすのかを定義する必要がある。

※6：不正な通信を検知するためのパターンマッチング文字列。

　IDS／IPSを導入していない場合は、DNSサーバソフトウェアの統計情報を利用するとよいだろう。DNSサーバソフトウェアでは、DNSの問い合わせ数・回答数といった統計情報を取得できる（※7）。先述したKaminsky Attackでは、存在しないホスト名の問い合わせが大量に発生する。存在しないホスト名の問い合わせがあった場合、ネームサーバでは“存在しない”という回答を返す。DNSサーバソフトウェアの統計情報において、“存在しない”回答数を監視し、回答数が急増したら警告を発するという仕組みが有効だと考えられる。

※7：DNSサーバソフトウェアのBINDであれば、「rndc stats」コマンドで統計情報が得られる。

　いずれの仕組みにおいても、キャッシュポイズニングの発生を検知したら、キャッシュサーバのキャッシュ情報を削除するという（強引ではあるが）暫定的な対策が取れるだろう。DNSサーバソフトウェアのバージョンアップといった根本的な対策が完了するまでの一時的な対策としてご検討いただきたい。

　今回紹介したセキュリティ対策は、DNSにおける基本的なセキュリティ設定だと思われるかもしれない。だが筆者は、この当たり前の対策ができていないネームサーバが予想以上に多いのではないかと危惧（きぐ）している。読者の皆さんが利用しているネームサーバに脆弱性がないか、ぜひ一度確認していただきたい。