## page was renamed from DNS/毒盛/キャッシュ毒盛/2014 ## page was renamed from DNS/キャッシュ毒盛/2014 DNS/キャッシュ毒盛/2014について、ここに記述してください。 == 毒盛道具の歴史 == 1. 問い合わせ手法： キャッシュにないドメイン名を問い合わせることで、問い合わせを送信させる [D. Kaminsky 2008] TTLは毒盛防御の道具ではない。連続した問い合わせを効率的に処理するための仕組み 1. パケット偽装： UDP アドレス偽装だけでなく、フラグメントの後半に毒を盛る手法もでてきた。 [2008, 2013] 1. ターゲットの選択: キャッシュされていない RRSet (ラベル、タイプ）を送り込む　[B. Mueller 2008] 　　 NS レコードを送り込むのは毒として効果的だからだ。キャッシュ上書き可能という理由もある。 1. Hitchhiker's Guide [2010]　毒盛手法のまとめ (Mueller 攻撃は含まれていない） == ターゲットの存在証明 == 毒盛し易いドメイン名（ゾーン名）が身近に存在する。 　 co.jp などの属性型jpドメイン名である。（JPRSには連絡ずみである。３ヶ月たっても公式発表はない。） == RFC 2181 Ranking == キャッシュ毒盛攻撃を防ぐものではない。（設定間違いをどう始末するかの案） 　特にAuthority/Additionl section 中の RRSet の扱いがよくない。 　　毒盛を助長する仕様になっていると言ってもいいくらい。 特に NS 移転通知 (Authority Section) を認めるかどうかの問題がある。（効用よりも害の方が大きいようだ） (参考） Ghost Domain Names 脆弱性 などで BIND の不十分な対応がさらされた。 Google Public DNS はこの脆弱性に対応しているような記述がある。 　 だが、具体的な脆弱性は公表しない。理由はご想像の通りだろう。 == 対策 == 1. ポートランダム化などの問い合わせエントロピーの増加 1. 攻撃を検知する仕組み。検知したら、キャッシュクリア（サービスに影響のない範囲で） 1. Public DNS Service (キャッシュサーバ）を利用する。 1. フラグメントパケットを使わない。　使われたら捨てる。　（EDNS０？） 1. キャッシュする条件をきびしくする。（特に NS） 1. その他（？） DNSSEC を持ち出す前にやること。　TCP 利用（UDPやめ）。 1. DNSCurve などのUDP暗号化 == 偽装パケットの排除 == https://www.ipa.go.jp/security/rfc/RFC3704JA.html {{{ BCP 38, RFC 2827 は、 偽装されたアドレスでネットワークにアクセスするトラフィックを拒否することによって、 分散型サービス妨害攻撃の影響を制限し、 「トラフィックについて、その正しい発信元ネットワークを追跡可能であること」を確保し易くすることを意図しています。 }}} http://tools.ietf.org/html/bcp38 -- ToshinoriMaeno <>