世界を動かす技術を、日本語で。

Cloudflareが7.3 Tbpsの巨大なDDoS攻撃をどのように防いだか

概要

  • Cloudflare は2025年5月、 史上最大規模 の7.3 Tbps DDoS攻撃を自動的に防御
  • 攻撃は Magic Transit を利用するホスティングプロバイダーを標的
  • 主な攻撃手法は UDPフラッド、複数のリフレクション・アンプリフィケーション攻撃も観測
  • 攻撃は 世界中の12万以上のIP から発生、分散型ネットワークで自動検知・緩和
  • CloudflareのDDoS防御技術 と、サービスプロバイダー向け無料ボットネット情報提供について解説

Cloudflareが7.3 Tbps DDoS攻撃を阻止 — 史上最大規模の防御事例

  • 2025年5月中旬、Cloudflareが 7.3 Tbps のDDoS攻撃を自動検知・緩和
  • 攻撃対象は Magic Transit 導入のホスティングプロバイダー
  • 直前のDDoSレポートでは6.5 Tbps規模の攻撃も報告
  • 7.3 Tbpsは、前記録より 12%増、Brian Krebs氏報告の攻撃より 1 Tbps大きい記録
  • 攻撃は 45秒間で37.4 TB のデータを送信
    • これはHD映画9,350本分、7,480時間のHD動画に相当
    • 音楽なら9.35百万曲、写真なら12.5百万枚分
  • 攻撃は 平均21,925ポート を対象、最大 34,517ポート/秒 に達する爆撃型

DDoS攻撃の詳細と主な手法

  • 攻撃トラフィックの 99.996%がUDPフラッド
    • 残り0.004%はリフレクション・アンプリフィケーション攻撃
      • QOTDリフレクション、Echoリフレクション、NTPリフレクション、Mirai UDPフラッド、Portmapフラッド、RIPv1アンプリフィケーション等
  • 各攻撃手法の概要と防御策
    • UDPフラッド: UDPパケットを大量送信し回線や機器を圧迫
      • 防御策: クラウド型DDoS対策、UDPトラフィックのスマートレート制限
      • 注意点: VoIPやゲーム等正規UDPサービスへの影響に注意
    • QOTDリフレクション: UDP/17を悪用し増幅攻撃
      • 防御策: QOTDサービス無効化、UDP/17遮断
    • Echoリフレクション: UDP/TCP/7を悪用し反射増幅
      • 防御策: Echoサービス無効化、ポート7遮断
    • NTPリフレクション: NTPサーバのmonlistコマンド悪用
      • 防御策: monlist無効化、NTPソフト更新、UDP/123制限
      • 注意点: 過剰なUDP/123遮断は時刻同期に影響
    • Mirai UDPフラッド: IoTボットネットによるUDP攻撃
      • 防御策: IoT機器のセキュリティ強化、ファームウェア更新
      • 注意点: 正規UDPサービスへの影響に配慮
    • Portmapリフレクション: UDP/111のPortmapperサービス悪用
      • 防御策: 不要ならサービス無効化、必要時は信頼IPに限定
      • 注意点: RPC依存アプリへの影響を事前確認
    • RIPv1リフレクション: UDP/520の旧ルーティングプロトコル悪用
      • 防御策: RIPv1無効化、RIPv2+認証へ移行
      • 注意点: レガシー環境依存時は動作検証

攻撃元の特徴と分布

  • 攻撃は 122,145超のIPアドレス5,433 AS(自律システム)161カ国 から発生
  • トラフィックの約半数が ブラジルとベトナム から発信
    • 他、台湾、中国、インドネシア、ウクライナ、エクアドル、タイ、米国、サウジアラビア等
  • 最大発信AS: Telefonica Brazil(AS27699, 10.5%)
    • 次いでViettel Group(AS7552, 9.8%)、China Unicom(AS4837, 3.9%)等
  • 平均26,855、最大45,097のユニークIPが毎秒攻撃に参加

ボットネット情報の無料提供

  • Cloudflareは DDoS Botnet Threat Feed を無料提供
    • 600以上の組織が利用中
    • 自AS内の攻撃発信IPリストをAPIで取得可能
    • PeeringDB認証とCloudflareアカウント登録のみで利用開始

CloudflareのDDoS検知・緩和技術

  • グローバルAnycastネットワーク で攻撃トラフィックを最寄りデータセンターへ分散
    • 世界293拠点・477データセンターで攻撃を吸収・緩和
  • 自律型DDoS検知・緩和システム を全データセンターに展開
    • 攻撃元や規模に関係なく自動で検知・対応
  • リアルタイムパケットフィンガープリント を実施
    • LinuxカーネルのXDP・eBPF技術でパケットサンプリング
    • 不審パケットの即時特定・遮断

