文章目录
- SYN Flood是如何发生的
- 如何识别和防御SYN Flood
SYN Flood是互联网上最原始、最经典的DDoS（Distributed Denial of Service）攻击之一。它利用了TCP协议的三次握手机制，攻击者通常利用工具或者控制僵尸主机向服务器发送海量的变源IP地址或变源端口的TCP SYN报文，服务器响应了这些报文后就会生成大量的半连接，当系统资源被耗尽后，服务器将无法提供正常的服务。
增加服务器性能，提供更多的连接能力对于SYN Flood的海量报文来说杯水车薪，防御SYN Flood的关键在于判断哪些连接请求来自于真实源，屏蔽非真实源的请求以保障正常的业务请求能得到服务。
SYN Flood是如何发生的
SYN Flood顾名思义就是用洪水一样的SYN报文进行攻击。SYN报文指的是TCP协议中的Synchronize报文，是TCP三次握手过程中的首个报文。让我们先来了解一个正常的TCP三次握手过程。
TCP三次握手过程
- 开始建立连接时，客户端发送SYN报文到服务器，等待服务器确认。SYN报文的源IP地址和端口是客户端的IP地址和端口。
- 服务器收到SYN报文，回应一个SYN-ACK（Synchronize-Acknowledgement）报文。SYN-ACK报文的目的P地址和端口是客户端的IP地址和端口。
- 客户端收到服务器的SYN-ACK报文，向服务器发送ACK报文，服务器收到ACK报文后完成三次握手，TCP连接建立成功。
在连接超时之前，服务器会一直等待ACK报文，此时该连接状态为半开放连接（也被称为半连接）。半连接会占用服务器的连接数，当连接数被占满时，服务器就无法提供正常的服务了。黑客正是通过这个机制来实现SYN Flood。
SYN Flood的攻击过程
黑客通常通过伪造的源IP地址或端口，向服务器发送大量的SYN报文，请求建立TCP连接。由于源IP地址或端口是伪造的，服务器发送的SYN-ACK报文永远不会被真实的客户端接收和回应。极少数情况下，黑客也会使用真实源IP地址，但他们只是通过攻击工具发送海量SYN报文，工具并不会响应来自服务器SYN-ACK报文。无论如何，服务器都接收不到ACK报文，产生了大量的半连接。此时服务器需要维持一张巨大的等待列表，不停地重试发送SYN-ACK报文，同时大量的资源无法释放。当服务器被这些恶意的半连接占满时，就不会再响应新的SYN报文，从而导致正常的用户无法建立TCP连接。
如何识别和防御SYN Flood
SYN Flood的目的是占满服务器的连接数，消耗服务器的系统资源。对于服务器自身来说，最直接的做法就是提高服务能力，比如组建集群，升级硬件。但是这种方式成本巨大，且对于海量的攻击报文来说，并没有太大的作用，仅多撑几分钟甚至几秒而已。
所以，必须在这些攻击报文到达服务器之前就进行拦截。然而对于防火墙这类安全设备而言，SYN报文是正常的业务报文，防火墙的安全策略必须允许其通过，否则服务器就无法对外提供服务。如果能明确虚假源的IP地址，就能通过精细的安全策略阻止这些源发来的SYN报文。但是管理员无法预知哪些是虚假源。即使能分析出虚假源，也无法做到快速、自动地配置或取消安全策略来应对不可预期的攻击流量。
此时就需要Anti-DDoS系统的能力了，它部署在网络入口处，在服务器之前处理SYN报文，识别出虚假源，屏蔽来自这些地址的报文，只将合法的SYN报文传递给服务器。Anti-DDoS系统处理SYN报文主要有两种手段，源认证和首包丢弃。
源认证
Anti-DDoS系统拦截客户端发送的SYN报文，代替服务器向客户端发送SYN-ACK报文，如果客户端不应答，则认为该客户端为虚假源；如果客户端应答，则Anti-DDoS系统认为该客户端为真实源，并将其IP地址加入白名单，在一段时间允许该源发送的所有SYN报文通过，也不做代答。
首包丢弃
如果Anti-DDoS系统代替服务器应答了所有的SYN Flood攻击报文，那么性能瓶颈仅仅是从服务器转移到了Anti-DDoS系统而已。一旦Anti-DDoS系统的系统资源耗尽，攻击依旧会透传到服务器，而且大量反弹的SYN-ACK报文也会对网络造成一定的压力。Anti-DDoS系统利用首包丢弃来解决这个问题。
TCP协议的可靠性不仅体现在三次握手，还体现在超时与重传的机制。正常情况下客户端发送SYN报文后如果在一定时间没有收到服务器的SYN-ACK应答，客户端会重新发送SYN报文。Anti-DDoS系统会丢弃掉收到的第一个SYN报文。SYN Flood攻击时，黑客发送的绝大多数是变源的SYN报文，所有的SYN报文对于Anti-DDoS系统来说都是首包，都将被直接丢弃。如果客户端重传了SYN报文，Anti-DDoS系统再对该报文进行源认证。如此一来，大大减少了Anti-DDoS系统代答的压力。首包丢弃和源认证两种手段结合，对于防御SYN Flood（特别是不断变换源IP和源端口的虚假源攻击）非常有效。
