「DNSリフレクター攻撃」を防ぐために管理者にお願いしたいこと

大規模DDoS攻撃から考える、DNSサーバー管理の重要性

2013年12月27日 15時00分更新

文● 渡瀬圭市

今年（2013年）の3月に、スパム対策組織のSpamhaus Project、および同組織を支援した米Cloudflare社の2つを攻撃目標とした大規模なDDoS攻撃が発生した。今回、東京秋葉原で開催された「Internet Week 2013」のプログラム「DNS DAY」においてその対策についての報告があったことから、ここに今回のDDoS攻撃手法とその対策についてあらためて解説する。

「ピークトラフィック300Gbps超」の大規模DDoS攻撃

　「DDoS」とはDistributed Denial of Serviceの略で、多くの場所（機器）から相手のサーバーやネットワークに過大な負荷をかけ、サービス不能の状態に追い込む攻撃手法だ。DDoS攻撃はこれまでにも幾度となく行われてきたが、その規模（トラフィック量）は大きくても数百Mbpsから数十Gbps程度にとどまっており、100Gbpsを超えるものはまれであった。

　それに対して、今回のDDoS攻撃は攻撃規模が最大で300Gbpsを超えるきわめて大きなものであり、一部の地域で通信に障害が発生するなどの影響が確認されている。しかも、攻撃規模が大きくなった原因がDNSにあったため、インターネット関係者の間で大きな問題として捉えられるようになった。

　攻撃は、「オープンリゾルバー」と呼ばれるキャッシュDNSサーバーに対して送信元を攻撃対象のIPアドレスに偽装したクエリーを送ることで引き起こされる。送信元を偽装したクエリーを受け取ったオープンリゾルバーは、それを正しいクエリーとしてDNSの名前解決を行い、その結果を偽装されたIPアドレスに対して返すことになる。

　攻撃に悪用可能なオープンリゾルバーは世界中に無数に存在しており、偽装したクエリーを送ることで結果的に大量のDNS応答が攻撃対象に向かうこととなる。DNSが持つ「クエリーより応答の方が大きくなる（増幅される）」という特徴と、攻撃に悪用できる大量のオープンリゾルバーの存在により、きわめて大規模なDDoS攻撃が成立してしまったのだ。この攻撃手法を「DNSアンプ攻撃」や「DNSリフレクター攻撃」と呼ぶ。

今回の攻撃の概念図（情報処理学会IOT研究会におけるJPRS森下氏の講演資料より引用）

オープンリゾルバー根絶に向けての取り組み

　さて、今回の攻撃で悪用され、攻撃の大規模化を助けてしまった「オープンリゾルバー」とはどんなものだろうか。

　DNSの仕組みからすれば、本来、個々のキャッシュDNSサーバーがサービスを提供すべき対象は明確なはずである。たとえば、ISPならばサービス契約している顧客だけに、企業ならば自社従業員だけにキャッシュDNSサーバーの機能を提供すればよい。だが、実際にはどこからのクエリーであっても受け付けてしまうキャッシュDNSサーバーがインターネット上に多数存在している。これを「オープンリゾルバー」と呼ぶ。

　大規模攻撃を助け、“有害さ”が無視できないものとなったオープンリゾルバーに対して、インターネット関係者はさまざまな対策を進めている。DNSサーバーが攻撃者の“送信元偽装”を見破る「送信元検証（イングレスフィルタリング）」^※技術を導入するのが理想的だが、これは世界中のネットワークで適用しなければ大きな効果は望めず、対応が進んでいないのが現状である。

^{※RFC 2827（BCP 38）で定義された仕組み。イングレス（ingress：進入）の文字通り、自ネットワークに入ってくる送信元を偽装したパケットに対するフィルタリングを行う。}

　そのため、それと並行して個々のDNSサーバーでの対策が行われている。「オープンリゾルバーをなくしていく」というのはそのひとつで、キャッシュDNSサーバーがサービスを提供すべき対象を定義し、それ以外のネットワークからのアクセスを制限すればよい。

