11月 252011
 

Security Benefits
セキュリティ向上 

 http://code.google.com/intl/ja/speed/public-dns/docs/security.html

DNSサーバーに対して行われる攻撃として大きく2つあります。
ひとつは「DNSキャッシュポイズニング」、もうひとつは「DDosアタック」です。

DNSキャッシュポイズニングとは
利用するリゾルバ(前ページ「自組織にあるネームサーバー」)が権威DNSサーバーに名前解決を行い、通常であれば権威DNSサーバーからの回答待ち、権威DNSサーバーからの回答を利用するのですが、この「権威DNSサーバーからの応答」を偽って、誤った名前解決結果をリゾルバに渡し誤った情報をキャッシュさせることです。

名前解決の際にやり取りされる情報の中には「ID」と呼ばれる情報があり、「ID:12345」で問い合わせた場合、「ID:12345」をもった応答を問い合わせ結果として利用します。これは、問い合わせの際に指定したIDと一致するIDを持つ情報を名前解決結果として処理する仕様をついた攻撃方法です。

このIDはもちろんリゾルバが自由に指定できる(16bit)のですが、第三者がIDをランダムに指定した誤った情報をリゾルバDNSに大量に渡すことで、偶然にもIDが一致するという場合があります。この確率は「1/65,536」です。そうなると、第三者が誤った情報をリゾルバにキャッシュさせる事が出来ます。面白いことにDNSの名前解決結果の情報の接続元は何処でも良く、また仕様上接続元を名前解決後のデーターと共にリゾルバに渡さなければいけないという厳密なルールは有りませんので、誤った情報を受け取ったリゾルバも単純にIDがあっていれば信じるという動作を行なっています。

これにより起きるのが「DNSキャッシュポイズニング」です。
JPNICのページにわかりやすく説明が有りました。
○インターネット10分講座:DNSキャッシュポイズニング
http://www.nic.ad.jp/ja/newsletter/No40/0800.html

名前解決に利用されるパケットを理解するのに私は以下のページを参考にしました。
○An Illustrated Guide to the Kaminsky DNS Vulnerability(英語)
http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

DDosアタックとは
DDos(Distributed Denial of Service)アタックとは、大量の名前解決をリゾルバに行わせること、また名前解決の結果処理する必要があるデーター量が大きくなるような問い合わせを故意にと行い、DNSサーバーのリソースを利用しサービスに影響を与えるまたは停止させる攻撃のことです。特殊なパケットをDNSサーバーに処理させることでDNSサーバーを停止させるなどの脆弱性も過去に有りました。

上記2つの攻撃に対して100%防げる対策は今のところ無く、今現在でもDNSサーバーを攻撃される「可能性」は残っています。DNSサーバーを攻撃されないように運用するにはその可能性をできるだけ0%に近づけるために様々な設定が必要となります。

Google Public DNSがセキュリティ上どのような対策を行なっているかご紹介します。

1.上位DNSサーバーに問い合せを行う際に利用するアウトバウンドポートに53番を利用しない

「ID」が一致してしまえば正しい情報と認識してしまう仕様でありこの「ID」は16ビットで作成されるためランダムに生成したIDが一致する確立は「1/65,536」です。偶然IDを当てられたとしても、名前解決結果を待ち受けているポートに53番を利用せずGoogle Public DNSは32,000種類に及ぶの異なるポート番号を利用します。つまり、DNSキャッシュポイズニングを行いたい輩は、①「1/65,536」の確率でIDが合致させ、さらに②「1/32,000」の確率で偽りの情報を流し込むポート番号を的中させない限りキャッシュポイズニングが成立しません。その確率は「1/(65,536 × 32,000)」となり非常に小さい可能性であることがわかります。

2.利用する上位DNSサーバーをランダムに選ぶ

一般的にルートDNSに問い合わせて取得した権威DNSサーバーに名前解決する場合は、名前解決の速度が早いネームサーバーの情報に問い合わせを行いますが、Google Public DNSは対象となっている権威DNSからランダムに問い合わせ先を選出します。このランダムに選出した上位DNSサーバーからの応答のみを正しいおうとうとして処理します。名前解決の遅延が発生する心配がありますが、大抵の名前解決結果はGoogle Public DNS内にキャッシュされるためさほど心配は必要ありません。

3.名前解決対象のホスト名に文字文字を混ぜて上位DNSサーバーに問い合わせる

面白いことに、名前解決対象のホスト名に大文字と小文字を含めると、ほとんどの場合、そのままのホスト名を用いて返答が行われます。「Blog.TRippYbOY.cOM」を問い合わせれば、戻ってくる回答は「Blog.TRippYbOY.cOMは・・・・」という同じホスト名を用いた回答になります。この仕組みを利用してGoogle Public DNSは、上位DNSに問い合わせを行う際にホスト名に大文字小文字を含んで問い合わせを行います。回答に指定した大文字小文字を含んだ同じホスト名を含んで居ない場合は不正な情報として扱います。

大文字小文字を混ぜても、回答が小文字のみの回答(「blog.trippyboy.comは・・・」)を送ってくる上位DNSももちろん存在しますので、それらに関しては別途リスト化して情報をまとめているようです。

4.名前解決対象ホストに一意の文字列を付与する

特定のホスト名の名前解決を行う際にまずは対象のホストのネームサーバー(権威DNS)を確認する必要があります。この時に単純に「blog.trippyboy.comのNSは?」と聞くことも出来ますが、わざと一意な文字列をホスト名に追加し「entriih-f10r3.blog.trippyboy.comのNSは?」などとすることでGoogle Public DNSから行なった名前解決への応答を見分けられるようにします。ここでの目的は権威DNSを見つけるためだけですので、対象のホストが名前解決できなくても権威DNSサーバーさえ確認できれば問題ありません

