過去最大300Gbps超のDDoS攻撃に悪用されたDNSの「オープンリゾルバー」とは

　2013年3月、極めて大規模なDDoS攻撃が発生した。スパム対策組織のSpamhaus Projectと、今回の事件に際し同組織を支援した米Cloudflare社を攻撃目標としたもので、INTERNET Watchでも、その内容を受けて3月28日に「ネットを崩壊の瀬戸際に追い込んだ『史上最大のサイバー攻撃』が明るみに」と題した記事を掲載している。

　このDDoS攻撃の概要や経緯については、攻撃を受けたSpamhausやCloudFlareをはじめ、米国のSANS Internet Storm Centerといったセキュリティ専門機関などからもすでに調査報告などが発表されている。それらを見ると、「オープンリゾルバー」と呼ばれるDNSサーバーが攻撃に悪用されたという点ではおおむね共通しているが、本当のところはどうなのだろうか？　日本のccTLD「.jp」を管理・運用し、DNSに関する技術情報の提供も行っている株式会社日本レジストリサービス（JPRS）の技術広報担当である森下泰宏氏に話をうかがった。

DDoS攻撃は、SpamhausとCyberBunker/A2B Internet間の争いが発端

株式会社日本レジストリサービスの森下泰宏氏

――今回のDDoS攻撃はどのようなものだったのでしょうか。

　今回の事件については、現在までにさまざまなメディアやセキュリティ関連組織が情報を発信しています。その中でも比較的信頼性が高いと考えられる米国のセキュリティ専門機関SANSや、米Ciscoの専門家が執筆しているセキュリティブログによると、今回のDDoS攻撃ではこれまでで最大規模となる300Gbps以上のトラフィックを観測したとのことです。あるTier1 ISPに勤務している私の知人からも、これを裏付ける話をうかがっています。そして、今回のDDoS攻撃による大量のトラフィックにより、欧州を中心とする複数のIX（インターネットエクスチェンジ）において、一時的な遅延や通信障害が発生したようです。

　しかし、今回の攻撃によってインターネット全体が崩壊寸前まで追い込まれたとか、ある地域のインターネットが長期にわたって継続的にダウンしたといった事実は確認されていないようです。このことは、SANSが発表した報告書にも記述されており、いくつかの報道や報告ではその点がやや誇張され過ぎていたのではないでしょうか。

――そもそものきっかけは何だったのでしょう。

　今回Spamhausが攻撃目標となった背景には、オランダでデータセンター事業を営むCyberBunker社と同社に接続性を提供しているA2B InternetのすべてのIPアドレスを、Spamhausが作成・公開しているDNSBL（DNSで管理可能なIPアドレスブラックリスト）に登録したことがきっかけとなっているようです。Spamhausが作成・公開しているDNSBLは世界中のさまざまな組織やISPから参照されており、このリストに登録されたことで、CyberBunker/A2B Internetからそれらの組織やISP宛に送信される電子メールはすべてブロック（受け取り拒否）されてしまうことになります。

　SpamhausとCyberBunker/A2B Internetの間では、2011年10月14日付の「A2Bがオランダ警察に虚偽の報告書を提出」という“Spamhausの発表”を受け、名指しされたA2B Internetが「Spamhausの主張は虚偽であり、10月14日のリリースは同社のプロパガンダである」という旨の“対抗声明”を3日後の10月17日に発表するなど、以前から小競り合いがあったようです。

　そのような状況において、今回、SpamhausがCyberBunker/A2B InternetのIPアドレスを自らのブラックリストに丸ごと登録したことから、同社がホスティングしているサービスの利用者やサービスの支援者などを含む一部のインターネットユーザーがSpamhausを攻撃対象としたDDoS攻撃を開始し、これが今回の大規模なDDoS攻撃の契機となりました。攻撃の発生日は報告書によって若干食い違っていますが、おおむね3月16日から19日の間に始められたようです。つまり、DDoS攻撃発生の背景はSpamhausとCyberBunker/A2B Internet間の争いに端を発しているということですね。

――SpamhausとCyberBunker/A2B Internet間の争いが、なぜここまで大きくなったのでしょうか。

　今回のDDoS攻撃は長期にわたって継続・拡大されサービス運営に影響を及ぼしたことから、Spamhausは分散CDNサービスを提供しているCloudFlareに支援を要請しました。CloudFlareは要請に応じる形で自らが運営するサービスインフラをSpamhausに提供し、その結果、CloudFlareも今回のDDoS攻撃の対象となりました。同社のCDNサービスが大規模なDDoS攻撃に耐えたことから、攻撃者はSpamhausやCloudFlare自身に加え、同社が接続しているIXも攻撃対象に加えたと言われています。このように、攻撃は日を追うに連れて規模や攻撃対象が拡大されていき、ピーク時には300Gbps以上という非常に大きなトラフィックを観測しました。DDoS攻撃は1週間以上にわたって続けられたと報告されています。

