老到的攻擊者一邊攻擊，還會用各種手段來監視攻擊的效果，在需要的時候進行一些調整。簡單些就是開個窗口不斷地ping目標主機，在能接到回應的時候就再加大一些流量或是再命令更多的傀儡機來加入攻擊。
DDoS攻擊實例-SYNFlood攻擊
SYN-Flood是目前最流行的DDoS攻擊手段，早先的DoS的手段在向分布式這一階段發展的時候也經曆了浪裏淘沙的過程。SYN-Flood的攻擊效果最好，應該是眾黑客不約而同選擇它的原因吧。那麼我們一起來看看SYN-Flood的詳細情況。
SynFlood原理-三次握手
SynFlood利用了TCP/IP協議的固有漏洞。麵向連接的TCP三次握手是SynFlood存在的基礎。
TCP連接的三次握手
圖二TCP三次握手
如圖二，在第一步中，客戶端向服務端提出連接請求。這時TCPSYN標誌置位。客戶端告訴服務端序列號區域合法，需要檢查。客戶端在TCP報頭的序列號區中插入自己的ISN。服務端收到該TCP分段後，在第二步以自己的ISN回應(SYN標誌置位)，同時確認收到客戶端的第一個TCP分段(ACK標誌置位)。在第三步中，客戶端確認收到服務端的ISN(ACK標誌置位)。到此為止建立完整的TCP連接，開始全雙工模式的數據傳輸過程。
SynFlood攻擊者不會完成三次握手
圖三SynFlood惡意地不完成三次握手
假設一個用戶向服務器發送了SYN報文後突然死機或掉線，那麼服務器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下服務器端一般會重試（再次發送SYN+ACK給客戶端）並等待一段時間後丟棄這個未完成的連接，這段時間的長度我們稱為SYNTimeout，一般來說這個時間是分鍾的數量級（大約為30秒-2分鍾）；一個用戶出現異常導致服務器的一個線程等待1分鍾並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接，即使是簡單的保存並遍曆也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務器的TCP/IP棧不夠強大，最後的結果往往是堆棧溢出崩潰---即使服務器端的係統足夠強大，服務器端也將忙於處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱做：服務器端受到了SYNFlood攻擊（SYN洪水攻擊）。
下麵是我在實驗室中模擬的一次SynFlood攻擊的實際過程
這一個局域網環境，隻有一台攻擊機（PIII667/128/mandrake），被攻擊的是一台Solaris8.0(spark)的主機，網絡設備是Cisco的百兆交換機。這是在攻擊並未進行之前，在Solaris上進行snoop的記錄，snoop與tcpdump等網絡監聽工具一樣，也是一個很好的網絡抓包與分析的工具。可以看到攻擊之前，目標主機上接到的基本上都是一些普通的網絡包。
...
...
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
?->(multicast)ETHERType=0000(LLC/802.3),size=52bytes
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
192.168.0.66->192.168.0.255NBTDatagramServiceType=17Source=GU[0]
192.168.0.210->192.168.0.255NBTDatagramServiceType=17Source=ROOTDC[20]
192.168.0.247->192.168.0.255NBTDatagramServiceType=17Source=TSC[0]
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
192.168.0.200->(broadcast)ARPCWhois192.168.0.102,192.168.0.102?
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
192.168.0.66->192.168.0.255NBTDatagramServiceType=17Source=GU[0]
192.168.0.66->192.168.0.255NBTDatagramServiceType=17Source=GU[0]
192.168.0.210->192.168.0.255NBTDatagramServiceType=17Source=ROOTDC[20]
?->(multicast)ETHERType=0000(LLC/802.3),size=52bytes
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
?->(broadcast)ETHERType=886F(Unknown),size=1510bytes
...
...
接著，攻擊機開始發包，DDoS開始了...，突然間sun主機上的snoop窗口開始飛速地翻屏，顯示出接到數量巨大的Syn請求。這時的屏幕就好象是時速300公裏的列車上的一扇車窗。這是在SynFlood攻擊時的snoop輸出結果：
...
...
127.0.0.178->lab183.lab.netAUTHCport=1352
127.0.0.178->lab183.lab.netTCPD=114S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netTCPD=115S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netUUCP-PATHCport=1352
127.0.0.178->lab183.lab.netTCPD=118S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netNNTPCport=1352
127.0.0.178->lab183.lab.netTCPD=121S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netTCPD=122S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netTCPD=124S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netTCPD=125S=1352SynSeq=674711609Len=0Win=65535
127.0.0.178->lab183.lab.netTCPD=126S=1352SynSeq=674711609Len=0Win=65535