<> ---- = DNS/毒盛/対策 = <> 設定のむずかしいDNSSECを使わなくとも、安全にできることを示す。 この対策が簡単だとは言わない。 　中間者攻撃は別の方法で対策すべき。[[../防衛]] Measures for Making DNS More Resilient against Forged Answers https://tools.ietf.org/html/rfc5452 == アクセス制限 == 共用リゾルバーは危険です。 == エントロピー == [[/DNS-cookies]] [[/port-randomize]] [[/0x20]] 送信ポートとTXIDとのランダム化をしていないのは論外 == TCP == 毒盛が容易になる理由は送信元を詐称できるUDP利用です。 . TCPで毒盛が容易かどうかは分かっていませんが、TCPの方がより困難になるでしょう。 リゾルバーはqueryにはTCPだけを使うことを勧めます。 ゾーンサーバー側はUDP queryにはTC onの返答を返して、TCPによる問い合わせ直しを促すのがよいでしょう。 -- ToshinoriMaeno <> == 返答処理 == [[DNS/毒盛/AncillaryDataAttacks]] は捨てて、余計な処理をしない。 次の項目に関連する。 == キャッシュ優先 == 問い合わせを減らせるという理由でキャッシュにあるものを上書きするのは安全を傷つける。 {{{ キャッシュ優先を原則にすべきである。 }}} あらたな項目をキャッシュにしまうときには十分に注意すべきことは言うまでもない。 == キャッシュの管理 == 毒の影響を軽くするために、長すぎるTTLは制限する。([[DNS/GhostDomainNames]]) == NS毒 == Kaminsky/MuellerらはNSレコードとCNAMEレコードを使った攻撃を指摘しています。 === NS毒対策 === [[/NS毒]]：'''''キャッシュにあるNSを優先する。 ''''' . Answerあり返答のAuthority Sectionは捨てる。 [[/委譲返答毒]]は[[/先行するNXDomain返答]]などを利用して問い合わせを減らしつつ、 . 再問い合わせにより毒見する。 [[DNS/qname_minimisation]] を採用していれば、排除できる場合も多い。 委譲返答は再問い合わせする。 NXDOMAIN返答などではNSは受け取らない。-- ToshinoriMaeno <> == CNAME毒 == . [[/CNAME毒]]： . 先行するNoData返答を利用すれば、判別可能。([[/非存在判定]]） Answerなし返答のAuthority Sectionで、NSレコードを返してくるものがある。 . しかも、委譲返答ではない。 これらも当然捨てるべきだが、キャッシュを上書きする実装もありそう。(未確認） . -- ToshinoriMaeno <> = NS毒対策議論 = [[/非存在推定]] https://twitter.com/beyondDNS/status/806658529926856704 [[/NSがキャッシュにない場合]] [[/NSを上書きする毒]] . これ../AncillaryDataAttacks（2008)を十分吟味していなかったことは反省しなくてはならない。 tssのいう「移転インジェクション」とは実装不良の産物だから。 https://twitter.com/beyondDNS/status/1399196843855159299?s=20 {{{ 手元のキャッシュサーバーでの毒盛対策で残る課題はMueller流のNS毒です。 (NSレコードを持たないドメイン名にNS毒を盛る攻撃) 例えば、co\.jp NSを受け入れさせることです。 co\.jp がNSを持たないという情報をもたせるのが簡単な対策になります。 *\.co\.jp についての問い合わせはjpサーバーに送るという設定ができるので、 co\.jp ドメインだけであれば、簡単に対応できます。 (jp下の属性ドメイン名も同様) でも、地域型とかになると、数も多いので、別の方法を考えないといけないでしょう。 Public Suffix List 風のDBを用意しておくのもひとつの方法でしょう。 }}} == 記事 == January 12, 2017 Matthew Bryant (mandatory) @IAmMandatory Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target https://thehackerblog.com/respect-my-authority-hijacking-broken-nameservers-to-compromise-your-target/ ドメインのname serverに欠陥があって、乗っ取れるケース; == 2016年の成果 == 毒盛手法の整理と対策の整理：[[/zone cutsの非存在]]を決定できる情報を見過ごしていた。 . 否定返答のSOAレコードからzone cutsの非存在情報を取り出しておけば、委譲NS毒の多くは排除できる。 {{{ 毒見ずみの委譲返答は念のため再問い合わせする。TCPを使うことを勧める }}} === NXDomain/NoData === [[/NXDOMAIN返答活用]] と [[/NoData返答活用]] 実装はまだない。 . Answer (Section)のある[[/肯定返答]]も利用できそうです。 ほかにも考えられますが、zone cutsの不在情報を利用する毒見が効果的だと考えています。 . 直系ゾーンが同居していると、単純な不在情報ではなくなるので、検討しています。 === より簡単なやり方 === 二つの原則で毒は実用上十分に排除できる。（問い合わせが多少増える） 1. delegation返答をもらったら、nonceつきでNSを問い合わせなおす。これでdelegation毒は排除できる。 1. answer sectionありの返答ではanswer sectionだけ受け取り、他は捨てる。 == 2015年までのまとめ == 無差別毒盛対策としては以下のみっつを守ればよい。 1. 返答中の補助情報はすべて捨てる。(../AncillaryDataAttacks対策） 1. ただし、委譲返答が返ってきたときには、キャッシュされていないことを確認したあと、TCPで問い合せしなおす。 . また、もらった委任情報自身はキャッシュせずに、委任先にNS, A を問い合わせて、キャッシュしておく。 1. キャッシュは上書きしない。 （１ を守っていれば、上書きはまずおきない） １. により、キャッシュされる情報が減ることも考えられるが、２. により補う。 Answer Section (つまり、問い合せたレコード）に毒が入るケースとしてはどういうものがあるだろうか。 . Kaminsky流攻撃ではrandomドメイン名に対するものだろうから、毒はキャッシュされても使われることはなかろう。 手元のdnscache(djbdns)では実装ずみ。特に問題はおきていないと思う。 . たまにTCP対応していないドメインに遭遇する。w　-- ToshinoriMaeno <> UDPを使うときには、query source port randomizationはあった方がいい。 == 2014年以前 == https://twitter.com/beyondDNS/status/462005198265675777 . 今回(2014)のDNSキャッシュ毒盛は新たな攻撃手法の発見などではない。 ６年前に公表されたMueller 手法 （Kaminsky攻撃を活用） を適用しただけです。 それが go.jp のような重要なドメイン名へ簡単に毒盛できることを示したものです。 Mueller 手法を使えば、ほぼすべてのドメイン名に毒をいれられそうだ、というのが発見と言えなくもない。 ポートランダム化していないキャッシュサーバは鍵のかかってない家も同然です。 == キャッシュサーバでの対応例 == 毒盛脆弱性に対しての対応にどういう態度が見られるか、整理してみよう。 . 属性型 jp ドメインを例に * port randomization だけで十分だ。 (問題はrandomize しない管理者だ。） * DNSSECがあるじゃないか。　（DNSSECを使わないのが悪い。） * 検知したら、キャッシュクリアすればよい。　（現実的？） * 追加の検査をする。 (キャッシュサーバの改訂）　[キャッシュサーバの作成者の立場？] * DNS仕様の改善　[DNS設計者の立場] * 脆弱性など存在しない。　[ただの利用者だけかと思ったら] == ドメイン空間の改善 == NSレコードのない中間ノードは作らない。 末端のノードにもすべて NS を付けるとなると、別の問題が起きそうで、勧めない。 -- ToshinoriMaeno <> リゾルバーでNS毒見をするのが本筋です。-- ToshinoriMaeno <> == IETF ML == https://tools.ietf.org/html/draft-barwood-dnsext-fr-resolver-mitigations-08 . [[/barwood]] https://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01 . [[/wijngaards]] ---- <> ----