DNSベースのDDoS攻撃を防ぐための究極のガイド

DNSに関しては、CricketLiuが文字通り本を書きました。彼は、O'Reillyの「DNSand BIND」本の全5版を共同執筆しました。これは、ドメインネームシステムに関連するすべてのものに関する最も信頼のおけるガイドと一般に見なされています。クリケットは現在、Infobloxの最高インフラ責任者です。

DNSは明らかにコンピュータネットワークの重要なコンポーネントですが、これらのツールが不正行為に使用される場合があります。今週の新しい技術フォーラムでは、クリケットはDNSベースのDDoS攻撃の増大する問題とそれらに対処する方法を見ていきます。-ポールベネチア

DNSベースのDDoS攻撃:それらの仕組みと阻止方法

DNSベースのDDoS(分散型サービス拒否攻撃)は、インターネット上で最も一般的な破壊的攻撃の1つになっています。しかし、それらはどのように機能しますか?そして、私たちはそれらに対して防御するために何ができるでしょうか?

この記事では、DDoS攻撃がDNSインフラストラクチャを悪用する方法と標的にする方法の両方について説明します。また、自分自身や他の人を守るために何ができるかについても説明します。

大きななりすまし

DNSインフラストラクチャを使用したDDoS攻撃の生成は非常に簡単です。攻撃者はインターネットを介してネームサーバーにクエリを送信し、それらのネームサーバーは応答を返します。ただし、攻撃者は自分のIPアドレスからクエリを送信する代わりに、ターゲットのアドレス(Webサーバー、ルーター、別のネームサーバー、またはインターネット上のほぼすべてのノード)を偽装します。

DNSクエリのなりすましは、通常UDP(コネクションレス型ユーザーデータグラムプロトコル)を介して行われるため、特に簡単です。任意のIPアドレスからDNSクエリを送信するのはほぼ同じくらい簡単で、はがきに他の人の返信アドレスを書き込むのとほぼ同じ効果があります。

ただし、スプーフィングクエリは、ターゲットを無力化するのに十分ではありません。これらのクエリへの応答がクエリ自体よりも大きくない場合、攻撃者はスプーフィングされたクエリでターゲットを氾濫させることも同様に行います。いいえ、ターゲットへのダメージを最大化するには、各クエリが非常に大きな応答を返す必要があります。それは非常に簡単に扇動できることがわかりました。

1999年に導入されたDNSの拡張機能であるEDNS0の登場以来、UDPベースのDNSメッセージは大量のデータを伝送することができました。応答は4,096バイトまで大きくなる可能性があります。一方、ほとんどのクエリは、長さが100バイト未満です。

昔々、インターネットの名前空間でこれほど大きな応答を見つけることは比較的困難でした。しかし、組織がDNSSEC、DNS Security Extensionsの展開を開始したので、はるかに簡単になりました。DNSSECは、暗号化キーとデジタル署名を名前空間のレコードに保存します。これらは積極的に巨大です。

私のブログで、DNSSECレコードを含むisc.orgゾーンからの応答の例を見ることができます。応答のサイズは4,077バイトですが、クエリは44バイトです。

ここで、インターネット上の攻撃者が、そのなりすましクエリをWebサーバーのIPアドレスからisc.orgネームサーバーに送信しているところを想像してみてください。44バイトのクエリごとに、Webサーバーは4,077バイトの応答を受信します。これは約93倍の増幅率です。

これがどれほど悪くなるかを理解するために簡単な計算をしてみましょう。各攻撃者がインターネットへの比較的控えめな1Mbps接続を持っているとしましょう。彼は、そのリンクを介して1秒あたり約2,840の44バイトクエリを送信できます。このクエリストリームにより、ほぼ93Mbps相当の応答がWebサーバーに到達します。11人の攻撃者ごとに1Gbpsを表します。

反社会的攻撃者は、攻撃の実行を支援する10人の友人をどこで見つけますか?実際、彼らは何も必要としません。彼らは何千ものコンピューターのボットネットを使用します。

究極の効果は壊滅的です。四半期ごとのグローバルDDoS攻撃レポートで、Prolexic(DDoS緩和企業)は、167Gbpsを超えた顧客に対する最近のDNSベースの攻撃を報告しました。Prolexicはさらに、平均DDoS攻撃帯域幅が1四半期で718%増加して48Gbpsになったと報告しました

ちょっと待って!isc.orgネームサーバーを変更して、同じIPアドレスから同じデータを何度も照会されていることを認識できませんでしたか?彼らは攻撃を抑えることができませんでしたか?

彼らは確かにできます。しかし、攻撃者がトラフィックを増幅するために使用できるのはisc.orgネームサーバーだけではありません。確かに、攻撃者が使用できる信頼できるネームサーバーは他にもありますが、さらに悪いのは、オープンな再帰ネームサーバーです。

オープン再帰ネームサーバーは、任意のIPアドレスからの再帰クエリを処理する単なるネームサーバーです。 isc.orgデータのクエリを送信すると、返信があります。同じことを行うことができます。

