2010-12-18 15:25:43 
阿炯
TCP SYN洪水攻击
TCP RST复位攻击
-------------------------------------------------
什么是 TCP SYN Flood 攻击
TCP SYN Flood是一种常见，而且有效的远程拒绝服务(Denial of Service)攻击方式，它通过一定的操作破坏TCP三次握手建立正常连接，占用并耗费系统资源，使得提供TCP服务的主机系统无法正常工作。这个很有名的攻击方式叫DoS攻击，也就是所谓的拒绝服务攻击。而在拒绝服务攻击里，又以SYN Flood攻击最为有名，俗称洪水攻击。SYN Flood利用TCP协议的设计上的缺陷，通过特定方式发送大量的TCP请求从而导致受攻击的一方CPU超负荷或内存不足。
由于TCP SYN Flood是通过网络底层对服务器进行攻击的，它可以在任意改变自己的网络地址的同时，不被网络上的其他设备所识别，这样就给XX部门追查犯罪来源造成很大的困难。
TCP协议的漏洞在于：TCP协议不同于UDP协议，UDP不是基于连接的，也就说每次使用UDP协议给客户发送数据的时候，各数据报并不经由相同的路线。而TCP协议是基于连接的，在每次发送数据以前，都会在服务器于客户端先虚拟出一条路线，称TCP连接，以后的各数据通信都经由该路线进行知道本 TCP连接结束。
在描述该攻击的工作原理以前，我们先简单对TCP协议的通讯方式做一个简单的说明。
TCP协议的通讯方式
一、TCP三次握手
传输控制协议(Transport Control Protocol)是一种面向连接的，可靠的传输层协议。面向连接是指一次正常的TCP传输需要通过在TCP客户端和TCP服务端建立特定的虚电路连接来完成，该过程通常被称为“三次握手”。可靠性可以通过很多种方法来提供保证，在这里我们关心的是数据序列和确认。TCP通过数据分段(Segment)中的序列号保证所有传输的数据可以在远端按照正常的次序进行重组，而且通过确认保证数据传输的完整性。要通过TCP传输数据，必须在两端主机之间建立连接。举例说明，TCP客户端需要和TCP服务端建立连接，过程如下所示：
第一步：客户端发送一个带有SYN标记的TCP报文到服务端。指明端口号以及TCP连接初始序号等信息；
第二步：服务端在接收到来自客户端的请求之后，返回一个带有SYN+ACK标记的报文，表示接受连接，并在TCP序号加一；
第三步：客户端接受到来自服务端的确认信息后，也返回一个带有ACK标记的报文，表示已经接受到来自服务器的确认信息。服务器在得到该数据报文后，一个TCP连接才算真正建立起来。
在第一步中，客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法，需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后，在第二步以自己的ISN回应(SYN标志置位)，同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中，客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接，开始全双工模式的数据传输过程。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 十六位源端口号 | 十六位目标端口号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 三十二位序列号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 三十二位确认号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 四位 | |U|A|P|R|S|F| |
| 首部 |六位保留位 |R|C|S|S|Y|I| 十六位窗口大小 |
| 长度 | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 十六位校验和 | 十六位紧急指针 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 选项(若有) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据(若有) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP首部结构
TCP三次握手过程如下：
1)客户端向服务器端发送一个SYN置位的TCP报文，包含客户端使用的端口号和初始序列号x；
2)服务器端收到客户端发送来的SYN报文后，向客户端发送一个SYN和ACK都置位的TCP报文，包含确认号为x＋1和服务器的初始序列号y；
3)
TCP客户端
客户端端口
(1024－65535)
TCP服务器端
服务器端口
(1－1023)
SYN
SYN/ACK
ACK
客户端收到服务器返回的SYN＋ACK报文后，向服务器返回一个确认号为y＋1序号为x＋1的ACK报文，一个标准的TCP连接完成。如下图所示：
当客户端发送一个TCP连接请求给服务器之，服务器也发出了相应的响应数据报文之后，由于某些原因(如客户端突然死机或断网等原因)，客户端不能接受到来自服务器的确认数据报，这就制造了只有第一次和第二次握手的TCP半连接。由于服务器发出了带SYN+ACK标记的报文却并没有得到客户端返回相应的ACK报文，于是服务器就进入等待并进行SYN+ACK报文重发。当恶意的客户端构造出大量的这中TCP半连接发送到服务端时，服务端就会一直陷入等待的过程中，并且耗用大量的CPU资源和内存资源来进行SYN+ACK报文的重发，这就是SYN Flood攻击。
二、TCP标志
这里有必要介绍一下TCP分段中的标志(Flag)置位情况：
*SYN：同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
*ACK：确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
*RST：复位标志
复位标志有效。用于复位相应的TCP连接。
*URG：紧急标志
紧急(The urgent pointer) 标志有效。紧急标志置位，
*PSH：推标志
该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。
*FIN：结束标志
带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。
三、TCP端口
为了能够支持同时发生的并行访问请求，TCP提供一种叫做“端口”的用户接口。端口是操作系统核心用来识别不同的网络回话过程。这是一个严格的传输层定义。通过TCP端口和IP地址的配合使用，可以提供到达终端的通讯手段。实际上，在任一时刻的互联网络连接可以由4个数字进行描述： 来源IP地址和来源端口，目的IP地址和目的端口。位于不同系统平台，用来提供服务的一端通过标准的端口提供相应服务。举例来说，标准的TELNET守护进程(telnet daemon)通过监听TCP 23端口，准备接收用户端的连接请求。
四、TCP缓存(TCP Backlog)
通常情况下，操作系统会使用一块限定的内存来处理TCP连接请求。每当用户端发送的SYN标志置位连接请求到服务端的一个合法端口(提供TCP 服务的一端监听该端口)时，处理所有连接请求的内存使用量必须进行限定。如果不进行限定，系统会因处理大量的TCP连接请求而耗尽内存，这在某种程度上可以说是一种简单的DoS攻击。这块经过限定的，用于处理TCP连接的内存称为TCP缓存(TCP Backlog)，它实际上是用于处理进站(inbound)连接请求的一个队列。该队列保存那些处于半开放(half-open)状态的TCP连接项目，和已建立完整连接但仍未由应用程序通过accept()调用提取的项目。如果这个缓存队列被填满，除非可以及时处理队列中的项目，否则任何其它新的 TCP连接请求会被丢弃。
一般情况下，该缓存队列的容量很小。原因很简单，在正常的情况下TCP可以很好的处理连接请求。如果当缓存队列填满的时候新的客户端连接请求被丢弃，客户端只需要简单的重新发送连接请求，服务端有时间清空缓存队列以相应新的连接请求。
在现实环境中，不同操作系统支持TCP缓冲队列有所不同。在BSD结构的系统中，如下所示：
五、TCP进站(Inbound)处理过程
为了更好的讲述TCP SYN Flood的攻击过程，我们先来介绍一下正常情况下，TCP进站处理的过程。
服务端处于监听状态，客户端用于建立连接请求的数据包(IP packet)按照TCP/IP协议堆栈组合成为TCP处理的分段(segment)。
分析报头信息： TCP层接收到相应的TCP和IP报头，将这些信息存储到内存中。
检查TCP校验和(checksum)：标准的校验和位于分段之中(Figure-2)。如果检验失败，不返回确认，该分段丢弃，并等待客户端进行重传。
查找协议控制块(PCB{})：TCP查找与该连接相关联的协议控制块。如果没有找到，TCP将该分段丢弃并返回RST。(这就是TCP处理没有端口监听情况下的机制) 如果该协议控制块存在，但状态为关闭，服务端不调用connect()或listen()。该分段丢弃，但不返回RST。客户端会尝试重新建立连接请求。
建立新的socket：当处于监听状态的socket收到该分段时，会建立一个子socket，同时还有socket{}，tcpcb{}和 pcb{}建立。这时如果有错误发生，会通过标志位来拆除相应的socket和释放内存，TCP连接失败。如果缓存队列处于填满状态，TCP认为有错误发生，所有的后续连接请求会被拒绝。这里可以看出SYN Flood攻击是如何起作用的。
丢弃：如果该分段中的标志为RST或ACK，或者没有SYN标志，则该分段丢弃。并释放相应的内存。
TCP SYN Flood攻击的机制
客户端通过发送在TCP报头中SYN标志置位的数据分段到服务端来请求建立连接。通常情况下，服务端会按照IP报头中的来源地址来返回SYN/ACK置位的数据包给客户端，客户端再返回ACK到服务端来完成一个完整的连接。
在攻击发生时，客户端的来源IP地址是经过伪造的(spoofed)，现行的IP路由机制仅检查目的IP地址并进行转发，该IP包到达目的主机后返回路径无法通过路由达到的，于是目的主机无法通过TCP三次握手建立连接。在此期间因为TCP缓存队列已经填满，而拒绝新的连接请求。目的主机一直尝试直至超时(大约75秒)。这就是该攻击类型的基本机制。
发动攻击的主机只要发送较少的，来源地址经过伪装而且无法通过路由达到的SYN连接请求至目标主机提供TCP服务的端口，将目的主机的TCP缓存队列填满，就可以实施一次成功的攻击。实际情况下，发动攻击时往往是持续且高速的。
这里需要使用经过伪装且无法通过路由达到的来源IP地址，因为攻击者不希望有任何第三方主机可以收到来自目的系统返回的SYN/ACK，第三方主机会返回一个RST(主机无法判断该如何处理连接情况时，会通过RST重置连接)，从而妨碍攻击进行。如下图所示：
由此可以看到，这种攻击方式利用了现有TCP/IP协议本身的薄弱环节，而且攻击者可以通过IP伪装有效的隐蔽自己。但对于目的主机来说，由于无法判断攻击的真正来源。而不能采取有效的防御措施。
攻击原理
假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)，此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYN Flood攻击(SYN洪水攻击)。 
TCP客户端
客户端端口
(1024－65535)
TCP服务器端
服务器端口
(1－1023)
SYN
SYN/ACK
伪造源地址
六、防御技术
1、SYN－cookie技术
一般情况下，当服务器收到一个TCP SYN报文后，马上为该连接请求分配缓冲区，然后返回一个SYN＋ACK报文，这时形成一个半连接。SYN Flood正是利用了这一点，发送大量的伪造源地址的SYN连接请求，而不完成连接。这样就大量的消耗的服务器的资源。
SYN－cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷，改变了资源分配的策略。当服务器收到一个SYN报文后，不立即分配缓冲区，而是利用连接的信息生成一个cookie，并将这个cookie作为将要返回的SYN＋ACK报文的初始序列号。当客户端返回一个ACK报文时，根据包头信息计算cookie，与返回的确认序列号(初始的序列号＋1)的前24位进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。
该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配，使SYN Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息，使攻击者不能伪造cookie。cookie的计算过程如下：
1)服务器收到一个SYN包后，计算一个消息摘要mac：
mac = MAC(A，k)；
MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。
A为客户和服务器双方的IP地址和端口号以及参数t的串联组合：
A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t
K为服务器独有的密钥；
时间参数t为32比特长的时间计数器，每64秒加1；
2)生成cookie：
cookie = mac(0:24)：表示取mac值的第0到24比特位；
3)设置将要返回的SYN+ACK报文的初始序列号，设置过程如下：
i.高24位用cookie代替；
ii.接下来的3比特位用客户要求的最大报文长度MMS代替；
iii.最后5比特位为t mod 32。
客户端收到来自服务器SYN+ACK报文后，返回一个ACK报文，这个ACK报文将带一个cookie(确认号为服务器发送过来的SYN ACK报文的初始序列号加1，所以不影响高24位)，在服务器端重新计算cookie，与确认号的前24位比较，如果相同，则说明未被修改，连接合法，然后，服务器完成连接的建立过程。
SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息，实现了无状态的三次握手，从而有效的防御了SYN Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心，在连接建立过程中不在服务器端保存任何信息，所以失去了协议的许多功能，比如，超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制，当分配了一定的资源后再采用cookie技术，Linux就是这样实现的。还有一个问题是，当我们避免了SYN Flood攻击的同时，同时也提供了另一种拒绝服务攻击方式，攻击者发送大量的ACK报文，使服务器忙于计算验证。尽管如此，在预防SYN Flood攻击方面，SYN-cookie技术仍然是一种有效的技术。这种方法也在linux系统所推荐，在系统日志中会有相关异常提示：”possible SYN flooding on port 80. Sending cookies ”(当然这也可能是系统默认的连接数过小所致，而非ddos攻击)。
# dmesg
possible SYN flooding on port 80. Sending cookies.
possible SYN flooding on port 80. Sending cookies.
possible SYN flooding on port 80. Sending cookies.
possible SYN flooding on port 80. Sending cookies.
… …
possible SYN flooding on port 80. Sending cookies
开了syncookie之后经常会看到这个报警信息“possible SYN flooding on port 80. Sending cookies”，如果看系统资源还没问题的话，应该多数不是受到syn flood，而是并发连接过多,不过这个还是要看自己的应用。
我们修改系统的相关参数：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 20480
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.core.netdev_max_backlog = 1000
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭，很关键的一个参数。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。系统中很多参数的值均为1024，说实话，这个值在应用多的服务器上确实有些小。
net.ipv4.tcp_max_tw_buckets = 6000 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为6000。对于Apache、Nginx等服务器，以上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字而挂掉。
2、地址状态监控的解决方法
地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。
每个源地址都有一个状态与之对应，总共有四种状态：
初态：任何源地址刚开始的状态；
NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；
GOOD状态：断定存在的源地址所处的状态；
BAD状态：源地址不存在或不可达时所处的状态。
具体的动作和状态转换根据TCP头中的位码值决定：
1)监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。
2)监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。
3)监听到从服务器来的SYN ACK报文(目的地址为addr)，表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为 NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。
状态的转换过程如下图所示：
初态
GOOD
NEW
BAD
ACK/RST
SYN
ACK/RST
ACK包确认超时
ACK/RST
ACK包确认超时
下面分析一下基于地址状态监控的方法如何能够防御SYN Flood攻击。
1)对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。
2)对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送 ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。
从以上分析可以看出，基于监控的方法可以很好的防御SYN Flood攻击，而不影响正常用户的连接。
SYN洪水攻击(SYN Flood)利用TCP三次握手
1.SYN洪水介绍
当一个系统（客户端C）尝试和一个提供了服务的系统（服务器S）建立TCP连接，客户端C和服务端S会交换一系列报文。 正常的3次握手连接：首先是C发送一个SYN报文给服务端S，然后这个服务端发送一个SYN-ACK包以回应C，接着，C就返回一个ACK包来实现一次完整的TCP连接。就这样，C到服务端的连接就建立了，这时C和服务端就可以互相交换数据了。
SYN洪水：在S返回一个确认的SYN-ACK包的时候，S可能由于各种原因不会接到C回应的ACK包。这个也就是所谓的半开放连接，S需要耗费一定的数量的系统内存来等待这个未决的连接，虽然这个数量是受限，但是恶意者可以通过创建很多的半开放式连接来发动SYN洪水攻击 。
攻击者可以通过IP欺骗发送SYN包给受害者系统，这个看起来是合法的，但事实上所谓的C根本不会进行ACK回应服务端S的SYN-ACK报文，这意味着受害者将永远不会接到ACK报文。而此时，半开放连接将最终耗用受害者所有的系统资源（即使等待ACK包有超时限制），受害者将不能再接收任何其他的请求。
2.SYN cookie
SYN cookie用一个cookie来响应TCP SYN请求的TCP实现，在正常的TCP实现中，当S接收到一个SYN数据包，他返回一个SYN-ACK包来应答，然后进入TCP-SYN-RECV（半开放连接）状态来等待最后返回的ACK包。S用一个数据空间来描述所有未决的连接，然而这个数据空间的大小是有限的，所以攻击者将塞满这个空间。 在TCP SYN COOKIE的执行过程中，当S接收到一个SYN包的时候，他返回一个SYN-ACK包，这个数据包的ACK序列号是经过加密的，也就是说，它由源地址，端口源次序，目标地址，目标端口和一个加密种子计算得出。然后S释放所有的状态。如果一个ACK包从C返回，S将重新计算它来判断它是不是上个SYN-ACK的返回包。如果这样，S就可以直接进入TCP连接状态并打开连接。这样，S就可以避免守侯半开放连接。（检验加密数据可能会带来一定的CPU运算）
以上只是SYN COOKIE的基本思路，它在应用过程中仍然有许多技巧。
3.SYN COOKIE 防火墙
SYN COOKIE 防火墙是SYN cookie的一个扩展，SYN cookie是建立在TCP堆栈上的，他为linux操作系统提供保护。SYN cookie防火墙是linux的一大特色，可以使用一个防火墙来保护你的网络以避免遭受SYN洪水攻击。
SYN cookie防火墙的原理：
client firewall server
------ ------------------------------
1. SYN----------- - - - - - - - - - ->
2. <------------SYN-ACK(cookie)
3. ACK----------- - - - - - - - - - ->
4. - - - - - - -SYN--------------->
5. <- - - - - - - - - ------------SYN-ACK
6. - - - - - - -ACK--------------->
7. -----------> relay the ------->
<----------- connection <-------
####################C与防火墙建立连接开始####################
1：SYN包从C发送到S（计划建立连接）
2：防火墙在这里扮演S的角色来回应一个带SYN cookie的SYN-ACK包给C
3：如果C发送ACK包，接着防火墙和C的连接就建立了
####################C与防火墙建立连接结束###################
####################防火墙与S建立连接开始####################
4：防火墙这个时候扮演C的角色发送一个SYN给S
5：S返回一个SYN给C
6：防火墙扮演C发送一个ACK确认包给S，这个时候防火墙和S的连接也就建立了
###################防火墙与S建立连接结束####################
7：防火墙转发C和S间的数据
如果系统遭受SYN Flood，那么第三步就不会有，S不会收到相应在第一步的SYN包，所以击退了这次SYN洪水攻击。
A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system. Some systems can misdetect a SYN Flood when being scanned for open proxies, as commonly done by IRC servers and services. These are not SYN Floods, merely an automated system designed to check the connecting IP.
When a client attempts to start a TCP connection to a server, the client and server exchange a series of messages which normally runs like this:
1. The client requests a connection by sending a SYN (synchronize) message to the server.
2. The server acknowledges this request by sending SYN-ACK back to the client.
3. The client responds with an ACK, and the connection is established.
This is called the TCP three-way handshake, and is the foundation for every connection established using the TCP protocol.
The SYN flood is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a SYN, but before it has received the ACK.
There are two methods, but both involve the server not receiving the ACK. A malicious client can skip sending this last ACK message. Or by spoofing the source IP address in the SYN, it makes the server send the SYN-ACK to the falsified IP address, and thus never receive the ACK. In both cases the server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missing ACK.
If these half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. Once all resources set aside for half-open connections are reserved, no new connections (legitimate or not) can be made, resulting in denial of service. Some systems may malfunction badly or even crash if other operating system functions are starved of resources this way.
SYN cookies provide protection against the SYN flood by eliminating the resources allocated on the target host.
Limiting new connections per source per timeframe is not a general solution since the attacker can spoof the packets to have multiple sources.
A normal connection between a user and a server. The three-way handshake is correctly performed.
SYN Flood. The attacker sends several packets but does not send the "ACK" back to the server. The connections are hence half-opened and consuming server resources. Alice, a legitimate user, tries to connect but the server refuses to open a connection resulting in a denial of service.
-------------------------------------------------
TCP RST复位攻击
1.RST标识位
RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。发送RST包关闭连接时，不必等缓冲区的包都发出去(FIN包)，直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。TCP处理程序会在自己认为的异常时刻发送RST包。
2个例子：
1)A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。
2)A和B已经正常建立连接，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，A网断了，A通过若干原因放弃了这个连接(例如进程重启)。网络恢复之后，B又开始或重发数据包，A不知道这连接哪来的，就发了个RST包强制把连接关闭，B收到后会出现connect reset by peer错误。
2.RST复位报文段
TCP在下列三种情况下产生RST复位报文段。
1).到不存在的端口的连接请求
产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；而TCP则使用复位。
2).异常终止一个连接
终止一个连接的正常方式是一方发送FIN，这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，这也称为异常释放。异常终止一个连接对应用程序来说有两个优点：
(1)丢弃任何待发数据并立即发送复位报文段；
(2)RST的接收方会区分另一端执行的是异常关闭还是正常关闭。
3).检测半关闭连接
如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接称为半打开的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。下面介绍一种建立半打开连接的情形。在bsdi上运行Telnet客户程序，通过它和svr4上的丢弃服务器建立连接。接着断开服务器主机与以太网的电缆，并重启服务器主机。这可以模拟服务器主机出现异常(在重启服务器之前断开以太网电缆是为了防止它向打开的连接发送FIN，某些TCP在关机时会这么做)。服务器主机重启后，我们重新接上电缆，并从客户向服务器发送一行字符。由于服务器的TCP已经重新启动，它将丢失复位前连接的所有信息，因此它不知道数据报文段中提到的连接。TCP处理的原则是接收方以复位作为应答。
3).RST复位攻击
A和服务器B之间建立了TCP连接，如果此时C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，就是RST攻击。
伪造这样的TCP包能造成什么后果？
(1)、假定C伪装成A发过去的包，这个包如果是RST包，冲区上所有数据B将会丢弃与A的缓，强制关掉连接。
(2)、如果发过去的包是SYN包，那么，B会表示A已经是正常连接却又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接。
如何伪造成A发给B的包？
这里有两个关键因素，源端口和序列号。
一个TCP连接都是四元组，由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以，如果C要伪造A发给B的包，要在上面提到的IP头和TCP头，把源IP、源端口、目标IP、目标端口都填对。
(1)这里B作为服务器，IP和端口是公开的；
(2)A是我们要下手的目标，IP当然知道，但A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以进行碰撞。
(3)序列号问题是与滑动窗口对应的，伪造的TCP包里需要填序列号，如果序列号的值不在A之前向B发送时B的滑动窗口内，B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决，因为一个sequence长度是32位，取值范围0-4294967296，如果窗口大小像上图中我抓到的windows下的65535的话，只需要相除，就知道最多只需要发65537(4294967296/65535=65537)个包就能有一个序列号落到滑动窗口内。RST包是很小，IP头＋TCP头才40字节，算算我们的带宽就知道这实在只需要几秒钟就能搞定。
那么，序列号不是问题，源端口会麻烦点，如果各个操作系统不能完全随机的生成源端口，或者黑客们能通过其他方式获取到source port，RST攻击存在可能。
4.如何预防
简单粗爆的一个可行方法：可以通过防火墙简单设置，建议使用防火墙将进来的包带RST位的包丢弃。