ソフトウエア・ベンダー各社は2008年7月8日，DNSキャッシュ・ポイズニング攻撃を防ぐため，DNS用ソフトウエアのUDPソース・ポート割り当てがランダムになるよう改善する，セキュリティ・アップデートをリリースした（関連記事：複数のDNSサーバー製品にキャッシュ・ポイズニングのぜい弱性―パッチ適用を）。翌9日には，「imipack」と称する人物がセキュリティ関連メーリング・リストFull Disclosureに非常に興味深い現象の情報を投稿した。imipack氏がファイアウォールの背後にアップデート適用済みDNSサーバーを配置してネットワーク・アドレス変換（NAT）を実行したところ，同サーバーから返されるDNSトランザクションのUDPソース・ポートは，相変わらず連続するポートが割り当てられていたという。
セキュリティ業界がこの影響を完全に理解しているかどうかは定かでない。そこで，imipack氏の投稿に注目してもらう目的でこの記事を書く。我々が知る限り，この現象はimipack氏がテストしたファイアウォールだけでなく，あらゆるNAT機器で起こり得る。ネットワーク・アーキテクチャに重大な影響を及ぼすと考えられる（記事末尾に追加した最新情報を参照）。
ネットワーク上のホストがUDP要求に対応するソース・ポートを選ぶ際，ホストごとに専用のポートを選択する。ネットワーク通信で1対多の隠ぺいを行うNAT機器は，ネットワーク内の各ホストに専用ポートを割り当てる必要があるので，UDP要求を受信して転送する際には新たなソース・ポートを割り当てなければならない。市場に出回っているNAT機器でUDPソース・ポートをランダムに選択するものは存在しない。したがって，アップデート適用済みDNSクライアントとDNSサーバーがNAT機器の配下にある場合，DNSキャッシュ・ポイズニング攻撃に対してぜい弱なままである。最新のアップデートで導入されたソース・ポートのランダム性は，NAT機器で失われてしまうのだ。
NATの配下にあるDNSキャッシュ・サーバーがある場合，ネットワーク管理者はこのキャッシュ・サーバーをDMZに移動し，インターネット用の固有IPアドレスを直接割り当てた方がよいだろう。NAT配下にあるサーバーは，アップデート適用後もぜい弱性が残っている。当研究所では，今週DNSキャッシュ・ポイズニング攻撃に対するメディアの注目が高まる影響で，これから数カ月にわたって攻撃の頻度が増えかねないと考えている。
NAT機器がUDPソース・ポートをランダムに割り当てるべきかどうかについても，疑問に思っている。このような対応を行っているベンダーは今のところない。DNSクライアント・ソフトウエアの一部は7月9日にアップデートされ，NAT配下外に移されるDNSサーバーもあるだろうが，クライアントは引き続きNAT配下にとどまらざるを得ない。
クライアントのセキュリティ確保にUDPポートのランダムな割り当てが必要ならば，NAT機器もそのランダム性を維持するべきだという見方がある。ただし，この提案はNAT機器ベンダーから見て現実的でないだろう。NAT処理の性能低下という懸念があるし，ポート割り当て処理がベンダーの制御下にないソフトウエアで実行されるという理由もあるからだ。今後数カ月で，ベンダー各社がこの問題にどう取り組むか興味深い。
（今回の投稿に協力してくれたJonathan Lusky氏に感謝する）
補足情報
上の文章をFull Disclosureに投稿してから数時間後， Riad S. Wahby氏を含む多くのMLメンバーがipchainsを設定したLinuxボックスをテストしたところ，同ボックスの配下にあるクライアントでUDPソース・ポートの選択結果が変更されなかった，と投稿してくれた。ipchainsがコリジョン発生時にどう反応したか不明だが，大半のケースでクライアントによるポート選択のランダム性が維持されるため，これは一般的によい戦略だと思う。コリジョン時の反応を調べ，不手際な対応が重大なセキュリティ問題につながることを示そうとすると，ランダムに選択されたソース・ポートで頻発に衝突を起こさなければならない。それには同時発生するUDPトランザクションを大量に作る必要があり，実行は難しい。
また複数のMLメンバーから，われわれが紹介したファイアウォールと別の機器でも同様の動作を確認したとの連絡をもらった。各種NAT機器でどのようなコリジョン回避策を取り入れているのか，高負荷となった際にどう動くのか，セキュリティ上どのような影響があるのかなど，いくつか調べてみる余地はありそうだ。幸運なことに，現在のところLinuxは問題がないようで，NATベンダーにとっては調査の手がかりとなる。
Copyrights (C) 2008 IBM, Corp. All rights reserved.
本記事の内容は執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。
◆この記事は，日本IBMの許可を得て，米国のセキュリティ・ラボであるIBM Internet Security Systems X-Forceの研究員が執筆するブログIBM Internet Security Systems Frequency-X Blogの記事を抜粋して日本語化したものです。
オリジナルの記事は，More on DNS Cache Poisoning and Network Address Translationでお読みいただけます。
