SDN环境下的DDoS检测与缓解机制

贾 锟 ,王君楠 ,刘 峰

1 中国科学院大学网络空间安全学院 北京 中国 100093

2 中国科学院信息工程研究所 北京 中国 100093

1 引言

软件定义网络(Software-defined Network,SDN)是一种新型的网络架构,旨在协助网络运营商更好地管理基础设施。基于这个目标,SDN 构建了一个中心化的结构,赋予控制器全局视角,使其得以动态化地管理旗下所有交换机。通过软件编程的形式,控制器可以快速定义和控制路由规则、设置网络拓扑、安装网络应用等。鉴于其良好的可编程性和全局性,SDN 被广泛应用于具有大量服务设施,需要统一配置管理的环境,如云端,医院和学校。但是其中心化的架构在网络攻击面前又极其脆弱。一旦核心控制器被攻陷,整个SDN 网络都会崩塌[1]。针对这种架构最常见的攻击手段就是分布式拒绝服务攻击(Distributed Denial of Service,DDoS)。

传统DDoS 一般由攻击者控制的僵尸网络发起。大量受控终端,通过向指定受害者发送泛洪式地应用请求,消耗目标的带宽和计算资源,迫使目标服务器停止正常的应用服务。如果目标位于SDN 架构,带宽耗尽时,同链路的其他服务器也会受到影响。

除了传统的 DDoS,研究人员也发现了针对SDN 本身的新型DDoS 攻击手法,如针对控制器中心架构的Packet-In 泛洪攻击[2],针对交换机的流表溢出攻击[2],针对流表计时器的慢速DoS 攻击[3]及针对南向通道的CrossPath 攻击[4]等。

为了缓解这些问题,研究人员提出了大量方案,包括基于异常检测的方案[5-9],基于架构革新的方案[10-11]和基于负载均衡的方案[12-13]等。SDN 独有的可编程特性和全局视角使得这些方案能够快速地实现和应用。

SDN 环境下的DDoS 检测方案关键要点在于能否保障轻量化和实时性。因为SDN 本质上是通过建立一个中心架构来实现控制层与数据层的分离,所以它的控制层需要承接旗下所有交换机的通信任务。如果检测机制不能做到轻量化,就会占据太多宝贵的计算资源；而实时性是DDoS 防御的基本要求。现在很多主流的攻击方式都采用间歇式爆发攻击策略,即短时间快速发起打击,在瘫痪目标网络之后迅速停止。如果不能做到实时检测,防御机制就无法从根本上阻止DDoS 的破坏。

调研发现,现行的DDoS 检测方案大都着眼于某些特定的攻击手段,无法在多种DDoS 攻击场景下保持自身的轻量化与实时性；此外,研究人员常忽略了在正常工作状态时或者检测告警前降低SDN 工作负荷的重要性,导致SDN 极可能在检测响应之前就被瘫痪。为改善以上问题,本文提出了兼顾轻量化与实时性,适用于广泛场景的快速检测方案。

本文的主要贡献包括以下三点：

1) 提出了轻量化的SDDetector 检测方案。该方案完全基于SDN 自身的API 实现攻击检测,不依赖任何外部的辅助工具；其轻量化不仅体现在攻击发生时检测响应的及时性,还体现在无攻击时对SDN控制器的减负效果。

2) 创新性地提出在不同状态下采用不同粒度的路由规则。具体来说,在没有攻击警报时,执行的是粗粒度的路由规则；在攻击警报发送到控制器时,执行细粒度的路由规则。这种设定能够过滤掉大量的重复流量和合法流量,从而极大地减轻控制器的负载,提升方案的反应速度。

3) 显著提高多种攻击场景下的检测效率。SDDetector 以近似并行的方式运行Packet-In 的检测手段和基于流表统计信息的检测手段,依据特征提取速度最快的算法来完成攻击检测。实验表明,在采用源IP 伪造技术的DDoS 攻击场景下,SDDetector能够比参照的单一SVM 检测机制少用75%的反应时间。

文章结构安排如下：第二章简要阐述SDN 的背景信息,并介绍了当前的研究现状；第三章详细介绍了SDDetector 的设计细节以及工作流程；第四章分别进行了熵检测方案、SVM 检测方案、特征有效性检验的相关实验,最后在实战场景下进行了模型的工作场景再现；第五章总结SDDetector 在多场景下提高检测效率的方式,提出仍面临的部分问题,并在最后说明方案未来的改进方向。

2 背景与相关工作

本章简单介绍软件定义网络和OpenFlow协议的基础概念,并对现有的研究工作做一个总结。

2.1 软件定义网络与OpenFlow

SDN 是一种颠覆传统网络基础架构的新型框架。由美国斯坦福大学clean-slate 研究组率先提出,以中心化代替分布式,软件代替硬件。通过从各设备中剥离出数据层和控制层,并整合控制层功能于高层级的控制器,将传统的分布式拓扑变成集中管理的层级结构。并在控制层引入可编程的特性,以简化网络配置等操作,实现了定义路由规则,改变网络拓扑等功能的程序化,打破了传统架构的封闭性和僵硬性。

OpenFlow 是一种实现SDN 框架的具体协议,或者准确来说,它构建了数据层的基本运行规则,以及数据层与控制层的通信模式。OpenFlow 通过在交换机中引入流表的概念,实现传统的路由功能。在流表与端口配置统计功能,并授予控制器请求访问的特权,使控制器获得全局视野。关于该协议的具体信息可参考OpenFlow Specification[14]。

