云计算环境下TCP-SYN Flood攻击防御策略研究
2022-03-07肖敏
肖 敏
(绵阳师范学院信息工程学院,四川绵阳 621006)
0 引言
随着技术的进步,云计算使得服务提供商可以按需将基础设施、平台和软件等预期服务租赁给云用户.云用户可以从云上租赁服务,并在需求得到满足后将其释放回云.与传统数据中心相比,云计算带来了许多好处,如高灵活性(按需、自助服务)、快速响应、资源弹性伸缩、更高的资源利用率和更低运营成本等.
根据IDC(国际数据公司)的一项相关调查,安全问题是采用云计算的首要挑战[1].作为当今最常见的互联网攻击之一DoS(拒绝服务)和DDoS(分布式拒绝服务)的主要攻击目的是通过耗尽系统资源来损害其提供预期服务的能力.Cisco 2014年度安全报告将DDoS攻击的影响程度认定为严重[2].DDoS攻击大致可分为三类[3]:
1)基于卷的DDoS攻击:当大量此类流量被指向服务器时,这些攻击会影响服务器.例如ICMP Flood和UDP Flood攻击.
2)基于协议的DDoS攻击:这些攻击使用特定的Internet协议来消耗服务器的资源.例如TCP-SYN Flood攻击和Ping死亡攻击.
3)基于应用程序的DDoS攻击:这些攻击针对Internet应用程序的弱点.它也被称为应用层攻击.例如Slowloris攻击和DNS放大攻击.
其中TCP-SYN Flood是最常见的DDoS攻击,根据卡巴斯基2018年第四季度的统计报告,TCP-SYN Flood占总攻击的50%以上[4].TCP-SYN Flood攻击同时也是云上最常见的三种攻击之一[5].
TCP-SYN Flood是一种基于协议的DDoS攻击,TCP连接是由导致漏洞的三次握手TCP技术启动的.攻击者向目标系统发送连续的SYN请求,试图消耗足够的服务器资源,使系统对合法流量无法响应.正常的TCP连接需要三次握手.首先,客户端通过向服务器发送SYN包来请求连接.然后,服务器通过将SYN-ACK发送回客服端来确认此请求.最后,客户端用ACK报响应并完成连接的建立[6].如果客户端没有用预期的ACK消息响应服务器,比如恶意客户端可以简单地不发送预期的ACK,或者通过欺骗SYN中的源IP地址导致服务器将SYN-ACK发送到伪造的IP地址.那么服务器没有收到ACK消息,则等待超时.在等待超时的过程中,半连接状态保持在[7]一个空间有限的缓冲队列中.如果发送到服务器的大量SYN包没有响应,则会持续消耗服务器上的资源,最终可能超过服务器的能力,从而导致服务器无法连接到合法的客户端,甚至导致服务器系统崩溃[8].
R.Shea和J.Liu在虚拟化方面的研究表明[9],虚拟机的性能在DDoS攻击下比在具有相同资源量的非虚拟化系统上的性能下降更严重.由于虚拟化是云计算的核心,这意味着云中的虚拟机和相关服务比传统系统更容易受到DDoS攻击.在多租户环境中,攻击者不仅可以来自外部也可能从云中租用资源对其他租户的虚拟机发起攻击.特别是部署为IaaS的云环境中内部恶意租户的攻击可能导致同一共享环境中的所有虚拟机都会受到影响[10].因此,检测并阻止此类攻击变得极为重要.
本文重点研究了基于异常检测器的虚拟云环境下SYN Flood攻击的检测方法,尝试通过流表编程实现流表引导,通过插入分析器、探头和限速器尝试根据预定义策略模板和包统计数据触发启动防御系统,针对性限速以削弱DDoS攻击对于系统性能的影响.在实验系统中使用模拟攻击初步测试评价该方案的作用效果.
1 相关研究
为了检测网络中的DoS攻击,通常使用入侵检测系统(IDS).IDS是部署在网络或主机上的高级安全机制,用于检测DoS攻击、特洛伊木马和Internet蠕虫等恶意活动.IDS在检测过程中使用基于签名或异常的方法.基于特征的IDS需要一个已知攻击特征和模式的数据库才能检测到攻击.开源Snort[11]是一种常见的基于签名的IDS,Lonua等人对此进行了实验[12].然而,这些方法通常应用于传统非云化的网络中,在云计算等具有动态资源的大型网络中,存在检测延迟大、计算成本高等缺点,很难具有部署成本优势.
另一方面,基于异常的IDS使用统计或机器学习方法来检测攻击,并且与基于特征的IDS相比具有优势,因为它们能够在没有攻击信息和经验的情况下检测新的攻击.Gupta等人[13]提出了一个基于概要文件的网络入侵防御系统(NIPS)来保护云环境.相关研究应用了基于TCP SYN包数检测SYN Flood攻击的方法[14],将特定间隔内超过预定义阈值的SYN包数被视为攻击.其研究结果表明,该方法能够很好地检测SYN Flood攻击.然而,这种静态方式不具备动态调节能力,会导致不同规格的云主机受到相等的对待.
DongHyuk Kim等人[15]针对这一问题,提出了一种利用TCP超时机制和分组往返时间(RTT)来更简单有效地防御SYN洪泛攻击的技术.其思想是,如果正常的TCP发送方在超时之前没有从接收方接收到SYN/ACK包,则它会重新传输SYN包,而攻击者通常不会重新传输SYN包.其方案采用丢弃来自任何TCP发送方的第一个SYN包.如果交换机接收到重新传输的SYN,则认为SYN是从普通用户发送的,并将SYN转发给预期的接收方.但这种方式需要预先启动而非按一定的系统指标来触发,在无攻击的场景下并不友好.
2 系统设计
2.1 问题描述
虚拟化改变了目前的计算方式,许多数据中心完全虚拟化,以便在灾难恢复期间提供快速资源调配、向云端溢出并提高可用性.在2013年虚拟机的数量已经超过了服务器的数量,并且进一步的虚拟化没有停止的迹象[16].服务器虚拟化的兴起带来了数据中心网络的根本转变.一个新的网络访问层已经出现,其中大多数网络端口是虚拟的,而不是物理的[17],这就导致数据包转发的第一级交换机越来越多地驻留在Hypervisor中.在早期,这些Hypervisor的虚拟交换机(vSwitches)主要负责提供基本的网络连接.但随着虚拟化负载的激增,这种方法的局限性也变得越来越明显:虚拟化的负载与物理网络的耦合严重限制了其移动性、扩展性和快速资源调配能力.
随着以Openstack为代表的开源云平台的广泛部署,其默认使用的虚拟交换机组件Openvswitch在虚拟化的数据中心网络中承担了状态防火墙等更为复杂的功能[18].在这种虚拟交换机中,主要由两个组件构成:第一个是ovs-vswitchd,它是一个用户空间守护进程,它也是处理数据包的慢速通道;另一个组件则是负责Datapath的内核模块(Kernel Module),它是处理数据包的快速通道.图1描述了这两个主要组件如何协同工作来转发数据包.内核模块首先从物理NIC或VM的虚拟NIC接收数据包,ovs-vswitchd已经明确指示内核模块如何处理这种类型的数据包时,内核模块只需遵循ovs-vswitchd给出的称为actions的指令完成转发.该指令列出了传输数据包的物理端口,虚拟端口或者隧道,同时actions还可以指定修改、抽样或丢弃数据包等动作.如果内核模块没有被告知如何处理数据包,它会将其传递给ovs-vswitchd组件.在用户空间中,ovs-vswitchd确定如何处理数据包,然后将数据包以及所需的处理方式传递回内核模块.通常,ovs-vswitchd还会通知内核模块缓存actions,以处理类似的未来数据包[19].
图1 Openvswitch数据包转发示意图
复杂的带有状态的网络应用需要可以实现连接跟踪的状态机.它需要匹配到更精细的报文字段,包括源和目的IP地址,协议号,源和目的端口号,TCP标记位,以完成所需的连接跟踪.在这种模式下,任何TCP-SYN Flood攻击的数据包都会被快速通道的内核模块认为是一条新流,而需要上送到用户态ovs-vswitchd进行转发规则计算,因此在发生SYN Flood攻击时,openvswitch会因攻击产生过多的资源消耗而难以响应其他正常虚拟机的业务请求.
2.2 实验系统结构
本文所研究的系统在相关研究的基础上,在云环境中实现了动态的TCP-SYN Flood防御,其核心思想包括IP/MAC地址欺骗防护以及基于预定义阀值的SYN包攻击防护,目标是既能够有效的防御修改源IP/MAC地址的SYN Flood攻击,也能够实现根据系统指标和阀值进行动态防护.如图2所示,该系统部署于Hypervisor,利用Openvswitch、分析器、探头和限速器三个组件的联动.通过对Openvswitch的多级流表编程实现SYN包的统计和IP/MAC源地址欺骗的防护.分析器负责根据SYN包统计信息和防护阀值以及Openvswitch的资源使用率等信息决策是否触发探头采样,分析器也负责对采样结果进行分析并根据分析结果决定是否触发限速器进行限速.
图2 实验系统结构
2.3 Openvswitch
我们使用Openvswitch的多级流表来实现相关的转发业务、SYN包统计、以及IP/MAC欺骗防护.图4为Openvswitch的流表设计.
图4 分析器的工作流程
SYN包统计位于Openvswitch Table 8中,针对每个虚拟机端口增加一条用来匹配TCP SYN包的流表,如下所示:
ovs-ofctl add-flow br0 "table=8,priority=100,in_port= tap4a2f334c-03,eth,ip,tcp,tcp_flags=+syn,actions=resubmit(,9)"
当虚拟机SYN包进入Openvswitch并命中此流表后,就可以获取到此流表被命中的统计值,从而得到该虚拟机发送的SYN包数量.
其中IP/MAC欺骗防护位于table7,流表将检查虚拟机的IP,MAC地址和入接口的匹配关系,如果不匹配则会丢弃数据包,从而可以防止虚拟机内部通过IP或MAC欺骗产生大量的TCP SYN数据包.其流表实例如下:
ovs-ofctl add-flow br0 "table=7,priority=32 769,in_port=tap4a2f334c-03,dl_src=fa:16:3e:f6:a8:5a,nw_src=192.168.100.10,actions=resubmit(,8)"
ovs-ofctl add-flow br0 "table=7,priority=32 768,in_port==tap4a2f334c-03,actions=drop
2.4 分析器
分析器在系统中主要根据预定义的策略模板,Openvswitch中端口的TCP SYN统计信息,以及探头Probe采集的数据包样本,来决策是否需要进行SYN包限速.分析器的工作流程如图3所示.
图3 Openvswitch的流表设计
目前策略模板中主要针对两个统计因子来决策是否进行限速:TCP SYN Packet/s以及TCP Half Open Connection/s,其中TCP SYN Packet/s通过openvswitch的流表统计信息获取,TCP Half Open Connection/s通过探头Probe获取的采样在分析器中进行计算.
2.5 探头(Probe)
探头模块用于根据分析器指令来捕获指定虚拟机端口的数据包,并生成pcap文件以供分析器解析和计算.探头基于gopacket库实现,其捕获数据包和存储pcap文件的代码片段如下:
func ondemand_probe() {
//Open output pcap file and write header
f,_:=os.Create(deviceName_pcap)
w:=pcapgo.NewWriter(f)
w.WriteFileHeader(snapshotLen,layers.LinkTypeEthernet)
defer f.Close()
//Open the device for capturing
handle,err=pcap.OpenLive(deviceName,snapshotLen,promiscuous,timeout)
if err!=nil{
…
os.Exit(1)
}
defer handle.Close()
//Start processing packets
packetSource:=gopacket.NewPacketSource(handle,handle.LinkType())
for packet:=range packetSource.Packets(){
//Process packet here
w.WritePacket(packet.Metadata().CaptureInfo,packet.Data())
packetCount++
//Only capture 1000
if packetCount>1000{
break
}}}
2.6 限速器(Limiter)
限速器使用TC实现,通过u32分类器指定偏移量来匹配SYN数据包,其匹配过程和限速如下所示:
tc filter add dev tap4a2f334c-03 parent ffff:protocol ip prio 130 u32 match u8 0x02 0x02 at 33 police rate 10 bit burst 10 b drop
3 系统验证和对比
图5 实验攻击数据包统计信息
本次测试验证尝试在攻击虚拟机内部使用hping3攻击模拟TCP SYN Flood攻击,并在攻击虚拟机的虚拟网卡上使用tcpdump抓包来统计攻击包的数量信息.其中虚线为对照组的攻击包数量,实线为测试组的攻击包数量.在两轮测试中,使用hping3均产生了约50 Kpps的TCP SYN包,强度基本相当.使用这样的实验环境我们两次测试了攻击对Openvswitch的性能影响,以及对同Hypervisor的其他虚拟机网络业务的影响.第一次测试是在没有使用防御策略的情况下获取系统性能在被攻击状态下的对照数据,第二次则是测试应用防御策略后系统性能的响应数据.
ovs-vswitchd的CPU和内存使用率表示了Openvswitch用户态进程对计算资源的消耗.通过统计ovs-vswitchd的CPU和内存使用率能够评估防御系统对Openvswitch的保护的效果.图6显示了保护前后ovs-vswitchd的CPU使用率对比,可以发现在系统探测到可能存在TCP SYN Flood攻击并启动保护后,ovs-vswitchd的CPU使用率可保持到正常水平.
图6 CPU使用率对比
往返时间RTT(Round-Trip Time)在计算机网络中它是一个重要的性能指标.表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认,不包含数据传输时间)总共经历的时间.图7显示了一个与攻击虚拟机在同一Openvswitch下的正常虚拟机在两轮攻击时使用ping工具测试到出口设备的往返时间.从图8可以看到,在攻击发生、触发探头并启动系统防护后,往返时间可在短时间内恢复到正常水平.而未防护时,则持续在8 ms到135 ms区间波动.
图7 往返时间RTT对比
4 结论
在本次尝试和实验中,通过使用一个试验台,实现了本文所提出的在Openvswitch环境下对的TCP-SYN Flood攻击的防御策略算法,多维度的评估了其对于受攻击系统性能的影响,初步验证了的其有效性.结果显示该算法能有效地抵御测试数据集模拟的TCP-SYN Flood攻击.