カミンスキー氏が発表したDNSアタック手法と対策例：DNSキャッシュポイズニングの影響と対策（前編）（4/4 ページ）

2008年7月に公開されたDNSキャッシュポイズニングの脆弱性。DNSの仕様に深く関係するこの手法に対して、エンジニアはどのように対策を打つべきでしょうか。この脆弱性の本質的な問題と対策、そして私たちが考えなくてはならないセキュリティの心構えなど、2回に分けてお送りします（編集部）

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

攻撃成功率を低減するには？

　既存環境で可能な対策は、次の2点に尽きます。

1. 対策パッチを適用する
2. 設定ミスを撲滅する

　さまざまなニュースサイトやメーリングリスト、掲示板で話題になったように、この問題に対処するにはDNSサーバのパッチ適用が必須となります。また、BINDのパッチ適用の際にRPMなどのパッケージを利用すると強制的にnamed.confが変更されてしまうので、適用後は設定の確認も必須となります。

　そこで、次の2つのDNSサーバ構成を比べつつ、対策方法を考えてみることにしましょう。まずは一般的な構成を見ておきましょう。

図5　一般的なDNSサーバ構成

　これを、以下のような構成に変更します。

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

　2つのDNSサーバ構成には、大きな違いがいくつかあります。対策後のDNSサーバ構成では、下記の対策を行っています。

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. 監視マネージャにより、サーバの死活監視、リソース監視を徹底する

　これらの変更は、いずれも大きな意味を持ちます。一見するとこれらがどうして脆弱性対策となり得るのか、つながりにくい部分もあるかもしれません。これらの意味については、後編にて詳しく解説する予定です。それまでにぜひ、皆さまもその意味を想像してみてください。

後編へ→

Profile

Infoblox株式会社　Professional Service Engineer

藤川　浩一（ふじかわ　こういち）

DNS／DHCP／RADIUSのアプライアンスメーカーであるInfoblox株式会社に勤務し、コアネットワークシステムコンサルタント業務と、カスタムプログラムの設計業務を担当。

世界はたくさんの愛で満ちあふれていると信じてやまない乙女座O型 :-)

「DNSキャッシュポイズニングの影響と対策」バックナンバー

• DNSキャッシュポイズニングの原因・対策・その理由
• カミンスキー氏が発表したDNSアタック手法と対策例