2.2 相关工作

SDN 大量应用在云环境和医疗环境等基础核心产业平台中,因而针对SDN 的DDoS 容易连带地干扰寄生在平台上的大量服务,造成重大网络安全事故。为了预防这个问题,学术界提出了大量的检测防御方案。根据检测的方法可以分为基于统计的检测方案和基于机器学习的检测方案[15]。

基于统计的检测方案：通过提取统计特征对DDoS 攻击进行区分的方案。通常会设定一个阈值,超过阈值的流量则会判断为DDoS.Rui Wang 等人[5]提出了一个基于熵的检测方法,通过在交换机端部署一个数据收集器,并根据目的IP 的地址计算流的熵值。但是这个方案依赖于五元组(源IP, 目的IP,源端口,目的端口,协议)定义的流,这种检测方案快速且高效,但它需要单独部署一个额外的收集器,因为OpenFlow自带的流表可能不会指定具体的某个元素,如目的IP,这种情况检测方案就失效了。Mousavi 等[16]选择了一个相似的算法,但他是每50个数据包计算一次熵值。这种方法在真实环境中的应用效果不是很好,因为正常数据包的流量也很大时,往往会导致误判。Shariq[17]等人对每个数据包进行评分,评分原则基于源IP 是否在流表中,是否存在成功的TCP 连接过,协议类型,数据通信的速率。并采用动态自适应的阈值算法判定攻击是否发生。Xiang You 等[9]选择Packet-In 信息作为攻击的信号。我们前面提到了当交换机遇到无法匹配的数据包时,会触发Table-Miss选项,从而向控制器发送Packet-In信息。在攻击发生时,因为随机源IP 的技术,这种Table-Miss 情况会激增,从而导致大量Packet-In 消息。但是真实环境中,控制器极易在尚未来得及反应时就被瞬发的超大流量攻陷,因为这些Packet-In 信息都会通过南向接口发送到控制器。此外,采用真实源IP 的HTTP 泛洪攻击、SSL 泛洪攻击,因为不会激活大量Packet-In 信息,检测器就难以触发告警。

基于机器学习的检测方案：通过提取流经交换机的流量特征,并用机器学习方法进行恶意流量识别。在这之中,SOM 方法、SVM 方法和神经网络被使用得最为广泛。Braga 等[18]应用了一个轻量级的SOM 方法,在一个设定的时间窗口提取流量规则的六维特征,包括流量规则下的平均数据包数,平均持续时间等,然后用SOM 方法判断攻击是否发生。Jin Ye 等[7]通过Onp_Flow_Stats 信息收集流表的统计信息,并基于此提取源IP 的增长速度,源端口的增长速度,数据包数量的标准差,数据包字节量的标准差,配对流的比例等特征,最后用SVM 算法作为分类依据。但是特征配对流的比例在面对通配符时无法得到准备的 计算结果,影响了这个方法的普适性；如果为了解决这个问题又必须明确指定五元组的信息,又容易导致Table-Miss 的情况。类似的,Mehr[19]等人也采用了SVM作为他们的分类算法,但是他们生成的攻击流量仅仅每秒有25 个数据包。这可以在简单的实验环境下得到正确的检测,但在实际环境中,结果的可信度仍值得检验。

基于统计的检测方案和基于机器学习的检测方案都绕不开对OpenFlow 环境下流量特征的提取。主流的特征提取方式分为,基于南向通道的Packet-In特征提取和基于流表统计信息的特征提取。

基于Packet-In 特征提取的方案：交换机触发Table-Miss 选项后,会发送Packet-In 信息到控制器端。常见的SYN Flood、UDP Flood、ACK Flood 为了保护受控端,往往采用源IP 伪造的技术,因而会触发大量的Packet-In,基于此可以提取相应的异常特征。Da Yin[8]、Xiang You[9]、Niyaz[20]等人的工作都采用的这种机制。此外针对SDN 的Packet-In 和流表溢出攻击也有比较好的效果,因为他们本质上都需要随机生成匹配域,从而触发Packet-In。在以上攻击场景下,如果采用基于流表统计信息的方案,响应时间会因为南向带宽的堵塞以及交换机流表溢出而大幅增加。

基于流表统计信息特征提取的方案：在面对HTTP 泛洪攻击和不采用随机化匹配域中元素的DDoS 攻击表现卓越。因为他们能快速获取到流表特征,并能提取到更接近真实攻击流量的特征,如Rodrigo Braga[18],Jin Ye[7]等人的工作。但是在MiniNet 仿真环境下实践发现,流表中流规则数目过高时,会极大地增加流表统计信息获取的耗时。所以,在面对Packet-In 泛洪和流表溢出等新型攻击手段时,这种检测效率会大大降低。

表1 SDN 环境下的DDoS 检测研究汇总Table 1 Research of DDoS in SDN 类型

研究发现,现有的检测方案往往存在以下问题：

1) 基于Packet-In 特征提取的方案和基于流表统计信息进行特征提取的方案都不能很好地适用于广泛的攻击场景。

2) 研究大多针对于提高检测准确率而忽略了快速响应的需求,尤其是在面对不同的攻击场景时,系统的响应时间往往出入很大。

