TCP三向交握應用及原理

來源:互聯網
上載者:User
TCP/IP是很多的不同的協議組成,實際上是一個協議組,TCP使用者資料報表協議(也稱作TCP傳輸控制通訊協定,Transport Control Protocol。可靠的主機到主機層協議。這裡要先強調一下,傳輸控制通訊協定是OSI網路的第四層的叫法,TCP傳輸控制通訊協定是TCP/IP傳輸的6個基本協議的一種。兩個TCP意思非相同。 )。TCP是一種可靠的連線導向的傳送服務。它在傳送資料時是分段進行的,主機交換資料必須建立一個會話。它用位元流通訊,即資料被作為無結構的位元組流。 通過每個TCP傳輸的欄位指定順序號,以獲得可靠性。是在OSI參考模型中的第四層,TCP是使用IP的網間互聯功能而提供可靠的資料轉送,IP不停的把報文放到 網路上,而TCP是負責確信報文到達。在協同IP的操作中TCP負責:握手過程、報文管理、流量控制、錯誤偵測和處理(控制),可以根據一定的編號順序對非正常順序的報文給予從新排列順序。關於TCP的RFC文檔有RFC793、RFC791、RFC1700。

在TCP會話初期,有所謂的“三握手”:對每次發送的資料量是怎樣跟蹤進行協商使資料區段的發送和接收同步,根據所接收到的資料量而確定的資料確認數及資料發送、接收完畢後何時撤消聯絡,並建立虛串連。為了提供可靠的傳送,TCP在發送新的資料之前,以特定的順序將資料包的序號,並需要這些包傳送給目標機之後的確認訊息。TCP總是用來發送大批量的資料。當應用程式在收到資料後要做出確認時也要用到TCP。由於TCP需要時刻跟蹤,這需要額外開銷,使得TCP的格式有些顯得複雜。下面就讓我們看一個TCP的經典案例,這是後來被稱為MITNICK攻擊中KEVIN開創了兩種攻擊技術:

TCP工作階段劫持
SYN FLOOD(同步洪流)

在這裡我們討論的時TCP工作階段劫持的問題。

先讓我們明白TCP建立串連的基本簡單的過程。為了建設一個小型的模仿環境我們假設有3台接入互連網的機器。A為攻擊者操縱的攻擊機。B為中介跳板機器(受信任的伺服器)。C為受害者使用的機器(多是伺服器),這裡把C機器鎖定為目標機器。A機器向B機器發送SYN包,請求建立串連,這時已經響應請求的B機器會向A機器回應SYN/ACK表明同意建立串連,當A機器接受到B機器發送的SYN/ACK回應時,發送應答ACK建立A機器與B機器的網路連接。這樣一個兩台機器之間的TCP通話頻道就建立成功了。

B終端受信任的伺服器向C機器發起TCP串連,A機器對伺服器發起SYN資訊,使C機器不能響應B機器。在同時A機器也向B機器發送虛假的C機器回應的SYN資料包,接收到SYN資料包的B機器(被C機器信任)開始發送應答串連建立的SYN/ACK資料包,這時C機器正在忙於響應以前發送的SYN資料而無暇回應B機器,而A機器的攻擊者預測出B機器包的序號(現在的TCP序號預測難度有所加大)假冒C機器向B機器發送應答ACK這時攻擊者騙取B機器的信任,假冒C機器與B機器建立起TCP協議的對話串連。這個時候的C機器還是在響應攻擊者A機器發送的SYN資料。

TCP協議棧的弱點:TCP串連的資源消耗,其中包括:資料包資訊、條件狀態、序號等。通過故意不完成建立串連所需要的三向交握過程,造成串連一方的資源耗盡。

通過攻擊者有意的不完成建立串連所需要的三向交握的全過程,從而造成了C機器的資源耗盡。序號的可預測性,目標主機應答串連請求時返回的SYN/ACK的序號時可預測的。(早期TCP協議棧,具體的可以參見1981年出的關於TCP雛形的RFC793文檔)


TCP頭結構

TCP協議頭最少20個位元組,包括以下的地區(由於翻譯不禁相同,文章中給出相應的英文單詞):

