分散フィルタリングによるDNS リフレクター攻撃対策拡張手法の提案
M2015SC005 平松 剛
指導教員：河野1

浩之

はじめに

Akamai 社の 2015 年度第 4 四半期のインターネットセ
キュリティレポート [1] によるとネットワークを利用する攻撃の中で，DNS リフレクター攻撃は 92%も前期より増加しており，現在の攻撃手法のトレンドであるといえる．
DNS リフレクター攻撃とは，世界中に存在する設定不備の状態で運用されている，オープンリゾルバとよばれるDNS サーバを悪用することで攻撃者にとってより効率的
図 1 DAAD とフィルタリングによる被害低減手法
な DDoS 攻撃をすることができる手法である．
この攻撃への対策を講じている先行研究 [3] には，ネッ
1. 名前解決のパケットを監視して要求/応答とポート番
トワーク機器への負荷による処理速度の低下や輻輳といっ号を DAAD に登録する．
た問題がある．そこで，我々が提案する手法ではその問
2. 名前解決では要求と応答は常に 1:1 であるので、デー題を解決するために分散フィルタリングを実行する．一タベースを照合することで応答だけの異常なパケッ
般的に高い性能のルータが配置される BGP ルータでパトが一定値以上出現した場合，攻撃されていると判
ケットフィルタリングを実行することで処理速度の低下断する．
を防ぎ，ネットワーク内部のある一点で処理していた既存手法とは異なり，分散的にフィルタリング処理をする
3. 応答だけを送信してきている IP アドレスをフィルタことができる．この検証にはネットワークシミュレータ
リングするようにルータやファイアウォールに設定
ns-3 の拡張版である ns-3 DCE 上に BGP で経路交換をする．
するネットワークを実装し，フィルタリングの性能を評
4. ルータやファイアウォールでフィルタリングを実行価する.
することで被害を緩和する．
本研究論文は全 5 章で構成される．2 章では DNS リフ
Di らによって提案された手法 [2] は，Bloom Filter を用
レクター攻撃への対策として，提案されている手法についいることで DAAD を拡張し，データベースから効率的にて解説する．3 章では我々が提案する BGP ルータでフィ検索することができる．これによって機器にかかる負荷ルタリングを実行する手法を説明する．4 章では提案すが軽減された．
る手法に基づいてシミュレーションをし，5 章でその実験
2.2 Remote Triggered Brack Hole Filteringについて評価，考察をする．

2

先行研究

この章では，DNS リフレクター攻撃への既存対策手法及び先行研究について記す．DNS リフレクター攻撃への対策として一番効果的な手法は，外からの名前解決の問い合わせにも応答するという適切なアクセスコントロー
ルが設定されていないキャッシュサーバを全て無くすことであるが，それは現実的ではない．そこで攻撃への対策として様々な手法が考案されている．

Remote Triggered Brack Hole Filtering(RTBH)[4] とは，BGP を用いたフィルタリング手法である. BGP の設定であらかじめ null Routing となるプレフィックスを設定しておき，攻撃が起こった際に攻撃を受けているプレフィクスの Nexthop を設定しておいたプレフィックスに向けて広報する．これによって攻撃パケットの向かう先は null となり，攻撃パケットが破棄される．
2.3

先行研究の課題

DAAD を使った手法では，Di らによる拡張でデータベースにかかる負荷が解消されたが，通信帯域にかかるDAAD(DNS Amplification Attacks Detector)[3] とは， 負荷については解消されていない．また，RTBH では正Kambourakis らによって考案された DNS の名前解決の 常なパケットもブラックホールに巻き込んで破棄してし仕組みに基づいて，DNS リフレクター攻撃を検出するシ まうという問題点がある．
ステムであり，パケットフィルタリングと併用することで攻撃からの被害を低減することができる．DAAD とネッ 3 DAAD 拡張手法の提案
トワークフィルタリングを用いた被害の低減手法を図 1
本章では，RTBH のように BGP を使うことで分散フィに示し，図中の番号で示す緩和処理の流れを以下で説明 ルタリングを可能にした提案手法について記す．3.1 ではする．
想定する環境について示し，3.2 では分散フィルタリング
2.1DNS Amplification Attacks Detector

の処理の概要について述べる．

3.1

想定する環境