3) 研究均假定流规则是以细粒度五元组(源IP、目的IP、源端口、目的端口、协议)的形式呈现,而实际环境中,调整流规则的匹配域本应该是SDN 的常态。

4) 有些方案实际上是从传统DDoS 检测方式转移过来,没有很好地利用SDN 自身的全局特性。配置传统的检测方案通常又需要额外部署数据采集器,使方案变得异常复杂还增加了额外的开销。

5) 现有的研究方案大都着眼于在攻击发生时进行预警,从而针对性地遏止攻击流量以实现控制器的减负效果；忽略了正常工作状态时对控制器的降负。

为了尽可能在广泛的攻击场景仍能实现快速检测响应,并在正常工作状态时对控制器进行降负,本文提出了融合基于Packet-In 和基于流表统计的检测方案。方案重点考虑了如何在多种攻击手段下实现快速响应的能力,为此,我们以近似并行的机制运行两种检测方案,以响应速度最快的方式来判定攻击。推翻五元组的匹配域设定,改为在不同场景下应用不同粒度的匹配域,以尽可能降低交换机与控制器的运行负担。此外,本文还利用了控制器的全局视野,定位攻击源,并针对性地部署流规则以防御DDoS。

3 方案设计

围绕SDN 环境下的DDoS 检测与缓解需求,本文设计了面向多攻击场景的并行检测框架SDDetector。

SDDetector 核心功能均部署在OpenFlow 架构的控制器端。

SDN 的中心化架构赋予控制器遥控中枢的职能,在保障交换机正常路由功能的条件下,可以多样化定制其他的需求。开源的控制器API 又给了开发者一个很好的平台,可以快速且不干扰SDN 基础功能的情况下部署安全应用。

SDDetector 核心功能由五个模块组成,分别是数据监测模块、流规则模块、阈值警报模块、熵检测模块和SVM 检测模块。方案整体的工作流程如下：

1) 数据监测模块部署在控制器端,设定固定的时间间隔发起Onp_Flow_Stats 请求,获取交换机端的统计信息。

2) 阈值警报模块判定是否激发细粒度的流规则。其判定的依据为正向和反向数据包数量的比例,数据包的速率以及基于MAC 地址的熵值。如果超出阈值,该模块会尝试定位可疑受害者的MAC 和可疑攻击者的MAC。

3) 流规则模块负责下发针对性的流规则。有两种情况控制器会发送不同的流则。第一种情况,阈值警报模块触发,流规则模块删除初始的粗粒度流规则,改成细粒度的流规则。粗粒度的流规则指,只有交换机的输入端口、目的MAC 地址为具体的值,其他匹配域均为通配符ANY；细粒度的流规则指,除了上面两个元素以外,还有源IP 和目的IP,以及传输层协议为具体值。第二种情况,在进一步检测模块确认DDoS 攻击发生后,流规则模块将相应的数据流导流至流量过滤中心或简单的丢弃该流量。

4) 熵检测模块负责对发送到控制器的Packet-In消息进行相应的攻击检测。主要适用于流表溢出攻击和Packet-In 泛洪攻击等随机化源IP 的场景。

5) SVM 检测模块负责对可疑流量进行更多维的检测,其依赖的特征来源于控制器对细粒度流表统计的请求。只处理针对可疑者受害者的流量,以减少系统的工作量。

OpenFlow 交换机以流表(Flow Table)的方式实现传统交换机的路由功能。流表在SDN 架构中类似于现今传统网络路由器中的路由表,由很多条流规则(Flow Entry)组成。一条流规则定义一组路由指令,包括了匹配域、优先级、处理指令和统计数据等字段。当一个数据包流经交换机时,交换机根据匹配域寻找该数据包对应的流规则,如果有多个匹配的规则,则选择最高优先级的,随后根据该流规则的指令对数据包进行处理。

流规则的匹配域包含以下元素：

表2 流规则匹配域Table 2 Match Fields of Flow Entry

匹配域中的元素可以是具体的某个值,也可以是ANY 通配符,也就是可以根据需要定义一个宽泛的匹配域。如果数据包找到了匹配的流规则,那么它根据定义的指令进行相应处理；如果没有匹配的规则,则会触发一个Table-Miss 选项。这个选项会将该数据包的信息以Packet-In 模式转发给控制层。控制层再根据需要进行适当的处理,一般是添加匹配该数据包的流规则。

SDDetector 在初始阶段应用了一个粗粒度的路由规则,即匹配域中只指定In_Port 字段和目的MAC字段,分别代表从交换机的进入端口和流量的目标MAC 地址。当一个无法匹配的数据包到达SDN 交换机时,相应的Packet-In 信息会发送到控制器。如果我们初始就定义一个细粒度的流表规则的话,就可能导致大量不同源IP,不同端口信息的数据包触发Tale-Miss 选项,从而淹没交换机流表和控制器。粗粒度场景下的工作流程如图4 所示。

3.1 第一阶段统计信息请求

SDN 的端口和流表都配置了相应的统计功能。端口计数器负责统计流经该端口的数据包数量以及字节数。流表计数器记录匹配数据包的数量和字节信息之外,还需要记录流规则存活的时间。每一条流规则都设定了一个硬性存活时间和一个软性存活时间。在软性存活时间内如果没有接收到匹配数据包时,该流量规则就会自动清除；而硬性存活时间截止时,无论期间是否有匹配,都会强制清除该规则。

