T
traeai
登录
返回首页
Hacker News Best

有人能解释一下Cloudflare是否勒索了Canonical吗?

7.8Score
有人能解释一下Cloudflare是否勒索了Canonical吗?

TL;DR · AI 摘要

Cloudflare在未阻止攻击服务Beamed的情况下,既为攻击者提供基础设施,又向受害者Canonical收费恢复服务,引发是否构成变相勒索的争议。

核心要点

  • Cloudflare同时为攻击工具Beamed和受害者Canonical提供AS13335 CDN服务,形成利益冲突。
  • 攻击服务Beamed通过Immaterialism Limited注册,其背后控制人关联反监控维权组织Blueprint for Free Speech。
  • AS39287网络自2006年持续运营,曾属海盗湾创始人公司,2026年转移至英国注册实体。

结构提纲

按章节快速跳转。

  1. 2026年4月30日Canonical全站服务中断约20小时,5月1日恢复。

  2. 攻击者使用名为Beamed的商业DDoS服务,宣称可绕过Cloudflare防护机制。

  3. Beamed官网beamed.su由Cloudflare托管,直接在其平台上宣传绕过技术。

  4. Beamed通过Immaterialism Limited注册域名,该公司由激进派人士管理。

  5. AS39287自2006年起多次易主,从Flattr到抽象有限公司,体现长期滥用路径。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Cloudflare与Canonical事件分析
    • 攻击事件
      • 20小时服务中断
      • 影响ubuntu.com等关键服务
    • 攻击工具Beamed
      • 宣称可绕过Cloudflare
      • 官网由Cloudflare托管
    • 注册与控制链
      • Immaterialism Limited (UK)
      • Nicole Fernandez Chaves
      • Naomi Colvin(活动家)

金句 / Highlights

值得收藏与分享的关键句。

#Cloudflare#网络安全#DDoS#Canonical#CDN
打开原文

标题:有人能解释一下 Cloudflare 是否勒索了 Canonical 吗?

来源网址:https://www.flyingpenguin.com/can-someone-please-explain-whether-cloudflare-blackmailed-canonical/

Markdown 内容: 2026年4月30日,16:33:37 UTC。Canonical 的事件监控系统将 blog.ubuntu.com 标记为服务中断。

十分钟内,该公司其余的公开网站也相继瘫痪:主站 ubuntu.com、下游包管理系统所依赖的安全公告 API、开发者门户、企业官网以及培训平台。这些中断持续了大约二十小时。

2026年5月1日,12:44 UTC。服务恢复。

声称对此攻击负责的组织表示他们使用了一项付费服务。他们提到了租用的一种工具:一款名为 Beamed 的商业性拒绝服务产品,该产品通过多个顶级域名销售,其中 beamed.su 作为营销和博客站点,beamed.st 则是客户登录门户。2026年4月的一篇博文《_如何利用高级压力测试方法绕过 Cloudflare_》宣传了三种击败 Cloudflare 防护的技术,包括住宅 IP 轮换和手动“端点探测”以定位源服务器。Beamed 明确说明了其销售内容:

Cloudflare 充当反向代理,隐藏源服务器的真实 IP 地址。许多低质量的“启动器”在面对“攻击中模式”或机器人对抗模式时会失败。Beamed.su 采用多种先进技术,可有效对受 Cloudflare 及类似 CDN 保护的网站进行压力测试。

发布这段文字的博客本身由 Cloudflare 提供托管服务。所售产品是用于绕过 Cloudflare 的工具。而卖家的托管服务商正是 Cloudflare。

攻击发生一周后,beamed.su 和 beamed.st 仍然在线。两者均解析至 Cloudflare AS13335 的地址。Canonical 的两个软件仓库端点 security.ubuntu.com 和 archive.ubuntu.com 同样解析到 Cloudflare AS13335 地址,这是其作为付费客户的关系体现。

_Cloudflare 免费为攻击者提供前端支持,却向受害者收取救援费用。_

