DDoS客服协同防御机制研究

黄 强， 叶 震

（合肥工业大学 计算机与信息学院，安徽 合肥 230009）

0 引言

一般DoS（Denial－of－Service，简称 DoS）攻击是一种使服务器无法为正常用户提供服务的攻击行为，是攻击者发送大量的网络封包（Packet）到受害者（Victim）的主机服务器上，致使受害者的网络带宽耗尽，网络完全陷于瘫痪，或者造成服务器主机在同一个时间内接收大量的数据报连接请求，以至于超过服务器在该时间内能够处理的数据报的上限，从而使服务器无法响应其他正常用户的合法请求［1］。

在因特网上，DoS攻击的目的是破坏由中间设施网络或者末端服务器提供的各项服务，当发起的DoS攻击源数目众多时，称此时的攻击行为是 DDoS（distributed denial of service，简 称DDoS）攻击。攻击源的数目越多，其攻击能力就越强，从而防范也就变得越复杂。一个典型的DDoS攻击可由以下2个部分组成［2］：捕获“傀儡机”，即通常所说的“肉鸡”，通过一些手段发现傀儡机的漏洞，向其注入发动DDoS的攻击程序；通过主控机向傀儡机发送攻击信号，再由傀儡机向攻击目标发动攻击。

研究如何防范DDoS攻击对保护Internet的安全性和稳定性具有重要意义，一般对于DDoS攻击分为4个大类［3］：预防、检测、源追踪以及响应。在这4个方面吸引了国内外很多学者的注意，尤其是在攻击检测方面，更是运用了很多算法。文献［4］使用非参数的CUSUM算法来检测DDoS攻击，减少了漏报率和误报率，并且消耗较少的计算机资源；文献［5］提出了基于攻击流量特征聚类的特征提取算法，能够有效地进行检测过滤，减少攻击包传播的危害，保护有限的网络资源；文献［6］利用马尔可夫链模型通过统计的方法来学习网络的正常行为，将正常行为与当前网络行为进行比较来检测攻击；文献［7］利用数据挖掘中的关联算法和聚类算法，通过分布处理数据来检测攻击。但是，这些检测算法在检测攻击结束时刻的延迟均比较大，而且目前大部分攻击检测算法都是基于目的端（受害者端）［8］进行的，虽然受害端的攻击流量大，攻击特征明显，在受害端检测准确率会比较高，其受害端检测DDoS攻击存在以下问题。

（1）难以从正常的数据流中隔离出攻击流。

（2）发生攻击时受害端负载大，实施检测算法需考虑主机性能、处理能力和各方面的开销。

（3）当检测到攻击时，攻击已在实施，甚至已经完成攻击，往往来不及响应。

基于以上分析，本文提出了从傀儡机端（客户端）和服务器端进行协同防御的机制，当客户机成为傀儡机后，将防御此种DDoS攻击的任务合理地分配给傀儡机和服务器，由两者共同完成。对于非面向连接的攻击，主要采取在傀儡机端进行主动检测防御，而并非是基于受害端进行的攻击检测，这样使攻击流在进入网络前就被主动丢弃，从而将攻击的危害程度降到最低；对于面向连接的攻击，采用客服协同的SYN Cookie技术，使SYN Flood攻击的资源消耗失效，同时避免了传统的SYN Cookie技术可能带来的TCP－ACK攻击，从而主动有效地防御攻击DDoS。

1 DDoS客服协同防御机制

1.1 傀儡机端检测防御机制的提出

傀儡机是DDoS攻击的实施者和传播者，因此在傀儡机上防御此类攻击是可行有效的，只需把防御措施当作补丁安装到每台客户机即可。在傀儡机端防御通过傀儡机发动的UDP泛洪、ICMP洪流攻击不但可以大大减轻服务器端的防御负担，而且由于在攻击流进入网络前就将其丢弃，可以减轻甚至消除攻击流带来的网络拥塞，另外还能够检测出客户机是否受到黑客控制。因此，在傀儡机端进行检测防御具有花费代价小、实施简单、更具主动性、将危害降到最低等特点。

1.2 傀儡机端检测原理

客户机发送数据包前，分析所有数据包包头，丢弃源地址不是本机地址或是有分段的数据包。若数据包通过了以上检测，则根据协议类型采取不同的防御规则。

