DNS/キャッシュ毒盛/2014について、ここに記述してください。

1. 毒盛道具の歴史

  1. 問い合わせ手法： キャッシュにないドメイン名を問い合わせることで、問い合わせを送信させる [D. Kaminsky 2008]
    • TTLは毒盛防御の道具ではない。連続した問い合わせを効率的に処理するための仕組み
  2. パケット偽装： UDP アドレス偽装だけでなく、フラグメントの後半に毒を盛る手法もでてきた。 [2008, 2013]
  3. ターゲットの選択: キャッシュされていない RRSet (ラベル、タイプ）を送り込む　[B. Mueller 2008]
    • NS レコードを送り込むのは毒として効果的だからだ。キャッシュ上書き可能という理由もある。
  4. Hitchhiker's Guide [2010]　毒盛手法のまとめ (Mueller 攻撃は含まれていない）

2. ターゲットの存在証明

毒盛し易いドメイン名（ゾーン名）が身近に存在する。

3. RFC 2181 Ranking

キャッシュ毒盛攻撃を防ぐものではない。（設定間違いをどう始末するかの案）

特に NS 移転通知 (Authority Section) を認めるかどうかの問題がある。（効用よりも害の方が大きいようだ）

(参考） Ghost Domain Names 脆弱性 などで BIND の不十分な対応がさらされた。

Google Public DNS はこの脆弱性に対応しているような記述がある。

だが、具体的な脆弱性は公表しない。理由はご想像の通りだろう。

4. 対策

  1. ポートランダム化などの問い合わせエントロピーの増加
  2. 攻撃を検知する仕組み。検知したら、キャッシュクリア（サービスに影響のない範囲で）
  3. Public DNS Service (キャッシュサーバ）を利用する。
  4. フラグメントパケットを使わない。　使われたら捨てる。　（EDNS０？）
  5. キャッシュする条件をきびしくする。（特に NS）
  6. その他（？） DNSSEC を持ち出す前にやること。　TCP 利用（UDPやめ）。
  7. 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