我被反复问到的问题是:_刚刚发生的事情是否构成勒索?_ 以及,那个宣称负责的行为体(一个自称亲伊朗、名为“伊拉克伊斯兰网络抵抗组织”,又称 313 团队)为何最终会从一项服务租用攻击能力,而该服务的前端基础设施正是由 Canonical 最终支付费用来寻求缓解保护的同一家公司运营的?

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(1993 年 3 月出生),注册地址为伦敦大波特兰街的一个集体邮箱地址。

2025 年 4 月 11 日,Fernandez Chaves 辞去董事职务,但仍保留 75% 或以上的经济权益。接任董事为居住于英格兰的英国公民 Naomi Susan Colvin,任命地址相同。

Colvin 曾任勇气基金会(Courage Foundation)董事,该基金会是法律辩护机构,其受托人包括朱利安·阿桑奇(Julian Assange)、约翰·皮尔格(John Pilger)、薇薇安·韦斯特伍德(Vivienne Westwood)和雷纳塔·阿维拉(Renata Avila),曾支持维基解密(WikiLeaks)和巴雷特·布朗(Barrett Brown)等受益人。她目前担任“言论自由蓝图”(Blueprint for Free Speech)组织的英国与爱尔兰项目总监,致力于举报人保护和反SLAPP诉讼。阻止劳里·洛夫(Lauri Love)被引渡至美国的法律行动即由她领导。她是一位长期的社会活动人士。

2026 年 2 月 26 日,Immaterialism Limited 在 Companies House 同日提交了两项变更:注册办公地址变更(从大波特兰街 85 号变更为 167–169 号),以及 Fernandez Chaves 作为重大控制人信息的更新。

次日,即 2026 年 2 月 27 日,宣布 Beamed IP 地址空间及相关服务的路由基础设施转移了司法管辖权。

宣布 Materialism 地址空间的自治系统为 AS39287。RIPE 于 2006 年 1 月 24 日分配了此 AS 编号。自那时起,其路由标识一直保持连续,但注册运营商及记录国家已变更两次。

大约从 2017 年到 2020 年,AS39287 由塞浦路斯公司 Privactually Ltd 持有,并以 FLATTR-AS 名义运营。Flattr 是彼得·孙德·科尔莫索普(Peter Sunde Kolmosoppi)的微支付项目,他也是海盗湾(The Pirate Bay)的创始人之一。该注册下的前缀滥用联系人为 abuse@shelter.st。

从 2020 年到 2026 年,同一 AS 编号被重新分配给芬兰公司 ab stract ltd,地址位于赫尔辛基乌尔霍·凯科宁街 4-6E。其在 RIPE 记录中的维护对象为 BKP-MNT。记录中的指定人员为 Peter Kolmisoppi(代号“brokep”),同样是海盗湾的联合创始人,邮寄地址位于马尔默,邮箱为 noc@brokep.com。运营商域名 abstract.fi 的权威域名服务器为 Njalla 的三个服务器:njalla.fo、njalla.no 和 njalla.in。Njalla 是由彼得·孙德创办、通过圣基茨和尼维斯的 1337 Services LLC 运营的隐私即服务型域名代理。部分属于 ab stract 的地址前缀使用的滥用联系人为 cyberdyne.is。

2月27日的重新分配

2026年2月27日,UTC时间12:11:48,RIPE记录了第三次重新分配。AS39287被转让给Materialism s.r.l.,这是一家位于布加勒斯特冶金大道(Bulevardul Metalurgiei)的罗马尼亚公司,以“materialism”名义运营。早在五个月前,即2024年9月30日,已为Materialism开通了RIPE会员资格,但此后一直未使用。此次重新分配包括IPv4前缀45.158.116.0/22以及IPv6前缀2001:67c:2354::/48和2a02:6f8::/32,其中最后一个前缀最初于2008年8月在先前的管理体系下分配。

所有三次过渡期间,对等互联安排均保持不变。从FLATTR时期到materialism时期,AS39287持续以完全相同的配置与AS42708(Telia)、AS37560(GTT)、AS12552(GlobalConnect)、AS34244(Voxility)和AS54990进行路由导入和导出。相同的路由来自相同的上游网络。唯一变化的是可见的操作员名称。

