## page was renamed from DNS/キャッシュ毒盛/まとめ ## page was renamed from DNS/キャッシュ毒盛 ## page was renamed from DNS/キャッシュサーバ毒盛 ## page was renamed from DNS/キャッシュサーバ/毒盛 <> == DNS/キャッシュ毒盛 (2012-03-19 初稿） == <> [[/2014]] -- [[DNS/キャッシュサーバ]] -- [[DNS/毒盛]] -- [[DNS/毒盛再考]] <> <> The Hitchhiker’s Guide to DNS Cache Poisoning http://www.cs.utexas.edu/~shmat/shmat_securecomm10.pdf http://www.securecomm.org/2010/paperlist.shtml WSEC-DNS http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.155.3826&rep=rep1&type=pdf wild card DNS http://tools.ietf.org/search/draft-wijngaards-dnsext-resolver-side-mitigation-01 == 毒盛攻撃のターゲットは共用のキャッシュサーバだ == 毒盛は偽返答を送りつけることで成立するが、それには問い合わせをさせる必要がある。 　共用のキャッシュサーバなら、外部からでも問い合わせを簡単に起動できる。 　あるいはコンテンツサーバがキャッシュサーバと兼用になっている場合だ。 == 共用キャッシュサーバを避けよ == できれば、自前のキャッシュサーバを動かして、非公開の設定にせよ。 たしかに、bot化したPCが存在するネットワークではキャッシュへの毒盛は簡単だろう。 　ではDNSSECを入れたら安心か。違うのではないか。 [[/共用キャッシュサーバ]] == 外部からの再帰検索を禁止しても危険 == コンテンツサーバとキャッシュサーバが同居しているケースはまだ残っています。 　外部からのqueryでrecursion 禁止していても、内部ではキャッシュサーバとして使われているようです。 　port 固定の問い合わせを送ってくるので、簡単に分かります。毒を入れられ易い状態だと言えます。 http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug 内部キャッシュサーバを攻撃するひとつの方法 {{{ 　　 ... }}} [[/内部サーバの攻撃]] == キャッシュ毒盛対策にはTCP検索を推奨する == UDPだと送信元アドレスアドレスは詐称しやすい。TCPなら困難である。 　DNSサーバのTCPサポートは義務となった。TCPが重すぎるということはない。 　　TTLを長くすることで、上位サーバへの負荷は軽くできる。 　コンテンツサーバの負荷を減らすために、TTLを長くする圧力にもなる。 -- ToshinoriMaeno <> ---- 警告： __DNS キャッシュサーバへの毒盛攻撃__ (キャッシュポイズニング/キャッシュ汚染ともいわれています) * キャッシュサーバへの毒盛は DNS に内在する脆弱性を利用するものです。 * 公開、共用の DNS キャッシュサーバは特に危険です。 　　 キャッシュとコンテンツとは分けましょう。 * query port を random 化(patch, patch, patch!)していなければ、__１０分__程度で毒を盛られる可能性があります。 DNSSECしか解決方法がないような宣伝にはのせられないようにしましょう。 設定間違いが多数放置されているDNS管理の惨状を無視してDNSSECを推進するのは無謀です。 まずはDNSとはどういうものか理解しましょう。[[../基礎知識]] いまも[[/危険な大手サイト]]があります。(2009-04-13, 9-15 更新) 確認方法 https://www.dns-oarc.net/oarc/services/porttest ---- 利用者ができること 接続した先が偽サイトかもしれません。十分注意しましょう。 * フィッシング対策 http://www.antiphishing.jp/2008/09/post-23.html ガイドライン ----- == キャッシュサーバへの毒盛 == http://greyhat-security.com/dns-cache-poisoning-overview http://aspirationsoftware.com/indexthe-hitchhiker%E2%80%99s-guide-to-dns-cache-poisoning/ Kaminsky (2008-07)の発表で注目されました。(キャッシュ汚染とも呼ばれます。) * [[http://jvn.jp/cert/JVNVU800113/index.html|JVNVU#800113 複数の DNS 実装にキャッシュポイズニングの脆弱性 緊急]] * 「特定のキャッシュサーバ」に『短時間で』『偽情報(毒)』を紛れこませます。 * 多数の問合せをさせる方法は多数あって、Kaminsky の示した方法だけではありません。 [[http://marc.info/?l=namedroppers&m=121963095700960&w=2|Paul Vixie]] (なぜ、もっと早く警告されなかったか、という疑問は残りますが。) * 公開 DNS キャッシュサーバは特に危険です。すぐに使用をやめましょう。 * NAT/PAT device の内側の recursive namesever は『より危険』です。 [[../攻撃手法の説明]] -- [[http://jpinfo.jp/topics/080808.html|JPRS 説明図]] キャッシュポイズニング一般 [[../Kaminskyの攻撃手法]] -- http://www.doxpara.com/ Dan Kaminsky のページ -- [[../Kaminskyの警告]] -- [[http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html|Halvar Flake]] [[/対策]] -- [[/歴史]] [[DNSを信用するのは危険]] 毒盛対策の RFC http://tools.ietf.org/html/rfc5452 当然のことしか書いてありません。もっとやれることはあります。 === 緊急かつ必須の対策 === Kaminsky は今回の脆弱性を 2008 年初めに発見し、 いくつかのベンダーに通告したとのこと。 それらのベンダーが会合を持ったのが 3 月末で、修正版の公開が 7 月初めです。 この間に情報が漏れなかったという保証はありません。 {{{ query port を random 化 することです。(patch, patch, patch!) djbdns (dnscache)には公開当初から実装されています。 }}} 流れ弾(だま)に当る可能性を大幅に削減できます。 でも、これだけでは不十分です。 {{{ オープンリゾルバ(公開キャッシュサーバ)は非常に脆弱です。すぐに使用をやめましょう。 }}} === キャッシュサーバを分離しよう (管理者むけ) === キャッシュサーバを一般公開することはとても危険です。(オープンリゾルバ) * アクセスを制限して、危険性を減らすべきです。 * それには権威(コンテンツ)サーバとは分離しなくてはなりません。 * もともとコンテンツサーバとは分離するのが望ましいものです。 ==== まだまだ不十分 ==== アクセス制限しても、内部からの間接攻撃があります。 * 外部からのトラフィックバンド幅を制限すれば、攻撃されにくくなります。 * DNS 関係の活動の監視を怠らないこと。 * 余計な DNS 参照はしないこと。(逆引きも) * 利用者の啓発も重要です。 . DNS を信用すると危険なことを知らせましょう。 === キャッシュサーバでの対策 === 問い合わせのエントロピーを増やすことで危険を減らせます。 1. 問い合わせの大文字小文字化(randomに） 1. secure DNS cache by George Barwood === 利用者ができること === 自分が使っている DNS サーバ(キャッシュ)の安全度を確かめましょう。 * オープンリゾルバは特に危険です。使用をやめましょう。 * ISP を変えることも検討すべき時です。 * 共用リゾルバもできる限り避けましょう。 * 危ないページには近寄らないこと。 https://www.dns-oarc.net/oarc/services/dnsentropy Web-based DNS Randomness Test: port と transaction ID の分布を報告してくれます。 * POOR がでたら、ISP の DNS (キャッシュ) サーバを使うのをやめましょう。 * GREAT でも安心してはいけません。オープンリゾルバの可能性大です。 === ここまでやっても DNS は危険 === http://marc.info/?l=djbdns&m=121816690908827&w=2 UIC press release http://www.nytimes.com/2008/08/09/technology/09flaw.html NYT 記事 現状では接続した先が偽物かもしれないと思って、十分注意して使うしかありません。 　DNSSECが使えるためにはDNSSECで確認できないドメインのDNSレコードは捨てることができなければなりません。 　そんな状況には何年待ってもならないでしょう。 　そうなる前にDNSに依存するインターネットは使い物にならなくなっているでしょう DNSSECは解決策になりえるか？ DNSの脆弱性の発見者に聞く http://internet.watch.impress.co.jp/cda/special/2008/10/07/21090.html DNSSECの問題点も述べている。 === DNSCurve === [[DNSCurve]] が普及すれば状況は改善されますが、それにはまずあなたがDNSCurveを使うことから始める必要があります。 === 警告情報 === https://www.kb.cert.org/CERT_WEB\services\vul-notes.nsf/id/800113 . Multiple DNS implementations vulnerable to cache poisoning {{{ Insufficient transaction ID space Multiple outstanding requests Fixed source port for generating queries }}} http://jprs.jp/tech/security/multiple-dns-vuln-cache-poisoning.html 複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について * http://www.doxpara.com/ DJB の警告通りだった * BIND は去年にも同様の不良を指摘されています。 http://www.trusteer.com/files/BIND_9_DNS_Cache_Poisoning.pdf Klein * 今回のはより短時間で攻撃が成功する可能性があります。 * 欠陥のある DNS キャッシュを使っていると、2 分もしないで、 キャッシュに毒入れ(汚染)されるそうです。 Bruce Schneier: 　http://www.wired.com/politics/security/commentary/securitymatters/2008/07/securitymatters_0723 Lesson From the DNS Bug: Patching Isn't Enough == でも == Kaminsky のスライドでは攻撃可能なことや毒の内容の説明が不十分です。 * 偽返答を受入れてしまうキャッシュサーバにはスライドでは説明されていない欠陥がいくつもあります。 * BIND の不良データベースは非公開だそうです。 * http://fanf.livejournal.com/91801.html Tony Finch blog * Kaminsky は『議論は port random 化対策をやったあとで』というつもりのようです。 個別の対策をやってもきりがない、というのが現実なのでしょう。2009年8月現在、議論はなさそうです。 [[../BINDの歴史]] -- Kashpureff-style DNS cache corruption attack http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050411/158828/ (2005年の記事) == DNS 拡張 == http://www.jhsoft.com/dns-xqid.htm 拡張 transaction ID http://dnscurve.org/ DNSCurve ------ [[DNS]] 入門 [[DNSを信用するのは危険]]です。 詐欺にあってからでは遅いのです。 . [[インターネットを使う人]] ならだれでも [[DNS/Role|DNS の役割]]と [[DNS/Security|DNS の脆弱性、危険性]を . 理解しておくべきです。 DNS は『自己責任』で使うものだと理解しましょう。(それが現実だが、そうさせたくない人たちが甘い言葉を大声で） * [[DNSの諸問題]] . http://dns.measurement-factory.com/writings/whats-wrong-with-dns.pdf * [[../Myth|DNS に関する誤解集]] * [[../BIND博物館]] == 関連情報 == [[DNS/RFC]]　　[[/関連ページ]]　 http://djbdns.qmail.jp/jp/ djbdns 入門 -- http://tinydns.org/ tinydns.org -- http://wiki.tokai-ic.or.jp/hiki.cgi?OpenSourceSM13 これでいいのかインターネット (DNS 編) [[TIC セミナー 3/25]] [[DNS/TIC1021|問題提起編のスライド]] <> -- ToshinoriMaeno <>