Ubuntu／CanonicalインフラがDDoS攻撃で約30時間停止｜313 Teamが26.04リリースを狙った

2026年4月30日、Canonical／Ubuntuの中核インフラが大規模なDDoS攻撃を受けて長時間ダウンした。ubuntu.com本体、開発者向けプラットフォームのLaunchpad、Snap Store、シングルサインオン基盤のCanonical SSOまで影響が波及し、世界中のapt update／apt installが失敗、新規CVEに対するセキュリティアップデートの取得が事実上不可能になった。攻撃の主体は313 Team（Islamic Cyber Resistance in Iraq）を名乗る親イラン系ハクティビスト集団で、Ubuntu 26.04 LTS（Resolute Raccoon、4月23日リリース）公開直後の需要ピークを狙った点が今回の特徴だ。Canonicalは5月1日 14:44 CETに全サービス復旧を発表したが、約30時間の停止が世界中のDevOps現場に与えた衝撃は大きい。本記事ではこの事件の経緯、26.04直撃という攻撃の意図、運用者が取るべき暫定回避策、そしてOSS配布インフラを狙う脅迫型ハクティビズムの構造的リスクを解析する。

この記事ではCanonical／Ubuntuに対するDDoS攻撃事件を解析します。OSSサプライチェーン全体のリスク像についてはサプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

攻撃の経緯：26.04リリース週を直撃した約30時間の停止

Ubuntu Discourseの公式投稿と複数の独立した報道を時系列で整理すると、攻撃は単発の波ではなく断続的に継続し、復旧と再ダウンを繰り返したことがわかる。

ステータスページ上では多数のコンポーネントが同時に「Major Outage」となり、canonical.com・portal.canonical.com・maas.io・jaas.ai・assets.ubuntu.com・developer.ubuntu.comまで波及したことが報告された。攻撃者は単一ドメインを狙ったのではなく、Canonical配下のCDN／オリジンを横断的に標的化したと推定される。約30時間に及ぶ累計停止は、商用OSSベンダーのインシデントとしてはCloudflare／Fastly関連事件と並ぶ規模だ。

なぜ26.04リリース週を狙ったのか

今回の攻撃の最大の特徴は、Ubuntu 26.04 LTS（Resolute Raccoon、2026年4月23日リリース）の公開直後を狙って発射された点だ。26.04は偶数年4月の長期サポート（LTS）版にあたり、新カーネルや刷新されたツールチェーンを含む重要リリースで、世界中のISP・データセンターでイメージ取得需要が急増する週だった。攻撃が観測された4月30日は、まさにそのリリース直後の需要ピークのただ中だった。

リリース直後のミラー同期負荷とDDoSが重なることで、正常なフラッシュトラフィックなのか攻撃トラフィックなのか切り分けが困難になるという二次効果も生じる。これは2024年のFedora 41リリース時に観測された類似インシデントと構造が似ており、ハクティビスト側が「OSSの年中行事カレンダー」を学習している可能性を示唆する。

313 Teamとは何者か：脅迫型ハクティビズムの新潮流

313 Teamは「Islamic Cyber Resistance in Iraq」を称する親イラン系ハクティビスト集団で、2023年12月以降に短時間DDoSを連続発射する手口で知られる。これまでの観測では以下の特徴が報告されている。

今回の事件で注目すべき点は、金銭ではなく政治的アジェンダを掲げた“象徴的攻撃”である一方、攻撃対象としてOSSの中核を支える企業を選んだ非対称性だ。Canonicalほどの組織でも、配布インフラを止められれば全世界の運用者が即時に困る。OSS配布層の単一障害点が現実の攻撃面として狙われた典型例といえる。

何が止まったか：Launchpad／Snap Store停止の真の意味

今回の攻撃の真に深刻な側面は、止まった対象がOSS配布チェーンのほぼ全層に及んだ点にある。単にaptが失敗するだけではなく、開発者がパッケージを公開するLaunchpad、Snap Store、Canonical SSOまで一斉に止まった。

たとえば本サイトでも先日扱ったLinux Kernel Container Escape脆弱性 CVE-2026-31431（Copy Fail）の解説のような重大CVEが連続している現状で、security.ubuntu.comが落ちる＝CVE適用が遅れるという事実は、攻撃の「副次効果」ではなく明確な狙いとみるべきだ。Snap Storeの停止は、Firefoxのゼロデイが出た瞬間に更新が走らないことを意味し、結果としてエンドユーザー側の脆弱性窓を意図的に広げる効果を持つ。