インターネット上にオープンな再帰ネームサーバーは多くないはずです。再帰ネームサーバーの機能は、ラップトップやスマートフォンのようなDNSクライアントに代わってインターネットの名前空間でデータを検索することです。再帰ネームサーバー(IT部門など)をセットアップするネットワーク管理者は、通常、特定のコミュニティ(たとえば、あなたとあなたの仲間の従業員)がそれらを使用することを意図しています。 OpenDNSやGooglePublic DNSなどのサービスを実行している場合を除き、モルドバの市民がそれらを使用することを意味するものではありません。そのため、公的な精神を持ち、セキュリティを重視し、特に有能な管理者は、再帰ネームサーバーでアクセス制御を構成して、使用を許可されたシステムに制限します。

それを考えると、再帰ネームサーバーを開くのにどれほど大きな問題が発生する可能性がありますか?かなり大きい。Open Resolver Projectは、3,300万のオープン再帰ネームサーバーのリストを収集しました。ハッカーは、Webサーバー、ネームサーバー、またはボーダールーターでisc.orgデータを窒息するまで吐き出すために、これらの数だけスプーフィングされたクエリを実行できます。

これがDNSベースのDDoS攻撃の仕組みです。ありがたいことに、それらと戦う方法はいくつかあります。

嵐を乗り切る方法

ビジネスの最初の順序はDNSインフラストラクチャを計測することであるため、攻撃を受けている時期がわかります。あまりにも多くの組織は、クエリの負荷が何であるかを知らないため、そもそも攻撃されているかどうかを知ることはできません。

クエリの負荷の決定は、BINDの組み込みの統計サポートを使用するのと同じくらい簡単です。rndc statsを実行すると、BINDネームサーバーはデータを統計ファイルにダンプします。たとえば、または構成可能な統計間隔で。クエリレート、ソケットエラー、およびその他の攻撃の兆候について統計を調べることができます。攻撃がどのように見えるかがまだわからなくても心配しないでください。DNSを監視する目的の一部は、ベースラインを確立することです。これにより、何が異常であるかを特定できます。

次に、インターネットに面したインフラストラクチャを見てみましょう。外部の権威ネームサーバーに限定しないでください。スイッチとルーターのインフラストラクチャ、ファイアウォール、およびインターネットへの接続を調べます。単一障害点を特定します。それらを簡単に(そして費用効果的に)排除できるかどうかを判断します。

可能であれば、外部の権威ネームサーバーの地理的な分散を検討してください。もちろん、これは単一障害点を回避するのに役立ちますが、攻撃を受けていないときにも役立ちます。ゾーンの1つでドメイン名を解決する再帰ネームサーバーは、それに最も近い権威ネームサーバーにクエリを実行しようとするため、地理的な分散により、顧客や特派員のパフォーマンスが向上する傾向があります。顧客が特定の地域に集まっている場合は、信頼できるネームサーバーを顧客の近くに配置して、最も迅速な対応を提供するようにしてください。

おそらく、DoS攻撃に対抗するための最も基本的な方法は、インフラストラクチャをオーバープロビジョニングすることです。良いニュースは、ネームサーバーのオーバープロビジョニングは必ずしも費用がかかるわけではないということです。有能なネームサーバーは、1秒あたり数万または数十万のクエリを処理できます。ネームサーバーの容量がわからない場合は、 dnsperfなどのクエリツールを使用して、ネームサーバーのパフォーマンスをテストできます。できれば、実稼働サーバー自体ではなく、ラボ内の実稼働ネームサーバーと同様のテストプラットフォームを使用します。

ネームサーバーをオーバープロビジョニングする量を決定することは主観的です:あなたのオンラインプレゼンスはどのくらいの価値がありますか?ネームサーバーの前に失敗するインターネットに面したインフラストラクチャの他のコンポーネントはありますか?明らかに、ネームサーバーが汗をかく前に失敗するボーダールーターまたはファイアウォールの背後にファーストクラスのDNSインフラストラクチャを構築するためにお金を費やすことは愚かです。

お金に問題がない場合は、DNSインフラストラクチャに対する最先端のDDoS攻撃が100Gbpsを超える可能性があることを知っておくと役立つ場合があります。

エニーキャストを使用すると、DDoS攻撃に抵抗することもできます。エニーキャストは、複数のサーバーが単一のIPアドレスを共有できるようにする手法であり、DNSで特にうまく機能します。実際、インターネットのルートネームサーバーは、エニーキャストを何年にもわたって使用して、ルートのリストを単一のUDPベースのDNSメッセージに収めながら、世界中にルートゾーンデータを提供してきました。