控制器通过Onp_Flow_Stats 指令获取SDN 网络的全局视野。当交换机收到这个指令后,会将所有的统计信息上传到控制器,许多安全功能、限流功能都基于此。

统计信息请求最重要的两个问题分别是,访问请求的时间间隔,信息获取之后的特征提取。

访问请求的时间间隔：数据监测模块基于预定义的时间间隔周期性地发起流表统计数据请求。预定义的时间间隔对于模型的运行效率具有非常大的影响。过长的时间间隔容易导致对攻击的响应过慢,从而无法真正抵御突发性的DDoS 攻击；而过短的时间间隔容易加重控制器和交换机的负担。我们经过多番实验以及参考Braga[18]等人的工作,选择了与之相同的设计,以3s 作为预设的时间间隔。

特征提取：Dayal[23]等人在一次DDoS 仿真实验中展示了他们总结的多个异常特征。可以看到常见的DDoS 攻击,如Smurf,UDP flood,HTTP flood 和SYN flood 都暴露出了基于目的IP 的熵值异常。所以,相似的针对局域网内部的MAC 地址,也有这样的异常特征。考虑到SDN 通常应用于无限网络,移动网络,企业网络和校园网络,这样的局域网假设是符合现实情况的。

DDoS 通常应用随机源IP、随机目的端口的技术以躲避溯源追踪,因而DDoS 流量通常只有很少的交互信息。我们收集的一个真实环境DDoS 流量显示仅仅有3%～4%的下行流量,也就是服务器到众多攻击源的流量只占据总流量的极少数,但是在一个正常的流量集中,下行流量占到了 45%～50%,所以我们也监测在交换机端的上下行数据包数量的比率。本文用tx 数量数据包表示从交换机视角发送的数据包,用rx 表示从交换机视角接收的数据包数量。

此外流经交换机的数据包速度是反映大流量异常的最直接特征。

以上三个特征目的MAC 的熵、上下行流量的比率、数据包速度作为本文阈值检测模块的基本判断依据。值得一提的是,以上三个特征均可以用来定位可疑攻击源和可疑攻击目标,后文提及的针对性流规则部署即依赖于此。

OpenFlow 协议的Onp_Flow_Stats 指令可以向控制器旗下的所有交换机请求端口、流表统计信息。

端口统计信息典型范例：

port"s3-eth1"：rx pkts=143,bytes=11952,drop=0,errs=0,frame=0,over=0,crc=0；tx pkts=116,bytes=9844,drop=0,errs=0,coll=0

流表统计信息典型范例：

cookie=0x0,duration=101.711s,table=0,n_packets=39,n_bytes=2982,priority=1,in_port="s3-eth1",dl_dst=00：00：00：00：00：06,actions=output："s3-eth3"

得到端口统计的数据与流表统计的数据之后,根据下面的公式即可得到目的MAC 的熵、上下行流量比率、与数据包速度。

3.2 阈值警报

在提取了目的IP 的熵,上下行流量的比率以及数据包频率三个特征之后,我们对攻击威胁作一个初步判断。如果之中有一个特征超过了预设的阈值,就会触发阈值警报。我们选取的阈值基于真实环境中DDoS 的流量信息和在MiniNet 环境下模拟的DDoS 流量信息得到。我们依据异常的统计信息,建立了一个简单的攻击定位和溯源机制。一旦后续我们的深度检测模块判定DDoS 事件发生,攻击源就可以确定。

3.3 修改路由规则

当阈值警报发出时,流规则模块会立马生成相应的细粒度路由规则替换原先的粗粒度规则。具体来说,控制器首先会指示交换机删除老的(攻击源端口,攻击目标MAC,action=output)的流规则。这样下一个指向受害者的流量会触发Table-Miss选项并被发送到控制器。然后控制器会针对地定义一个新的流规则(源IP,协议,目的IP,目的MAC,action=output)。这里同样为了避免Packet-In 泛洪,和Dayal 等[23]相比,细粒度的流规则并不考虑加入TCP 或者UDP 的端口信息,且只有针对受害者IP的流量才会适用于新的路由规则,这个措施可以大大地减少controller 的负担。在用户众多、服务器众多的云环境和校园网环境下,这种“降负”效果更明显。

3.4 第二阶段统计信息请求

这一次的统计信息依赖于 SDN 自带的Table-Miss 功能和流表计数器。前者会在新流到来后发送Packet-In 信息到控制器,后者同第一阶段基本相同,也是通过发送Onp_Flow_Stats 指令进行请求,只不过这次只提取细粒度流表的特征与端口特征,且特征的定义也不一样。详细描述如下。

1) 流规则的数量：每一个不同IP 的数据包都会请求新的流规则,所以我们可以发现在一次DDoS攻击中,流规则的数量大幅上升,我们用字符n代表流规则的数量。

2) 流规则下的数据包平均数量：OpenFlow 交换机会自动统计匹配该流规则的数据包数量。攻击者通常会生成随机的源IP 地址以防防御方追踪溯源。这个方法被广泛应用于SYN 泛洪攻击、UDP 泛洪攻击和ACK 泛洪攻击。所以当匹配域扩展到包括源IP时,流规则下的平均数据包数量会急剧下降。与之相对的,如果攻击者不采用这种源IP 伪造技术,那么流规则下的平均数据包数量又会大幅上升。

