三次握手中服务器回复的ACK+SYN是一个数据段还是两个?

三次握手中服务器回复的ACK+SYN是一个数据段还是两个?,第1张

TCP握手协议在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;SYN:同步序列编号(SynchronizeSequenceNumbers)第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。完成三次握手,客户端与服务器开始传送数据

21端口用于连接,20端口用于传输数据。

1、区别说明:

1、进行FTP文件传输中,客户端首先连接到FTP服务器的21端口,进行用户的认证,认证成功后,要传输文件时,服务器会开一个端口为20来进行传输数据文件。

2、端口20才是真正传输所用到的端口,端口21只用于FTP的登陆认证。

3、我们平常下载文件时,会遇到下载到99%时,文件不完成,不能成功的下载。其实是因为文件下载完毕后,还要在21端口再行进行用户认证,而下载文件的时间如果过长,客户机与服务器的21端口的连接会被服务器认为是超时连接而中断掉,就是这个原因。解决方法就是设置21端口的响应时间。

3、端口说明:

1、21端口主要用于FTP(File Transfer Protocol,文件传输协议)服务,FTP服务主要是为了在两台计算机之间实现文件的上传与下载,一台计算机作为FTP客户端,另一台计算机作为FTP服务器,可以采用匿名(anonymous)登录和授权用户名与密码登录两种方式登录FTP服务器。

2、目前,通过FTP服务来实现文件的传输是互联网上上传、下载文件最主要的方法。另外,还有一个20端口是用于FTP数据传输的默认端口号。

3、在Windows中可以通过Internet信息服务(IIS)来提供FTP连接和管理,也可以单独安装FTP服务器软件来实现FTP功能,比如常见的FTP Serv-U。

4、 *** 作建议:

因为有的FTP服务器可以通过匿名登录,所以常常会被黑客利用。另外,21端口还会被一些木马利用,比如Blade Runner、FTP Trojan、Doly Trojan、WebEx等等。如果不架设FTP服务器,建议关闭21端口。

5、工作模式:

分为FTP Port模式和FTP Passive模式,Port模式的FTP步骤如下:

1、 客户端发送一个TCP SYN(TCP同步)包给服务器段众所周知的FTP控制端口21,客户端使用暂时的端口作为它的源端口;

2、 服务器端发送SYN ACK(同步确认)包给客户端,源端口为21,目的端口为客户端上使用的暂时端口;

3、 客户端发送一个ACK(确认)包;客户端使用这个连接来发送FTP命令,服务器端使用这个连接来发送FTP应答;

4、 当用户请求一个列表(List)请求或者发起一个要求发送或者接受文件的请求,客户端软件使用PORT命令,这个命令包含了一个暂时的端口,客户端希望服务器在打开一个数据连接时候使用这个暂时端口;PORT命令也包含了一个IP地址,这个IP地址通常是客户自己的IP地址,而且FTP也支持第三方(third-party)模式,第三方模式是客户端告诉服务器端打开与另台主机的连接;

5、 服务器端发送一个SYN包给客户端的暂时端口,源端口为20,暂时端口为客户端在PORT命令中发送给服务器端的暂时端口号;

拒绝服务攻击(Denial of Service,DoS)是目前比较有效而又非常难于防御的一种网络攻击方式,它的目的就是使服务器不能够为正常访问的用户提供服务。所以,DoS对一些紧密依靠互联网开展业务的企业和组织带来了致命的威胁。
SYN Flood是最为有效和流行的一种DoS攻击形式。它利用TCP三次握手协议的缺陷,向目标主机发送大量的伪造源地址的SYN连接请求,消耗目标主机的资源,从而不能够为正常用户提供服务。
11 TCP连接建立的过程
要掌握SYN Flood攻击的基本原理,必须先介绍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连接完成。如图1所示:
12 攻击原理
在SYN Flood攻击中,黑客机器向受害主机发送大量伪造源地址的TCP SYN报文,受害主机分配必要的资源,然后向源地址返回SYN+ACK包,并等待源端返回ACK包,如图2所示。由于源地址是伪造的,所以源端永远都不会返回ACK报文,受害主机继续发送SYN+ACK包,并将半连接放入端口的积压队列中,虽然一般的主机都有超时机制和默认的重传次数,但是由于端口的半连接队列的长度是有限的,如果不断的向受害主机发送大量的TCP SYN报文,半连接队列就会很快填满,服务器拒绝新的连接,将导致该端口无法响应其他机器进行的连接请求,最终使受害主机的资源耗尽。
TCP客户端
客户端端口
(1024-65535)
TCP服务器端
服务器端口
(1-1023)
SYN
SYN/ACK
伪造源地址
2 几种防御技术
SYN Flood攻击给互联网造成重大影响后,针对如何防御SYN Flood攻击出现了几种比较有效的技术。
21 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技术仍然是一种有效的技术。
22 地址状态监控的解决方法
地址状态监控的解决方法是利用监控工具对网络中的有关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状态则不变。
状态的转换图如图3所示:
初态
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攻击,而不影响正常用户的连接。
3 小结
本文介绍了SYN Flood攻击的基本原理,然后详细描述了两种比较有效和方便实施的防御方法:SYN-cookie技术和基于监控的源地址状态技术。SYN-cookie技术实现了无状态的握手,避免了SYN Flood的资源消耗。基于监控的源地址状态技术能够对每一个连接服务器的IP地址的状态进行监控,主动采取措施避免SYN Flood攻击的影响。这两种技术是目前所有的防御SYN Flood攻击的最为成熟和可行的技术。

1客户端先向服务器端发送①同步报文(SYN)
2服务器端收到请求之后发送②回复报文(SYN,ACK)
3客户端收到回复报文之后向服务器端发送③ACK报文

4客户端向服务器端发送④>握手信号 在数字电路中(如计算机),设备甲和设备乙交换信息(通讯),双方采用某个通讯规范(协议)来交换数据,它们的联络过程就叫“握手”,用来联络的信号就叫“握手信号”,单向联络通常用两根联络线:请求,应答,双向则四条。 握手协议 一、TCP握手协议 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认; 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=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存活时间。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/10568380.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-09
下一篇 2023-05-09

发表评论

登录后才能评论

评论列表(0条)

保存