DDoSは続いている、Canonicalはトラフィックを絞り始めた
ubuntu.comは戻った。だがlaunchpad.netはなお攻撃下にあり、Canonicalは「DoS中にトラフィックを厳しく制限する」防御モードに切り替わった。
「終わった」ではなく「絞っている」
ステータスページが、ある重要な事実を明かしている。日本時間5月3日 08:52、launchpad.netとppa.launchpad.netが「Custom maintenance」のステータスに入った。
そこに添えられた説明は短く、しかし決定的だ。
severely restricting traffic to launchpad during DoS. Alert override（DoS中にlaunchpadへのトラフィックを厳しく制限している。アラートを上書き）
Canonicalが、攻撃継続中であることを認めながら、アラートを意図的に黙らせている状態だ。これは防御策の一環であって、復旧ではない。
「Major Outage」ではなく「Custom maintenance」になっている理由はここにある。本当に落ちているわけではない。ただ、Canonicalが攻撃トラフィックと正規トラフィックを分離するために、入口の蛇口を絞っている。結果として、開発者がaptでパッケージを引きにくる、Snap StoreでSnapをインストールしにくる、CIパイプラインがビルドを試みる——そうした正規アクセスも、いまは届きにくい状態にある。
過去48時間の波状攻撃の記録
ステータスページのインシデント履歴を時系列で並べると、攻撃が断続的に再開を繰り返していた様子が見える。
5月2日の昼に「Component Livepatch API and a few other components are Down」として記録されたインシデントは、6時間26分続いた。影響範囲は gopkg.in、lists.ubuntu.com、ppa.launchpad.net、Livepatch API、canonical.com、login.ubuntu.com、maas.io、launchpad.net、blog.ubuntu.com、developer.ubuntu.com、その他3コンポーネント。一気に11以上のサービスが同時にダウンした最大規模の波だった。
その後も小刻みに連鎖が続く。19:23-19:34に assets.ubuntu.com が11分間ダウン、18:44-19:23に ppa.launchpad.net が39分間ダウン、19:27からは ppa.launchpad.net が再びダウンし、これは翌日朝の02:08まで6時間40分続いた。
5月3日に入ってからも止まっていない。02:11-02:34に ppa.launchpad.net、03:14-08:12に ppa.launchpad.net + launchpad.net、そして08:31までの間 assets.ubuntu.com も9分間落ちた。
「攻撃は4時間続く」と最初に宣言した313 Teamのメッセージは、もはや事実と無関係になっている。事態は完全に別の段階に入った。
過去90日のCanonical障害は「中央値59分」だった
このスケールを正しく感じるには、平時のCanonicalがどんな数字だったかを思い出す必要がある。
外部の稼働監視サービスIsDownの集計によれば、Canonicalは過去90日で92件のインシデントが記録されている。中央値は23分。1時間も経たずに片付くのが平時の姿だった。それが今回は、4時間・6時間・40時間という単位で長引いている。
ステータスページの「コンポーネントステータス履歴」では、影響をもっとも色濃く受けたサービスのアップタイムが具体的に下がっている。launchpad.netは過去7日で80.82%、ppa.launchpad.netは79.34%、ubuntu.comは80.93%、blog.ubuntu.comは80.78%、developer.ubuntu.comは80.28%。通常99%超だったサービスが、週次80%前後まで沈んだ。
100%のうち20%が落ちる。直感的には小さく見えるが、可用性99.9%を約束する商用サービスの世界で、80%という数字は事故ではなく事件だ。
Copy Failの修正配布期と完全に重なっている
ここでもう一度、別の文脈を重ねたい。
Ubuntu公式が4月30日に公開したCopy Fail対応ブログが示す影響範囲は、Resolute(26.04)を除く全Ubuntuバージョンだ。Trusty 14.04からQuesting 25.10まで、いま稼働している実質ほぼ全ての本番Ubuntuサーバーが、root権限を奪取できる脆弱性にさらされている。
Copy Failは、暗号化処理の入口にあたるカーネルモジュール(algif_aead)の論理欠陥だ。732バイトのPythonスクリプトで、サーバーに一般ユーザーとしてログインできる相手が管理者権限を取れる。家の中に入れる人なら誰でも、家主の鍵束まで持ち出せる構造だ。これを塞ぐには、kmodパッケージで該当モジュールを無効化する暫定策、続いて修正カーネルへの更新が必要だ。
問題は、その配布インフラのコアにあたる Livepatch API、Canonical SSO(login.ubuntu.com)、Ubuntu Pro契約管理(portal.canonical.com)、Snap Storeのバックエンド(launchpad.net)が、いずれも今回の攻撃で繰り返し落ちていることだ。apt updateで公開パッケージを取りに行く経路はミラー分散のおかげで生きていた。だが、企業向けの自動パッチ運用を支える集中APIは、止まったり戻ったりを繰り返している。
世界中の管理者がCopy Failを塞ぐ作業をしている、まさにそのタイミングで、対応経路の一部が繰り返し叩かれている。これはローカル権限昇格、つまりサーバーにすでに入れる相手が管理者になれる脆弱性だ。共用サーバーや、外部からスクリプトを実行できる構成の現場ほど、修正の遅れが致命傷に近づく。
Canonicalは「制限する」を選んだ
「アラートを上書きしてDoS中のトラフィックを絞る」という今朝の判断には、Canonicalがこの攻撃をどう見ているかが滲む。
DDoS対応で「すべてを通す」を選び続ければ、いつか帯域が飽和する。「すべてを止める」を選べば、正規ユーザーへの被害が最大化する。Canonicalが選んだのは、その中間にあたる「意図的なスロットリング」、つまり蛇口を絞って様子を見る選択だ。
これは攻撃側との消耗戦に入ったシグナルでもある。Cloudflareのような商用CDNを前段に置いていない以上、自前のインフラで殴り合うしかない。「絞る」というのは、自前で持ちこたえるための時間稼ぎだ。攻撃が止むのが先か、Canonicalのリソースが先に切れるか、その勝負がいま続いている。
Canonicalが恐喝に応じる線は引かれていない。だが応じないなら、こうやって絞り続けるしかない。それが今の景色だ。
残された選択肢
5月1日にThe Registerが報じた313 Teamの恐喝メッセージ——「連絡してこなければ攻撃を続ける」——への反応は、Canonical側からも攻撃側からも、表向きには見えてこない。
Canonicalは沈黙している。Ubuntu Community Hubの告知は5月1日の文面のままで、新しい広報コメントは出ていない。313 Team側のTelegramチャンネルでも、恐喝後の追加メッセージや次の標的の予告は確認できていない。
ただ、攻撃が続いているという事実だけが、消されない形でステータスページに刻まれ続けている。Canonicalが交渉を拒否したからこそ、攻撃は止まらない。313 Teamが沈黙しているのは、止め方を見つけられていないからかもしれない。あるいは、止める気がないからかもしれない。どちらにしても、Canonical側に残された選択肢が見えない。
オープンソースの「集中点」が叩かれ続けている
Arch Linuxは2025年8月にDDoS被害を受けた。Ubuntu/Canonicalは2026年4月末から少なくとも5月3日まで攻撃を受け続けている。期間も影響範囲も、Arch Linuxのときとは桁が違う。
オープンソースは分散している、というのは半分しか正しくない。コードはGitHubに散らばっているし、配布はミラーに分散している。だが、「公式の権威」を担うAPI、認証サーバー、契約ポータル、CVE通知、Livepatchの配布元は、どれも一極集中の構造のままだ。攻撃者は、その分散しきれない一点を見つけ出して、繰り返し叩いている。
Canonicalが今朝とった「絞る」という対応は、このアーキテクチャの限界に対する応急処置だ。根本的な解決ではない。次にUbuntuが、あるいは別のディストリビューションが同じ立場に置かれたとき、同じ手で防げる保証はない。
ubuntu.comは表向き戻った。launchpad.netは絞られている。Copy Failのパッチは、その絞られた経路を抜けて、これから世界に届かなければならない。
参照元
他参照