3) 流规则数据包数量的熵值：我们以一个细粒度的视角去定义熵值,而且我们只针对流向目标IP的流量,也就是我们统计符合目标IP 为受害者的流规则的离散度。

4) 目的IP 的熵：攻击发生时,流量往往集中在受害者,而目标为其他服务器的数据包占比会较小,这就导致了目的IP 熵值的异常。

5) 上下行流量的比率：当海量的流量涌向受害者,受害者通常不能正常地进行反馈回应。此外,如果目标端口不在服务端口中,那么服务器不会响应RST 数据。这些因素都导致了DDoS 期间的上下行流量的比率异常。上下行流量都是从交换机的视角去定义,也就是从交换机到终端的流量为上行流量,从终端到交换机的流量为下行流量,所以实际上在发生DDoS 攻击时靠近攻击源的端口,这个比率会低于1。

3.5 熵检测

与上面流表统计特征获取同步进行的是熵检测。熵检测模块部署在控制器端,在第一阶段的阈值告警之后就会自动触发,开始收集经由控制器的Packet-In 统计特征。因为我们的设计同时采用了基于Packet-In 的检测方案和基于流表统计信息的检测方案,我们希望尽可能突出两种检测方案的各自优势,减少两种检测方案的重复部分,因此此处我们只针对采用随机源IP 技术的攻击手段,如Packet-In泛洪攻击和流表溢出攻击。并针对性地只选择了两个特征,即源IP 的熵和目的IP 的熵。Xiang You 等[9]的方案选择了包括源IP 的熵、目的IP 的熵和目的端口的熵。并以1000 个数据包作为窗口,进行相应的熵值计算。本文的细粒度规则不涉及传输层端口,所以端口的熵值对于模型检测意义不大。

熵是反映数据分布离散度的指标,熵值比较高说明分布的集中度比较低,也就是更加离散；熵值比较低说明分布比较集中。极端情况,如分布在0点的概率为1,那么该分布的熵为0。熵的数学定义如下：

根据Xiang You 等[9]的论述,数据包的熵近似满足正态分布。正态分布具有高度对称性和集中性,绝大多数数据分布集中在均值附近。以明确的概率方式阐述即：

——以68.2%的概率分布在均值附近一个标准差的范围内；

——以95.4%的概率分布在均值附近两个标准差的范围内；

——以99.7%的概率分布在均值附近三个标准差的范围内。

本文选择两个标准差作为异常判定的标准,因为随机源IP 的攻击策略会导致源IP 熵值急剧增大,而针对性的泛洪攻击又会导致目的IP 熵值急剧减小,所以实际上我们只选择单一方向作为异常判定的标准,即：

同时满足这两个条件时,认为发生了Packet-In泛洪攻击。

3.6 SVM 检测

基于Packet-In 的熵检测方案也有它的劣势,其一是只有在拿到1000 个Packet-In 数据包之后检测才能进行,但是在交互式的DDoS 或者无源IP 伪造的攻击场景下,如HTTP DDoS、HTTPS DDoS,交换机并不一定能很快触发足够的Packet-In 消息。此外Packet-In 消息只反映新流的报文信息,也就是说已经有相应匹配流规则的数据包,是无法通过Packet-In 进行统计特征的提取的,而数据包的数量,流规则存活时间,流规则的数目等又是反映DDoS的关键特征。因而单纯依赖Packet-In 的熵很可能不能准确反映实际攻击的某些特征。

为了应对上面提到的交互式DDoS 和无源IP 伪造的攻击手段,同时选取更能代表真实流经交换机流量的特征,本文同步引入了一个SVM 检测方案来分类正常流量和攻击流量。这里说的正常是指在此期间不存在DDoS 行为,攻击是指在此期间存在DDoS 行为。文中针对的流量最小单元是时间间隔内的所有流量,而不是单个数据包或单个流规则。因为在攻击发生时,通常也会存在有正常的通信流量。得益于RYU 控制器的开源API,我们的SVM 检测模块可以轻松地部署在控制器端。SVM 的基本原理介绍如下。

SVM 分类模型：

SVM 最初是一种对数据进行二分类的线性分类器,通过计算得到一个超平面,以最低的误差将数据分割到超平面的两端。如图6：

超平面的定义为：

判定数据所属的分类是依赖于：

但是这种常规的SVM 模型只对线性可分割的数据有效。因而在20 世纪90 年代,一批学者提出了改进SVM 的方法,引入了核函数的概念,使得SVM 也能处理非线性可分的数据。

核函数的本质是将源数据从线性不可分的空间投影到线性可分的高维空间。常见的核函数包括高斯核函数(RBF),多项式核函数和Sigmoid 核函数。高斯核函数通过升维使原先线性不可分的数据变得线性可分,在现实场景中应用非常广泛。相对于其他核函数,高斯核函数更适用于样本数量可观,而特征维度较少的场景,因而本文最终选择了高斯核函数作为SVM 检测方案的基础。

3.7 丢弃或导流

根据分类结果,我们可以定制将攻击流量丢弃还是将其引导至专业的DDoS 清洗设备。值得一提的是,因为只有针对目标地址的流量才会引导至清洗设备,所以实际上SDDetector 还能降低外置的清洗设备的工作负荷。

本文整体方案的伪代码如下：

4 实验

