---------------------------------------------------------------------
■技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について
株式会社日本レジストリサービス（JPRS）
初版作成 2013/04/18（Thu）
---------------------------------------------------------------------
▼はじめに
2013年3月16日（協定世界時）[CISCO2013]から3月下旬にかけ、迷惑メール
対策の活動を進めている国際組織The Spamhaus Projectに対する攻撃に端を
発する、大規模かつ長期間にわたる分散サービス不能（DDoS）攻撃が発生し
ました。
今回の攻撃ではこれまでで最大規模となる300Gbps以上のトラフィックを観
測したと報告されており、その影響でロンドン、ドイツ、オランダ、香港な
どの大手インターネットエクスチェンジ（IX）においてトラフィック交換の
遅延が発生し[CISCO2013]、一部地域においてインターネットが一時的に利
用しにくくなるなどの障害が発生しました（ただし、インターネット全体へ
の攻撃の影響は限定的でした[SANS2013]）。
今回の攻撃には不適切な設定がされた「オープンリゾルバー」と呼ばれるサー
バーを悪用した「DNS Reflector Attacks（DNSリフレクター攻撃）」と呼ば
れる攻撃手法（*1）が使われたことが判明しています。この攻撃手法そのも
のは有効な対策方法も含め以前から知られているものですが、今回の事件を
きっかけとし、この攻撃手法に関する技術的内容とその対策についての関心
が高まっています。
（*1）JPRSでは公式文書における本攻撃手法の名称として「DNS Amp攻撃」
を使用してきましたが、今後はRFC 5358[BCP140]における記述に従い
「DNS Reflector Attacks（DNSリフレクター攻撃）」を使用します。
本文書ではDNSリフレクター攻撃に関し、以下の項目について記述します。
1. リフレクター攻撃とは何か
1.1 リフレクター攻撃＝反射攻撃≒アンプ攻撃
1.2 リフレクター攻撃成立の条件
2. DNSリフレクター攻撃の内容
2.1 DNSがリフレクター攻撃に悪用されやすい理由
2.2 攻撃の分類とシナリオ例
（1）オープンリゾルバーを用いたDNSリフレクター攻撃
（2）権威DNSサーバーを用いたDNSリフレクター攻撃
2.3 攻撃の特徴
3. 対策とその現状
3.1 対策の概要
3.2 ネットワークにおける対策：Source Address Validation（送信元検証）
3.3 オープンリゾルバーにおける対策：オープンリゾルバーをなくす
（1）キャッシュDNSサーバーと権威DNSサーバーの分離
（2）キャッシュDNSサーバーにおける適切なアクセスコントロールの実施
（3）不必要な再帰検索要求受け付けの無効化
§オープンリゾルバーは「有害リゾルバー」
3.4 権威DNSサーバーにおける対策：現在進行中、DNS RRLの導入が有力
4. DNS RRLの概要と実装状況
4.1 DNS RRLの目的
4.2 DNS RRLの概要
4.3 False Positive発生の抑制
4.4 DNS RRLが効果を発揮する状況
4.5 DNS RRLの実装状況
4.6 DNS RRLの現状と今後
5. まとめ
A. 参照（References）
なお、JPRSではオープンリゾルバーとして動作しているBINDの設定を簡単に
修正する方法をまとめた文書を公開しております。本文書と併せてご参照く
ださい。
設定ガイド：オープンリゾルバー機能を停止するには【BIND編】
<http://jprs.jp/tech/notice/2013-04-18-fixing-bind-openresolver.html>
---------------------------------------------------------------------
1. リフレクター攻撃とは何か
リフレクター（Reflector）は反射器あるいは反射板などと訳され、本来は
光や音などを反射（Reflection）させる装置や機器のことをいいます。
コンピューターネットワークでは、送信元からの問い合わせに対し反射的な
応答を返すように動作するものをリフレクターと呼びます。Web（HTTP）や
DNSなどをはじめとするインターネット上の多くのプロトコルでは、サービ
スを提供するWebサーバーやDNSサーバーがリフレクターとして動作します
[PAXSON2001]。
1.1 リフレクター攻撃＝反射攻撃≒アンプ攻撃
リフレクターが持つ特性をサービス不能（DoS）攻撃などに悪用した攻撃手
法を総称して「Reflector Attacks（リフレクター攻撃）」と呼びます
[BCP140]。
リフレクター攻撃ではリフレクターが持つ反射（Reflection）という特性を
悪用していることから「Reflection Attacks （反射攻撃）」とも呼ばれます。
また、リフレクターがデータの増幅器（アンプ）として動作している場合、
「Amplification Attacks（アンプ攻撃）」とも呼ばれます。
1.2 リフレクター攻撃成立の条件
インターネットにおいてリフレクター攻撃を効率よく成立させるためには、
攻撃にあたり以下の三つの条件を満たしている必要があります。
（1）送信元IPアドレスの詐称による攻撃が可能であること
リフレクター攻撃成立のためには、攻撃者が作成した送信元IPアドレスを
詐称した問い合わせがリフレクターに到達可能な状態になっている必要が
あります。
インターネットで使われている通信プロトコル（IP）ではIPパケット中の
送信元IPアドレスは送信者による自己申告が原則となっており、詐称する
ことが可能です。攻撃者はこの特性を利用し、送信元として攻撃対象の
IPアドレスが指定されたIPパケットをリフレクターに送信することでリフ
レクターからの応答を攻撃対象に誘導し、攻撃を成立させます。
（2）リフレクターとなり得るサーバーが数多く存在していること
前述したようにインターネットでは、サービスを提供するサーバーがリフ
レクターとなり得ます。そのため、対象となるサーバーがインターネット
上に数多く存在している、すなわちそのサービスが広く普及しているほど、
リフレクターを用いた攻撃がしやすくなります。
（3）リフレクターによる増幅率が高いこと
リフレクターによる増幅率、すなわち問い合わせに対する応答のサイズ比
が大きいほど、リフレクターを用いた攻撃の効率が向上します。
2. DNSリフレクター攻撃の内容
ここでは、DNSがリフレクター攻撃に悪用されやすい理由、攻撃手法の分類
と具体的なシナリオ例、それぞれの攻撃手法が持つ特徴について解説します。
2.1 DNSがリフレクター攻撃に悪用されやすい理由
DNSはその特性上、リフレクター攻撃を成立させうる三つの条件をすべて満
たしています。すなわち、DNSは本質的にリフレクター攻撃に悪用されやす
いプロトコル／サービスの一つであるといえます（*2）。
（*2）NTPやSNMPなど、このようなプロトコル／サービスはDNSに限らないこ
とに注意が必要です。
（1）送信元IPアドレスの詐称による攻撃が可能である
インターネットではIPの上位で動作する主な通信プロトコルとして、TCP
とUDPという二種類のプロトコルが使われています。
そのうち、Web（HTTP）などで使用されているTCPでは通信開始時にスリー
ウェイ・ハンドシェイクと呼ばれる手順により相手との疎通を相互に確認
し、その後に実際のデータ通信を開始します。攻撃者が送信元IPアドレス
を詐称していた場合スリーウェイ・ハンドシェイクによる接続が成功せず、
データ通信を行うことができません。
これに対し、DNSで使われているUDPでは通信時のサーバーの負荷や遅延時
間（レイテンシー）を軽減するため、通信開始時に相手との疎通確認をす
ることなくデータ通信を開始する仕組みになっています。そのためその特
性上、送信元IPアドレスを詐称した攻撃が成立しやすくなっています。
（2）リフレクターとなり得るサーバーが数多く存在する
DNSはインターネットの黎明（れいめい）期から現在に至るまで広く使用
されている、インターネットの基本サービスの一つです。そのため、リフ
レクターとなり得るDNSサーバーが、インターネット上に数多く存在して
います。
（3）リフレクターによる増幅率が高い
DNSでは問い合わせの内容が応答にそのままコピーされる仕様となってお
り、応答のサイズが問い合わせのサイズよりも必ず大きくなります。また、
DNSSECやIPv6、SPF/DKIMなどの普及により、応答のサイズが増大する傾向
にあります。
DNSが持つこれらの特性に由来する脅威は従来から指摘されており
[PAXSON2001]、2006年頃から報告され始めたDNSリフレクター攻撃により、
この問題が顕在化しました[JPRS2006][JPRSTC003]。
2.2 攻撃の分類とシナリオ例
DNSリフレクター攻撃は踏み台として悪用されるDNSサーバーの種類により、
以下の二種類に分類されます。これら二種類の攻撃はその手法に由来する特
徴や適用可能な対策が異なっていることから、分けて考える必要があります。
（1）オープンリゾルバーを用いたDNSリフレクター攻撃
オープンリゾルバーは不適切な設定内容やデフォルト設定の不備などの理
由により本来必要となるアクセスコントロールが実施されておらず、イン
ターネット上のどこからの名前解決要求であっても実行してしまう状態に
なってしまっているキャッシュDNSサーバーのことをいいます。オープン
リゾルバーを用いたDNSリフレクター攻撃の脅威は以前から知られており、
単にDNSリフレクター攻撃と言った場合、従来はこの攻撃手法を指してい
ました[BCP140]。
オープンリゾルバーを用いたDNSリフレクター攻撃による攻撃のシナリオ例
を以下に示します。
1）インターネット上に存在する多数のオープンリゾルバーに名前解決要
求を送信し、応答をキャッシュしておきます。この際、応答のサイズ
ができるだけ大きくなる問い合わせパターン（*3）を使用し、攻撃の
効率を高めることが一般的です。
（*3）問い合わせ型（QTYPE）としてANYやTXTを指定するなど。
2）応答をキャッシュ済のオープンリゾルバーに対し 1）と同じ内容の名
前解決要求を、送信元IPアドレスを攻撃対象のものに詐称したうえで、
高い頻度で送り続けます。
3）多数のオープンリゾルバーが攻撃対象に対しサイズの大きい応答を、
高い頻度で送り続けます。
（2）権威DNSサーバーを用いたDNSリフレクター攻撃
最近、従来からのオープンリゾルバーを用いたDNSリフレクター攻撃に加
え、権威DNSサーバーを用いたDNSリフレクター攻撃の事例が報告され始め
ています[BUSH2013][UVA2013]。
権威DNSサーバーを用いたDNSリフレクター攻撃による攻撃のシナリオ例を
以下に示します。権威DNSサーバーを用いたDNSリフレクター攻撃では、権
威DNSサーバーからの応答が攻撃に直接利用されます。
1）インターネット上に存在する多数の権威DNSサーバーに対し、攻撃対象
のIPアドレスを詐称した問い合わせを高い頻度で送り続けます。この
際、応答のサイズができるだけ大きくなる問い合わせパターンを使用
することで攻撃の効率を高められることは、前述したオープンリゾル
バーを用いたDNSリフレクター攻撃と同様です。
2）多数の権威DNSサーバーが攻撃対象に対しサイズの大きい応答を、高い
頻度で送り続けます。
2.3 攻撃の特徴
それぞれの攻撃手法に由来する特徴を以下に示します。
（1）オープンリゾルバーを用いたDNSリフレクター攻撃
オープンリゾルバーを用いたDNSリフレクター攻撃ではキャッシュさせる
内容として増幅率の高いものを選択することにより、攻撃の効率を容易に
高めることができます。攻撃者は攻撃にあたり増幅率の高いデータを一つ
準備すればよく、DNSの仕組みにより攻撃用のデータを数多くのオープン
リゾルバー上に、容易に複製できます。
そのため、オープンリゾルバーを用いたDNSリフレクター攻撃は、インター
ネットの安定運用に対する、大きな脅威の一つとなっています。本文書の
冒頭で紹介したDDoS攻撃においてもオープンリゾルバーが悪用されたこと
が判明しています[CISCO2013][SANS2013]。
（2）権威DNSサーバーを用いたDNSリフレクター攻撃
一方、権威DNSサーバーを用いたDNSリフレクター攻撃では、権威DNSサー
バーからの応答が攻撃に直接利用されます。そのため、前述のオープンリ
ゾルバーを用いた攻撃に比べ攻撃の効率は下がりますが、権威DNSサーバー
はその特性上インターネット全体にサービスを提供する必要があることか
ら、オープンリゾルバーの場合と異なり本文書において解説するアクセス
コントロールの導入による対策が難しいという特徴があります
[UVA2013][MEKKING2013]。
3. 対策とその現状
DNSリフレクター攻撃のようなDDoS攻撃への対策を考慮する場合、二つの重
要なポイントがあります。一つは「自分がDDoS攻撃の被害者となった場合に
どう防御すればよいのか」であり、もう一つは「自分がDDoS攻撃の加害者や
踏み台とならないようにするにはどう対策すればよいのか」です。
このうち本文書では後者、すなわち自身や自身が管理するネットワークが
DNSリフレクター攻撃の加害者や踏み台とならないようにするための対策と
その現状について解説します。
3.1 対策の概要
オープンリゾルバーを用いたDNSリフレクター攻撃は以前から知られており、
自らが加害者や踏み台にならないようにするために採用すべき手法も確立し
ています。本文書ではネットワークにおける対策、及びDNSサーバーにおけ
る対策の双方について解説します。
一方、権威DNSサーバーを用いたDNSリフレクター攻撃への対策については、
現在も技術者や専門家の間で提案や実装が進められている段階にあります。
本文書ではその対策として現在提案されているもののうち、現時点において
最も有力な対策の一つとされているDNS Response Rate Limiting（DNS RRL）
について解説します。
3.2 ネットワークにおける対策：Source Address Validation（送信元検証）
DNSリフレクター攻撃を成立させるためには、送信元IPアドレスを詐称した
データによる攻撃が可能である必要があります。
そのため、送信元IPアドレスを詐称したデータを送信できないようにネット
ワーク機器などで設定することにより、自身のネットワークがDNSリフレク
ター攻撃の攻撃元となることを根本的に防止できます。これをSource
Address Validation（送信元検証）といい、RFC 2827[BCP38]とそれを更新
するRFC 3704[BCP84]により、インターネットにおける運用ガイドラインと
してまとめられています。
送信元検証はオープンリゾルバー及び権威DNSサーバーのいずれを用いた
DNSリフレクター攻撃にとどまらず、他のプロトコルを利用したリフレクター
攻撃に対しても効果を発揮します。かつ、キャッシュポイズニングの加害者
となることなども併せて防止できることから、各ISPやiDCなどにおける実施
が強く推奨されています。
3.3 オープンリゾルバーにおける対策：オープンリゾルバーをなくす
オープンリゾルバーを用いたDNSリフレクター攻撃への対策の基本は「オー
プンリゾルバーをなくす」です。以下の（1）～（3）で解説する対策はRFC
5358[BCP140]により、インターネットにおける運用ガイドラインとしてまと
められています。
（1）キャッシュDNSサーバーと権威DNSサーバーの分離
キャッシュDNSサーバーと権威DNSサーバーではその機能やサービス対象・
サービスの提供範囲が異なっています。以降で説明する対策の実施を容易
にするため、キャッシュDNSサーバーと権威DNSサーバーを別のサーバーに
分離することが強く推奨されています（*4）。
（*4）セキュリティやサーバー運用上の観点からも、キャッシュDNSサー
バーと権威DNSサーバーの分離が強く推奨されています。詳細は
JPRSトピックス＆コラム No.20「DNSの安全性・安定性向上のため
のキホン」[JPRSTC020]をご参照ください。
（2）キャッシュDNSサーバーにおける適切なアクセスコントロールの実施
キャッシュDNSサーバーにおいてIPアドレスベースでの適切なアクセスコ
ントロールを実施し、オープンリゾルバーでなくすことが有効な対策とな
ります。これにより、自分が管理するキャッシュDNSサーバーが外部に対
するDNSリフレクター攻撃の踏み台となることを、根本的に防止できます。
（3）不必要な再帰検索要求受け付けの無効化
DNSリフレクター攻撃ではレジストリに登録されている権威DNSサーバーの
情報が、オープンリゾルバーを発見するための手段として使われる場合が
あります。レジストリに登録される権威DNSサーバーの情報は公開情報で
あり、もし該当する権威DNSサーバーがオープンリゾルバーとなっていた
場合、DNSリフレクター攻撃の踏み台として悪用されるリスクが飛躍的に
高まることになります。
このため、サーバーの設定によりそれらのサーバーの再帰検索要求の受け
付けの機能を無効に設定し、オープンリゾルバーでなくしておくことが強
く推奨されています。
§オープンリゾルバーは「有害リゾルバー」
このように、DNSリフレクター攻撃において効率の良い踏み台として容易
に悪用可能なオープンリゾルバーは、インターネットの安定運用を脅かす
極めて有害な存在となっています。また、オープンリゾルバーとなってい
る場合キャッシュポイズニングに対する危険性が飛躍的に上昇するなど、
セキュリティ上の観点からも不適切な状態であるといえます。
3.4 権威DNSサーバーにおける対策：現在進行中、DNS RRLの導入が有力
前述の通り権威DNSサーバーではその特性上、インターネット全体にサービ
スを提供する必要があります。そのため、キャッシュDNSサーバーと同様の
IPアドレスベースでのアクセスコントロールの実施は困難です。
これを受け、権威DNSサーバーをDNSリフレクター攻撃の踏み台として利用し
にくくするためのさまざまな対策が提案・実装され始めています。本文書で
紹介するDNS Response Rate Limiting（以下、DNS RRL）はそのための有力
な対策の一つであり、BIND 9やNSDなどの実装において導入が進められてい
ます。
以降では、DNS RRLの概要と現時点における実装状況について解説します。
4. DNS RRLの概要と実装状況
4.1 DNS RRLの目的
DNS RRLはPaul Vixie氏とVernon Schryver氏により提案されている、DNSサー
バーの応答頻度を制限するための技術です[RRL]。従来の対策は何らかの形
でDNSの問い合わせを制限するためのものがほとんどでしたが、DNS RRLでは
所定の条件によってDNSの応答を制限することにより、DNSリフレクター攻撃
の効果を低減させることを目的としています（*5）。
（*5）すなわち、DNS RRLはDNSリフレクター攻撃の発生そのものを防止する
ための技術ではありません。
4.2 DNS RRLの概要
DNSリフレクター攻撃では踏み台となるオープンリゾルバーや権威DNSサーバー
に高い頻度で問い合わせを送りつけることにより、攻撃を成立させます。
既に解説したようにオープンリゾルバーを利用したDNSリフレクター攻撃で
は、IPアドレスベースでのアクセスコントロールの実施（オープンリゾルバー
でなくすこと）が有効な手段となります。しかし、権威DNSサーバーを利用
したDNSリフレクター攻撃では、IPアドレスベースでのアクセスコントロー
ルを事前に実施しておくことは困難です（*6）。
（*6）攻撃発生後に限定的かつ一時的なアクセスコントロールを事後導入す
る手法は、有効となる場合があります。
特に、権威DNSサーバーに対する送信元としてBotnetなどが利用され、攻撃
元が広域分散された場合、それら全てを効果的に制限することは極めて困難
です。
DNS RRLではこうした攻撃の場合にも攻撃対象となるIPアドレスは単一、あ
るいは一定のネットワーク内であることが多い点に着目し、
・あるIPアドレスブロック宛の
・単位時間あたりの同一名（*7）に対する同一ステータスの応答が
所定の頻度を超えた場合に、応答の破棄などの制限を発動させるための仕組
みを提供します。
（*7）名前を変更しながらの連続攻撃に対応するため、サブドメインにおけ
る不在応答はすべて同一名と判定されます。
4.3 False Positive発生の抑制
DNS RRLのような検出型の攻撃対策では、いわゆるFalse Positive（*8）の
発生をどのように抑制するかが重要なポイントとなります。
（*8）本来は検出すべきでない事象を誤検出してしまうことをいいます。
DNS RRLではDNSに従来からあるTCPフォールバックの仕組みを利用すること
で、この問題に対応しています。具体的にはDNS RRLの制限発動時に該当す
る応答の一部については単純な応答の破棄に替え、DNS応答の切り詰め（TC）
が発生した旨の、DNSプロトコルに合致したDNS応答を返すようになっていま
す（*9）。
（*9）この応答のサイズは常に512バイト以下に抑制されることも、重要な
ポイントの一つです。
もし、この応答を正当な問い合わせを送信したキャッシュDNSサーバーが受
信した場合、そのキャッシュDNSサーバーはDNSプロトコルの仕様に従いTCP
により問い合わせを再送することが期待されます。その場合、そのキャッシュ
DNSサーバーは応答を正しく受け取ることができます。
このようにDNS RRLではDNSプロトコルの仕様を巧みに利用することで、
False Positiveの発生を抑制するための仕組みを備えています。
4.4 DNS RRLが効果を発揮する状況
DNS RRLは他の手段を導入しにくい権威DNSサーバーへの導入において、特に
効果を発揮します。
通常、権威DNSサーバーに問い合わせを送信するのはキャッシュDNSサーバー
です。キャッシュDNSサーバーはキャッシュ機能を有しており、TTLで指定さ
れた時間内に同一名／同一タイプの問い合わせを再送信することは原則とし
てありません（*10）。このため、DNSリフレクター攻撃における典型的な攻
撃パターンである「同一送信先への同一名に対する応答」を異常動作として
検出することが比較的容易です。
（*10）キャッシュDNSサーバーの再起動やキャッシュクリアなどにより、問
い合わせが再送信されることはあり得ます。その場合も、DNS RRLが
発動するレベルの再送信をする可能性は極めて低いと考えられます。
それに対し、キャッシュDNSサーバーに問い合わせを送信するクライアント
はキャッシュ機能を有していない場合が多く、DNS RRLの安易な導入はDNSの
安定運用に悪影響を及ぼす危険性があります（*11）。
（*11）提案者であるPaul Vixie氏自身が指摘しています[VIXIE2012]。
4.5 DNS RRLの実装状況
本文書作成時点におけるDNS RRLの実装状況は以下の通りです。現在では
NSDやKnot DNSなど、BIND 9以外の権威DNSサーバーにおいてもDNS RRLがサ
ポートされ始めています。
・BIND
BIND（Berkeley Internet Name Domain）は米国のInternet Systems
Consortium, Inc.（以下、ISC）が開発しているDNSソフトウェアです。
DNS RRLはBIND 9に対するパッチとして提供されています。開発元のISCで
はBIND 9の次のメジャーリリースとなるBIND 9.10及びBIND 10において、
DNS RRLを標準サポートする予定であると発表しています。
・NSD
NSD（Name Server Daemon）はオランダのNLnet Labsが開発している権威
DNSサーバーです。
NSDではNSD 3.2.15においてRRLが実装されました。ただし、デフォルトで
はDNS RRLは無効となっておりコンパイル時に --enable-ratelimit オプ
ションが必要になります。開発元のNLnet Labsでは次のメジャーバージョ
ンとなるNSD 4において、DNS RRLを標準サポートする予定であると発表し
ています。
・Knot DNS
Knot DNSはチェコのccTLDレジストリであるCZ.NICが開発している権威
DNSサーバーです。
Knot DNSでは1.2.0-rc3においてDNS RRLが実装されました。なお、本文書
の執筆時点における最新バージョンは1.2.0です。
4.6 DNS RRLの現状と今後
DNS RRLはDNSの仕組みの細部まで緻密に考慮された、巧妙かつ有力な仕組み
であるといえます。実際に複数のTLDの権威DNSサーバーを攻撃対象／踏み台
としたDDoS攻撃の事例において、DNS RRLの緊急導入が高い抑止効果を発揮
した旨の報告がされています[BUSH2013]。
ただし、DNS RRLは提案・実装されてからまだ日が浅く、運用ノウハウの蓄
積や実装の安定化、デフォルトの設定内容のリファインなど、今後必要とな
る事項が数多く存在しており、いまだ開発途上にあるといえます。
かつ、参考リンクに引用したW. Matthijs Mekking氏の資料でも指摘されて
いるように、DNS RRLは「Cat-and-mouse game（いたちごっこ）」の技術で
あるといえます[MEKKING2013]。仮にDNS RRLが十分に普及し効果を発揮した
場合攻撃者はそれを回避するため、より洗練された形に攻撃方法を改良して
くることが予想されます。
5. まとめ
本文書の理解促進のため、重要なポイントを箇条書きにしたものを示します。
・リフレクター攻撃の概要
- リフレクターとして動作しているサーバーの特性が悪用される
- その特性から反射（リフレクション）攻撃・アンプ攻撃などと呼ばれる
・DNSはリフレクター攻撃に悪用されやすい
- リフレクター攻撃が成立する三つの条件は以下の通り
（1）送信元IPアドレスの詐称による攻撃が可能である
（2）リフレクターとなり得るサーバーが数多く存在している
（3）リフレクターによる増幅率が高い
- DNSはその特性上、これらの条件をすべて満たしている
・DNSリフレクター攻撃の種類
- DNSリフレクター攻撃は、
（1）オープンリゾルバーを用いるもの
（2）権威DNSサーバーを用いるもの
の二種類に分類される
- これらの攻撃は特徴や対策が異なっており、分けて考える必要がある
・オープンリゾルバーを用いたDNSリフレクター攻撃
- 攻撃の効率を容易に高めることができる
- DNSの仕組みにより攻撃用のデータを容易に複製できる
- インターネットの安定運用に対する大きな脅威の一つとなっている
・権威DNSサーバーを用いたDNSリフレクター攻撃
- オープンリゾルバーを用いた攻撃に比べ、攻撃の効率は下がる
- 従来からあるアクセスコントロールによる対策が難しい
・DNSリフレクター攻撃に対する対策
- 対策の基本は「自分が加害者や踏み台にならないこと」
- 根本対策はネットワークにおけるBCP38/BCP84の導入
・オープンリゾルバーにおける対策
- 対策の基本は「オープンリゾルバーをなくすこと」
- 重要な三つの対策
（1）キャッシュDNSサーバーと権威DNSサーバーの分離
（2）適切なアクセスコントロールの実施
（3）不必要な再帰検索要求受け付けの無効化
- オープンリゾルバーは「有害リゾルバー」
・権威DNSサーバーにおける対策
- アクセスコントロールの実施は困難
- 現在、さまざまな対策が提案・実装中
- 現時点における有力な対策：DNS Response Rate Limiting（DNS RRL）
・DNS RRLの概要
- 問い合わせでなく応答頻度を制限
- 目的は「DNSリフレクター攻撃の効果低減」
- DNSリフレクター攻撃の発生そのものを防止する技術ではない
・DNS RRLの仕組み
- 以下の条件により、DNS応答を制限
（1）あるIPアドレスブロック宛の
（2）単位時間あたりの同一名に対する同一ステータスの応答が
所定の頻度を超えた場合
- DNSプロトコルの仕組みを利用し、False Positiveの発生を抑制
- 権威DNSサーバーへの導入において効果を発揮
- キャッシュDNSサーバーへの導入は悪影響を及ぼす危険性あり
・DNS RRLの実装状況
- BIND 9に対するパッチとして公開
- BIND 9.10、BIND 10において実装予定
- NSD、Knot DNSなど、サポートされる実装は増える傾向にある
・DNS RRLの現状と今後
- DNSの仕組みの細部まで緻密に考慮された巧妙な仕組み
- 複数のTLDの権威DNSサーバーの攻撃事例において高い効果を発揮
- ただし、いまだ開発途上にある
- 運用ノウハウの蓄積、実装安定化、設定のリファインなどが今後必要
- 「いたちごっこ」技術であり、将来の攻撃方法改良・洗練が予想される
A. 参照（References）
[CISCO2013]
Hanford, S., "Chronology of a DDoS: SpamHaus", Cisco Blogs,
March 2013.
<http://blogs.cisco.com/security/chronology-of-a-ddos-spamhaus/>
（Ciscoの担当者によるSpamhausを標的としたDDoS攻撃の時系列の記録）
[SANS2013]
Bambenek, J., "Where Were You During the Great DDoS Cybergeddon
of 2013?", ISC Diary, March 2013.
<https://isc.sans.edu/diary/15496>
（米国のセキュリティ専門機関SANS Internet Storm Centerのレポート）
[PAXSON2001]
Paxson, V., "An analysis of using reflectors for distributed
denial-of-service attacks", ACM SIGCOMM Computer Communication
Review, Volume 31 Issue 3, July 2001.
<http://www.icir.org/vern/papers/reflectors.CCR.01.pdf>
（リフレクターを用いたDDoS攻撃について分析した論文）
[JPRS2006]
DNS の再帰的な問合せを使った DDoS 攻撃の対策について
<http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html>
（オープンリゾルバーを用いたDNS Amp攻撃とその対策について解説）
[JPRSTC003]
JPRSトピックス＆コラム No.003
DDoSにあなたのDNSが使われる ～DNS Amp脅威と対策～
<http://jprs.jp/related-info/guide/003.pdf>
（オープンリゾルバーを用いたDNS Amp攻撃とその対策について解説）
[JPRSTC020]
JPRSトピックス＆コラム No.020
DNSの安全性・安定性向上のためのキホン
～お使いのDNSサーバーは大丈夫ですか？～
<http://jprs.jp/related-info/guide/020.pdf>
（DNSの安全性と安定性を高めるために必要な基本事項について解説）
[BUSH2013]
Bush, R., "DNS Rate Limiting a Hard Lesson", Asia Pacific
OperatorS Forum (APOPS), February 2013.
<http://www.apricot2013.net/__data/assets/pdf_file/0011/58880/130226.apops-dns-rate-limit_1361839670.pdf>
（Randy Bush氏の発表資料、権威DNSサーバーを標的としたDNSリフレクター
攻撃とDNS RRLの適用について解説）
[RRL]
Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS
RRL)", ISC-TN-2012-1-Draft2, June 2012.
<http://ss.vix.su/~vixie/isc-tn-2012-1.txt>
（DNS RRLの技術仕様）
[VIXIE2012]
Vixie, P., "DNS RRL In Action", DNS-OARC, Toronto, October 2012.
<https://ccnso.icann.org/node/34809>
（Paul Vixie氏の発表資料、DNS RRLの概要と実装状況について解説）
[UVA2013]
Rozekrans, T., J. de Koning, M. Mekking, "Defending against DNS
reflection amplification attacks", University of Amsterdam
System & Network Engineering RP1, February 2012.
<http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf>
（アムステルダム大学SNE/OS3によりまとめられた研究論文、
DNS RRLの詳細な解説、DNSリフレクター攻撃の種類別検証結果あり）
[MEKKING2013]
Mekking, W. M., "DNS Rate Limiting", German UNIX User Group
(GUUG), February 2013.
<http://www.guug.de/veranstaltungen/ffg2013/talks/DNS_Rate_Limiting__Matthijs_Mekking.pdf>
（NLnet LabsのW. Matthijs Mekking氏の発表資料、
DNS RRLの詳細な解説、考察あり）
[BCP38]
Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
<http://www.ietf.org/rfc/rfc2827.txt>
（送信元IPアドレスの偽装によるDoS攻撃の防止）
[BCP84]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
<http://www.ietf.org/rfc/rfc3704.txt>
（マルチホームネットワークへのイングレスフィルターの適用）
[BCP140]
Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers
in Reflector Attacks", BCP 140, RFC 5358, October 2008.
<http://www.ietf.org/rfc/rfc5358.txt>
（キャッシュDNSサーバーにおけるリフレクター攻撃の防止）
---------------------------------------------------------------------
▼連絡先
本文書に関するお問い合わせは <dnstech-info@jprs.jp> までご連絡ください。
▼更新履歴
2013-04-18 11:00 初版作成
株式会社日本レジストリサービス Copyright©2001-2024 Japan Registry Services Co., Ltd.