作為站長或者公司的網站的網管，什么最可怕？
顯然是網站受到的DDoS攻擊。大家都有這樣的經歷,就是在訪問某一公司網站或者論壇時,如果這個網站或者論壇流量比較大,訪問的人比較多,打開頁面的速度會比較慢,對不?!一般來說,訪問的人越多,網站或論壇的頁面越多,數據庫就越大,被訪問的頻率也越高,占用的系統資源也就相當可觀,。
CC攻擊是DDoS(分布式拒絕服務)的一種，相比其它的DDoS攻擊CC似乎更有技術含量一些。這種攻擊你見不到虛假IP，見不到特別大的異常流量，但造成服務器無法進行正常連接，一條ADSL的普通用戶足以掛掉一臺高性能的Web服務器。由此可見其危害性，稱其為“Web殺手”毫不為過。最讓站長們憂慮的是這種攻擊技術含量不是很高，利用工具和一些IP代理，一個初、中級的電腦水平的用戶就能夠實施DDoS 攻擊。
那么怎樣保證這些網站服務器的安全呢？冰盾DDoS防火墻專家認為，防護CC攻擊大家有必要了解CC攻擊的原理及如果發現CC攻擊和對其的防范措施（參閱：http://www.bingdun.com/solution/website.htm）。
一、 CC攻擊的原理：?
CC攻擊的原理就是攻擊者控制某些主機不停地發大量數據包給對方服務器造成服務器資源耗盡，一直到宕機崩潰。CC主要是用來攻擊頁面的，每個人都有這樣的體驗：當一個網頁訪問的人數特別多的時候，打開網頁就慢了，CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行訪問那些需要大量數據操作(就是需要大量CPU時間)的頁面，造成服務器資源的浪費，CPU長時間處于100%，永遠都有處理不完的連接直至就網絡擁塞，正常的訪問被中止。
二、CC攻擊的種類：?
CC攻擊的種類有三種，直接攻擊，代理攻擊，僵尸網絡攻擊，直接攻擊主要針對有重要缺陷的 WEB 應用程序，一般說來是程序寫的有問題的時候才會出現這種情況，比較少見。僵尸網絡攻擊有點類似于 DDOS 攻擊了，從 WEB 應用程序層面上已經無法防御，所以代理攻擊是CC 攻擊者一般會操作一批代理服務器，比方說 100 個代理，然后每個代理同時發出 10 個請求，這樣 WEB 服務器同時收到 1000 個并發請求的，并且在發出請求后，立刻斷掉與代理的連接，避免代理返回的數據將本身的帶寬堵死，而不能發動再次請求，這時 WEB 服務器會將響應這些請求的進程進行隊列，數據庫服務器也同樣如此，這樣一來，正常請求將會被排在很后被處理，就象本來你去食堂吃飯時，一般只有不到十個人在排隊，今天前面卻插了一千個人，那么輪到你的機會就很小很小了，這時就出現頁面打開極其緩慢或者白屏。
三、 攻擊癥狀?
CC攻擊有一定的隱蔽性，那如何確定服務器正在遭受或者曾經遭受CC攻擊呢?我們可以通過以下三個方法來確定。
(1).命令行法
一般遭受CC攻擊時，Web服務器會出現80端口對外關閉的現象， 因為這個端口已經被大量的垃圾數據堵塞了正常的連接被中止了。我們可以通過在命令行下輸入命令netstat -an來查看，如果看到類似如下有大量顯示雷同的連接記錄基本就可以被CC攻擊了：
……?
TCP 192.168.1.3:80 192.168.1.6:2205 SYN_RECEIVED 4?
TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4?
TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4?
TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4?
TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4 ……?
其中“192.168.1.6”就是被用來代理攻擊的主機的IP，“SYN_RECEIVED”是TCP連接狀態標志，意思是“正在處于連接的初始同步狀態 ”，表明無法建立握手應答處于等待狀態。這就是攻擊的特征，一般情況下這樣的記錄一般都會有很多條，表示來自不同的代理IP的攻擊。
(2).批處理法?
上述方法需要手工輸入命令且如果Web服務器IP連接太多看起來比較費勁，我們可以建立一個批處理文件，通過該腳本代碼確定是否存在CC攻擊。打開記事本鍵入如下代碼保存為CC.bat：?
@echo off?
time /t >>log.log?
netstat -n -p tcp |find ":80">>Log.log?
notepad log.log?
exit?
上面的腳本的含義是篩選出當前所有的到80端口的連接。當我們感覺服務器異常是就可以雙擊運行該批處理文件，然后在打開的log.log文件中查看所有的連接。如果同一個IP有比較多的到服務器的連接，那就基本可以確定該IP正在對服務器進行CC攻擊。?
(3).查看系統日志?
上面的兩種方法有個弊端，只可以查看當前的CC攻擊，對于確定Web服務器之前是否遭受CC攻擊就無能為力了，此時我們可以通過Web日志來查，因為Web日志忠實地記錄了所有IP訪問Web資源的情況。通過查看日志我們可以Web服務器之前是否遭受CC攻擊，并確定攻擊者的IP然后采取進一步的措施。
Web日志一般在C:\WINDOWS\system32\LogFiles\HTTPERR目錄下，該目錄下用類似httperr1.log的日志文件，這個文件就是記錄Web訪問錯誤的記錄。管理員可以依據日志時間屬性選擇相應的日志打開進行分析是否Web被CC攻擊了。默認情況下，Web日志記錄的項并不是很多，我們可以通過IIS進行設置，讓Web日志記錄更多的項以便進行安全分析。其操作步驟是：?
“開始→管理工具”打開“Internet信息服務器”，展開左側的項定位到到相應的Web站點，然后右鍵點擊選擇“屬性”打開站點屬性窗口，在“網站”選項卡下點擊“屬性”按鈕，在“日志記錄屬性”窗口的“高級”選項卡下可以勾選相應的“擴展屬性”，以便讓Web日志進行記錄。比如其中的“發送的字節數”、“接收的字節數”、“所用時間”這三項默認是沒有選中的，但在記錄判斷CC攻擊中是非常有用的，可以勾選。另外，如果你對安全的要求比較高，可以在“常規”選項卡下對“新日志計劃”進行設置，讓其“每小時”或者“每一天”進行記錄。為了便于日后進行分析時好確定時間可以勾選“文件命名和創建使用當地時間”。
四、 CC攻擊防御策略?
確定Web服務器正在或者曾經遭受CC攻擊，那如何進行有效的防范呢?
(1).取消域名綁定?
一般cc攻擊都是針對網站的域名進行攻擊，比如我們的網站域名是“www.abc.com”，那么攻擊者就在攻擊工具中設定攻擊對象為該域名然后實施攻擊。?
對于這樣的攻擊我們的措施是在IIS上取消這個域名的綁定，讓CC攻擊失去目標。具體操作步驟是：打開“IIS管理器”定位到具體站點右鍵“屬性”打開該站點的屬性面板，點擊IP地址右側的“高級”按鈕，選擇該域名項進行編輯，將“主機頭值”刪除或者改為其它的值(域名)。?
經過模擬測試，取消域名綁定后Web服務器的CPU馬上恢復正常狀態，通過IP進行訪問連接一切正常。但是不足之處也很明顯，取消或者更改域名對于別人的訪問帶來了不變，另外，對于針對IP的CC攻擊它是無效的，就算更換域名攻擊者發現之后，他也會對新域名實施攻擊。
(2).域名欺騙解析?
如果發現針對域名的CC攻擊，我們可以把被攻擊的域名解析到127.0.0.1這個地址上。我們知道127.0.0.1是本地回環IP是用來進行網絡測試的，如果把被攻擊的域名解析到這個IP上，就可以實現攻擊者自己攻擊自己的目的，這樣他再多的肉雞或者代理也會宕機，讓其自作自受。?
另外，當我們的Web服務器遭受CC攻擊時把被攻擊的域名解析到國家有權威的政府網站或者是網警的網站，讓其網警來收拾他們。?
現在一般的Web站點都是利用類似“新網”這樣的服務商提供的動態域名解析服務，大家可以登錄進去之后進行設置。
(3).更改Web端口?
一般情況下Web服務器通過80端口對外提供服務，因此攻擊者實施攻擊就以默認的80端口進行攻擊，所以，我們可以修改Web端口達到防CC攻擊的目的。運行IIS管理器，定位到相應站點，打開站點“屬性”面板，在“網站標識”下有個TCP端口默認為80，我們修改為其他的端口就可以了。
(4).IIS屏蔽IP?
我們通過命令或在查看日志發現了CC攻擊的源IP，就可以在IIS中設置屏蔽該IP對Web站點的訪問，從而達到防范IIS攻擊的目的。在相應站點的“屬性”面板中，點擊“目錄安全性”選項卡，點擊“IP地址和域名現在”下的“編輯”按鈕打開設置對話框。在此窗口中我們可以設置“授權訪問”也就是“白名單”，也可以設置“拒絕訪問”即“黑名單”。比如我們可以將攻擊者的IP添加到“拒絕訪問”列表中，就屏蔽了該IP對于Web的訪問。
五、針對CC攻擊的商業解決方案
很多的網站管理者是等到網站遭到攻擊了，受到損失了，才去尋求解決的方案，在將來的互聯網飛速發展的時代，一定要有安全隱患意識，不要等到損失大了，再去想辦法來補救，這樣為時已晚。
然而當網站受到攻擊時，大多數人想到的是-----快點找硬防，基本上都步了一個誤區，就是認為網站或者服務器被攻擊，購買硬件防火墻，什么事都萬事大吉了，實際上這樣的想法是極端錯誤的。多年的統計數據表明，想徹底解CC攻擊是幾乎不可能的，就好比治療感冒一樣，我們可以治療，也可以預防，但卻無法根治，但我們若采取積極有效的防御方法，則可在很大程度上降低或減緩生病的機率，防治DDOS攻擊也是如此， 實際上比較理想解決方案應該是“軟件+硬件”的解決方案。此方案對于資金較為充足的企業網站來說，這個方案適合他們；硬件在DDOS防護上有優勢，軟件CC防護上有優勢；
相對于一些對于ICP內容網站、論壇社區BBS、電子商務eBusiness、音樂網站Music、電影網站File等網站服務器越來越普及，但由于種種原因往往會遭受競爭對手或打擊報復者的惡意DDOS攻擊，持續的攻擊會導致大量用戶流失，嚴重的甚至因人氣全失而被迫關閉服務器，為了最大程度的保護運營者的利益，冰盾科技結合多年抗DDOS的實踐經驗給出了最少的安全投資可獲得最大安全回報的抗DDOS解決方案。
首先攻擊者擁有一個流量巨大的網站，這個網站的流量，很可能是他花錢買回來的，當然也可能是他控制的肉雞，在控制的肉雞上面訪問他的網站。黑客的網站首頁非常簡單，但是在他的源代碼中，卻隱藏了達到上百個<iframe>標簽。對！聰明的你，應該想得出他的<iframe>標簽里面放的是什么了吧？沒錯！他的<iframe>里面，放的就是他要攻擊的網站的地址。
??????? 舉一個例子來說明一下攻擊者的威力，假設黑客的網站是aaa.com，你的網站是BBB.com。如果有人在163的首頁代碼中，有這么一段：<iframe src="http://aaa.com" border="0" width="0" height="0"></iframe>，那么在所有人訪問163的主頁時，也會不知不覺的訪問http://aaa.com。然后http://aaa.com的首頁中可能有100個如下的代碼：<iframe src=http://BBB.com border="0" width="0" height="0"></iframe>，當然他還可能放上bbb.com這個網站十個甚至更多不同的地址。那就表明：凡是有一個人訪問了163，就可能會訪問BBB.com十次。以每秒300個請求來說，一天就是25920000個請求，再加上頁面上的圖片和其它文件等，估計就是上億個請求了。1天上億個請求，普通的網站受得了嗎？有很多被攻擊的網站用的是虛擬主機，每秒不到100個連接可能就無法提供服務了。即使是那種單獨幾臺服務器的網站，也根本就無法承受！即使WEB Server可以承受，那帶寬呢？即使帶寬可以承受，那么Db Server呢？
??????? 朋友的網站就受到此種攻擊，他試著將網站轉移到他朋友的服務器上面，當然最后的結果還是照樣拖累他朋友的服務器癱瘓。
??????? 這種就是是典型的CC攻擊。CC攻擊比DDOS攻擊更可怕的就是，CC攻擊一般是硬防很難防止住的。為什么呢？一、因為CC攻擊來的IP都是真實的，分散的；二、CC攻擊的數據包都是正常的數據包；三、CC攻擊的請求，全都是有效的請求，無法拒絕的請求。
??????? 其實只要仔細研究了一下這種攻擊的模式，發現這種攻擊，理論上是可以防止的，即只要通過有效的手段，完全可以將危害降低到最輕。因為這種攻擊有一個致命的弱點。它致命的弱點在哪里呢？當然就是在<iframe>上面。通過<iframe>進行CC攻擊，攻擊者的想法和創意，確實很讓人驚嘆，但這正好造成了他的完美失敗。熟悉網頁程序的朋友應該都知道，用<iframe>嵌入的網頁，自然都會有HTTP_REFERER值，而有了這個值，從這個值上面屏蔽或是轉發掉來源的網站即可。也就是說，你可以訪問我，但是我不將真實的頁面返回給你，我可以把你隨意打發掉，或是將你隨意轉到另外一個網站上去（如：公安部？哈哈，我就見過有人類似這樣做的），這樣我就可以大量的節省我的帶寬、我的DB Server資源、我的Web Server資源。你最多就是占用了我大量的TCP連接罷了。
下面貼一段Web server的配置代碼，用于解決此類攻擊：
valid_referers none blocked server_names google.com google.cn *.google.com *.google.cn baidu.com *.baidu.com *.你自己的域名(在這里還可以加入其他的，比如說SOSO，YAHOO，SOGOU YOUDAO等);
if ($invalid_referer) {
return?? 404;
}
??????? 上面的代碼，很簡單的設置了，只要不是HTTP_REFERER來源于上面設置網址來源的請求，通通轉發至404。
CC攻擊大家都懂的，就是消耗服務器資源，資源，可以是哪些？
1.CPU，2.內存，3.網絡，4.連接，5.數據庫資源，6.服務應用池，7.。。。。
CC攻擊，就是偽造N多請求，瞬間同時訪問。可以造成服務端溢出、報錯、系統崩潰、硬盤燒壞、網卡發熱、數據庫不能連接、查詢、內存溢出。
另外，32位系統最多占用4G內存也是一個瓶頸【所以建議大內存VPS/獨服裝64BIT】。
解決辦法：
燒錢，砸硬防。
如果資金不充裕，或者處于創業成長期，可以考慮下面幾處：
1.升級服務器（哪是瓶頸就升哪里）。
2.優化程序，數據庫使用NOSQL【非查詢式數據庫】，比如memcached。
3.前端使用一部分防火墻規則，注意最好使用被動防御【有攻擊了再啟動規則】。
4.集群。
別信啥CDN可防C的。除非他家是GOV開的，否則他砸不起這錢。
我們公司用的CHINACACHE，可是有屁防C的功能。
這里主要講解一下針對數據庫瓶頸的CC攻擊。
比如一search.php?keyword=1992year，查詢一次需要0.01秒，那么查詢100次就可以占滿1秒 CPU時間，如果再加大并發量，
比如加大10倍，那么這些請求就得排隊讓CPU處理 10秒鐘。
這就是一種CC攻擊。當然也可以有大便那種60萬并發的CC，靜態頁面都能C死，當然這除了砸錢是無解的，我們討論也沒意義。
傳統CC針對的瓶頸主要就是數據庫查詢瓶頸。
應對：memcached【內存緩存】
比如，查詢 search.php?keyword=1992year，就可以
$mem->set("search_keyword_".md5($_GET['keyword']),$mysql_data,600)將查詢得到的數據緩存在內存中，
600是指過期時間，是指在10分鐘過后，緩存可能會被新插入的緩存覆蓋。
這樣，如果內存不出現瓶頸，數據庫壓力可以被分擔很多。
但。。。新的問題又來了，每個請求keyword不同，那么不也同樣可以C死？
所以，必需限制總的處理量
用nginx_limit_req，將seach.php為key，把search.php總的【非單IP】并發限制在5個/秒。
超時彈回一個php js算法驗證【有效期一次】，
這樣，就算SEARCH.PHP被C住，也影響不大。
最重要的，還是那句話：千萬別裝B，裝B遭雷P。
轉自：http://www.hostloc.com/thread-116967-1-2.html
http://www.admin5.com/article/20081102/112695.shtml
? ? ? ? ? ? http://www.bingdun.com/cc/1158.htm
有服務器需求請加QQ1911624872咨詢