　ただし、理屈の上では簡単だが、「公式に提供していないキャッシュDNSサーバーにいつの間にか外部の利用者がぶら下がっている」、「かつては顧客であったが他社のサービスに移った後もDNSに関する設定を変更していない」といった例もあり、実際にアクセス制限を加えるのは簡単ではないようだ。気づかずに外部からを利用している人や自社の顧客ではなくなった人などに連絡を取るのが困難であること、また仮に連絡が取れたとしても「ネットが使えなくなる（なった）」とクレームが入るケースもあることなどが問題だという。

　もちろん、そうしたことを踏まえても、問題の大きいオープンリゾルバーを放置するわけにはいかない。上述したような経緯でなかなかオープンリゾルバーをなくすことができなかった大手ISPでも、徐々に「オープンリゾルバーの根絶」に乗り出している。

世界（左）および日本国内のオープンリゾルバー数の推移（JPCERT/CCの「オープンリゾルバ確認サイト」より引用）

　JPCERT/CCでは「オープンリゾルバ確認サイト」を公開し、利用者のPCでオープンリゾルバーを利用する設定になっていないか、またインターネット接続元の機器（ブロードバンドルーターなど）がオープンリゾルバーになっていないかどうかを確認するよう呼びかけている。この機会にあらためてチェックし、設定を見直したほうがいいだろう。

▼ オープンリゾルバ確認サイト（JPCERT/CC）
▼ オープンリゾルバーを用いたDNSリフレクター攻撃の概要と対策　～知らない間にあなたも加害者に～（JPRS森下氏の講演資料：PDF）
▼ オープンリゾルバ（Open Resolver）に対する注意喚起（JPNIC）

権威DNSサーバー、そしてJP DNSでの対策

　ここまで見てきたのはキャッシュDNSサーバーにおける対策だ。しかし、DNSアンプ攻撃（DNSリフレクター攻撃）では、キャッシュDNSサーバーばかりでなく権威DNSサーバーも悪用の対象になりうる。そのため権威DNSサーバーにおいても対策が必要になるが、ここでの大きな問題は、権威DNSサーバーでは特定のアクセス元に制限することができない（インターネット上のどこからのクエリーでも受け付ける必要がある）という点だ。

　そのため、権威DNSサーバーに適用できる「DNS RRL（Response Rate Limiting）」という技術が開発された。その仕組みをざっくりと説明すると、「同一とみなせる高頻度のDNS応答について、回数や大きさを制限する」ものだ。DNSアンプ攻撃を完全に防げるわけではないが、踏み台としての効果を小さくし、攻撃の規模を低減することが可能になる。日本では、JPドメイン名を管理・運用する日本レジストリサービス（JPRS）などが導入を進めている。権威DNSサーバーにおける対策も着々と進んでいると言っていいだろう。

ネットワーク管理者にお願いしたいこと

　インターネットを安定して運用していくためには、DNSの安定運用が重要である。DNSが正しくそのサービスを提供できなければ、相手に正しく接続することも、相手に正しくメールを送ることもできなくなってしまう。

　一方、DNSは分散データベースであり、ISPやホスティング事業者といったサービス提供者のみならず、企業や大学なども含めた幅広いネットワーク管理者の協力も欠かすことができない。利用者側で動作するDNSクライアント、名前解決を担当するキャッシュDNSサーバー、それぞれのドメイン名の情報を管理する権威DNSサーバーのすべてが円滑に動作することで、DNSの安定運用が実現できるからである。

　DNSサーバーの管理運用にあたっては、「キャッシュDNSサーバーと権威DNSサーバーの分離」、「キャッシュDNSサーバーにおけるサービス提供範囲の制限」、「権威DNSサーバーにおけるキャッシュDNSサーバー機能の停止」という3点は、今や必須事項であると言える。そのうえで、SPFやDKIM、DNSSECなど攻撃に利用可能な大きなデータを管理する必要がある場合は、権威DNSサーバーへのDNS RRL導入も併せて検討していただきたい。JPRSが公開している「JPRS トピックス＆コラム」の記事で、こうした対策の重要性がわかりやすくまとめられている。

▼ DNSの安全性・安定性向上のためのキホン～お使いのDNSサーバーは大丈夫ですか？～（JPRS、PDF）

　インターネットは、私たちの日常に欠かせないものとなっている。その安定のために、ネットワーク管理者の方々の幅広いご協力をお願いしたい。

ツイートする

カテゴリートップへ