運用者が今すぐ取れる暫定回避策

公式の復旧を待つ間にも、現場のサーバーは脆弱性を抱えたまま動き続ける。Ubuntu運用者が即座に取れる現実的な対策を3段階で整理する。

1. 国内ミラーへの切り替え

/etc/apt/sources.listのarchive.ubuntu.com・security.ubuntu.comを国内ミラーに差し替えることで、Canonical本体が落ちていても更新を継続できる。日本国内の主要ミラーは次のとおり。

# JAIST（北陸先端科学技術大学院大学）に切替
sudo sed -i.bak \
  -e 's|http://archive.ubuntu.com/ubuntu|http://ftp.jaist.ac.jp/pub/Linux/ubuntu|g' \
  -e 's|http://security.ubuntu.com/ubuntu|http://ftp.jaist.ac.jp/pub/Linux/ubuntu|g' \
  /etc/apt/sources.list

# 24.04以降のDEB822形式（/etc/apt/sources.list.d/ubuntu.sources）を使う環境
sudo sed -i.bak \
  -e 's|archive.ubuntu.com|ftp.jaist.ac.jp/pub/Linux|g' \
  -e 's|security.ubuntu.com|ftp.jaist.ac.jp/pub/Linux|g' \
  /etc/apt/sources.list.d/ubuntu.sources

sudo apt update

ただしsecurity mirrorはCanonical本体の信頼チェーンに依存しているため、本体が完全停止していると更新タイムスタンプが古くなる場合がある。あくまで「攻撃が部分的で本体側の同期が動いている」前提での回避策だ。

2. apt実行時のリトライ／タイムアウト調整

DDoSが間欠的な場合、apt側の再試行回数を増やすだけで体感の改善ができる。/etc/apt/apt.conf.d/99-retryに以下を追加する。

# /etc/apt/apt.conf.d/99-retry
Acquire::Retries "5";
Acquire::http::Timeout "60";
Acquire::https::Timeout "60";
Acquire::ForceIPv4 "true";

# 並列ダウンロード数を抑え、上流負荷を下げつつ自分の成功率を上げる
Acquire::Queue-Mode "host";
Acquire::http::Pipeline-Depth "0";

ForceIPv4はDDoS時にIPv6側のルーティングが不安定になる現象を回避する保険として有効だ。

3. ローカル／オフラインキャッシュの活用

中規模以上の組織ではapt-cacher-ngやAptlyを社内に立て、ミラーから取得したパッケージをローカルキャッシュ化しておくと、上流ダウンの影響を最小化できる。CIランナーや本番サーバー群が同じパッケージを並列取得する場合、平常時のトラフィック削減にもなる。

# apt-cacher-ng クイックスタート（Docker）
docker run -d --name apt-cacher-ng \
  -p 3142:3142 \
  -v $(pwd)/apt-cacher-ng-cache:/var/cache/apt-cacher-ng \
  --restart unless-stopped \
  sameersbn/apt-cacher-ng:latest

# クライアント側設定
echo 'Acquire::HTTP::Proxy "http://apt-cache.local:3142";' \
  | sudo tee /etc/apt/apt.conf.d/01proxy

# 主要ミラーをremap_*で複数登録（apt-cacher-ng本体側）
# /etc/apt-cacher-ng/backends_ubuntu に以下を列挙:
#   http://ftp.jaist.ac.jp/pub/Linux/ubuntu/
#   http://ftp.riken.jp/Linux/ubuntu/
#   http://archive.ubuntu.com/ubuntu/

複数のミラーをbackendsに登録しておけば、片方が落ちても自動でフェイルオーバーする。CIランナー専用の小規模Squidキャッシュを置くだけでも、リリース週のフラッシュ需要を吸収できる。

Ubuntuリリース体系とAIスタック更新で押さえる前提

今回の影響範囲を正しく見積もるには、Ubuntuのリリース体系と、apt経由で更新されるAIスタック（GPUドライバ・CUDA）の依存関係を理解しておく必要がある。とくにLLM／機械学習を回す環境は、OS本体よりもNVIDIAドライバ・CUDA・cuDNNといったapt配布物への依存が深く、archive停止の影響を受けやすい。

