パッチの適用は急務としても、これだけでは確実に脅威がなくなるわけではないのがこの問題のポイントです。しかし私たちにはまだできることがあります。後編では6つの対策ポイントを提示し、現時点におけるベストプラクティスを考えます。(編集部)
前編「カミンスキー氏が発表したDNSアタック手法と対策例」に続き、DNSキャッシュポイズニングの対策を解説します。その前に、根本的な解決策はあるのかどうかを考えてみましょう。
【関連記事】
Infoblox リチャード・ケーガン氏インタビュー
DNSアタック、技術者がまずすべき3つの対策(@IT NewsInsight)
http://www.atmarkit.co.jp/news/200809/19/infoblox.html
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サーバ構成との違いは、次の9点です。
これらを以下の6つの対策にまとめました。
では、これらの変更理由とそのポイントについて、対策を1つずつ確認してみましょう。
Copyright © ITmedia, Inc. All Rights Reserved.