DDoS 増幅攻撃の構造

増幅攻撃は、最も一般的な分散型サービス拒否 (DDoS) 攻撃ベクトルの 1 つです。これらの攻撃は通常、フラッディング攻撃またはボリューム攻撃に分類されます。攻撃者は、ターゲットが処理できる以上のトラフィックを生成することに成功し、受信したトラフィックの量によってリソースを使い果たします。

このブログでは、増幅攻撃の構造と状況を調査することから始め、最も一般的な攻撃ベクトル、ボリューム、および分布に関する Azure からの統計を提供します。次に、増幅攻撃を軽減するために Azure で講じられたいくつかの対策について説明します。

DDoS 増幅攻撃とは?

リフレクション攻撃には、攻撃者、リフレクター、ターゲットの 3 者が関与します。攻撃者はターゲットの IP アドレスをスプーフィングして、ターゲット (この場合は仮想マシン (VM)) に応答するリフレクター (オープン サーバー、ミドルボックスなど) にリクエストを送信します。攻撃が増幅されるには、応答が要求よりも大きくなければならず、その結果、増幅攻撃が反映されます。攻撃者の動機は、最小のリクエストから最大のリフレクションを作成することです。攻撃者は、多くのリフレクターを見つけて、最大の増幅をもたらすリクエストを作成することで、この目標を達成します。

リフレクト増幅攻撃の根本的な原因は、攻撃者が送信元 IP アドレスをスプーフィングすることで、リフレクターをターゲットに応答させることができることにあります。スプーフィングが不可能な場合、この攻撃ベクトルは軽減されます。そのため、IP 送信元アドレスのスプーフィングを無効にするために多くの努力が払われており、攻撃者が増幅攻撃のためにネットワークを利用できないように、今日では多くの組織がスプーフィングを防止しています。残念ながら、かなりの数の組織が依然としてソース スプーフィングを許可しています。スプーファー プロジェクトは、IPv4 自律システムの 3 分の 1 がスプーフィングを許可または部分的に許可していることを示しています。

UDP および TCP 増幅攻撃

ほとんどの攻撃者は、UDP を利用して増幅攻撃を開始します。これは、適切なハンドシェイクがないために、なりすまし IP ソース アドレスを含むトラフィックが反映される可能性があるためです。

UDP ではリフレクト増幅攻撃を簡単に開始できますが、TCP にはスプーフィング攻撃を複雑にする 3 ウェイ ハンドシェイクがあります。その結果、IP 送信元アドレスのスプーフィングはハンドシェイクの開始に制限されます。 TCP ハンドシェイクはリフレクションを可能にしますが、TCP SYN+ACK 応答は TCP SYN よりも大きくないため、簡単に増幅することはできません。さらに、TCP SYN+ACK 応答がターゲットに送信されるため、攻撃者はそれを受け取ることはなく、TCP SYN+ACK に含まれる重要な情報を学習できず、3 ウェイ ハンドシェイクを正常に完了して、ターゲットに代わって要求を作成し続けることができません。ターゲット。

しかし、近年、TCP をベースとしたリフレクション攻撃や増幅攻撃が出現し始めています。

独立した調査では、国家検閲ファイアウォールやその他のディープ パケット インスペクション デバイスなどのミドルボックスを利用してボリューム フラッドを起動する、 より新しい TCP 反射増幅ベクトルが発見されました。ミドルボックス デバイスは、TCP 接続の一方の側 (クライアントからサーバーへのパケットなど) しか見えない非対称ルーティング環境に展開される場合があります。この非対称性を克服するために、このようなミドルボックスは非準拠の TCP スタックを実装することがよくあります。攻撃者はこの不正行為を利用します。攻撃者は 3 ウェイ ハンドシェイクを完了する必要はありません。それらは、ミドルボックスから増幅された応答を引き出す一連の要求を生成でき、場合によっては無限の増幅に達する可能性があります。業界は、ファイアウォールや IDPS デバイスなどの検閲やエンタープライズ ミドル ボックスからのこの種の攻撃を目撃し始めており、攻撃者が DDoS を主要な武器として利用して大混乱を引き起こす方法をさらに模索しているため、この傾向が強まることが予想されます。

カーペット爆撃は、反射増幅攻撃のもう 1 つの例です。 UDP リフレクションを利用することが多く、近年では TCP リフレクションも利用しています。カーペット爆撃では、攻撃を単一または少数の宛先に集中させるのではなく、攻撃者は特定のサブネットまたはクラスレス ドメイン間ルーティング (CIDR) ブロック (/22 など) 内の多くの宛先を攻撃します。このような攻撃は、一般的なベースラインベースの検出メカニズムを下回ってしまう可能性があるため、攻撃の検出と軽減がより困難になります。

