## page was renamed from DNS/毒盛/手法の説明 ## page was renamed from DNS/攻撃/手法の説明 ## page was renamed from DNS/攻撃手法の説明 #pragma section-numbers on == DNS/毒盛/手法 == <> <> 警告: http://www.e-ontap.com/blog/20080831.html インターノット崩壊論者の日記などをみて、 こちらにやってこられた方へ . port random 化対策はおすみでしょうか。 [[DNS]] はお読みになったでしょうか。 . DNS の基礎を理解せずに、攻撃手法を理解しようとするのは時間の無駄です。 [[../キャッシュサーバへの毒盛]]もぜひ読んでください。 referral, glue という用語をおわかりですか。 . この先を読むにはこれらを理解していないとむずかしいと思います。 ---- == DNS/攻撃手法の説明 == 現状の DNS (特にキャッシュ)にはさまざまな脆弱性(の歴史)が存在します。 * DNS の仕様はデータの構成法が中心で、もともと動くかどうかさえ分らなかった時代のものです。 * 悪人はいないという前提で出発しています。 * BIND (named) の実装が事実上の仕様となっています。 * BIND の歴史は DNS の不良の歴史と言えます。:-) * 実装上の弱点、設定の問題点、そしてデータの間違いなど、あらゆる部分に セキュリティを脅かす種がひそんでいます。[[DNS/visa.co.jp事件]]はご存知ですか。 === キャッシュサーバの脆弱性 (1) === * 問合せ port が固定されているサーバ (patch, patch, patch!) . 予測可能だけでも論外なのに (BIND など) * port 変換に問題のある firewall 装置 * transaction ID が予測可能なサーバ * 問合せ元を制限していない(公開)キャッシュサーバ(権威サーバ兼用も) * 「誕生日のパラドックス」手法に弱いキャッシュサーバ === キャッシュサーバの脆弱性 (2) === * referrals 返答がキャッシュに優先して書込まれる実装 * glue がキャッシュに優先して書込まれる実装 1. BIND では A レコードとは別に扱かわれることがあるが不十分 1. glue を無視することができない現状 === Kaminsky の発見した攻撃法 (2008-08-06 公開) === 多数の問合せを送りださせ、その返答として偽パケットを送りつけます。 transaction ID が合致することを期待する方法です。 . ただし、transaction ID が合致しただけでは毒盛できません。 送られるデータ(DNS レコード)については詳しい説明はされていません。 DNS キャッシュ(実装)に対応した攻撃データまでは公開されていません。 [[../Kaminskyの攻撃手法]] 公開されている攻撃コード: Kaminsky の発見に基づくとあります。 http://www.caughq.org/exploits/CAU-EX-2008-0002.txt http://www.caughq.org/exploits/CAU-EX-2008-0003.txt 多数の問合せをさせる方法は Kaminsky の方法以外にもたくさん存在するようです。 . このため、現在は port random 化が最優先の実行可能な対策となります。 == 基本対策 == 1. query port randomization などの entropy 増大策 (patch も) 1. アクセス制限 (公開は非常に危険) 1. コンテンツサーバとの分離 1. 外部からのトラフィック制限 (監視) Kaminsky は「まずは port randomizationを」と言っています。議論はその後で。 === 毒入れは簡単ではない === port と transaction ID が一致するだけで必らず毒入れされる訳ではありません。 世間の多くの記事(特に日本語の記事)はこの意味で間違っています。 しかしながら、毒盛手法(**)は存在しますから、 『patch しなくても安全という意味ではありません。』 念のため。 ---- (**) re-delegation 攻撃: [[/Bernhard Mueller]]によりre-delegation攻撃という方法が公表されています。 . glueレコードではなく、ドメインとして乗っ取るということのようです。 X-( ---- 毒盛手法がきちんと説明されていないことの背景は以下のようなものでしょう。 * 毒には多数の亜種が存在します。これらに対応する簡単な対策は存在しないでしょう$ * 手法をひとつでも完全に説明することは悪用される危険を招きます。 * port random 化されていないサーバはとても危険です。 * Black Hat でのKaminsky の講演やスライドは毒の説明をしていません。 　「(referral 毒を)受入れる実装なら、毒入れできる」とだけあります。その通りです。 * 公開されている攻撃コードも成功する条件までは明記されていません。 * DNSSEC が唯一の解決策であると書いてあるのは真実ではありません。 　　DNSSECを推進したい人が多数います。 * 『王様は裸だ』と言えない大人が大部分だからでしょう。 === 対抗手段 === 解決策ではありません。提案されているものなどの紹介です。 glue を受入れてよいかの条件を見直す。 * NS レコードはキャッシュを優先し、書き換えを控える。 . TTL の効果を発揮させられるケースが増える。しかし、迂回攻撃(Kaminsky)も可能。 * glue は A レコードとは区別すること(trust分離)で、毒を無効化できる場合がある。 . BIND では Kaminsky attack で迂回攻撃される。 unbound 1.0.2 はキャッシュを優先することで、毒盛を(部分)防御する。 * 非 glue A レコードは原則破棄するのが有効だが、DNS トラフィックが増加する。 * 毒盛されやすい zone 設定、レコード設定をさけるという運用もありそうです。 問合せに TCP を使うなどの影響が大きそうな対策は別途検討します。 [[DNSCurve]]を使うのもいいでしょう。 === 功罪 === キャッシュを優先すると、サーバの変更に即時追従できなくなる。 . キャッシュをあふれさせる攻撃も可能であり、 キャッシュあふれの対策を施せるか。 == 参考資料 == [[../毒盛の脆弱性]] RFC 2181 Clarifications to the DNS Specification ---------- 前野年紀 [[質問歓迎]]