DNS に関しては、Cricket Liu が文字通り本を書きました。 彼は、O’Reilly の「DNS and BIND」本の全 5 版を共著しており、一般に、ドメイン名システムに関連するすべての事柄に関する決定的なガイドと見なされているものです。 Cricket は現在、Infoblox の最高インフラストラクチャ責任者です。
DNS は明らかにコンピュータ ネットワークの重要なコンポーネントですが、これらのツールが悪用されることもあります。 今週の New Tech Forum では、Cricket が、DNS ベースの DDoS 攻撃の増大する問題とその対処法について取り上げます。 — Paul Venezia
DNSベースのDDoS攻撃。 その仕組みと止め方
DNSベースのDDoS（分散型サービス拒否攻撃）は、インターネット上で最も一般的な破壊的攻撃の1つになっています。 しかし、それらはどのように動作するのでしょうか。
この記事では、DDoS 攻撃がどのように DNS インフラストラクチャを悪用し、ターゲットとするかについて説明します。
大きな偽装
DNSインフラを使用したDDoS攻撃の生成は、驚くほどシンプルです。 攻撃者はインターネット上のネーム サーバーにクエリを送信し、ネーム サーバーは応答を返します。 しかし、攻撃者は自分の IP アドレスからクエリを送信するのではなく、Web サーバー、ルーター、別のネーム サーバー、またはインターネット上のあらゆるノードをターゲットとして、そのアドレスになりすますのです。 任意の IP アドレスから DNS クエリを送信することは、他人の返信用住所をハガキに書くのと同じくらい簡単で、ほぼ同じ効果があります。
クエリを偽装しても、ターゲットを無力化するには十分ではありません。 これらのクエリへの応答がクエリ自体よりも大きくない場合、攻撃者は偽装されたクエリをターゲットに殺到させるのと同じくらいうまくいくでしょう。 そうではなく、ターゲットへのダメージを最大化するためには、それぞれのクエリが非常に大きなレスポンスを返す必要があるのです。 1999 年に導入された DNS の拡張機能セットである EDNS0 の登場以来、UDP ベースの DNS メッセージは多くのデータを運ぶことができるようになりました。 応答は4,096バイトになることもあります。 一方、ほとんどのクエリは 100 バイト未満です。
かつて、インターネットのネームスペースでこれほど大きなレスポンスを見つけることは比較的困難でした。 しかし、組織が DNSSEC (DNS Security Extensions) を導入し始めた今、それははるかに容易になっています。 DNSSECは、暗号キーとデジタル署名を名前空間のレコードに保存します。 これらは実に巨大です。
DNSSEC レコードを含む isc.org ゾーンからの応答の例は、私のブログで見ることができます。
さて、インターネット上の攻撃者が、あなたの Web サーバーの IP アドレスから isc.org ネーム サーバーに偽装したクエリを送信する様子を思い浮かべてみてください。 各 44 バイトのクエリに対して、Web サーバーは 4,077 バイトの応答を受信し、増幅率は約 93 倍になります。
これがどの程度悪化するか、簡単に計算してみましょう。 各攻撃者が、インターネットへの比較的控えめな 1Mbps の接続を持っているとします。 この攻撃者は、1秒間に約2840個の44バイトのクエリをそのリンクに送信することができます。 このクエリーストリームは、ウェブサーバーに届く約93Mbps相当のリプライをもたらすことになる。 反社会的な攻撃者は、攻撃実行を手伝ってくれる10人の友人をどこで見つけるのでしょうか。 実は、彼らは一人も必要としません。 彼らは何千台ものコンピュータからなるボットネットを使用します。
最終的な効果は壊滅的です。 四半期ごとのグローバル DDoS 攻撃レポートの中で、Prolexic（DDoS ミティゲーション企業）は、ある顧客に対する 167Gbps を超える DNS ベースの最近の攻撃について報告しています。 Prolexic はさらに、平均 DDoS 攻撃帯域幅が 1 四半期で 718% 増加して 48Gbps になったと報告しています。
But wait! isc.org のネーム サーバーは、同じ IP アドレスから同じデータを何度も照会されていることを認識するように変更できないのでしょうか。
それは確かに可能です。 しかし、攻撃者が自分のトラフィックを増幅するために使用できるのは、isc.org のネーム サーバーだけではありません。 もちろん、攻撃者が使用できる権威あるネーム サーバーは他にもありますが、さらに悪いのは、オープンな再帰ネーム サーバーです。
オープンな再帰ネーム サーバーは、どの IP アドレスからの再帰クエリも処理する、単なるネーム サーバーです。 私は、isc.org データに対するクエリを送信し、isc.org は私に返信しますし、あなたも同じことができます。 再帰ネームサーバーの機能は、ラップトップやスマートフォンのようなDNSクライアントに代わって、インターネットの名前空間のデータを検索することです。 再帰型ネームサーバーを設置するネットワーク管理者（IT部門など）は、通常、特定のコミュニティ（たとえば、あなたとあなたの同僚）が使用することを意図しています。 OpenDNSやGoogle Public DNSのようなサービスでない限り、モルドバ市民が使うことは想定していないでしょう。 そのため、公共心があり、セキュリティに関心があり、特に有能な管理者は、再帰ネーム サーバーにアクセス制御を設定し、使用を許可されたシステムに制限します。 かなり大きいです。 Open Resolver Project は、3,300 万のオープンな再帰ネーム サーバーのリストを収集しました。 ハッカーは、ウェブ サーバー、ネーム サーバー、またはボーダー ルーターが停止するまで、isc.org のデータを吐き出すために、これらの数だけ偽装したクエリーを発射することが可能です。
嵐を切り抜ける方法
まず最初に行うべきことは、DNS インフラストラクチャを構築し、攻撃を受けていることを確認することです。 非常に多くの組織が、クエリ負荷が何であるかを把握していないため、そもそも攻撃されているかどうかを知ることができません。
クエリ負荷を判断することは、BIND の組み込み統計サポートを使用するのと同じくらい簡単にできます。 BIND ネームサーバーは、たとえば rndc stats を実行したとき、あるいは設定可能な統計間隔で、その統計ファイルにデータをダンプします。 クエリ率、ソケットエラー、その他の攻撃の兆候を統計で調べることができる。 DNSを監視する目的の1つは、ベースラインを確立することであり、何が異常かを特定することができます。
次に、インターネットに面したインフラストラクチャを見てみましょう。 外部の権威あるネームサーバーに限定せず、スイッチやルーターのインフラ、ファイアウォール、およびインターネットへの接続を調査します。 単一障害点を特定する。
可能であれば、外部権威ネームサーバーを広範囲に地理的に分散することを検討します。 これは、単一障害点を回避するのに役立つのはもちろんですが、攻撃を受けていないときにも役に立ちます。 ゾーンの1つでドメイン名を解決する再帰ネームサーバーは、それに最も近い権威ネームサーバーに問い合わせようとするので、地理的な分散は顧客と通信相手に良いパフォーマンスを提供する傾向があります。 顧客が特定の地域に集中している場合、最も迅速な応答を提供するために、権威あるネームサーバーをその近くに配置するようにします。
おそらく、DoS 攻撃に対抗する最も基本的な方法は、インフラストラクチャを過剰にプロビジョニングすることです。 有能なネーム サーバーは、1 秒あたり数万、数十万のクエリを処理できます。 ネームサーバーの能力がどの程度かわからない場合は、こちらをご覧ください。 dnsperf などのクエリー ツールを使用して、ネーム サーバーのパフォーマンスをテストすることができます。できれば、本番サーバーそのものではなく、ラボで本番のネーム サーバーと同様のテスト プラットフォームを使用してください。 あなたのオンライン プレゼンスはどの程度の価値がありますか。 インターネットに面したインフラストラクチャの他のコンポーネントで、ネーム サーバーより先に故障するものはありますか。
お金に糸目をつけないのであれば、DNS インフラに対する最先端の DDoS 攻撃が 100Gbps を超えることを知っておくと役に立つかもしれません。 エニーキャストを使用することも DDoS 攻撃に対抗するのに役立ちます。エニーキャストは、複数のサーバーが 1 つの IP アドレスを共有できるようにする技術で、特に DNS でうまく機能します。 実際、インターネットのルート ネーム サーバーは、ルート ゾーン データを世界中に提供するために長年にわたって Anycast を使用してきましたが、ルートのリストが 1 つの UDP ベースの DNS メッセージに収まるようにしました。 ルーティングプロセスは、ネームサーバーがリッスンする新しい仮想IPアドレスへのルートを近隣のルーターにアドバタイズします。 ルーティングプロセスは、ローカルのネームサーバーが応答しなくなった場合、そのルートの広告を停止するようなスマートさも必要です。 ルーティングデーモンとネームサーバーの健康状態は、自分で作ったコードで接着することもできるし、それを代行してくれる製品を購入することもできる。 Infoblox の NIOS には、偶然にも Anycast のサポートが含まれています。
Anycast は DDoS 攻撃からどのように身を守るのでしょうか。 たとえば、2 つの Anycast グループに 6 つの外部ネーム サーバーがあるとします（つまり、3 つが 1 つの Anycast IP アドレスを共有し、3 つが別の IP アドレスを共有します）。 各グループには、米国、ヨーロッパ、およびアジアの各メンバーが1人ずついます。 あなたに対してDDoS攻撃を行うホストは、インターネット上のどの地点からでも、一度にどちらかのグループの1つのメンバーにしかトラフィックを送ることができず、したがって、攻撃することもできません。 攻撃者が北米、ヨーロッパ、およびアジアから同時に十分なトラフィックを発信してインフラストラクチャを圧迫しない限り、成功することはありません。
最後に、大きな資本支出なしに、広い地理的分散と Anycast を同時に利用できる方法があります。 クラウド ベースの DNS プロバイダーを使用することです。 Dyn や Neustar などの企業は、世界中のデータ センターで独自の Anycast ネーム サーバーを実行しています。 お客様は、ゾーンをホストし、お客様のデータに対するクエリに応答するために、これらの会社にお金を支払います。 また、プロバイダーに依頼して、自社のネームサーバーをゾーンのセカンダリとして構成し、自社で指定・管理するマスター・ネームサーバーからデータをロードすれば、ゾーンデータを直接管理し続けることができます。 ただし、マスターを非表示にして（つまり、NSレコードがそれを指していない状態にして）運用しないと、攻撃者がそれを単一障害点としてターゲットにする危険性があります。 ほとんどのプロバイダーは、ゾーン内のデータに対してネーム サーバーが受け取ったクエリの数に基づいて、少なくとも部分的に請求します。 DDoS 攻撃では、これらのクエリが劇的に増加する可能性があるため (完全に制御不能であり、まったく利益にならない)、トラフィックのコストをユーザーに転嫁せずに DDoS 攻撃に対処する規定があることを確認してください。 しかし、他の誰かに対する DDoS 攻撃に加担しないようにすることも、ほぼ同様に重要です。
DNS サーバーがトラフィックを増幅する方法についての説明を覚えていますか。 攻撃者は、オープンな再帰ネーム サーバーと権威あるネーム サーバーの両方を増幅器として使用でき、ネーム サーバーがクエリの 100 倍以上の応答をインターネット上の任意のターゲットに送信するよう偽装されたクエリを送信します。 さて、このような攻撃のターゲットになりたくないのはもちろんですが、共犯者にもなりたくはないですよね。 この攻撃は，ネームサーバーのリソースだけでなく，帯域幅も使用する． ターゲットがあなたのネームサーバーからそのネットワークへのトラフィックをブロックする措置を取る場合、攻撃が終了した後、ターゲットはあなたのゾーンでドメイン名を解決できない可能性があります。 そうしないことです。 再帰的なクエリに対してオープンなネーム サーバーを実行する正当な理由がある組織は非常に少ないです。 Google Public DNSとOpenDNSが思い浮かびますが、これを読んでいるということは、おそらく彼らではないでしょう。 残りの人は、アクセス制御を再帰的ネームサーバーに適用して、許可されたクエリアのみが使用できるようにする必要があります。 これはおそらく、DNSクエリーを内部ネットワーク上のIPアドレスに制限することを意味し、ネームサーバーの実装で簡単にできます（Microsoft DNSサーバーは、クエリーに対するIPアドレスベースのアクセス制御をサポートしていません）。
しかし、権威あるネーム サーバーを実行している場合はどうでしょうか。 明らかに、あなたはクエリを受け入れるIPアドレスを制限することはできません — あるいは、とにかく、あまりできません (RFC1918アドレスのような、明らかに偽のIPアドレスからのクエリを拒否することができます)。
長年にわたるインターネットの「ホワイトハット」である Paul Vixie と Vernon Schryver は、権威あるネーム サーバーを増幅に使用する DDoS 攻撃は、特定のクエリー パターンを示すことに気付きました。 特に、攻撃者は、ネーム サーバーに、同じ偽装 IP アドレス (またはアドレス ブロック) から同じクエリを何度も送信し、最大限の増幅を求めます。 お行儀のよい再帰型ネームサーバーがそんなことをするわけがない。 1990>
Vixie と Schryver は、Response Rate Limiting (RRL) と呼ばれる、権威あるネームサーバーが同じクエリアに何回同じ応答を送ったかを追跡できる賢い仕組みを考え出しました。 そのレートが設定可能な閾値を超えた場合、ネームサーバーは一定期間、クエリアへのレスポンス送信を停止する。 問合せ者が権威ネームサーバーに同じ質問をするのをやめれば、権威ネームサーバーはその応答の抑制をやめる。
RRL はバージョン 9.9.4 で BIND ネームサーバーに組み込まれ、NSD や Knot を含む他のいくつかのネームサーバー実装が現在それをサポートしています。 人々がネーム サーバーを新しいバージョンまたは RRL をサポートする新しい実装にアップグレードするにつれ、攻撃者が DNS インフラストラクチャを増幅器として使用することが徐々に難しくなるはずです。
この議論は、DNS インフラストラクチャが DDoS 攻撃でどのように標的とされ悪用されるか、また、DDoS 攻撃に対抗し、ネーム サーバーが知らないうちに攻撃に参加することがないようにするにはどうすればよいかを理解するのに役立つことを願っています。 このセレクションは、InfoWorldの読者にとって重要であり、最も関心が高いと思われるテクノロジーを、私たちの主観に基づいて選んでいます。 InfoWorldは、掲載のためのマーケティング資料を受け付けておらず、すべての投稿コンテンツを編集する権利を有します。 お問い合わせは、[email protected].
この記事「The ultimate guide to preventing DNS-based DDoS attacks」は、InfoWorld.comに掲載されたものです。 最新のビジネス テクノロジー ニュースについては、InfoWorld.com の Twitter.
をフォローしてください。