まとめと推奨事項

  • DDoS防御は ネットワークやアプリごとの特性考慮 が重要
  • 不要サービスの無効化正規トラフィックへの配慮 が被害最小化の鍵
  • Cloudflareの 分散型・自律型防御 が大規模攻撃にも有効
  • サービスプロバイダーは ボットネット情報活用 による攻撃源対策を推奨

Hackerたちの意見

この記事でQOTDプロトコルについて学んだよ!https://datatracker.ietf.org/doc/html/rfc865 インターネットの面白いアーティファクトだね!

自分のプライベートネットワークで動かしてるんだけど、かわいいからね。おもちゃみたいなCのユーティリティを書いて、Dockerに対応させたから、Proxmoxにポンと投げられるようにしたんだ。https://github.com/jkingsman/RFC865-QotD-Server-for-Docker

← ここにCloudflareがDDoS攻撃を売ってるサイトを守ってるっていう標準的な文句を入れておくよ(最悪の場合、病気を守りながら治療を売るっていう利害の対立だね)。

「Cloudflareの顧客、ホスティングプロバイダー」って誰だったのか、どのIPを狙ってたのか、なんでそんなことをしたのか知ってる人いる? なんでそんなに大掛かりなことをしてサービスを潰そうとしたのか気になるな。

記事によると、攻撃は45秒だったみたい。昔、かなり有名なウェブサイトを運営してたけど、90秒の攻撃がよく来てたんだ。推測するに、DDoSサービスの中には短い攻撃を無料サンプルとして提供するのがあって、私たちが有名だったから狙われたんだと思う。ありがたいことに、ほとんどの場合、攻撃は私たちのサービスじゃなくてウェブサイトに向けられたから、ウェブサイトの可用性はあまり重要じゃなかった。大抵の攻撃は大したことなくて、すぐに飽きて他に移っていった。ウェブサーバーを落とす攻撃はちょっと嬉しかったけど…それを使ってウェブサーバーと実際に仕事をしてるサーバーの調整ができたからね。

プロバイダーが誰かはわからないけど、攻撃はほぼ確実にプロバイダーを狙ってたんじゃなくて、彼らのプラットフォーム上にホストされているサイトを狙ってたと思う。多くのホスティング会社は、顧客にCloudflareのDDoS防止を提供するようなものをアップセルしてるんだ。狙われたサイトはおそらく政治的か物議を醸すようなものだったんじゃないかな。私はホスティングプロバイダーで働いてて、こういうことには常に対処してるよ。

DDoS攻撃は、インターネット全体の一部を使って単一のホストを攻撃するんだ。インターネットのユーザーや接続デバイスが増えるにつれて、DDoSのボリュームと単一の接続のボリュームの比率はどんどん大きくなるよね。何か解決策はないの?

100%の解決策ではないけど、ISPがやったら大いに助かることがあるよね:1) 偽のソースアドレスを防ぐために出口フィルタリングを行うこと 2) 大量の悪意のあるトラフィックを送信している顧客を一時的にシャットオフすること

どうやら、広まっている解決策はないし、どこでも機能する単一の解決策もないみたい。ソースアドレスフィルタリング(BCP 38)は部分的には効果があったけど、データセンターでやるのは難しいし望ましくない。ここで使われると推測されるIoTデバイスには、上流で解決策が必要だね。MUD(RFC 8520)みたいなものが提案されてるけど、問題もある - 開発者は自分のデバイスのすべての通信をリストアップして、それを何らかの形で提供できる必要がある(MUDプロファイルサーバー)。消費者の中には、自分からは絶対にやらない人もいるし、デバイスメーカーに自分がデバイスを持っていることを知らせたくない人もいる(つながった大人のおもちゃとか考えてみて…)。それに、IoTデバイスはオーナーによって更新されないことが多いから、何年もIoTボットネットのDoS攻撃が続くと思っておいた方がいいよ。

カパチャス?最悪で嫌われる解決策かもしれないけど、一応言っとこうと思って。もしかしたら、失敗したカパチャが多すぎると、1時間くらいIPに接続できなくなるかもね。

トラフィックごとにお金を取るようにすればいいんじゃない?

消費者向けの家庭やオフィス用ルーターは、クライアントにIP接続を無制限で提供してるけど、なんでそうなってるんだろう?デフォルトでは、利用可能な帯域幅を全部使えるようになってるはずだし、ISPから消費者へのサービス(たぶん有料)もそうだと思うけど、なんで消費者ルーターのIoTでそれがデフォルトなの?プリンターが500Mbpsの送信速度を必要とする理由って何?それとも、私の高級な歯ブラシとか?

Hacker Newsで議論の続きを見る