深入理解TCP协议及其源代码

Posted 2021-03-20 wangp19

 

1、三次握手的具体流程

所谓三次握手，即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

（1）第一次握手：客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段中不含应用层数据，其首部中的SYN标志位被置为1。另外，客户机会随机选择一个起始序号seq=J（连接请求报文不携带数据，但要消耗一个序号）。

（2）第二次握手：服务器的TCP收到连接请求报文段后，如同意建立连接，就向客户机发回确认，并为该TCP连接分配TCP缓存和变量。在确认报文段中，SYN和ACK位都被置为1，确认号字段的值为J+1，并且服务器随机产生起始序号seq=K（确认报文不携带数据，但也要消耗一个序号）。

（3）第三次握手：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置1，确认字段为K+1，该报文段可以携带数据，若不携带数据则不消耗序号。
成功进行以上三步后，就建立了TCP连接。

2、TCP三次握手缺陷引起的SYN泛洪攻击

  SYN泛洪攻击利用TCP三次握手协议的缺陷，向目标主机发送大量的伪造源地址的SYN连接请求，使得被攻击方资源耗尽，从而不能够为正常用户提供服务。

  在TCP协议中被称为三次握手的连接过程中，如果一个用户向服务器发送了SYN报文，服务器又发出 SYN+ACK 应答报文后未收到客户端的 ACK 报文，这种情况下服务器端会再次发送SYN+ACK给客户端，并等待一段时间后丢弃这个未完成的连接，这段时间的长度称为SYN Timeout，一般来说这个时间是分钟的数量级。

  SYN 泛洪攻击所做的就是利用这个SYN Timeout和TCP/IP协议族中的另一个漏洞: 报文传输过程中对报文的源 IP 地址完全信任进行攻击。SYN 泛洪攻击通过发送大量的伪造 TCP 连接报文而造成大量的 TCP 半连接,服务器端将为了维护这样一个庞大的半连接列表而消耗非常多的资源。这样服务器端将忙于处理攻击者伪造的TCP连接请求而无法处理正常连接请求,甚至会导致堆栈的溢出崩溃。

    造成SYN洪泛攻击最主要的原因是TCP/IP协议的脆弱性。TCP/IP是一个开放的协议平台，它将越来越多的网络连接在一起，它基于的对象是可信用户群，所以缺少一些必要的安全机制，带来很大的安全威胁。例如常见的IP欺骗、TCP连接的建立、ICMP数据包的发送都存在巨大的安全隐患，给SYN洪泛攻击带来可乘之机。在本次实验下我们将采用kali linux虚拟机进行泛洪攻击。

3、kali下Haping3工具介绍

Hping是一个命令行下使用的TCP/IP数据包组装/分析工具，其命令模式很像Unix下的ping命令，但是它不是只能发送ICMP回应请求，它还可以支持TCP、UDP、ICMP和RAW-IP协议，它有一个路由跟踪模式，能够在两个相互包含的通道之间传送文件。Hping常被用于检测网络和主机，其功能非常强大，可在多种操作系统下运行，如Linux，FreeBSD，NetBSD，OpenBSD，Solaris，MacOs X，Windows。

(1)Haping3工具主要功能：

防火墙测试 
实用的端口扫描 
网络检测，可以用不同的协议、服务类型（TOS）、IP分片 
手工探测MTU（最大传输单元）路径 
先进的路由跟踪，支持所有的协议 
远程操作系统探测 
远程的运行时间探测 
TCP/IP堆栈审计 

(2)haping3命令主要参数

 

  -h  --help        显示帮助

 

  -v  --version      显示版本

 

  -c  --count       发送数据包的数目

 

  -i  --interval     发送数据包间隔的时间 (uX即X微秒, 例如： -i u1000)

 

     --flood     尽最快发送数据包，不显示回复。

 

  -n  --numeric      数字化输出，象征性输出主机地址。

 

  -q  --quiet       安静模式

 

  -I  --interface    网卡接口 (默认路由接口)

 

  -V  --verbose     详细模式

 

  -D  --debug       调试信息

 

  -z  --bind      绑定ctrl+z到ttl(默认为目的端口)

 

  -Z  --unbind      取消绑定ctrl+z键

 

  -a   源地址欺骗。伪造IP攻击，防火墙就不会记录你的真实IP了，当然回应的包你也接收不到了

 

UDP/TCP 模式

  -s  --baseport          // 缺省随机源端口

  -p  --destport          // 缺省随机源端口

  -k  --keep         // 保持源端口

  -w  --win         winsize (default 64)// win的滑动窗口。windows发送字节(默认64)

  -O  --tcpoff         // 设置伪造tcp数据偏移量(取代tcp地址长度除4)

  -Q  --seqnum        // 仅显示tcp序列号

  -b  --badcksum        (尝试)发送具有错误IP校验和数据包。许多系统将修复发送数据包的IP校验和。所以你会得到错误UDP/TCP校验和。

  -M  --setseq        设置TCP序列号 

  -L  --setack        设置TCP的ack 

  -F  --fin        set FIN flag

  -S  --syn        set SYN flag

  -R  --rst        set RST flag

  -P  --push        set PUSH flag

  -A  --ack        set ACK flag  

  -U  --urg        set URG flag      

  -X  --xmas        set X unused flag (0x40)

  -Y  --ymas        set Y unused flag (0x80)

 

4、虚拟机模拟泛洪攻击

在同一个局域网下，在两台虚拟机之间进行SYN Flood攻击，其中攻击者为Kali Linux，被攻击者为ubuntu。

首先查看两个虚拟机的IP地址，看是否在同一个网段下，并测试之间的连通性。

 

 

 

 

 

