圖二 TCP三次握手

　　如圖二，在第一步中，客戶端向服務(wù)端提出連接請求。這時TCP SYN標(biāo)志置位�？蛻舳烁嬖V服務(wù)端序列號區(qū)域合法，需要檢查。客戶端在TCP報頭的序列號區(qū)中插入自己的ISN。服務(wù)端收到該TCP分段后，在第二步以自己的ISN回應(yīng)(SYN標(biāo)志置位)，同時確認(rèn)收到客戶端的第一個TCP分段(ACK標(biāo)志置位)。在第三步中，客戶端確認(rèn)收到服務(wù)端的ISN(ACK標(biāo)志置位)。到此為止建立完整的TCP連接，開始全雙工模式的數(shù)據(jù)傳輸過程。

　　Syn Flood攻擊者不會完成三次握手

　　　　 圖三 Syn Flood惡意地不完成三次握手

　　假設(shè)一個用戶向服務(wù)器發(fā)送了SYN報文后突然死機或掉線，那么服務(wù)器在發(fā)出SYN+ACK應(yīng)答報文后是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下服務(wù)器端一般會重試（再次發(fā)送SYN+ACK給客戶端）并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數(shù)量級（大約為30秒-2分鐘）；一個用戶出現(xiàn)異常導(dǎo)致服務(wù)器的一個線程等待1分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務(wù)器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數(shù)以萬計的半連接，即使是簡單的保存并遍歷也會消耗非常多的CPU時間和內(nèi)存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務(wù)器的TCP/IP棧不夠強大，最后的結(jié)果往往是堆棧溢出崩潰---即使服務(wù)器端的系統(tǒng)足夠強大，服務(wù)器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，服務(wù)器失去響應(yīng)，這種情況我們稱做：服務(wù)器端受到了SYN Flood攻擊（SYN洪水攻擊）�！　�

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

　　這一個局域網(wǎng)環(huán)境，只有一臺攻擊機（PIII667/128/mandrake），被攻擊的是一臺Solaris 8.0 (spark)的主機，網(wǎng)絡(luò)設(shè)備是Cisco的百兆交換機。這是在攻擊并未進行之前，在Solaris上進行snoop的記錄，snoop與tcpdump等網(wǎng)絡(luò)監(jiān)聽工具一樣，也是一個很好的網(wǎng)絡(luò)抓包與分析的工具。可以看到攻擊之前，目標(biāo)主機上接到的基本上都是一些普通的網(wǎng)絡(luò)包。

…
…
　　　　 ? -> (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
…
… 　　　

　　接著，攻擊機開始發(fā)包，DDoS開始了…，突然間sun主機上的snoop窗口開始飛速地翻屏，顯示出接到數(shù)量巨大的Syn請求。這時的屏幕就好象是時速300公里的列車上的一扇車窗。這是在Syn Flood攻擊時的snoop輸出結(jié)果：
　　 …
…
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
… …