TCP SYNACK FINRSTPSHURG 详解.docx

TCP SYNACK FINRSTPSHURG 详解.docx

《TCP SYNACK FINRSTPSHURG 详解.docx》由会员分享，可在线阅读，更多相关《TCP SYNACK FINRSTPSHURG 详解.docx（11页珍藏版）》请在冰豆网上搜索。

TCPSYNACKFINRSTPSHURG详解

三次握手Three-wayHandshake

一个虚拟连接的建立是通过三次握手来实现的

1.（B）-->[SYN]-->（A）

假如服务器A和客户机B通讯.当A要和B通信时，B首先向A发一个SYN（Synchronize）标记的包，告诉A请求建立连接.

注意:

一个SYN包就是仅SYN标记设为1的TCP包（参见TCP包头Resources）.认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。

因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不能让外部任何主机主动建立连接。

2.（B）<--[SYN/ACK]<--（A）

接着，A收到后会发一个对SYN包的确认包（SYN/ACK）回去，表示对第一个SYN包的确认，并继续握手操作.

注意:

SYN/ACK包是仅SYN和ACK标记为1的包.

3.（B）-->[ACK]-->（A）

B收到SYN/ACK包,B发一个确认包（ACK），通知A连接已建立。

至此，三次握手完成，一个TCP连接完成

Note:

ACK包就是仅ACK标记设为1的TCP包.需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位

这就是为何连接跟踪很重要的原因了.没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤（Ipchains）收到ACK包时,会让它通过（这绝对不是个好主意）.而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包

四次握手Four-wayHandshake

四次握手用来关闭已建立的TCP连接

1.（B）-->ACK/FIN-->（A）

2.（B）<--ACK<--（A）

3.（B）<--ACK/FIN<--（A）

4.（B）-->ACK-->（A）

注意:

由于TCP连接是双向连接,因此关闭连接需要在两个方向上做。

ACK/FIN包（ACK和FIN标记设为1）通常被认为是FIN（终结）包.然而,由于连接还没有关闭,FIN包总是打上ACK标记.没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的

连接复位Resettingaconnection

四次握手不是关闭TCP连接的唯一方法.有时,如果主机需要尽快关闭连接（或连接超时,端口或主机不可达）,RST（Reset）包将被发送.注意在，由于RST包不是TCP连接中的必须部分,可以只发送RST包（即不带ACK标记）.但在正常的TCP连接中RST包可以带ACK确认标记

请注意RST包是可以不要收到方确认的?

无效的TCP标记InvalidTCPFlags

到目前为止，你已经看到了SYN,ACK,FIN,和RST标记.另外，还有PSH（Push）和URG（Urgent）标记.

最常见的非法组合是SYN/FIN包.注意:

由于SYN包是用来初始化连接的,它不可能和FIN和RST标记一起出现.这也是一个恶意攻击.

由于现在大多数防火墙已知SYN/FIN包,别的一些组合,例如SYN/FIN/PSH,SYN/FIN/RST,SYN/FIN/RST/PSH。

很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。

别的已知的非法包有FIN（无ACK标记）和"NULL"包。

如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有ACK标记。

"NULL"包就是没有任何TCP标记的包（URG,ACK,PSH,RST,SYN,FIN都为0）。

到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。

当你发现这些不正常的包时，肯定有人对你的网络不怀好意。

UDP（用户数据包协议UserDatagramProtocol）

TCP是面向连接的，而UDP是非连接的协议。

UDP没有对接受进行确认的标记和确认机制。

对丢包的处理是在应用层来完成的。

（oraccidentalarrival）.

此处需要重点注意的事情是：

在正常情况下，当UDP包到达一个关闭的端口时，会返回一个UDP复位包。

由于UDP是非面向连接的,因此没有任何确认信息来确认包是否正确到达目的地。

因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口（?

）。

由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口（非防火墙的）的UDP包将不会到达目的，它们将返回一个复位UDP包。

因为这个原因，UDP端口扫描总是不精确、不可靠的。

