自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

TCP協(xié)議:說(shuō)RST標(biāo)識(shí)位 談RST復(fù)位攻擊

安全 黑客攻防 網(wǎng)絡(luò)管理
RST表示復(fù)位,用來(lái)異常的關(guān)閉連接,在TCP的設(shè)計(jì)中它是不可或缺的。發(fā)送RST包關(guān)閉連接時(shí),不必等緩沖區(qū)的包都發(fā)出去(FIN包),直接就丟棄緩存區(qū)的包發(fā)送RST包。而接收端收到RST包后,也不必發(fā)送ACK包來(lái)確認(rèn)。

1.RST標(biāo)識(shí)位

RST表示復(fù)位,用來(lái)異常的關(guān)閉連接,在TCP的設(shè)計(jì)中它是不可或缺的。發(fā)送RST包關(guān)閉連接時(shí),不必等緩沖區(qū)的包都發(fā)出去(FIN包),直接就丟棄緩存區(qū)的包發(fā)送RST包。而接收端收到RST包后,也不必發(fā)送ACK包來(lái)確認(rèn)。

TCP處理程序會(huì)在自己認(rèn)為的異常時(shí)刻發(fā)送RST包。

2個(gè)例子:

1)A向B發(fā)起連接,但B之上并未監(jiān)聽相應(yīng)的端口,這時(shí)B操作系統(tǒng)上的TCP處理程序會(huì)發(fā)RST包。

2)A和B已經(jīng)正常建立連接,正在通訊時(shí),A向B發(fā)送了FIN包要求關(guān)連接,B發(fā)送ACK后,A網(wǎng)斷了,A通過(guò)若干原因放棄了這個(gè)連接(例如進(jìn)程重啟)。網(wǎng)絡(luò)恢復(fù)之后,B又開始或重發(fā)數(shù)據(jù)包,A不知道這連接哪來(lái)的,就發(fā)了個(gè)RST包強(qiáng)制把連接關(guān)閉,B收到后會(huì)出現(xiàn)connect reset by peer錯(cuò)誤。

2.RST復(fù)位報(bào)文段

TCP在下列三種情況下產(chǎn)生RST復(fù)位報(bào)文段。

1.到不存在的端口的連接請(qǐng)求

產(chǎn)生復(fù)位的一種常見情況是當(dāng)連接請(qǐng)求到達(dá)時(shí),目的端口沒(méi)有進(jìn)程正在監(jiān)聽。對(duì)于UDP,當(dāng)一個(gè)數(shù)據(jù)報(bào)到達(dá)目的端口時(shí),該端口沒(méi)在使用,它將產(chǎn)生一個(gè)ICMP端口不可達(dá)的信息;而TCP則使用復(fù)位。

2.異常終止一個(gè)連接

終止一個(gè)連接的正常方式是一方發(fā)送FIN,這也稱為有序釋放,因?yàn)樵谒信抨?duì)數(shù)據(jù)都已發(fā)送之后才發(fā)送FIN,正常情況下沒(méi)有任何數(shù)據(jù)丟失。但也有可能發(fā)送一個(gè)復(fù)位報(bào)文段而不是FIN來(lái)中途釋放一個(gè)連接,這也稱為異常釋放。異常終止一個(gè)連接對(duì)應(yīng)用程序來(lái)說(shuō)有兩個(gè)優(yōu)點(diǎn):(1)丟棄任何待發(fā)數(shù)據(jù)并立即發(fā)送復(fù)位報(bào)文段;(2)RST的接收方會(huì)區(qū)分另一端執(zhí)行的是異常關(guān)閉還是正常關(guān)閉。

3.檢測(cè)半關(guān)閉連接

如果一方已經(jīng)關(guān)閉或異常終止連接而另一方卻還不知道,我們將這樣的TCP連接稱為半打開的。任何一端的主機(jī)異常都可能導(dǎo)致發(fā)生這種情況。只要不打算在半打開連接上傳輸數(shù)據(jù),仍處于連接狀態(tài)的一方就不會(huì)檢測(cè)另一方已經(jīng)出現(xiàn)異常。下面介紹一種建立半打開連接的情形。在bsdi上運(yùn)行Telnet客戶程序,通過(guò)它和svr4上的丟棄服務(wù)器建立連接。接著斷開服務(wù)器主機(jī)與以太網(wǎng)的電纜,并重啟服務(wù)器主機(jī)。這可以模擬服務(wù)器主機(jī)出現(xiàn)異常(在重啟服務(wù)器之前斷開以太網(wǎng)電纜是為了防止它向打開的連接發(fā)送FIN,某些TCP在關(guān)機(jī)時(shí)會(huì)這么做)。服務(wù)器主機(jī)重啟后,我們重新接上電纜,并從客戶向服務(wù)器發(fā)送一行字符。由于服務(wù)器的TCP已經(jīng)重新啟動(dòng),它將丟失復(fù)位前連接的所有信息,因此它不知道數(shù)據(jù)報(bào)文段中提到的連接。TCP處理的原則是接收方以復(fù)位作為應(yīng)答。

