# 40秒22.2Tbps：史上最大DDoS攻防拆解，运营商该抄哪份作业 ## 概述 2025年9月，Cloudflare通报其成功缓解了一次峰值达22.2 Tbps、包速率10.6 Bpps（每秒106亿包）的DDoS攻击，全程仅持续约40秒——这是公开报道中人类网络史上最大规模的流量攻击纪录。本文回答三个问题：这个纪录是怎么在40秒内刷出来的？十二年里攻击纪录为何从300 Gbps暴涨74倍？以及最关键的——站在运营商和IDC运维的角度，面对“秒级峰值”的流量海啸，传统人工封堵为什么必输，防御纵深应该怎么搭。 ## 目录 - 一、40秒，22.2Tbps：纪录是怎么刷出来的 - 二、十二年纪录史：300G到22.2T的74倍杠杆 - 三、放大攻击原理：一份请求换五万份回应 - 四、Aisuru：不讲武德的“垃圾流量工厂” - 五、运营商防御纵深：吸收、清洗、压制 - 六、写给运维的七条清单 - 结语 ## 一、40秒，22.2Tbps：纪录是怎么刷出来的 先看事件本身。据Cloudflare官方博客通报，这次攻击发生在2025年9月中旬，目标是某托管服务商，攻击流量全部经由Cloudflare网络承载并被吸收。两个数字需要放在一起看： - **峰值速率22.2 Tbps**——相当于约2200万台千兆宽带用户同时满速下载； - **包速率10.6 Bpps**——每秒106亿个包。 把这两个数一除，有一个对运维来说非常重要的隐含结论：22.2×10¹² bps ÷ 10.6×10⁹ pps ≈ 2100 bit/包，即**平均包长只有260字节左右**。这不是靠大包堆带宽的“胖水管攻击”，而是海量小包的“包速率攻击”——它打击的是路由器、防火墙、负载均衡器的**每秒转发包数（PPS）能力和ACL查表能力**，而不是链路带宽。很多IDC的设备带宽余量充足，包速率余量却极其有限，这是很多“带宽没打满但业务先瘫”故障的真正病因。 第三个数字同样致命：**40秒**。据通报，流量从起涨到冲顶的整个过程以秒计，攻击方还对UDP源端口做了大规模随机化，让基于端口、五元组的静态过滤规则基本失效。传统的“值班工程师看到告警→登录网管→定位→打电话给上游→下发封堵”的流程，走完一遍少说5分钟——而攻击只给你40秒。这个时间差，就是本轮所有抗D体系重构的出发点。 值得说明的是，Cloudflare在通报中披露了规模与矢量，但没有点名攻击来源；第三方安全研究者（如Krebs on Security）将其归因于活跃的Aisuru僵尸网络，此归属未经官方证实，下文按“第三方分析”处理。 ## 二、十二年纪录史：300G到22.2T的74倍杠杆 单次纪录是新闻，纪录的斜率才是趋势。把公开可查的标志性攻击拉一张表，攻击能力的膨胀速度一目了然： | 时间 | 事件 | 峰值规模 | 主要矢量 | 备注 | |---|---|---|---|---| | 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）。前者的治理答案是源头反劫持，后者的答案是打补丁和协议加固。 ```mermaid 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现行纪录 ``` ## 四、Aisuru：不讲武德的“垃圾流量工厂” 按Krebs on Security等第三方的持续追踪，2024年以来不断刷新纪录的流量主要来自一个被称为Aisuru的僵尸网络：由入侵的家用路由器、摄像头、Android设备等组成，特征是产出海量“垃圾流量”，除了勒索和打瘫竞争对手，还被曝出用于攻击xAI的Grok直播流等高价值目标（此类用途归属未经官方证实）。它的可怕之处不在单点技术，而在三件事的叠加： 1. **肉鸡质量的“宽带化”**。Mirai时代的肉鸡多是ADSL时代的摄像头，单机上行几兆；如今的肉鸡大量来自千兆光纤入户的家用设备，单机攻击能力高两个数量级，几万台就能凑出十几Tbps。 2. **抗封堵设计**。如22.2 Tbps这次采用的UDP源端口全域随机化，让运营商没法靠“封某个端口段”这种低成本的五元组规则止血，只能按前缀甚至整条链路来切，误伤面急剧放大。 3. **白菜价的攻击服务**。租用型DDoS（booter/stresser）常年以几十到几百美元的价位在灰色市场流通，纪录攻击的边际成本极低——这意味着纪录不是终点，只要“生意”还在，下一个数字只会更大。 对运营商的直接影响是：**你网络里的每一台弱口令设备，都可能正在给别人交“攻击算力”的税**。这也解释了为什么各国监管近两年不断把“源地址验证、终端治理”写进合规要求——源头不管，下游永远在替上游还债。 ## 五、运营商防御纵深：吸收、清洗、压制 面对秒级冲顶的攻击，业界共识的防御架构可以概括为三层：**先摊薄（吸收）、再净化（清洗）、快止血（压制）**。核心逻辑是承认一个现实：没有任何单点能硬扛22.2 Tbps，防御的本质是用全球分布式容量把攻击稀释成每个节点可消化的规模，再靠自动化把响应时间压进攻击的40秒窗口。 ```mermaid 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分钟完全缓解的成绩，背后是预先打通的引流通道——临时抱佛脚在秒级攻击面前等于没有防御。 ## 六、写给运维的七条清单 把上面的分析收敛成可执行清单，按优先级排序： 1. **监控阈值按PPS设，不只按bps设**。22.2 Tbps攻击的平均包长只有约260字节，你的带宽利用率告警大概率根本不会响，包速率告警才会。 2. **自查并关停自家网内的放大器**：NTP关闭monlist、DNS递归只对本网开放、Memcached禁UDP、家用终端推送UPnP加固固件。每次放大系数表刷新纪录，前排协议里总有你网络里的设备。 3. **落BCP38/uRPF源地址校验**。反射攻击的前提是源地址可伪造，接入网每上量一个uRPF，全网攻击成本就抬高一分。 4. **CoPP与路由协议保活先于一切业务优化**，并在每次大版本升级后回归验证。 5. **预生成FlowSpec/RTBH预案模板**，把封堵动作做成“一键”，并把误伤代价大的动作单独分级审批。 6. **与上游抗D能力做真实引流演练**，至少覆盖“清洗回注”全链路，SLA里写死缓解生效时间。 7. **Flow数据留足留存周期**。攻击不只是安全事件，也是报案、监管通报和后续追偿的取证依据，不留flow等于白挨打。 ## 结语 从2013年Spamhaus的300 Gbps到2025年的22.2 Tbps，十二年74倍——攻击者用行动证明了摩尔定律在“破坏力”上同样成立。但对运维工程师来说，这次纪录真正的信息量藏在三个数字的除法里：260字节的平均包长提醒你看PPS而不是带宽，40秒的冲顶时间提醒你人工流程必须重构成自动化闭环，五万倍的放大系数提醒你源头治理才是最便宜的防御。纪录还会被刷新，大概率就是明年；而防御体系的每一次“提前量”，都来自把今天这份拆解真正抄进自己的网络里。 ## 参考来源 1. [Cloudflare mitigates record 22.2 Tbps DDoS attack（Cloudflare官方博客）](https://blog.cloudflare.com/cloudflare-mitigates-record-22-2-tbps-ddos-attack/) — 22.2 Tbps/10.6 Bpps纪录攻击的官方通报，本文核心数据来源 2. [Cloudflare DDoS威胁报告（季度系列）](https://blog.cloudflare.com/ddos-threat-report-2025-q3/) — 5.6 Tbps、7.3 Tbps等历年纪录及攻击趋势统计 3. [GitHub 2018年DDoS事故报告（GitHub Engineering）](https://github.blog/2018-03-01-ddos-incident-report/) — Memcached反射1.35 Tbps攻击的第一方复盘 4. [2016年Dyn网络攻击（Wikipedia）](https://en.wikipedia.org/wiki/2016_Dyn_cyberattack) — Mirai僵尸网络与Dyn事件的完整时间线 5. [Cloudflare学习中心：DNS放大攻击原理](https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/) — 反射放大系数与原理的公开科普资料 --- > 本文由「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 等场景全覆盖。