CanonicalへのDDoS、6日目に終結。残ったのは何か

4月30日夜から続いていたCanonicalへの大規模DDoSが、5月6日に終結した。Canonicalは恐喝を退けたが、6日間のダウンタイムが残したのは「無傷の勝利」ではない。

終結はCanonical公式の言葉で確定した

5月6日 03:26 UTC（日本時間 12:26）、Canonicalは公式X（@Canonical）と公式Discourseで攻撃の収束を発表した。投稿は短い。

最近のサービス停止について、心からお詫びいたします。現段階で、DDoS攻撃で影響を受けたサービスに対する緩和措置を実装し、復旧を完了しました。詳細はDiscourseの更新を参照してください。

「mitigations and restored」という言い回しは、攻撃が完全に止んだという意味ではない。Canonicalが攻撃トラフィックをいなす仕組みを実装し、ユーザー側から見えるサービスを正常状態に戻した、という意味だ。攻撃側が再び手を変えて戻ってくる可能性は依然として残る。声明の続きにある「一部サービスで部分的な性能低下を経験する可能性がある」という注記が、その含みを示している。

ステータスページでは現在、全コンポーネントが「operational」表示になっている。StatusGatorも5月7日 10:05 UTC時点で「サービスは正常稼働、過去24時間の障害は解消済み」と記録している。連休前夜から世界中の管理者を揺さぶった6日間のインシデントは、ようやく過去形で語れる段階に入った。

攻撃期間は結局「丸6日」になった

時系列をJSTで整理しておく。

開始は4月30日 18:00頃（UK時間）、日本時間で5月1日 02:00頃。終結発表は5月6日 12:26 JST。結局6日間にわたって、世界最大級のLinuxディストリビューションのインフラが攻撃下にあったことになる。

途中で「復旧した」と報じられた瞬間が何度かあった。OMG! Ubuntuは5月4日付で「全サービス稼働中」と書き、FastNetMonも同日に同様の報を出した。だがStatusGatorの15分間隔ログを見ると、5月3日に20時間超のダウン、5月4日に10時間超、5月5日にも11時間超のダウンが記録されている。あの「復旧宣言」はその瞬間のスナップショットを切り取っただけで、攻撃側はCanonicalが防御を当てるたびに手法を変えて戻ってきていた。

ステータスページが緑なのに繋がらない、という奇妙な状態が断続的に起きていた。Ubuntu Discourseでもユーザーから「Launchpadはダウンしているのにステータスは終日upと表示されている」という指摘が出ていた。インシデント対応における「表示」と「実態」の乖離は、こうした長期戦で必ず噴き出す問題だ。

攻撃を主張した313 Team（イラク・イスラム・サイバーレジスタンス）は、5月6日以降に追加攻撃を表明していない。Canonicalが緩和に成功した時点で、攻撃継続のコストパフォーマンスが見合わなくなったと見ていい。

Canonicalは恐喝に応じなかった

このインシデントで最も重要な事実は、技術的な復旧の話ではない。Canonicalが恐喝交渉を一切受けず、6日間の沈黙だけで押し切ったことだ。

313 TeamはTelegram経由で脅迫文を送り、Session（メタデータを最小化するメッセンジャー、身代金交渉の常用ツール）の連絡IDを共有していた。「我々のSession連絡IDをメールで送った。応じなければ攻撃を続ける」という露骨なメッセージだった。具体的な金額は明示されていなかったが、ハクティビズムから純粋な恐喝への変質を示す内容だった。

Canonicalは公式チャンネルで攻撃を「sustained, cross-border attack（持続的・越境的な攻撃）」と認めただけで、要求の存在にも拒否にも一切触れなかった。教科書的に正しい対応だ。一度応じれば、Canonicalは「払う標的」としてマークされ、同種の攻撃が定期的に来る関係に組み込まれる。