3.RST復(fù)位攻擊

A和服務(wù)器B之間建立了TCP連接,如果此時(shí)C偽造了一個(gè)TCP包發(fā)給B,使B異常的斷開了與A之間的TCP連接,就是RST攻擊。

偽造這樣的TCP包能造成什么后果?

1、假定C偽裝成A發(fā)過(guò)去的包,這個(gè)包如果是RST包,沖區(qū)上所有數(shù)據(jù)B將會(huì)丟棄與A的緩,強(qiáng)制關(guān)掉連接。

2、如果發(fā)過(guò)去的包是SYN包,那么,B會(huì)表示A已經(jīng)是正常連接卻又來(lái)建新連接,B主動(dòng)向A發(fā)個(gè)RST包,并在自己這端強(qiáng)制關(guān)掉連接。

如何偽造成A發(fā)給B的包?

這里有兩個(gè)關(guān)鍵因素,源端口和序列號(hào)。

一個(gè)TCP連接都是四元組,由源IP、源端口、目標(biāo)IP、目標(biāo)端口唯一確定一個(gè)連接。所以,如果C要偽造A發(fā)給B的包,要在上面提到的IP頭和TCP頭,把源IP、源端口、目標(biāo)IP、目標(biāo)端口都填對(duì)。

1)這里B作為服務(wù)器,IP和端口是公開的;

2)A是我們要下手的目標(biāo),IP當(dāng)然知道,但A的源端口就不清楚了,因?yàn)檫@可能是A隨機(jī)生成的。當(dāng)然,如果能夠?qū)ΤR姷腛S如windows和linux找出生成source port規(guī)律的話,還是可以進(jìn)行碰撞。

3)序列號(hào)問(wèn)題是與滑動(dòng)窗口對(duì)應(yīng)的,偽造的TCP包里需要填序列號(hào),如果序列號(hào)的值不在A之前向B發(fā)送時(shí)B的滑動(dòng)窗口內(nèi),B是會(huì)主動(dòng)丟棄的。所以我們要找到能落到當(dāng)時(shí)的AB間滑動(dòng)窗口的序列號(hào)。這個(gè)可以暴力解決,因?yàn)橐粋€(gè)sequence長(zhǎng)度是32位,取值范圍0-4294967296,如果窗口大小像上圖中我抓到的windows下的65535的話,只需要相除,就知道最多只需要發(fā)65537(4294967296/65535=65537)個(gè)包就能有一個(gè)序列號(hào)落到滑動(dòng)窗口內(nèi)。RST包是很小,IP頭+TCP頭才40字節(jié),算算我們的帶寬就知道這實(shí)在只需要幾秒鐘就能搞定。

那么,序列號(hào)不是問(wèn)題,源端口會(huì)麻煩點(diǎn),如果各個(gè)操作系統(tǒng)不能完全隨機(jī)的生成源端口,或者黑客們能通過(guò)其他方式獲取到source port,RST攻擊存在可能。

4.如何預(yù)防

簡(jiǎn)單粗爆的一個(gè)可行方法:可以通過(guò)防火墻簡(jiǎn)單設(shè)置。建議使用防火墻將進(jìn)來(lái)的包帶RST位的包丟棄。

責(zé)任編輯:藍(lán)雨淚 來(lái)源: CSDN博客
相關(guān)推薦

2020-11-10 13:52:19

TCPRST攻擊IP

2010-06-09 15:30:51

2019-09-18 08:53:55

2022-01-14 13:53:03

TCP進(jìn)程窗口

2020-01-06 11:22:06

TCPLinux內(nèi)核

2023-09-02 22:02:58

TCP協(xié)議四次揮手

2023-09-02 21:57:52

網(wǎng)絡(luò)TCP協(xié)議

2010-09-08 16:09:02

2023-02-16 14:19:07

IP地址UDP

2022-10-19 14:08:42

SYNTCP報(bào)文

2010-09-02 15:34:25

DHCP協(xié)議

2010-08-29 21:24:53

DHCP協(xié)議

2009-06-04 10:48:29

2010-06-13 15:16:02

2019-11-24 19:34:04

HTTP長(zhǎng)連接短連接

2010-06-28 09:43:14

AMF協(xié)議

2013-08-01 10:01:02

網(wǎng)絡(luò)協(xié)議TCP協(xié)議UDP協(xié)議

2020-12-03 08:37:38

TCPIPARP協(xié)議

2022-07-20 07:29:55

TCPIP協(xié)議

2019-09-30 09:28:26

LinuxTCPIP
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)