#acl All:read,write == DNS/毒盛/対策/末永ブログの議論 == 書き込み可能のページ: 「情報」タブをクリックすることで、変更部分を差分表示するためのページにいけます。 <> 攻撃手法は[[DNS/毒盛/Mueller手法]]による偽委譲返答(NS毒盛)である。 この攻撃に対する簡単かつ効果的な防御を考案した。 {{{ 返答に付随するSOAレコードから得られる情報を利用して、 zone cut が存在していない場所を知り、それを委譲返答毒(*)の排除に使うものである。 　(*) JPRSは「委任インジェクション」と呼んでいる。 SOAレコード以外からもzone cutの非存在を確認できるが、ここでは扱っていない。 zone cut非存在は他の毒の排除にも利用できるが、今ここでは扱わない。 }}} NS毒盛攻撃が成立するのはDNSの欠陥というよりは「実装の欠陥」だ。 　そういいうことが明らかになったと考える。-- ToshinoriMaeno <> DNSに問題がないという意味ではない。どういう実装が必要かすら分からないのがDNSだから。 ------ 末次さんが http://wp.kaz.bz/tech/2016/03/29/2109.html で理解したことをまとめているので、 それについてのコメントや議論を残しておく。より理解が進むことを期待して。-- ToshinoriMaeno <> == 防御方法について == === 基本原理 === 以下のロジックにより、DNSキャッシュサーバがキャッシュされていない偽応答を受け取った際、事前にその偽応答があり得ないことを予知することができ、偽応答を無視することができます。 また、そもそもその偽応答に対応する問い合わせを行わないことができます。 {{{ コメント：単なる偽返答ではなく、偽の委譲返答(NS)を対象とした対策です。 　　以下の部分はやや混乱しているように思うが、どうコメントするかは未定 キャッシュされている偽応答というのがあるとしたら、どういうものでしょうか。 「キャッシュにない応答を受け取ったとしても」という意味でしょうね。 偽応答が返る問い合わせをさせないのは無理です。 }}} *「攻撃対象となっているドメイン名がゾーンではない」ことを事前にDNSキャッシュサーバが知っていることによって、 そのドメイン名に対するNSレコードを受け入れない（正当な回答と認めない）ことができる。 * 事前に「その名前のゾーンは存在しない」ことを知っておくことにより、 そのドメイン名に対する問い合わせが発生した際にNSレコードを返さないことができる。 {{{ NSを返さないだけではなくて、NXDomainを返せるのですが、おまけの効果ですね。 }}} * SOAレコードはそのゾーンの頂点にのみ存在することから、 ゾーンが存在する場合SOAレコードは問い合わせたドメイン名に対するものと一致する。 {{{ ここはなにをいいたいのか不明 }}} {{{ 問い合わせたレコードのドメイン名が、AUTHORITY で返ってくるSOAのラベルと一致する、という意味で書いていました。 下のゾーンの不存在に対する逆の例（ゾーンの存在を確認する方法）のつもりでした。 -- kaz. Suenaga <> }}} * 問い合わせたドメイン名からSOAレコードで返されたラベル名までの間のサブドメインに対し ゾーンが存在しないことを知ることができる。 {{{ ここがポイントです。JPRSの藤原が指摘したことだが、これらに対する毒盛攻撃が可能だったから。 }}} * ゾーンが存在しないことを知っていることにより、 上位のサーバに対する問い合わせを発生させずに問い合わせへの応答ができる。 {{{ 問い合わせを発生させないのは無理だと思っているが、なにかアイデアがありますか。 }}} {{{ NSを受け入れないことと、NSを問い合わせる必要がないことを混同していたように思います。 唯一、NSが問合せられた際のみ上位にそのNSを問い合わせる必要がないように思います。 NS CO.JP を問い合わせられた場合、CO.JP ゾーンが存在しないことを知っていることにより、上位にNS CO.JPを問い合わせることなく、NS JP を問い合わせられると思います。 その場合も「問い合わせずに応答できる」は間違いですね。 ご指摘ありがとうございます。 -- kaz. Suenaga <> }}} === 「ドメイン名がゾーンではない」ことを知る方法 === ドメイン名がゾーンではないことを知るために、NODATA(上記 正当な問い合わせの応答 2.）およびNXDOMAIN（同 3.）の際にAUTHORITY SECTIONに返ってくるSOAレコードの利用ができる。 {{{ co.jpを問い合わせたときの話と、co.jp 下の名前を問い合わせたときの話が混じっていて、わかりづらい。 　　co.jpがゾーンでないことが分かる例だということですか。 確かに、qname minimisationではco.jpを先に問い合わせることになる。 しかし、前野が注目したのは、Kaminsky流攻撃で、$random.co.jp の問い合わせをすることで、 　　jp サーバから送りつけられる co.jp NS (委譲返答) のふりをした毒を見分ける方法です。 　　　事前にco.jpを問い合わせるという動作はこれまでのリゾルバーはしない。 　リゾルバーが積極的にco.jp NSを問い合わせれば、ゾーンでないことは当然分かる。 　 }}} * 例で co.jp を問い合わせている際に jp のSOAが返ってきているということは co.jp ゾーンが存在しないことを意味する。 * 同時に co.jp に対する NSレコードがないことを意味する。 * また 例えば [[/example.co.jp]] について dig +norec a example.co.jp @z.dns.jp とすると jp の SOA が返ってくるが、このことから、example.co.jp ゾーン、および co.jp ゾーンの存在しないことを同時に知ることができる。 {{{ 親子ゾーンが同居しているときにSOAでどういう情報が返ってくるか、理解しておられるでしょうか。 }}} === 「ドメイン名がゾーンではない」ことを知るタイミング === 想定している攻撃手法は1度で成功する確率は非常に低いため、 1度目の問い合わせの時点でSOAレコードが取得されることによりゾーンが存在しないことを DNSキャッシュサーバは事前に知ることができる。 {{{ 事前ではなく、攻撃が届く前にくらいでしょうか。 最近始まったqname minimisationでゾーンカット探索を行うので、 そのときにもzone (cut)の不存在を知ることができます。 co.jpなどはそうなるでしょう。 }}} 攻撃に限らず通常の(間違った）問い合わせで発生する応答などからも同様にゾーンが存在しないことを知ることができる。 === この防御方法の利点 === 原理が単純であり対応が極めて容易である 1度目の攻撃をそのまま防御に利用できる 正常な問い合わせや単なる間違いも含めて、正しいゾーン境界をしる機会が非常に多い 元々本来受け取っているデータを元にするため新たに通信量が増大するわけではない {{{ 評価をありがとう。 対策として成立するかどうかを考えている段階でしたので、効率などは検討不十分でした。 }}}