## page was copied from DNS/毒盛 = DNS/毒盛/概要 = <> UDP をやめよう、という話になってきています。　TCPにするなら、DNSSEC もいらない。 TCP でも危険だと、食い止めようとするひとたち。 == 毒盛とは == [[../部品紹介]] [[../キャッシュサーバ]] [[../成立の要件]] 対策?：　[[../ゾーンサーバの監視]] http://cloud.watch.impress.co.jp/epw/cda/security/2008/08/28/13724.html 「ポートランダム化もすでに破られている」 === 2014 年にあらたな展開 === * Mueller の「委譲毒盛」を使った攻撃の再評価（前野）で、 co.jp などに簡単に毒が入ることがわかった。 * 鈴木は NS が上書きできるケースが多いことを示した。　 http://www.e-ontap.com/blog/20140415.html http://www.e-ontap.com/dns/endofdns.html http://www.e-ontap.com/dns/endofdns2.html === 攻撃手法 === [[DNS/キャッシュ毒盛]] [[/雨だれ攻撃]] [[https://en.wikipedia.org/wiki/DNS_spoofing|DNS_spoofing]] [[/成立の要件]] [[/taxonomy]] [[/poison]] https://moin.qmail.jp/DNS/RFC2181/s5 [[/Guide]] [[DNS/The Hitchhiker’s Guide to DNS Cache Poisoning]] https://www.nic.ad.jp/ja/newsletter/No40/0800.html　[[/nicの説明]] https://tools.ietf.org/html/rfc5452 == 経緯 == === Kaminsky 攻撃 === * Kaminsky流の攻撃手法により、毒盛の防御にはTTLは役にたたないことが示されました。 [[/Kaminsky手法]] {{{ Kaminsky 手法は「キャッシュされていない名前を問い合わせる」ことにより、「毒を送りつける機会を増やす」ものである。 }}} * どういうレコードをキャッシュさせるか（毒盛するか）は、次の段階の話です。 * Kaminsky が示した例では当時のBINDにすら毒盛できませんでした。 BIND各バージョンへの毒入れ実験 (Kaminsky Bug の検証) http://www.e-ontap.com/dns/bindmatrix.html https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf 民田スライドを参照 [[DNS/毒盛/Kaminsky手法/JPRS資料]] * しかし、 [[DNS/node_re-delegation]]の報告にあるように「委譲返答」を使った攻撃が有効であると分かっています。 　　 [[/Mueller手法]] による「委譲返答攻撃」 と呼びます。 === Mueller の委譲返答攻撃 === Mueller は偽委譲返答（NSなど）を送りこむ攻撃が考えられると言っています。　[[DNS/毒盛/Mueller手法]] Mueller paper の指摘では {{{ 　キャッシュにないレコードを毒として注入します。ここでもTTLは関係しません。（ランキングも） }}} ここまでが2008年に明らかになったことです。（それに世界が気づいていなかったとしたら不思議です。） 問い合わせポートのランダム化である程度の防御ができるからでしょう。 [[DNS/NSレコード/返答中のNS]] === Ghost Domain Names === そして、2012年には[[DNS/GhostDomainNames]]脆弱性が指摘されています。(これもキャッシュへの毒盛です） 　（上位サーバで）登録を削除されたはずのドメイン（幽霊）をキャッシュサーバに残す（活かし続ける）というもの。 　関連して「[[共用DNSサービスの危険性]]」を指摘しました。（サブドメイン登録など一部の問題は改善されました。） unbound などのキャッシュサーバ（実装）での対策も追加されていますが、十分利用されているとは言えません。 -- ToshinoriMaeno <> == いまも残る脅威 == A レコード(web サーバやDNSゾーンサーバ) はキャッシュされていることが多いので、対象としません。 === NS レコードが危ない === Mueller 手法にある NSレコードを狙うのが有効そうです。 RFC2181 では参照返答に含まれるNSレコードでキャッシュを上書きしてよいか、あいまいです。 　Mueller 手法で簡単にNSに毒を入れられるキャッシュ実装もありそうです。 {{{ 正規の返答がNXDOMAINであるような問い合せを送るので、 　毒盛したいNSレコードがキャッシュさせられることがない。 これにより効果的な攻撃になります。 }}} --> Kaminsky 流の「存在しない下位の名前」を問い合せて、一段上位のNSを返答します。 === NSレコードを持っていないノードが危ない === 現実のDNSゾーン構成を観察すると、簡単に毒盛できそうなケースが多数見つかります。 　2月に通報済みです。-- ToshinoriMaeno <> NSレコードを持たないノードです。たとえば、co.jp などの属性型JPドメイン名のおおもとです。 　JPRSはいまもこのことを公表していません。(-- ToshinoriMaeno <>) [[DNS/委任毒盛]] 一部の人だけが読めます。　-- ToshinoriMaeno <> == いますぐ確認して欲しいこと == {{{ ゾーンサーバとキャッシュサーバは分けていますか。 }}} {{{ キャッシュサーバのポートランダム化はお済みでしょうか。 }}} http://snoopy.e-ontap.com/　　　http://snoopy.e-ontap.com/announce.html 　危険なDNSサーバの利用者へ警告を行う活動を行っています == 毒盛に使う毒 == * キャッシュサーバにキャッシュされていなくて、 * 正当な権威サーバからの返事には含まれていなさそうで、 * 偽返答なら受け入れられそうなレコードとは： Answer Section ではなさそうですね。 Mueller にあるように Authoriyt Section 内の NS レコードが一番狙われ易い。 [[DNS/Authority_Section_Poisoning]] なかでも、[[DNS/委譲毒盛]] はターゲットを発見できれば、すぐにも毒盛できてしまう危険な手口です。 == キャッシュにあっても危ないかも == キャッシュが優先されて、置き換えが起きないのなら、 余計なお節介のNSレコードも毒盛防御には役にたっているのかもしれない。 でも、置き換えられるのではないか。 [[DNS/RFC2181/s5]] [[/root-servers.net]] == 参考情報 == [[DNS/キャッシュサーバの動作/毒盛耐性]] http://www.e-ontap.com/dns/bindmatrix.html (Kaminsky Bug の検証) [[DNS/GhostDomainNames]] [[DNS/GDN]] [[DNS/NSレコード/DNS返答中のNS]] [[DNS/BINDの歴史/場当たり的対応]] http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf 教科書には載っていないDNS　（JPRS　森下） DNSキャッシュポイズニング対策　IPA https://www.ipa.go.jp/security/vuln/DNS_security.html <> <>