2025年9月,Cloudflare通报其成功缓解了一次峰值达22.2 Tbps、包速率10.6 Bpps(每秒106亿包)的DDoS攻击,全程仅持续约40秒——这是公开报道中人类网络史上最大规模的流量攻击纪录。本文回答三个问题:这个纪录是怎么在40秒内刷出来的?十二年里攻击纪录为何从300 Gbps暴涨74倍?以及最关键的——站在运营商和IDC运维的角度,面对“秒级峰值”的流量海啸,传统人工封堵为什么必输,防御纵深应该怎么搭。
先看事件本身。据Cloudflare官方博客通报,这次攻击发生在2025年9月中旬,目标是某托管服务商,攻击流量全部经由Cloudflare网络承载并被吸收。两个数字需要放在一起看:
把这两个数一除,有一个对运维来说非常重要的隐含结论:22.2×10¹² bps ÷ 10.6×10⁹ pps ≈ 2100 bit/包,即平均包长只有260字节左右。这不是靠大包堆带宽的“胖水管攻击”,而是海量小包的“包速率攻击”——它打击的是路由器、防火墙、负载均衡器的每秒转发包数(PPS)能力和ACL查表能力,而不是链路带宽。很多IDC的设备带宽余量充足,包速率余量却极其有限,这是很多“带宽没打满但业务先瘫”故障的真正病因。
第三个数字同样致命:40秒。据通报,流量从起涨到冲顶的整个过程以秒计,攻击方还对UDP源端口做了大规模随机化,让基于端口、五元组的静态过滤规则基本失效。传统的“值班工程师看到告警→登录网管→定位→打电话给上游→下发封堵”的流程,走完一遍少说5分钟——而攻击只给你40秒。这个时间差,就是本轮所有抗D体系重构的出发点。
值得说明的是,Cloudflare在通报中披露了规模与矢量,但没有点名攻击来源;第三方安全研究者(如Krebs on Security)将其归因于活跃的Aisuru僵尸网络,此归属未经官方证实,下文按“第三方分析”处理。
单次纪录是新闻,纪录的斜率才是趋势。把公开可查的标志性攻击拉一张表,攻击能力的膨胀速度一目了然:
| 时间 | 事件 | 峰值规模 | 主要矢量 | 备注 |
|---|---|---|---|---|
| 2013年 | Spamhaus事件 | 约300 Gbps | DNS/Chargen反射 | 当年被称为“撼动互联网” |
| 2016年 | Dyn DNS事件 | 约1.2 Tbps | Mirai物联网僵尸网络 | Twitter、Netflix等大面积不可用 |
| 2016年 | OVH托管事件 | 约1.1 Tbps | Mirai变种 | 约15万台IoT设备参与 |
| 2018年 | GitHub事件 | 1.35 Tbps | Memcached反射 | 约8分钟内完全缓解 |
| 2020年 | AWS客户遭攻击 | 2.3 Tbps | CLDAP反射 | AWS季度威胁报告披露 |
| 2021年 | Azure客户遭攻击 | 3.47 Tbps | UDP反射 | 微软披露,当时纪录 |
| 2023年 | HTTP/2 Rapid Reset | 3.98亿 rps | 应用层协议漏洞(CVE-2023-44487) | 应用层纪录,Google/AWS/Cloudflare同日披露 |
| 2024年6月 | Cloudflare通报 | 5.6 Tbps | UDP洪水 | 目标为东亚某ISP,持续数十秒 |
| 2025年5月 | Cloudflare通报 | 7.3 Tbps | UDP洪水 | 当时纪录 |
| 2025年9月 | Cloudflare通报 | 22.2 Tbps / 10.6 Bpps | UDP洪水+源端口随机化 | 现行纪录,本文主角 |
三条曲线值得单独说:
第一,Tbps级纪录十年涨了约74倍(300 Gbps→22.2 Tbps),而同期骨干网单端口容量只从100G涨到800G(8倍)。攻击流量的增长远快于管道容量的增长,靠“把水管修粗”硬扛,经济上已经不可行,这是Anycast分布式吸收成为主流的根本原因。
第二,攻击范式在2023年分叉。网络层靠“设备数量”(IoT肉鸡海),应用层靠“协议漏洞”(一个HTTP/2请求反复触发流重建,单请求放大成百上千倍)。运维侧要同时准备两套防御:网络层拼容量和调度,应用层拼WAF/协议补丁。
第三,反射放大是贯穿始终的杠杆。攻击者自己发的永远是“小请求”,被借用的全世界的开放服务器替他“发大回应”。
反射放大攻击(DRDoS)的原理一句话说清:利用“请求小、回应大 + 源地址可伪造”的协议特性,让第三方服务器替攻击者打流量。
攻击者向全世界的Memcached服务器发送一个几十字节的get请求,但把源IP伪造成受害者的地址。Memcached按设计把缓存内容原样吐回——于是所有回应都涌向受害者。整条链路里攻击者自己的上行流量几乎可以忽略,“杠杆”全在被滥用的开放服务上。
各协议的典型放大倍数(取自Cloudflare等公开测量的典型值,随具体实现与配置浮动):
| 协议 | 滥用点 | 放大倍数(约) |
|---|---|---|
| Memcached(UDP 11211) | 未鉴权的get请求 | 最高约51000倍 |
| NTP | monlist命令 | 约556倍 |
| Chargen | 字符生成回显 | 约359倍 |
| CLDAP | LDAP匿名查询 | 约57倍 |
| DNS | 开放递归ANY查询 | 约50倍 |
| SSDP | UPnP发现 | 约31倍 |
| SNMPv2 | 遍历查询 | 约6倍 |
对运营商来说这张表有个刺眼的含义:放大器就在你家的接入网里。每一次设备升级后新增的开放DNS递归、每一台没关monlist的NTP服务器、每一个默认开着UPnP的家用路由器,都是下一次纪录的潜在“燃料”。2018年GitHub那次1.35 Tbps攻击,源头是全网数千台配置错误的Memcached,GitHub在事故报告里写得很清楚:攻击持续约8分钟,靠黑洞路由加第三方清洗扛过去的——那已经是当年近乎教科书级的响应速度。
近年有个值得注意的技术变化:QUIC/HTTP/3时代,协议设计内置了“响应不超过请求3倍”的抗放大上限,新协议层面已很难再造千倍杠杆。所以近两年的巨型攻击基本回到两条老路:真机海的UDP洪水(如22.2 Tbps这次)和应用层协议逻辑漏洞(如Rapid Reset)。前者的治理答案是源头反劫持,后者的答案是打补丁和协议加固。
timeline
title DDoS纪录进化史 2013-2025
2013 : Spamhaus事件 约300Gbps : 反射放大进入公众视野
2016 : Dyn事件 约1.2Tbps : Mirai物联网肉鸡海登场
2018 : GitHub事件 1.35Tbps : Memcached五万倍杠杆
2020 : AWS扛住2.3Tbps : 云厂商开始接管纪录
2023 : Rapid Reset 3.98亿rps : 应用层协议漏洞分叉
2024 : 5.6Tbps : 包速率维度浮出水面
2025 : 5月7.3Tbps : 9月22.2Tbps现行纪录
按Krebs on Security等第三方的持续追踪,2024年以来不断刷新纪录的流量主要来自一个被称为Aisuru的僵尸网络:由入侵的家用路由器、摄像头、Android设备等组成,特征是产出海量“垃圾流量”,除了勒索和打瘫竞争对手,还被曝出用于攻击xAI的Grok直播流等高价值目标(此类用途归属未经官方证实)。它的可怕之处不在单点技术,而在三件事的叠加:
对运营商的直接影响是:你网络里的每一台弱口令设备,都可能正在给别人交“攻击算力”的税。这也解释了为什么各国监管近两年不断把“源地址验证、终端治理”写进合规要求——源头不管,下游永远在替上游还债。
面对秒级冲顶的攻击,业界共识的防御架构可以概括为三层:先摊薄(吸收)、再净化(清洗)、快止血(压制)。核心逻辑是承认一个现实:没有任何单点能硬扛22.2 Tbps,防御的本质是用全球分布式容量把攻击稀释成每个节点可消化的规模,再靠自动化把响应时间压进攻击的40秒窗口。
flowchart TD
A[互联网入口流量] --> B[边缘路由器集群]
B -->|正常| C[客户业务]
B -->|可疑洪峰| D[sFlow探针抽样]
D --> E[态势感知平台]
E -->|异常PPS告警| F[自动决策引擎]
F -->|FlowSpec封堵规则| B
F -->|引流通告| G[清洗中心]
G --> H[清洗集群逐包过滤]
H --> I[干净流量GRE回注]
I --> C
三层里各家的主流手段对比如下:
| 手段 | 原理 | 生效速度 | 控制粒度 | 典型局限 |
|---|---|---|---|---|
| Anycast分布吸收 | 同一IP多地通告,攻击流量被天然摊到全球节点 | 实时 | 粗(按节点容量) | 需要全球节点与带宽储备,自建不现实 |
| RTBH黑洞路由 | 将目标前缀指向下跳为null0并向上游宣告 | 秒级 | 极粗,目标业务全灭 | 只能保网络不能保业务 |
| BGP FlowSpec(RFC 8955) | 向邻居路由器下发过滤规则,可匹配端口、包长、分片等 | 秒到分钟级 | 细 | 依赖邻居AS支持,策略一致性难管 |
| 清洗中心引流回注 | BGP引流入洗,逐包检测后GRE/MPLS回注 | 分钟级 | 最细 | 回注带宽成本高,引流路径本身可能被堵 |
| 应用层前置(WAF/CDN) | 协议加固+人机识别 | 实时 | 应用级 | 只覆盖七层,对网络层洪水无解 |
落到工程实践,有三个在国内运营商网络里反复验证过的要点:
其一,控制面存活优先于一切。 包速率洪水冲垮的第一块骨牌往往不是业务,而是路由器自身——BGP会话抖动、路由表震荡,局部故障瞬间放大成全网故障。CoPP(控制面保护)策略、BGP会话保活与Graceful Restart,必须在洪水到来之前配置并演练过,这是“保住指挥系统”的问题。
其二,决策必须自动化,人工只能做复核。 40秒的攻击窗口决定了“检测→决策→下发”必须闭环在秒级:sFlow/NetFlow探针秒级抽样,态势平台按PPS/新建速率等基线自动触发预案,FlowSpec规则预生成、一键下发。人工的角色是把最后确认权保留在“误伤代价大的动作”(如整段黑洞)上。
其三,与上游的SLA要写到“时间”。 和传输、抗D服务商(以及国内云堤这类运营商级抗D平台)的协议里,“缓解生效时间”必须写成明确的分钟级SLA并定期演练,而不是一张“7×24支持”的含糊承诺。GitHub当年8分钟完全缓解的成绩,背后是预先打通的引流通道——临时抱佛脚在秒级攻击面前等于没有防御。
把上面的分析收敛成可执行清单,按优先级排序:
从2013年Spamhaus的300 Gbps到2025年的22.2 Tbps,十二年74倍——攻击者用行动证明了摩尔定律在“破坏力”上同样成立。但对运维工程师来说,这次纪录真正的信息量藏在三个数字的除法里:260字节的平均包长提醒你看PPS而不是带宽,40秒的冲顶时间提醒你人工流程必须重构成自动化闭环,五万倍的放大系数提醒你源头治理才是最便宜的防御。纪录还会被刷新,大概率就是明年;而防御体系的每一次“提前量”,都来自把今天这份拆解真正抄进自己的网络里。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
