== DNS/毒盛/2016 == <> 新年の抱負に以下のように書いたが、その後、 Kaminsky-Mueller型の[[NS/毒盛/NS毒盛]]は簡単に防御できると分かった。(実装はまだ） {{{ 　リゾルバー（キャッシュ）が抱える毒盛脆弱性についてのわかりやすいまとめを作る。（無謀） }}} === 否定的返答の利用 === Kaminsky流攻撃において、これまで利用されていなかったNXDOMAIN情報を利用するのが重要である。 　[[DNS/毒盛/対策/NXDOMAIN返答活用]] noerror返答のSOA情報も同様に利用できる。 委譲（委任）返答毒以外の毒盛は考えなくていい。 　最終的には問い合わせしなおすが、その前に多くの毒がそれだと分かる。 （現状のリゾルバーはこれらの情報を利用していない。） 例えば、2014年に指摘した毒盛脆弱性： 　　属性型JPドメイン名にあらわれるgo.jp, co.jp などの中間ノード（ドメイン名）に対する委譲毒は排除できる。 Kaminsky流攻撃で本来のサーバから返るNXDOMAIN返答でco.jpドメインにはNSがないことが分かるから。 qname minimisationを採用しているなら、co.jpなどの中間ドメイン名のNSを直接問い合わせるので、 もっと簡単に毒だと分かる。（これも現状では利用されていないようだが） あるいは、jprs.co.jp NSをJP NSに問い合わせたときの返答からもco.jpゾーンが存在しないことは分かる。 この程度の判断でも毒だと判定できる範囲は広がる。 あとはドメイン名階層の構成によって毒盛可能かどうかを判断することになる。 　（NSなしノードが多段になっている場合にはもう少し手間がかかる） これで、中間者攻撃は別にすると、DNSSECを使わなくても、NS毒盛対策は簡単になった。 ---- 毒盛に脆弱というより、DNSは脆弱性の塊のようなものだから、 　どうすれば比較的安全に使えるか、とか、どの程度の危険を覚悟すべきか、とかを解説する方が現実的だ。 でも、そういうことを書いても読むひとはいないだろう。 　みなさんは危険を直視したくないようだから。 -- ToshinoriMaeno <> 「残っている脆弱性」というのも変なので、「分かっている脆弱性」とするか。 実装によってはほぼ解消されているものもある -- ToshinoriMaeno <> ---- == UDP fragmentation attack == [[DNS/1/UDP]] checksum 0 という恐ろしい設定が今も残っている。 　[[DNS/脆弱性]] http://www.ietf.org/proceedings/87/slides/slides-87-saag-3.pdf DNS Cache-Poisoning: New Vulnerabilities and Implications, or: DNSSEC, the time has come! 2012年 http://arxiv.org/pdf/1205.4011.pdf　　Fragmentation Considered Poisonous checksumを合わせる部分が難しい点だと思っていたが、 check sum 0 -> 計算しないという指定があって、 　それをVerisignが使っていることが判明した。（多分、最近のことだろう） リゾルバー側の防御としては、check sum 0が指定されたUDPは受け取らないことだ。 -- ToshinoriMaeno <> だが、checksumがあっても、あまり役に立たないことが多い。 ---- https://www.iajapan.org/ipv6/summit/SAPPORO2014/pdf/JPRS_SAPPORO2014.pdf {{{ IPフラグメンテーションの弱点 [攻撃側から見れば、長所ｗ） （DNSサーバーの応答ログ） •キャッシュDNSサーバーの応答ログには攻撃の痕跡が残らない 　–リアセンブリーされなかったフラグメントはIP層で捨てられ、 　　リアセンブリーされた応答のみが上位層に到達する 　–これに対し、カミンスキー型攻撃手法では複数のDNS応答が上位層に到達するため、 　　　攻撃の痕跡が残る • IP/データリンク層には痕跡が残る – netstatコマンドやtcpdumpコマンドなどである程度確認可能 }}}