しかし、その「正しさ」の代償が6日間のダウンタイムだったことも事実だ。Ubuntu Pro／ESM契約を持つ企業ユーザーは、その期間中pro attachが失敗し、esm.ubuntu.comへの到達性が断続的に失われた。contracts.canonical.comのDNSが攻撃下のIP帯（185.125.190帯）しか返さない構造だったため、ユーザー側にできることは「Canonicalの復旧を待つ」以外になかった。

払わない判断を選んだ企業の従業員と顧客が、不便を肩代わりしている。これはランサムウェアやDDoS恐喝が世界中で広がっている現代における、避けられない副作用だ。Canonicalが今回の沈黙で得たのは「次は来ないかもしれない」という不確実な賭けでしかない。

CopyFailとの最悪のタイミング

このDDoSが発生した時期は、Linuxエコシステムにとって最悪のタイミングだった。

4月29日、セキュリティ企業Theori（Xint Code）がCopyFail（CVE-2026-31431）を公開していた。2017年以降に出荷された全Linuxディストリビューション（カーネル4.14〜6.19.12）に存在する権限昇格の脆弱性で、CVSSスコア7.8。732バイトのPythonスクリプトで再現でき、レース条件に依存しないため確実に成功する。Ubuntu 24.04 LTSも当然影響を受けていた。

つまり、Canonicalがセキュリティパッチを配信しなければならない最も切迫した瞬間に、配信インフラそのものが攻撃で停止していたことになる。security.ubuntu.comはaptミラーと違ってミラー数が限定的なため、CVE通知や緊急パッチの取得は他のサブドメインより影響を受けやすい構造だった。

5月4日にはCISA（米サイバーセキュリティ・インフラセキュリティ庁）がCopyFailをKEV（Known Exploited Vulnerabilities）カタログに追加し、米連邦民間機関に5月15日までの対処を命令した。連邦機関のシステム管理者は、Canonicalのインフラが断続的に応答しない中でパッチを取得しなければならなかった。

PC Perspectiveが指摘した皮肉な構造は、終結した今になってより鮮明に見える。攻撃者の意図がCopyFailパッチ配信の妨害だったかどうかは分からない。だが、結果として「Linuxの権限昇格を防ぐパッチ」と「そのパッチを配るインフラへの攻撃」が同時進行する状況が6日間続いた。これは偶然の重なりとして片付けるには重すぎる。

露呈したのは構造的な脆弱性だった

Tom's Hardwareの読者コメント欄で繰り返された「なぜCloudflareを使っていないのか」という疑問は、6日間の沈黙のあいだ宙に浮いたままだった。終結した今、その問いはより重く跳ね返ってきている。

Cloudflareの2025年Q4 DDoSレポートでは、過去最大規模の攻撃が記録され続けている。同社は2025年Q4に31.4Tbpsの攻撃を観測しており、過去最大記録を塗り替え続けている状況だ。313 Teamが使ったとされるBeamedというDDoS-for-hire（DDoS請負）サービスは3.5Tbpsの攻撃帯域を主張していた。世界記録の10分の1に満たない規模でも、商用CDN無しの企業インフラを6日間止めるには十分だった。自社インフラだけで耐え抜くという選択は、2026年の脅威環境では事実上不可能になっている。

それでもCanonicalがCloudflareのような前段防御を採用してこなかった理由は、推測するしかない。オープンソースインフラのルーティングをCDN事業者に握らせることへのイデオロギー的な抵抗、コスト構造、エンドポイントの多様性。どれも一定の説得力はある。だが、6日間のダウンタイムが企業ユーザーに与えた実害と、Canonicalのブランドが受けた損傷を考えると、その判断のコスト計算は今後見直されるはずだ。

313 Teamの過去の標的を辿ると、サウジAbsher（2023年12月）、Truth Social（2025年6月）、クウェート政府26ドメイン（2026年2月）、GCC協調作戦（2026年3月）、Bluesky（2026年4月15日）、mastodon.social、eBay日本／米国と続き、Canonicalは主要オープンソースインフラを狙った初の事例となった。「次の標的」がどこになるかは分からないが、攻撃側が「オープンソース基盤を6日間止められる」という実証データを得てしまったことは確かだ。

