許多伴侶都知道木桶理論，一桶水的最大容量不是由它最高的處所抉擇的，而是由它最低的處所抉擇，處事器也是一樣，處事器的安詳性也是由它最懦弱的處所抉擇的，最懦弱的處所有多危險處事器就有多危險。DDOS也是一樣，只要你的處事器存在一個很耗資源的處所，限制又不足，就頓時成為別人DDOS的工具。好比SYN-FLOOD，它就是操作處事器的半毗連狀態(tài)比完全毗連狀態(tài)更耗資源，而SYN動員方只需要不斷的發(fā)包，基礎(chǔ)不需要幾多資源。一個好的DDOS進攻必需是通過本身少少資源的耗損帶來對方較大的資源耗損，不然好比ICMP-FLOOD和UDP-FLOOD都必需和別人一樣大的帶寬，對方處事器耗損幾多資源本身也得賠上幾多資源，效率極其低下，又很容易被人發(fā)明，此刻根基沒有什么人用了。
CC進攻道理
CC主要是用來進攻頁面的。各人都有這樣的經(jīng)驗，就是在會見論壇時，假如這個論壇較量大，會見的人較量多，打開頁面的速度會較量慢，對不？！一般來說，會見的人越多，論壇的頁面越多，數(shù)據(jù)庫就越大，被會見的頻率也越高，占用的系統(tǒng)資源也就相當可觀，此刻知道為什么許多空間處事商都說各人不要上傳論壇，談天室等對象了吧。
一個靜態(tài)頁面不需要處事器幾多資源，甚至可以說直接從內(nèi)存中讀出來發(fā)給你就可以了，可是論壇就紛歧樣了，我看一個帖子，系統(tǒng)需要到數(shù)據(jù)庫中判定我是否有讀讀帖子的權(quán)限，假如有，就讀出帖子內(nèi)里的內(nèi)容，顯示出來——這里至少會見了2次數(shù)據(jù)庫，假如數(shù)據(jù)庫的體積有200MB巨細，系統(tǒng)很大概就要在這200MB巨細的數(shù)據(jù)空間搜索一遍，這需要幾多的CPU資源和時間？假如我是查找一個要害字，那么時間越發(fā)可觀，因為前面的搜索可以限定在一個很小的范疇內(nèi)，好比用戶權(quán)限只查用戶表，帖子內(nèi)容只查帖子表，并且查到就可以頓時遏制查詢，而搜索必定會對所有的數(shù)據(jù)舉辦一次判定，耗損的時間是相當?shù)拇蟆?br />
CC就是充實操作了這個特點，模仿多個用戶（幾多線程就是幾多用戶）不斷的舉辦會見（會見那些需要大量數(shù)據(jù)操縱，就是需要大量CPU時間的頁面）。許多伴侶問到，為什么要利用署理呢？因為署理可以有效地埋沒本身的身份，也可以繞開所有的防火墻，因為根基上所有的防火墻城市檢測并發(fā)的TCP/IP毗連數(shù)目，高出必然數(shù)目必然頻率就會被認為是Connection-Flood。利用署理進攻還能很好的保持毗連，，我們這里發(fā)送了數(shù)據(jù)，署理幫我們轉(zhuǎn)發(fā)給對方處事器，我們就可以頓時斷開，署理還會繼承保持著和對方毗連（我知道的記錄是有人操作2000個署剃頭生了35萬并發(fā)毗連）。
大概許多伴侶還不能很好的領(lǐng)略，我來描寫一下吧。我們假設(shè)處事器A對Search.asp的處理懲罰時間需要0.01S（多線程只是時間支解，對結(jié)論沒有影響），也就是說他一秒可以擔(dān)保100個用戶的Search請求，處事器答允的最大毗連時間為60s，那么我們利用CC模仿120個用戶并發(fā)毗連，那么顛末1分鐘，處事器的被請求了7200次，處理懲罰了6000次，于是剩下了1200個并發(fā)毗連沒有被處理懲罰。有的伴侶會說：丟毗連！丟毗連！問題是處事器是按先來后到的順序丟的，這1200個是在最后10秒的時候提倡的，想丟？！還早，顛末計較，處事器滿負開始丟毗連的時候，應(yīng)該是有7200個并發(fā)毗連存在行列，然后處事器開始120個/秒的丟毗連，我們動員的毗連也是120個/秒，處事器永遠有處理懲罰不完的毗連，處事器的CPU100%并長時間保持，然后丟毗連的60秒處事器也判定處理懲罰不外來了，新的毗連也處理懲罰不了，這樣處事器到達了超等忙碌狀態(tài)。
蝴蝶：我們假設(shè)處事器處理懲罰Search只用了0.01S，也就是10毫秒（這個速度你可以去各個有開放時間顯示的論壇看看），我們利用的線程也只有120，許多處事器的丟毗連時間遠比60S長，我們的利用線程遠比120多，可以想象可駭了吧，并且客戶機只要發(fā)送了斷開，毗連的保持是署理做的，并且當處事器收到SQL請求，必定會進入行列，豈論毗連是否已經(jīng)斷開，并且處事器是并發(fā)的，不是順序執(zhí)行，這樣使得更多的請求進入內(nèi)存請求，對處事器承擔(dān)更大。
雖然，CC也可以操作這里要領(lǐng)對FTP舉辦進攻，也可以實現(xiàn)TCP-FLOOD，這些都是顛末測試有效的。
防御要領(lǐng)
說了進攻道理，各人必定會問，那么怎么防止？利用硬件防火墻我不知道如何防御，除非你完全屏蔽頁面會見，我的要領(lǐng)是通過頁面的編寫實現(xiàn)防止。
1.利用Cookie認證。這時候伴侶說CC內(nèi)里也答允Cookie，可是這里的Cookie是所有毗連都利用的，所以啟用IP+Cookie認證就可以了。
2.操作Session。這個判定比Cookie越發(fā)利便，不僅可以IP認證，還可以防刷新模式，在頁面里判定刷新，是刷新就不讓它會見，沒有刷新標記給它刷新標記。給些示范代碼吧，Session：
1then
Session(“refresh”)=session(“refresh”)+1
Response.redirect“index.asp”
Endif
這樣用戶第一次會見會使得Refresh=1，第二次會見，正常，第三次，不讓他會見了，認為是刷新，可以加上一個時間參數(shù)，讓幾多時間答允會見，這樣就限制了耗時間的頁面的會見，對正常客戶險些沒有什么影響。
3.通過署剃頭送的HTTP_X_FORWARDED_FOR變量來判定利用署理進攻呆板的真實IP，這招完全可以找到動員進攻的人，雖然，不是所有的署理處事器都發(fā)送，可是有許多署理都發(fā)送這個參數(shù)。具體代碼：
這樣會生成CCLog.txt，它的記錄名目是：真實IP[署理的IP]時間，看看哪個真實IP呈現(xiàn)的次數(shù)多，就知道是誰在進攻了。將這個代碼做成Conn.asp文件，替代那些毗連數(shù)據(jù)庫的文件，這樣所有的數(shù)據(jù)庫請求就毗連到這個文件上，然后頓時就能發(fā)明進攻的人。
4.尚有一個要領(lǐng)就是把需要對數(shù)據(jù)查詢的語句做在Redirect后頭，讓對方必需先會見一個判定頁面，然后Redirect已往。
5.在存在多站的處事器上，嚴格限制每一個站答允的IP毗連數(shù)和CPU利用時間，這是一個很有效的要領(lǐng)。
CC的防止要從代碼做起，其實一個好的頁面代碼都應(yīng)該留意這些對象，尚有SQL注入，不僅是一個入侵東西，更是一個DDOS缺口，各人都應(yīng)該在代碼中留意。舉個例子吧，某處事器，開動了5000線的CC進攻，沒有一點回響，因為它所有的會見數(shù)據(jù)庫請求都必需一個隨機參數(shù)在Session內(nèi)里，全是靜態(tài)頁面，沒有結(jié)果。溘然發(fā)明它有一個請求會和外面的處事器接洽得到，需要較長的時間，并且沒有什么認證，開800線進攻，處事器頓時滿負荷了。
代碼層的防止需要從點點滴滴做起，一個劇本代碼的錯誤，大概帶來的是整個站的影響，甚至是整個處事器的影響，慎之！