本文的实验环境通过MiniNet 构建。MiniNet 是基于Linux Container 架构开发的一个进程虚拟化网络仿真工具。可以创建包含主机,交换机,控制器和链路的虚拟网络,其交换机支持OpenFlow1.1 和1.3协议。实验构造的拓扑结构如图7 所示。

根据传统的路由规则,所有流经路由设备的数据包都会修改源MAC 地址为该路由设备的MAC 地址,目的MAC 地址为下一个路由设备的MAC 地址。但是通过WireShark 抓包发现,SDN 网络内部并不会有这样的机制,也就是说数据包在SDN 环境下传输时,源MAC 和目的MAC 从始至终都不会发生改变,这对于我们的检测方案有着至关重要的作用。SDN模拟环境运行在Ubuntu 18.04.4 LTS 上。处理器为Intel core i7-8550U,2.00GHz,内存为8GB RAM。SDN 的控制器部署在另一台虚拟机,内存为4GB RAM。Hping3 作为生成攻击流量的工具,它可以定制从链路层到应用层的几乎所有报文信息,也可以自由设置攻击频率,数据段长度,还能选择是否随机化端口和IP。实验阶段生成了SYN DDoS、UDP DDoS、ACK DDoS,RST DDoS 和混杂型的DDoS 流量。并且在某些时间阶段,应用了源IP 伪造的技术。背景流量在用户终端抓取,并通过TCPRePlay 工具在SDN 模拟环境下进行重放。

为了全面地论证本文的方案设计,我们进行了多个实验,包括熵检测方案的实验,SVM 检测方案的实验,特征有效性检验的实验,攻防实战的实验。

4.1 熵检测方案的实验

3.5 节中提到,源IP 的熵和目的IP 的熵符合正态分布,为了验证这个结论,实验采集了4.5GB 的合法流量,计算得到了正常流量目标IP 分布的熵均值约为3.14,标准差为0.515；源IP 分布的熵均值为3.49,标准差为0.68。

通过将数据频次以直方图的形式描绘,如图8,我们可以近似看到目的IP 的熵的确呈现明显的正态分布特性。

4.2 SVM 检测方案的实验

为了验证SVM 检测方案的有效性,我们进行了SVM 检测方案的相关实验。该环节收集的DDoS 数据集来源于MiniNet 模拟器下的模拟攻击。其中的流量类型包括SYN DDoS、UDP DDoS、ACK DDoS、RST DDoS 和Mixed DDoS。Mixed DDoS 指混杂了以上多种DDoS 类型的攻击流量。为了较好地模拟真实环境,实验还在多个终端上收集了40GB 的正常通信流量作为实验的背景流量,并通过TcpReplay 工具在实验阶段进行重放。测试的DDoS 数据集来源于真实环境下的攻击流量和模拟环境下的攻击流量。真实的攻击数据采集于2018 年,包含常见的UDP DDoS,ACK DDoS 和HTTP DDoS,在17min 发出了总共22.3GB 的流量。将原始数据输入模拟的SDN 网络,交换机流表就会自动记录得到统计信息,再经过一系列运算处理,控制端才正式提取出来SVM 检测方案所需的五大特征。我们最初在选择使用哪些特征时,确立了一个基本准则,即特征的值应该尽量不受用户规模的影响,这样才能增加特征在不同应用场景下的普适性。在输入SVM 分类模型之前,提取的特征还需要经过sigmoid 函数做一个标准化处理,这能够协助SVM 模型实现更快速的收敛速度和更高的分类准确率。方案设置了50 轮的训练周期,直到模型达到收敛。

Jin Ye[7]等人的方案和本文的方案原理类似,均采用了基于SVM 的分类算法,但与我们不同的是,他们的模型特征从始至终都基于细粒度的路由规则。即便如此,我们的分类结果,也显示出优于他们测试结果的特性。表3 列出了SDDetector 与Jin Ye方案的分类结果对比。

表3 SVM 检测结果对比Table 3 Jin Ye’s Plan & Our Plan

同时也在表4 列举了SDDetector 针对真实攻击下的检测结果,以此证明实验结果的可靠性。

表4 真实环境下的检测结果Table 4 Detection Result in Real World

检测结果证明SVM 的检测方案可以很好地预警DDoS 流量,无论是实验环境下生成的模拟DDoS,还是真实环境下的DDoS。

4.3 特征有效性检验实验

决定检测方案有效性的一个核心因素就是特征的区分度,为此我们分别采集了合法流量,采用源IP 伪造技术的DDoS,以及采用真实IP 的DDoS,并计算流规则的数量、流规则下的数据包平均数量、流规则数据包数量的熵值、目的IP 的熵、上下行流量的比率具体值,得到以下实例图(图9～图13)。

其中绿色代表合法流量,黄色代表采用源IP 伪造技术的DDoS,红色代表采用真实IP 的DDoS。图10 中,因为实验条件受限,发起DDoS 攻击的主机数目较少,因而采用真实IP 的DDoS 与合法流量产生的流规则数目都太少,在比例尺下发生了重叠,所以只能看到一种颜色。

可以看到,在绝大多数情况下,三种特征的区分度都非常明显,因而能够证明其用来进行分类的有效性。

4.4 攻防实战实验