エニーキャストを展開するには、ネームサーバーをサポートするホストがOSPFやBGPなどの動的ルーティングプロトコルを実行する必要があります。ルーティングプロセスは、ネームサーバーがリッスンする新しい仮想IPアドレスへのルートを隣接ルーターにアドバタイズします。ルーティングプロセスは、ローカルネームサーバーが応答を停止した場合にそのルートのアドバタイズを停止するのに十分スマートである必要もあります。独自の構造のコードを使用して、ルーティングデーモンをネームサーバーの状態に接着することができます。または、それを処理する製品を購入することもできます。 InfobloxのNIOSには、偶然ではありませんが、Anycastのサポートが含まれています。

エニーキャストはDDoS攻撃に対してどのように防御しますか?たとえば、2つのエニーキャストグループに6つの外部ネームサーバーがあるとします(つまり、3つが1つのエニーキャストIPアドレスを共有し、3つが別のエニーキャストIPアドレスを共有します)。各グループには、米国に1人、ヨーロッパに1人、アジアに1人のメンバーが含まれています。あなたに対してDDoS攻撃を仕掛けるホストは、一度にインターネット上の任意のポイントから、いずれかのグループの1人のメンバーにのみトラフィックを送信できます(したがって、攻撃のみ)。攻撃者が北米、ヨーロッパ、アジアから同時に十分なトラフィックを調達してインフラストラクチャを圧倒しない限り、攻撃は成功しません。

最後に、多額の資本支出なしに、地理的に広い分布とエニーキャストを同時に利用できる方法があります。クラウドベースのDNSプロバイダーを使用します。 DynやNeustarなどの企業は、世界中のデータセンターで独自のエニーキャストネームサーバーを実行しています。ゾーンをホストし、データのクエリに回答するために料金を支払います。また、プロバイダーにゾーンのセカンダリとしてネームサーバーを構成するように依頼し、社内で指定および管理するマスターネームサーバーからデータを読み込むことで、ゾーンデータを引き続き直接制御できます。マスターを非表示にして(つまり、マスターを指すNSレコードがない状態で)実行するようにしてください。そうしないと、攻撃者が単一障害点としてマスターを標的にするリスクがあります。

クラウドベースのDNSプロバイダーを使用する場合の注意点:ほとんどの場合、ネームサーバーがゾーン内のデータに対して受信するクエリの数に少なくとも部分的に基づいて請求されます。DDoS攻撃では、これらのクエリが劇的に増加する可能性があるため(完全に制御不能であり、まったく利益になりません)、トラフィックのコストをあなたに渡さずにDDoS攻撃に対処するための準備が整っていることを確認してください。

DDoS攻撃の共犯者にならないようにする方法

これで、DDoS攻撃に抵抗するようにDNSインフラストラクチャを構成する方法がわかりました。ただし、他の誰かに対するDDoS攻撃に加担しないようにすることもほぼ同じくらい重要です。

DNSサーバーがトラフィックを増幅する方法の説明を覚えていますか?攻撃者は、オープンな再帰ネームサーバーと権威ネームサーバーの両方をアンプとして使用し、偽のクエリを送信して、ネームサーバーがインターネット上の任意のターゲットにクエリの100倍を超える応答を送信する可能性があります。さて、もちろん、あなたはそのような攻撃の標的になりたくありませんが、共犯者にもなりたくありません。この攻撃では、ネームサーバーのリソースと帯域幅が使用されます。ターゲットがネームサーバーからそのネットワークへのトラフィックをブロックする対策を講じている場合、攻撃が終了した後、ターゲットはゾーン内のドメイン名を解決できない可能性があります。

オープンな再帰ネームサーバーを実行している場合、解決策は簡単です。実行しないでください。再帰クエリに対してオープンなネームサーバーを実行する正当な理由がある組織はほとんどありません。 Google Public DNSとOpenDNSの2つが思い浮かびますが、これを読んでいるとしたら、おそらくそうではないと思います。残りのメンバーは、アクセス制御を再帰ネームサーバーに適用して、許可されたクエリアのみがそれらを使用するようにする必要があります。これはおそらく、DNSクエリを内部ネットワーク上のIPアドレスに制限することを意味します。これは、その塩に値するネームサーバー実装で簡単に実行できます。 (Microsoft DNSサーバーは、クエリに対するIPアドレスベースのアクセス制御をサポートしていません。必要な内容を読んでください。)

しかし、信頼できるネームサーバーを実行している場合はどうでしょうか。明らかに、クエリを受け入れるIPアドレスを制限することはできません-とにかく、それほど多くはありません(RFC 1918アドレスなどの明らかに偽のIPアドレスからのクエリを拒否する可能性があります)。ただし、応答を制限することはできます。

2つの長年のインターネット「ホワイトハット」であるPaulVixieとVernonSchryverは、増幅に信頼できるネームサーバーを使用するDDoS攻撃が特定のクエリパターンを示すことに気づきました。特に、攻撃者はネームサーバーに同じスプーフィングされたIPアドレス(またはアドレスブロック)から同じクエリを何度も送信し、最大の増幅を求めます。正常に動作する再帰ネームサーバーはそれを行いません。応答をキャッシュし、応答内のレコードの存続時間が経過するまで再度要求されませんでした。