TCP源連接埠(Source Port):16位的源連接埠其中包含初始化通訊的連接埠。源連接埠和源IP地址的作用是標示報問的返回地址。

TCP目的連接埠(Destination port):16位的目的連接埠域定義傳輸的目的。這個連接埠指明報文接收電腦上的應用程式地址介面。

TCP序號(序列碼,Sequence Number):32位的序號由接收端電腦使用,重新分段的報文成最初形式。當SYN出現,序列碼實際上是初始序列碼(ISN),而第一個資料位元組是ISN+1。這個序號(序列碼)是可以補償傳輸中的 不一致。

TCP應答號(Acknowledgment Number):32位的序號由接收端電腦使用,重組分段的報文成最初形式。,如果設定了ACK控制位,這個值表示一個準備接收的包的序列碼。

資料位移量(HLEN):4位包括TCP頭大小,指示何處資料開始。

保留(Reserved):6位範圍,這些位必須是0。為了將來定義新的用途所保留。

標誌(Code Bits):6位標誌域。表示為:緊急標誌、有意義的應答標誌、推、重設串連標誌、同步序號標誌、完成發送資料標誌。按照順序排列是:URG、ACK、PSH、RST、SYN、FIN。

視窗(Window):16位,用來表示想收到的每個TCP資料區段的大小。

校正位(Checksum):16位TCP頭。源機器基於資料內容計算一個數值,收資訊機要與源機器數值 結果完全一樣,從而證明資料的有效性。

優先指標(緊急,Urgent Pointer):16位,指向後面是優先資料的位元組,在URG標誌設定了時才有效。如果URG標誌沒有被設定,緊急域作為填充。加快處理標示為緊急的資料區段。

選項(Option):長度不定,但長度必須以位元組。如果 沒有 選項就表示這個一位元組的域等於0。

填充:不定長,填充的內容必須為0,它是為了數學目的而存在。目的是確保空間的可預測性。保證包頭的結合和資料的開始處位移量能夠被32整除,一般額外的零以保證TCP頭是32位的整數倍。


標誌控制功能

URG:緊急標誌
緊急(The urgent pointer) 標誌有效。緊急標誌置位,

ACK:確認標誌
確認編號(Acknowledgement Number)欄有效。大多數情況下該標誌位是置位的。TCP前序內的確認編號欄內包含的確認編號(w+1,Figure:1)為下一個預期的序列編號,同時提示遠端系統已經成功接收所有資料。

  PSH:推標誌
該標誌置位時,接收端不將該資料進行隊列處理,而是儘可能快將資料轉由應用處理。在處理 telnet 或 rlogin 等互動模式的串連時,該標誌總是置位的。

RST:複位標誌
  複位標誌有效。用於複位相應的TCP串連。

SYN:同步標誌
同步序列編號(Synchronize Sequence Numbers)欄有效。該標誌僅在三向交握建立TCP串連時有效。它提示TCP已連線的服務端檢查序列編號,該序列編號為TCP串連初始端(一般是用戶端)的初始序列編號。在這裡,可以把TCP序列編號看作是一個範圍從0到4,294,967,295的32位計數器。通過TCP串連交換的資料中每一個位元組都經過序列編號。在TCP前序中的序列編號欄包括了TCP分段中第一個位元組的序列編號。

  FIN:結束標誌
  帶有該標誌置位的資料包用來結束一個TCP回話,但對應連接埠仍處於開放狀態,準備接收後續資料。