IANA认证域名注册商列表还显示,Immateriali.sm的客户群中包含1337 Services LLC,即Njalla背后的商业实体。因此,该链条的注册商端与隐私代理端同属一个校友集群。

1337 Services。是的,我知道。

2月27日的证书轮换

Canonical仓库端点的相关证书透明度记录显示,在路由重新分配发生的同一24小时内出现了以下条目:

  • 2月27日,UTC时间06:14:03,Let’s Encrypt为archive.ubuntu.com签发了一张新的顶级域名证书。
  • 同一天19:13:35,Let’s Encrypt为security.ubuntu.com签发了一张新的顶级域名证书。在此条目前,该主机名在2026年的证书透明度日志中仅包含区域镜像站点的证书,此前的日志中并未出现过security.ubuntu.com的顶级域名证书。
  • 同日22:14:03,clouds.archive.ubuntu.com获得了一张新证书。

接下来的九天内,azure.archive.ubuntu.com、wildcard-gce.archive.ubuntu.com和wildcard-ec2.archive.ubuntu.com也重复了相同的模式。每一张新证书都是为顶级域名签发,而非区域镜像站点。

要在不破坏网络与源站之间加密的前提下将某个主机名置于内容分发网络(CDN)之后,前提是该主机名在源站必须拥有有效的原点证书。只有先在源站部署证书,才能让CDN开始从中拉取内容。

这两起事件在2月27日的高度同步性至今尚未得到解释。

图片 1

攻击时间线

此事件的逐分钟日志来自Canonical官方的状态页面status.canonical.com,由一名用户于4月30日约UTC时间22:52截取并发布至Ubuntu Discourse论坛第81470号帖子中。以下所有时间均为UTC时间。若原始资料使用太平洋夏令时间或英国夏令时间,则已在括号内注明换算后的时间。

  • 16:33:37:blog.ubuntu.com首次标记为“宕机”。此时间为事件起始时间。
  • 16:34:10:canonical.com 宕机。
  • 16:34:45:academy.canonical.com 宕机。
  • 16:35:15:developer.ubuntu.com 宕机。
  • 16:35:22:maas.io 宕机。
  • 16:36:09:jaas.ai 宕机。Ubuntu安全API(CVE)宕机。
  • 16:37:13:Ubuntu安全API(通知)宕机。
  • 16:41:57:assets.ubuntu.com 宕机。
  • 16:43:25:ubuntu.com 宕机。

由此可见,安全公告服务在事件发生三分钟内中断,营销主站则在十分钟内中断。此时仍未受影响的两个主机是security.ubuntu.com和archive.ubuntu.com——而这正是两个一旦不可用就会导致全球每一台Ubuntu系统执行_apt update_失败的关键端点。

  • 19:34:38:security.ubuntu.com首次标记为“宕机”。
  • 19:40:01:archive.ubuntu.com 宕机。

这一点值得注意:攻击者将这两个仓库端点保留了三个小时后才最后启用。

从19:40 UTC起,在随后的七十分钟内,这两个仓库端点在状态面板上反复在“宕机”与“运行中”之间切换。状态日志记录显示,security.ubuntu.com经历了五次“宕机/恢复”切换,archive.ubuntu.com则有四次。

这种模式符合在源站尝试缓解措施(如速率限制、地理过滤、流量清洗),但在高达3.5 Tbps的持续攻击流量下失败的表现。

  • 20:50:29:archive.ubuntu.com 标记为“运行中”。
  • 20:51:13:security.ubuntu.com 标记为“运行中”。

此后44秒内,这两个主机再未在捕获的日志快照中显示为宕机状态(日志持续至22:52 UTC)。波动现象彻底停止。两个端点几乎同时稳定下来,间隔不到一分钟,此时距离攻击开始已过去四小时十七分钟。

目前这两个主机名的解析结果与当时稳定后的目标一致。截至目前,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仅向Cloudflare移交了两条A记录:正是攻击者所针对的两个仓库访问端点。其余所有服务仍保留在Canonical自有的硬件上,并依靠原有缓解机制承受攻击冲击。

