很多朋友都知道木桶理論，一桶水的最大容量不是由它最高的地方?jīng)Q定的，而是由它最低的地方?jīng)Q定，服務器也是一樣，服務器的安全性也是由它最脆弱的地方?jīng)Q定的，最脆弱的地方有多危險服務器就有多危險。DDOS也是一樣，只要你的服務器存在一個很耗資源的地方，限制又不夠，就馬上成為別人DDOS的對象。比如SYN-FLOOD，它就是利用服務器的半連接狀態(tài)比完全連接狀態(tài)更耗資源，而SYN發(fā)動方只需要不停的發(fā)包，根本不需要多少資源。一個好的DDOS攻擊必須是通過自己極少資源的消耗帶來對方較大的資源消耗，否則比如ICMP-FLOOD和UDP-FLOOD都必須和別人一樣大的帶寬，對方服務器消耗多少資源自己也得賠上多少資源，效率極其低下，又很容易被人發(fā)現(xiàn)，現(xiàn)在基本沒有什么人用了。

CC攻擊原理

CC主要是用來攻擊頁面的。大家都有這樣的經(jīng)歷，就是在訪問論壇時，如果這個論壇比較大，訪問的人比較多，打開頁面的速度會比較慢，對不？！一般來說，訪問的人越多，論壇的頁面越多，數(shù)據(jù)庫就越大，被訪問的頻率也越高，占用的系統(tǒng)資源也就相當可觀，現(xiàn)在知道為什么很多空間服務商都說大家不要上傳論壇，聊天室等東西了吧。

一個靜態(tài)頁面不需要服務器多少資源，甚至可以說直接從內(nèi)存中讀出來發(fā)給你就可以了，但是論壇就不一樣了，我看一個帖子，系統(tǒng)需要到數(shù)據(jù)庫中判斷我是否有讀讀帖子的權(quán)限，如果有，就讀出帖子里面的內(nèi)容，顯示出來——這里至少訪問了2次數(shù)據(jù)庫，如果數(shù)據(jù)庫的體積有200MB大小，系統(tǒng)很可能就要在這200MB大小的數(shù)據(jù)空間搜索一遍，這需要多少的CPU資源和時間？如果我是查找一個關(guān)鍵字，那么時間更加可觀，因為前面的搜索可以限定在一個很小的范圍內(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ā)給對方服務器，我們就可以馬上斷開，代理還會繼續(xù)保持著和對方連接（我知道的記錄是有人利用2000個代理產(chǎn)生了35萬并發(fā)連接）。

可能很多朋友還不能很好的理解，我來描述一下吧。我們假設(shè)服務器A對Search.asp的處理時間需要0.01S（多線程只是時間分割，對結(jié)論沒有影響），也就是說他一秒可以保證100個用戶的Search請求，服務器允許的最大連接時間為60s，那么我們使用CC模擬120個用戶并發(fā)連接，那么經(jīng)過1分鐘，服務器的被請求了7200次，處理了6000次，于是剩下了1200個并發(fā)連接沒有被處理。有的朋友會說：丟連接！丟連接！問題是服務器是按先來后到的順序丟的，這1200個是在最后10秒的時候發(fā)起的，想丟？！還早，經(jīng)過計算，服務器滿負開始丟連接的時候，應該是有7200個并發(fā)連接存在隊列，然后服務器開始120個/秒的丟連接，我們發(fā)動的連接也是120個/秒，服務器永遠有處理不完的連接，服務器的CPU100%并長時間保持，然后丟連接的60秒服務器也判斷處理不過來了，新的連接也處理不了，這樣服務器達到了超級繁忙狀態(tài)。

蝴蝶：我們假設(shè)服務器處理Search只用了0.01S，也就是10毫秒（這個速度你可以去各個有開放時間顯示的論壇看看），我們使用的線程也只有120，很多服務器的丟連接時間遠比60S長，我們的使用線程遠比120多，可以想象可怕了吧，而且客戶機只要發(fā)送了斷開，連接的保持是代理做的，而且當服務器收到SQL請求，肯定會進入隊列，不論連接是否已經(jīng)斷開，而且服務器是并發(fā)的，不是順序執(zhí)行，這樣使得更多的請求進入內(nèi)存請求，對服務器負擔更大。

當然，CC也可以利用這里方法對FTP進行攻擊，也可以實現(xiàn)TCP-FLOOD，這些都是經(jīng)過測試有效的。

防范方法

說了攻擊原理，大家肯定會問，那么怎么防御？使用硬件防火墻我不知道如何防范，除非你完全屏蔽頁面訪問，我的方法是通過頁面的編寫實現(xiàn)防御。

1.使用Cookie認證。這時候朋友說CC里面也允許Cookie，但是這里的Cookie是所有連接都使用的，所以啟用IP+Cookie認證就可以了。

2.利用Session。這個判斷比Cookie更加方便，不光可以IP認證，還可以防刷新模式，在頁面里判斷刷新，是刷新就不讓它訪問，沒有刷新符號給它刷新符號。給些示范代碼吧，Session：

1then

Session(“refresh”)=session(“refresh”)+1

Response.redirect“index.asp”

Endif

這樣用戶第一次訪問會使得Refresh=1，第二次訪問，正常，第三次，不讓他訪問了，認為是刷新，可以加上一個時間參數(shù)，讓多少時間允許訪問，這樣就限制了耗時間的頁面的訪問，對正常客戶幾乎沒有什么影響。

3.通過代理發(fā)送的HTTP_X_FORWARDED_FOR變量來判斷使用代理攻擊機器的真實IP，這招完全可以找到發(fā)動攻擊的人，當然，不是所有的代理服務器都發(fā)送，但是有很多代理都發(fā)送這個參數(shù)。詳細代碼：

這樣會生成CCLog.txt，它的記錄格式是：真實IP[代理的IP]時間，看看哪個真實IP出現(xiàn)的次數(shù)多，就知道是誰在攻擊了。將這個代碼做成Conn.asp文件，替代那些連接數(shù)據(jù)庫的文件，這樣所有的數(shù)據(jù)庫請求就連接到這個文件上，然后馬上就能發(fā)現(xiàn)攻擊的人。

4.還有一個方法就是把需要對數(shù)據(jù)查詢的語句做在Redirect后面，讓對方必須先訪問一個判斷頁面，然后Redirect過去。

5.在存在多站的服務器上，嚴格限制每一個站允許的IP連接數(shù)和CPU使用時間，這是一個很有效的方法。

CC的防御要從代碼做起，其實一個好的頁面代碼都應該注意這些東西，還有SQL注入，不光是一個入侵工具，更是一個DDOS缺口，大家都應該在代碼中注意。舉個例子吧，某服務器，開動了5000線的CC攻擊，沒有一點反應，因為它所有的訪問數(shù)據(jù)庫請求都必須一個隨機參數(shù)在Session里面，全是靜態(tài)頁面，沒有效果。突然發(fā)現(xiàn)它有一個請求會和外面的服務器聯(lián)系獲得，需要較長的時間，而且沒有什么認證，開800線攻擊，服務器馬上滿負荷了。

代碼層的防御需要從點點滴滴做起，一個腳本代碼的錯誤，可能帶來的是整個站的影響，甚至是整個服務器的影響，慎之！