精华内容
下载资源
问答
  • 【1】TCP三次握手 【2】SYN Flood 1、TCP连接建立——三次握手 几个概念: 【1】seq:序号,占4个字节,范围[0,4284967296],由于TCP是面向字节流的,在一个1个TCP连接中传送字节流中国的每一个...

    概述

    总结一下TCP中3次握手过程,以及其原生的缺陷 引起的SYN Flood的介绍

    【1】TCP三次握手

    【2】SYN Flood


    1、TCP连接建立——三次握手

    几个概念:

    【1】seq:序号,占4个字节,范围[0,4284967296],由于TCP是面向字节流的,在一个1个TCP连接中传送字节流中国的每一个字节都按照顺序编号,此外序号是循环使用的

    【2】ACK: 仅当ACK=1时确认字段才有效,当ACK=0时确认字段无效,并且TCP规定,在连接建立后所有的传送报文段都必须要把ACK置为1

    【3】SYN:同步序列号,用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段;若对方同意连接,则响应报文中SYN=1,ACK=1

    【4】FIN :用来释放一个连接,当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接


    1.1、3次握手过程

    服务端的TCP进程先创建传输控制块TCB,准备接受客户端进程的连接请求,然后服务端进程处于LISTEN状态,等待客户端的连接请求,如有,则作出响应。
        1、客户端的TCP进程也首先创建传输控制模块TCB,然后向服务端发出连接请求报文段,该报文段首部中的SYN=1,ACK=0,同时选择一个初始序号 seq=i。TCP规定,SYN=1的报文段不能携带数据,但要消耗掉一个序号。这时,TCP客户进程进入SYN—SENT(同步已发送)状态,这是 TCP连接的第一次握手。
        2、服务端收到客户端发来的请求报文后,如果同意建立连接,则向客户端发送确认。确认报文中的SYN=1,ACK=1,确认号ack=i+1,同时为自己 选择一个初始序号seq=j。同样该报文段也是SYN=1的报文段,不能携带数据,但同样要消耗掉一个序号。这时,TCP服务端进入SYN—RCVD(同 步收到)状态,这是TCP连接的第二次握手。
        3、TCP客户端进程收到服务端进程的确认后,还要向服务端给出确认。确认报文段的ACK=1,确认号ack=j+1,而自己的序号为seq=i+1。 TCP的标准规定,ACK报文段可以携带数据,但如果不携带数据则不消耗序号,因此,如果不携带数据,则下一个报文段的序号仍为seq=i+1。这 时,TCP连接已经建立,客户端进入ESTABLISHED(已建立连接)状态。这是TCP连接的第三次握手,可以看出第三次握手客户端已经可以发送携带 数据的报文段了。
        当服务端收到确认后,也进入ESTABLISHED(已建立连接)状态。


    1.2、关于第三次握手的解释

    前俩比较容易理解,第三次握手看似多余其实不然,这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判

    比如:客户端发送了一个连接请求报文段A到服务端,但是在某些网络节点上长时间滞留了,而后客户端又超时重发了一个连接请求报文段B该服务端,而后 正常建立连接,数据传输完毕,并释放了连接。但是请求报文段A延迟了一段时间后,又到了服务端,这本是一个早已失效的报文段,但是服务端收到后会误以为客户端又发出了一次连接请求,于是向客户端发出确认报文段,并同意建立连接。那么问题来了,假如这里没有三次握手,这时服务端只要发送了确认,新的 连接就建立了,但由于客户端没有发出建立连接的请求,因此不会理会服务端的确认,也不会向服务端发送数据,而服务端却认为新的连接已经建立了,并在 一直等待客户端发送数据,这样服务端就会一直等待下去,直到超出保活计数器的设定值,而将客户端判定为出了问题,才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手,客户端就不会向服务端发出确认,服务端由于收不到确认,就知道客户端没有要求建立连接,从而不建立该连接。




    2、 缺陷引起的SYN Flood

    2.1、SYN Flood 攻击

    SYN- Flood攻击是当前网络上最为常见的DDoS攻击,也是最为经典的拒绝服务攻击,它就是利用了TCP协议实现上的一个缺陷,通过向网络服务所在端口发送大量 的伪造源地址的攻击报文,就可能造成目标服务器中的半开连接队列被占满,从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现,但至今仍然显示 出强大的生命力。很多操作系统,甚至防火墙、路由器都无法有效地防御这种攻击,而且由于它可以方便地伪造源地址,追查起来非常困难。它的数据包特征通常 是,源发送了大量的SYN包,并且缺少三次握手的最后一步握手ACK回复。

    原理:攻击者首先伪造地址对 服务器发起SYN请求,服务器回应(SYN+ACK)包,而真实的IP会认为,我没有发送请求,不作回应。服务 器没有收到回应,这样的话,服务器不知 道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者 如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。

    2.2、SYN Flood 防护措施

    主要通过以下3种方式

    1. 无效连接监视释放

    这种方法不停的监视系统中半开连接和不活动连接,当达到一定阈值时拆除这些连接,释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉,”伤敌一千,自损八百“

    2. 延缓TCB分配方法

    SYN Flood关键是利用了,SYN数据报文一到,系统立即分配TCB资源,从而占用了系统资源,因此有俩种技术来解决这一问题

    Syn Cache技术

    这种技术在收到SYN时不急着去分配TCB,而是先回应一个ACK报文,并在一个专用的HASH表中(Cache)中保存这种半开连接,直到收到正确的ACK报文再去分配TCB

    Syn Cookie技术

    Syn Cookie技术则完全不使用任何存储资源,它使用一种特殊的算法生成Sequence Number,这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息,以及对方无法知道而己方比较固定的一些信息,如MSS、时间等,在收到对方 的ACK报文后,重新计算一遍,看其是否与对方回应报文中的(Sequence Number-1)相同,从而决定是否分配TCB资源

    3. 使用SYN Proxy防火墙

    原理:对试图穿越的SYN请求进行验证之后才放行、

    展开全文
  • 建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示:1、TCP连接建立——三次握手几个概念: 【1】seq:序号,占4个字节,范围[0,4284967296],由于TCP是面向字节流的,在一个1个TCP连接中...

    建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示:

    这里写图片描述

    1、TCP连接建立——三次握手

    几个概念: 
    【1】seq:序号,占4个字节,范围[0,4284967296],由于TCP是面向字节流的,在一个1个TCP连接中传送字节流中国的每一个字节都按照顺序编号,此外序号是循环使用的 
    【2】ACK: 仅当ACK=1时确认字段才有效,当ACK=0时确认字段无效,并且TCP规定,在连接建立后所有的传送报文段都必须要把ACK置为1 
    【3】SYN:同步序列号,用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段;若对方同意连接,则响应报文中SYN=1,ACK=1 
    【4】FIN :用来释放一个连接,当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接

    这里写图片描述

    1.1、3次握手过程

    服务端的TCP进程先创建传输控制块TCB,准备接受客户端进程的连接请求,然后服务端进程处于LISTEN状态,等待客户端的连接请求,如有,则作出响应。 
    1、客户端的TCP进程也首先创建传输控制模块TCB,然后向服务端发出连接请求报文段,该报文段首部中的SYN=1,ACK=0,同时选择一个初始序号 seq=i。TCP规定,SYN=1的报文段不能携带数据,但要消耗掉一个序号。这时,TCP客户进程进入SYN—SENT(同步已发送)状态,这是 TCP连接的第一次握手。 
    2、服务端收到客户端发来的请求报文后,如果同意建立连接,则向客户端发送确认。确认报文中的SYN=1,ACK=1,确认号ack=i+1,同时为自己 选择一个初始序号seq=j。同样该报文段也是SYN=1的报文段,不能携带数据,但同样要消耗掉一个序号。这时,TCP服务端进入SYN—RCVD(同 步收到)状态,这是TCP连接的第二次握手。 
    3、TCP客户端进程收到服务端进程的确认后,还要向服务端给出确认。确认报文段的ACK=1,确认号ack=j+1,而自己的序号为seq=i+1。 TCP的标准规定,ACK报文段可以携带数据,但如果不携带数据则不消耗序号,因此,如果不携带数据,则下一个报文段的序号仍为seq=i+1。这 时,TCP连接已经建立,客户端进入ESTABLISHED(已建立连接)状态。这是TCP连接的第三次握手,可以看出第三次握手客户端已经可以发送携带 数据的报文段了。 
    当服务端收到确认后,也进入ESTABLISHED(已建立连接)状态。

    1.2、关于第三次握手的解释

    前俩比较容易理解,第三次握手看似多余其实不然,这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判 
    比如:客户端发送了一个连接请求报文段A到服务端,但是在某些网络节点上长时间滞留了,而后客户端又超时重发了一个连接请求报文段B该服务端,而后 正常建立连接,数据传输完毕,并释放了连接。但是请求报文段A延迟了一段时间后,又到了服务端,这本是一个早已失效的报文段,但是服务端收到后会误以为客户端又发出了一次连接请求,于是向客户端发出确认报文段,并同意建立连接。那么问题来了,假如这里没有三次握手,这时服务端只要发送了确认,新的连接就建立了,但由于客户端没有发出建立连接的请求,因此不会理会服务端的确认,也不会向服务端发送数据,而服务端却认为新的连接已经建立了,并在 一直等待客户端发送数据,这样服务端就会一直等待下去,直到超出保活计数器的设定值,而将客户端判定为出了问题,才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手,客户端就不会向服务端发出确认,服务端由于收不到确认,就知道客户端没有要求建立连接,从而不建立该连接。

    2、 缺陷引起的SYN Flood

    2.1、SYN Flood 攻击

    SYN- Flood攻击是当前网络上最为常见的DDoS攻击,也是最为经典的拒绝服务攻击,它就是利用了TCP协议实现上的一个缺陷,通过向网络服务所在端口发送大量 的伪造源地址的攻击报文,就可能造成目标服务器中的半开连接队列被占满,从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现,但至今仍然显示 出强大的生命力。很多操作系统,甚至防火墙、路由器都无法有效地防御这种攻击,而且由于它可以方便地伪造源地址,追查起来非常困难。它的数据包特征通常 是,源发送了大量的SYN包,并且缺少三次握手的最后一步握手ACK回复。 
    原理:攻击者首先伪造地址对 服务器发起SYN请求,服务器回应(SYN+ACK)包,而真实的IP会认为,我没有发送请求,不作回应。服务 器没有收到回应,这样的话,服务器不知 道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者 如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。

    2.2、SYN Flood 防护措施

    2.2.1. 无效连接监视释放 
    这种方法不停的监视系统中半开连接和不活动连接,当达到一定阈值时拆除这些连接,释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉,”伤敌一千,自损八百“ 
    2.2.2. 延缓TCB分配方法 
    SYN Flood关键是利用了,SYN数据报文一到,系统立即分配TCB资源,从而占用了系统资源,因此有俩种技术来解决这一问题 
    Syn Cache技术 
    这种技术在收到SYN时不急着去分配TCB,而是先回应一个ACK报文,并在一个专用的HASH表中(Cache)中保存这种半开连接,直到收到正确的ACK报文再去分配TCB 
    Syn Cookie技术 
    Syn Cookie技术则完全不使用任何存储资源,它使用一种特殊的算法生成Sequence Number,这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息,以及对方无法知道而己方比较固定的一些信息,如MSS、时间等,在收到对方 的ACK报文后,重新计算一遍,看其是否与对方回应报文中的(Sequence Number-1)相同,从而决定是否分配TCB资源 
    2.2.3. 使用SYN Proxy防火墙 
    原理:对试图穿越的SYN请求进行验证之后才放行

    3、经历状态

    3.1 Client端所经历的状态

    这里写图片描述

    3.2 Server端所经历的状态

    这里写图片描述

    4、常见问题:

    4.1、为什么连接的时候是三次握手,关闭的时候却是四次握手?

    答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

    4.2、为什么存在TIME_WAIT状态?

    答:1、可靠的终止TCP连接

    这里写图片描述

    2、保证让迟来的TCP报文段有足够的时间被识别并丢弃

    这里写图片描述
    这里写图片描述

    4.3、TCP第三次握手失败怎么办?

    在此,将《TCP/IP协议族》中每一个状态的转换伪代码整理下:

    这里写图片描述

    第58行指明了当第三次握手失败时的处理操作,可以看出当失败时服务器并不会重传ack报文,而是直接发送RTS报文段,进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

    4.4、为什么不能用两次握手进行连接

    我们知道,3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。 现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

    5、小知识

    a.默认情况下(不改变socket选项),当你调用close( or closesocket,以下说close不再重复)时,如果发送缓冲中还有数据,TCP会继续把数据发送完。 
    b. 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送),但是还可以接收数据。 
    c. 应用层如何知道对端关闭?通常,在最简单的阻塞模型中,当你调用recv时,如果返回0,则表示对端关闭。在这个时候通常的做法就是也调用close,那么TCP层就发送FIN,继续完成四次握手。如果你不调用close,那么对端就会处于FIN_WAIT_2状态,而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。 
    d. 在很多时候,TCP连接的断开都会由TCP层自动进行,例如你CTRL+C终止你的程序,TCP连接依然会正常关闭,你可以写代码试试

    6、TIME_WAIT状态

    a.从以上TCP连接关闭的状态转换图可以看出,主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后,会进入TIME_WAIT状态。TIME_WAIT状态也称为2MSL状态。

    b.什么是2MSL?MSL即Maximum Segment Lifetime,也就是报文最大生存时间,引用《TCP/IP详解》中的话:“它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么,2MSL也就是这个时间的2倍。其实我觉得没必要把这个MSL的确切含义搞明白,你所需要明白的是,当TCP连接完成四个报文段的交换时,主动关闭的一方将继续等待一定时间(2-4分钟),即使两端的应用程序结束。你可以写代码试试,然后用setstat查看下。

    c.为什么需要2MSL?根据《TCP/IP详解》和《The TCP/IP Guide》中的说法,有两个原因: 
    其一,保证发送的ACK会成功发送到对方,如何保证?我觉得可能是通过超时计时器发送。这个就很难用代码演示了。 
    其二,报文可能会被混淆,意思是说,其他时候的连接可能会被当作本次的连接。直接引用《The TCP/IP Guide》的说法:The second is to provide a“buffering period” between the end of this connection and any subsequent ones. If not for this period, it is possible that packets from different connections could be mixed, creating confusion.

    d.TIME_WAIT状态所带来的影响:

    当某个连接的一端处于TIME_WAIT状态时,该连接将不能再被使用。事实上,对于我们比较有现实意义的是,这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时,这意味着这个TCP连接并没有断开(完全断开),那么,如果你bind这个端口,就会失败。对于服务器而言,如果服务器突然crash掉了,那么它将无法再2MSL内重新启动,因为bind会失败。解决这个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。

    e.特别注意

    当建立一个TCP连接时,服务器端会继续用原有端口监听,同时用这个端口与客户端通信。而客户端默认情况下会使用一个随机端口与服务器端的监听端口通信。有时候,为了服务器端的安全性,我们需要对客户端进行验证,即限定某个IP某个特定端口的客户端。客户端可以使用bind来使用特定的端口。对于服务器端,当设置了SO_REUSEADDR选项时,它可以在2MSL内启动并listen成功。 
    但是对于客户端,当使用bind并设置SO_REUSEADDR时,如果在2MSL内启动,虽然bind会成功,但是在windows平台上connect会失败。而在linux上则不存在这个问题。(我的实验平台:winxp, ubuntu7.10)

    要解决windows平台的这个问题,可以设置SO_LINGER选项。SO_LINGER选项决定调用close时TCP的行为。SO_LINGER涉及到linger结构体,如果设置结构体中l_onoff为非0,l_linger为0,那么调用close时TCP连接会立刻断开,TCP不会将发送缓冲中未发送的数据发送,而是立即发送一个RST报文给对方,这个时候TCP连接就不会进入TIME_WAIT状态。如你所见,这样做虽然解决了问题,但是并不安全。通过以上方式设置SO_LINGER状态,等同于设置SO_DONTLINGER状态。

    断开连接时的意外: 
    这个算不上断开连接时的意外,当TCP连接发生一些物理上的意外情况时,例如网线断开,linux上的TCP实现会依然认为该连接有效,而windows则会在一定时间后返回错误信息。这似乎可以通过设置SO_KEEPALIVE选项来解决,不过不知道这个选项是否对于所有平台都有效。

    7、各种状态解析

    FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是: FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。(主动方)

    FIN_WAIT_2:上面已经详细解释了这种状态,实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外一方告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。(主动方)

    TIME_WAIT: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方)

    CLOSING(比较少见): 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发送FIN报文后,按理来说是应该先收到(或同时收到)对方的 ACK报文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接

    CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是查看你是否还有数据发送给对方,如果没有的话,那么你也就可以close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)

    LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。(被动方)

    CLOSED: 表示连接中断。

    展开全文
  • 三次握手为了防止已失效的连接请求报文突然有传送到了服务器,因而产生错误连接。 现假定出现一个异常情况,客户端发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后...

        三次握手为了防止已失效的连接请求报文突然有传送到了服务器,因而产生错误连接。

        现假定出现一个异常情况,客户端发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后的某一个时间到达服务器。如果不是三次握手,服务器发送确认,新的连接就建立了,由于现在客户端并没有发出建立连接的请求,服务器只能一直等待客户端发送数据。如果采用三次握手,就可以防止以上现象的发生。

        三次握手的缺陷:SYN- Flood攻击是当前网络上最为常见的DDoS攻击,也是最为经典的拒绝服务攻击,它就是利用了TCP协议实现上的一个缺陷,通过向网络服务所在端口发送大量 的伪造源地址的攻击报文,就可能造成目标服务器中的半开连接队列被占满,从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现,但至今仍然显示 出强大的生命力。很多操作系统,甚至防火墙、路由器都无法有效地防御这种攻击,而且由于它可以方便地伪造源地址,追查起来非常困难。它的数据包特征通常 是,源发送了大量的SYN包,并且缺少三次握手的最后一步握手ACK回复。

        原理:攻击者首先伪造地址对 服务器发起SYN请求,服务器回应(SYN+ACK)包,而真实的IP会认为,我没有发送请求,不作回应。服务 器没有收到回应,这样的话,服务器不知 道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者 如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。

    解决方法:

    1. 无效连接监视释放

    这种方法不停的监视系统中半开连接和不活动连接,当达到一定阈值时拆除这些连接,释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉,”伤敌一千,自损八百“

    2. 延缓TCB分配方法

    SYN Flood关键是利用了,SYN数据报文一到,系统立即分配TCB资源,从而占用了系统资源,因此有俩种技术来解决这一问题

    Syn Cache技术

        这种技术在收到SYN时不急着去分配TCB,而是先回应一个ACK报文,并在一个专用的HASH表中(Cache)中保存这种半开连接,直到收到正确的ACK报文再去分配TCB

    Syn Cookie技术

        Syn Cookie技术则完全不使用任何存储资源,它使用一种特殊的算法生成Sequence Number,这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息,以及对方无法知道而己方比较固定的一些信息,如MSS、时间等,在收到对方 的ACK报文后,重新计算一遍,看其是否与对方回应报文中的(Sequence Number-1)相同,从而决定是否分配TCB资源。

    3.使用SYN Proxy防火墙

    原理:对试图穿越的SYN请求进行验证之后才放行、

    转载于:https://my.oschina.net/u/4045381/blog/3097257

    展开全文
  • TCP三次握手和漏洞解决

    千次阅读 2016-04-11 19:40:58
    tcp三次握手 一:TCP建立过程 1.服务器先创建TCB(传输控制块),准备接受客户端的连接请求,然后服务器处于listen状态 2.客户端创建TCB,准备发送请求连接报文段,此时首部的同步位syn=1(syn不携带数据...
    tcp三次握手
    


    一:TCP建立过程



    1.服务器先创建TCB(传输控制块),准备接受客户端的连接请求,然后服务器处于listen状态
    2.客户端创建TCB,准备发送请求连接报文段,此时首部的同步位syn=1(syn不携带数据,所以要消耗一个序列号),选择一个初始序号seq=x,然后这时候,客户端从closed状态->syn-sent(同步已发送)状态。
    3.服务器接收请求报文,同意连接之后,则向客户端发送确认报文,此时确认报文同部位syn=1,ACK=1,
    确认号ack=x+1,但是syn=1,会消耗一个序号,所以要设置seq=y。此时服务器的状态是syn-rcvd(同步已接收)。
    4.客户端接收确认报文,还要向服务器发送确认报文,确认报文ACK=1,确认号为ack=y+1,因为ACK可以携带数据,不需要消耗序号。发送完之后,这时候客户端处于established状态
    5.服务器收到确认报文,这时候也处于了established状态。

    PS:同步位syn=1,不携带数据段,所以需要消耗一个序列号,而ACK可以携带数据段。


    二:为什么客户端最后一次还需要发送一次确认。
    这主要为了防止已失效的连接请求报文段突然传到服务端,因而产生错误。


    三:TCP三次握手的缺陷
        
        1.SYN FLOOD攻击
        SYN-FLOOD是一种常见的DDos攻击,拒绝服务攻击。通过网络服务所在的端口发送大量伪造原地址的攻击报文,发送到服务端,造成服务端上的半开连接队列被占满,从而阻止其他用户进行访问。
        它的数据报特征是大量syn包,并且缺少最后一步的ACK回复。



        原理:攻击者首先伪造地址,对服务器发起syn请求,服务器回应syn+ACK,而真实的IP会认为我没有发送请求,不做回应,而服务端没有收到回应,服务器就不知道是否发送成功,默认情况下重试5次 syn_retries,这样的话,对于服务器内存和带宽有很大的消耗。


        2.解决SYN FLOOD方法
        (1).无效连接监控
        不停监视半开连接和不活动连接,当半开连接数和不活动连接数到达一定值时候,就释放系统资源。
        伤敌1000,自损8000
        (2).延缓TCB方法
        SYN FLOOD的关键是利用了,syn数据报一到,系统就分配TCB资源。
        那么我们有两种方法资源问题
        Syn cache
        这种技术在收到Syn时不急着分配TCB,而是先回应一个ACK报文,并在一个专用的HASH表中保存这种连接,直到收到正确的ACK,才分配TCB。
        (3).Syn Cookie
        用一种特殊的算法生成sequence number,算法考虑到对方的信息和己方信息,收到对方的ACK报文后,验证之后才决定是否生成TCB


    展开全文
  • TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。 同时由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议,TCP是全双工模式,所以需要四次挥手关闭连接。 TCP包首部 ...
  • 1、TCP连接建立——三次握手 (1)第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。 (2)第二次握手:Server收到数据包后由...
  • TCP三次握手详解

    2019-10-01 22:21:11
    three-way handshake)所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步,根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系,并建立虚连接。...
  • 最近一直在恶补计算机网络方面的知识,之前对TCP三次握手和四次挥手还是模糊的,对于其中的细节浑然不知。最近看了很多这方面的知识。也在系统的学习计算机网络,加深自己的网络编程功底。本文将从TCP三次握手...
  • 面试官:讲讲TCP三次握手和四次挥手 某上市公司遇到过,面试高频题。 文章尽量用最简洁的语言方便理解与记忆。 一、三次握手(建立链接) A 代表主动链接方,B 代表被动链接方 1.1 简单点 A->B 你活着吗? B...
  •  在传递数据之前,会有三次握手来建立连接 应用数据被分割成TCP认为最合适的数据库(按字节编号,合理分片),这和UDP完全不同,应用程序产生的数据报长度保持不变。(将数据截断为合理的长度) 当TCP发出一个段...
  • TCP三次握手

    2021-04-21 20:25:34
    TCP三次握手三次握手第一次握手第二次握手第三次握手为什么 TCP 握手需要三次?TCP 的三次握手的漏洞-SYN 洪泛攻击 三次握手 TCP所谓三次握手是指建立一个TCP连接时需要客户端和服务端总共发三个包已确认建立连接。 ...
  • 【引言】 ...当然是从三次握手和四次挥手说起啦,可能大家都知道TCP是三次交互完成连接的建立,四次交互来断开一个连接,那为什么是三次握手和四次挥手呢?反过来不行吗? 疑症一:TCP三次握手、四次
  • TCP三次握手与DDOS攻击原理

    千次阅读 2016-06-20 19:37:29
    TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认; 第二次握手:服务器收到syn包,必须确认...
  • TCP三次握手过程,如果两次握手会怎么样?

    万次阅读 多人点赞 2017-09-06 11:19:14
    可是这个TCP有几个比较讨厌的就是聊天之前要做很多准备工作,有两步(真实的有步,这里是为了体现两次握手缺陷)  第一步: 他要发送一条 建立连接的消息 告诉对方咱两要通信了  第二步: 对方收到这个...
  • TCP三次握手和四次挥手和UDP协议

    千次阅读 2018-10-29 08:48:26
    三次握手 四次挥手 为什么建立连接是三次而断开连接是四次呢? TCP和UDP的区别 TCP数据包的封装 UDP数据包封装 SCTP SYN Flood泛洪攻击 TCP TCP(Transmission Control Protocol) 传输控制协议,是面向连接...
  • TCP三次和四次挥手过程1、TCP报文段首部2、TCP三次握手过程及常见问题2.1 TCP三次握手过程2.2 常见问题2、TCP四次挥手过程及问题2.1 TCP四次挥手过程2.2 常见问题 1、TCP报文段首部     &...
  • 所谓三次握手是指建立一个TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在socket 编程中,这一过程由客户端执行connect 来触发。 第一次握手: 客户端将标志位SYN 置为1,随机产生一个值seq=J,...
  • 三次握手 我们先明确两个定义: 1,client为数据发送方 2,server为数据接收方 好,下面进行三次握手的总结: 1,client想要向server发送数据,请求连接。这时client想服务器发送一个数据包,其中同步位(SYN...
  • TCP中的三次握手

    千次阅读 2016-11-27 22:54:08
    当然是从三次握手和四次挥手说起啦,可能大家都知道TCP是三次交互完成连接的建立,四次交互来断开一个连接,那为什么是三次握手和四次挥手呢?反过来不行吗? 疑症一:TCP三次握手、四次挥手
  • 三次握手 我们先明确两个定义: 1,client为数据发送方 2,server为数据接收方 好,下面进行三次握手的总结: 1,client想要向server发送数据,请求连接。这时client想服务器发送一个数据包,其中同步位(SYN)被置...
  • 在”从TCP三次握手说起–浅析TCP协议中的疑难杂症(1)“文章中,我们提到第6个疑问:TCP的头号疼症TIME_WAIT状态,下面我们继续这个问题的解答。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,243
精华内容 4,897
关键字:

tcp三次握手缺陷