攻撃手法は「DNSリフレクター攻撃」、たとえて言うなら……

――今回の事件に使われた攻撃手法について教えてください。

　今回の事件では、「DNSリフレクター攻撃」と呼ばれる攻撃手法が使われたことが判明しています。

　リフレクターというのは、反射板のことです。自転車や自動車などの後ろに光を反射する板が付けられていますね。あれがリフレクターです。通常のリフレクターは光を反射しますが、コンピューターネットワークではデータを反射します。インターネットにはウェブやDNSなどいろいろなサービスがありますが、これらのサービスのサーバーは、（要求に対して応答を返すという）すべてリフレクターとして動作しています。

　そして、今回の事件ではDNSサーバーが持つリフレクターとしての特性が悪用されました。この攻撃手法は「DNSリフレクション攻撃」「DNS Amp攻撃」などとも呼ばれており、攻撃対象が使っているIPアドレスに送信元IPアドレスを詐称した問い合わせを多くのDNSサーバーに高い頻度で送信し、これらのDNSサーバーからの応答を攻撃対象に反射（リフレクション）させることでDDoS攻撃を成立させるものです。

　もう少し分かりやすい例で説明しましょう。仮に私がAさんに恨みを持っているとします。そして、私は攻撃にあたり、Aさんの自宅近くにある飲食店やレストランなどの電話番号を調べておきます。そして、私がAさんを名乗り、声色を真似てそれらのお店に次々と出前の注文をします。そして、それらのお店からAさんの家に次々と注文した料理が送りつけられるというのが今回の攻撃で使われた攻撃手法です。

　この攻撃では、鰻重や上寿司など、単価の高い料理を使えば使うほど一軒あたりのいやがらせの効率が増しますよね。これと同様に問い合わせに対する応答のサイズ比、つまり増幅率が大きくなるDNS問い合わせと応答の組み合わせを使うことで、攻撃の効率を容易に上げることができます。今回の事件では、DNSリフレクター攻撃が持つこの特性が悪用され、攻撃の規模が大変大きくなりました。

攻撃手法のイメージ図：なりすましによる迷惑行為の例

攻撃手法のイメージ図：DNSの場合

容易に悪用されうる「オープンリゾルバー」、世界に2000万台以上存在

――この攻撃は容易に行えるものなのでしょうか。

　現時点では、容易に行える状況にあります。今回の攻撃では「オープンリゾルバー」と呼ばれる効率の良い増幅器として利用可能なDNSサーバーが大量に使われたことが判明しています。

　オープンリゾルバーは、不適切な設定やデフォルト設定の不備などにより本来必要なアクセスコントロールが実施されていないため、インターネット上のどこからの名前解決要求であっても実行してしまう状態にあるDNSサーバーのことです。世界中のオープンリゾルバーの状況を調査しているopenresolverproject.orgが、このようなDNSサーバーが全世界に2000万台以上存在しているという調査結果を発表しています。また、4月19日に開催されたJANOG31.5の「DNS Open Resolverについて考える」セッションの発表によると、このようなサーバーは日本国内にも数多く存在しているとのことです。

　これらのサーバーは「攻撃者がその気になりさえすれば、効率の良い増幅器としていつでも使える状態」であり、極めて危険な状態であると言えます。

――なぜそれほど多くのオープンリゾルバーが存在しているのでしょうか。

　その質問には、歴史的事情から説明しなければいけません。かつて、インターネットは相互扶助と善意によって成り立っており、DNSサーバーを自分でセットアップできない人や利用できない人のために、自組織のキャッシュDNSサーバーを外部にも公開している場合がありました。また、自組織／ISPの利用者が外部のネットワークを使っている場合も組織／ISP内で普段使用しているものと同じキャッシュDNSサーバーを使い続けることができるように、意図的にオープンリゾルバーとしている場合もありました。

　このような背景などから、DNSサーバーの代表的な実装である「BIND」も、デフォルトではインターネット上のどこからの名前解決要求であっても受け付ける、つまり現在でいうオープンリゾルバーの状態が標準となっていました。BINDでは、2007年にリリースされたバージョン「9.4.0」でローカルホストと自身が接続されているローカルネットワークからの名前解決要求のみを受け付けるようにデフォルトが変更されるまでこの状態が続きました。つまり、9.4.0よりも前のバージョンのBINDをデフォルト設定のままで運用している場合、それらはすべてオープンリゾルバーになってしまうことになります。

