三次握手

三次握手 三次握手 [编辑本段] 三次握手-简介 所谓的“三握手”:对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据 量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，TCP 在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。TCP 总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。 [编辑本段] 三次握手-释意 TCP握手 在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手:建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认; 第二次握手:服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个ASK包(ask=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态; 三次握手协议 第三次握手:客户端收到服务器的SYN，ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念: 未连接队列:在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包(syn=j)开设一个条目，该条目明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。 Backlog参数:表示未连接队列的最大容纳数目。 SYN-ACK 重传次数 服务器发送完SYN,ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。 半连接存活时间:是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。 [1] * 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 的 三次握手协议 经典案例，这是后来被称为MITNICK 攻击中KEVIN 开创了两种攻击技术: TCP 会话劫持和SYN FLOOD(同步洪流) 在这里我们讨论的是TCP 会话劫持的问。 先让我们明白TCP 建立连接的基本简单的过程。为了建设一个小型的模仿环境我们假设有3 台接入互联网的机器。A 为攻击者操纵的攻击机。B 为中介跳板机器(受信任的服务器)。C 为受害者使用的机器(多是服务器)，这里把C 机器锁定为目标机器。A 机器向B机器发送SYN 包，请求建立连接，这时已经响应请求的B 机器会向A 机器回应SYN/ACK表明同意建立连接，当A 机器接受到B 机器发送的SYN/ACK 回应时，发送应答ACK 建立 A 机器与B 机器的网络连接。这样一个两台机器之间的TCP 通话信道就建立成功了。B 终端受信任的服务器向C 机器发起TCP 连接，A 机器对服务器发起SYN 信息，使C 机器不能响应B 机器。在同时A 机器也向B 机器发送虚假的C 机器回应的SYN 数据包，接收到SYN 数据包的B 机器(被C 机器信任)开始发送应答连接建立的SYN/ACK 数据包，这时C 机器正在忙于响应以前发送的SYN 数据而无暇回应B 机器，而A 机器的攻击者预测出B 机器包的序列号(现在的TCP 序列号预测难度有所加大)假冒C 机器向B 机器发送应答ACK 这时攻击者骗取B 机器的信任，假冒C 机器与B 机器建立起TCP 协议的对话连接。这个时候的C 机器还是在响应攻击者A 机器发送的SYN 数据。 TCP 协议栈的弱点:TCP 连接的资源消耗，其中包括:数据包信息、条件状态、序列号等。通过故意不完成建立连接所需要的三次握手过程，造成连接一方的资源耗尽。通过攻击者有意的不完成建立连接所需要的三次握手的全过程，从而造成了C 机器的资源耗尽。序列号的可预测性，目标主机应答连接请求时返回的SYN/ACK 的序列号是可预测的。 一、TCP三次握手 传输控制协议(Transport Control Protocol)是一种面向连接的，可靠的传输层协议。面向连接是指一次正常的TCP传输需要通过在TCP客户端和TCP服务端建立特定的虚电路连接来完成，该过程通常被称为“三次握手”。可靠性可以通过很多种来提供保证，在这里我们关心的是数据序列和确认。TCP通过数据分段(Segment)中的序列号保证所有传输的数据可以在远端按照正常的次序进行重组，而且通过确认保证数据传输的完整性。要通过TCP传输数据，必须在两端主机之间建立连接。举例说明，TCP客户端需要和TCP服务端建立连接，过程如下所示: TCP Client Flags TCP Server 1 Send SYN (seq=w) ----SYN---> SYN Received 2 SYN/ACK Received <---SYN/ACK---- Send SYN (seq=x)， ACK (w+1) 3 Send ACK (x+1) ----ACK---> ACK Received， Connection Established w: ISN (Initial Sequence Number) of the Client x: ISN of the Server 在第一步中，客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法，需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后，在第二步以自己的ISN回应(SYN标志置位)，同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中，客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接，开始全双工模式的数据传输过程。 二、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结构的系统中，如下所示: OS Backlog BL+ Grace Notes SunOS 4.x.x 5 8 IRIX 5.2 5 8 Linux 1.2.x 10 10 Linux does not have this grace margin FreeBSD 2.1.0 32 FreeBSD 2.1.5 128 Win NTs 3.5.1 6 6 NT does not appear to have this margin Win NTw 4.0 6 6 NT has a pathetic backlog 五、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标志，则该分段丢弃。并释放相应的内存。