看起来大UDP包的碎片是常见的DOS（DenialofService）攻击的常见形式（这里有个DOS攻击的例子，）.

ICMP（网间控制消息协议InternetControlMessageProtocol）

如同名字一样，ICMP用来在主机/路由器之间传递控制信息的协议。

ICMP包可以包含诊断信息（ping,traceroute-注意目前unix系统中的traceroute用UDP包而不是ICMP），错误信息（网络/主机/端口不可达network/host/portunreachable）,信息（时间戳timestamp,地址掩码addressmaskrequest,etc.），或控制信息（sourcequench,redirect,etc.）。

你可以在http:

//www.iana.org/assignments/icmp-parameters中找到ICMP包的类型。

尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。

Redirect（5）,AlternateHostAddress（6）,RouterAdvertisement（9）能用来转发通讯。

Echo（8）,Timestamp（13）andAddressMaskRequest（17）能用来分别判断主机是否起来，本地时间和地址掩码。

注意它们是和返回的信息类别有关的。

它们自己本身是不能被利用的，但它们泄露出的信息对攻击者是有用的。

ICMP消息有时也被用来作为DOS攻击的一部分（例如：

洪水pingfloodping,死ping?

呵呵，有趣pingofdeath）?

/p>

包碎片注意ANoteAboutPacketFragmentation

如果一个包的大小超过了TCP的最大段长度MSS（MaximumSegmentSize）或MTU（MaximumTransmissionUnit），能够把此包发往目的的唯一方法是把此包分片。

由于包分片是正常的，它可以被利用来做恶意的攻击。

因为分片的包的第一个分片包含一个包头，若没有包分片的重组功能，包过滤器不可能检测附加的包分片。

典型的攻击Typicalattacksinvolveinoverlappingthepacketdatainwhichpacketheaderis典型的攻击TypicalattacksinvolveinoverlappingthepacketdatainwhichpacketheaderisnormaluntilisitoverwrittenwithdifferentdestinationIP（orport）therebybypassingfirewallrules。

包分片能作为DOS攻击的一部分，它可以crasholderIPstacks或涨死CPU连接能力。

Netfilter/Iptables中的连接跟踪代码能自动做分片重组。

它仍有弱点，可能受到饱和连接攻击，可以把CPU资源耗光。

握手阶段：

序号方向seqack

1　　A->B100000

2B->A2000010000+1=10001

3A->B1000120000+1=20001

解释：

1：

A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0

2：

B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：

你的请求我已收到，我这方的数据流就从这个数开始。

B的ACK是A的seq加1，即10000＋1＝10001

3：

A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：

你的回复我收到了，我这方的数据流就从这个数开始。

A此时的ACK是B的seq加1，即20000+1=20001

数据传输阶段：

序号　　方向　　　　　　seqacksize

23A->B40000700001514

24B->A7000040000+1514-54=4146054

25A->B4146070000+54-54=700001514

26B->A7000041460+1514-54=4292054

解释：

23:

B接收到A发来的seq=40000,ack=70000,size=1514的数据包

24:

于是B向A也发一个数据包，告诉B，你的上个包我收到了。

B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小（不包括以太网协议头，IP头，TCP头），以证实B发过来的数据全收到了。

25:

A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。

于是它再发一个数据包给B。

这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq（70000）加上包的size（54）填充,即ack=70000+54-54（全是头长，没数据项）。

其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.

另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如图1所示。

（1）第一次握手：

建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。

（2）第二次握手：

服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。

（3）第三次握手：

客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

                              图1TCP三次握手建立连接

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。

这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。

收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。

首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。

和SYN一样，一个FIN将占用一个序号。

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

TCP采用四次挥手关闭连接如图2所示。

                              图2 TCP四次挥手关闭连接

1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。

但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

TCP状态机

 TCP协议的操作可以使用一个具有11种状态的有限状态机（FiniteStateMachine）来表示，图3-12描述了TCP的有限状态机，图中的圆角矩形表示状态，箭头表示状态之间的转换，各状态的描述如表3-2所示。

图中用粗线表示客户端主动和被动的服务器端建立连接的正常过程：