　また、BINDではサーバープログラムであるnamedにキャッシュDNSサーバーと権威DNSサーバーの双方の機能が実装されており（※1）、かつキャッシュDNSサーバーの機能がデフォルトで有効となっていることから、権威DNSサーバーでは本来必要ではない名前解決機能が有効になってしまっている例が世界中の多くのDNSサーバーにおいて見受けられます。

　そして、最近注目され始めている事例として、各家庭でインターネットに接続するために使われているホームルーターの一部にオープンリゾルバーとなっているものが存在することが報告されています。多くのホームルーターは自身のネットワーク内のクライアントからの名前解決要求をISPのキャッシュDNSサーバーに転送するDNSプロキシー（DNSフォワーダー）機能を持っていますが、アクセスコントロールの不備によりWAN側からの名前解決要求であっても受け付けてしまう、つまりオープンリゾルバーの状態になってしまっているものが存在しています。

「DNSリフレクター攻撃」発生のリスクを減らすためには

――DNSがリフレクター攻撃に悪用されやすい理由を教えてください。

　DNSの仕様（DNSプロトコル）は、リフレクター攻撃を効率良く実行するために必要な3つの条件をすべて満たしています。つまり、DNSはそもそもリフレクター攻撃に使われやすいものであるといえます。

　まず、リフレクター攻撃を成立させるためには、送信元IPアドレスを攻撃対象のものに詐称した問い合わせをリフレクターに送り付け、応答を攻撃対象に誘導する必要があります。現在のインターネットではTCPとUDPという2種類のプロトコルが主な通信に使われていますが、DNSでは通信にかかる負荷を下げ、かつ通信にかかる時間を短くするため、主な通信プロトコルとしてUDPが採用されています。UDPでは相手との間の事前確認をすることなく実際のデータを送信する仕様になっているため、TCPに比べ送信元IPアドレスの詐称による攻撃を実行しやすくなっています。

　2つ目の条件は、リフレクターとして使えるサーバーがインターネット上に数多く存在していることです。DNSは、現在のインターネットの原型であるARPANETがTCP/IPに対応した直後から現在に至るまで使われ続けており、数多くのDNSサーバーがインターネット上に存在しています。

　また、それに加え、すでに説明したように本来はその必要がないサーバーやホームルーターなどがオープンリゾルバーになってしまっている場合が数多くあり、状況を悪化させています。さきほど紹介したopenresolverproject.orgが4月16日に公開した“調査結果”でも古いバージョンのBINDやホームルーターと考えられる多数のオープンリゾルバーが存在していることが報告されています。

　3つめの条件は、リフレクターによる増幅率が高いことです。DNSは問い合わせの内容が応答にそのままコピーされる仕様になっているため、応答のサイズが問い合わせのサイズよりも必ず大きくなります。

　そして、署名を付加することによりDNS応答を受信側で検証できるようにするための技術であるDNSSECや、より大きなアドレス空間を持つIPv6、電子メールの送信元を認証するためのプロトコルであるSPFやDKIMなどの普及により、DNS応答のサイズが増大する傾向にあります。これらの技術はDNSの信頼性を向上させ、また、これまでになかった新しい利用方法をDNSに追加するものですが、その一方で効率の良い攻撃に悪用可能な大きなデータ、つまりDNSリフレクター攻撃に使える元ネタを攻撃者が容易に発見できる状況を招いてしまう遠因ともなったという側面もあります。

――DNSリフレクター攻撃発生のリスクを減らすためにはどうすればいいのでしょうか。

　DNSリフレクター攻撃発生のリスクを減らすためには、これまでに説明した条件を成立させない、あるいはその効果を下げるための対策を実施することが有効になります。

　第1の条件が成立しない、つまりIPアドレスを詐称した問い合わせがリフレクターとなるDNSサーバーにそもそも到達しないようにすることが、DNSリフレクター攻撃に対する最も有効かつ根本的な対策となります。このための手段として有効になるのが、ソースアドレス検証（Source Addres Validation）と呼ばれる技術です（※2）。この対策は、ISPの外部接続用のルーターやデータセンターにおける各ホストを接続するスイッチなど、主にネットワーク機器において実施すべき対策となります。

　もう1つの対策は第2の条件、つまり効率の良いリフレクターとして容易に使える状態にあるオープンリゾルバーの数を減らすことにより、DNSリフレクター攻撃発生のリスクを減らすものです。これまでで説明したように、インターネット上は本来はその必要がないサーバーやホームルーターなどが知らない間にオープンリゾルバーになってしまっているケースが数多くあります。これらをオープンリゾルバーでなくすことにより、攻撃発生のリスクを減らすことができます。