TCP カーペット爆撃の一例は、TCP SYN+ACK リフレクションです。攻撃者は、スプーフィングされた SYN を広範囲のランダムまたは事前に選択されたリフレクターに送信します。この攻撃では、増幅は、応答が得られないときに TCP SYN+ACK を再送信するリフレクターの結果です。 TCP SYN+ACK 応答自体の増幅は大きくない可能性があり、リフレクターによって送信される再送信の数に依存します。図 3 では、ターゲットの仮想マシン (VM) のそれぞれに向けて反射された攻撃トラフィックは、それらをダウンさせるのに十分ではない可能性がありますが、全体として、トラフィックはターゲットのネットワークを圧倒する可能性があります。

Azure での UDP および TCP 増幅攻撃

Azure では、インバウンド (インターネットから Azure へ) およびアウトバウンド (Azure からインターネットへ) 増幅攻撃を軽減するために継続的に取り組んでいます。過去 12 か月で、約 175,000 件の UDP 反射増幅攻撃を緩和しました。 10 を超える攻撃ベクトルを監視しました。最も一般的なものは、49,700 回の攻撃を含む NTP、42,600 回の攻撃を含む DNS、27,100 回の攻撃を含む SSDP、および 18,200 回の攻撃を含む Memcached です。これらのプロトコルは、それぞれ最大 x4,670、x98、x76、および x9,000 の増幅率を示すことができます。

すべての攻撃ベクトルにわたる 1 回の攻撃について、1 秒あたりのパケット数で最大攻撃スループットを測定しました。最高のスループットは、昨年 8 月の 1 秒あたり 5,800 万パケット (pps) の SSDP フラッドで、Azure の 1 つのリソースに対して 20 分間続いた短い攻撃キャンペーンでした。

TCP 反射増幅攻撃は、 新しい攻撃ベクトルが発見され、より一般的になっています。さまざまな種類のリフレクターと攻撃ベクトルを利用して、Azure リソースに対するこれらの攻撃に遭遇します。

そのような例の 1 つは、アジアの Azure リソースに対する TCP SYN+ACK の TCP 反射増幅攻撃です。攻撃は 3000 万 pps に達し、15 分間続きました。攻撃のスループットは高くありませんでしたが、約 900 個のリフレクターが関与し、それぞれに再送信があったため、pps レートが高くなり、ホストやその他のネットワーク インフラストラクチャ要素がダウンする可能性がありました。

スプーフィングされた送信元から ACK 応答を取得しないリフレクターに関連する多くの TCP SYN+ACK 再送信が見られます。このような再送信の例を次に示します。

再送されたパケットは、最初のパケットから 60 秒後に送信されました。

Azure で増幅攻撃を軽減する

反射増幅攻撃は今後も定着し、インターネット コミュニティに深刻な課題をもたらします。彼らは進化を続け、プロトコルやソフトウェア実装の新しい脆弱性を悪用して、従来の対策を回避します。増幅攻撃の影響を最小限に抑えるには、業界全体の協力が必要です。特定の場所でこのような攻撃を緩和するだけでは、ピンポイントの緩和戦略では十分ではありません。これには、ネットワークと DDoS 緩和機能の絡み合いが必要です。

Azure のネットワークは、世界最大のネットワークの 1 つです。ネットワーク全体で複数の DDoS 戦略と DDoS 緩和パイプラインを組み合わせて、反射増幅 DDOS 攻撃に対抗します。

ネットワーク側では、さまざまなトラフィック監視、トラフィック エンジニアリング、およびサービス品質 (QoS) 技術を継続的に最適化および実装して、ルーティング インフラストラクチャで直接増幅攻撃をブロックします。これらのメカニズムは、ワイド エリア ネットワーク (WAN) ネットワークのエッジとコア、およびデータ センター内に実装されています。 (インターネットからの) インバウンド トラフィックの場合、ネットワークのエッジで攻撃を緩和することができます。同様に、アウトバウンド攻撃 (ネットワーク内から発信される攻撃) は、WAN を使い果たしたりネットワークから離れたりすることなく、データ センターで直接ブロックされます。

