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

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

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

対策4：ネットワーク担当者、セキュリティ担当者も関係者

　ファイアウォールやルータでNAPTを利用している場合は、これら機器のファームウェアやOSのアップデート、ひいてはIPアドレス構成も併せて考えるべきです。

　キャッシュDNSの通信や社内クライアントからの通信が、想定ネットワークのように1つのグローバルIPアドレスにまとめてNAPTを利用している場合、必然的に1システム当たりで利用可能なSourceポートの数が減ってしまうばかりでなく、ファイアウォールやルータの問題によりポートランダム化の効果が失われることもあり得ます。

　せっかくパッチを適用してキャッシュDNSサーバがSourceポート番号をランダムに送信しているのに、ファイアウォールやルータがSourceポート番号をシーケンシャルに変換して送信したり、利用するSourceポートの数を著しく制限してしまった場合、これもまた攻撃の成功確率を高めてしまいます。

　古いバージョンのファイアウォールやルータを利用している場合、今回の脆弱性に関連して、これらのファームウェアやOSのアップデートも、ぜひご確認ください。

対策5：メンテナンスしやすい環境をつくる

　対策後のDNS構成図（図1）では、内部キャッシュDNSサーバの上に、2重化されたDNSサーバをさらに配置しています。そしてDMZ上のメールサーバも、参照するDNSサーバを変更しています。

　内部キャッシュDNSサーバは社内クライアントやメールサーバから届くDNSクエリを、すべて2重化したキャッシュDNSサーバに対してクエリ転送を行います。これはキャッシュDNSサーバとコンテンツDNSサーバを物理的に分割してセキュリティを保つだけではなく、今回のようなDNSに関する脆弱性が再び発見された場合でもメンテナンスを迅速に実施するうえで、大きなポイントとなります。

　前編で示したような一般的なネットワーク環境であれば2台、現実的には10台、20台の内部キャッシュDNSサーバが存在することがあり得ます。今回のように何らかの脆弱性がDNSに見つかった場合、従来の構成では存在する内部キャッシュDNSサーバの数だけメンテナンスを計画、実施する必要がどうしても発生してしまいます。

　しかし、対策後のDNSサーバ構成では、キャッシュDNSサービスに問題が発生した場合、今後はこの2重化されたキャッシュDNSサーバをまずメンテナンスすればよいのです。内部キャッシュDNSサーバがWindowsサーバで構築されている場合は、Active Directoryのドメインコントローラも兼ねているケースが非常に多いものと思います。このようにDNSサーバがそれ以外のアプリケーションサーバを兼ねている環境でパッチを適用することを考えると、いくらその緊急性を理解できていても同一ホスト内で動作するほかのアプリケーションに対する影響を考慮しなければならず、迅速なパッチ適用が困難になってしまうでしょう。

　そのため、キャッシュDNSサービス以外のサービスを提供しない専用サーバを中間に挟むことで、容易にメンテナンスを実行できる環境を準備することは、結果として迅速にセキュリティ対策を打てる環境にもなり得るのです。

　このキャッシュDNSサーバを2重化する理由は連載「もう一度見直したいDNS／DHCP」でも触れているように、パッチ適用中のサービス停止に伴うアプリケーションの処理性能低下を最低限にとどめるためとなります。

　また、もし今後、コンテンツDNSサーバに問題が発生した場合、DMZ上の外部向けDNSサーバを先行してメンテナンスすることになりますが、その場合は、同様にコンテンツDNSサーバだけをメンテナンスすればよい、ということになります。単純にキャッシュDNSサーバとコンテンツDNSサーバを分離するだけでも、メンテナンスの際に必要になる注意点は少なくなるため、機能分離を明確化した構成はどのようなネットワークにおいてもメリットを出せるものと考えています。