被害端末は，インタんーネットにおける中規模 AS のネットワークの中に存在する端末の一つであり，所属する AS と隣接する AS との間で BGP による経路交換がされている．

ある場合に，送信先 IP アドレスとパケットサイズでフィルタリングする．

DNS リフレクター攻撃では，送信元ポート番号が UDP53と固定であること，送信先ポート番号に指定されるのがUDP0，53 がほとんどであり，パケットサイズが 4000byte程度と攻撃の統計がでているのでルールが適用しやすい．
3.5

3.2

分散フィルタリングの処理概要

本提案手法では，DAAD による DNS リフレクター攻
撃の検知，検知後の解析によるフィルタリングパターンの判断，フィルタリングルールを BGP で流すことによるBGP Flowspec を用いた分散フィルタリングという順序で実行することで，DNS リフレクター攻撃による被害を緩和する．図 2 に簡単な処理の流れを示す．

BGP Flowspec による分散フィルタリング

各ルータでは，判定されたフィルタリングルールが適用され次第攻撃パケットの送信元に対する帯域制限や，攻撃パケットの破棄など境界ルータでフィルタリングを実行していく．DAAD によって攻撃の発信元である DNSサーバを特定することで BGP にのせてフィルタリングルールを攻撃発信元にできるだけ近い，被害者から遠く離れたルータへ届ける．これにより，他のネットワークへの被害も最小限に抑えることができる．
しかし，現在広域ネットワークでの実装はすすんでおらず，その原因としては上位 ISP にあたるトランジット
ISP が下位 ISP から流れてくるフィルタリングルールを信用できないという理由が主である.

BGP Flowspec の問題点解決

図 2 フィルタリング処理の流れ

3.3

DNS リフレクター攻撃の発生

パケット監視システムと DAAD によって DNS リフレクター攻撃が検知されるまでは，それぞれのネットワーク内で動作する機器は通常通りの機能を果たしている．攻撃を受けていると検知した場合に次の処理へ．

3.4

攻撃パターンの判別

DNS リフレクター攻撃では，同じ内容の問い合わせが繰り返し送信されてくることから被害者のネットワークに所属するユーザからの正常な DNS 問い合わせにできるだけ影響が出ないようなフィルタリングルールを設定することが可能である．DAAD のデータから，パケットサイズや送信先/送信元の IP アドレス，送信先ポート番号を調べる事で，あらかじめ決めておいた異常なパケットのルールのどれに近いか判定し，次の処理へと進む．ここでのルールとは，正常な通信をできる限り阻害しないようなフィルタリングルールを設定するためのものである．悪意のないユーザにできるだけ影響が出ないように設定した場合のルール例は以下の通りである．
1. 監視の結果，攻撃元が１つの場合に送信先/元 IP アドレスとポート番号，パケットサイズでフィルタリングする．
2. 監視の結果，攻撃元は複数だが，送信先ポート番号が一定である場合に，送信先 IP アドレスとポート番号，パケットサイズでフィルタリングする．
3. 監視の結果，攻撃元も，送信先ポート番号も複数でその問題を解決するために，我々の提案手法では，先行文献の RTBH で使用されているルートリフレクタとよばれるルータを用いて，同じ規模の ISP 同士で VPN を張ることでフィルタリングルールを伝えることを提案する. 信頼できる同規模 ISP へルールを送り，その ISP が信頼する別 ISP へと伝えていくことでルールを広げていく. これならばメリット/デメリットがお互いに同じ規模であるので成立しやすいのではないかと考える.

4

分散フィルタリングの検証

本章では，実験に使用したツールと提案手法の有効性を示すために行うシミュレーション及び既存手法との比
較方法について記す．

4.1

シミュレーション環境

本研究では，実験環境としてネットワークシミュレータである ns-3[6] 上に，提案手法に必要な攻撃者の踏み台となっている DNS サーバと BGP によって経路が交換されている AS，被害者のネットワークを実装する．通常 ns-3 では BGP を再現することができないが，ns-3 のフレームワークであり Linux カーネルに実装されたネットワークスタックを利用することができる Direct CodeExecution(DCE)[7] を用いることで AS 間での通信を再現する．できる限り現実での環境に近づけるために BGPによるルーティングを実行した状態で攻撃シナリオをシミュレーションする．

4.2

シナリオファイル概要

