誰か、CloudflareがCanonicalを脅迫したのか説明してくれないか？
(flyingpenguin.com)- Canonical の公開Webサービスは2026年4月30日16:33 UTCから約20時間停止し、Ubuntuリポジトリのエンドポイントも遅れて障害に入った
- 攻撃の犯行声明を出した親イラン系グループは、有料DDoSサービス Beamed を使ったと述べており、BeamedはCloudflare回避と住宅用IPローテーションを宣伝している
- Beamed のドメインと関連する登録・ルーティング基盤は、Cloudflare AS13335、Immaterialism、AS39287、Materialism s.r.l. の記録へとつながる
- AS39287の再割り当て と、Canonicalの archive.ubuntu.com・security.ubuntu.com の apex 証明書更新は、2026年2月27日の同じ24時間内に発生した
- Canonicalは攻撃中、security.ubuntu.com と archive.ubuntu.com だけをCloudflareへ移し、公開記録上では身代金ではなく有料サブスクリプションが移動した構図になっている
Canonical障害とCloudflare移行
- 2026年4月30日 16:33:37 UTC、Canonicalの監視システムは blog.ubuntu.com を Service Down と表示し、約10分以内に ubuntu.com、セキュリティ勧告API、開発者ポータル、企業サイト、教育プラットフォームなどの公開Webサービスも一緒に停止した
- 障害は 約20時間 続き、2026年5月1日12:44 UTCに Service Restored と記録された
- 犯行声明を出したグループは、自らを Islamic Cyber Resistance in Iraq または 313 Team と名乗る親イラン系グループで、有料サービスを利用したと明かした
- 攻撃ツールとして名指しされた Beamed は、複数のTLDで販売される商用のサービス拒否製品で、beamed.su はマーケティング・ブログサイト、beamed.st は顧客ログインポータルとして使われている
- Beamedの2026年4月のブログ記事は「Cloudflare回避」を宣伝し、住宅用IPローテーション と手動の「endpoint hunting」によってオリジンサーバーを見つける方法を含む3つの手法を掲げている
- 攻撃から1週間後も beamed.su と beamed.st はオンラインのままで、どちらも Cloudflare AS13335 のアドレスに解決された
- Canonicalの2つのリポジトリエンドポイントである security.ubuntu.com と archive.ubuntu.com も、その後 Cloudflare AS13335 のアドレスを使うようになった
Beamedと登録・ルーティング基盤
- Beamed の消費者向けドメインは Immaterialism Limited というレジストラを通じて登録されており、このレジストラは定額料金とJSON APIベースのドメイン登録を販売している
- Immateriali.sm は Cloudflareのネームサーバー である tani.ns.cloudflare.com と trey.ns.cloudflare.com を通じてプロキシされている
- Immaterialism Limited は英国 Companies House に 会社番号 15738452 で登録されており、2024年5月24日に設立された
- 設立時の取締役はコスタリカの Nicole Priscila Fernandez Chaves で、ロンドン Great Portland Street の大量郵便受け住所を使っていた
- 2025年4月11日、Fernandez Chaves は取締役を退任したが、75%超の経済的利害関係 は維持し、同じ住所で英国居住者の Naomi Susan Colvin が後任取締役に任命された
2026年2月27日のAS39287再割り当て
- 2026年2月26日、Immaterialism Limited は Companies House に同日付で2つの変更を提出した
- 登録事務所を 85 Great Portland Street から 167-169 Great Portland Street へ変更した
- Fernandez Chaves の person with significant control の詳細を変更した
- 翌日の2026年2月27日、Beamedと関連サービスのIP空間を告知する ルーティング基盤 が管轄を移した
- Materialismのアドレス空間を告知する自律システムは AS39287 で、RIPEは2006年1月24日にこのAS番号を割り当てた
- AS39287のルーティング上の同一性は維持されたが、登録上の運用者と国の記録は2度変わった
-
Privactually LtdとFLATTR-ASの時代
- 2017年ごろから2020年ごろまで、AS39287はキプロス企業 Privactually Ltd が保有し、FLATTR-AS という名前で運用されていた
- Flattrは、The Pirate Bayの共同創業者の1人 Peter Sunde Kolmosoppi のマイクロペイメントプロジェクトにつながる
- その登録の下でプレフィックスの abuse 連絡先は abuse@shelter.st だった
-
ab stract ltdの時代
- 2020年から2026年まで、同じAS番号はヘルシンキ Urho Kekkosen katu 4-6E に所在するフィンランド企業 ab stract ltd に再割り当てされていた
- RIPE記録の maintainer オブジェクトは BKP-MNT で、記録上の人物は The Pirate Bay のもう1人の創業者 Peter Kolmisoppi だった
- 運用者ドメイン abstract.fi の権威ネームサーバーは njalla.fo、njalla.no、njalla.in の3つのNjallaネームサーバーだった
- Njalla は Peter Sunde が作った privacy-as-a-service のドメインプロキシで、セントクリストファー・ネイビスの 1337 Services LLC を通じて運営されている
-
Materialism s.r.l.への再割り当て
- 2026年2月27日 12:11:48 UTC、RIPEは3回目の再割り当てを記録し、AS39287 はルーマニア・ブカレスト Bulevardul Metalurgiei に所在する Materialism s.r.l. の所有となった
- 再割り当てには 45.158.116.0/22、2001:67c:2354::/48、2a02:6f8::/32 が含まれ、最後のIPv6プレフィックスは前体制のもとで2008年8月に初めて割り当てられていた
- 3回の移行期間を通じてピアリング設定は維持され、AS39287は AS42708(Telia)、AS37560(GTT)、AS12552(GlobalConnect)、AS34244(Voxility)、AS54990 と同じ構成で import/export を続けた
- 同じ経路が同じアップストリームネットワークへ出ており、公開記録で変わったのは見かけ上の運用者名だけだった
- IANAの公認ドメインレジストラ一覧には、Immateriali.sm の顧客基盤に Njalla の背後にいる取引法人 1337 Services LLC が含まれている
同日に発生したCanonical証明書ローテーション
- Canonicalのリポジトリエンドポイントの証明書透明性記録には、ルーティング再割り当てが起きた同じ 24時間のウィンドウ の中で複数の項目が現れる
- 2026年2月27日 06:14:03 UTC、Let’s Encrypt が archive.ubuntu.com の新しい apex 証明書を発行した
- 同日 19:13:35 UTC、Let’s Encrypt が security.ubuntu.com の新しい apex 証明書を発行した
- security.ubuntu.com の2026年の証明書透明性記録では、この項目以前は地域ミラー証明書しかなく、可視ログにはそれ以前の apex 証明書 は現れない
- 同日 22:14:03 UTC、clouds.archive.ubuntu.com の新しい証明書が発行された
- その後9日間、同じパターンが azure.archive.ubuntu.com、wildcard-gce.archive.ubuntu.com、wildcard-ec2.archive.ubuntu.com で繰り返された
- それぞれの新しい証明書は地域ミラーではなく、apex ホスト名 に発行された
- apex ホスト名の有効なオリジン証明書は、そのホスト名をコンテンツ配信ネットワークの背後に置くための前提条件として扱われる
- 2026年2月27日に起きたルーティング再割り当てとCanonicalの証明書ローテーションの同時性は、公開記録だけでは説明されない
攻撃タイムライン
- タイムラインは Canonical の status.canonical.com ページにあった分単位の障害ログに基づいており、4月30日ごろ22:52 UTCに Ubuntu Discourse thread 81470 にスナップショットとして残された記録である
-
最初の10分: 公開Web全体の障害
- 16:33:37: blog.ubuntu.com が最初に Down と表示され、Incident Start Time として記録された
- 16:34:10: canonical.com Down
- 16:34:45: academy.canonical.com Down
- 16:35:15: developer.ubuntu.com Down
- 16:35:22: maas.io Down
- 16:36:09: jaas.ai Down、Ubuntu Security API(CVEs) Down
- 16:37:13: Ubuntu Security API(Notices) Down
- 16:41:57: assets.ubuntu.com Down
- 16:43:25: ubuntu.com Down
- セキュリティ勧告フィードは開始後 3分以内 に落ち、マーケティング apex は10分以内に落ちた
- この時点でまだ攻撃されていなかったホストは security.ubuntu.com と archive.ubuntu.com で、これら2つのエンドポイントはすべてのUbuntuインストールで
apt updateの失敗を引き起こしうるリポジトリエンドポイントだった
-
3時間後のリポジトリエンドポイント攻撃
- 19:34:38: security.ubuntu.com が最初に Down と表示された
- 19:40:01: archive.ubuntu.com Down
- リポジトリエンドポイントは攻撃開始から 約3時間後 に障害へ入った
- 19:40 UTCから次の70分間、2つのリポジトリエンドポイントはステータスボード上で Down と Operational を繰り返した
- ステータスログには、その期間中 security.ubuntu.com の Down/Operational 切り替えが5回、archive.ubuntu.com の切り替えが4回記録されている
- このパターンは、オリジン側でレート制限、地域フィルタ、トラフィックスクラビングのような緩和を試みたが、公表された 3.5 Tbps 規模の持続負荷の下で失敗した様子と符合する
-
20:50 UTC以降の安定化
- 20:50:29: archive.ubuntu.com Operational
- 20:51:13: security.ubuntu.com Operational
- この 44秒間隔 の後、22:52 UTCまで続くキャプチャスナップショットでは、2つのホストは再び Down として現れない
- フラッピングは止まり、2つのエンドポイントは攻撃開始から 4時間17分 の時点で1分未満の間隔で同時に安定化した
- security.ubuntu.com と archive.ubuntu.com は執筆時点で 104.20.28.246 と 172.66.152.176 に解決され、これらのアドレスは Cloudflare が AS13335 で運用するアドレスである
- その他の影響を受けたホストである ubuntu.com、canonical.com、launchpad.net、snapcraft.io、login.ubuntu.com は、依然として Canonical の AS41231 空間である 185.125.189.x と 185.125.190.x に解決される
- ubuntu.com の権威ネームサーバーは依然として ns1.canonical.com、ns2.canonical.com、ns3.canonical.com である
選択的なCloudflare移行
- Canonical は、攻撃者がリポジトリ停止のために狙った security.ubuntu.com と archive.ubuntu.com の2つのAレコードだけをCloudflareへ渡した
- 残りのサービスはCanonicalの自前インフラに残り、既存の緩和策の下で攻撃に耐えた
- リポジトリ以外のホストはスナップショットの終端までフラッピングを続け、その後はアップストリームフィルタリングと攻撃緩和または停止の組み合わせで復旧した
- Canonical の最初の公式な公表は5月1日 07:13 UTCに投稿され、これはリポジトリエンドポイントが Cloudflareの背後で安定化してから10時間後 だった
- すべてのコンポーネントの完全復旧は5月1日 12:44 UTCに確認され、攻撃開始から 約20時間後 だった
「脅迫」かどうかを巡る構図
- 公開に確認できる経路では 身代金の支払い は動いていない
- その規模の暗号資産の流れも公開記録には現れない
- 要求書も公開されておらず、交渉があったとしても非公開で進んだ可能性が高い
- 公開記録上で動いたのは 有料サブスクリプション である
- Canonical の最も価値の高い2つのエンドポイント、すなわち自動セキュリティ更新の世界的失敗を引き起こしうるリポジトリエンドポイントが、Cloudflareとのサービス関係へと移行した
- 同時にCloudflareの他の現行顧客には、Canonicalを攻撃していた booter運営体 が含まれている
- Beamed が引き続き雇える状態にあり、Canonicalインフラの障害時間が締め切りのように機能したことで、別個の公開要求がなくても取引が成立した構図として解釈される
- 防御側は両側から収益を得ながらも、その都度コンテンツ中立で利用規約の文言内にとどまる形になる
競馬通信網独占との比較
- 1930年代、Moses Annenberg の General News Bureau は、全米の bookmaker に競馬場の結果を迅速に販売していた
- 購読した bookmaker は生き残り、購読しなかった bookmaker は、購読した競合のせいでオッズ設定能力を失ったという比較が付される
- Annenberg の収益は競馬結果の検証に対する 独占 に依存し、この独占によって非公式 bookmaker は営業のために彼の wire に依存するようになった
- 連邦政府は1939年の 税務起訴 によってこの独占を崩し、その後の wire service も1940年代まで摘発された
- 1942年の Mayor LaGuardia 関連報道 には、ニューヨーク、ニュージャージー、Westchester、Nassau County の競馬賭博業者と poolroom bookmaker 向けの「年100万ドルの wire service」摘発で9人が逮捕されたとある
- 今日の DDoS防御市場 は、booter市場との関係において似た位置にあるという批判につながる
- Cloudflare の収益は、公開インターネット上でサービスが到達可能かどうかを検証する位置に依存しており、同じ企業が booter のホスティング提供者でもあるとき、脅威と保護の役割が1つの収益フローに統合される
公開記録に残った痕跡
- この事件の痕跡は複数のレジストリと企業開示に分散して残っている
- Companies House には企業書類があり、RIPEデータベース にはルーティング再割り当てがあり、証明書透明性ログには apex 証明書ローテーションの日付があり、Canonical のステータスページにはレコードが変わった時刻が残っている
- 2026年2月27日には3つの準備が同じカレンダー上のウィンドウで完了した
- Materialism s.r.l. が AS39287 とそれに付随する古いIPv6プレフィックスの所有権を取得した
- Immaterialism Limited が Companies House 書類を提出した
- Canonical 側では、後にコンテンツ配信ネットワークの背後へ移される2つの apex ホスト名がオリジン証明書を更新した
- 攻撃開始から Canonical のリポジトリホスト名にCloudflareアドレスが現れるまでの 4時間の間隔 は、購買判断が動いた区間として解釈される
- 2026年4月30日 20:50:29 UTCに、新しい顧客関係が公開的に見えるようになった
1件のコメント
Hacker Newsのコメント
私の理解では、Cloudflareから攻撃能力を借りるという表現は不正確です。
その集団がCloudflareの背後でサイトをホストしていたのは事実ですが、Cloudflareのインフラが攻撃に使われたと主張しているのは見たことがありません。
記事全体として、攻撃者が運営する案内サイトをホストすることと、攻撃そのものをホストすることを混同しているように見えます。
ウェブサイトであれ制御インフラであれ、すべて攻撃対象でした。
DDoS防御はAkamaiのような会社が提供していて、価格は要問い合わせ、大企業向けで、匿名での加入は絶対にできませんでした。
CloudflareはDDoS-for-hireサービスまで含めて誰にでも無料のDDoS防御を提供し、業界を変えました。互いをオフラインに追い込めなくなると、DDoS産業は本格的に成長できるようになりました。
プロキシされたトラフィックだからというだけでもなさそうで、少なくとも
CF-Connecting-Ipヘッダーはありません。この攻撃に使われたかは分かりませんが、一部の攻撃には使われています。
ただしCloudflareは、依然としてほとんどの他のインフラ提供者よりはるかに迷惑度が低いです。
論理としてもあまり成立しているようには思えません。
AWSにホストされたコマンド＆コントロールサーバーも多いですし、AWSの被害者も多いですが、だからといってAWSが責任を負うとか脅迫しているとまでは言いにくく、答えはたいていノーだと思います。
誰でも、Cloudflareのホスティングサービスを使うべきではないと思うサイトをいくつか挙げられるでしょう。
問題は、そのリストが人によって違うことです。
Cloudflareは、合法的な命令を受けるまでは何でもホストすべきです。
何らかの曖昧な基準でサイト内容が「適切か」を判断し始めたら、人々が正当に強く怒るのは確実です。
Cloudflareから攻撃能力を借りるという主張には根拠が必要で、私の知る限り攻撃者は実際の攻撃にCloudflareのインフラを使っていません。
この記事全体の空気感とGoogle関連の記事での空気感があまりに違っていて、かなり戸惑います。
Cloudflareが悪意ある行為者かどうかは断言できませんが、誰もがそうである可能性を前提に振る舞うべきだと思います。
宣伝されているサービスがCloudflareを明示的に攻撃するとしているなら、まともな規約であれば当然違反でしょう。
実際、Cloudflareの規約にもそう書かれています。
https://www.cloudflare.com/en-ca/website-terms/
「7. PROHIBITED USES」には、CloudflareのサーバーやAPI、接続されたネットワークを損傷・無効化・過負荷・妨害・阻害するような形でウェブサイトやオンラインサービスを利用してはならず、ウイルス、ワーム、トロイの木馬などの破壊的要素を送信してはならず、ハッキングや暗号資産マイニングなどによって不正アクセスを試みてはならないとあります。
またCloudflareは、違法・有害、または規約違反だと単独の裁量で判断したコンテンツをDistributed Web Gatewayからブロックする権利を留保しており、そこにはマルウェア配布、フィッシング助長、その他の技術的濫用も含まれます。
攻撃者の案内サイトを落としても、GitHub Pagesや無数の無料静的サイトホスティングに移るだけです。
私には、Cloudflareが実際の攻撃自体を可能にしていたという証拠がまったくないように見えます。
完全に外部でいると決めたわけではありません。
関与しないという主張は、黙認として読むべきです。
十分に気に入らないユーザーは実際に追い出していると分かっているからです。
こうした記事は、Cloudflareがセキュリティ通報や法的命令に反応しないという奇妙な思い込みを前提にしているように見えます。
私の経験では、Cloudflareは業界全体と比べて適切かつ比較的迅速に対応します。
もっと先回りして動いたり、加入手続きにもっと摩擦を入れたりすることはできるでしょうが、インターネット警察をやらないという理由は理解できます。
インターネットにコンテンツをホストするために、クレジットカード、電話番号、身分証のコピーまで要求されるべきだとは思いません。
そうしなければ、他の島々がその接続を切っていました。
法執行は最後の手段でした。裁判所はインターネットの速度では動かず、しかもインターネットは国境を越える性質を持つため、誰も上から降ってくる政府規制など望んでいなかったからです。
Cloudflareはベンチャー資本を使って高価なものを無料で提供し、市場シェアを買いました。
すべての食料品店を自分の島に移転させてしまえば、他者から排除される心配なく犯罪活動の巣窟を運営できます。
ボットネット、マルウェア、オンライン詐欺と戦っている人に聞いてみれば分かります。
Cloudflareの行き止まりに達したら、もう諦めるしかありません。
感染コンピューターが7,000台しかない事件など、法執行機関が扱うはずもなく、Cloudflareも自ら調査して措置することはありません。
私は実際そうしていません。
内部調査を始めたり、abuseを行っている顧客に連絡したりするのに十分な証拠は提供したのに、そうしませんでした。
stresserであれば、外から見えるのはログインパネルだけでしょう。
こうしたサイトが自分たちのやっていることを公然と宣伝しているわけでもありません。
Cloudflareは自らをインフラとして位置づけています。
つまり、自分たちが運ぶコンテンツには責任を負わないということです。
通常であれば、インターネット上の悪質なシステムから自分のシステムを守るには、IPレイヤーでブロックできます。
しかしCloudflareは、IPレイヤーで良いシステムも悪いシステムも、その間のあらゆるものもプロキシします。
普通なら、犯罪組織が運営するサイトをIPレベルで遮断するか、コンテンツをホストしている組織の
abuse@に連絡して遮断・通報できます。Cloudflareはその両方をできなくします。
そしてCloudflareにabuse通報を送っても、私の連絡先情報を通報相手にそのまま渡さないという保証もありません。
この数年で、より責任感があるように見せる方向へ立場を変えてきましたが、本質は同じです。
Cloudflareの背後に隠れたシステムに
abuse@通報を送りたくても、誰に転送するのか分からない状態では、転送しないだろうと安心することはできません。先週の関連投稿:
“Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
https://news.ycombinator.com/item?id=48025001
現代インターネットにおけるCFの役割は好きではありませんが、この記事はCanonicalの証明書更新と会社移転が同じ日にあったという以外、根拠なく点と点を結びつけようとする推測の寄せ集めに見えます。
ただし、脇筋として見る価値のある話はあります。
Njallaは最近ひっそりと組織再編か所有権変更を行ったようで[1]、Njallaとimmateriali.smは関係する法人のように見えます[2]。
https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...
記事が非常に簡潔に述べている通り、Cloudflareは攻撃者を無料で前段で守り、被害者には救済の費用を請求します。
DDoS防御サービスはデジタルなみかじめ料のようにも見え、攻撃者に攻撃を続けさせるインセンティブが生じます。
「インターネットは危険です。無料プランを使う攻撃者からウェブサイトを守りたいなら、私たちにお金を払いなさい」という構図です。
少なくとも積極的な共謀や収益分配がないとしても、DDoS防御サービスがどちら側に立っているのかは明確ではありません。
指摘には同意しますが、CloudflareがDDoSを発明したわけではありません。
Cloudflareが明日魔法のように消えたとしても、AIクローラーは止まりません。
代替案は何でしょう。インターネットを見るために政府発行の身分証をアップロードしなければならない世界、という話ではないですよね？
インターネットの相対的な匿名性と世界的な性格を保ちたいなら、それをどう実現できるでしょうか。
人々が協同組合を作って防御を担うこともできるかもしれませんが、世界規模の主体として運営するのは難しいでしょう。
DDoS防御は主に、処理可能なほどの過剰な容量を持ち、それをフィルタリングする形なので、必要な投資はかなり大きいです。
CloudflareはThe Daily Stormerの事例[1]のように100%ではないにせよ、おおむね自社システムを通過する推定上合法なコンテンツを検閲せず、合法性の判定者になることを自ら選んでいません。
[1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
完全に同意します。
Cloudflareは巨大な規模で詐欺師たちを保護しているのに、誰も気にしていません。
私がCloudflareに通報した偽ショッピングモールや、Cloudflareの背後にあったフィッシングページは、一つも落ちませんでした。
本当に一つもです。
人々を守ることで何十億も稼ぐ会社なら、こういうことを真剣に扱うべきです。
たとえば「20ドルの被害を受けたので、損害賠償請求の対象を特定するため、Cloudflareに提供された顧客の支払い情報、発行銀行、口座番号を求める」といった少額訴訟は、かなり有効に見えます。
まだ誰かが試したという話は聞きませんが、誰かがやるなら結果を見てみたいです。
私は今の状態のほうがずっとましだと思います。
Ubuntuが落ちたのは、ubuntuサーバーがcopy.failにパッチを当てられないようにして、そのハッカー集団がその間にできるだけ多くの対象を悪用しようとしていたからだと、ずっと思っていました。
modprobe(8)の設定をいくつか変更することで緩和できました。# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf# rmmod algif_aeadこの機能を使っているプロセスがあるかもしれませんが（
lsof | grep AF_ALG）、私の理解では広く使われていないので、大半のシステムでは無効化しても問題ないはずです。すべてのapexサーバーは負荷分散を維持するよう高可用性で構成されているはずなので、一般ユーザーはcopy.failのパッチ時に何も感じないはずです。
私たちのユーザーも、パッチを配布した際にまったく気づきませんでした。
それは脅迫というよりゆすりに近いです。
CFはそのどちらもしていません。
この論理なら、キーボードメーカーも自社製品で書かれた違法行為に責任があると言えてしまいます。
犯罪活動の支援に使われている組織に継続してサービスを提供することはまったく別の話で、違法活動を理由に顧客を解約するのは何ら物議を醸すことではありません。
UPSの荷物で爆弾を受け取ったからといってUPSのせいではありません。
しかし、誰かがUPSを使って人々に爆弾を送っていると知らされているのに、何の措置も取らず、しかも爆弾の発送者を守っているように見えるなら、ある程度の責任は生じるのではないでしょうか。
このシナリオでの「キーボードメーカー」は、Cloudflareではなく、Cloudflareが機器を買うルーターメーカーに近いです。
この比喩でCloudflareは、あらゆる汚いものとまともな解説を一緒に載せる新聞のアグリゲーターに近いです。
通常なら、汚い新聞は読まなければよく、読みたい人は自分で決めればいい話です。
しかしCloudflareのケースでは、主要なまともな新聞がすべてCloudflare経由でコンテンツを配信することにしており、問題のあるものが一緒に配信されると、元の発行者ではなくCloudflareに文句を言うしかなくなります。
しかもCloudflareは、事前に分からない形で私の情報を非常に不快な相手に渡す可能性もあります。
線引きはどこでするべきでしょうか?