1.2.1 UDP数据包过滤规则

UDP数据包过滤规则，如图1所示。

图1 UDP数据包过滤规则

对于UDP数据包，丢弃源端口和目的端口相同的数据包，同时知道UDP协议是不可靠的传输，主要用于DNS、Network Time Protocol、Multimedia－Streamin、VoIP、Network File System和Chat Application等，通过UDP来通信的应用都有一个比较稳定的数据率，而且对每个目的地址只连接很少的端口。正常的UDP会话一般都使用小的UDP包，通常有效数据内容不超过10字节，且数据包的大小是不定的，随机性很高［9］。因此，可以通过限定每个目的地址单位时间内连接的源目的端口对数量来防御对服务随机端口的扫描，而对于UDP旧数据流（通过目的地址，源目的端口判断），通过该数据流的历史表现（如数据包大小异常）和数据率来判定是丢弃还是放行。

对于UDP数据流本文用到了自己定义的数据结构体DD－UDP－Log－Node和DD－UDP－Conn－Node用于记录最新时间、目的IP、源端口、目的端口、失败次数、成功次数、每个目的IP的端口对使用数量、数据包长度和指向下一节点的指针。一方面用于检查现数据包的“新鲜度”和便于日志的清理，另一方面用于检测旧数据流的历史表现行为（如数据包长度异常，所请求的服务器端口是不开放的），从而判断该数据流的攻击性。

1.2.2 ICMP数据包过滤规则

对于ICMP数据包，由于ICMP是网络控制，专门用作逻辑错误和诊断的信使。且普通用户并不会频繁地使用需要回应的ICMP请求应答报文，正常的ICMP消息也不会超过64～128字节。因此，可以通过限制单位时间内主机发送出去的ICMP包，有效地防御利用ICMP来进行DDoS攻击，同时对于接收到的ICMP包，过滤掉需要回复的请求包，从而有效防御Smurf攻击。当接收“目的端口不可达”的ICMP包时记录该不可达端口，以用于防御UDP洪流攻击该端口而使服务器忙于回复“目的端口不可达”报文。

对于ICMP包也同样定义了自己的数据结构体DD－ICMP－Log－Node，用于记录最新事件、目的IP、发包数量和指向下一节点的指针，相应的软件流程如图2所示。

图2 ICMP数据包过滤规则

1.3 客服协同的SYN Cookie机制

本文采用客服协同的SYN Cookie技术防止SYN DDoS攻击，该机制很好地借助客户机，不但保留了SYN Cookie技术的优点而且较好地弥补了它的缺点，能够有效地防止SYN DDoS半连接攻击，使得服务器的资源不会被攻击耗尽。

客服协同的SYN Cookie机制原理如下：

（1）当客户机端发出一个SYN连接请求时，在内存中做相应的记录，作为检验ACK数据报的依据。

（2）在TCP服务器收到TCP－SYN包并返回TCP SYN－ACK包时，不分配一个专门的数据区，也不计算Cookie值。

（3）客户机端在发送ACK确认时，检查是否有与之对应的SYN请求，若有，说明这是正常的连接请求，放行；否则，说明这是攻击数据流，丢弃。

（4）在收到TCP－ACK包时，再分配专门的数据区，从而使客户端与服务器之间建立一个完整的TCP连接，为以后的数据交换服务。

对于TCP数据流本文用到了自己定义的日志结构体DD－TCP－Log－Node，用于记录最新时间、创建数据流的时间、源IP、目的IP、源端口、目的端口、数据流状态、SYN包通过次数、向服务器发送的最新确认号、下一次应发送的确认号上限、数据流速和指向下个节点的指针。该结构体用于检查现数据包的“新鲜度”，便于日志的清理工作，用于记录检测的SYN数据包和ACK数据包的行为状况，从而决定该数据包的放行与否。在进行流速限制时，通过直接改变发送窗口的大小来实现。

TCP数据报的过滤规则，如图3所示。

图3 TCP数据报的过滤规则

由于TCP是一个可靠的面向连接的数据流协议，TCP传送的报文可以看成是连续的数据流。在每个TCP包中都包含一个序列号Syn－Number和一个确认号AckNumber，SynNumber是本报文段中所发送数据的起始字节编号，Ack－Number表示期望收到对方发出的下一个报文段数据部分的起始字节编号。在TCP服务器收到客户端发来的一个TCP－SYN数据报时，检查该报文的序列号SynNumber，并返回一个TCPACK数据报，该报文中包含了确认号AckNum－ber，而此时 AckNumber＞SynNumber，确认号符合要求，若AckNumber＜SynNumber，则客户端即可认为确认号不符合要求，从而丢弃该数据报。

