01 · 攻击分类学:容量型/协议型/应用型
DDoS攻击按耗尽的资源类型可分为三大类,三者对防御体系的要求截然不同:
| 类别 | 目标资源 | 典型手法 | 防御重心 |
|---|---|---|---|
| 容量型 (Volumetric) | 链路带宽 | UDP Flood、各类反射放大攻击 | 上游清洗与带宽冗余;反射源治理 |
| 协议型 (Protocol) | 协议栈状态表(连接跟踪、会话表) | SYN/ACK Flood、TCP分片、GRE Flood | 状态卸载、SYN代理/Cookie、边界ACL |
| 应用型 (Application) | 应用进程资源(CPU、内存、后端连接) | HTTP Flood/CC、慢速攻击、DNS Water Torture、协议实现缺陷利用 | WAF与语义检测、速率与行为限制、协议栈加固 |
分类的实践意义:现实中大规模攻击几乎都是多向量混合——先以容量型攻击消耗带宽与清洗容量,再以协议型耗尽防火墙状态表,最后以低速应用层流量渗透。防御体系必须按"分层解耦"设计(第6页):任何单一设备(再大的防火墙)都无法独立承受三类攻击的叠加,这正是协同防御的根本理由。
02 · 容量型攻击与反射放大机理
2.1 反射放大攻击原理
反射放大攻击(Reflection/Amplification)由两个要素构成:IP源地址欺骗(受害方地址伪装为请求源)+放大服务(响应远大于请求的无认证UDP服务)。攻击者向开放的放大服务发送伪造源IP的小请求,服务将大响应发往受害者。因此治理需双管齐下:在骨干网落实源地址校验(BCP38/RFC 2827,2000年发布至今仍是关键短板),并收敛全球开放放大服务的暴露面。
2.2 主要反射放大面与收敛措施
| 服务 | 放大机理 | 危害程度与典型事件 | 收敛/治理措施 |
|---|---|---|---|
| NTP | monlist命令返回最近600个客户端列表 | 系数约556.9倍;2013—2014年广泛用于数百Gbps级攻击 | 升级ntpd≥4.2.7p26(默认禁用monlist)或在配置中禁用;限制对外UDP 123 |
| DNS | 开放递归解析器响应伪造查询(尤其ANY/大记录集) | 系数约28—54倍;开放递归器长期位列最大反射源 | 关闭对公网开放递归;部署Response Rate Limiting(RRL);缩小ANY响应 |
| SSDP | UPnP设备响应M-SEARCH多播查询 | 系数约30.8倍;消费路由器/摄像头是主要暴露源(与子课题01、03直接相关) | 路由器WAN侧关闭UPnP;SSDP服务不监听公网 |
| Memcached | UDP接口支持stats/get返回大量数据 | 系数可达1万—5.1万倍,史上最强放大面;2018年2月GitHub遭1.35Tbps攻击(Akamai披露);NETSCOUT(Arbor)随后披露观测到1.7Tbps级攻击 | 启动参数禁用UDP(-U 0)或升级至默认禁用版本;绑定内网地址;云厂商安全组默认封禁11211 UDP |
| CLDAP | 无认证的LDAP查询响应 | 系数约56—70倍;2017年起被大型DDoS租用平台采用 | LDAP服务器不暴露UDP 389至公网 |
| WS-Discovery | 本应仅限内网的多播发现协议(UDP 3702)暴露至公网后遭单播查询滥用 | 系数可达约300倍(NETSCOUT等公开披露口径);2019年起多次用于大型攻击,成为SSDP之外新的IoT放大面 | 边界阻断UDP 3702入站;发现服务不监听公网地址(与子课题01、03设备配置直接相关) |
| CharGEN/QOTD/TFTP等 | 老旧诊断/轻量传输协议 | 系数60—360倍;暴露面小但治理彻底(无人使用) | 直接停用对应服务 |
关键事实:2020年2月AWS披露其Shield服务缓解了一次2.3Tbps的UDP反射攻击(当时公开披露的容量型攻击峰值纪录之一);2021年11月微软披露Azure缓解3.47Tbps级攻击(多向量UDP反射,针对亚洲客户应用)。纪录的持续刷新说明:容量型攻击的上限由全球可被欺骗的放大资源总量决定,而非攻击者的带宽预算——反射源治理是全互联网的公共责任(BCP38与开放服务治理,见第6页)。
03 · 协议型攻击
- SYN Flood:海量伪造源IP的TCP SYN包耗尽受害者连接队列。防御三件套:SYN Cookie(Linux内核原生支持)、SYN代理(防火墙/负载均衡代为应答)、缩短半连接超时与队列调优。
- ACK/RST与分片攻击:伪造的ACK洪水消耗状态匹配资源;异常分片(重叠分片、碎片的微小分片)可绕过状态检测与触发重组开销。防御要点:状态表卸载至高容量专用设备、分片重组策略收紧、异常包型ACL。
- TCP状态耗尽型混合:Mirai的某些攻击模式即以"低速但高并发连接保持"消耗防火墙会话表——在容量型攻击掩护下极具隐蔽性。
- GRE/ESP隧道攻击:针对VPN网关与隧道端点的流量型攻击;防御依赖上游过滤与隧道端点的高可用设计。
协议型攻击的共同特征是目标并非带宽而是状态:防火墙、负载均衡、NAT设备的会话表容量(通常远低于接口带宽)是真实瓶颈。这也解释了为何"单机箱"抗D设备常在大攻击中失效——会话表先满,带宽再高也无意义。第6页的分层防御设计将状态处理尽量上移至少数高容量节点。
04 · 应用层攻击
4.1 典型手法
| 手法 | 机理 | 防御要点 |
|---|---|---|
| HTTP Flood/CC攻击 | 海量"看似合法"的请求(常选重计算URL如搜索、登录)耗尽应用资源;Mēris采用HTTP管线化(Pipeline)技术放大单连接请求密度 | 行为分析与令牌桶限速、JS挑战/CAPTCHA分层、URL级配额、缓存前置 |
| 慢速攻击 | 以极低速率发送请求头/体(Slowloris,2009年由安全研究者RSnake公开)或缓慢读取响应(Slow Read),少量连接即可拖垮Web服务器 | 头/体超时收紧、慢速连接断开策略、反向代理前置隔离 |
| DNS Water Torture | 僵尸网络向受害DNS服务器发起大量随机不存在子域查询,打垮权威/递归DNS | 权威与递归分离、随机子域速率限制、Anycast DNS、上游封锁已知肉鸡IP段 |
| HTTP/2 Rapid Reset | CVE-2023-44487(2023年10月披露):滥用HTTP/2的RST_STREAM帧在单连接内快速重置大量流,绕过并发流限制,以极小带宽制造巨量请求处理负载;Google披露峰值约3.98亿rps、Cloudflare披露约2.01亿rps、AWS披露约1.55亿rps | 及时升级HTTP/2实现(各厂商已发布修复);按连接重置速率异常检测;限制单IP/单连接流创建速率 |
| JS挑战绕过型 | 攻击者使用无头浏览器完整执行JS挑战,使"人机验证"成本优势失效 | 多信号联合评分(TLS指纹、浏览器指纹、行为轨迹)、与云清洗信誉库联动 |
Rapid Reset事件的里程碑意义:2023年10月的攻击首次把公开披露的应用层DDoS纪录从"千万rps级"推到"亿级rps",且利用的是协议实现缺陷而非僵尸网络规模——它提示防御方必须将协议栈安全更新纳入DDoS基线(与子课题01的OTA更新治理呼应),仅靠清洗扩容无法应对此类攻击。
05 · 攻击经济学与RDoS
- DDoS即服务(Booter/Stresser):平台化出售攻击能力,公开执法与研究报告(含Europol、FBI通报及学术测量研究)显示,单次攻击服务价格可低至数美元量级、月订阅数十美元——攻击门槛远低于防御成本,这是治理必须打击需求侧的根本原因。2016年安全记者Krebs公开报道vDOS平台(两名以色列运营者后被定罪)时,其内部数据库显示该平台两年间收入超过60万美元,可见市场规模。
- RDoS(勒索型DDoS):2015年起成为常态动机。标志性案例:2015年11月自称"Armada Collective"的组织勒索多家机构,瑞士加密邮件服务商ProtonMail公开承认支付了赎金后攻击停止——此类案例反复验证一个原则:支付赎金无法建立"免攻击"信誉,反而抬高行业勒索水位。2020年后伴随加密货币支付渠道,RDoS对金融机构、游戏、加密货币交易所的威胁持续存在。
- 动机结构:行业威胁报告长期显示DDoS动机集中于:游戏作弊与竞争(如2014年圣诞节LizardStresser攻击游戏平台)、敲诈勒索、黑产竞争打压、地缘政治表达(如2007年爱沙尼亚事件)。理解动机有助于预测目标选择与攻击窗口。
06 · 攻击趋势研判
- 纪录持续刷新但结构分化:容量型纪录由2.3Tbps(AWS,2020)到3.47Tbps(微软,2021);应用型由1720万rps(Cloudflare,2021)到3.98亿rps(Google,2023)。两类纪录分别对应"反射资源总量"与"协议实现缺陷",防御投资需双线并进。
- HTTP化与加密化:攻击流量中HTTPS占比持续上升(Cloudflare等多份年度报告口径),加密既掩护攻击内容,也使"以加密指纹识别肉鸡"成为关键防御技术。
- 利用IoT与云的双向寄生:攻击基础设施同时寄生在被控IoT设备(Mirai/Mozi)与滥用云资源/虚拟私人服务器上;云厂商滥用检测与IoT暴露面治理同等重要。
- 针对关键目标的"点穴式"攻击:Dyn事件证明攻击DNS、CDN等关键节点可实现"杠杆式"放大效应;对关键信息基础设施运营者而言,依赖单一上游服务本身即是风险敞口(第6页韧性设计)。