DNS/毒盛/キャッシュ毒盛/まとめ

　　 <img src="http://aaaa.example.com/image.jpg"/>
    <img src="http://aaab.example.com/image.jpg"/>
    <img src="http://aaac.example.com/image.jpg"/>
    ...

/内部サーバの攻撃

5. キャッシュ毒盛対策にはTCP検索を推奨する

UDPだと送信元アドレスアドレスは詐称しやすい。TCPなら困難である。

DNSサーバのTCPサポートは義務となった。TCPが重すぎるということはない。
- TTLを長くすることで、上位サーバへの負荷は軽くできる。
コンテンツサーバの負荷を減らすために、TTLを長くする圧力にもなる。

-- ToshinoriMaeno 2011-05-19 15:25:53

警告： DNS キャッシュサーバへの毒盛攻撃 (キャッシュポイズニング/キャッシュ汚染ともいわれています)

キャッシュサーバへの毒盛は DNS に内在する脆弱性を利用するものです。
公開、共用の DNS キャッシュサーバは特に危険です。
- キャッシュとコンテンツとは分けましょう。
query port を random 化(patch, patch, patch!)していなければ、１０分程度で毒を盛られる可能性があります。

DNSSECしか解決方法がないような宣伝にはのせられないようにしましょう。

設定間違いが多数放置されているDNS管理の惨状を無視してDNSSECを推進するのは無謀です。
まずはDNSとはどういうものか理解しましょう。../基礎知識

いまも/危険な大手サイトがあります。(2009-04-13, 9-15 更新)

確認方法 https://www.dns-oarc.net/oarc/services/porttest

利用者ができること

接続した先が偽サイトかもしれません。十分注意しましょう。
- フィッシング対策 http://www.antiphishing.jp/2008/09/post-23.html ガイドライン

6. キャッシュサーバへの毒盛

http://greyhat-security.com/dns-cache-poisoning-overview

http://aspirationsoftware.com/indexthe-hitchhiker%E2%80%99s-guide-to-dns-cache-poisoning/

Kaminsky (2008-07)の発表で注目されました。(キャッシュ汚染とも呼ばれます。)

JVNVU#800113 複数の DNS 実装にキャッシュポイズニングの脆弱性緊急
「特定のキャッシュサーバ」に『短時間で』『偽情報(毒)』を紛れこませます。
多数の問合せをさせる方法は多数あって、Kaminsky の示した方法だけではありません。
Paul Vixie (なぜ、もっと早く警告されなかったか、という疑問は残りますが。)
公開 DNS キャッシュサーバは特に危険です。すぐに使用をやめましょう。
NAT/PAT device の内側の recursive namesever は『より危険』です。

../攻撃手法の説明 -- JPRS 説明図キャッシュポイズニング一般

../Kaminskyの攻撃手法 -- http://www.doxpara.com/ Dan Kaminsky のページ -- ../Kaminskyの警告 --

Halvar Flake

/対策 -- /歴史 DNSを信用するのは危険

毒盛対策の RFC http://tools.ietf.org/html/rfc5452

当然のことしか書いてありません。もっとやれることはあります。

6.1. 緊急かつ必須の対策

Kaminsky は今回の脆弱性を 2008 年初めに発見し、いくつかのベンダーに通告したとのこと。それらのベンダーが会合を持ったのが 3 月末で、修正版の公開が 7 月初めです。この間に情報が漏れなかったという保証はありません。

query port を random 化 することです。(patch, patch, patch!)
    djbdns (dnscache)には公開当初から実装されています。

流れ弾(だま)に当る可能性を大幅に削減できます。でも、これだけでは不十分です。

  オープンリゾルバ(公開キャッシュサーバ)は非常に脆弱です。すぐに使用をやめましょう。

6.2. キャッシュサーバを分離しよう (管理者むけ)

キャッシュサーバを一般公開することはとても危険です。(オープンリゾルバ)