非仓库类主机在整个日志记录结束前仍持续波动。它们最终通过上游过滤与攻击减弱的共同作用恢复正常。

Canonical 首次公开承认的消息发布于 5 月 1 日世界标准时间 07:13,此时距离其仓库端点在 Cloudflare 后方“恢复稳定”已过去十小时。所有组件的完全恢复于 5 月 1 日 12:44 UTC 得到确认,距事件发生约二十小时。

定义所发生之事

没有任何可见渠道显示支付了赎金。

相关规模的加密货币流动并未出现在公共记录中。

勒索信件也未浮出水面。

若存在谈判,也是私下进行的。

_真正发生变动的是一项付费订阅服务。_

Canonical 的两个最高价值端点——其拒绝访问会导致全球自动化安全更新失败——转变为与一家供应商的服务关系,而该供应商的其他_当前客户包括当时正在攻击 Canonical 的僵尸网络运营方_。

这笔交易完成时,并不需要 Cloudflare 发出任何要求。Beamed 持续对外提供服务的能力本身就是要求。Canonical 自身基础设施上的中断计时就是最后期限。保护者在两端都获得收益,同时在每一刻都保持内容中立,并符合其服务条款的文字规定。无论这种局面是 Cloudflare 主动设计,还是通过汇集无关客户决策而自然形成,从勒索运作机制的角度来看并无区别。结果都是一样的。

任何历史学者都应该能认出,这正是我们此前见过的相同架构。

1930 年代,摩西·安嫩伯格(Moses Annenberg)创办的“通用新闻社”(General News Bureau)向全美各地的赌马庄家出售及时的赛马结果。订阅该服务的庄家得以生存;拒绝订阅的则因竞争对手掌握准确赔率信息而导致自身设赔能力崩溃。

安嫩伯格的收入依赖于他对赛果验证的垄断地位,这使得每个未经授权的庄家都不得不依赖他的电报线路才能运营。联邦政府于 1939 年通过税务起诉打破了这一垄断,此后对继任电讯服务商的突袭一直持续到 1940 年代。1942 年,拉瓜迪亚市长毫不手软:

“昨天,警方突袭了位于自由街 126 号五楼的一套办公室,以及布朗克斯区彭菲尔德街 834 号一栋八十五户住宅楼内的公寓,逮捕了九人。警方称这是‘一个年收入百万美元的电讯服务网络,专为纽约、新泽西、威彻斯特和拿骚县的台球厅庄家及其他赛马赌徒提供赌博信息’。”

如今,DDoS 防护市场在“僵尸网络攻击即服务”(booter market)面前所处的位置大致相同。Cloudflare 的收入依赖于其作为“某项服务是否可在公共互联网上被访问”的验证者角色。当同一家公司同时也是僵尸网络的托管服务商时,威胁与防护的角色便合并为单一收入流。

使此次事件尤为特殊的是,公共记录似乎经过了“洗白”。Companies House 保存着公司注册文件,RIPE 数据库记录了路由重新分配,证书透明度日志记载了顶级域名证书的轮换日期,Canonical 自己的状态页面则记录了记录变更的具体分钟。

这一切都是公开登记信息或企业披露内容。甚至 2 月 27 日的集群活动也存在于公共记录之中。当天,在同一时间段内完成了三项准备工作:Materialism s.r.l. 获得了 AS39287 及其长期持有的 IPv6 地址段的控制权;Immaterialism Limited 提交了 Companies House 的注册文件;而在 Canonical 方面,后来被迁移至内容分发网络后的两个顶级主机名也更新了其源服务器证书。

攻击开始与 Cloudflare 地址出现在 Canonical 仓库主机名之间相隔四小时,这正是购买决策发生的时间窗口。我想象着工程师们从“坚守防线”抵抗经由 Cloudflare 路由的攻击,转变为“签署 Cloudflare 合同”。大约也就是持续中断的成本超过 Cloudflare 报价所需的时间。

新的客户关系于 2026 年 4 月 30 日 20:50:29 UTC 正式显现。

AI 可能会生成不准确的信息,请核实重要内容