发现二者之间能够ping通。

接下来我们在kali linux下发动泛洪攻击，同时观察ubuntu的cpu使用情况。

 

 未发动泛洪攻击前的ubuntu的cpu使用情况如下所示，cpu使用率很低。

 

 发动泛洪攻击后，其cpu使用情况如下所示，同时在ubuntu内进行一些操作时，系统变得非常卡，连打开一个文件夹都反应非常慢，当把发送数据包间隔的时间进一步缩小，ubuntu虚拟机直接黑屏。

 

 最后在ubuntu下使用wireshark进行抓包分析

 

 

 

因为在进行泛洪攻击时隐藏了源IP地址，伪造IP地址为10.0.1.1，所以发现有大量的源地址为10.0.1.1的包在给目的主机发送请求连接，进行SYN泛洪攻击，目的主机处理不过来，SYN一直持续攻击，一直消耗系统的资源，最终导致系统崩溃。

再详细看一下

 

 

 

目的主机向收到的连接请求进行了确认，但是却收不到回复，服务器端会再次发送SYN+ACK给客户端，服务器端将忙于处理攻击者伪造的TCP连接请求而无法处理正常连接请求，如果这些半连接的握手请求是恶意程序发出，并且持续不断，那么就会导致服务端较长时间内丧失服务功能——这样就形成了DoS攻击。

5、如何防御SYN泛洪攻击

(1)缩短SYN timeout时间

(2)设置SYN cookie
  给每一个请求连接的IP地址分配一个cookie，如果短时间内连续受到某个IP的重复SYN文，认定是受到了攻击，以后从这个IP地址来的包会被丢弃。服务器端在收到客户端的SYN 包后，防火墙代替服务器向客户端发送SYN+ACK包，如果客户端在一段时间内没有应答或中间的网络设备发回了ICMP错误消息，防火墙则丢弃此状态信息； 如果客户端的ACK到达，防火墙代替客户端向服务器发送SYN包，并完成后续的握手最终建立客户端到服务器的连接。通过这种技术，保证了每个SYN包源的真实有效性，确保服务器不被虚假请求浪费资源，从而防范了对服务器的SYN 泛洪攻击。SYN cookie不在主机上保存任何状态，只保存所有初始TCP连接状态，用一个队列来存储。它使用编码函数将所有信息加密后用SYN+ACK发送到客户端，并且将最后的三次握手最后部分返回给服务器。 当然它还有一个缺陷就是不能将初始的SYN的所有选项加密成cookie，第二个问题就是TCP协议要求对不应答的数据进行转发，假设服务器在放弃或者丢弃连接之前转发SYN+ACK , 就会发送一个RST给客户端去关闭这个连接.当SYN + ACK到达客户端，但是返回的ACK丢失，这种结果就导致客户端和服务器端状态建立不平等。 通常，这种情况被服务器转发处理，但是在SYN cookie中，主机中不保存任何状态，这种转发的机制是不存在的。
  SYN cookie是通过返回的ACK来完成整个连接的建立，不依赖于流程化的SYN, SYN+ACK传送。这可能造成ACK请求ROOD攻击， 这种攻击依赖使用正确的值来允许建立连接。这也提供一个绕过防火墙的可能，因为防火墙依赖SYN来过滤外部连接，而现在建立连接根本不依靠SYN包了。另一个SYN cookie的困难就是同TCPV6 的兼容上。TCP/IP的运作依靠发送系列化的对等递增的序列数，并且用先前接受的SYN SEQ值来建立连接完成三次握手过程。 然而，一旦TCP连接完成了，TCP/IP的序列号的使用是强制性的，这要求服务器纪录下初始的序列号，不论这个项是否需要。 因此SYN cookie不能应用于高性能要求的服务器。通常的方法是使用状态分配机制，并且只在大量状态被分配的时候才启用SYN cookie。

(3)使用防火墙
  防火墙位于客户端和服务器之间．因此利用防火墙来阻止DoS攻击能有效地保护内部的服务器。针对SYN Flood，防火墙通常有三种防护方式：SYN网关、被动式SYN网关和SYN中继。
  1）SYN网关： 防火墙收到客户端的SYN包时，直接转发给服务器：防火墙收到服务器的SYN/ACK包后，一方面将SYN/ACK包转发给客户端，另一方面以客户端的名义给服务器回送一个ACK包．完成TCP的三次握手，让服务器端由半连接状态进入连接状态。当客户端真正的ACK包到达时。有数据则转发给服务器，否则丢弃该包。由于服务器能承受连接状态要比半连接状态高得多。所以这种方法能有效地减轻对服务器的攻击。
  2）被动式SYN网关： 设置防火墙的SYN请求超时参数，让它远小于服务器的超时期限．防火墙负责转发客户端发往服务器的SYN包，服务器发往客户端的SYN/ACK包、以及客尸，端发往服务器的ACK包。这样，如果客户端在防火墙计时器到期时还没发送ACK包，防火墙则往服务器发送RST包，以使服务器从队列中删去该半连接。由于防火墙的超时参数远小于服务器的超时期限，出此这样能有效防止SYN Flood攻击．
  3）SYN中继： SYN中继防火墙在收到客户端的SYN包后．并不向服务器转发而是记录该状态信息后主动给客户端回送SYN/ACK包，如果收 到客户端的ACK包。表明是正常访问，由防火墙向服务器发送SYN包并完成三次握手。这样由防火墙作为代理来实现客户端和服务器端的连接。可以完全过滤不可用连接发往服务器。

 

参考：https://blog.csdn.net/qq_38684504/article/details/84308100