アクセスを制限して、危険性を減らすべきです。
それには権威(コンテンツ)サーバとは分離しなくてはなりません。
もともとコンテンツサーバとは分離するのが望ましいものです。

6.2.1. まだまだ不十分

アクセス制限しても、内部からの間接攻撃があります。

外部からのトラフィックバンド幅を制限すれば、攻撃されにくくなります。
DNS 関係の活動の監視を怠らないこと。
余計な DNS 参照はしないこと。(逆引きも)
利用者の啓発も重要です。
- DNS を信用すると危険なことを知らせましょう。

6.3. キャッシュサーバでの対策

問い合わせのエントロピーを増やすことで危険を減らせます。

問い合わせの大文字小文字化(randomに）
secure DNS cache by George Barwood

6.4. 利用者ができること

自分が使っている DNS サーバ(キャッシュ)の安全度を確かめましょう。

オープンリゾルバは特に危険です。使用をやめましょう。
ISP を変えることも検討すべき時です。
共用リゾルバもできる限り避けましょう。
危ないページには近寄らないこと。

https://www.dns-oarc.net/oarc/services/dnsentropy

Web-based DNS Randomness Test: port と transaction ID の分布を報告してくれます。

POOR がでたら、ISP の DNS (キャッシュ) サーバを使うのをやめましょう。
GREAT でも安心してはいけません。オープンリゾルバの可能性大です。

6.5. ここまでやっても DNS は危険

http://marc.info/?l=djbdns&m=121816690908827&w=2 UIC press release

http://www.nytimes.com/2008/08/09/technology/09flaw.html NYT 記事

現状では接続した先が偽物かもしれないと思って、十分注意して使うしかありません。

DNSSECが使えるためにはDNSSECで確認できないドメインのDNSレコードは捨てることができなければなりません。そんな状況には何年待ってもならないでしょう。そうなる前にDNSに依存するインターネットは使い物にならなくなっているでしょう

DNSSECは解決策になりえるか？ DNSの脆弱性の発見者に聞く

http://internet.watch.impress.co.jp/cda/special/2008/10/07/21090.html
- DNSSECの問題点も述べている。

6.6. DNSCurve

DNSCurve が普及すれば状況は改善されますが、それにはまずあなたがDNSCurveを使うことから始める必要があります。

6.7. 警告情報

https://www.kb.cert.org/CERT_WEB\services\vul-notes.nsf/id/800113

Multiple DNS implementations vulnerable to cache poisoning

        Insufficient transaction ID space
        Multiple outstanding requests
        Fixed source port for generating queries

http://jprs.jp/tech/security/multiple-dns-vuln-cache-poisoning.html 複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

http://www.doxpara.com/ DJB の警告通りだった
BIND は去年にも同様の不良を指摘されています。
http://www.trusteer.com/files/BIND_9_DNS_Cache_Poisoning.pdf Klein
今回のはより短時間で攻撃が成功する可能性があります。
欠陥のある DNS キャッシュを使っていると、2 分もしないで、キャッシュに毒入れ(汚染)されるそうです。

Bruce Schneier:

http://www.wired.com/politics/security/commentary/securitymatters/2008/07/securitymatters_0723
- Lesson From the DNS Bug: Patching Isn't Enough

7. でも

Kaminsky のスライドでは攻撃可能なことや毒の内容の説明が不十分です。

偽返答を受入れてしまうキャッシュサーバにはスライドでは説明されていない欠陥がいくつもあります。
BIND の不良データベースは非公開だそうです。
http://fanf.livejournal.com/91801.html Tony Finch blog
Kaminsky は『議論は port random 化対策をやったあとで』というつもりのようです。個別の対策をやってもきりがない、というのが現実なのでしょう。2009年8月現在、議論はなさそうです。

../BINDの歴史 -- Kashpureff-style DNS cache corruption attack

http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050411/158828/ (2005年の記事)