TCP SYN-Flood攻击

本文转载自华为企业互动社区

大家好,强叔和你们又见面了!上一期强叔带着大家一起了解了单包攻击的基本防御知识,知道了单包攻击的几大类型,以及防火墙支持防御的攻击种类。但是,在现网中单包攻击只占了很小一部分比例,更多的攻击还是集中在流量型攻击和应用层攻击。本期强叔将继续为大家讲解一下现网上常见的流量型攻击。
 

过去,攻击者所面临的主要问题是网络带宽,由于较小的网络规模和较慢的网络速度的限制,攻击者无法发出过多的请求。虽然类似“Ping of Death”的攻击类型只需要较少量的包就可以摧毁一个没有打过补丁的操作系统,但大多数的DoS攻击还是需要相当大的带宽,而以个人为单位的黑客们很难消耗高带宽的资源。为了克服这个缺点,DoS攻击者开发了分布式的攻击。
木马成为黑客控制傀儡的工具,越来越多的计算机变成了肉鸡,被黑客所利用,并变成了他们的攻击工具。黑客们利用简单的工具集合许多的肉鸡来同时对同一个目标发动大量的攻击请求,这就是DDoS(Distributed Denial of Service)攻击。随着互联网的蓬勃发展,越来越多的计算机不知不觉的被利用变成肉鸡,攻击逐渐变成一种产业。

提起DDoS攻击,大家首先想到的一定是SYN Flood攻击。今天强叔就给大家详细说说SYN flood的攻击和防御。
 

最初的SYN Flood攻击类似于协议栈攻击,在当年的攻击类型中属于技术含量很高的“高大上”。当年由于系统的限制以及硬件资源性能的低下,称霸DDoS攻击领域很久。它与别人的不同在于,你很难通过单个报文的特征或者简单的统计限流防御住它,因为它“太真实”、“太常用”。
SYN Flood具有强大的变异能力,在攻击发展潮流中一直没有被湮没,这完全是他自身的优秀基因所决定的:

  1.  单个报文看起来很“真实”,没有畸形。
  2. 攻击成本低,很小的开销就可以发动庞大的攻击。

2014年春节期间,某IDC的OSS系统分别于大年初二、初六、初七连续遭受三轮攻击,最长的一次攻击时间持续将近三个小时,攻击流量峰值接近160Gbit/s!事后,通过对目标和攻击类型分析,基本可以判断是有一个黑客/黑客组织发起针对同一目标的攻击时间。经过对捕获的攻击数据包分析,发现黑客攻击手段主要采用SYN Flood。
2013年,某安全运营报告显示,DDoS攻击呈现逐年上升趋势,其中SYN Flood攻击的发生频率在2013全年攻击统计中占31%。

可见,时至今日,SYN Flood还是如此的猖獗。下面我们一起看一下它的攻击原理。

 

TCP三次握手

SYN flood是基于TCP协议栈发起的攻击,在了解SYN flood攻击和防御原理之前,还是要从TCP连接建立的过程开始说起。在TCP/IP协议中,TCP协议提供可靠的连接服务,无论是哪一个方向另一方发送数据前,都必须先在双方之间建立一条连接通道,这就是传说中的TCP三次握手。
  

TCP SYN-Flood攻击_第1张图片 TCP三次握手
  1. 第一次握手:客户端向服务器端发送一个SYN(Synchronize)报文,指明想要建立连接的服务器端口,以及序列号ISN。 
  2.  第二次握手:服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时在SYN+ACK报文中将确认号设置为客户端的ISN号加1。 ACK即表示确认(Acknowledgment)。
  3. 第三次握手:客户端收到服务器的SYN-ACK包,向服务器发送ACK报文进行确认,ACK报文发送完毕,三次握手建立成功。

如果客户端在发送了SYN报文后出现了故障,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的,即第三次握手无法完成,这种情况下服务器端一般会重试,向客户端再次发送SYN+ACK,并等待一段时间。如果一定时间内,还是得不到客户端的回应,则放弃这个未完成的连接。这也是TCP的重传机制。

 

 SYN Flood攻击正是利用了TCP三次握手的这种机制。攻击者向服务器发送大量的SYN报文请求,当服务器回应SYN+ACK报文时,不再继续回应ACK报文,导致服务器上建立大量的半连接,直至老化。这样,服务器的资源会被这些半连接耗尽,导致正常的请求无法回应。

TCP SYN-Flood攻击_第2张图片 SYN-Flood攻击


 防火墙针对SYN Flood攻击,一般会采用TCP代理和源探测两种方式进行防御。

TCP代理


TCP代理是指我们的防火墙部署在客户端和服务器中间,当客户端向服务器发送的SYN报文经过防火墙时,防火墙代替服务器与客户端建立三次握手。一般用于报文来回路径一致的场景。
 

TCP SYN-Flood攻击_第3张图片 TCP代理
  1. 防火墙收到SYN报文,对SYN报文进行拦截,代替服务器回应SYN+ACK报文。
  2.  如果客户端不能正常回应ACK报文,则判定此SYN报文为非正常报文,防火墙代替服务器保持半连接一定时间后,放弃此连接。
  3.  如果客户端正常回应ACK报文,防火墙与客户端建立正常的三次握手,则判定此SYN报文为正常业务报文,非攻击报文。防火墙立即与服务器再建立三次握手,此连接的后续报文直接送到服务器。

整个TCP代理的过程对于客户端和服务器都是透明的。

TCP代理过程中,防火墙会对收到的每一个SYN报文进行代理和回应,并保持半连接,所以当SYN报文流量很大时,对防火墙的性能要求非常的高。
了解了攻击原理,再学习防御原理,是不是觉得很容易理解。讲了这么多,大家对SYN Flood的攻击以及TCP代理防御是不是有了一定的认识。其实,TCP代理的本质就是利用防火墙的高性能,代替服务器承受半连接带来的资源消耗,由于防火墙的性能一般比服务器高很多,所以可以有效防御这种消耗资源的攻击。

 

但是TCP代理只能应用在报文来回路径一致的场景中,如果来回路径不一致,代理就会失败。可是在现网中,报文来回路径不一致的场景也是很常见的,那这种情况下如果发生了SYN Flood攻击,防火墙要怎么防呢?
不用担心,我们还有第二个杀手锏:TCP源探测!

 

TCP源探测


TCP源探测是防火墙防御SYN Flood攻击的另一种方式,没有报文来回路径必须一致的限制,所以应用普遍。
 

TCP SYN-Flood攻击_第4张图片 TCP源探测
  1.  当防火墙收到客户端发送的SYN报文时,对SYN报文进行拦截,并伪造一个带有错误序列号的的SYN+ACK报文回应给客户端。
  2.  如果客户端是虚假源,则不会对错误的SYN+ACK报文进行回应。
  3.  如果客户端是真实源发送的正常请求SYN报文,当收到错误的SYN+ACK报文时,会再发出一个RST报文,让防火墙重新发一个正确的SYN+ACK报文;防火墙收到这个RST报文后,判定客户端为真实源,则将这个源加入白名单,在白名单老化前,这个源发出的报文都认为是合法的报文,防火墙直接放行,不在做验证。

这里,我们再回头对比一下TCP源探测和TCP代理两种方式,会发现TCP源探测对客户端的源只做一次验证通过后,就加入白名单,后续就不会每次都对这个源的SYN报***验证,这样大大提高了TCP源探测的防御效率和防御性能,可以有效缓解防火墙性能压力。

 

讲了这么多,大家是不是就会觉得TCP源探测对于SYN Flood已经是一个完美的防御方案了呢?它会不会也有什么弱点呢?

 

很长一段时间里,SYN Flood在防火墙TCP代理和TCP源探测双重防御的压制下,得到了遏制。但是随着木马被广泛植入到更多的肉鸡,一个初级黑客简单操作就可以操纵动则上G流量的时候, SYN Flood变得更加嗜血。TCP代理和TCP源探测方式说到底都是使用防火墙牺牲自身的CPU不断的来解决问题。但是一旦海量低开销的SYN Flood攻击报文同时蜂拥而至时,这种伤敌一千自损八百的方式将走向另外一个极端,防火墙很有可能成为瓶颈。华为防火墙在不断提升自身性能的同时,还是可以承担一定的开销。但是传统的防御手段都是反弹,也就是说如果攻击流量是1G的话,防火墙的反弹流量也有1G,这样就相当于有2G的“攻击”流量在互联网上占据着带宽,我们在防御的过程中不自觉的放大了垃圾流量,拥塞了链路。


魔高一尺,道高一丈,随着SYN Flood攻击的不断变异,防火墙也一直不断地提升着自身的防御能力。
 TCP提供可靠的传输层,其中可靠性的保障之一就是确认从另一端收到的数据。但是数据和确认在传输过程中都有丢弃的可能,所以TCP通过在发送时设置一个定时器来解决这个问题。如果定时器到达设置的时间了,还是没有收到某个数据的确认报文,则TCP就会重传这个数据。华为专业AntiDDoS设备正是利用了TCP这种重传的机制,推出“首包丢弃”功能与“TCP源探测”结合的防御方式,以应对超大流量的SYN Flood攻击。当SYN报文蜂拥而至时,专业AntiDDoS设备会将收到的第一个报文记录并直接丢弃,然后等待第二个重传报文。收到重传报文后,再对重传报文进行源探测。
这里提到了专业AntiDDoS设备,强叔也顺便给大家介绍一下,虽然防火墙具备DDoS防御能力,但是他毕竟不是专业的防攻击设备,术业有专攻,华为公司推出的AntiDDoS1000和AntiDDoS8000系列是专业的AntiDDoS设备,先进的防御技术在业界也是遥遥领先、大名鼎鼎,在腾讯、阿里巴巴都获得一致好评,是华为公司的尖刀产品哦!更多内容可以登录华为公司主页下载相关相产品文档。

 

强叔提问

回顾一下,在这一篇中,我们一起学习了TCP代理和TCP源探测,以及两种方式的利与避,还提到了防火墙只能在来回路径一致的场景中使用TCP代理,那么大家有没有想过,为什么防火墙在来回路径不一致的场景中,TCP代理会失败呢?

扫描二维码,关注“小眼睛的梦呓”公众号,在手机端查看文章 扫描二维码,关注“清远的梦呓”公众号,在手机端查看文章

你可能感兴趣的:(网络通信)