## page was renamed from DNS/毒盛/NS毒盛/対策 ## page was renamed from DNS/毒盛/NS毒盛/対策はある ## page was renamed from DNS/毒盛/Kaminsky手法/対策はある <> ---- == DNS/毒盛/NS毒盛/対策 == <> {{{ (1) answer sectionが空でない返答(delegation返答ではない返答)を受けとったら、 　answer sectionにある情報だけを受け入れるのが安全です。 　authority sectionなどに毒が入っているかもしれません。 (2) delegation返答の場合でも、 すでに[[/ゾーンが存在しないしないことが推定できる返答]]を得ている状態であれば、 NSを問い合わせ直すことで毒を排除できます。 }}} すべてのdelegation返答を疑う必要はない。-- ToshinoriMaeno <> ---- [[DNS/毒盛/対策/NXDOMAIN返答活用]]に現状でのベストの対策を書きました。(実装はまだ） 　[[DNS/毒盛/Kaminsky手法]]では返答がNXDOMAINになるような問い合わせを利用します。 ところが、この[[DNS/返答/NXDOMAIN]]情報はリゾルバー側では活用されていまぜん。 この返答を利用することで、余分の手間をかけずにかなりの毒を排除できます。 　例：[[DNS/返答/NXDOMAIN/qmail.jp]] -- ToshinoriMaeno 2016-03-16 20:16:02 　NXDomain返答による妨害も考えておかないといけないでしょうけど、それはまだです。-- ToshinoriMaeno <> ワイルドカードを設定しているゾーンからの返答(Answer Section)ありの場合でも、 　zone cuts が存在しない名前を推定して、NS毒を排除できそうです。 　　系列ゾーンの同居の場合でも、隔世世代同居でなければ害はない。（害があっても気にしない） ---- Kaminsky(2008)のスライドにある攻撃方法は毒盛対策されたキャッシュに対しては成功の可能性は少ない。 攻撃の内容 {{{ $RANDOM.foo.com についての query を送りつける。(start) }}} 別の返答を考える。(民田スライド　IW2008-H3-07.pdf) {{{ 　$RANDOM.foo.com についての返答はあってもなくてもよい foo.com IN NS www.foo.com 　　 [authority section] www.foo.com IN A 6.6.6.6 [additional section] }}} この返答は拒否できるか。 　問い合わせ先が foo.com サーバであれば、 　ここでのauthority section, additional section は referral/delegation ではないことに注意せよ。 　Dan Kaminsky は delegation を使った攻撃だと言っているので、民田スライドは Kaminsky のものとは異なる。　 　additional section などは 　DNS キャッシュの効率を重視するなら、受け入れるのだろうが、セキュリティを犠牲にしてよいのか。 === 対策 === キャッシュされているレコードを上書きしない。 キャッシュの効率を少し下げることになるが、authority section, additional section を捨てる。 どちらも必須の情報ではないからだ。 (ヒント：$RANDOM.foo.com はどこに問い合わせたのか） ".com サーバ"に問い合わせた結果が上の返答だったのであれば、 "referralであり、glue である"ということになるが、 そのためには foo.com サーバの情報がキャッシュされていないという前提が必要である。 しかし、そういう前提についてはどこにも触れられていない。 -- ToshinoriMaeno <> === この対策で十分か === これで十分な対策かというと、残念ながらそうではない。 　　Bernhard Mueller re-delegation　を検索してみよ。 glue レコードを通常の A レコードと区別してキャッシュするという提案もあるが、回避した攻撃も可能である。 ------- 当面の対策としては (一年前だったら） 　1. 公開キャッシュサーバをやめる。 1. キャッシュサーバの使うportをランダム化する。 ことが重要である。 == 毒盛攻撃の検知も重要である == 無用な返答が多数送られてきたら、警告を発して、警戒モードに移る。 DNSSECを普及させたい人達はDNSSECしか解がないようなことを言っているが、 それは嘘である。ほかにも方法はあるし、DNSSECが急速に普及する可能性は小さい。 Kaminsky の指摘と警告があっても対策されていない DNS サーバが多数ある現状では、 「DNS を信用しない」という態度が重要であると考える。 たとえ対策ずみであっても、(ISP 提供の)公開キャッシュサーバは危険である。 == 攻撃の検知は有効か == 多数の問合せは検知できるとしても、時間をかけた攻撃の検知が可能とはかぎらない。 == 別の方向の対策 == それよりも、NSレコードの受け入れ検査をもっと厳しくする方が現実的だし、 TCPを使って DNS query やりとりを行う方が現実的だと思う。 TCPでは負荷が上がり過ぎというひとは、毒盛の危険性を小さく見ているのであろう。 -- ToshinoriMaeno <>