ns-3 では DNS を再現することができないので，実験
ではシミュレーションシナリオとして，DNS サーバ役のノードから DNS 応答パケットとして UDP パケットを大量に送信することで DNS リフレクター攻撃を擬似的に再現する．実験に使用するシナリオファイルは，ns-3 DCEに付属している田崎創氏によって開発された BGP 用のサンプルファイルを参考に記述した．ns-3DCE ではルーティングソフトウェアである quagga を用いて BGP を動作させている．構築した実験環境を図 3 に示す．図 3 中の番号はすべてシナリオで記述したノードの番号と一致している.

法である．パケットロス率は ns-3 で計測する機能が DCEモジュールを導入することによって使用できなくなるた
めに，逆に ns-3 DCE を導入することで使用可能となった iperf を実行することでその値を計測する.
シミュレーション結果

4.4

提案手法の有効性を検証するために行なったシミュレー
ションの結果であるスループット，パケットロス率の測定結果を示し既存手法と比較した結果を評価する．
シミュレーション実行環境
シミュレーションシナリオを実行した環境は以下の表2 の通りである．ns-3 DCE では Linux カーネルを使用しており，今回のシミュレーションで使用するフィルタリング機能などの設定はデフォルトでは組み込まれていないので，menuconfig で細かい設定を行い，カーネルを再構築して使用した．

図 3 実験環境のノード配置図
表 2 シミュレーション実行環境

表 1 各種パラメータシミュレーション時間
ネットワークノード合計数
攻撃実行端末数BGP 経路を構成するリンク帯域幅
その他経路を構成するリンク帯域幅
攻撃端末の攻撃レート
攻撃パケットの宛先ポート
エラー発生率シミュレーション試行回数

4.360[sec]21 ノード11100Mbps
10Mbps
10MbpsUDP 530.00001%
20 回

提案手法の評価基準

実験では，BGP Flowspec を実際に実行することは困難であるので，境界ルータとして想定してあるネットワー
クノードで，あらかじめ設定しておいたフィルタリングルールに基づいてフィルタリングを実行する．攻撃がはじまり，分散フィルタリングが開始された後にフィルタリングルータから被害端末へのパケットロス率，スループットについても調査し，既存の手法である単体でのフィルタリング時と比較する．スループットは 2 種類の方法で測定をする.1 つめの手法は，ns-3 のパケットトレース機能を用いて測定する手法である. 受信ソケットへ流入してきたパケットを 1 秒毎に区切ってファイルに出力していくことで計測区間のスループットを算出する. 検証ではTCP,UDP 共に計測することで攻撃パケットと正常なパケットのスループットを表示する.2 つめの手法は iperf を利用する方法であり，後述するパケットロスと同様の手OSCPU
メモリ (RAM)ns-3 バージョン
DCE バージョン
カーネル

Ubuntu 14.04 LTS 64bit
Intel Core i7 920 @ 2.67GHz × 8
6GB
ns-3.26
DCE-1.9
Linux 2.6.36

TCP スループットの比較

4.5

図 4 に示されているのは，ns-3 の機能を用いて出力されたグラフである．Dist が提案手法である分散フィルタリングによるスループットであり，Single が既存手法である単体でのフィルタリングとなっている．分散フィル
タリングの TCP スループットの平均値は，一部分ランダムエラー要素によって単体フィルタリングに負けている部分もあるが，UDP スループットが減少し始めている部
分で総合的に見て単体フィルタリングよりも高い値であることがわかる．
Total Throughputs at Sink Node90

Dist TCP averageDist UDP average
Single TCP average
Single UDP average

8070
Throughputs(Mbps)

攻撃端末はインターネット上のあらゆる場所に点在しているため，被害端末であるノード [0] 以外の端末である
ノード [2,3,5,6,8,9,11,12,14,15,17] から攻撃パケットを送信する. シミュレーションを実行する上での各種パラメー
タの値を以下の表 1 に示す．

6050403020100-100102030Times(sec)40

図 4 スループット比較図

5060

単体フィルタリングではシミュレーション開始から 45秒，分散フィルタリングでは遠距離から 20 秒，30 秒，45秒の時にフィルタリングを開始しており，その結果が UDPのスループットが正しく減少していることがわかる．

4.6

ループットが向上した．従って，提案手法では既存手法の問題であったスループットの向上と通信路の負荷によるパケットロスについて改善することができたといえる．

