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