Tcp连接的建立及SYN洪泛攻击

Posted 2021-12-16 修心_666

Tcp连接的建立及SYN洪泛攻击

Tcp连接的建立（三次握手）

​ 连接建立前，服务器进程处于LISTEN状态，等待客户的连接请求。

​   一： 客户端发送tcp连接请求报文段，Tcp首部SYN=1，seq=x。(Tcp规定，SYN报文段不能携带数据，但要消耗掉一个序号)

​   二： 服务器的Tcp收到连接请求报文段后，如果同意建立连接，则向客户端发回确认，并为该Tcp连接分配缓存和变量。确认报文段中，SYN=1，ACK=1，ack=x+1，seq=y（自己选择的一个初始序号y）。（确认报文段中不能携带数据，但也要消耗一个序号）

​   三： 客户端收到确认报文段之后，还要向服务器给出确认，并为该Tcp连接分配缓存和变量。ACK=1，ack=y+1，seq=x+1。该报文段可以携带数据，若不携带数据，则不消耗序号。

​   服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于收到SYN洪泛攻击。

SYN洪泛攻击

​   SYN攻击利用的是TCP的三次握手机制，攻击端利用伪造的IP地址向被攻击端发出请求，而被攻击端发出的响应 报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。

  什么是SYN洪泛攻击？

​   TCP SYN泛洪发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

  SYN泛洪攻击原理

​   那么假如在这“握手”的过程中，客户端程序因为莫名崩溃等原因，收到SYN+ACK报文后不再回以ACK，服务端将如何处置呢？这时服务端会“优雅地”再等等，会不会是发送的包丢失了呢？于是重新发送一遍SYN+ACK，再收不到来自客户端的ACK响应的话，就把这次连接丢弃掉。这个过程大约会“优雅地”持续分钟级，这个持续时间被称作SYN timeout时间。如果只有个别这样的异常情况，目标服务端处理起来自是毫不费力；可如果大量这样的情况出现，对服务端来说就不堪重负了。这是为什么呢？

​   如果大量的握手请求涌向TCP服务端，而它们只发出SYN报文而不以ACK响应结束握手，服务端就要为这每一个请求都维持约一分多钟的连接去等待ACK，也就形成所谓的“半连接”。维护这些半连接是需要消耗很多服务器的网络连接资源的。如果短时间内这些资源几乎都被半连接占满，那么正常的业务请求在这期间就得不到服务，处于等待状态。

​   更进一步的，如果这些半连接的握手请求是恶意程序发出，并且持续不断，那么就会导致服务端较长时间内丧失服务功能——这就形成了DoS（Denial of Service拒绝服务）攻击。这种攻击方式就称为SYN泛洪（SYN flood）攻击。

​   由于正常的TCP三次握手中发出去多少SYN报文，就会收到多少SYN+ACK报文。攻击方需要将这些消息丢弃，同时为了隐藏自己，于是需要大量伪造泛洪攻击的源地址，随机改成其它地址。为达到SYN泛洪攻击的效果，这些伪造的源地址最好无法响应SYN+ACK，如这些源地址的主机根本不存在，或者被防火墙等网络设施拦截，等等。

  防范措施

​   对于SYN泛洪攻击的防范，优化主机系统设置是常用的手段。如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。