01 · 分层防御模型总览
大规模DDoS防御的根本原则是"分层解耦、就近消解"：让每一类攻击在它最有效的消耗位点之前被拦截。据此构建四层模型：
| 层级 | 职责 | 核心机制 | 典型主体 |
|---|---|---|---|
| L1 终端/源侧 | 减少肉鸡与放大源总量（治本） | 默认口令治理、固件更新、暴露面收敛（关闭开放递归/UPnP/monlist） | 设备厂商、终端用户、云平台 |
| L2 网络边界 | 协议型/应用型攻击就地消解 | SYN Cookie、ACL、WAF、速率限制、JS挑战 | 组织防火墙、负载均衡、云WAF |
| L3 上游/运营商 | 容量型攻击就近压制 | 近源清洗、RTBH、FlowSpec、骨干限速、源地址校验 | 接入ISP、骨干运营商、IXP |
| L4 云清洗/全球网络 | 吸收超大规模与全球分布攻击 | Anycast、分布式清洗中心、全球信誉库 | Cloudflare、Akamai Prolexic、AWS Shield、电信云堤等 |
攻击缓解决策链（每层内部同样适用）
检测—分类—牵引—清洗—回注—复盘的闭环
说明：本决策链为防御运营通用流程示意；各环节工具选型见后续各节。
02 · 云清洗与Anycast
2.1 Anycast的杠杆原理
Anycast让同一IP地址在全球多个节点同时广播，互联网路由自然将用户（及攻击者）引导至拓扑最近的节点。攻击流量因此被物理分散到整个清洗网络中"消化"——2016年Dyn事件中受影响的是DNS服务商本身，而非Cloudflare类Anycast CDN架构的客户，直观展示了该架构的杠杆效应。Anycast是防御容量型攻击的第一性杠杆：防御容量不再等于单点带宽，而等于全网节点带宽之和。
2.2 清洗服务形态对比
| 形态 | 原理 | 适用场景 |
|---|---|---|
| Always-on代理接入 | 业务常态经云WAF/CDN代理，攻击时无缝缓解 | 网站/应用类业务首选；DNS切换类攻击同样被其隐藏源站IP的能力保护 |
| 按需清洗（On-demand） | 平时直连，攻击时通过DNS切换或BGP引流至清洗中心 | 大流量非Web业务、成本敏感场景；切换时延是关键指标 |
| 永远在线检测+按需缓解 | 流量镜像持续检测，缓解动作按需下发 | 混合形态，平衡成本与响应速度 |
2.3 主要服务商（公开可查）
| 服务 | 说明 |
|---|---|
| AWS Shield | 集成于AWS的云DDoS防护（Standard免费集成、Advanced增值）；AWS公开的威胁态势报告披露了2020年2月2.3Tbps缓解案例（第4页） |
| Cloudflare | 基于Anycast网络的抗D服务（Magic Transit/Spectrum面向网络层与任意协议）；长期发布DDoS攻击趋势年度报告 |
| Akamai Prolexic | 老牌清洗服务；披露并缓解了2016年Krebs 620Gbps与2018年GitHub 1.35Tbps事件 |
| Microsoft Azure DDoS Protection | Azure平台原生抗D；微软安全博客披露2021年11月3.47Tbps缓解案例 |
| 中国电信"云堤" | 中国电信骨干网抗D服务（2015年推出），提供近源清洗能力，是国内运营商级抗D的代表性产品；三大运营商均建有骨干清洗能力 |
源站IP隐匿是隐性生命线：采用代理接入形态时，源站真实IP必须与任何公开渠道（历史DNS记录、子域解析、邮件头、证书透明度日志中的直连证书）隔离，否则攻击者可绕过清洗网络直连源站——大量"上了云仍被打瘫"的案例源于此配置疏漏。
03 · 上游与近源缓解技术
- 近源清洗（Scrubbing Center）：骨干网旁路部署的清洗集群，将攻击流量在运营商侧牵引清洗后回注；对容量型攻击的消解位置最接近"反射源与肉鸡"，带宽成本最优。国内以三大运营商骨干清洗中心与电信云堤为代表。
- RTBH（远程触发黑洞，RFC 7999）：受害方通过BGP社区值向上游宣告特定前缀或主机路由"黑洞化"，牺牲局部保全全网。RTBH有两种形态：destination-based（丢弃目标前缀全部流量，保住链路但业务全断）与source-based（丢弃来自攻击源前缀的流量，需严格 uRPF 校验支持，可在保住目标的同时部分恢复业务）。
- BGP FlowSpec（RFC 8955，替代RFC 5575）：以BGP消息向上下游下发细粒度流量过滤/限速策略（五元组+报文属性），实现"分钟级"的定向丢弃（如丢弃指向目标的UDP/11211流量）——比ACL手工配置快几个数量级，是现代运营商协同缓解的标准工具。
- 源地址校验（BCP38/RFC 2827、RFC 3704）：在全网入口过滤伪造源地址流量。这是根治反射放大攻击的唯一终极手段，但二十年部署仍不彻底（MANRS持续推动），第5节继续展开。
- 骨干限速与协议限速：对NTP/SSDP/CLDAP等历史放大端口在骨干实施默认限速（如运营商侧对UDP/123的异常大流量限速），以极低误伤成本压缩放大攻击空间。
04 · 目标侧缓解技术
| 技术 | 机制 | 注意事项 |
|---|---|---|
| SYN Cookie/代理 | 内核或前置设备延迟分配连接资源直至握手完成 | Linux原生支持；注意与某些TCP选项的兼容性 |
| 状态卸载 | 防火墙"无状态模式"或高性能专用设备承接大流量 | 牺牲部分审计能力换取状态表生存 |
| WAF与语义限速 | 基于请求语义（URL、方法、Token特征）的限速与阻断 | 规则过严误伤正常用户；需灰度与回退预案 |
| JS挑战/CAPTCHA | 以交互成本区分人机，过滤无头浏览器与肉鸡 | 对移动端与API业务需改用Token、签名等机器身份方案 |
| 缓存与降级 | 攻击期全站静态化、关闭重计算端点（搜索/导出） | "降级模式"应预置并演练，临时改代码风险高 |
| DNS防护 | Anycast权威DNS、响应速率限制（RRL）、随机子域限速 | 权威与递归分离；域名锁定防劫持转移 |
| 自动扩容 | 云环境弹性扩容吸收应用层压力 | 扩容有分钟级时延且成本敏感；应与限速联动而非单独依赖 |
05 · 全局协议治理：BCP38/MANRS/RPKI
- BCP38（RFC 2827，2000年；BCP84/RFC 3704更新）：要求网络在入口丢弃源地址不属于本网段的流量。若全球严格落实，反射放大攻击将因无法伪造源地址而基本失效——这是成本收益比最高的全球治理工程，但依赖每个网络逐一落实，推进二十余年仍未完成。
- MANRS倡议（2014年由互联网协会ISOC发起）：以路由安全四项行动（过滤、地址验证、协调、全局可见性）汇聚运营商、IXP与CDN共识，将反伪造源与路由防泄漏纳入行业自律基线。
- RPKI与路由源验证（RFC 6811）：通过RPKI ROA声明IP前缀的合法来源AS，防止BGP劫持——它同时保护DDoS缓解基础设施本身不被劫持（如将清洗流量重定向）。
- 开放服务治理：关闭开放递归DNS、NTP monlist、SSDP公网暴露、Memcached UDP等放大面（具体清单见第4页2.2节），由"扫描—通报—整改"机制驱动（Shadowserver等向网络所有者免费通报暴露服务）。
结构性结论：DDoS防御的"技术天花板"不在清洗中心，而在全球BCP38与开放服务治理的完成度。任何组织在规划防御预算时应明确：清洗是止血，协议治理才是止血带。这一判断对监管投入与产业协作方向具有直接指导意义。
06 · 协同机制与演练
- 跨层联动流程：检测（L2/L4）→判定→按预案触发L3引流或L4清洗→上游协同（RTBH/FlowSpec社区值预先与ISP约定）→业务侧降级。联动接口、授权联系人、决策时延阈值均应事前书面化——DDoS期间不可能临时谈判。
- 上游多样性：关键业务的多线接入与多CDN互备可避免"单一上游被打穿即全断"；Dyn事件的教训之一正是DNS依赖集中。
- 演练机制：基于真实预案的桌面推演与可控实弹演练（利用压力测试服务商的合规授权测试），覆盖"夜间/节假日""清洗切换失败回退""上游不响应升级路径"等失败分支；演练结论回流预案版本管理。
- 行业协同：通过ISAC、运营商安全工作组等渠道共享攻击指纹与肉鸡情报（第5页）；对关键信息基础设施运营者，《关键信息基础设施安全保护条例》框架下的应急演练为法定化要求。
- 与僵尸网络治理联动：DDoS攻击期间采集的指纹与源数据应立即反哺情报体系，支撑近源压制与执法线索沉淀——"防御一次、清账一批"。
07 · 新技术趋势与工程展望
在经典四层模型之上，以下方向正在重塑DDoS防御的工程形态（均为公开可查的产业趋势，不涉及特定未公开产品能力）：
| 方向 | 机制与价值 | 注意事项 |
|---|---|---|
| 内核级包处理（eBPF/XDP） | 在网卡驱动层直接丢弃/限速恶意包，单节点缓解能力向千万pps级演进，摆脱专用硬件依赖 | 程序正确性须严格验证；升级与回滚机制必须内建 |
| 清洗能力边缘下沉 | 检测与缓解逻辑部署至PoP/边缘节点，缩短攻击路径、降低骨干回传压力 | 与Anycast架构天然契合；跨节点策略一致性管理复杂 |
| 加密流量AI检测 | 以TLS指纹与流量时序特征识别肉鸡信标及HTTP Flood，弥补内容不可见缺陷 | 需持续对抗样本漂移；误报治理与可解释性要求高 |
| HTTP/3与QUIC迁移 | QUIC的连接迁移与全加密改变了L4清洗与限速语义，防御规则需同步演进 | UDP 443的放行与限速策略须重新评估 |
| 自动化协同（SOAR） | 检测—牵引—清洗策略下发全流程自动化，将MTTM压缩至秒级（与第8页度量指标衔接） | 自动化必须有熔断与人工接管通道——防御误动作同样受法律约束（第8页） |
选型建议：新技术应作为四层模型的增强而非替代——eBPF解决单机性能、AI解决加密盲区、SOAR解决响应时延，但分层解耦、就近消解、上游多样性的架构原则不变。投资优先级应服从第4页攻击分类学的结论：先补齐最薄弱环节，再引入增强能力。