
後編 DNSキャッシュポイズニングの原因・対策・その理由
藤川 浩一
Infoblox株式会社
Professional Service Engineer
2008/9/24
パッチの適用は急務としても、これだけでは確実に脅威がなくなるわけではないのがこの問題のポイントです。しかし私たちにはまだできることがあります。後編では6つの対策ポイントを提示し、現時点におけるベストプラクティスを考えます。(編集部)
前編「カミンスキー氏が発表した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点です。
- キャッシュサービスを利用するDNSサーバに、対応パッチを適用する
- キャッシュDNSサーバの設定を確認/変更する
- 外部DNSサーバの再帰問い合わせ機能を無効化あるいは制限する
- 2重化されたキャッシュDNSサーバを新規に導入する
- 内部キャッシュDNSサーバに届くDNSクエリを、2重化したキャッシュサーバに転送する
- メールサーバ等、DMZ内サーバのDNSクエリを、2重化したキャッシュサーバに向ける
- キャッシュDNSサーバがインターネットに出るときのNATアドレスは、そのほかの通信とは別のIPアドレスを利用させる
- 外部向けのAuthoritative DNSサーバを増設し、ヒドゥンプライマリ構成に変更する
- 監視マネージャにより、サーバの死活監視、リソース監視を徹底する
これらを以下の6つの対策にまとめました。
- 対策1:何はなくともパッチは適用する
- 対策2:設定ミスを撲滅する
- 対策3:外部向けDNSサーバを増やす
- 対策4:ネットワーク担当者、セキュリティ担当者も関係者という空気をつくる
- 対策5:メンテナンスしやすい環境をつくる
- 対策6:日々の監視を行う
では、これらの変更理由とそのポイントについて、対策を1つずつ確認してみましょう。
| ←前編へ | 1/4 |
| Index | |
| DNSキャッシュポイズニングの原因・対策・その理由 | |
| Page1 DNSキャッシュポイズニングの本質的な問題点 あるべきDNSサーバ構成 |
|
| Page2 対策1:何はなくともパッチは適用する 対策2:設定ミスを撲滅する 対策3:外部向けDNSサーバを増やす |
|
| Page3 対策4:ネットワーク担当者、セキュリティ担当者も関係者 対策5:メンテナンスしやすい環境をつくる |
|
| Page4 対策6:日々の監視を行う 時代とともに変わる「ベストプラクティス」 |
|
| Security&Trust記事一覧 |
TechTargetジャパン
- 実録、「Hardening Zero」の舞台裏 (2012/5/25)
コラムの更新頻度を落として何をやっていたかって? 「守る技術」に焦点を当てたこんなイベントを開催しました - 複雑化、巧妙化する脅威への対策は? (2012/5/23)
データ保護や標的型攻撃対策、クラウドセキュリティ……「第9回 情報セキュリティEXPO」の会場で見つけた製品を一挙に紹介 - 仮想化がはらむ新たなリスク (2012/5/17)
仮想化に伴って生じるセキュリティやパフォーマンスへの影響を慎重に考慮し、うまく制御していく方法を紹介します - 新入生も新入社員も勉強会に寄っといで! (2012/5/14)
週末ともなれば至るところでセキュリティ系勉強会やCTFなどのイベントがあり、ツイートも盛り上がりました
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -

