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

过去，***者所面临的主要问题是网络带宽，由于较小的网络规模和较慢的网络速度的限制，***者无法发出过多的请求。虽然类似“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三次握手。
  

  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报文，导致服务器上建立大量的半连接，直至老化。这样，服务器的资源会被这些半连接耗尽，导致正常的请求无法回应。


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


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

  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***的另一种方式，没有报文来回路径必须一致的限制，所以应用普遍。
 

  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设备，先进的防御技术在业界也是遥遥领先、大名鼎鼎，在腾讯、阿里巴巴都获得一致好评，是华为公司的尖刀产品哦！更多内容可以登录华为公司主页下载相关相产品文档。