控制器在SDN 框架中扮演了核心中枢的角色。它负责监控整个网络的流量信息,部署新的流量规则,处理异常情况等。针对SDN 的攻击手段很多都利用其中心化的架构,达到瘫痪控制器就攻陷整个SDN 网络的效果,比如Packet-In 泛洪攻击。交换机的流表也是容易被针对的点,如恶意规则注入攻击[3],对流规则算法的探测攻击[24],以及流表溢出攻击[3]。

相对于传统DDoS,针对SDN 的Packet-In 泛洪攻击和数据层流表溢出攻击破坏力更大,也更难检测和防御。4.4.1 和4.4.2 对这两种新型DDoS 的原理进行详细介绍。

4.4.1 Packet-In 泛洪攻击

OpenFlow 作为实现SDN 框架的具体协议,针对流经交换机的数据包定义了一套完备的处理机制。首先,根据数据包的报文信息,找到优先级最高的匹配流规则,再执行流规则下定义的指令；如果没有找到匹配的流规则,则触发Table-Miss 选项,向控制器发送Packet-In 信息,请求控制器下发一套适用于该数据包的流规则。鉴于SDN 网络的中心化架构,数据包流经的所有交换机都需要向控制器发送一次Packet-In 信息,这对脆弱的控制器来说是一个极大的挑战。Packet-In 泛洪攻击的过程如图14。攻击者通过伪造匹配域中的元素,生成大量激发Table-Miss的数据包,迫使交换机发送Packet-In 数据包到控制器。控制器需要响应每一个Packet-In 信息,并下发相应的流规则。这不仅会堵塞南向通道的带宽,还会附带耗尽控制器的计算资源。据DevoFlow 测量,HP ProCurve 5406zl 型号的交换机仅仅可以支持17Mbps 大小的南向通道带宽[3]。

4.4.2 数据层流表溢出攻击

OpenFlow 交换机的流表也可能成为DDoS 攻击的目标。我们知道一个流规则必然指定某几个具体的元素,如果新的数据包到来不能匹配这些流规则的话,控制器会通过Flow-Mod 消息下发一个新的流规则。但是交换机能够维持的流规则数量是有限的。每个流规则本身会占据内存,同时他们还会维系一个计数器,负责统计流经的数据包数和字节数等特征；系统还需要对每个流规则进行相应的硬性存活时间和软性存活时间检查。每添加一个流规则都是对交换机的一次资源占用。目前大多数商用交换机都使用TCAM 存储流表。TCAM 是一种基于硬件的表项查找方法,支持对流表的并行访问,也就是说可以进行一次比对就完成对流表中所有规则的匹配,因而面对海量的数据流量,效率可以大大提高,且几乎不受表项数目增加的影响。但是其高昂成本和能耗导致很多商用交换机的存储容量极其受限。如Pica 8 商用交换机只能够存放8192 条流规则[25]。采用随机化数据包字段的DDoS 攻击能够迅速占满交换机的流表,导致新的规则无法添加,从而无法处理到来的新的合法数据。

鉴于Packet-In 泛洪攻击与数据层流表溢出攻击的巨大威胁,我们在设计DDoS 检测防御框架时,需要重点考虑尽量少地触发Table-Miss 选项,在之前研究中只有很少人提及这个想法。

4.4.3 两阶段攻击

为了验证SDDetector 在多种攻击场景下的检测效果,实验需要构造针对SDN 的Packet-In 泛洪攻击和流表溢出攻击。因为触发Packet-In 数据包只需要修改匹配域中的某个元素即可；触发Flow-Mod 修改流表的指令也是同样的原理。而本文方案细粒度流规则的匹配域包括了源IP,因而实验采用了源IP 伪造技术模拟针对SDN 的Packet-In 泛洪攻击和流表溢出攻击。实际上,如果匹配域包括了其他元素,实验也可以通过伪造其他元素触发检测。

实验分为两个阶段分别进行。第一个阶段引入源IP 伪造技术,模拟Packet-In 泛洪和流表溢出攻击,第二个阶段,采用真实源IP,模拟传统的ACK 泛洪攻击。下图15 表示的从攻击源抓到的流量分布图,图16 表示从受害者端抓到的流量分布图。图中显示攻击源抓到的流量会随着时间起伏,研究发现这是由于CPU 和网络适配器的性能不足导致的,即使在非MiniNet 环境下测试的流量也呈现这种状况。鉴于其不会影响整体的实验进程,我们大可以忽略不管。图15 展示实验在16：32：37 的时候激活了一次随机源IP 的SYN DDoS,与此同时,受害者端的下行流量开始迅速激增。随后模型探测到了可疑的攻击,删掉了相应的流规则,这导致在图16 中16：32：39 处流量的快速下降。紧接着,新的细粒度的流规则开始创建。引入的时间函数告知攻击在16：32：41 的时候正式被检测发现,并立即添加了丢弃来自攻击源数据包的流规则。然而图16 发现,流量并没有在16：32：41 直接下降到0。经过多番测试和验证,发现新的丢弃规则发送前已经进入交换机等待路由的数据包会继续向目标终端发送,因而仍会维持一段时间的数据传输。可以看到在受害者端的流量16：32：46 开始趋于0,而实际上从攻击源端看到的流量并未停止。在第二个阶段,实验采用了真实源IP 机制。流程图参见图17,图18。攻击发起于16：14：26 左右,被检测于16：14：32,与前面情况相同,受害者端的流量持续到16：14：37 才结束。但是从攻击源的流量可以看到实际上在16：15：02 的时候攻击才停止。

