DNSキャッシュポイズニングの原因・対策・その理由：DNSキャッシュポイズニングの影響と対策（後編）（1/4 ページ）

パッチの適用は急務としても、これだけでは確実に脅威がなくなるわけではないのがこの問題のポイントです。しかし私たちにはまだできることがあります。後編では6つの対策ポイントを提示し、現時点におけるベストプラクティスを考えます。（編集部）

[藤川浩一，Infoblox株式会社]

　前編「カミンスキー氏が発表したDNSアタック手法と対策例」に続き、DNSキャッシュポイズニングの対策を解説します。その前に、根本的な解決策はあるのかどうかを考えてみましょう。

【関連記事】

Infoblox リチャード・ケーガン氏インタビュー

DNSアタック、技術者がまずすべき3つの対策（＠IT NewsInsight）

http://www.atmarkit.co.jp/news/200809/19/infoblox.html

DNSキャッシュポイズニングの本質的な問題点

　DNSキャッシュポイズニングの本質的な問題点は、利用可能なトランザクションIDの総数が16ビット（65536）であるDNSのプロトコル仕様が、時代の変遷により貧弱となってしまったことにあります。DNSの仕様が確定した時代、コンピュータの性能がいまよりずっと貧弱な時代では、確かにこのような仕様でも十分だったのかもしれません。

　しかし、コンピュータとネットワークの性能が飛躍的に向上したことは誰の目にも明らかで、近所の家電量販店で20年前のスーパーコンピュータ以上の性能を持つパソコンや、当時では考えられなかったGigabit Ethernet機器を手軽に買えるようになり、そして100Mbpsの超高速なインターネット接続環境が普及した現在では、現状のDNSプロトコル仕様が貧弱になってしまった事実は否めません。

　とはいえ、ここでDNSプロトコルの仕様を拡張することはあまりにも非現実的です。そしてDNSSECの利用でこの問題を解決することが可能であることも指摘されていますが、どちらにしても多くの労力と時間がどうしてもかかることでしょう。

　DNSプロトコルの仕様変更を行った場合、その普及に必要な時間はネットワークをIPv4からIPv6に移行するくらいかかりそうなことは、想像に難くありません。有力視されているDNSSECもまた、現時点ですべてのDNSサーバで利用されているわけでもなく、そもそも実装されていないことさえあり得ます。仕事柄多くのDNS環境を目にしてきましたが、2008年の現在でもBIND4が動いていたりする環境を見ると、これはもうDNSSECの普及以前の話だな、と正直感じてしまうのです。

　その上で、筆者は次のように考えます。

　脆弱性があるにしろ、今はこのプロトコルとソフトウェアを利用し続けなければ、仕事にもプライベートにも、多くの影響を及ぼしてしまいます。仕様や実装の脆弱性を嘆き悲しんだり怒るより、まずはできるだけの対応を迅速に行い、そして今後このような仕様やソフトウェア実装の問題が発生したときに備え、より迅速に、より効率的に対応ができる準備をしておくことが重要なのではないのか、と。

　実装にも普及にも時間がかかりがちな次世代技術の導入に向け、確実に安全にアップデートできる環境を用意する、これは企業ネットワークを考えるうえでも、組織を運営していくうえでも、とても重要なことであると考えています。

　最小限の投資で最大限の効果を、とは昔からよく聞くセリフですが、ことDNSに関しては最小限にも達しない投資しかされてこなかったのではないでしょうか。

【関連記事】

実用 BIND 9で作るDNSサーバ

第13回　次世代のセキュリティ拡張DNSSECをBIND 9で実現

http://www.atmarkit.co.jp/flinux/rensai/bind913/bind913a.html

あるべきDNSサーバ構成

　前編の最後で、DNS脆弱性対策のほかに将来的なメンテナンスやセキュリティ対応に備え、下記のようなDNSサーバ構成をご紹介しました。

図1　対策後のDNSサーバ構成

　一般的なDNSサーバ構成との違いは、次の9点です。

1. キャッシュサービスを利用するDNSサーバに、対応パッチを適用する
2. キャッシュDNSサーバの設定を確認／変更する
3. 外部DNSサーバの再帰問い合わせ機能を無効化あるいは制限する
4. 2重化されたキャッシュDNSサーバを新規に導入する
5. 内部キャッシュDNSサーバに届くDNSクエリを、2重化したキャッシュサーバに転送する
6. メールサーバ等、DMZ内サーバのDNSクエリを、2重化したキャッシュサーバに向ける
7. キャッシュDNSサーバがインターネットに出るときのNATアドレスは、そのほかの通信とは別のIPアドレスを利用させる
8. 外部向けのAuthoritative DNSサーバを増設し、ヒドゥンプライマリ構成に変更する
9. 監視マネージャにより、サーバの死活監視、リソース監視を徹底する

　これらを以下の6つの対策にまとめました。

• 対策1：何はなくともパッチは適用する
• 対策2：設定ミスを撲滅する
• 対策3：外部向けDNSサーバを増やす
• 対策4：ネットワーク担当者、セキュリティ担当者も関係者という空気をつくる
• 対策5：メンテナンスしやすい環境をつくる
• 対策6：日々の監視を行う

　では、これらの変更理由とそのポイントについて、対策を1つずつ確認してみましょう。

←前編へ