SYN_flood

SYN flood或稱SYN洪水 、 SYN洪泛是一種阻斷服務攻擊 ， 起因於攻擊者傳送一系列的SYN請求到目標系統 。 當用戶端試著與伺服器間建立TCP連線時 ， 正常情況下用戶端與伺服器端交換一系列的信息如下 ： 用戶端透過傳送SYN同步 （ synchronize ） 信息到伺服器要求建立連線 。 伺服器透過響應用戶端SYN - ACK以抄收 （ acknowledge ） 請求 。 用戶端答應ACK ， 連線隨之建立 。 這即是所謂TCP三向交握 ， 並且這是每個使用TCP傳輸協議建立連線的基礎 。 SYN flood是一種廣爲人知的攻擊 ， 一般對現代網路不太有效 。 這種攻擊只有在伺服器在收到SYN後分配資源 ， 但在收到ACK之前這個區段有效 。 SYN flood攻擊目前有兩種方法 ， 不過都與伺服器端沒收到ACK有關 。 惡意用戶可以跳過傳送最後的ACK信息 ； 或者在SYN裏透過欺騙來源IP位址 ， 這讓伺服器送SYN - ACK到假造的IP位址 ， 因此永不可能收到ACK 。 這兩個案例伺服器會花點時間等抄收通知 ， 故一個簡單的網路壅塞可能是由於沒有ACK造成的 。 如果這些綁定伺服器資源 ， 透過海量SYN信息淹沒伺服器是有可能耗盡其資源 。 一旦所有資源都撥給半開通連線所保留 ， 沒有新的連線 （ 不管合法不合法 ） 可被建立 ， 導致阻斷服務攻擊 。 如果系統調用函數需要使用到此類被消耗資源 ， 某些系統可能會出現極爲嚴重的故障 ， 甚至宕機 。 過去 ( 1996年 ) 用來分配資源給半開通連線的技術牽涉到通常相當短的佇列 。 佇列的每個空位可在連線完成 、 或者到期時被清空 。 當佇列滿時 ， 新進來的連線建立會失敗 。 以上面的範例來說 ， 所有新進來的連線在總共8個封包被送出之前會被阻擋下來 。 也就是說 ， 每3分鐘正時算好的8個封包將阻斷所有新進的TCP連線完成 。 這讓這種阻斷服務攻擊只須佔很小的傳輸量 。 建議的反制方法包括SYN cookie或者限定某一段時間內來自同一來源請求新連線的數量 ， 不過因爲現代的TCP / IP堆疊沒有上面所述的瓶頸 ， 因此介於SYN flood與其它種基於通道容量類型的攻擊應該會只有很小或幾乎沒有差別 。 反射路由器亦可以被攻擊者所利用 ， 以取代客戶端機器 。 SYN講的是黑客利用TCP協議發送大量的半連接請求去攻擊目標服務器或者主機 ， 致使目標服務器發生拒絕服務 ， 或者藍屏 。