实验证明,本文提出的融合熵检测算法和SVM检测算法的方案能够在多种DDoS 环境下有效运行。Jin Ye[7]等人的方案也采用了SVM 的检测算法,但是他们从初始阶段就以细粒度的视角去做整体的检测,这就意味着DDoS 攻击时,控制器需要处理比我们多得多的Packet-In 信息,交换机也会运维比我们更多的流规则。而且,经过第一阶段的过滤,我们的模型只对流向目标终端的流量进行进一步检测,这能排除掉大量不必要的流量,节省运算资源,同时提高模型的检测准确率。

为了展示本文提到的方案在多种DDoS 攻击场景的效率,我们复现了Jin Ye 的方案,即从初始阶段就开始采用细粒度的流表规则,并直接获取所有的流表统计信息进行检测。同时引入计时函数,获取从收集统计数据到输出检测结果的耗时。

表5 方案耗时比较Table 5 Time consuming comparison of schemes

可以看到在面对采用随机源IP 技术的Packet-In泛洪攻击时,Jin Ye 的方案用时大大超过了我们的模型；尤其是攻击频率指数级增大的情况。原因很简单。拥塞的南向通道使得Jin Ye 等人设想的统计信息获取阶段耗时太久。实验发现,单纯算法提取特征并分类的耗时不超过0.1s,也就是说,方案的核心负荷来源于获取流表统计信息的过程。而SDDetector 在面对Packet-In 泛洪攻击时,优先基于熵的算法进行检测,只需要采集到1000 个Packet-In 数据包就可以完成,并在检测结果出来后,迅速就阻断了攻击源,防止持续的Packet-In 数据包冲击控制器。这些因素共同作用就使得我们的处理时间只占到他们处理时间的四分之一。

5 结论与未来工作

5.1 结论

本文提出了一个SDN 环境下的轻量级DDoS 检测与缓解方案。特别考虑了细粒度的流规则会给交换机和控制器带来沉重的负担,因而在两种不同的情形下配置了不同粒度的流规则。同时,模型也融合了适用于不同攻击场景下的检测方案,即针对Packet-In 泛洪攻击的熵值检测方案,和针对无源IP伪造的攻击手段的SVM 检测方案。并且,模型只针对流向可疑的攻击受害者的流量进行相应的细粒度流规则部署。这些举措都是为了尽可能地去降低交换机与控制器的运行负荷。通过实验发现,常规直接检测方案面对源IP 随机化时影响模型运行效率的最大因素来源于流表信息的获取,这导致检测的速率与保留真实源IP 时大相径庭。在这种情况下,我们的模型会优先选择更高效的基于Packet-In 的检测方案。但是面对如HTTP 泛洪攻击和HTTPS 泛洪攻击场景时,Packet-In方案又会因为需要等待足够检测基准的Packet-In 数据包,而浪费时间,此时SVM 检测方案反而能脱颖而出了。而且熵检测方案提取的特征,并不能很好地反映真实流经交换机的流量的绝大多数特性。SDDetector 还具备双层保险,即使瞬发的正常流量,如大热的电视剧播出时间,或者假日的网络购物促销,触发了阈值警告,熵检测模型和SVM 检测模型也能对其进行可靠的再分类。SVM 算法中选择的5 个特征和熵检测算法选择的2 个特征都能够明显地反映流量的异常。

5.2 未来工作

1) 实验发现如果交换机部署的是细粒度的流规则,那海量的数据极易引发Packet-In 泛洪,从而导致控制器的处理压力巨幅上升,这是SDN 的一个巨大隐患,但是绝大多数SDN 环境下的DDoS 研究都是基于单控制器[26]。未来我们需要尝试去解决这种由于中心化导致的单点失效的问题,通过引入多控制器的平台,实现控制器的负载均衡,从而有效增加SDN 网络的弹性生存能力。

2) 此外,因为RYU API 的限制,本文的两个检测手段实际上是以串联的形式布局,也就是需要先按照Packet-In 的模式做检查,如果熵检测模块没有得到检测结果,且耗时超过正常值时,我们会立马判定不存在Packet-In 泛洪,同时掐断Packet-In 检测,转而为SVM 检测。未来需要把这个串联的布局,改为完全并行的布局,两个方案同时实施,并且互相通信,一方完成攻击检测之后,另一方立即停止,降低负荷的同时,达到快速响应的目标。

3) 随着人们对SDN 的进一步了解,除了传统的泛洪式DDoS 外,还有一些精巧的DoS 手段也会对SDN 造成巨大的影响,如利用流规则Duration 的慢速攻击手段[27],因为每个流规则都定义了一个软性存活时间,在这个时间段如果没有匹配的数据包,则流规则会被自动删除。攻击者于是每次都在软性存活时间截止前发送一个数据包,从而能够长期维系流规则,还能减少Packet-In 和数据包数量上的异常。此外,还有针对SDN拓扑发现阶段的攻击手段[28],针对OpenFlow 处理机制漏洞buffered-packet 的攻击手段[29]都可能会造成SDN 的拒绝服务。未来还需要补充针对这些攻击手段的检测机制。

致 谢在此向对本文工作提出指导的老师、同学表示感谢,以及对提出建议的评审专家表示感谢。