Ubuntu

CanonicalへのDDoS、丸5日経ってもまだ終わらない

情報の灯台

2026年5月6日 00:5800

連休前夜から始まったCanonicalへの大規模DDoSは、現地時間5月5日の現在も終結していない。「まだつながらない」という日本ユーザーの感覚は気のせいではなく、攻撃そのものが波のように戻ってきている事実を反映していた。

攻撃は終わっていなかった

英語圏のテック媒体は5月4日付けで「全サービス復旧」と書いた。しかし、Canonical公式ステータスページを15分間隔で観測しているStatusGatorのログには、もっと正直な数字が残っている。

2026年5月のCanonicalダウンタイム（StatusGator観測）

5月1日：19時間18分／5月2日：44分／5月3日：メンテナンス2時間59分とダウン20時間58分／5月4日：10時間13分／5月5日：11時間6分（本記事執筆中も継続中）

5月2日にいったん収束したように見え、楽観的な復旧宣言が各媒体で出た。だが5月3日に再び20時間超のダウンが記録され、5月4日も10時間以上、そして本日5月5日も11時間を超える停止が続いている。

5月5日午前9:05（UTC）開始のインシデントは執筆時点で3時間24分継続中、別系統では午前3:50開始の5時間15分のダウンも記録されている。攻撃が止んだのではない。Canonicalが防御を当てるたびに、攻撃側が手法を変えて戻ってきている。

ユーザー実感がインフラの真実を語っている

StatusGatorのCanonicalページに本日寄せられている報告は、現状を生々しく示している。

英国のあるユーザーは午後1:49にこう書いた。185.125.190.[24,31,32,75,77]の各IPがTLSハンドシェイクを落とし続けており、pro attachは100%失敗する。contracts.canonical.comのDNSがそれらのIPしか返さないからだ。esm.ubuntu.comも約50%失敗する。動いているIPは91.189.91.0/24にある──。問題の正体を言い当てた診断だ。

カルナータカ州（インド）のユーザーは「6時間つながらない」と書き、英国とイタリアからは複数の「Service down」報告が並ぶ。地理的に分散したユーザーが同じ症状を訴えているということは、ローカルなネットワーク不調ではなく、Canonical側のIP群への到達性そのものが不安定だと見ていい。

ユーザー報告から見える攻撃の特徴

一部IP（185.125.190帯）でTLSハンドシェイクが落ち続け、別IP帯（91.189.91帯）は健全──攻撃側が特定のサーバーセットを集中的に狙い、Canonicalがそれを切り離そうとしているように見える。

5月4日の「復旧宣言」は何だったのか

OMG! Ubuntuは記事の追記で「5月4日時点でインシデントは解決、全サービス稼働中。ただしLaunchpad（PPA経由のapt含む）は不安定」と書いた。FastNetMonも同日「Canonicalステータスページに『全システム稼働中』と表示されている」と報じている。これらは嘘ではない。そのタイミングではいったん緑表示になっていた。

問題はその後だ。Canonicalステータスページは、StatusGatorの観測によれば1日のうち何度もup/downを行き来している。「復旧宣言」を見出しで打った媒体の多くは、その瞬間のスナップショットを切り取って終わっていた。実態は応酬がまだ進行中の状態であり、執筆時点でも完全に決着していない。

5月3日深夜（UTC）にUbuntu DiscourseでユーザーtheofficialgmanがLaunchpadはダウンしているのにステータスページでは終日「up」と表示されていると指摘した投稿は、こうした表示と実態の乖離を当事者の側から突いたものだった。彼は丁寧に書いた。Launchpadがダウンしていると分かっているなら、apt updateを連打してサーバー負荷を上げるよりステータスサイトに正確な情報を出してほしい──。

インシデント対応の透明性そのものに関わる指摘だ。ステータスが緑なのに繋がらないとき、ユーザーは自分側の障害を疑い、無駄なリトライでサーバーへの負荷を増やす。それは攻撃側に塩を送る結果になる。

日本ユーザーへの実害は限定的だが、ゼロではない

日本のUbuntuユーザーが直面した状況は、英語圏とは少し違う色合いがある。aptミラーは日本国内に複数稼働しており、攻撃を受けたのは英国のオリジンサーバーだったためだ。

note上で5月3日21時35分に公開されたzephel01の解説記事では、応急処置としてjp.archive.ubuntu.comまたはftp.udx.icscoe.jpへの切り替え手順がまとめられている。執筆時点で日本ユーザーが直面していた苦境がうかがえる文面で、現在も基本的には有効な対処法だ。

ICSCoE（産業サイバーセキュリティセンター）が秋葉原UDXで運用するミラーは100Gbpsの帯域を持ち、英国オリジンが沈黙しても日本国内ではaptが普段通り動く環境を作れる。Ubuntuのミラー分散モデルが、地理的・地政学的攻撃に対する結果的なクッションとして機能した。