さらに、専用の DDoS 緩和パイプラインは継続的に進化し、そのような攻撃に対する高度な緩和技術を提供します。この緩和パイプラインは、DDoS ネットワーク戦略に加えて、別の保護レイヤーを提供します。これら 2 つの保護レイヤーを組み合わせることで、最大かつ最も巧妙なリフレクト アンプ攻撃に対する包括的なカバレッジが提供されます。

リフレクト増幅攻撃は通常ボリュームメトリックであるため、高度な緩和戦略を実装するだけで十分であるだけでなく、最大規模の攻撃に対処できる高度にスケーラブルな緩和パイプラインを維持することも必要です。当社の軽減パイプラインは、グローバルに 60Tbps 以上を軽減できます。また、すべてのネットワーク レイヤーに軽減容量を追加することで、それを進化させ続けています。

異なる攻撃ベクトルには異なる処理が必要です

UDP ベースのリフレクト増幅攻撃は、すべての攻撃ベクトルに対して追跡、監視、検出、軽減されます。攻撃された IP アドレス全体の異常検出、L4 プロトコル、スプーフィングされた送信元 IP の追跡など、これらの攻撃に対抗するためのさまざまな緩和手法があります。 UDP 反射増幅攻撃はしばしばフラグメント化されたパケットを作成するため、IP フラグメントを監視してそれらをうまく緩和します。

TCP ベースのリフレクト増幅攻撃は、貧弱な TCP スタック実装、および大量のリフレクターとターゲットのセットを利用して、このような攻撃を開始します。攻撃者やリフレクターからの攻撃を検出してブロックできるように、軽減戦略を採用しています。 TCP SYN、TCP SYN+ACK、TCP ACK、およびその他の TCP ベースの攻撃に対処するために、一連の緩和策を採用しています。緩和は、スプーフィングされたパケットを識別する TCP 認証メカニズムと、データが TCP パケットに追加されてリフレクターによる増幅をトリガーするときに攻撃トラフィックをブロックする異常検出を組み合わせます。

Azure DDoS Protection を使って増幅攻撃から保護する

Azure の DDoS 緩和プラットフォームは、60Tbps を超えて拡張できるグローバルに分散された DDoS 保護プラットフォームを採用することで、史上最大の DDoS 攻撃を緩和しました。当社のプラットフォームとお客様のワークロードが DDoS 攻撃から常に保護されていることを保証します。 DDoS 態勢を強化するために、他の業界関係者と継続的に協力して、リフレクト アンプ攻撃と戦っています。

Azure のお客様は、インフラストラクチャとクラウド プラットフォームの保護の一環として、レイヤー 3 およびレイヤー 4 の DDoS 攻撃から保護されています。ただし、Azure DDoS Protection Standard は、保護されたアプリケーションの特定のトラフィック パターンに合わせて検出ポリシーを自動調整することで、お客様に包括的な保護を提供します。これにより、フラッシュ クラウド イベントの場合など、トラフィック パターンに変化が生じるたびに、DDoS ポリシーが自動的に更新され、最適な保護のためにそれらの変化が反映されます。保護されたアプリケーションに対して反射増幅攻撃が開始されると、自動調整されたポリシーに基づいて検出パイプラインが自動的に検出します。緩和ポリシーは、お客様が手動で構成または変更する必要なく自動的に設定され、リフレクト増幅攻撃をブロックするために必要な対策が含まれています。

保護は、新規または既存の仮想ネットワークで簡単に有効にすることができ、アプリケーションやリソースの変更は必要ありません。最近リリースされた Azure の組み込みポリシーを使用すると、すべての仮想ネットワーク リソースとログの構成でのオンボーディングが大幅に容易になり、ネットワーク セキュリティ コンプライアンスの管理が向上します。

アプリケーションのセキュリティ体制を強化するために、Azure のネットワーク セキュリティ サービスを連携させてワークロードを保護できます。DDoS 保護は、Azure が提供するツールの 1 つです。ゼロトラスト アーキテクチャを追求する組織は、より優れた保護を実現するために、当社のサービスの恩恵を受けることができます。

Azure DDoS Protection Standard の詳細を確認する

• Azure DDoS Protection 製品ページ.
• Azure DDoS Protection Standardのドキュメント。
• Azure DDoS Protection Standard 参照アーキテクチャ.
• DDoS 防御のベスト プラクティス。
• Azure DDoS ラピッド レスポンス.
• オンプレミスのリソースを保護します。

アミール・ダハンとサイド・パシャ
Azure ネットワーク チーム

参考文献

1スプーファープロジェクト

2 TCP Reflected Amplification のためのミドルボックスの武器化