阅读： 16
随着社会各个行业对网络和应用程序服务的依赖性越来越高，它们的可用性变得像电力一样重要，尤其是对业务连续性有高需求的行业。比如当金融、网络服务供应、零售业等相关公司的关键业务应用失效时，运营和生产力便会停止，这意味着供应链和生产中断，导致收入损失、品牌损害、客源流失等后果。DDoS攻击试图耗尽网络、应用程序或服务的可用资源，旨在破坏业务连续性。当前，DDoS攻击呈现复杂化趋势、攻击规模不断增大、次数不断增多等。显然，对于高度依赖业务连续性的关键基础设施行业，DDoS攻击无疑是一大威胁。
本文首先对DDoS攻击作简要概述，其次对近五年来被公开披露且影响较大的DDoS攻击事件进行梳理，着重介绍近年来流行的反射放大型DDoS攻击及其载体协议，因为此类攻击追溯困难、具有放大效果、攻击成本低，越来越受到攻击者的追捧。最后分析首次利用DCCP协议进行反射放大型DDoS攻击的案例——DCCP DDoS攻击，旨在详细介绍不为人所熟知的DCCP协议以及攻击原理，提出防御措施。
一、DDoS攻击概述
DDoS攻击就是向目标设备发送大量的垃圾网络流量，耗尽应用程序、网络或网站的资源。DDoS即分布式DoS攻击，可以由多个源主机同时发送流量，相比于单个更加难以防范。DDoS攻击的分类方式多种多样，比较常见的分类方式有按照协议进行分类，例如IP、TCP、UDP、ICMP、HTTP等DDos攻击。也可以按照攻击方式进行分类，例如泛洪型攻击、反射型攻击、放大型攻击、慢攻击、混合型攻击等。DDoS攻击的表现形式主要有两种，一种针对网络带宽流量，通过利用大量攻击数据包使得网络带宽被阻塞，导致合法包无法到达主机。而另一种针对受害主机资源，通过大量数据包占用主机内存和CPU等资源，导致受害主机无法提供正常的网络服务。
全球网络每年遭受数以万计次的DDoS攻击，且攻击具有很强的策略性和针对性。Akamai研究人员披露的《2020年DDoS攻击研究报告》显示DDoS勒索攻击活动的数量、大规模攻击（超过100Gbps）开始急剧增加。该公司参与缓解的DDoS攻击中，有65%具有多向量攻击的特点，甚至有一次攻击多达14种攻击向量。绿盟科技在2020年的监测结果显示，受新冠疫情影响，国内二月份DDoS数量激增，攻击势力主要来自于境外，美国是最大的境外攻击来源国。国内医疗、教育、政府等行业因受到疫情影响遭受的攻击次数显著增长。DDoS攻击平均时长缩短，攻击成本也不断下降，中小型攻击取代了小型攻击，占据主导地位。Mirai和Gafgyt仍旧是当今世界范围内影响最大的两个Linux/IoT DDoS家族。本文通过对近五年公开披露且影响较大的DDoS攻击事件梳理（表1）可知，DDoS攻击事件主要集中在金融、政府机构、电信和现代服务行业，载体协议所在层级有网络层、传输层、应用层。
二、近5年重要DDoS攻击事件梳理
表1 近5年部分DDoS攻击事件
三、反射放大型DDos攻击
DDos攻击包括TCP洪水攻击（SYN Flood）、反射放大攻击（DrDos）、CC攻击（HTTP Flood）等，其中反射放大攻击（DDoS amplification attacks）非常巧妙，属于容量耗尽攻击，通过少量的精心构造的资源请求能获得超大流量的响应数据包，对目标网络资源造成巨大的消耗，达到“四两拨千斤”的效果。
事实上，自从2017年以来，反射放大攻击成为了攻击者们进行DDoS攻击非常重要的选择。由绿盟科技和中国电信云堤联合发布的《2020DDoS攻击态势报告》可知，相较于2019年，反射攻击增长明显，新型反射攻击层出不穷，占所有攻击类型的34%。常被用做反射放大攻击的协议载体有CLDAP、Memcached、SSDP、DNS、NTP、SNMP等。由卡巴斯基披露的《2021年第一季度DDoS攻击研究报告》显示，越来越多的可用于DDoS放大攻击的载体被发现，比如流媒体服务器中的PMSSDP服务、RDP服务、Powerhouse VPN服务器（the Chameleon protocol）、DTLS协议、DCCP协议等。加之随着越来越多的物联网设备接入互联网，攻击者也可利用物联网协议发动DDoS反射放大攻击，如2021年RSA大会中，绿盟科技在物联网安全论坛发表题为《物联网中基于UDP的DDoS新型反射攻击研究》主题演讲中提到的WS-Discovery、OpenVPN和CoAP三个物联网协议。理论上讲，已被详细分析并且给出防御策略的常见协议，比如NTP、CLDAP、Memcached等，不应该再出现类似攻击事件，但事实是利用这些载体的攻击依旧占据最大比例，原因就在于产品不会被及时更新或打补丁。表2总结了最常见和最新披露的部分反射放大型DDoS攻击载体。
| 载体协议 | 简介 | 端口 | 放大倍数 |
| CLDAP | 面向无连接的轻量目录访问协议，该协议的反射DDoS主要针对Windows服务器的活动目录服务Active Directory（AD） | UDP 389 | 56~70 |
| Memcached | 类似于Redis，一种键值缓存系统，开放11211端口、未设置安全检查 | UDP 11211 | 10000~50000 |
| SSDP | 简单服务发现协议，本质是一个在UDP上面的HTTP协议，支持请求根节点下所有设备的信息 | UDP 1900 | 30.8 |
| DNS | 域名系统，利用DNS服务器响应大于请求的特定数据包进行DDoS反射放大攻击 | UDP 53 | 50~179 |
| NTP | 网络时间协议，该协议允许网络连接的设备同步其内部时钟，通过利用在某些NTP服务器上启用的monlist命令，攻击者能够将其初始请求流量相乘，从而产生较大的响应 | UDP 123 | 556.9 |
| SNMP | 简单网络管理协议，通过一台客户端机器向一个被管理的设备发出查询请求，获取这台设备当前运行状态的检测情况等 | UDP 161 | 6.3 |
| TFTP | Trivial File Transfer Protocol（RFC1350），旨在UDP之上建立一个类似于FTP协议，但仅支持文件上传和下载功能的传输协议，所以它不包含FTP协议中的目录操作和用户权限等内容 | 随机UDP端口 | 9 |
| ARMS | Apple远程管理服务，即Apple远程桌面（ARO）的一部分，ARD启用后，ARMS服务开始在端口3283上侦听传输到远程Apple设备的入站命令。客户端向netAssistant服务端口发送一个UDP最小包，服务端会返回携带主机标识的超大包 | UDP 3283 | 35.5 |
| RDP | Windows远程桌面协议，将格式错误的UDP 数据包发送给开放了UDP 3389端口的RDP服务器便可以完成放大攻击 | UDP 3389 | 85.9 |
| PMSSDP | Plex媒体服务器是一个流媒体系统和个人媒体库，主要通过UDP端口32414完成SSDP（PMSSDP）请求响应服务 | UDP 32414 | 4.68 |
| DTLS | DTLS（数据传输层安全）协议用于在UDP 上建立安全连接，通过该连接发送大多数DNS查询以及音频和视频流量 | — | 36 |
| DHDiscover | 视频监控设备的设备发现服务，即会返回设备的诸多信息，如设备MAC地址、类型等 | UDP 37810、23000 | 200 |
| ADDP | Advanced Digi Discovery Protocol旨在进行设备发现，设备涉及Digi的多款产品，如Connect WAN 3G、ConnectPort WAN VPN等 | 2362 | 9 |
| discovery service | 利用Ubiquiti设备10001端口的发现服务可进行反射放大攻击 | UDP 10001 | 30~35 |
| WS-Discovery（ONVIF） | 是一种局域网内的服务发现多播协议，任何一个合法的IP地址发送服务发现报文给某个设备时，该设备就会对其进行响应 | UDP 3702或随机 | 300~500 |
| OpenVPN | OpenVPN是一个用于创建虚拟专用网络加密通道的软件包，允许创建的VPN使用公开密钥、电子证书或用户名/密码进行身份验证 | UDP 1194 | 5~60 |
| CoAP | 受限制的应用协议，是基于UDP实现的类HTTP协议，目的是让物联网中的资源限制型设备高效入网 | UDP 5683 | 34 |
| The Chameleon Protocol | 电源VPN服务器上的UDP端口20811运行一个尚未确定的服务，通过一个字节的请求包ping此端口，会响应一个大小是请求包40倍的包 | UDP 20811 | 40 |
| DCCP | 数据报拥塞控制协议，DCCP协议要求在数据传输之前进行三方握手，类似于SYN-ACK反射，但不同的是DCCP握手包含有数据 | 传输层协议 | 响应包相比于请求包多8个字节 |
四、DCCP DDoS攻击案例分析
在所有的反射型攻击中，反射型UDP攻击占比最多，这是因为TCP反射基本无放大能力，即攻击和发送的流量基本一致，攻击代价较高，被使用的较少。不同于表2搜集的大部分基于UDP的反射放大DDoS攻击协议，DCCP协议是一种传输层协议。显然该协议并不像TCP/UDP那样为人所熟知，DCCP协议相较于UDP协议增加了拥塞控制，主要为需要及时交付的流媒体应用程序服务。DCCP DDoS攻击案例是首次利用DCCP协议进行反射放大型DDoS攻击，该攻击不仅协议载体新颖，且无法通过对基于TCP/UDP攻击的防御措施进行防范。
（1）事件回顾：
2021年4月Akamai披露的高达800Gbos的DDoS多向量攻击过程中使用了之前从未使用过的协议载体，协议33，即数据报拥塞控制协议（Datagram Congestion Control Protocol，简称DCCP)。使用DCCP进行反射攻击类似于SYN-ACK反射。攻击看起来像是大量的欺骗DCCP请求（54 字节）数据包到达实际的DCCP接收主机。启用DCCP的主机将尝试完成与欺骗源主机的握手，从而产生DCCP响应（62 字节）反射，每个响应包大于请求数据包8个字节，虽然从数据量来看，DCCP反射攻击数据放大效果一般，但是由于DCCP反射攻击旨在绕过已知的基于TCP／UDP的攻击实施防御措施，并且只要攻击者在数据包中正确配置IP头，它们就能成功的将攻击流量路由给受害者。
DCCP协议由于非常适合于交付有时间限制且传输数据量较大的应用，比如流媒体、多人在线游戏、网络电话等，显然这些应用都非常流行。虽然该协议暂时还未被大规模使用，但是相较于采用UDP协议并单独设置拥塞控制机制而言，使用内置在Linux内核（版本2.6.14及以上）中的DCCP协议无疑是更好的选择。而一旦该协议得到全面采用，滥用此协议的攻击将会急剧上升。
（2）协议原理：
数据报拥塞控制协议(DCCP)是一种传输级协议，如TCP、UDP就是传输级协议，目的是解决许多不同的拥塞问题，尤其是对于不需要数据可靠性传输（TCP重传机制），但是需要拥塞控制的应用程序非常有用。DCCP是一个提供双向单播拥塞控制连接的不可靠数据包传输协议，它适合传输相当大的数据量的应用，并且能在时间线和可靠性上权衡。随着及时交付大于可靠性的流媒体应用程序在网络总流量中所占的百分比越来越大，它们很可能造成严重拥塞。而UDP协议虽然可以满足及时交付，但却没有拥塞控制，DCCP协议由此诞生。
DCCP是一个面向连接的协议，需要三次握手才能传输数据。实际上DCCP使用一个称为“半连接”的概念，DCCP半连接是单向的、不可靠的数据管道，大多数应用程序将创建两个半连接彼此明显分离，以便双向发送数据。两个半连接也可以绑定在一起，像TCP一样一个方向移动的数据包可以携带对另一个方向接收数据的确认。DCCP允许每个半连接确定自己的拥塞控制。目前有两个“拥塞控制ID配置文件”（CCID）。
CCID2，使用与TCP非常类似的拥塞算法。该算法能快速利用可用的带宽，同时在检测到拥塞事件时使用拥塞窗口快速响应。可以满足在线游戏最大限度利用带宽的需要。
CCID3，称为TFRC（TCP-friendly rate control），目的是避免带宽的快速变化，保证公平的对待网络用户。TFRC对网络拥塞事件的反应会更加缓慢，但随着时间的推移，将收敛到类似于TCP所选择的带宽利用率。适合需要发送源源不断的数据包的应用程序，如电话、流媒体，对于此类应用程序保持数据流比尽可能使用可用带宽更重要。
DCCP协议主要适用的应用程序包括流媒体，多人在线游戏和互联网电话。此外DCCP还有一些其它功能，旨在最大限度的减少开销，抵制拒绝服务攻击等。
由RFC 4340可知，DCCP通用报文头有两种格式：取决于X的值，当X等于1时，序列号有16+32=48bit，通用头部为16字节，而当X为0时，只有低位的24位序列号被传送，通用头部只有12字节。
源端口和目标端口，各16位，这两个字段用于标识连接。源端口表示发送主机上的端口，目标端口表示接收主机上的端口。与TCP和UDP一样，DCCP协议也会设置常用端口和非常用端口。
数据偏移，表示从DCCP数据报文的头部到应用数据开始位置的数据长度，以4字节为单位。当收到给定数据偏移小于最小报文头部和大于DCCP数据包长度的数据报时，接收端将其丢弃。
CCVal，4位，发送端用它来表明CCID类型。
校验和覆盖范围：4位，指明校验和的覆盖范围，通常包括DCCP头部和可选项，但有时也会将应用数据包括在内。
校验和：16位，基于覆盖范围计算校验和。
保留字段Res，3位，发送者必须在生成的数据包上将此字段设置为全零，接收者忽略该值。
类型，4位，指明数据包的类型，DCCP传输协议提供的数据类型如下表所示：
扩展序列号X，1位，设置为1时表示使用扩展的通用头部48位序列号，设置为0时头部只有2位序列号。所有的数据包中只有DCCP-Data、DCCP-DatatAck和DCCP-Ack允许将X设置为0或1。其余数据包类型，DCCP-Request、DCCP-Response、DCCP-CloseReq、DCCP-Close、DCCP-Reset、DCCP-Sync和DCCP-SyncAck都必须将X设置为1。
序列号，24位或48位，在所有数据包的序列中唯一标识数据包。
在所有当前定义的数据包中，除了DCCP-Request和DCCP-Data类型的数据包以外都携带了一个48位或者24位的确认号，当X为1时，确认号的格式为：
当X为0时，确认号的格式为：
保留字段，8或者16位，发送方需将保留字段设置为0，接收方忽略。
确认号，48或24位，即表示接收方接收到的最大序列号。
由于DCCP DDoS反射型攻击事件中只涉及两种数据包，DCCP请求数据包（DCCP-Request Packets）和DCCP响应数据包（DCCP-Response Packets），篇幅有限本文只介绍这两种数据包的报文格式。
| 通用DCCP报文头部，X=1，Type=0（DCCP-Request）16字节 |
| 服务代码（Service Code） 4字节（32位） |
| 可选项 |
| 应用数据 |
服务代码指明客户端应用程序想要建立的应用层连接服务，即该连接打算使用的应用层协议。
| 通用DCCP报文头部，X=1，Type=0（DCCP-Request）16字节 |
| 1位保留+48位确认号，8字节 |
| 服务代码（Service Code） 4字节（32位） |
| 可选项 |
| 应用数据 |
确认编号等于收到的DCCP请求上的序列号。
服务代码等于收到的DCCP请求上的服务代码。
DCCP协议包括握手阶段、数据传输阶段、连接终止阶段（挥手阶段），三个阶段分别涉及不同的数据报文，其中握手连接过程如下图所示：
通过报文格式以及握手流程可知，DCCP DDoS反射放大攻击所多出的8个字节数据为DCCP响应数据包的确认号部分。
（3）攻击流程：攻击者伪造源IP的DCCP-Request数据包发送到DCCP服务器，DCCP接收到请求数据包后返回给受害主机DCCP-Response数据包，消耗受害主机资源。
常用的DDoS攻击工具包括LOIC、HOIC、Slowloris、IP stresser等，这些攻击工具主要针对IP、TCP、UDP、HTTP等常见协议，并不支持DCCP协议。当前，Windows系统实现并不支持套接字类型SOCK_DCCP，故本文在linux系统下通过SOCKET套接字编程实现收发DCCP数据包，并用wireshark工具捕获握手阶段的DDCP数据包进行分析。
1、客户端发送DCCP请求数据包：总共90字节，源端口为40356，目标端口为123456，类型为Request（0），sequence Number=276065830449372；
2、服务器端发送DCCP响应数据包：总共114字节，源端口为12356，目标端口为40356，类型为Response（1），sequence Number=128884521706842，Ack Number=276065830449372；
上图可以看到请求和响应报文可选项的具体字段值与长度，请求报文可选项总长度为36字节，而响应报文为52字节。由于DCCP DDoS反射放大攻击来自这两个数据包，可以知道实际的DCCP协议响应数据包不只是比DCCP请求包大8个字节的确认号，还需加上可选字段多出的16个字节。
3、客户端发送DCCP确认报文：源端口40358，目的端口为12356，类型为Ack（3），sequence Number=276065830449373，Ack Number=128884521706842；
4、握手成功以后，客户端发送数据包到服务器端，源端口40358，目的端口为12356，类型为Ack（3），sequence Number=276065830449374，Ack Number=128884521706844；
（4）防御措施：由于反射放大攻击比较关键的一步是伪造源IP数据包，故对源IP限速、对已知的反射协议设置IP地址白名单依旧是有效的防御方式。
参考链接
[1] https://www.netscout.com/what-is-ddos#component–2
[2] https://www.cloudflare.com/zh-cn/learning/ddos/ransom-ddos-attack/
[3] https://www.imperva.com/learn/ddos/anti-ddos-protection/
[4] https://baijiahao.baidu.com/s?id=1684857827057139111&wfr=spider&for=pc
[6] https://blogs.akamai.com/sitr/2021/03/threat-advisory—dccp-for-ddos.html
[7] https://www.netscout.com/what-is-ddos/what-is-reflection-amplification-attack
[9] https://www.freebuf.com/articles/network/215983.html
[10] https://www.sohu.com/a/249602768_354899
[11] https://www.zoomeye.org/searchResult?q=port%3A5683
[12] http://blog.nsfocus.net/tftp-reflection-attack-analysis-report/
[13] https://www.freebuf.com/articles/network/215983.html
[14] http://blog.nsfocus.net/ripple20-digi-0717/
[15] https://www.freebuf.com/vuls/215171.html
[16] https://blog.csdn.net/Baidu_Secrity/article/details/113696802
[17] https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol
[18] https://www.wenmi.com/article/pt2tti009zxs.html
[19] https://lwn.net/Articles/149756/
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。