ただし、security.ubuntu.comはミラー数が限定的なため、CVE通知や緊急セキュリティパッチの取得は影響を受けやすい。CopyFail（CVE-2026-31431）というLinuxカーネルの権限昇格脆弱性が直前に公開されていたタイミングで、セキュリティAPIが沈黙する事態は実害として無視できない大きさを持っていた。pro attachやesm.ubuntu.comの問題は、Ubuntu ProやESM（Expanded Security Maintenance）契約を使っている企業ユーザーには特に痛い。

攻撃の正体と恐喝への転換

攻撃を主張した313 Team──正式名「The Islamic Cyber Resistance in Iraq」──については、これまで断片的だった素性が補強された。

過去の攻撃対象を辿ると、サウジアラビアのAbsherプラットフォーム（2023年12月）、Truth Social（2025年6月）、Bluesky（2026年4月15日）と続き、Canonicalは主要オープンソースインフラを狙った初の事例となる。グループ名はナージー・アル＝アリーが1969年に生み出したパレスチナの政治風刺画キャラクター「ハンダラ」のモチーフと結び付いた象徴的なもので、初確認は2023年12月、ガザ紛争開始直後だった。HawkEyeの脅威アドバイザリは2026年3月時点で、イラン情報省（MOIS）との繋がりを評価している。

そして注目されたのは恐喝への舵切りだ。Telegramチャンネル経由で送られた脅迫文はこう書かれていた。

簡単な解決策がある。我々のSession連絡IDをメールで送った。応じなければ攻撃を続ける。お前たちは厳しい立場にある、馬鹿な真似はするな。

ハクティビズムから純粋な恐喝へという変質を示すメッセージだ。Sessionはメタデータを最小化するメッセンジャーで、身代金交渉でよく使われる。具体的な金額は明示されておらず、Canonicalは要求への対応について公に何も語っていない。

そして本日5月5日も攻撃が続いているということは、Canonicalが交渉に応じない選択肢を貫いている可能性が高い。教科書的に正しい対応だが、その代償として6日目のダウンタイムが積み上がっている。

CopyFailとのタイミングの重なり

この攻撃をめぐって最も議論されているのが、LinuxカーネルのCopyFail開示と同時期だったことの意味だ。CopyFailは2017年以降のほぼ全Linuxディストリビューションに影響する権限昇格の脆弱性で、攻撃直前にUbuntuが緊急パッチ配信を始めようとしていた。

PC Perspectiveが指摘したのは皮肉な構造だ。パッチ配信のためのインフラがDDoSで停止したため、CopyFailの修正取得が困難になった──攻撃者の意図かどうかは分からないが、CVE通知とパッチ配信が同時に止まる状況は、通常のサービス障害よりも深い穴を開ける。

Tom's Hardwareの読者コメント欄では「なぜCloudflareを使っていないのか」という素朴な疑問が繰り返された。Cloudflareの2025年第4四半期DDoSレポートでは、過去最大規模の攻撃が記録され続けており、自社で耐え抜く選択は今や難しい。5日経ってもまだ終わらない現状は、その判断の代償をリアルタイムで証明している。

5日になった今、どう対処すべきか

本記事執筆時点で、archive.ubuntu.com、assets.ubuntu.com、security.ubuntu.comの3コンポーネントがStatusGatorで「down」と表示されている。launchpad.net、ppa.launchpad.net、canonical.com本体は「up」だ。状況は刻々と変わるので、自分の環境で何かが繋がらないなら、まずstatus.canonical.comを確認するのが早い。

つながらないときの対処は3つに絞れる。

第一に、日本ユーザーであれば国内ミラーへの切り替えが一番効く。jp.archive.ubuntu.comまたはftp.udx.icscoe.jpに向けるだけで、英国オリジンの不安定さからは独立できる。

第二に、apt updateが「Hash Sum mismatch」を出す場合はsudo apt clean && sudo apt updateでキャッシュをクリアする。ミラー同期の途中で取得した不完全なファイルが原因のことが多い。

第三に、Ubuntu Pro / ESMのpro attachが失敗している場合、それはcontracts.canonical.comのDNS応答が現在攻撃を受けているIP帯（185.125.190帯）を返してしまっているからだ。Canonical側の復旧待ちしか選択肢がない。

攻撃はまだ終わっていない。終わるまで何日かかるのか、Canonicalがどこで決着をつけるのか、現時点では分からない。確かなのはひとつだけだ。Linuxエコシステムの中央ハブが、3.5Tbpsのbooterサービスにここまで揺さぶられている──その光景を、本日も世界中の管理者が眺め続けている。

参照元