偶数年4月の.04リリース（24.04・26.04）が長期サポート（LTS）版で、本番・サーバー用途の基準になる。.10や奇数年の中間リリースはサポート9ヶ月の短期版で、新機能の先取り用と位置づけられる。今回攻撃を受けた26.04は前述のとおりLTSであり、LTSへのアップグレード需要が世界規模で集中する週を狙われたことが被害を増幅させた。

AIスタック（GPUドライバ／CUDA）はarchive停止の影響を強く受ける

GPUを使うAI／ML環境は、OSパッケージに加えて以下のapt由来コンポーネントに依存する。archive・securityミラーやNVIDIAのaptリポジトリが止まると、これらの更新・再構築が連鎖的に詰まる。

・ubuntu-drivers／nvidia-driver-*：Ubuntu本体archive経由で配布されるNVIDIAドライバ。archive停止時はドライバ更新・新規インストールが失敗
・CUDA Toolkit・cuDNN：NVIDIAの専用aptリポジトリ（developer.download.nvidia.com）から取得。Ubuntu archiveとは別系統だが、依存パッケージ（gcc、build-essential、カーネルヘッダ）はUbuntu archive側にあるため間接的に影響
・コンテナ基盤のnvidia-container-toolkit：GPUコンテナ運用の要。これが更新できないとCUDAイメージのビルド・更新が停止
・do-release-upgradeでの26.04移行：GPUドライバの再ビルド(DKMS)を伴うため、archive混雑期のアップグレードはドライバ不整合のリスクが上がる

# GPU/CUDA環境では、archive停止時に「何が更新待ちか」を即座に把握する
apt list --upgradable 2>/dev/null | grep -Ei 'nvidia|cuda|linux-(image|headers)|dkms'

# DKMS（ドライバ再ビルド）状態の確認。アップグレード前に整合性を見る
dkms status

# NVIDIA aptリポジトリの到達性チェック（停止検知用）
curl -sS -o /dev/null -w '%{http_code}\n' \
  https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/

GPU/CUDA環境では、ドライバとカーネルのバージョン整合（ABI）が崩れると起動不能やCUDA認識不可に直結する。archive混雑期にはドライバ・カーネルの更新を意図的に保留（apt-mark hold）し、ミラー同期が落ち着いてから整合性を確認しつつ更新するのが安全だ。AIワークロードを止めないためにも、後述のローカルキャッシュにNVIDIA系パッケージも含めておくと復旧が早い。AIエージェントが自動でこうした更新・運用を回す環境のリスク設計については、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドも参考になる。

攻撃手法の技術的解析：L3／L7ハイブリッドDDoS

公開情報と過去の313 Teamの行動パターンから推測される今回の攻撃の技術的構造を整理する。あくまで状況証拠ベースの推定だが、再発時の検知・対処のヒントになる。

推定される攻撃ベクトル

security.ubuntu.comのように静的ファイル中心のオリジンに対しては、ボリューメトリック攻撃でCDN／オリジン間回線を埋めるのが効きやすい。一方で動的処理を含むLaunchpadやCanonical SSOは、L7のTLSハンドシェイク消費がCPU側のボトルネックになる。今回複数のドメインが同時に長時間落ちたのは、両方を組み合わせた「ハイブリッドDDoS」と見るのが妥当だろう。

商用booterの経済性

313 Teamが利用したと主張するBeamed.SUのようなcommercial booter（IPストレッサー）は、月額数十ドル〜数百ドルでGbps級のDDoSを発射可能だ。ハクティビストにとって費用対効果が極めて高く、「金銭目的の犯罪者」と「政治的動機の集団」の境界が曖昧になりつつある。

booter利用料の概算：
- 月額$30:    〜10Gbps、攻撃時間 数分単位
- 月額$200:   〜100Gbps、攻撃時間 長時間
- 月額$500+:  数百Gbps、複数キャンペーン同時実行

数十万円の月額コストで世界規模のOSSインフラに圧力をかけられる構造そのものが、今回の事件の根本にある。サプライチェーン側で見ると、依存関係の自動更新を扱うRenovate・Dependabot防御｜サプライチェーン攻撃の最新対策とも問題が地続きで、配布経路と依存性管理の両面で備える必要がある。

過去のOSSサプライチェーン事件との位置づけ

OSSインフラを標的にしたDDoS／脅迫はこれが初めてではない。文脈を整理すると今回の攻撃の位置づけが見える。

