Tips: DNS Cache Poisoning攻撃

細かい内容は DNSのプロトコルを知らないと理解できないので、以下は概説。

1. どういう攻撃なの?

粗っぽく言うと、Webをアクセスするために人間が使っている名前(たとえば eip.econ.kanagawa-.u.ac.jp)を、実際にコンピューターが通信するための数字だけのアドレス(IPアドレス)に変換するシステムが DNS。当然、誰かがその変換表を用意しておくのだが、DNSの仕組みでは全体の変換表を一括して管理するというシカケではなく、細かくブロック化して、ブロックごとに管理するシカケになっている。たとえば、eip.econ.kanagawa-u.ac.jpという名前をどのような IPアドレスに変換するかを管理しているのは、133.72.3.15, 133.72.3.16, 133.72.191.22 という 3カ所のシステム。ここでは、このよな変換表を管理している権威あるサーバのことを「コンテンツサーバー」と呼ぼう。

DNSのシカケでは、コンテンツサーバーとネットワークの負荷を下げるために、一度問い合わせて結果を得た変換についてはしばらく覚えておく(cacheしておく)シカケが利用者とコンテンツサーバーの間に入っている。これを、ここでは「キャッシュサーバー」と呼ぶ。つまり、キャッシュサーバーが覚えている(cacheしている)情報については、わざわざコンテンツサーバーに再度問い合わせないシカケである。ここが、攻撃のミソ。

何らかの方法でキャッシュサーバーに嘘の変換表を覚えさせることができれば、ユーザーはキャッシュサーバーが答える嘘情報でIPアドレスを得て、そこにアクセスすることになる。このような攻撃を DNS Cache Poisoning攻撃と呼ぶ。この攻撃は DNSのプロトコル自体の脆弱性に起因するのでそう簡単に回避できない。

2. なんで今更問題になってるの?

従来も DNS Cache Poisoning攻撃用のツールはいくつか存在したが、攻撃が成功する確率が低かったためそれほど大騒ぎにはなっていなかった。しかし、最近新たなプロトコル上の脆弱性が発見されて、攻撃の成功確率が急上昇し、現実的な脅威としての対応が必要になった。詳しい内容が知りたければ、Dan Kaminskyでググれ。

3. なんで https限定にしたの?

上述のように、DNSが信用できない可能性が高まったため、名前によるアクセスはどこにアクセスしているかが現時点ではあまり信用できない。そのため、データの出所をDNS以外のシカケ、具体的には証明書を使って保証できるように、アクセススキームを httpsに限定した。

なお、本サイトの内容はもともと全部公開情報なので、httpsの採用による暗号化の意味は全くない。証明書を確認することによって、どのような組織が情報提供しているかを(信用できない DNSを使ってではなく)明らかにすることが目的。オレオレ証明書サイトとは発想が正反対なので注意されたい。

オマケ. 本気でアタックされると思ってるの?

もちろん、思っていません(笑)

DNS Cache Poisoning攻撃をしてまで、本サイトへのアクセスをフィッシングサイトへ誘導するという行為に何らかの合理性があるとはとても思えませんし、多分実際にアタックする人はいないでしょう。本気でやるなら、httpでアクセスできるのに認証が必要でユーザーが多いSNSあたりが狙い目だと思います。しかしながら、追加的なコストは実質ゼロで、情報の出所を明らかにできる技術的な手段が存在する以上、対策しておく方が望ましいとサイト運用者が考えているだけです。

# 検索サイトでの順位が下がってきていることがアクセススキーム制限と関係があるのだとしたら、SEO的には大きなコストかもしれない。本サイトの場合は関係ありませんが(笑)