有人可以解釋一下，Cloudflare 到底有沒有勒索 Canonical？ （★ 98 分）
文章指出，2026 年 4 月 30 日 16:33 UTC 起，Canonical 的 blog.ubuntu.com 先被監控系統標為服務中斷，接著 ubuntu.com、canonical.com、開發者入口、訓練平台與 Ubuntu 安全公告 API（應用程式介面）等公開服務在約 10 分鐘內陸續受影響，整體中斷約 20 小時。聲稱犯案的是自稱親伊朗的 Islamic Cyber Resistance in Iraq／313 Team，並表示租用了 Beamed 這類商用 DDoS（分散式阻斷服務攻擊）壓力測試服務。文章特別指出，Beamed 公開宣傳可繞過 Cloudflare 防護，其網站與登入入口本身卻由 Cloudflare 代理；而 Canonical 之後將 security.ubuntu.com 與 archive.ubuntu.com 兩個關鍵 Ubuntu 套件倉庫端點移到 Cloudflare AS13335（Cloudflare 的自治系統編號）後恢復穩定，形成作者所稱「Cloudflare 替攻擊者免費做前端防護，又向受害者收取救援費用」的疑問。
作者進一步整理公開紀錄，包含 Beamed 網域註冊商 Immaterialism Limited、Companies House（英國公司登記機關）資料、RIPE（歐洲網路協調中心的網路資源資料庫）中的 AS39287 轉移，以及 Let’s Encrypt 憑證透明度紀錄。文章稱，2026 年 2 月 27 日同一天出現多個事件：AS39287 轉到羅馬尼亞的 Materialism s.r.l. 名下，Immaterialism Limited 提交公司資料變更，Canonical 的 archive.ubuntu.com、security.ubuntu.com 等 apex 主機名稱也更新了來源端 TLS 憑證；作者認為，這些憑證是日後把端點放到 CDN（內容傳遞網路）後仍維持加密連線的前提。到了攻擊當天，兩個倉庫端點比其他站點晚約 3 小時才被打，之後在狀態頁反覆中斷與恢復，直到 20:50 至 20:51 UTC 左右同時穩定，且解析到 Cloudflare 位址；其他 Canonical 站點則仍留在自家 AS41231 空間。文章因此主張，雖沒有可見的贖金、加密貨幣流向或威脅信，但實際移動的是付費訂閱關係，並把這種結構類比為數位版保護費模式。
Hacker News 討論對這個指控分歧很大。批評者認為文章把「Cloudflare 代理攻擊者的宣傳網站」與「Cloudflare 提供攻擊流量」混為一談，稱「向 Cloudflare 租用攻擊能力」並不準確；攻擊者即使不用 Cloudflare，也能改用其他主機、Telegram 或隱私代理服務宣傳。也有人指出，Cloudflare 免費方案幾乎任何人都能使用，這更像是缺乏審查與濫用回報流程失靈，而不是能證明 Cloudflare 與攻擊者有直接商業合作或共謀。部分留言也補充，若要要求 Cloudflare 提供帳戶身分或下架，通常需要法院傳票等正式法律程序，單靠一般使用者通報未必會有結果。
另一派則認為，即使沒有主觀共謀，Cloudflare 的角色仍有明顯利益衝突：它可以同時保護惡意服務的可用性，又向受害者販售 DDoS 防護，讓攻擊造成的外部成本由受害者承擔。留言中也有人把這與詐騙廣告、釣魚網站長期躲在大型平台或代理服務後方相比，主張大型網路基礎設施公司應承擔更多濫用治理責任。討論最後延伸到網際網路基礎協定的弱點、DDoS 防護必須依靠巨大容量、匿名性與責任歸屬難以兼得等問題；整體看來，多數較審慎的觀點承認此事件揭露了 DDoS 防護市場的結構性誘因問題，但不認為現有公開資料足以證明 Cloudflare 曾蓄意勒索 Canonical。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=48098537