なぜDNS増幅攻撃について書くのか？
先週（2006/3/29）、"http://www.jpcert.or.jp/at/2006/at060004.txt">JPCERTやJPRSが注意喚起を呼びかけた"DNS
の再帰的な問合せを使った DDoS"の件。
本質的な危険が理解されないまま途方にくれている方が多そうなのでフォローします。
DNS増幅攻撃とは
まず"DNS の再帰的な問合せを使った DDoS攻撃"というのが表現が分かりにくいのですが、これはDNS
Amplification Attacksという攻撃の手法を指しています。
ここではDNS増幅攻撃と呼びます。今回のJPCERT,JPRSからのアナウンスの意図を理解するには、
このDNS増幅攻撃を理解することが大切ですので、ここで説明します。
DNS増幅攻撃の登場人物は以下のとおりです。
攻撃者：DNS増幅攻撃する悪意あるクラッカー
踏み台：不適切な設定のDNSサーバ、及びその管理者
犠牲者：DNS増幅攻撃の犠牲になる人（具体的には、
2006年あたまからVeriSignがこの攻撃を受けています。）
どのように攻撃が成立するかというと・・・
１、攻撃者はDNSサーバにソースIPを偽装したDNSリクエストを送る。
２、DNSサーバは偽装されたIPに対してリクエストの結果を送信する。
３、結果的に犠牲者のネットワークに大量のDNSトラフィックが押し寄せて、通信の遅延などが発生する。
ということです。
既存のDoSとの違い
ここまで読んで、「なんだ今までBotNetがやっていたことと変わらないじゃないか？」と思った方は鋭いです。
確かにここまではありきたりなDDoSの一種と大差ありません。ここからがポイントです。
DNSを使った名前解決はクエリー要求とクエリー応答の通信量の差が大きいです。
試しに、nslookupコマンドで""return top.js.OpenExtLink(window,event,this)"
href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp"の全てのレコードを要求してみます。
style="MARGIN-RIGHT: 0px">
> set type=all
> href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
Server: "return top.js.OpenExtLink(window,event,this)"
href="http://ns1.mss-iss.ne.jp/"
target="_blank">ns1.mss-iss.ne.jp
Address: "return top.js.OpenExtLink(window,event,this)"
href="http://211.19.41.185/"
target="_blank">211.19.41.185
Non-authoritative answer:
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
internet address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.128.254/"
target="_blank">133.11.128.254
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
MX preference = 10, mail exchanger = "return top.js.OpenExtLink(window,event,this)"
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp nameserver =
href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp
href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp nameserver =
href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp
href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp nameserver =
href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
internet address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.128.254/"
target="_blank">133.11.128.254
href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp AAAA IPv6
address = 2001:200:180::35:3
href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://157.82.0.1/"
target="_blank">157.82.0.1
href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp AAAA IPv6
address = 2001:200:180::35:1
href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.0.1/"
target="_blank">133.11.0.1
href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp AAAA IPv6
address = 2001:380:1ab::35:2
href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://219.166.230.42/"
target="_blank">219.166.230.42
このときクライアントからDNSサーバへの通信は53byteです。
たいしてDNSサーバからの応答は各種レコード、IPv6アドレスなどが含まれており、
約7倍の350byteもの通信が発生します。
たとえばDoSを仕掛ける攻撃者が32Kbpsのダイヤルアップ回線を使っていたとしましょう。
攻撃者が直接www.u-tokyo.ac.jpにDoSをしたとしても、
細いダイヤルアップ回線がボトルネックとなって、
1時間で犠牲者のネットワークに送ることのできるトラフィックは10MByte程度にしかなりません。（図「普通のDoS」）
![]( "dos_normal")
height="360"
alt="dos_normal"
src=
"http://blog.sparky.jp//media/img_20060404T230925404.jpg"
width="353" />
そこでDNS増幅攻撃の登場です。攻撃者は再帰問い合わせを許すDNSサーバにクエリー要求をします。
ソースIPが偽装されているのでDNSサーバからの応答は"http://www.u-tokyo.ac.jp">www.u-tokyo.ac.jpに送られます。
このトラフィックは、クライアントからDNSサーバへの通信の約7倍ですので、先ほどの7倍約70MByteになります。。
（図「DNS増幅攻撃を使ったDoS」）
![]( "dos_dnsamp")
height="360"
alt="dos_dnsamp"
src=
"http://blog.sparky.jp//media/img_20060404T230926295.jpg"
width="367" />
このようにDNSのプロトコルの性質を巧みに利用して、
今までのDDoS以上のトラフィックを犠牲者のネットワークに送りつけることをDNS増幅攻撃と言います。
DNS増幅攻撃をもっと増幅する方法!？
増幅が7倍という風に書きましたがこれはあくまで一例で、7倍以上に増幅する方法もあります。"return top.js.OpenExtLink(window,event,this)"
href="http://www.isotf.org/news/DNS-Amplification-Attacks.pdf"
target=
"_blank">http://www.isotf.org/news/DNS-Amplification-Attacks.pdfにはクエリーの方法を変えて60byteのDNSクエリーに対して、
合計4320 Byteの通信を発生させられるとあります。この場合、72倍の増幅攻撃が成立します。
またSmurfの手法を応用するということが考えられます。
SmurfはソースIPをブロードキャストアドレスにするという手法でしたが、
この手法を応用してDNS増幅攻撃をさらに増幅するという攻撃例がすでにあるそうです。
そして中長期的視点から考えた場合、DNSのクエリー応答の通信量は増える傾向にあります。
DNSが多機能化してきているからです。
IPv6,DNSSEC,NAPTRなどをサポートするようになればDNSサーバからの通信量はさらに増加します。
DNS増幅攻撃が行いやすくなると言えます。
対策
DNS増幅攻撃を許してしまう主な原因は以下の2つです。
１、キャッシュサーバが誰からのクエリーでも応答する設定になっている。
２、spoofされたトラフィックを外部に流すことを許しているネットワークが多い。
この2つの原因、どちらかを是正することでDNS増幅攻撃を止めることができます。
対策についてはJPRS,JPCERTからのアドバイザリに詳しく載っていますので、そちらを参照してください。
このアドバイザリが出たのは、このような背景、
そして現実に被害を受けているサイトがあるという現実を踏まえて
「とりあえず比較的対策が簡単なキャッシュサーバの設定を是正をしていきましょう」という意図だと思います。
最後に
誰からのクエリーでも応答するDNSキャッシュサーバのことを、「オープンルックアップ」といいます。
MTAの「オープンリレー」になぞらえているんでしょう。
様々な方ががんばった結果、MTAに関してはSPAMの中継をしないようにきちんと設定する
（=オープンリレーのMTAを放置しない）という意識が、管理者一般に浸透しています。
同じようにDNSもオープンルックアップのまま外部に公開していると、
他サイトへのDDoSの踏み台になる可能性があるということを広く伝える地道な努力が必要です。
参考
DNS Amplification Attacks
href="http://www.isotf.org/news/DNS-Amplification-Attacks.pdf"
target=
"_blank">http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
The Continuing Denial of Service Threat Posed by DNS
Recursion
href=
"http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf"
target=
"_blank">http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf
DNS の再帰的な問合せを使った DDoS 攻撃に関する注意喚起
href="http://www.jpcert.or.jp/at/2006/at060004.txt"
target=
"_blank">http://www.jpcert.or.jp/at/2006/at060004.txt
DNS の再帰的な問合せを使った DDoS 攻撃の対策について
href=
"http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html"
target=
"_blank">http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html
どなたかのホームページ
href=
"http://www.vwnet.jp/mura/BookFollow/JPCERT-AT-2006-0004.htm"
target=
"_blank">http://www.vwnet.jp/mura/BookFollow/JPCERT-AT-2006-0004.htm
激しいDDoS攻撃の詳細を明らかにしたVeriSign社
href=
"http://blog.privacy-jp.com/index.php/2006/03/18/e_sei_ao_a_ra_na_ifdifpa_cs_c_ca_a_a_da"
target=
"_blank">http://blog.privacy-jp.com/index.php/2006/03/18/e_sei_ao_a_ra_na_ifdifpa_cs_c_ca_a_a_da
（警察庁の翻訳）
href=
"http://www.techworld.com/security/news/index.cfm?NewsID=5586"
target=
"_blank">http://www.techworld.com/security/news/index.cfm?NewsID=5586
（原文）
