DNSキャッシュポイズニングの原因・対策・その理由：DNSキャッシュポイズニングの影響と対策（後編）（2/4 ページ）
パッチの適用は急務としても、これだけでは確実に脅威がなくなるわけではないのがこの問題のポイントです。しかし私たちにはまだできることがあります。後編では6つの対策ポイントを提示し、現時点におけるベストプラクティスを考えます。（編集部）
対策1：何はなくともパッチは適用する
DNSサーバソフトウェアを提供する会社や組織は2008年8月に本脆弱性に対するパッチを提供していますので、早急にこれを適用するべきです。
パッチ未適用のBINDを例に取ると、UDPによるDNSクエリを行う場合に利用するSourceポート番号が適切にランダム化されないために、攻撃時に詐称すべきSourceポート番号を容易に類推することが可能となり、結果的に攻撃成功確率を向上させてしまいます。
また、パッチを適用しても設定が誤っている場合は、パッチ適用による効果が無意味になってしまうため、ここにも注意が必要です。BINDを利用している場合は、次の設定を必ず確認してください。
●named.confの内容
Options {
:
query-source address * port *;
:
}
query-source設定でport 53など、何らかのポートが明示的に指定されている場合は該当項目と、ファイアウォールなどによるOutgoing通信の許可を修正してください。query-source設定でportが明示的に指定されている場合は、そのポート番号のみを利用してDNSクエリを行うこととなります。そのため攻撃成功確率は飛躍的に高まってしまうのです。
もし、ポート番号が正常にランダム化されていれば、攻撃の成功確率は劇的に低下します。
対策2：設定ミスを撲滅する
管理者の無知、怠慢、システムへの過小投資、そのほか政治的な理由……さまざまな原因があることは察しますが、不要なネットワークからの再帰問い合わせを許しているDNSサーバがいかに多いことか。仕事柄多くのDNSサーバを目にしてきましたが、いかなる理由があるにしろ再帰問い合わせ可能（Open Recursion）なDNSを放置していることは、自殺行為であり犯罪行為といっても過言ではありません。
インターネットからの不要な再帰問い合わせ制限を行いましょうと、さまざまなWebサイトやメーリングリストであれだけ話題になっているにもかかわらず、どうしてこれが浸透しないのか、非常に疑問を感じてしまいます。
本脆弱性を突いた攻撃を行うためには攻撃者が再帰問い合わせによるDNSクエリを行えることが前提条件となるため、不要なネットワークからの再帰問い合わせを拒否することは、本脆弱性に対する対応として非常に重要となります。
DMZ上で自ドメイン情報を公開するAuthoritative DNSサーバで再帰問い合わせを行わざるを得ない場合は、BINDであればView機能を利用することで再帰問い合わせを利用できるネットワークを制限できます。
しかし、コンテンツDNSサーバとしての機能と、キャッシュDNSサーバとしての機能は併用しないことがセキュリティ上望ましいのはいうまでもありません。再帰問い合わせを許可するネットワークの設定の誤りなど、人為的ミスにより攻撃を許してしまう可能性や、再帰問い合わせを許可したネットワークのアドレスを詐称した攻撃が行われる可能性は、決してゼロではないのです。
●named.confの内容
Options {
:
recursion no;
query-source address * port *;
:
}
そのため、対策後のDNSサーバ構成では図3のように、あえてDMZ上のAuthoritative DNSサーバでは再帰問い合わせを無効化しています。そしてDMZ上のメールサーバが参照するキャッシュDNSサーバを、外部向けAuthoritative DNSではなく、そのほかのキャッシュサーバに向け、継続して再帰問い合わせができるようにします。
対策3：外部向けDNSサーバを増やす
この構成では、アドレスを詐称されないためにDMZに配置する外部向けDNSサーバを増やしています。これは、本脆弱性の攻撃に必要な詐称DNS応答を生成しにくくする、という点において重要な役目を果たします。
攻撃者が汚染したいDNS情報は、あなたが保有するドメインやDNSレコードではありません。より世の中に知れ渡った大きなサービスのドメインやDNSレコードなのです。攻撃者は最初のANSWER SECTIONを生成しやすいドメインを踏み台として利用することで、その目的を果たそうとするのです。
ここで攻撃の成功確率を思い出してみましょう。
P（t）：攻撃成功確率
P（s）：1回のクエリで攻撃が成功する確率
t：攻撃持続時間
Rr：（1クエリ当たりの）応答攻撃レート
Rq：クエリ攻撃レート
W：正規応答が返ってくるまでのRTT
N：攻撃対象のレコードを保持するネームサーバ（Authoritative DNSサーバ）数
Port：Query portの数（固定ポートの場合1）
ID：DNSのID（16bit = 65536）
図2 攻撃成功確率
NTT情報流通プラットフォーム研究所 豊野剛氏
“DNS Cache Poisoningの概要と対処”より引用
攻撃成功確率P（t）を低減させるためには、N×Port×IDにより導き出せる分母の数をいかに大きくするか、そしてRr×Wにより導き出せる分子の数をいかに小さくするか、にかかってきます。
DNS管理者が操れる数字は、DNSサーバ台数を表すNと、正規応答が返ってくるまでのRTTを表すWしかありません。それ以外の数字はDNSのプロトコル仕様により上限が決まっており、攻撃者の“粘り方”次第で変動します。
パッチの適用でPortは非常に大きくなりましたが、今後コンピュータの性能がより向上した場合は、おそらくこれだけでは攻撃を防ぎきれないでしょう。そのため、正規応答を返す外部DNSサーバの数を増やすことは、最も効率のよい防御策になり得ます。
DNSサーバの応答速度を速めることも有効ですが、そのためにはインターネットへの接続回線速度や、DNSサーバ性能を垂直的にスケールアップする必要があるため、現在のネットワークサービスコストやハードウェアのコストを考慮すると、割高になりがちです。NSレコードを登録するDNSサーバ数を2台から3台、4台に増やすだけで、攻撃者はその分の詐称応答を生成しなければならなくなります。
外部DNSサーバを増やし、自分のドメインを守ることは、ひいてはほかのDNSサーバを守ることにもつながり、結果的にインターネットを守ることにもつながるのです【注】。
【注】
この点を考慮して、WHOIS登録の段階で3台以上のネームサーバを登録することを強く推奨する方向に各NICが動きだしてくれれば、より確実なのかもしれません。
なお、ヒドゥンプライマリ構成にしているのは、単純にゾーンメンテナンスの容易性を考慮したためで重要な意味はありませんが、こういうバックグラウンドづくりは今後の運用を考慮すると非常にメリットが大きいと考えます。
【関連記事】
もう一度見直したいDNS／DHCP
第2回 DNSベストプラクティスとは「隠す」そして「重ねる」
http://www.atmarkit.co.jp/fsecurity/rensai/corenet02/corenet01.html
Copyright © ITmedia, Inc. All Rights Reserved.