syn flood攻击详解

一：概念
什么是SYN Flood攻击?
SYN Flood (SYN洪水) 是种典型的DoS (Denial of Service，拒绝服务) 攻击。效果就是服务器TCP连接资源耗尽，停止响应正常的TCP连接请求。

原理：
首先说tcp3次握手
连接发起方是A，连接接受方是B

二：原理部分

整体理解
实际上3次握手整体上可以分为两部分内容，
（1）建立A→B的连接，使得B能够接收A的数据
（2）建立B→A的连接，使得A能够接收B的数据

分步理解
A首先发送SYN（Synchronization）消息给B，要求B做好接收数据的准备；B收到后反馈SYN-ACK（Synchronization-Acknowledgement） 消息给A，这个消息的目的有两个：(1) 向A确认已做好接收数据的准备，(2) 同时要求A也做好接收数据的准备，此时B已向A确认好接收状态，并等待A的确认，连接处于半连接；此时通过SYN和SYN-ACK消息开启了A→B的单向通信通道（B获知了A的消息序号）

A收到后再次发送ACK(Acknowledgement)消息给B，向B确认也做好了接收数据的准备，至此三次握手完成，“连接”就建立了，实际上只是双方都按对方的要求进入了可以接收消息的状态。SYN-ACK和ACK消息开启了B→A单向通信通道（A获知了B的消息序号）。

为什么使用序列号
以上彼此要求对方确认的“状态”主要是双方将要使用的消息序号(SequenceNum)，TCP为保证消息按发送顺序抵达接收方的上层应用，需要用消息序号来标记消息的发送先后顺序的。

三：出现问题

以上讨论的是在双方诚实可信，网络正常的理想状况下建立连接。但实际情况是，网络可能不稳定会丢包，使握手消息不能抵达对方，也可能是对方故意不按规矩来，故意延迟或不发送握手确认消息。假设B通过某TCP端口提供服务，B在收到A的SYN消息时，积极的反馈了SYN-ACK消息，使连接进入半开状态，因为B不确定自己发给A的SYN-ACK消息或A反馈的ACK消息是否会丢在半路，所以会给每个待完成的半开连接都设一个Timer，如果超过时间还没有收到A的ACK消息，则重新发送一次SYN-ACK消息给A，直到重试超过一定次数时才会放弃。

四：造成的危害

做好人是要付出代价的，B为帮助A能顺利连接，需要分配内核资源维护半开连接，那么当B面临海量的大忽悠A时[1]，如上图所示，SYN Flood攻击就形成了。攻击方A可以控制肉鸡向B发送大量SYN消息但不响应ACK消息，或者干脆伪造SYN消息中的Source IP，使B反馈的SYN-ACK消息石沉大海[2]，导致B被大量注定不能完成的半开连接占据，直到资源耗尽，停止响应正常的连接请求[3]。

五：应对措施

（1）提高TCP端口连接容量
在Linux上可以修改以下配置提高TCP半开连接队列大小的上限：
/proc/sys/net/ipv4/tcp_max_syn_backlog
（2）减少半开连接的资源占用时间
可以减少半开状态下等待ACK消息的时间或者重试发送SYN-ACK消息的次数：
/proc/sys/net/ipv4/tcp_synack_retries
（3）启用某种半开连接回收机制
使得当半开连接队列满了以后做“除旧迎新”操作，当然并不是所有系统都支持这种机制。

权宜之计：
以上方法更像是权宜之计，只是缓解了被攻击时的系统压力，以及稍稍提高了些防御门槛，但也同时影响了部分正常的请求的建立
（1）减少SYN-ACK重试次数
同样也会降低某些网络环境不好的正常用户的连接成功率
（2）使用半开连接回收机制
攻击者只需提高攻击频率就可使大部分正常的等待的半开连接，在ACK消息到来前就被踢出队列。

六：深度分析

任何一个SYN消息无论来源是谁，都会消耗B的一些资源保存半开状态，并逐渐达到“鸠占鹊巢”的效果。

SYN Cache和SYN Cookies就是基于这个观察提出的两个方案。

（1）SYN Cache

SYN Cache的出发点主要是针对“鸠占鹊巢”问题
基本原理如下：
构造一个全局的Hash Table，用来缓存系统当前所有的半开连接信息，连接成功则从Cache中清除相关信息；Hash Table中每个桶（bucket）的容量大小也有限制，当桶“满”时做除旧迎新操作。当B收到一个SYN消息后，会将半开连接信息加入到Hash Table中，其中key的生成很关键，既要用到SYN消息中包含的信息（如：Source IP，Port等）又要做到很难被攻击者猜到，一般会通过一个秘密的函数生成，这样所有的半开连接无论好坏，都看似随机地被平均分配到了不同的“桶”中，使攻击难度大增，因为为达到DoS效果，攻击者需要使每个桶都达到填满状态，并且还要有足够快的“填桶”速度，使得正常的半开连接在还未完成建立前就被踢出桶，这样的攻击行为估计在达到目的前早就暴露了。

（2）SYN Cookies
SYN Cookies着眼点主要是设法消除半开连接的资源消耗
原理与HTTP Cookies技术类似

B通过特定的算法把半开连接信息编码成“Cookie”，用作B给A的消息编号（SequenceNum），随SYN-ACK消息一同返回给连接发起方A，这样在连接完全建立前B不保存任何信息。如果A是正常用户，则会向B发送最后一次握手消息（ACK），B收到后验证“Cookie”的内容并建立连接；如果A是攻击者，则不会向B反馈ACK消息，B也没任何损失，也就说是单纯的SYN攻击不会造成B的连接资源消耗。当然这种方案也有一定缺点，最明显的就是B不保存连接的半开状态，就丧失了重发SYN-ACK消息的能力，这一方面会降低正常用户的连接成功率，另一方面会导致某些情况下正常通信的双方会对连接是否成功打开产生误解，如A发给B的第三次握手消息(ACK)半路遗失，A认为连接成功了，B认为没收到ACK，连接没成功，这种情况就需要上层应用采取策略特别处理了。