TCP三向交握及其背後的缺陷

標籤：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 Flood2.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三向交握及其背後的缺陷