ネットワークワーキンググループ A. Hubert RFC: 5452 Netherlabs Computer Consulting BV. 更新(Updates): 2181 R. van Mook 分類: 標準化過程(Standards Track) Equinix 2009年1月 偽造応答に対するDNSの耐性強化策 Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 要旨 現在のインターネットの情勢は、深刻な脅威をDNSにもたらしている。 DNSプロトコルをより完全な形で安全にできるまでの過渡期において、 再帰ネームサーバーの"スプーフィング"を何ケタも困難にし、 DNSを強靱にする対策は今でも実施可能である。 暗号技術により安全にされたDNSであっても、本文書の対策が計算量を大幅に 節約する可能性を持つことから、不正な応答を素早く破棄する能力を備える ことに役立つ。 本文書は、これまでに標準化されていない特定の振る舞いを記述することで、 DNSに不正な応答を受理させない耐性強化策を提示する。本文書は RFC 2181 を 更新する。 Hubert & van Mook Standards Track [Page 1] RFC 5452 DNS Resilience against Forged Answers January 2009 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 要件と定義 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 用語の定義 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. キーワード . . . . . . . . . . . . . . . . . . . . . . . . 5 3. DNSスプーフィングの概要 . . . . . . . . . . . . . . . . . . . 5 4. スプーフィング成功条件の詳細な解説 . . . . . . . . . . . . . . 6 4.1. 問い合わせの強制 . . . . . . . . . . . . . . . . . . . . . 6 4.2. 問い合わせ部の一致 . . . . . . . . . . . . . . . . . . . . 7 4.3. IDフィールドの一致 . . . . . . . . . . . . . . . . . . . . 7 4.4. 正規の応答の送信元アドレスとの一致 . . . . . . . . . . . . 7 4.5. 正規の応答の送信先アドレス及び送信先ポートとの一致 . . . . 8 4.6. 正規の応答に先んじた応答の送付 . . . . . . . . . . . . . . 9 5. 誕生日攻撃 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. In-Domain(インドメイン)のレコードのみの受理 . . . . . . . . . 9 7. 複数の攻撃機会が与えられる場合の成功確率 . . . . . . . . . . . 10 7.1. 計算で使用する記号 . . . . . . . . . . . . . . . . . . . . 10 7.2. 攻撃成功確率の計算 . . . . . . . . . . . . . . . . . . . . 11 8. 成功確率に関する議論 . . . . . . . . . . . . . . . . . . . . . 12 8.1. 単一ドメイン名を標的とした反復的スプーフィングの試み . . . 13 9. 偽造応答への対策 . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. 問い合わせ・応答の一致判定ルール . . . . . . . . . . . . . 13 9.2. アドレスとポート番号を使用した問い合わせID空間の拡張 . . . 14 9.2.1. 本手法の正当性に関する議論 . . . . . . . . . . . . . . 14 9.3. スプーフィングの検知及びその対処 . . . . . . . . . . . . . 15 10. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Hubert & van Mook Standards Track [Page 2] RFC 5452 DNS Resilience against Forged Answers January 2009 1. はじめに 本文書は、DNS実装に共通の問題を幾つか記述する。これらの問題は以前から 認識されていたものだが、大部分は未解決のままとなっている。これらの 問題点を短く要約して提示することに加え、本文書で記載されるリゾルバー の耐性を大幅に強化可能なルールも提供する。本文書のゴールは、現行の プロトコルの範囲内で可能な限り既存のDNSを安全性を高めることである。 以下の記述は、リゾルバーの開発者に向けたものである:どのネームサーバー 実装を使用するか、あるいはどのオプションを有効にするかは運用者次第 である。運用上の制約が以下に示すセキュリティ上の懸案事項に優先される かもしれない。しかし、実装では、本文書記載の機能を運用者が有効に でき得ることが期待される。 インターネット上のほぼすべてのトランザクションは、[RFC1034]、[RFC1035] 及びそれ以降に発行された関連RFC記載のDNS処理を必要とする。 加えて、最近では SSL/TLS 証明書は、他の認証手段による身元確認無しに、 SMTP([RFC5321])で送信された確認電子メールに返信するだけで取得できる ようになった。一般に電子メール配送制御にはDNSが使用される。 言い換えると、DNSを(一時的にも)制御可能な者は、ドメイン名に対する SSL/TLS証明書取得の身元確認処理も含む、インターネット上の大半の トランザクションを迂回できることになる。これはつまり、たとえSSL/TLS 保護下のトランザクションであっても、(意図した通信先以外に)誘導され得る ことを意味する。 そのような迂回させられたトラフィックが、インターネットユーザーに不利益を 生じさせることは充分に考えられる。 本文書の、またその他の開発の結果、DNSのセキュリティと信頼度に関する重要な 機能が一新された。DNSコミュニティは、暗号技術を拡張したDNSプロトコルの 仕様確定及び実装に懸命に取り組んでいる最中であるが、その一方で、 現在稼働中のDNSを、関連する標準の範囲内で可能な限り安全なものにするため、 幾つかの作業を実施すべきである。 現在最も広く使用されているリゾルバーが、この種の処理を最適な形では実施 していないという点において、この文書を緊急・重要なものとしていることに 注意すべきである。 DNSが直面する脅威の詳細な分析は、[RFC3833] で得られる。 Hubert & van Mook Standards Track [Page 3] RFC 5452 DNS Resilience against Forged Answers January 2009 本文書は、RFC 3833で示された幾つかの脅威を発展させたものであり、特に、 "ID及び問い合わせの推測(ID Guessing and Query Prediction)"、"名前連鎖 攻撃(Name Chaining)"を扱ったセクションの内容を採り上げている。更に、 DNSプロトコルの関連仕様に盛り込まれた、多数の既存のルール・ガイドライン の重要性を強調する。以降では、より安全なDNSプロトコルが標準化・普及する までの間、DNSが安全性の拠り所にできる、新たな要件をも規定する。 以後に示唆する対策すべてを実装しても、プロトコルユーザーは、リゾルバーの トラフィックを観測・改ざんしたりパケットを注入し得る第三者の攻撃から 保護されるわけではないことに注意すべきである。 これらの攻撃シナリオに対する保護を提供するプロトコル拡張については、 [RFC4033]及び以後に発行されたRFCを参照のこと。 2. 要件と定義 2.1. 用語の定義 本文書で使用する用語の定義を以下に示す。 クライアント: 通常、エンドユーザーのコンピューター上の"スタブリゾルバー"。 リゾルバー: クライアントに再帰検索サービスを提供するネームサーバー。 キャッシングDNSサーバーまたはフルサービスリゾルバーとも呼ばれる([RFC1123] セクション6.1.3.1)。 スタブリゾルバー: クライアントコンピューター上で動作する極めて限定された 機能のリゾルバー。再帰検索作業はフルサービスリゾルバーに委託する。 問い合わせ: リゾルバーから、通常はUDPパケットで送信される問い掛け 応答: 権威ネームサーバーから、通常はUDPパケットで返される 問い合わせの回答 第三者: リゾルバーまたは意図する問い合わせ受信者以外のものすべて。 第三者は任意の権威ネームサーバーにアクセスできるが、リゾルバーまたは 権威サーバーによって配送されたパケットにはアクセスできない。 攻撃者: 悪意ある第三者 スプーフィング: 選択した(攻撃者が決めた)回答を受理させることで、 DNS処理の秩序を乱そうと企てる行為 Hubert & van Mook Standards Track [Page 4] RFC 5452 DNS Resilience against Forged Answers January 2009 正規の応答: 正当な権威サーバーから到達した正しい回答 標的ドメイン名: 攻撃者が応答のスプーフィングを仕掛けようとしている ドメイン名 偽造データ: 攻撃者によって仕込まれた応答 2.2. キーワード 本文書における "しなければならない(MUST)"、"してはならない(MUST NOT)"、 "要求される(REQUIRED)"、"するものとする(SHALL)"、"しないものとする (SHALL NOT)"、"すべきである(SHOULD)"、"すべきではない(SHOULD NOT)"、 "推奨される(RECOMMENDED)"、"してもよい/することができる(MAY)"、 "任意である(OPTIONAL)" というキーワードは、[RFC2119]に記述される通りに 解釈されるものとする。 3. DNSスプーフィングの概要 DNSパケットを巧妙に作り上げ、注意深く時期を選んで然るべき処理を実施 すると、現在普及しているリゾルバーの大部分に"スプーフィング"を仕掛ける ことができる。一旦スプーフィングが成功すると、キャッシングDNSサーバーは不当に 受理させられたデータを再利用して応答するようになり、クライアントは 誤った、恐らくは悪意あるサーバーに誘導される。 このプロセスがどのように機能するかを理解するためには、リゾルバーに 応答を受理させる条件は何かを知ることが重要である。 [RFC1034]のセクション5.3.3記載の以下の文は、現在生じている問題を予見 するものだった。 リゾルバーは、応答の解析(parse)を行う際に、やりすぎと思えるくらいに 完璧を期すべきである。また、応答のIDフィールドを使用して、その応答が 送信した問い合わせに対応しているかを検査すべきである。 以下の条件がすべて満たされた場合に限り、DNSデータはリゾルバーに受理される。 1. 応答パケットの問い合わせ部の内容が、現在応答を待っている問い合わせ パケットの問い合わせ部と等しい。 2. 応答パケットのIDフィールドが問い合わせパケットのそれと一致する。 3. 問い合わせを送信したネットワークアドレス(IPアドレス・ポート番号)と 同じアドレスから応答が到達する。 4. 応答がポート番号を含み、送信したものと同じネットワークアドレス から到達する。 一般に、この四つの条件を満たした最初の応答が受理される。 Hubert & van Mook Standards Track [Page 5] RFC 5452 DNS Resilience against Forged Answers January 2009 もし、第三者が正規のネームサーバーからの応答よりも前に四つの条件を 満たすことに成功した場合、リゾルバーに偽造したデータを送り込める ことになる。そうすることをわれわれは、偽造データによるスプーフィング を試みる"攻撃者"と呼んでいる。 第三者が先に挙げた条件をすべて満たすことは理論的に可能である。その 難易度は、リゾルバー実装の機能とゾーンの設定に依存する。 4. スプーフィング成功条件の詳細な解説 前の段落で、改ざん(または偽造)データによるスプーフィングを仕掛けるために、 攻撃者が満たさなければならない多数の条件を議論した。本セクションは、 スプーフィングの相対的難易度と、実装側で定義された選択が、その難易度 克服のために攻撃者が実行しなければならない作業量にどの程度影響するか について議論する。 より詳細な解説が[RFC3833]のセクション2.2に記述されている。 4.1. 問い合わせの強制 形式的には、ネームサーバーが運用者や顧客、より一般的にはその利用者以外 にサービスを提供する必要はない。近年、オープンな再帰ネームサーバーが DoS攻撃の増幅に使用されるようになっている。 (オープンな状態で)フルサービスを提供すると、第三者がそのリゾルバーを 標的として、スプーフィングを仕掛けようとしているドメイン名への問い合わせを 送信することが出来てしまう。問い合わせを受信し、かつキャッシュに応答が 無かった時点で、当該リゾルバーはその問い合わせを関連する権威ネームサーバーに 送信する。これは、偽造した応答データを受け入れさせる機会を提供する ことになる。 問い合わせは間接的な手段で強制される場合もある。例えば、メールサーバーに DNS検索(lookup)実行を誘発させることが考えられる。 一部の運用者は、無許可のIPアドレスに対しては再帰検索サービスを提供 せず、キャッシュによる応答だけしかしないといったアクセス制限を実行 している。これにより、正確な時期をとらえて強制的に問い合わせを発行させる ことができなくなるため、第三者によるスプーフィングはより困難になる。 しかし、外部への問い合わせが生じるだろう時期の範囲は推定できる。ネーム サーバーはキャッシュに保存されたエントリーのTTLの減少状況を公開している からである。この情報から、ある時刻以後であれば、満了したエントリーを 回復(リフレッシュ)するために新しい問い合わせが発行されると判断できる。 標的ドメイン名のRRsetのTTLは、攻撃の機会が与えられる頻度を決定する。 従って、短いTTLはスプーフィングの実行可能性を大幅に高めることを 意味する。 Hubert & van Mook Standards Track [Page 6] RFC 5452 DNS Resilience against Forged Answers January 2009 攻撃者は、顧客・従業員あるいは運用者を装うことで、標的リゾルバーへの 許可されたアクセスを得られる可能性があることに注意。更に、[RFC5358]記載の DNSリフレクターを使用することでアクセスが得られる場合もある。 4.2. 問い合わせ部の一致 DNSパケットは、問い合わせ・応答の両方が問い合わせ部を含む。受信した応答の 問い合わせ部が、送信した問い合わせのものと等しいことを検証すべきである。 4.3. IDフィールドの一致 DNSのIDフィールドは16ビット幅である。これは、全ビットを使用し、かつ その中身が真にランダムであれば、フィールド値を推定するためには平均32768回 の試行が必要なことを意味する。事例証拠によれば、14ビットしか使用しない 実装があることが示唆されている。これは、IDフィールドの推定は平均8192回の 試行で充分であることを意味する。 加えて、標的ネームサーバーに同一の問い合わせを複数回強制的に発行させること ができるならば、"誕生日攻撃(Birthday Attack)" 現象により、攻撃者により 送信されたいずれかの偽造データが複数の発行済み問い合わせと一致する、 つまり攻撃が成功する可能性は劇的に増大する。より詳細な内容については セクション5を参照のこと。 4.4. 正規の応答の送信元アドレスとの一致 本条件を満たすには、権威ネームサーバーのアドレスを詐称してパケットを リゾルバーに送信できる必要があることに注意すべきである。。二つのBCP (Best Current Practice)、具体的には[RFC2827]と[RFC3013]は、ISPに、 自身の顧客に割り当てた以外のアドレスを使用させないことを指示しているが、 これらの推奨は普遍的に(広い範囲ですら)実装されているわけではない。 多くのゾーンは、権威ネームサーバー2台あるいは3台持つ。これは、 たとえ2ケタ台の成功率という単純な想定をしたとしても、正規の応答の 送信元アドレスに一致させる成功率は非常に高くなる。 大半の再帰ネームサーバーは、複数の権威ネームサーバーの相対的なパフォーマンス 指標を保存しており、それを使用することで、どの権威ネームサーバーに最初に 問い合わせるかの判定を容易にしている。一例として、最も早く応答が返される 可能性の高いものが選択される。 通常の場合、この条件を満たすために必要な試行の回数は、たかだか2回 ないし3回である。 Hubert & van Mook Standards Track [Page 7] RFC 5452 DNS Resilience against Forged Answers January 2009 4.5. 正規の応答の送信先アドレス及び送信先ポートとの一致 正規の応答の送信先アドレスは、そのきっかけとなった問い合わせの送信元 アドレスであることに注意。 一般に、再帰ネームサーバーが実際に使用しているアドレスは既知である。 それに対し、問い合わせに使用した送信元ポートの推定はより困難である。現在 普及している大半のリゾルバーは、起動時に任意のポート番号を(恐らくは ランダムに)選択し、それを全問い合わせの発行時に使用する。しかし、問い合わせ 発行時の送信元ポートが、伝統的にDNSサーバーに割り当てられたサーバー ポート番号の53に固定されている場合も極めて多い。 問い合わせの送信元ポートがランダムであっても固定であれば、攻撃者は、 監視下にあるいずれかの権威ネームサーバーを使用して、そのポート番号を 特定することができる。これは、この条件を満たすために、何らかの推定 作業が不要になることを意味する。 問い合わせ送信時に複数の送信元ポートを使用する場合、実効的ID空間は 使用するポート番号数倍に拡大する。 問い合わせの発行ごとにランダムなポート番号を選択する名前解決サーバーも 存在するが、あまり一般的ではない。この戦略に従うのであれば、この ランダムに選択されるポート番号は、最大16ビットで構成される追加の IDフィールドと見なすことができる。 ポート番号の範囲を最大限に利用する場合、1024より小さいポート番号は 利用できない場合があり、その残りは64512となることから、問い合わせの 送信元ポートと一致させるには、平均して約32256回の試行が必要となる。 DNSが使用するポート番号は、その一部が他のプロトコルに割り当てられて いることを考慮しても、一般に 1024-49152 とするのが安全である。 DNSリゾルバーは、既に使用中のポートはどれも使用できない。DNSリゾルバーが ポートを使用する場合、短時間の専有の後そのポートは開放され、使用する ポートは別の番号に移行する。高い頻度で使用されるリゾルバーの場合に限り、 アプリケーションの所望する特定のUDPポート番号が長期に渡って専有される ため、問題が生じる可能性がある。 ファイアウォールはここで述べる条件を満たす試行を防げないことに 注意すべきである。ファイアウォールは正当なアドレスから受信した(ように 見える)回答を受理するため、何ら付加的なセキュリティ機能を提供しない ためである。 4.6. 正規の応答に先んじた応答の送付 何らかのパケットによって先に示した四つの条件(付加的な条件が加わることも ある)が一度満たされると、以後はどの応答も受理されなくなる。 Hubert & van Mook Standards Track [Page 8] RFC 5452 DNS Resilience against Forged Answers January 2009 これは、第三者が偽造した応答を注入する際に限られた時間しか与えられて いないことを意味する。以後の計算評価において、(権威ネームサーバーまで のネットワーク距離に依存するが)この攻撃可能期間を最大100ms 程度である と仮定する。 恐らくは攻撃者による(一時的な)多量の問い合わせで正規の権威ネーム サーバーが過負荷になっている場合、この時間は遙かに長くなる。 5. 誕生日攻撃 いわゆる"誕生日のパラドックス"とは、あるグループに属する2名以上の メンバーが同じ誕生日である確率が50%を越えるには、そのグループに23名 居れば充分であるというものである。 攻撃者が、標的リゾルバーに同じ権威サーバーに宛てて同じ(同一のQNAME、 QTYPE、QCLASS)問い合わせを複数個、強制的に発行させることができる場合、 攻撃者はこの厳格な事象の利益を享受できる。 その場合、攻撃者が送信したどのパケットも受理される可能性が非常に高く なる。それらのパケットは単一のドメインに向けて発行された複数の問い合わせ のうち、どれか一つにだけ一致すればよいからである。先に説明した誕生日の 比喩と対比すると、問い合わせと応答で構成されたグループにおいて一つのIDを 共有してしまう確率は、グループの構成要素数に対して急激に上昇する。 同じ問い合わせの発行数が少ない限り、応答のスプーフィングが成功する確率は、 正確なドメインとネームサーバーへの問い合わせを発行した数に対して線形に しか増加しない。 一方で、問い合わせ発行数がより多い場合、その効果が実効的でなくなる。 より詳細な情報は、US-CERT [vu-457875] で得られる。 6. In-Domain(インドメイン)のレコードのみの受理 権威ネームサーバーからの応答に、サーバーが権威を持つゾーンには属さないが、 権威付きであるかのように考えられる情報が含まれる場合がある。例えば、ある ドメイン名のMXレコードへの問い合わせに対して、他のドメインに属するメール エクスチェンジャーとそのIPアドレスが返されることがある。 そのような応答を無分別に受理すると、リゾルバーは信頼できない情報源から 得たデータを受理してしまう可能性がある。データ生成者がQNAMEまたは QNAMEの親に対して権威を持つことが明らかな場合にだけ、データを受理 するように注意を払わなければならない。 Hubert & van Mook Standards Track [Page 9] RFC 5452 DNS Resilience against Forged Answers January 2009 これを達成する非常に簡単な方法の一つに、意図した問い合わせドメイン名の 一部である場合にだけ応答データを受理することが考えられる。 7. 要素が組み合わされた場合の難易度 あるゾーンが2台の権威ネームサーバーを保持すると仮定すると、送信先ポートが 既知あるいは固定である場合、IDフィールド・送信元アドレス・送信先アドレスの すべてを一致させるために必要なパケット数は、平均して 2 * 2^15 = 65000 程度 となる。 先に仮定したように、攻撃可能期間が約100ms与えられているとすると、 一回の試行で偽造データを50%の確率で受理させるためには、攻撃者は 約650000pps(パケット/秒)のレートでデータを送信できる必要がある。 実際の最小DNS応答はIPヘッダーも含めて80バイト前後で構成されるので、 先のパケット送信レートは 416Mbps(ビット/秒)のバーストに相当する。 2006年中頃の時点で、このレベルの帯域を提供するネットワークは必ずしも 一般的ではなかったが、特にサーバー管理セグメント内に限定すれば珍しい というものでもなかった。 また、この416Mbpsという値も、正当な権威サーバーを囮の問い合わせで過負荷に 陥れ、正規の応答の生成を妨害するなどして、攻撃可能期間を1秒にまで増大 することで変更できる。具体的に、攻撃可能期間が1秒になるならば、必要な 帯域は42Mbpsにまで減少する。 更に、攻撃者に2回以上の攻撃機会が与えられ、TTLが300秒のドメイン名に 対して60分間の攻撃が許されるのであれば、偽造データを50%の確率で受理 させるにはわずか4Mbpsで充分になる。より長い攻撃時間が使えるならば、 先に挙げた攻撃成功条件の1(問い合わせ部の一致)を満たすのは容易である。 攻撃時間内に、著名なドメイン名への問い合わせは何度も行われる。その ドメイン名のTTLが短ければ、権威ネームサーバーへの問い合わせが発生する ので、攻撃の機会が得られる。 7.1. 計算で使用する記号 以下の記号を使用する。 I: 利用可能な異なるID数 (最大65536) P: 利用可能なポート数 (1024未満の値は通常使用できないので最大約64000だが、 この値が1の場合もある) N: ドメインが保持する権威ネームサーバー数 (平均2.5程度) Hubert & van Mook Standards Track [Page 10] RFC 5452 DNS Resilience against Forged Answers January 2009 F: 攻撃者によって送信される "偽造" パケットの数 R: 攻撃者が1秒間に送信可能なパケット数 W: 攻撃可能期間(単位:秒)。権威ネームサーバーの応答時間によって時間 制限が課せられる (多くの場合0.1秒) D: リゾルバーが発行する同一内容の問い合わせ数(通常1。同一内容の定義は セクション5参照) A: 攻撃者が各攻撃可能期間に実施する攻撃試行回数 7.2. 攻撃成功確率の計算 リゾルバーに対するスプーフィングが成功する確率は、攻撃可能期間内に リゾルバーに到着する偽造パケット数を問題空間の大きさ(一致が必要な 情報量)で割ったものに等しい。 リゾルバーが同一内容の問い合わせを 'D' 個発行する場合、偽造パケットが これらのどれか一つと一致する確率は、発行個数に比例して大きくなる。 本計算では、'D' は小さな値しか採らないと仮定する。 スプーフィングが成功する確率を記号 P_s で表記すると、以下の式が得られる。 D * F P_s = --------- N * P * I 上式は、パケット数をパケット送信(受信)レートに変換しておくと、 必要に応じて必要帯域への変換が容易なため、検討の際に便利である。 攻撃可能期間の長さを 'W' とすると、攻撃者が1秒間に送信可能なパケット数は 'R' であり、受理を目論む偽造パケットの対象個数 'F' は以下の式で表される。 D * R * W F = R * W -> P_s = --------- N * P * I 最後に、所定の攻撃可能期間 'T' の間にスプーフィングが成功する確率を 計算するにあたり、攻撃者は標的ドメインのTTLが終了する 'TTL' 秒ごとに新しい 攻撃機会を得られることを理解すべきである。これは、攻撃試行回数 'A' が 'T / TTL' に等しいことを意味する。 Hubert & van Mook Standards Track [Page 11] RFC 5452 DNS Resilience against Forged Answers January 2009 攻撃が少なくとも1回成功する確率は、以下の式で得られる。 (T / TTL) A ( D * R * W ) P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) ( N * P * I ) 先に提示した数値を各変数 D, W, N, P, I に代入すると、上式は以下の式に 変形できる。 (T / TTL) ( R ) P_cs = 1 - ( 1 - ------- ) ( 1638400 ) この得られた式から、ネームサーバー実装が何も変わらないならば、TTLを 増加させる以外のスプーフィング防御手段はないことがわかる。 権威ネームサーバー数 N を小さいとは言えない値にまで増やすのは現実的 ではない。 TTLが0秒という悪条件下では、問い合わせ送信ごとに攻撃機会が与えられるので、 実効的TTLは権威ネームサーバーの応答時間 'W' に等しくなる。 最後に示した事例の場合、スプーフィング技法はTTLの満了に依存しないが、 依然として標的ドメイン名を変更しながら、何度も繰り返し問い合わせを行う 振る舞いは同じである。 8. 成功確率に関する議論 先に提示した計算は、DNSデータのスプーフィングが比較的容易に実行できる ことを示している。例えば、先に導出した式をTTL 3600のRRsetに対して適用 すると、攻撃者が7000ppsで偽造パケットを送信できる場合(レートに換算すると 4.5Mbps)、最初の24時間でスプーフィングが成功する確率は10%だが、 1週間後には50%に上昇する。 RRsetのTTLが60秒であれば、攻撃成功率は24分で10%に到達し、3時間以内に 50%、9時間以内に90%となる。 先に注記したように、ある種の攻撃では実効的TTLが0に近くなる。 先に記載した攻撃は、注意深いサーバーオペレーターには検知可能であることに 注意。予期しない4.5Mbpsものパケットストリームは恐らく気づかれるだろう。 しかし、重要な前提として、これまでに示した計算では正規の応答の送信先 ポートは既知または固定であるとしている。 Hubert & van Mook Standards Track [Page 12] RFC 5452 DNS Resilience against Forged Answers January 2009 ポート番号が未知で、これも推定する必要がある場合、問題空間は64000倍に 拡大するため、これまでの計算と同様の攻撃成功率を得るためには、攻撃者は 285Gbps以上の送信レートを保持する必要がある。 そのような帯域幅は一般に利用可能ではなく、(本文書執筆時点で)予見できる 将来においても期待できない。 ある種のファイアウォールでは、問い合わせ発行用に単一のDNS送信元ポートしか 通信許可していない場合、設定変更が必要になるかもしれないことに注意。 8.1. 単一ドメイン名を標的とした反復的スプーフィングの試み スプーフィングの成功という目標達成に向け、事実上無限回の問い合わせを 使えるようにする技法が存在する。先の数式に従うと、これにより実効的 TTLは0になる。 この方法を使用する場合、攻撃者が先に示したのと同じ 7000pps のパケット 送信レートを保持しており、問い合わせ送信元ポート(偽造データの送信先ポート) が一つしか使用されないとすると、スプーフィング成功確率は7秒以内に50%に 跳ね上がる。 本文書で推奨するように、送信元ポート数を64000まで増やした場合でも、 同様の送信レートの場合、116時間後にはスプーフィング成功確率が50%に 到達する。 9. 偽造応答への対策 9.1. 問い合わせ・応答の一致判定ルール リゾルバー実装は、受信した応答にDNS信頼度判定ルール([RFC2181] セクション5.4.1)を適用する前に、対応する問い合わせと以下の項目すべてが 一致しているかを判定しなければならない(MUST)。 ・ 応答送信元アドレスと問い合わせ送信先アドレス ・ 応答送信先アドレスと問い合わせ送信元アドレス ・ 応答送信先ポートと問い合わせ送信元ポート ・ 問い合わせID ・ 問い合わせ名 ・ 問い合わせクラス及び問い合わせタイプ 一致しない応答は無効(invalid)と見なさなければならない(MUST)。 Hubert & van Mook Standards Track [Page 13] RFC 5452 DNS Resilience against Forged Answers January 2009 9.2. アドレスとポート番号を使用した問い合わせID空間の拡張 リゾルバー実装は、以下の条件を満たさなければならない(MUST)。 ・ 問い合わせ発行時に、現実的に利用可能なポート番号の最大範囲内(53または 1024以上)から予測不能な送信元ポートを使用すること。 ・ 複数の問い合わせを発行する場合、異なる複数の送信元ポートを同時に 使用すること。 ・ 問い合わせ発行時に、利用可能な最大範囲内(0-65535)で予測不能な問い合わせID を使用すること。 複数のIPアドレスを持つリゾルバーは、問い合わせ発行時に、予測不能な方法で 選択したアドレスを使用すべき(SHOULD)である。 リゾルバー実装は、特定ポート番号に固定した使用を回避する手段を提供 すべき(SHOULD)である。 リゾルバーは信頼関係を構築した権威ネームサーバーを優先すべき(SHOULD) である。スタブリゾルバーは、再帰リゾルバーと通信する際に、TSIG (Transaction Signature [RFC2845])またはIPsec([RFC4301])を使用できる ようにすべき(SHOULD)である。 暗号技術に基づく応答の有効性検証(TSIG, SIG(0))が利用可能な場合、 リゾルバーは、先に挙げたルールを適用せず、替わりに有効性検証技術の 提供する信頼性に依存してもよい(MAY)。 適切な予測不能性は、[RFC4086]に記載の高品質な(擬似)乱数生成を採用する ことで達成できる。 9.2.1. 本手法の正当性に関する議論 攻撃者は、フルDNSリゾルバーに攻撃者の用意したネームサーバーへの問い合わせ 発行を強制できるので、リゾルバーが送信元ポートを固定していたりある種の 順序に基づいて使用したりしていれば、それを観測することができる。 従って、リゾルバーの内部状態(現在のポート使用状況)から低コスト・高精度 で将来の使用ポートが推定できるようなリバースエンジニアリングが容易に実行 できてはならない。 一つまたは少数の上流にしか接続されていないDNSフルリゾルバーは、使用する 送信元IPアドレスとUDPポート番号を事実上固定して運用している。これらは 潜在的な攻撃者の予測可能性が極めて高いため、避けなければならない。 同様に、問い合わせID生成時に前回使用したIDを単純にインクリメントする実装の フルDNSリゾルバーは、非常に予測可能性が高く、スプーフィングされやすい。 Hubert & van Mook Standards Track [Page 14] RFC 5452 DNS Resilience against Forged Answers January 2009 最後に、脆弱な乱数生成器は内部状態が保護されていないので、連続して生成 された幾つかの"ランダム"な値を観測した攻撃者は、次に生成される値を 容易に推定可能である。暗号強度の高い乱数生成器は、連続して生成された値を 幾つ観測されようとも、次の生成値を予測できないものである。 9.3. スプーフィングの検知及びその対処 無効な多数のパケットが先に述べた基準に達するなどして、リゾルバーが スプーフィングを仕掛けられていることを検知した場合、UDPを使用した 問い合わせを中止し、TCPで問い合わせを再発行してもよい(MAY)。TCPは、 本質的な特徴としてシーケンス番号を使用するので、第三者による偽造に 対してUDPよりも遙かに耐性が高い。 10. セキュリティに関する考慮点 本文書は、DNS応答の偽造が成功する確率を低減させるために、DNS仕様の 明確化を行っている。先に記述した推奨事項は、より広いクラスの攻撃も 防御可能なDNSの暗号技術拡張を補完するものである。 本文書は、実効的なDNSトランザクションIDを16ビットを越えた値に拡張 するため、UDP送信元ポート番号のランダム化を推奨している。 先の推奨事項を実装していないリゾルバーは、偽造された応答を容易に強制的に 受理させられ、それがクライアントコンピューターに渡されるため、(ユーザー) トラフィックを恐らくは悪意あるエンティティのもとに誤って誘導して しまう。 本文書はDNSのセキュリティに直接影響するものであるから、実装者は 本文書の推奨に従うことが強く推奨される。 セキュリティに関する考慮点の大半はセクション4及び5に、提案する対策は セクション9に記載がある。 簡潔にするため、ここでセキュリティの考慮点を繰り返す代わりに、読者は これらのセクションを参照されたい。 本文書は、運用者が使用すべき特定のアルゴリズムを何も規定しない。 本文書は、実装者がサポートすべき(SHOULD)あるいはサポートしなければ ならない(MUST)アルゴリズムを規定するものである。 問い合わせ発行リゾルバーが使用したUDP送信元ポートの範囲を限定するか、 ある種の順序に基づくものに変換してしまうNATデバイスが存在すると、 送信元ポートランダム化の効果は大幅に減少してしまうことに注意すべき である。 Hubert & van Mook Standards Track [Page 15] RFC 5452 DNS Resilience against Forged Answers January 2009 NATまたはステートフルファイアウォールの内側に配置されたDNS再帰サーバーを 高い問い合わせ負荷で運用すると、利用可能なNAT変換エントリー/ポートをすべて 消費してしまう場合がある。問い合わせポートのランダム化を実施すると、 問い合わせポートを固定した場合よりも短時間で変換エントリーを消費する。 これを回避するため、NATまたはステートフルファイアウォールは、問い合わせを 変換エントリーにマッピングし、最後に発行した時点から10-17秒経過した エントリーは削除してもよい/すべきである。[RFC4787]準拠のデバイスは、 ポート53を使用するUDPメッセージを他のUDPプロトコルメッセージとは 別に処理する必要がある。 ポート/状態を外部から使い切らせる攻撃の可能性を最小化するため、多数の DNS問い合わせを生成するサービスは、各接続について通信速度制限を設定 すべきである。本推奨は、特にE-Mailサーバーに適用される。 11. Acknowledgments Source port randomization in DNS was first implemented and possibly invented by Dan J. Bernstein. Although any mistakes remain our own, the authors gratefully acknowledge the help and contributions of: Stephane Bortzmeyer Alfred Hoenes Peter Koch Sean Leach Norbert Sendetzky Paul Vixie Florian Weimer Wouter Wijngaards Dan Wing 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. Hubert & van Mook Standards Track [Page 16] RFC 5452 DNS Resilience against Forged Answers January 2009 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 12.2. Informative References [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008. [vu-457875] United States CERT, "Various DNS service implementations generate multiple simultaneous queries for the same resource record", VU 457875, November 2002. Hubert & van Mook Standards Track [Page 17] RFC 5452 DNS Resilience against Forged Answers January 2009 Authors' Addresses Bert Hubert Netherlabs Computer Consulting BV. Braillelaan 10 Rijswijk (ZH) 2289 CM The Netherlands EMail: bert.hubert@netherlabs.nl Remco van Mook Equinix Auke Vleerstraat 1 Enschede 7521 PE The Netherlands EMail: remco@eu.equinix.com Hubert & van Mook Standards Track [Page 18]