過去の主流は「悪意あるコードを混入させる」「特定脆弱性を悪用する」攻撃だったが、今回はインフラそのものを止めて影響力を交渉カードにする点で性質が異なる。npmやPyPI、cargo、Docker Hubなど他のOSSパッケージレジストリも同様の標的になり得る。最近のCI／CD周辺脆弱性、たとえばGitHub RCE脆弱性CVE-2026-3854｜git pushでパイプライン乗っ取りとも組み合わさると、影響範囲は配布層と実行層の両方に広がる。

構造的リスク3点

1. OSS配布インフラの寡占：DebianやUbuntuのarchiveが落ちるだけで、世界中のサーバーが同時に困る。攻撃インセンティブが大きい
2. ハクティビストの商業化：commercial booterサービス（IPストレッサー）の発達で、技術力が低くても大規模DDoSが打てる
3. 公式コミュニケーション不足：Canonicalほどの組織でも初動の声明が遅い。混乱拡大と二次被害（フィッシング偽サイト誘導等）を招く

BCP（事業継続計画）として考えるOSS依存リスク

今回の事件を一過性のニュースとして消費するのではなく、自社の事業継続計画（BCP）に「OSS配布インフラの停止」を正式に組み込む契機とすべきだ。具体的なシナリオベースの想定と対応を表にまとめる。

「想定外の停止」を「想定内の運用」に組み替える発想転換が、SRE組織にとっての真の学びになる。

監視テンプレート例（Prometheus／Blackbox Exporter）

外部依存サービスの可用性を継続的に監視するためのblackbox-exporter設定例を示す。これがあれば、次回似たような事象が発生したとき早期に気づける。

# prometheus.yml の抜粋
scrape_configs:
  - job_name: 'oss-supply-chain-health'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://archive.ubuntu.com/ubuntu/dists/noble/Release
          - https://security.ubuntu.com/ubuntu/dists/noble-security/Release
          - https://api.snapcraft.io/v2/snaps/info/core
          - https://launchpad.net/
          - https://login.ubuntu.com/
          - https://registry-1.docker.io/v2/
          - https://registry.npmjs.org/
          - https://pypi.org/simple/
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

応答時間とHTTPステータスをアラート化し、5分以上継続失敗で通知すれば、ニュースで知る前に運用側で気づける。Slack通知に「代替ミラーへの切替コマンド」をリンクとして含めれば、夜間オンコール対応も効率化できる。

復旧後の事後対応チェックリスト

5月1日 14:44 CETに復旧した後も、以下の点検を行うことで「次回」への備えとなる。

• sources.list／ubuntu.sourcesに複数のミラーURLを冗長化しているか
• apt-cacher-ng等のローカルキャッシュを構築済みか
• CVE通知をCanonical Security APIだけでなく、CVE.org・OSV・GitHub Advisory Databaseなど複数経路で監視しているか
• CI/CDでapt失敗時の自動リトライ／代替ミラー切替が機能するか
• サプライチェーンインシデントを想定したランブック（手順書）が整備されているか
• 26.04へのアップグレード計画を、ミラー混雑が落ち着くタイミングまで見直したか
• Snap更新の状態（snap changes）に異常がないか確認したか

OSSは「タダで動くもの」ではなく、コミュニティとインフラ運営者の善意とコストで成り立っている。今回のような攻撃は、その脆さを露呈させる一方で、運用者側にも「依存関係の冗長化」という当事者意識を要求している。Ubuntu 26.04のアップグレードを予定している組織は、ミラー側の同期が落ち着く5月中旬以降を目安に、複数ミラーを併用しながら段階的に切り替えるのが安全だ。

参照ソース

• Update concerning DDoS attack on Canonical and Ubuntu (Ubuntu Discourse) — Canonical／Ubuntu公式の更新投稿（5月1日 14:44 CET全サービス復旧の発表を含む）
• Ubuntu services hit by outages after DDoS attack (TechCrunch) — TechCrunchによる第一報の俯瞰
• Canonical confirms Ubuntu infrastructure under sustained DDoS attack (The Register) — The Registerの技術的詳細とDevOpsインパクトの分析
• Canonical under sustained DDoS attack as Ubuntu 26 releases — Iranian group 313 Team claims responsibility (Tom’s Hardware) — 帰属（attribution）と26.04リリースとの関連分析