分类： 网络与安全
2011-10-21 14:11:53
挑战
在过去的十年，DDoS攻击成为了Internet的严重威胁。最近，由于人们每日的交流沟通、生产业务、甚至关键性的任务比如航空、紧急事务协同等，越来越依赖于，这种威胁变得更加严重。
就目前为止，DDoS攻击的手法已经有数十种之多，但从攻击手法的分类来说，DDos攻击可以以两种方式导致合法业务的拒绝：
(1) 通过大量的/复杂的流量，消耗掉中或者端主机的某些关键资源，以达到合法业务被拒绝的目的。此类攻击通常称为泛洪攻击;
(2) 利用路由器、端主机操作或某些应用程序中的缺陷，使服务不可用。此种类型的攻击通常称为弱点攻击。
相对应地，业界提出的DDoS防御工具也同样不少，而我们又如何评估这些防御工具孰优孰劣呢?
所谓的评估是基于测量的。准确测量DDoS攻击的影响，是评估某种DDoS攻击防御机制的基础。仅当某个DDoS攻击防御机制被证明可防御、或可消除DDoS攻击的影响，并将此防御/消除的过程对Internet用户透明时，才是有价值的。
如果我们可以测量(未采用防御机制时)某项遭到DDoS攻击的服务，那么就可以：
(1) 理解和表达出各种攻击的严重程度(比如，攻击A导致网络上的所有服务不可用，而攻击B仅仅对新的用户造成HTTP 服务不可用);
(2)确定某项DDoS防御机制的有效性(比如，DDoS防御机制A在遭到攻击1分钟后消除了90%的DDoS攻击影响)。
从而我们就可以在性价比上对不同的防御机制得到可比性依据。
传统的测量方法
某项对特定目标的DDoS攻击的总体影响通常是，“目标”运行变慢，或者对合法用户停止了某些需要的服务。
历史上，DDoS攻击的研究者们采用这样一些测量参数来判断攻击造成的效果：
(1) 没有收到回应的合法流量的报文百分比;
(2) 合法流量及攻击流量对资源的占用百分比;
(3) 合法流量及攻击流量的TCP的吞吐量或者Goodput;
(4) 合法流量全部事务的持续时长。
从这些测量参数可以获得DDoS攻击影响的基本情况，但没有真正测量到是否特定服务已经不可用了。
这是因为Internet的应用程序有着非常不同的[微软用户1] 需求。如在线游戏及其语音交互对哪怕100ms的延迟都相当地敏感，而FTP应用则可以忍受分钟级的延迟;语音应用程序对时延抖动敏感，而其他类型的应用程序则不是这样;多媒体和在线游戏对丢包敏感，而基于TCP的应用程序可以忍受相当数量的丢包并从中恢复。
可见，一定程度的时延、时延抖动或者丢包是否会导致DDoS的影响，依赖于特定应用程序的QoS需求。因此应该根据不同应用的应用层QoS需求，通过测量应用层QoS来评估不同的DDoS防御机制/工具的有效性。.
基于应用的测量方法
对DDoS攻击影响的测量，我们建议把网络中的合法流量以事务(Transactions)作为单位进行定义，并根据应用的类型进行分类。对每一类应用，定义特定的QoS需求，并以此来判断该应用是否达到了令人满意的服务效果。因而，对DDoS攻击影响的测量实际上就变成了：对每种不同的应用，测量不满足QoS需求的事务数的百分比。
基于应用的测量，其核心就是：测量在遭到攻击时合法的客户端是否收到了可接受的服务。
我们定义特定应用的事务transaction，比如文件下载、流量网页或者VoIP语音。对每种事务测量5个参数：
(1)单向延迟
(2)请求/响应时延
(3)丢包
(4)全部事务的持续时长
(5)时延抖动
依赖于不同类型应用的QoS需求，我们将事务分为几种不同的类型。然后，根据不同类型应用的门限值(应用的QoS需求)，来比较上面测量到的参数，以此判断每个事务是否成功，并对不同应用类型计算失败事务的百分比PFT(Percentage of Failed Transactions)。DDoS攻击的影响就可通过这些加权平均的PFT值来衡量，并可得到一个覆盖不同类型应用的柱状图。
应用的QoS需求
如果某种应用类型的QoS需求不严格，或者说应用范围不广泛，那么就不建议使用。比如在邮件服务器之间的SMTP应用(非实时、无单向延迟的要求、事务的请求响应时延可达4小时、无丢包率要求、无时延抖动要求)。
我们建议采用以下几种业务类型作为测量中的合法业务流量：
HTTP / Chat / DNS / 语音 / 视频 / FTP
对不同应用的QoS需求，采用3GPP的Universal Telecommunications System QoS性能需求的定义(其定义了不同类型应用的可接受的服务质量)。
|
应用类型 |
QoS分类 |
单向延迟 |
请求/响应 时延 |
丢包率 |
事务持续时长 |
时延抖动 |
|
Chat |
非实时 |
<30s |
无要求 |
|
|
|
|
Web |
实时,block |
|
any<4s 或maxRTT<4s |
|
<300% |
|
|
FTP |
实时,block |
|
any<10s 或maxRTT<10s |
|
<300% |
|
|
Telnet |
实时,block |
|
any<250ms 或maxRTT<250ms |
|
<300% |
|
|
DNS |
实时,block |
|
整个事务<4s |
|
|
|
|
ICMP |
实时,block |
|
整个事务<4s |
|
|
|
|
VoIP |
实时 |
<150ms |
whole<4s 或maxRTT<4s（control） |
<3％ |
|
<50ms |
|
视频 |
实时 |
<10s |
whole<4s 或maxRTT<4s（control） |
<1％ |
|
|
表1 应用类型分类及其QoS需求定义
应用的事务Transaction定义：
|
应用 |
事务 |
|
Chat |
TCP flow 且 inactive time >4 秒 |
|
Web，电子商务 |
单次 请求/响应 |
|
FTP，文件共享 |
单次 请求/响应 |
|
Telnet |
TCP flow 且 inactive time >4 秒 |
|
DNS |
单次 请求/响应 |
|
ICMP |
单次 请求/响应 |
|
语音及视频 |
TCP flow 及其 相关的UDP flow |
表2 应用的事务定义
【Flow：流，定义为两个固定IP地址和端口号的端口之间的所有流量。】
对于上述类型的应用，其事务的时延、丢包率等参数不符合表1中的QoS需求定义时，即可认为是失败。
测试数据的后期处理
对某些DDoS攻击来说，其攻击造成的影响仅仅在这种攻击持续过程中才会有，当攻击停止时，冲击也就停止了。因此，判断事务的成功与否，必须在DDoS攻击发生过程中才有意义。
在对DDoS攻击的冲击效果的测试过程中同时测量事务的成功/失败情况，可以通过这样的方法实现，即，对每种应用类型，计算失败事务的百分比PFT，并在柱状图中列出这些(不同应用类型的)数据。这对获得对某种应用的DDoS攻击效果很有用，例如，对Web服务的端口80的TCP SYN攻击。
对DDoS防御性能的评估来说，DDoS攻击冲击效果的影响是具备时间相关性的。这是因为DDoS防御机制起作用通常对于攻击来说有一定的时延，DDoS攻击的冲击效果从测量结果来看，在开始阶段要远高于后期(此时防御机制开始启动)。我们在DDoS攻击持续时间内，按照T秒为单位采样DDoS冲击效果随时间的变化，并按照下面的方式，对每个T秒的时间间隔计算事务失败率：
(1)在当前时间间隔内失败或者成功的事务数;
(2)在某个时间间隔内失败的事务，不再纳入到后续时间间隔内的PFT计算。
测试样例
现在通过一个简单的例子来说明上面提到的测量方法，测试拓扑如图1(DDoS防御性能与拓扑有密切关联)。
|
应用 |
事务 |
|
Chat |
TCP flow 且 inactive time >4 秒 |
|
Web，电子商务 |
单次 请求/响应 |
|
FTP，文件共享 |
单次 请求/响应 |
|
Telnet |
TCP flow 且 inactive time >4 秒 |
|
DNS |
单次 请求/响应 |
|
ICMP |
单次 请求/响应 |
|
语音及视频 |
TCP flow 及其 相关的UDP flow |
图1 测试样例的组网拓扑
合法流量说明：采用HTTP流量、Telnet流量、FTP流量、DNS流量、ICMP流量。
攻击流量说明：采用UDP泛洪攻击，攻击目的在于耗尽服务器侧的1.25MBps(10Mbps)的链路带宽。
【UDP Flood攻击：使用某个范围的虚假源地址，向目标网络设备发送一系列的UDP数据报文。此种攻击通常针对网络带宽，即造成链路拥塞。】
图2即为针对每种应用的、不同攻击强度下的PFT测量结果。从中可以明显看到执行时间较长的事务对UDP泛洪攻击更加敏感，比如FTP应用比Telnet应用对UDP泛洪攻击更敏感(即在攻击强度较小时有更高的事务失败率)，而仅当UDP泛洪的攻击强度达到(瓶颈链路)带宽的4倍时(上述测试拓扑中的10M链路)，DNS事务才会受到显著影响。
现在我们在上述中部署DDoS防御，并以相同的攻击注入，测量在启用DDoS防御机制后的攻击效果。(为说明本测试样例的DDoS攻击防护效果，避免在路由器和DDoS防护设备间出现链路带宽瓶颈干扰测试，我们部署的是GE链路。)
【对UDP Flood攻击的防护，业界有着不同的防御机制。本测试样例中，我们采用这样的机制：对受保护的服务器比如上图中的攻击目标机，手工或通过流量学习自动设置一个UDP会话的阈值，该阈值的大小依据应用环境中日常合法的UDP流量大小进行设置，超过阈值的UDP会话将被丢弃。本例中，我们设置为1000/S。】
在部署DDoS防护设备并使能UDPFlood防护功能、UDP会话阀值1000/S的条件下，应用层事务的失败率特性如图4(稳定后)。
Ÿ HTTP、ICMP得到很好的保护;
Ÿ FTP、Telnet应用也得到了较好的保护。以FTP应用为例，其失败率主要为瓶颈链路上与UDP流量的带宽竞争关系导致，但由于DDoS防护机制的作用，其失败率并未随着UDP Flood攻击强度的增加而受到影响;
Ÿ 而由于DNS业务通常基于UDP(DNS的数据大于512字节时将采用TCP)，因此上述DDoS防护机制在限制了UDP会话总量(1000/S)的条件下，DNS业务实际上与UDP Flood攻击流量竞争1000会话/S的门限资源。从数据上看，测试样例中采用的防护机制，对DNS业务的保护是不理想的。
作为对DDoS防护能力的评估，就如本文前面所提到的，希望能够确定该项DDoS防御机制的有效性，即上述的DDoS防御机制在遭到UDP Flood攻击多少时间后消除了多少攻击影响?
为简化数据及方便测试操作，此测试样例调整了评估DDoS防护机制有效性的出发点，即在防护机制启动后不同时间，对不同应用可以多大程度上消除UDP Flood攻击影响。
测试中在UDP Flood攻击影响稳定后，启动DDoS防御设备的UDP Flood防护功能，并以秒为单位检查各项应用的失败情况。通过数据分析，在启动UDP Flood防护功能后的第4秒，各项应用的事务失败率呈现出变化。
以HTTP事务为例，HTTP事务的失败率从第4秒开始下降，第7秒时HTTP事务失败率降低到0。因此可以认为该DDoS防御设备，对于HTTP应用，UDP Flood防护机制生效后7秒钟可将5Kpps、Packet Size 1000B的UDP Flood攻击影响降低到0。
【如下面的部分所阐述的，以上结论仅仅对此特定的DDoS攻击流量类型、特定的合法流量特征、特定的拓扑及该设备的这种UDP Flood攻击防护机制有效。】
其他影响因素
对于全面评估DDoS防御性能，实际上还有更多因素需要识别：
l DDoS攻击流量：即到达受害者的混合后的恶意分组、本地攻击还是分布式攻击、本次攻击中的攻击机分布状况及其活动性状况;
l 合法流量：即混合后的合法分组、在目标的通信模式。在攻击发生时，合法流量和攻击流量将竞争有限的资源。“合法流量”的特征决定着在此竞争过程中，合法流量受影响的程度。混合后的合法流量是评估DDoS防御的重要环节。测试中使用不同的混合流量，可能得到关于被测系统/设备性能的不同评估结论。
l网络拓扑及其资源：即目标网络的架构。这些特征标识了在DDoS攻击下的弱点，并包含了网络拓扑及其资源的分布。另外，某些防御措施的性能要依赖于评估活动中所选择的网络拓扑。因为DDoS攻击可能针对网络上的路由器、链路带宽或者服务;从多个攻击机发出的攻击流量可能在网络的某些节点汇聚起来，因此拓扑是评估DDoS防御系统性能测试活动中相当重要的影响。
对于整个DDoS防御性能测试来说，还需要考虑：
l防御机制：在最近几年业界开发了大量的DDoS防御系统。因为DDoS攻击具有多面性，所以对于某种特定的DDoS攻击，可能存在差别巨大的防御机制/方法。某些系统针对于攻击检测，而其他的系统则在保护合法用户流量的同时过滤攻击流量，甚至有些系统还可以跟踪定位攻击的源头，还有一些系统则通过调整下层的通信实现对某些特定类型的DDoS攻击的防御能力。为全面的评估某个DDoS防御系统，我们要了解攻击检测、响应、防护或者跟踪攻击源的机制，并通过逐渐加大攻击强度，进而发现攻击bypass或者导致防御系统崩溃的临界点。