オープンリゾルバーはインターネットにとって有害な“有害リゾルバー”

――オープンリゾルバーでなくすための具体的な方法について教えてください。

　DNSサーバーにおける基本的な対策は以下の3つです。これらの対策についてはJPRSで公開している「トピックス＆コラム　No.20『DNS の安全性・安定性向上のためのキホン～お使いのDNSサーバーは大丈夫ですか？～』」でまとめておりますので、そちらをご覧いただければと思います。

1）キャッシュDNSサーバーと権威DNSサーバーを分離する
2）キャッシュDNSサーバーにおいて適切なアクセスコントロールを実施する
3）権威DNSサーバーにおいて不必要な再帰検索要求受け付けを無効化する

　ただし、上記1）の分離については即時の実施が難しい場合も考えられます。そのような場合も含め、BINDにおける具体的な設定方法をJPRSで公開している「設定ガイド：オープンリゾルバー機能を停止するには【BIND編】」に掲載しておりますので、DNSサーバーとしてBINDをお使いの方は、そちらも併せてご覧・ご確認ください。

　一方、ホームルーターがオープンリゾルバーとなっている場合、ファームウェアの更新などの対策が必要になります。現在使用中のルーターがオープンリゾルバーとなっているかどうかを確認できるウェブページ「Open DNS Resolver Check」がありますので、そちらで状況を確認できます。

　ホームルーターについては、4月19日に行われたJANOG31.5の「DNS Open Resolverについて考える」セッションにおいて、JPCERT/CCの久保さんから「もしそのようなルーターを発見された場合、脆弱性ハンドリングの一環として機種情報をJPCERT/CCまでご連絡いただきたい」という旨の発言がありました。もし、使用中のホームルーターがオープンリゾルバーであると判明した場合、JPCERT/CCに機種名などの情報を連絡するようにするとよいでしょう。

――すべきことは明確なのですね。ではなぜこの問題はなかなか解決しないのでしょうか。

　先ほど説明したソースアドレス検証の導入やDNSサーバー／ホームルーターの設定を修正してオープンリゾルバーでなくすといった対策は、いずれも自分がDNSリフレクター攻撃の加害者や増幅器（踏み台）にならないための対策です。

　つまり、自分がDNSリフレクター攻撃の直接の被害者にならない、あるいはなった場合の被害を軽減させるための対策ではないため、設定の効果を具体的な形で示しにくいという特徴があります。つまり「この設定をすることで利用者がより安全になります」とか「お客様によりよいサービスを提供できるようになります」といった、直接的な導入効果を示しにくいのです。このため、例えばこのインタビュー記事をお読みになられたシステムやネットワークの管理担当者が上司に「うちもこういう設定変更を導入したい」と提案しても、具体的な効果をうまく説明できない場合があるかもしれません。

　特に、ネットワークにおける根本的な対策であるソースアドレス検証はその導入効果を示しづらいことに加え、効果がきわめて利他的（自分のネットワークや利用者から加害者を生み出さない）です。海外では、フィンランドにおいて監督官庁が自国のISPに対し、自らのネットワークへのソースアドレス検証の導入を規定（Regulation）の1つとして義務付けたという事例もあります（※3）。

――最後に、何か加えておきたいお話はありますでしょうか。

　「オープンリゾルバー」という言葉は同じオープンという言葉を使っていても「オープンソース」や「オープンな企業風土」などとは異なり、不適切な設定や設定の不備により引き起こされる良くない状況を示しています。今回の事件の際に、技術者ではない一般の方々からもこの件に関する質問や問い合わせをいただきましたが、それらの方々は全員「オープンリゾルバー」を悪い意味にとってくれませんでした。

　DNSリフレクター攻撃の増幅器・踏み台として容易に利用可能なオープンリゾルバーはインターネットの安定運用を脅かす極めて有害な存在です。そこで、今回公開した技術解説では“有害リゾルバー”という、問題があることがより明確になるような表現も入れました。

　DNSリフレクター攻撃は2006～2007年ごろから継続して問題視されているもので、決して新しい問題ではありません。そして、今回の問題は集中的なキャンペーンのような一過性の行動のみで解決するものではなく、各関係者における継続的な取り組みを加えた形での総合的な対策が必要になります。JPRSでは、今後もこの件についての情報発信や対策を継続していきます。関係各位におかれましては、ご理解とご協力をよろしくお願いいたします。

――本日はお忙しい中ありがとうございました。

　なお、既知ではあるが、JPRS以外からもJPNICとJPCERT/CCから今回の件について情報が提供されている。参考情報として参照するといいだろう。