5.重複する名前解決クエリを削除する

Google Public DNSから上位DNSサーバーに行う名前解決数が多ければ多いほど、別の言い方をすると、Google Public DNSが外部サーバーに情報を求める機会が増えるほど、DNSキャッシュポインズニングを行われる可能性は高くなります。従って同じ内容の名前解決を何度も行わず、同時に同様の名前解決のクエリが来た場合は重複するものを削除することで上位DNSサーバーへのクエリ回数を減らします。また、既述の通りキャッシュするのでこれまた良しですね。

6.クライアントからの名前解決回数、Google Public DNSから上位DNSへの名前解決回数の制限

DDos攻撃に対しての対策として同じ接続元からのクエリ検索、上位DNSへのクエリ回数を独自にカウントし、以上に多いものやデーター転送量など(詳細は非公開)を元に不正であるという判断を行い制限を行なっています。

7.需要がいホスト名のレコードは常にキャッシュしている

仮にDDos攻撃を受けサービス提供が難しくなった場合でも、需要が高いホスト名に関しては常にキャッシュしておくことで、上位DNSサーバーに問い合わせが行えない状況に陥ったとしても、影響を最小限にとどめるよう対策が取られています。

以上となります。

まとめると、Google Public DNS

  • 無料で利用出来る
  • 多くのホスト名を前もってキャッシュしているため名前解決が早い
  • セキュリティ対策が十分に施されている

なので、いいんですね。

これ書くのに3日間勉強しました。
おかげでDNSキャッシュポイズニングの仕組みを理解できました。
情報源を確認せずにIDが一致すれば良い仕様だなんて・・・。

改めてインターネットの歴史って浅いんだなって痛感しました。
これから広がっていくであろうインターネットの世界の成長に期待します!

参考:

Google:Google Public DNS(英語)
http://code.google.com/intl/ja/speed/public-dns/

JPNIC:ドメイン名のしくみ
http://www.nic.ad.jp/ja/dom/system.html

JPNIC:インターネット10分講座:DNSキャッシュポイズニング
http://www.nic.ad.jp/ja/newsletter/No40/0800.html

An Illustrated Guide to the Kaminsky DNS Vulnerability(英語)
http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

以上

  8 コメント

  1. […] 参考:Google Public DNS を使う理由を学びました。ちゃんちゃん。の巻 (TrippyBoyの愉快な日々) […]

  2. こんばんは
    オープンリゾルバの対策をしてくださいとレンタルサーバーから連絡がありました。
    名前解決はバリュードメインのDNSサーバーを使ってるんでとめても問題ないと考えていたんですが、
    wp-login.phpにホスト名でアクセス規制、/etc/hosts.allowでホスト名を規制してますけど、これが全部アクセスできなく
    なってしまってえらいめにあいました。

    俺自身sshでログインできず。webminのtextログインから復旧させる始末です・・・。
    会社の環境は複数の回線と固定ipではないのでipのアクセス規制がむずかしいんですよね。

    俺の部屋の回線は固定ipができるかどうか頼んでみるつもりです。

  3. くりくりさん

    こんばんは!今日はありがとうございました。
    /etc/resolve.conf にてDNSの指定を解除したということですか!?(・・;)
    うまく読み取れていなかったらすいませんっ

    私はプロバイダのホスト名の末尾を用いて制限しています。
    wp-login.phpはBasic認証で保護して、sahに関してはポートの変更とswatchで動的にブロックをかけて/etc/hosts.allowで数回弾かれたIPはiptablesでDROPしてます。

  4. オープンリゾルバ対策する場合はnamed.confで再帰的問い合わせを禁止しました。
    recursion no;
    allow-query-cache { localhost; };

    この設定をいじっていたらアクセスできない事象が発生しました。
    それはそれでいいんですが、
    最近はネット経由でコンソール接続ができるのでそれを試してみたら出来ない!!

    今日一日メールでレンタルサーバーとやりとりです。
    bindは昔から苦手で困ったものです。

  5. くりくりさん

    ご自身のサーバー上にDNSを構築されて、かつサーバー自身の名前解決を構築されたDNSで行われている状況でrecursion no;にされたということでしょうか。これは外部サーバーに名前解決を行いに行かない設定と思われます。。問題になっちゃいますね(^^;;
    forwarderとしてGooglePublicDNSを指定されてみてはいかがでしょうか。

    サーバー自身の名前解決を自身のDNSにしないか
    DNSへ問い合わせる接続元を制限するか
    forwarderの設定をするかで対応できるかと思います!

  6. recursion no;危険ですよねw
    yesにして結局,iptablesでポート53をとじました。
    思い出したのが
    私の前の管理者がやはりnoにしていてyum updateがエラーはいてしまい。
    yesに変更したんですよ。

    >サーバー自身の名前解決を自身のDNSにしないか
    >DNSへ問い合わせる接続元を制限するか
    >forwarderの設定をするかで対応できるかと思います!

    うちのサーバーで試してみて会社にあてることにします・・・。

  7. bindの設定でallow-queryなどを使った制限もしておいた方がいいかもしれませんね(^_^)☆
    iptablesで53番を制限したなら問題なさそうです!

  8. […] Google Public DNS を使う理由を学びました。ちゃんちゃん。の巻 […]

コメント大歓迎!質問も受け付けておりますヽ(*´∀`)ノ

%d人のブロガーが「いいね」をつけました。