服務端處於監聽狀態,用戶端用於建立串連請求的資料包(IP packet)按照TCP/IP協議堆棧組合成為TCP處理的分段(segment)。

  
分析前序資訊: TCP層接收到相應的TCP和IP前序,將這些資訊儲存到記憶體中。

  檢查TCP校正和(checksum):標準的校正和位於分段之中(Figure:2)。如果檢驗失敗,不返回確認,該分段丟棄,並等待用戶端進行重傳。

  尋找協議控制塊(PCB{}):TCP尋找與該串連相關聯的協議控制塊。如果沒有找到,TCP將該分段丟棄並返回RST。(這就是TCP處理沒有連接埠監聽情況下的機制) 如果該協議控制塊存在,但狀態為關閉,服務端不調用connect()或listen()。該分段丟棄,但不返回RST。用戶端會嘗試重建立立串連請求。

  建立新的socket:當處於監聽狀態的socket收到該分段時,會建立一個子socket,同時還有socket{},tcpcb{}和pub{}建立。這時如果有錯誤發生,會通過標誌位來拆除相應的socket和釋放記憶體,TCP串連失敗。如果緩衝隊列處於填滿狀態,TCP認為有錯誤發生,所有的後續串連請求會被拒絕。這裡可以看出SYN Flood攻擊是如何起作用的。

  丟棄:如果該分段中的標誌為RST或ACK,或者沒有SYN標誌,則該分段丟棄。並釋放相應的記憶體。


發送序列變數

SND.UNA : 發送未確認

SND.NXT : 發送下一個

SND.WND : 發送視窗

SND.UP : 發送優先指標

SND.WL1 : 用於最後視窗更新的段序號

SND.WL2 : 用於最後視窗更新的段確認號

ISS : 初始發送序號

 


接收序號

RCV.NXT : 接收下一個

RCV.WND : 接收下一個

RCV.UP : 接收優先指標

IRS : 初始接收序號


當前段變數

SEG.SEQ : 段序號

SEG.ACK : 段確認標記

SEG.LEN : 段長

SEG.WND : 段視窗

SEG.UP : 段緊急指標

SEG.PRC : 段優先順序


CLOSED表示沒有串連,各個狀態的意義如下:

LISTEN : 監聽來自遠方TCP連接埠的串連請求。

SYN-SENT : 在發送串連請求後等待匹配的串連請求。

SYN-RECEIVED : 在收到和發送一個串連請求後等待對串連請求的確認。

ESTABLISHED : 代表一個開啟的串連,資料可以傳送給使用者。

FIN-WAIT-1 : 等待遠程TCP的串連插斷要求,或先前的串連插斷要求的確認。

FIN-WAIT-2 : 從遠程TCP等待串連插斷要求。

CLOSE-WAIT : 等待從本機使用者發來的串連插斷要求。

CLOSING : 等待遠程TCP對串連中斷的確認。

LAST-ACK : 等待原來發向遠程TCP的串連插斷要求的確認。

TIME-WAIT : 等待足夠的時間以確保遠程TCP接收到串連插斷要求的確認。

CLOSED : 沒有任何串連狀態。

TCP串連過程是狀態的轉換,促使發生狀態轉換的是使用者調用:OPEN,SEND,RECEIVE,CLOSE,ABORT和STATUS。傳送過來的資料區段,特別那些包括以下標記的資料區段SYN,ACK,RST和FIN。還有逾時,上面所說的都會時TCP狀態發生變化。


序號

請注意,我們在TCP串連中發送的位元組都有一個序號。因為編了號,所以可以確認它們的收到。對序號的確認是累積性的。TCP必須進行的序號比較操作種類包括以下幾種:

①決定一些發送了的但未確認的序號。

②決定所有的序號都已經收到了。

③決定下一個段中應該包括的序號。


對於發送的資料TCP要接收確認,確認時必須進行的:

SND.UNA = 最老的確認了的序號。

SND.NXT = 下一個要發送的序號。

SEG.ACK = 接收TCP的確認,接收TCP期待的下一個序號。

SEG.SEQ = 一個資料區段的第一個序號。

SEG.LEN = 資料區段中包括的位元組數。

SEG.SEQ+SEG.LEN-1 = 資料區段的最後一個序號。

如果一個資料區段的序號小於等於確認號的值,那麼整個資料區段就被確認了。而在接收資料時下面的比較操作是必須的:

RCV.NXT = 期待的序號和接收視窗的最低沿。

RCV.NXT+RCV.WND:1 = 最後一個序號和接收視窗的最高沿。

SEG.SEQ = 接收到的第一個序號。

SEG.SEQ+SEG.LEN:1 = 接收到的最後一個序號

相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

11.11 Big Sale for Cloud

Get Unbeatable Offers with up to 90% Off,Oct.24-Nov.13 (UTC+8)

Get It Now >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。