2 仿真实验

为了验证提出的DDoS客服协同防御机制的有效性，在仿真软件模拟试测中建立2个场景，每个场景主要由普通用户节点、攻击节点、路由器和服务器构成。第1个场景中，傀儡机端和服务器端都不添加过滤规则；第2个场景中，在傀儡机端添加过滤规则，在服务器端添加VDR分析［10］。在2个场景中分别用不同种类的DDoS攻击方法攻击服务器，查看仿真结果中客户机端和服务器端的数据流量，以证实该机制的防御效果。

（1）对UDP和ICMP攻击防御客户端结果如图4和图5所示。图4中，红线表示正常的客户端数据包流量，绿线表示未添加过滤规则的攻击端数据包流量，蓝线表示添加了过滤规则后的攻击端数据包流量。

图4 UDP客户端数据流平均时间拦截图

图5 ICMP客户端数据流平均时间拦截图

图5中，蓝线表示正常的客户端数据包流量，绿线表示攻击端数据包流量，红线表示实施过滤规则后的攻击端数据包流量，从中可以看出仿真环境中的客户端防御系统对UDP和ICMP攻击起到了非常好的抵御作用。

（2）对TCP SYN攻击仿真结果。受攻击的Web服务器数据流量，如图6所示。

图6 受攻击的Web服务器数据流量

从图6可以看出，由客户端发出的TCP连接请求，在没有客服协同的SYN Cookie机制的过滤规则下，大量的带有攻击性数据包被客户端放行，致使服务器遭受了攻击，而采取了客服协同的SYN Cookie机制的过滤规则后，大部分攻击性的数据包被过滤并丢弃，从而减轻了服务器端的压力，不至于使服务器遭受巨大的攻击而无法响应其他正常的TCP连接请求。

3 结束语

本文首先引出了4类DDoS攻击抵御机制，并着重分析了攻击检测方面的一些方法，然后提出了DDoS客服协同防御机制，即通过傀儡机端主动检测和客服协同的SYN Cookie技术来抵御DDoS的攻击，初步的仿真实验已经验证了其有效性。

［1］杨子翔，蔡锡钧.Network DoS／DDoS攻击及预防方法之研究［EB／OL］.［2000－10－21］.http：／／www.nckv.edu.tw／TANET2000／download／A3－2，2000－10－21／2010－12.

［2］Wang H N，Zhang D L，Shin K G.Detecting SYN flooding attacks［C］／／INFOCOM，Vol 3，2002：1530－1539.

［3］Sun Z X，Tang Y W.Router anomaly traffic filter algorithm investigation based on character aggregation［J］.Journal of Software，2006，17（2）：295－304.

［4］Du Ping，Nakao A.Mantlet Trilogy：DDoS defense deployable with innovative anti－spoofing，attack detection and mitigation［C］／／2010Proceedings of 19th International Conference on Computer Communications and Networks（ICCCN），2010：1－7.

［5］高 能，冯登国，向 继.一种基于数据挖掘的拒绝服务攻击检测技术［J］.计算机学报，2006，29（6）：944－951.

［6］陈 伟，何炎祥，彭文灵.一种轻量级的拒绝服务攻击检测方法［J］.计算机学报，2006，29（8）：1392－1400.

［7］雷 颖.DoS／DDoS攻击原理与防范［J］.微计算机信息，2010（24）：77－79.

［8］Kumar P A R，Selvakumar S.Distributed denial－of－service（DDoS）threat in collaborative environment：a survey on DDoS attack tools and traceback mechanisms［C］／／IEEE International Advance Computing Conference，2009：1275－1280.

［9］Mirkovic J，Reiher P.D－WARD：a source－end defense against flooding denial－of－service attacks［J］.IEEE Transactions on Dependable and Secure Computing，2005：2（3）：216－232.

［10］叶 震，施伟伟.基于TCP－IP报头分析和主动测试的DDoS攻击响应机制［J］.合肥工业大学学报：自然科学版，2010，33（3）：363－367.