日本ユーザーの実害は限定的だったが、無傷ではなかった

日本のUbuntuユーザーが直面した状況は、英語圏よりは緩やかだった。aptミラーが日本国内に複数稼働しており、攻撃を受けたのは英国のオリジンサーバーだったためだ。jp.archive.ubuntu.comまたはICSCoE（産業サイバーセキュリティセンター）が秋葉原UDXで運用するftp.udx.icscoe.jp（100Gbps帯域）に切り替えれば、英国オリジンが沈黙してもaptは普段通り動いた。Ubuntuのミラー分散モデルが、地理的・地政学的攻撃に対する結果的なクッションとして機能した形になる。

ただし、Ubuntu Pro／ESMの契約ユーザーは無傷ではなかった。pro attachの失敗、esm.ubuntu.comへの断続的な到達不能、CVE通知APIの沈黙は、自動化されたパッチ管理パイプラインを直撃する。連休中で対応人員が薄かった日本企業のシステム管理者にとっては、「Linuxの権限昇格脆弱性が公開された直後にCanonicalが応答しない」という状況自体がリスクだった。

apt updateが失敗した日本ユーザーが取るべき対処は、現時点ではほぼ不要になっている。Canonicalステータスページが全コンポーネント正常に戻っており、security.ubuntu.comも応答する。だが、CopyFailのパッチを当てていない環境があるなら、今こそ最優先で適用すべきだ。apt update && apt upgradeを実行し、再起動でカーネルを切り替える。それで終わる。

6日間で何が変わったのか

攻撃は終わった。Canonicalは恐喝を拒んだ。サービスは戻った。教科書的には、これは「正しい対応の勝利」として記録される。

だが、終結した今だからこそ見える事実もある。3.5Tbpsを名乗るDDoS-for-hireサービスを買った匿名のグループが、Linuxエコシステムの中央ハブを6日間揺さぶり続けることができた。Canonicalは耐え抜いたが、攻撃側もコストをほぼ払っていない。Beamedのような商用攻撃インフラは、月額数百ドル程度から借りられる。攻撃者にとって6日間の継続は、車1台分のコストすら超えない可能性がある。

これは、Canonicalひとつの問題では終わらない。Debian、Fedora、SUSE、Arch──オープンソースインフラの大半は、同じ「商用CDN無し・自社耐性のみ」のモデルで運用されている。次の標的が決まれば、同じ6日間が別の場所で繰り返される。

恐喝に応じない判断は正しい。だが、その正しさをユーザーが肩代わりしなくて済む構造を作る責任は、最終的には基盤を運営する側に戻ってくる。Canonicalがこの6日間から何を学ぶか。Cloudflareの導入なのか、自前のスクラビングセンター強化なのか、torrentベースの配信モデルへの分散化なのか。答えは6月以降のCanonical公式ブログに出てくるはずだ。

世界中の管理者が、その続報を待っている。

参照元

• Canonical and Ubuntu Status
• Canonical (@Canonical) on X - 緩和措置を実装し復旧完了

関連記事

• CanonicalへのDDoS、丸5日経ってもまだ終わらない
• DDoSは続いている、Canonicalはトラフィックを絞り始めた
• UbuntuサーバーDDoS続報、Canonicalが認め攻撃者は恐喝へ
• Ubuntu主要サーバーが停止、親イラン集団が犯行を主張
• Copy Fail続報、パッチなき開示で世界が混乱
• Ubuntu 26.04、完全Rust化先送り44件のCVE
• Ubuntu 26.10が目指す「文脈を理解するデスクトップ」の全容
• systemd 261 RC1、OSインストーラーとクラウド対応を強化
• Fragnesia公開、Linux LPE 2週で3件目
• FedoraとUbuntu、ともにAI機能導入へ