客户端的状态变迁用粗实线，服务器端的状态变迁用粗虚线。

细线用于不常见的序列，如复位、同时打开、同时关闭等。

图中的每条状态变换线上均标有“事件／动作”：

事件是指用户执行了系统调用（CONNECT、LISTEN、SEND或CLOSE）、收到一个报文段（SYN、FIN、ACK或RST）、或者是出现了超过两倍最大的分组生命期的情况；动作是指发送一个报文段（SYN、FIN或ACK）或什么也没有（用“－”表示）。

每个连接均开始于CLOSED状态。

当一方执行了被动的连接原语（LISTEN）或主动的连接原语（CONNECT）时，它便会脱离CLOSED状态。

如果此时另一方执行了相对应的连接原语，连接便建立了，并且状态变为ESTABLISHED。

任何一方均可以首先请求释放连接，当连接被释放后，状态又回到了CLOSED。

表3-2TCP状态表

状态

描述

CLOSED

关闭状态，没有连接活动或正在进行

LISTEN

监听状态，服务器正在等待连接进入

SYNRCVD

收到一个连接请求，尚未确认

SYNSENT

已经发出连接请求，等待确认

ESTABLISHED

连接建立，正常数据传输状态

FINWAIT1

（主动关闭）已经发送关闭请求，等待确认

FINWAIT2

（主动关闭）收到对方关闭确认，等待对方关闭请求

TIMEDWAIT

完成双向关闭，等待所有分组死掉

CLOSING

双方同时尝试关闭，等待对方确认

CLOSEWAIT

（被动关闭）收到对方关闭请求，已经确认

LASTACK

（被动关闭）等待最后一个关闭确认，并等待所有分组死掉

1.正常状态转换

  我们用图3-13来显示在正常的TCP连接的建立与终止过程中，客户与服务器所经历的不同状态。

读者可以对照图3-12来阅读，使用图3-12的状态图来跟踪图3-13的状态变化过程，以便明白每个状态的变化：

∙服务器端首先执行LISTEN原语进入被动打开状态（LISTEN），等待客户端连接；

∙当客户端的一个应用程序发出CONNECT命令后，本地的TCP实体为其创建一个连接记录并标记为SYNSENT状态，然后给服务器发送一个SYN报文段；

∙服务器收到一个SYN报文段，其TCP实体给客户端发送确认ACK报文段同时发送一个SYN信号，进入SYNRCVD状态；

∙客户端收到SYN+ACK报文段，其TCP实体给服务器端发送出三次握手的最后一个ACK报文段，并转换为ESTABLISHED状态；

∙服务器端收到确认的ACK报文段，完成了三次握手，于是也进入ESTABLISHED状态。

 在此状态下，双方可以自由传输数据。

当一个应用程序完成数据传输任务后，它需要关闭TCP连接。

假设仍由客户端发起主动关闭连接。

∙客户端执行CLOSE原语，本地的TCP实体发送一个FIN报文段并等待响应的确认（进入状态FINWAIT1）；

∙服务器收到一个FIN报文段，它确认客户端的请求发回一个ACK报文段，进入CLOSEWAIT状态；

∙客户端收到确认ACK报文段，就转移到FINWAIT2状态，此时连接在一个方向上就断开了；

∙服务器端应用得到通告后，也执行CLOSE原语关闭另一个方向的连接，其本地TCP实体向客户端发送一个FIN报文段，并进入LASTACK状态，等待最后一个ACK确认报文段；

∙客户端收到FIN报文段并确认，进入TIMEDWAIT状态，此时双方连接均已经断开，但TCP要等待一个2倍报文段最大生存时间MSL（MaximumSegmentLifetime），确保该连接的所有分组全部消失，以防止出现确认丢失的情况。

当定时器超时后，TCP删除该连接记录，返回到初始状态（CLOSED）。

∙服务器收到最后一个确认ACK报文段，其TCP实体便释放该连接，并删除连接记录，返回到初始状态（CLOSED）。

∙

∙ 

∙

∙ 

∙

∙ 

∙

∙ 

∙