インターネットで、例えば www.nire.com というドメイン名を、実際にサーバーに割り当てられた IP アドレスに名前解決するのに使われるのが DNS サーバです。では、プロバイダが運用している DNS サーバのセキュリティホールを突かれて、偽の答えを返すようになっていたら…。いくら入力した URL が正しくても、開いた Web ページの内容は、本物そっくりに作られた悪意ある Web コンテンツかもしれません。

DNS キャッシュとは

例えば microsoft.com や google.com のような、プロバイダの契約者が頻繁にアクセスするであろうドメイン名は、そのたびにいちいち問い合わせにいっていては、相手の DNS サーバに負担をかけます。またドメイン名と IP アドレスの対応関係は、一部の特殊な使い道を除いてそんなにコロコロ変わるものではありません。クライアント側のプロバイダの DNS サーバにコピーを持っておいて、一度照会されたドメイン名は、指定された「賞味期限」内ならそのコピーを見に行くようにすれば、クライアントだってより速く返事をもらえます。これが DNS キャッシュです。

それを汚染する DNS キャッシュ ポイズニング

ところが、DNS サーバのキャッシュ ポイズニングという、DNS サーバ攻撃の手法があります。キャッシュを「汚染する」この方法、悪意をもった攻撃者が、DNS クライアントからサーバへの問い合わせに対して偽の情報を「下手な鉄砲も数打ちゃ当たる」で手当たり次第に返します。ある確率でそれは成功して、偽データをキャッシュしてしまうことになります。

そこから先どう悪用するかはいろいろな方法がありますが、Web ブラウザでショッピングサイトに接続しに行ったとして、偽の IP アドレス、偽のサイトに誘導されたことに気づかない利用者が ID / パスワードを入力すると、まったく違う第三者にまんまと入手されフィッシング詐欺の餌食になるわけです。

一般的な対策

この DNS キャッシュ ポイズニング、決して新しい手法というわけではなく、対応方法もいくつか提案されています。ただ、根本的な対策というわけではなく、たまたま偽 DNS サーバから送られてきたパケットの「つじつま」が合ってしまう確率を下げるための方法です。

DNS クライアント側

  • 上位の DNS サーバに問い合わせる際の発信側ポート番号 (source port) を毎回ランダムにする
  • DNS クライアントとサーバの間で NAT を経由している場合は、NAT が使用するポート番号も毎回ランダムにする

DNS サーバ側

  • セカンダリ DNS サーバの数を増やす
  • TTL を長くする
  • キャッシュサーバにするつもりがない DNS サーバでは機能を OFF にする (Bind なら recursion: no)

問題点自体は 2002年11月19日の US-CERT あたりから指摘されていて、無駄なキャッシュサーバ機能は OFF にするべき、なんていうのはこの頃から言われているのですが、2008年7月にダン・カミンスキー (Dan Kaminsky) 氏が新たな攻撃手法を含めた発表を行うのに先だって、DNS サーバの各実装がいっせいにパッチを提供したということのようです。

続き: 対策方法が残念なヤマハの RT ルータの DNS キャッシュ ポイズニング対策