從TCP協議的原理論rst復位攻擊

在談RST攻擊前，必須先了解TCP：如何透過三次握手建立TCP連線、四次握手怎樣把全雙工的連線關閉掉、滑動視窗是怎麼傳輸資料的、TCP的flag標誌位裡RST在哪些情況下出現。下面我會畫一些儘量簡化的圖來表達清楚上述幾點，之後再瞭解下RST攻擊是怎麼回事。

TCP是在IP網路層之上的傳輸層協議，用於提供port到port面向連線的可靠的位元組流傳輸。我來用土語解釋下上面的幾個關鍵字：

port到port：IP層只管資料包從一個IP到另一個IP的傳輸，IP層之上的TCP層加上埠後，就是面向程式了，每個port都可以對應到使用者程式。

可靠：TCP會負責維護實際上子虛烏有的連線概念，包括收包後的確認包、丟包後的重發等來保證可靠性。由於頻寬和不同機器處理能力的不同，TCP要能控制流量。

位元組流：TCP會把應用程式傳來的位元組流資料切割成許多個資料包，在網路上傳送。IP包是會失去順序或者產生重複的，TCP協議要能還原到位元組流本來面目。

從上面的TCP協議圖可以看到，標誌位共有六個，其中RST位就在TCP異常時出現，也是我這篇文章重點關注的地方。

下面我透過A向B建立TCP連線來說明三次握手怎麼完成的。

為了能夠說清楚下面的RST攻擊，需要結合上圖說說：SYN標誌位、序號、滑動視窗大小。

建立連線的請求中，標誌位SYN都要置為1，在這種請求中會告知MSS段大小，就是本機希望接收TCP包的最大大小。

傳送的資料TCP包都有一個序號。它是這麼得來的：最初傳送SYN時，有一個初始序號，根據RFC的定義，各個作業系統的實現都是與系統時間相關的。之後，序號的值會不斷的增加，比如原來的序號是100，如果這個TCP包的資料有10個位元組，那麼下次的TCP包序號會變成110。

滑動視窗用於加速傳輸，比如發了一個seq=100的包，理應收到這個包的確認ack=101後再繼續發下一個包，但有了滑動視窗，只要新包的seq與沒有得到確認的最小seq之差小於滑動視窗大小，就可以繼續發。

滑動視窗毫無疑問是用來加速資料傳輸的。TCP要保證“可靠”，就需要對一個資料包進行ack確認表示接收端收到。有了滑動視窗，接收端就可以等收到許多包後只發一個ack包，確認之前已經收到過的多個資料包。有了滑動視窗，傳送端在傳送完一個資料包後不用等待它的ack，在滑動視窗大小內可以繼續傳送其他資料包。舉個例子來看吧。

大家看上圖，標誌位為.表示所有的flag都為0。標誌位P表示flag為PSH的TCP包，用於快速傳輸資料。

前三個包是三次握手，客戶端表示自己的滑動視窗大小是65535(我的XP機器)，伺服器端表示滑動視窗是5840(螢幕寬了，沒截出來)。從第四個包開始，客戶端向伺服器傳送PSH包，資料長度是520位元組，伺服器發了ack確認包。注意此時win視窗大小發生了改變哈。以此類推。

倒數第二、三包，伺服器在滑動視窗內連續向客戶端發包，客戶端傳送的ack 124同時確認了之前的兩個包。這就是滑動視窗的功能了。

如果談到TCP攻擊就需要注意，TCP的各種實現中，在滑動視窗之外的seq會被扔掉!下面會講這個問題。

先畫張簡單的正常關閉連線狀態變遷圖。

FIN標誌位也看到了，它用來表示正常關閉連線。圖的左邊是主動關閉連線方，右邊是被動關閉連線方，用netstat 可以看到標出的連線狀態。

FIN是正常關閉，它會根據緩衝區的順序來發的，就是說緩衝區FIN之前的包都發出去後再發FIN包，這與RST不同。

RST表示復位，用來異常的關閉連線，在TCP的設計中它是不可或缺的。就像上面說的一樣，傳送RST包關閉連線時，不必等緩衝區的包都發出去(不像上面的FIN包)，直接就丟棄快取區的包傳送RST包。而接收端收到RST包後，也不必傳送ACK包來確認。

TCP處理程式會在自己認為的異常時刻傳送RST包。例如，A向B發起連線，但B之上並未監聽相應的埠，這時B作業系統上的TCP處理程式會發RST包。

又比如，AB正常建立連線了，正在通訊時，A向B傳送了FIN包要求關連線，B傳送ACK後，網斷了，A透過若干原因放棄了這個連線(例如程式重啟)。網通了後，B又開始發資料包，A收到後表示壓力很大，不知道這野連線哪來的，就發了個RST包強制把連線關了，B收到後會出現connect reset by peer錯誤。

A和伺服器B之間建立了TCP連線，此時C偽造了一個TCP包發給B，使B異常的斷開了與A之間的TCP連線，就是RST攻擊了。實際上從上面RST標誌位的功能已經可以看出這種攻擊如何達到效果了。

那麼偽造什麼樣的TCP包可以達成目的呢?我們至頂向下的看。

假定C偽裝成A發過去的包，這個包如果是RST包的話，毫無疑問，B將會丟棄與A的緩衝區上所有資料，強制關掉連線。

如果發過去的包是SYN包，那麼，B會表示A已經發瘋了(與OS的實現有關)，正常連線時又來建新連線，B主動向A發個RST包，並在自己這端強制關掉連線。

這兩種方式都能夠達到復位攻擊的效果。似乎挺恐怖，然而關鍵是，如何能偽造成A發給B的包呢?這裡有兩個關鍵因素，源埠和序列號。

一個TCP連線都是四元組，由源IP、源埠、目標IP、目標埠唯一確定一個連線。所以，如果C要偽造A發給B的包，要在上面提到的IP頭和TCP頭，把源IP、源埠、目標IP、目標埠都填對。這裡B作為伺服器，IP和埠是公開的，A是我們要下手的目標，IP當然知道，但A的源埠就不清楚了，因為這可能是A隨機生成的。當然，如果能夠對常見的OS如windows和 找出生成source port規律的話，還是可以搞定的。

序列號問題是與滑動視窗對應的，偽造的TCP包裡需要填序列號，如果序列號的值不在A之前向B傳送時B的滑動視窗內，B是會主動丟棄的。所以我們要找到能落到當時的AB間滑動視窗的序列號。這個可以暴力解決，因為一個sequence長度是32位，取值範圍0-4294967296，如果視窗大小像上圖中我抓到的windows下的65535的話，只需要相除，就知道最多隻需要發65537(4294967296/65535=65537)個包就能有一個序列號落到滑動視窗內。RST包是很小的，IP頭+TCP頭也才40位元組，算算我們的頻寬就知道這實在只需要幾秒鐘就能搞定。

那麼，序列號不是問題，源埠會麻煩點，如果各個作業系統不能完全隨機的生成源埠，或者駭客們能透過其他方式獲取到source port，RST攻擊易如反掌，後果很嚴重。

原文地址：