常見的DoS***的原理和防禦
1、SYN洪水***
要理解dos***，首先要理解TCP連接的三次握手過程(Three-wayhandshake)。
在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。
第一次握手:建立連接時，客戶端發送SYN包((SYN=i)到服務器，並進入SYN SEND狀態，等待服務器確認;
第二次握手:服務器收到SYN包，必須確認客戶的SYN (ACK=i+1 )，同時自己也發送一個SYN包((SYN=j)}即SYN+ACK包，此時服務器進入SYN_RECV狀態;[1]
第三次握手:客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ACK=j+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手，客戶端與服務器開始傳送數據。
在上述過程中，還有一些重要的概念:[1]
半連接: 收到SYN包而還未收到ACK包時的連接狀態稱爲半連接，即尚未完全完成三次握手的TCP連接。
半連接隊列: 在三次握手協議中，服務器維護一個半連接隊列，該隊列爲每個客戶端的SYN包(SYN=i )開設一個條目，該條目表明服務器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在服務器處於SYN_ RECV狀態，當服務器收到客戶的確認包時，刪除該條目，服務器進入ESTABLISHED狀態。
Backlog參數: 表示半連接隊列的最大容納數目。
SYN-ACK重傳次數: 服務器發送完SYN-ACK包，如果未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息、從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同。
半連接存活時間: 是指半連接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時也稱半連接存活時間爲Timeout時間、SYN_RECV存活時間。
上面三個參數對系統的TCP連接狀況有很大影響。
SYN洪水***屬於DoS***的一種，它利用TCP協議缺陷，通過發送大量的半連接請求，耗費CPU和內存資源。SYN***除了能影響主機外，還可以危害路由器、防火牆等網絡系統，事實上SYN***並不管目標是什麼系統，只要這些系統打開TCP服務就可以實施。從圖4-3可看到，服務器接收到連接請求(SYN=i )將此信息加入未連接隊列，併發送請求包給客戶端( SYN=j,ACK=i+1 )，此時進入SYN_RECV狀態。當服務器未收到客戶端的確認包時，重發請求包，一直到超時，纔將此條目從未連接隊列刪除。配合IP欺騙，SYN***能達到很好的效果，通常，客戶端在短時間內僞造大量不存在的IP地址，向服務器不斷地發送SYN包，服務器回覆確認包，並等待客戶的確認，由於源地址是不存在的，服務器需要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，正常的SYN 請求被丟棄，目標系統運行緩慢，嚴重者引起網絡堵塞甚至系統癱瘓。過程如下:[1]
***主機C(地址僞裝後爲C')-----大量SYN包---->被***主機
C'<-------SYN/ACK包----被***主機
由於C’地址不可達，被***主機等待SYN包超時。***主機通過發大量SYN包填滿未連接隊列，導致正常SYN包被拒絕服務。另外，SYN洪水***還可以通過發大量ACK包進行DoS***。
【防禦方法】
第一種是縮短SYN Timeout時間
第二種方法是設置SYN Cookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續受到某個IP的重複SYN報文，就認定是受到了***，以後從這個IP地址來的包會被一概丟棄。
>netstat -n -p tcp >result.txt
【SYN Cookie】
當服務器收到一個SYN報文後，不立即分配緩衝區，而是利用連接的信息生成一個cookie，並將這個cookie作爲將要返回的SYN＋ACK報文的初始序列號。
當客戶端返回一個ACK報文時，根據包頭信息計算cookie，與返回的確認序列號（初始的序列號＋1）的前24位進行對比，如果相同，則是一個正常連接，然後，分配資源，建立連接。
【缺陷】
SYN Cookies 的使用不與任何協議定義衝突，照理來說它該和所有的 TCP 實現兼容。然而，當 SYN Cookies 使用的時候，會發生兩種值得注意的變化：
首先，服務器只能編碼八種 MSS 數值，因爲只有 3 位二進制空間可用。
其次，這個服務器必須拒絕所有的TCP 選用項，例如大型窗口和時間戳，因爲服務器會在信息被用其他方式存儲時丟棄 SYN 隊列條目。
儘管這些限制將不可避免地導致一個不如最佳的體驗，它們的效果很少被客戶端注意到——這些改變只在被***時值得注意。在這樣的情況下，犧牲 TCP 選項來保護連接一般被認爲是合乎情理的。
Linux內核從 2.6.26 版本開始爲 TCP 選用項加入了有限的支持，通過把它們編碼在時間戳內實現。
較新的TCP Cookie 傳輸（TCPCT）標準被設計用來克服 SYN Cookies 的這些問題，並且在各種方面改進這套機制。不像 SYN Cookies，TCPCT 是一個 TCP 拓展並且要求兩端點都支持 TCPCT。
2、ACK Flood***
在TCP連接建立之後，所有的數據傳輸TCP報文都是帶有ACK標誌位的，主機在接收到一個帶有ACK標誌位的數據包的時候，需要檢查該數據包所表示的連接四元組是否存在，如果存在則檢查該數據包所表示的狀態是否合法，然後再向應用層傳遞該數據包。如果在檢查中發現該數據包不合法，例如該數據包所指向的目的端口在本機並未開放，則主機操作系統協議棧會迴應RST包告訴對方此端口不存在。通常狀態檢測防火牆所做的事情與此類似，只不過防火牆只攔截非法的數據包，而不主動迴應。
對比主機以及防火牆在接收到ACK報文和SYN報文時所做動作的複雜程度，顯然ACK報文帶來的負載要小得多。所以在實際環境中，只有當***程序每秒鐘發送ACK報文的速率達到一定的程度，才能使主機和防火牆的負載有大的變化。當發包速率很大的時候，主機操作系統將耗費大量的精力接收報文、判斷狀態，同時要主動迴應RST報文，正常的數據包就可能無法得到及時的處理。這時候客戶端（以IE爲例）的表現就是訪問頁面反應很慢，丟包率較高。但是狀態檢測的防火牆通過判斷ACK報文的狀態是否合法，藉助其強大的硬件能力可以較爲有效的過濾***報文。當然如果***流量非常大（特別是千兆線路上，我們曾經觀察到200~300Mbps左右的ACK Flood），由於需要維護很大的連接狀態表同時要檢查數量巨大的ACK報文的狀態，防火牆也會不堪重負導致全網癱瘓。
3、死亡之ping (pingofdeath)
ICMP(InternetControlMessageProtocol，Internet控制信息協議)在Internet上用於錯誤處理和傳遞控制信息。最普通的ping程序就是這個功能。而在TCP/IP的RFC文檔中對包的最大尺寸都有嚴格限制規定，許多操作系統的TCP/IP協議棧都規定ICMP包大小爲64KB，且在對包的標題頭進行讀取之後，要根據該標題頭裏包含的信息來爲有效載荷生成緩衝區。"PingofDeath"就是故意產生畸形的測試Ping（PacketInternetGroper）包，聲稱自己的尺寸超過ICMP上限，也就是加載的尺寸超過64KB上限，使未採取保護措施的網絡系統出現內存分配錯誤，導致TCP/IP協議棧崩潰，最終接收方宕機。
【防禦方法】
1、用高級設置法預防Ping
2、用網絡防火牆阻隔Ping
使用防火牆來阻隔Ping是最簡單有效的方法，現在基本上所有的防火牆在默認情況下都啓用了ICMP過濾的功能。
3、啓用IP安全策略防Ping
4、修改TTL值防Ping
許多***者喜歡用TTL值來判斷操作系統，他們首先會Ping一下你的機子，如看到TTL值爲128就認爲你的系統爲Windows NT/2000，如果TTL值爲32則認爲目標主機操作系統爲Windows 95/98，
如果爲TTL值爲255/64就認爲是UNIX/Linux操作系統。既然***者相信TTL值所反應出來的結果，那麼我們不妨修改TTL值來欺騙***者，達到保護系統的目的
5、防火牆在處理Ping of Death***報文時，是通過判定數據包的大小是否大於65535字節，如果數據包大於65535字節，則判定爲***報文，直接丟棄。
4、UDP泛洪
UDPflood***：如今在Internet上UDP（用戶數據包協議）的應用比較廣泛，很多提供WWW和Mail等服務設備通常是使用Unix的服務器，它們默認打開一些被***惡意利用的UDP服務。如echo服務會顯示接收到的每一個數據包，而原本作爲測試功能的chargen服務會在收到每一個數據包時隨機反饋一些字符。UDPflood假冒***就是利用這兩個簡單的TCP/IP服務的漏洞進行惡意***，通過僞造與某一主機的Chargen服務之間的一次的UDP連接，回覆地址指向開着Echo服務的一臺主機，通過將Chargen
和Echo服務互指，來回傳送毫無用處且佔滿帶寬的垃圾數據，在兩臺主機之間生成足夠多的無用數據流，這一拒絕服務***飛快地導致網絡可用帶寬耗盡。
【防禦方法】
UDP協議與TCP 協議不同，是無連接狀態的協議，並且UDP應用協議五花八門，差異極大，因此針對UDP Flood的防護非常困難。其防護要根據具體情況對待：
判斷包大小，如果是大包***則使用防止UDP碎片方法：根據***包大小設定包碎片重組大小，通常不小於1500.在極端情況下，可以考慮丟棄所有UDP碎片。
***端口爲業務端口：根據該業務UDP最大包長設置UDP最大包大小以過濾異常流量。
***端口爲非業務端口：一個是丟棄所有UDP包，可能會誤傷正常業務;一個是建立UDP連接規則，要求所有去往該端口的UDP包，必須首先與TCP端口建立TCP連接。不過這種方法需要很專業的防火牆或其他防護設備支持。
5、Land（LandAttack）***
在Land***中，***利用一個特別打造的SYN包--它的原地址和目標地址都被設置成某一個服務器地址進行***。此舉將導致接受服務器向它自己的地址發送SYN-ACK消息， 結果這個地址又發回ACK消息並創建一個空連接，每一個這樣的連接都將保留直到超時，在Land***下，許多UNIX將崩潰，NT變得極其緩慢（大約持續五分鐘）。
【防禦方法】
防火牆在處理Land***報文時，通過檢查TCP報文的源地址和目的地址是否相同，或者TCP報文的源地址是否爲環回地址，如果是則丟棄。
6、淚滴***
對於一些大的IP數據包，往往需要對其進行拆分傳送，這是爲了迎合鏈路層的MTU（最大傳輸單元）的要求。比如，一個6 000字節的IP包，在MTU爲2 000的鏈路上傳輸的時候，就需要分成3個IP 包。在IP報頭中有一個偏移字段和一個拆分標誌（MF）。如果MF標誌設置爲1，則表示這個IP包是一個大IP包的片段，其中偏移字段指出了這個片段在整個IP包中的位置。例如，對一個6 000字 節的IP包進行拆分（MTU爲2 000），則3個片段中偏移字段的值依次爲0，2 000，4 000。這樣接收端在全部接收完IP數據包後，就可以根據這些信息重新組裝這幾個分次接收的拆分IP包。在這 裏就有一個安全漏洞可以利用了，就是如果***們在截取IP數據包後，把偏移字段設置成不正確的值，這樣接收端在收到這些分拆的數據包後，就不能按數據包中的偏移字段值正確組合這些拆分的數據包，但接收端會不斷嘗試，這樣就可能致使目標計算機操作系統因資源耗盡而崩潰。
【防禦方法】
檢測這類***的方法是對接收到的分片數據包進行分析，計算數據包的片偏移量（Offset）是否有誤。反***的方法是添加系統補丁程序，丟棄收到的病態分片數據包並對這種***進行審計。儘可能採用最新的操作系統，或者在防火牆上設置分段重組功能，由防火牆先接收到同一原包中的所有拆分數據包，然後完成重組工作，而不是直接轉發。因爲防火牆上可以設置當出現重疊字段時所採用的規則。
7、IP地址掃描***
IP地址掃描***是***者運用ICMP報文（如Ping和Tracert命令）探測目標地址，或者使用TCP/UDP報文對一定地址發起連接，通過判斷是否有應答報文，以確定哪些目標系統確實存活着並且連接在目標網絡上。
【防禦方法】
防火牆對收到的TCP、UDP、ICMP報文進行檢測，當某源IP地址連續發送報文的目的IP地址與前一個報文的目的IP地址不同時，則記爲一次異常，當異常次數超過預定義的閾值時，則認爲該源IP的行爲爲IP地址掃描行爲，防火牆會將該源IP地址加入黑名單。
8、Smurf***
Smurf***通過使用將回復地址設置成受害網絡的廣播地址的ICMP應答請求(ping)數據包，來淹沒受害主機，最終導致該網絡的所有主機都對此ICMP應答請求做出答覆，導致網絡阻塞。更加複雜的Smurf將源地址改爲第三方的受害者，最終導致第三方崩潰。
***的過程是這樣的：Woodlly Attacker向一個具有大量主機和因特網連接的網絡的廣播地址發送一個欺騙性Ping分組（echo 請求），這個目標網絡被稱爲反彈站點，而欺騙性Ping分組的源地址就是Woolly希望***的系統。
這種***的前提是，路由器接收到這個發送給IP廣播地址（如206.121.73.255）的分組後，會認爲這就是廣播分組，並且把以太網廣播地址FF:FF:FF:FF:FF:FF:映射過來。這樣路由器因因特網上接收到該分組，會對本地網段中的所有主機進行廣播。
讀者肯定能夠想到下面會發生什麼情況。網段中的所有主機都會向欺騙性分組的IP地址發送echo響應信息。如果這是一個很大的以太網段，可以會有500個以上的主機對收到的echo請求進行回覆。
由於多數系統都會儘快地處理ICMP傳輸信息，Woodlly Attacker把分組的源地址設置爲目標系統，因此目標系統都很快就會被大量的echo信息吞沒，這樣輕而易舉地就能夠阻止該系統處理其它任何網絡傳輸，從而引起拒絕爲正常系統服務。
這種***不僅影響目標系統，還影響目標公司的因特網連接。如果反彈站點具有T3連接（45Mbps），而目標系統所在的公司使用的是租用線路（56Kbps），則所有進出該公司的通訊都會停止下來。
這種***現在已經很少見,大多數的網絡已經對這種***免疫了.
【防禦方法】
配置路由器禁止IP廣播包進網
配置網絡上所有計算機的操作系統，禁止對目標地址爲廣播地址的ICMP包響應。
被***目標與ISP協商，有ISP暫時阻止這些流量。
對於從本網絡向外部網絡發送的數據包，本網絡應該將其源地址爲其他網絡的這部分數據包過
9、Fraggle***
類似於Smurf，使用UDP應答消息而非ICMP。UDP端口7（ECHO）和端口19（Chargen）在收到UDP報文後，都會產生迴應。在UDP的7號端口收到報文後，會迴應收到的內容，而UDP的19號端口在收到報文後，會產生一串字符流。它們都同ICMP一樣，會產生大量無用的應答報文，佔滿網路帶寬。***者可以向子網廣播地址發送源地址爲受害網絡或受害主機的UDP包，端口號用7或19.子網絡啓用了此功能的每個系統都會向受害者的主機做出響應，從而引發大量的包，導致受害網絡的阻塞或受害主機的崩潰；子網上沒有啓動這些功能的系統將產生一個ICMP不可達的消息，因而仍然消耗帶寬。也可將源端口改爲Chargen。目的端口爲ECHO，這樣會自動不停地產生迴應報文，其危害性更大。
【防禦方法】
檢查進入防火牆的UDP報文，若目的端口號爲7或19，則直接拒絕，並將***記錄到日誌，否則允許通過。
10、電子郵件炸彈
電子郵件炸彈是最古老的匿名***之一，通過設置一臺機器不斷的大量的向同一地址發送電子郵件，***者能夠耗盡接受者網絡的帶寬。
【防禦方法】
對郵件地址進行配置，自動刪除來自同一主機的過量或重複的消息。
11、畸形消息***
各類操作系統上的許多服務都存在此類問題，由於這些服務在處理信息之前沒有進行適當正確的錯誤校驗，在收到畸形的信息可能會崩潰。
【防禦方法】
打最新的服務補丁。