5おわりに

iperf による計測区間

本研究では，DNS リフレクター攻撃の対策として正確性の高い DAAD という攻撃の検知手法を利用すること単体でのフィルタリングを実行する端末はノード [1] で で正確なフィルタリングルールを導き出した．そのルーあり，攻撃パケットがこのルータのみで処理されるため ルをもとに BGP Flowspec[5] を用いることで被害端末のに，ノード [1] とノード [18] の間が特に通信の負荷がかか ネットワークから遠く離れた攻撃元に近い BGP ルータへフィルタリングルールを届けることで，分散フィルタるボトルネックリンクとなることが予想される．
リングをする手法について提案をした．
分散フィルタリング
インターネット上に無数に点在する DNS サーバからの分散フィルタリングを実行する端末はノード [1，4，7， パケットが集中する前の段階である BGP ルータ上でフィ10，13，16] の 6 箇所であり，トランジット ISP を模して ルタリングを行うことで，分散フィルタリングを実施し，いるノード [18，19，20] でのパケット流量が減少するは 単体でのフィルタリングでの問題であるフィルタリングずである．そこで，そのポイントを押さえる観測位置と 機器付近でのネットワークへの影響，また機器への負荷して表 3 に示したノードで iperf のサーバ/クライアント の面で緩和をすることができた．具体的には，iperf で計を動作させる．
測したパケットロス率では，送信パケットに占める割合で既存手法に比べて 5.5%の減少を確認できた．また，スループットでは約 6%の改善を確認することができた．
表 3 スループット, パケットロス率測定ノード一覧
今後の課題としては，分散フィルタリングのルールの伝種別
トランジット
ボトルネック 達手段として，トランジット ISP などの自分より上位のISP にそのルールいかに信用してもらうのか．上位 ISP
Servernodes[0]nodes[1]へ BGP によるルールの伝達が可能になれば一度にかなりClient nodes[1，4，7，10，13，16]
nodes[18]の ISP へルールを伝達することが可能になる．また，そうなった場合には伝達の速度もかなり高速化することができると考えられるため，早急に安心してルールを配布
パケットロス率の計測結果できる仕組み作りをしていかなければならない．

単体フィルタリング計測結果
単体フィルタリング

参考文献
Bandwidth9.23 Mbits/sec

Lost/Total
1058/ 8921

Datagrams(12\%)[1] Akamai Technologies: Q4 2015 State of the Internet- Security Report (2015).


[2] Di Paola, S. and Lombardo, D.: Protecting againstiperf の結果，単体フィルタリングの場合 12%のパケット
DNS Reflection Attacks with Bloom Filters, pp. 1–
ロスということがわかる．また，帯域幅は 9.23Mbits/sec
16, Springer Berlin Heidelberg (2011).
で利用することができている．
[3] Kambourakis, G., Moschos, T., Geneiatakis, D. and
分散フィルタリング計測結果
Gritzalis, S.: Detecting DNS amplification attacks,
International Workshop on Critical Information InBandwidth
Lost/Total
Datagrams
frastructures Security, Springer, pp. 185–196 (2007).
9.80 Mbits/sec
581/ 8921(6.5\%)[4] Kumari, W. and McPherson, D.: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF), RFC 5635 (Informational) (2009).
iperf の結果，単体フィルタリングの場合 6.5%のパケットロスということがわかる．また，帯域幅は 9.8Mbits/sec [5] Marques, P., Sheth, N., Raszuk, R., Greene, B.,
で利用することができている．
Mauch, J. and McPherson, D.: Dissemination of
比較結果
パケットロス計測結果では提案手法である分散フィルタリングが 6.5%，既存手法である単体フィルタリングで12%と，送信パケットに占める割合で 5.5%の減少となった．スループットでは，分散フィルタリングでは帯域幅が 9.80Mbits/sec を計測したのに対して単体フィルタリングの場合では 9.23Mbits/sec を計測したので，約 6%ス

Flow Specification Rules, RFC 5575 (Proposed Standard) (2009). Updated by RFC 7674.
[6] NationalScience
Foundation:ns-3,
http://www.nsnam.org/ (Accessed Jan. 2017).
[7] 田崎 創 : ns-3 Direct Code Execution(ns-3-dce),
https://www.nsnam.org/overview/projects/directcode-execution/ (Accessed Jan. 2017).