對DDoS攻擊執行個體之SYN Flood攻擊的詳細內容講述

來源:互聯網
上載者:User

 此文章主要介紹的是DDoS攻擊執行個體  SYN Flood攻擊,我們大家都知道SYN-Flood是目前使用最廣泛的DDoS攻擊手段,早先的DoS的手段在向分布式這一階段發展的時候也經曆了千軍萬馬過獨木橋的過程。

SYN-Flood的攻擊效果最好,應該是眾駭客不約而同選擇它的原因吧。那麼我們一起來看看SYN-Flood的詳細情況。

SYN-Flood是目前最流行的DDoS攻擊手段,早先的DoS的手段在向分布式這一階段發展的時候也經曆了浪裡淘沙的過程。SYN-Flood的攻擊效果最好,應該是眾駭客不約而同選擇它的原因吧。那麼我們一起來看看SYN-Flood的詳細情況。

 

Syn Flood原理 - 三向交握

Syn Flood利用了TCP/IP協議的固有漏洞。連線導向的TCP三向交握是Syn Flood存在的基礎。

TCP串連的三向交握

如圖二,在第一步中,用戶端向服務端提出串連請求。這時TCP SYN標誌置位。用戶端告訴服務端序號地區合法,需要檢查。用戶端在TCP前序的序號區中插入自己的ISN。服務端收到該TCP分段後,在第二步以自己的ISN回應(SYN標誌置位),同時確認收到用戶端的第一個TCP分段(ACK標誌置位)。在第三步中,用戶端確認收到服務端的ISN(ACK標誌置位)。到此為止建立完整的TCP串連,開始全雙工系統模式的資料轉送過程。

Syn Flood攻擊者不會完成三向交握

假設一個使用者向伺服器發送了SYN報文後突然死機或掉線,那麼伺服器在發出SYN+ACK應答報文後是無法收到用戶端的ACK報文的(第三向交握無法完成),這種情況下伺服器端一般會重試(再次發送SYN+ACK給用戶端)並等待一段時間後丟棄這個未完成的串連,這段時間的長度我們稱為SYN Timeout,一般來說這個時間是分鐘的數量級(大約為30秒-2分鐘);

一個使用者出現異常導致伺服器的一個線程等待1分鐘並不是什麼很大的問題,但如果有一個惡意的攻擊者大量類比這種情況,伺服器端將為了維護一個非常大的半串連列表而消耗非常多的資源----數以萬計的半串連,即使是簡單的儲存並遍曆也會消耗非常多的CPU時間和記憶體,何況還要不斷對這個列表中的IP進行SYN+ACK的重試。

實際上如果伺服器的TCP/IP棧不夠強大,最後的結果往往是堆疊溢位崩潰---即使伺服器端的系統足夠強大,伺服器端也將忙於處理攻擊者偽造的TCP串連請求而無暇理睬客戶的正常請求(畢竟用戶端的正常請求比率非常之小),此時從正常客戶的角度看來,伺服器失去響應,這種情況我們稱做:伺服器端受到了SYN Flood攻擊(SYN洪水攻擊)。

下面是我在實驗室中類比的一次Syn Flood攻擊的實際過程

這一個區域網路環境,只有一台攻擊機(PIII667/128/mandrake),被攻擊的是一台Solaris 8.0 (spark)的主機,網路裝置是Cisco的百兆交換器。這是在攻擊並未進行之前,在Solaris上進行snoop的記錄,snoop與tcpdump等網路監聽工具一樣,也是一個很好的網路抓包與分析的工具。可以看到攻擊之前,目標主機上接到的基本上都是一些普通的網路包。 …

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.200 -> (broadcast) ARP C Who is 192.168.0.102, 192.168.0.102 ?

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes

接著,攻擊機開始發包,DDoS開始了…,突然間sun主機上的snoop視窗開始飛速地翻屏,顯示出接到數量巨大的Syn請求。這時的螢幕就好象是時速300公裡的列車上的一扇車窗。這是在Syn Flood攻擊時的snoop輸出結果: …

 

127.0.0.178 -> lab183.lab.net AUTH C port=1352

127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352

127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net NNTP C port=1352

127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535

127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535

這時候內容完全不同了,再也收不到剛才那些正常的網路包,只有DDoS包。大家注意一下,這裡所有的Syn Flood攻擊包的源地址都是偽造的,給追查工作帶來很大困難。這時在被攻擊主機上積累了多少Syn的半串連呢?我們用netstat來看一下:

# netstat -an | grep SYN

192.168.0.183.9 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.13 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.19 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.21 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.22 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.23 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.25 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.37 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

192.168.0.183.53 127.0.0.79.1801 0 0 24656 0 SYN_RCVD

其中SYN_RCVD表示當前未完成的TCP SYN隊列,統計一下:

# netstat -an | grep SYN | wc -l

5273

# netstat -an | grep SYN | wc -l

5154

# netstat -an | grep SYN | wc -l

5267

…..

共有五千多個Syn的半串連儲存在記憶體中。這時候被攻擊機已經不能響應新的服務要求了,系統運行非常慢,也無法ping通。

上述的相關內容就是對對DDoS攻擊執行個體之SYN Flood攻擊的詳細內容講述的描述,希望會給你帶來一些協助在此方面。

文章轉自 ddos教程 http://www.blddos.com/gonggao/2012/1016/9.html

 

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。