一、 CC攻擊的原理：
CC攻擊的原理就是攻擊者控制某些主機不停地發(fā)大量數(shù)據(jù)包給對方服務(wù)器造成服務(wù)器資源耗盡，一直到宕機崩潰。CC主要是用來消耗服務(wù)器資源的，每個人都有這樣的體驗：當(dāng)一個網(wǎng)頁訪問的人數(shù)特別多的時候，打開網(wǎng)頁就慢了，CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行訪問那些需要大量數(shù)據(jù)操作(就是需要大量CPU時間)的頁面，造成服務(wù)器資源的浪費，CPU長時間處于100%，永遠都有處理不完的連接直至就網(wǎng)絡(luò)擁塞，正常的訪問被中止。
二、CC攻擊的種類：
CC攻擊的種類有三種，直接攻擊，代理攻擊，僵尸網(wǎng)絡(luò)攻擊，直接攻擊主要針對有重要缺陷的 WEB 應(yīng)用程序，一般說來是程序?qū)懙挠袉栴}的時候才會出現(xiàn)這種情況，比較少見。僵尸網(wǎng)絡(luò)攻擊有點類似于 DDoS 攻擊了，從 WEB 應(yīng)用程序?qū)用嫔弦呀?jīng)無法防御，所以代理攻擊是CC 攻擊者一般會操作一批代理服務(wù)器，比方說 100 個代理，然后每個代理同時發(fā)出 10 個請求，這樣 WEB 服務(wù)器同時收到 1000 個并發(fā)請求的，并且在發(fā)出請求后，立刻斷掉與代理的連接，避免代理返回的數(shù)據(jù)將本身的帶寬堵死，而不能發(fā)動再次請求，這時 WEB 服務(wù)器會將響應(yīng)這些請求的進程進行隊列，數(shù)據(jù)庫服務(wù)器也同樣如此，這樣一來，正常請求將會被排在很后被處理，就象本來你去食堂吃飯時，一般只有不到十個人在排隊，今天前面卻插了一千個人，那么輪到你的機會就很小很小了，這時就出現(xiàn)頁面打開極其緩慢或者白屏。
三、CC攻擊與DDOS的區(qū)別
1) 什么是DDoS攻擊？
DDoS攻擊就是分布式的拒絕服務(wù)攻擊，DDoS攻擊手段是在傳統(tǒng)的DoS攻擊基礎(chǔ)之上產(chǎn)生的一類攻擊方式。單一的DoS攻擊一般是采用一對一方式的，隨著計算機與網(wǎng)絡(luò)技術(shù)的發(fā)展，DoS攻擊的困難程度加大了。于是就產(chǎn)生了DDoS攻擊，它的原理就很簡單：計算機與網(wǎng)絡(luò)的處理能力加大了10倍，用一臺攻擊機來攻擊不再能起作用，那么DDoS就是利用更多的傀儡機來發(fā)起進攻，以比從前更大的規(guī)模來進攻受害者。常用的DDoS軟件有：LOIC。
在這里補充兩點：第一就是DDOS攻擊不僅能攻擊計算機，還能攻擊路由器，因為路由器是一臺特殊類型的計算機；第二是網(wǎng)速決定攻擊的好和快，比如說，如果你一個被限制網(wǎng)速的環(huán)境下，它們的攻擊效果不是很明顯，但是快的網(wǎng)速相比之下更加具有攻擊效果。
2)什么是CC攻擊？
3)兩者區(qū)別
DDoS是針對IP的攻擊，而CC攻擊的是服務(wù)器資源。
四、CC攻擊的變異品種 慢速攻擊
1)什么是慢速攻擊
一說起慢速攻擊，就要談?wù)勊某擅麣v史了。HTTP Post慢速DoS攻擊第一次在技術(shù)社區(qū)被正式披露是2012年的OWASP大會上，由Wong Onn Chee 和 Tom Brennan共同演示了使用這一技術(shù)攻擊的威力。
這個攻擊的基本原理如下：對任何一個開放了HTTP訪問的服務(wù)器HTTP服務(wù)器，先建立了一個連接，指定一個比較大的content-length，然后以非常低的速度發(fā)包，比如1-10s發(fā)一個字節(jié)，然后維持住這個連接不斷開。如果客戶端持續(xù)建立這樣的連接，那么服務(wù)器上可用的連接將一點一點被占滿，從而導(dǎo)致拒絕服務(wù)。
和CC攻擊一樣，只要Web服務(wù)器開放了Web服務(wù)，那么它就可以是一個靶子，HTTP協(xié)議在接收到request之前是不對請求內(nèi)容作校驗的，所以即使你的Web應(yīng)用沒有可用的form表單，這個攻擊一樣有效。
在客戶端以單線程方式建立較大數(shù)量的無用連接，并保持持續(xù)發(fā)包的代價非常的低廉。實際試驗中一臺普通PC可以建立的連接在3000個以上。這對一臺普通的Web server，將是致命的打擊。更不用說結(jié)合肉雞群做分布式DoS了。
鑒于此攻擊簡單的利用程度、拒絕服務(wù)的后果、帶有逃逸特性的攻擊方式，這類攻擊一炮而紅，成為眾多攻擊者的研究和利用對象。
2)慢速攻擊的分類
發(fā)展到今天，慢速攻擊也多種多樣，其種類可分為以下幾種：
Slow headers：Web應(yīng)用在處理HTTP請求之前都要先接收完所有的HTTP頭部，因為HTTP頭部中包含了一些Web應(yīng)用可能用到的重要的信息。攻擊者利用這點，發(fā)起一個HTTP請求，一直不停的發(fā)送HTTP頭部，消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見，攻擊客戶端與服務(wù)器建立TCP連接后，每30秒才向服務(wù)器發(fā)送一個HTTP頭部，而Web服務(wù)器再沒接收到2個連續(xù)的rn時，會認為客戶端沒有發(fā)送完頭部，而持續(xù)的等等客戶端發(fā)送數(shù)據(jù)。
Slow body：攻擊者發(fā)送一個HTTP POST請求，該請求的Content-Length頭部值很大，使得Web服務(wù)器或代理認為客戶端要發(fā)送很大的數(shù)據(jù)。服務(wù)器會保持連接準備接收數(shù)據(jù)，但攻擊客戶端每次只發(fā)送很少量的數(shù)據(jù)，使該連接一直保持存活，消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見，攻擊客戶端與服務(wù)器建立TCP連接后，發(fā)送了完整的HTTP頭部，POST方法帶有較大的Content-Length，然后每10s發(fā)送一次隨機的參數(shù)。服務(wù)器因為沒有接收到相應(yīng)Content-Length的body，而持續(xù)的等待客戶端發(fā)送數(shù)據(jù)。
Slow read：客戶端與服務(wù)器建立連接并發(fā)送了一個HTTP請求，客戶端發(fā)送完整的請求給服務(wù)器端，然后一直保持這個連接，以很低的速度讀取Response，比如很長一段時間客戶端不讀取任何數(shù)據(jù)，通過發(fā)送Zero Window到服務(wù)器，讓服務(wù)器誤以為客戶端很忙，直到連接快超時前才讀取一個字節(jié)，以消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見，客戶端把數(shù)據(jù)發(fā)給服務(wù)器后，服務(wù)器發(fā)送響應(yīng)時，收到了客戶端的ZeroWindow提示（表示自己沒有緩沖區(qū)用于接收數(shù)據(jù)），服務(wù)器不得不持續(xù)的向客戶端發(fā)出ZeroWindowProbe包，詢問客戶端是否可以接收數(shù)據(jù)。
使用較多的慢速攻擊工具有：Slowhttptest和Slowloris。
3)哪些服務(wù)器易被慢速攻擊
慢速攻擊主要利用的是thread-based架構(gòu)的服務(wù)器的特性，這種服務(wù)器會為每個新連接打開一個線程，它會等待接收完整個HTTP頭部才會釋放連接。比如Apache會有一個超時時間來等待這種不完全連接（默認是300s），但是一旦接收到客戶端發(fā)來的數(shù)據(jù)，這個超時時間會被重置。正是因為這樣，攻擊者可以很容易保持住一個連接，因為攻擊者只需要在即將超時之前發(fā)送一個字符，便可以延長超時時間。而客戶端只需要很少的資源，便可以打開多個連接，進而占用服務(wù)器很多的資源。
經(jīng)驗證，Apache、httpd采用thread-based架構(gòu)，很容易遭受慢速攻擊。而另外一種event-based架構(gòu)的服務(wù)器，比如Nginx和lighttpd則不容易遭受慢速攻擊。
4)如何防護慢速攻擊
Apache服務(wù)器現(xiàn)在使用較多的有三種簡單防護方式。
mod_reqtimeout：Apache2.2.15后，該模塊已經(jīng)被默認包含，用戶可配置從一個客戶端接收HTTP頭部和HTTPbody的超時時間和最小速率。如果一個客戶端不能在配置時間內(nèi)發(fā)送完頭部或body數(shù)據(jù)，服務(wù)器會返回一個408REQUEST TIME OUT錯誤。配置文件如下：
< IfModule mod_reqtimeout.c > RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500 < /IfModule >
mod_qos：Apache的一個服務(wù)質(zhì)量控制模塊，用戶可配置各種不同粒度的HTTP請求閾值，配置文件如下：
< IfModule mod_qos.c > /# handle connections from up to 100000 different IPs QS_ClientEntries 100000 /# allow only 50 connections per IP QS_SrvMaxConnPerIP 50 /# limit maximum number of active TCP connections limited to 256 MaxClients 256 /# disables keep-alive when 180 (70%) TCP connections are occupied QS_SrvMaxConnClose 180 /# minimum request/response speed (deny slow clients blocking the server, keeping connections open without requesting anything QS_SrvMinDataRate 150 1200 < /IfModule >
mod_security：一個開源的WAF模塊，有專門針對慢速攻擊防護的規(guī)則，配置如下：
SecRule RESPONSE_STATUS “@streq 408” “phase:5,t:none,nolog,pass, setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:’1234123456′”
SecRule IP:SLOW_DOS_COUNTER “@gt 5” “phase:1,t:none,log,drop,
msg:’Client Connection Dropped due to high number of slow DoS alerts’, id:’1234123457′”
傳統(tǒng)的流量清洗設(shè)備針對CC攻擊，主要通過閾值的方式來進行防護，某一個客戶在一定的周期內(nèi)，請求訪問量過大，超過了閾值，清洗設(shè)備通過返回驗證碼或者JS代碼的方式。這種防護方式的依據(jù)是，攻擊者們使用肉雞上的DDoS工具模擬大量http request，這種工具一般不會解析服務(wù)端返回數(shù)據(jù)，更不會解析JS之類的代碼。因此當(dāng)清洗設(shè)備截獲到HTTP請求時，返回一段特殊JAVAScript代碼，正常用戶的瀏覽器會處理并正常跳轉(zhuǎn)不影響使用，而攻擊程序會攻擊到空處。
而對于慢速攻擊來說，通過返回驗證碼或者JS代碼的方式依然能達到部分效果。但是根據(jù)慢速攻擊的特征，可以輔助以下幾種防護方式：1、周期內(nèi)統(tǒng)計報文數(shù)量。一個TCP連接，HTTP請求的報文中，報文過多或者報文過少都是有問題的，如果一個周期內(nèi)報文數(shù)量非常少，那么它就可能是慢速攻擊；如果一個周期內(nèi)報文數(shù)量非常多，那么它就可能是一個CC攻擊。2、限制HTTP請求頭的最大許可時間。超過最大許可時間，如果數(shù)據(jù)還沒有傳輸完成，那么它就有可能是一個慢速攻擊。
簡單的Nginx防CC方式
實驗
Nginx配置
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
#限制每ip每秒不超過20個請求，漏桶數(shù)burst為5
#brust的意思就是，如果第1秒、2,3,4秒請求為19個，
#第5秒的請求為25個是被允許的。
#但是如果你第1秒就25個請求，第2秒超過20的請求返回503錯誤。
#nodelay，如果不設(shè)置該選項，嚴格使用平均速率限制請求數(shù)，
#第1秒25個請求時，5個請求放到第2秒執(zhí)行，
#設(shè)置nodelay，25個請求將在第1秒執(zhí)行。
limit_req zone=one burst=1 nodelay;
}
}
上面樣本的配置是什么意思呢？
- $binary_remote_addr 表示：客戶端IP地址
- zone 表示漏桶的名字
- rate 表示nginx處理請求的速度有多快
- burst 表示峰值
- nodelay 表示是否延遲處理請求，還是直接503返回給客戶端，如果超出rate設(shè)置的情況下。
詳細的可以參考官方說明文檔：Module ngx_http_limit_req_module
模擬請求
這里我們需要Apache Benchmark這個小工具來生成請求
//1個用戶持續(xù)100s的時間向服務(wù)器發(fā)送請求 ab -t 100 -c 1 -vvv http://example.com/
Nginx配置樣本一
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
limit_req zone=one burst=1 nodelay;
}
}
ab測試結(jié)果如下所示：
| 數(shù)據(jù) | 成功的請求數(shù) | 失敗的請求數(shù) | 請求時間 | 每秒成功的請求數(shù) |
|---|---|---|---|---|
| 1 | 100 | 19438 | 101.195 | 0.98 |
| 2 | 100 | 17651 | 100.655 | 0.99 |
| 3 | 97 | 25735 | 100.424 | 0.96 |
| 4 | 101 | 26791 | 100.000 | 1.01 |
| 5 | 98 | 19051 | 100.514 | 0.98 |
| 平均 | 99 | 21733.2 | 100.557 | 0.98 |
以上失敗的請求在Nginx上生成的錯誤日志如下顯示
2015/05/09 12:48:57 [error] 6564#0: *2219 limiting requests, excess: 1.273 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com" 2015/05/09 12:48:57 [error] 6564#0: *2220 limiting requests, excess: 1.272 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com" 2015/05/09 12:48:57 [error] 6564#0: *2221 limiting requests, excess: 1.271 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com" 2015/05/09 12:48:57 [error] 6564#0: *2222 limiting requests, excess: 1.270 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com" 2015/05/09 12:48:57 [error] 6564#0: *2223 limiting requests, excess: 1.269 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com" 2015/05/09 12:48:57 [error] 6564#0: *2224 limiting requests, excess: 1.268 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
如上ab測試中如果是失敗的請求，nginx的limit_req模塊會統(tǒng)一返回503給客戶端，瀏覽器上面顯示的是這個樣子的。
Nginx配置樣本二
在配置二里面，我把burst（峰值）提高到了10
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
limit_req zone=one burst=10 nodelay;
}
}
| 數(shù)據(jù) | 成功的請求數(shù) | 失敗的請求數(shù) | 請求時間 | 每秒成功的請求數(shù) |
|---|---|---|---|---|
| 1 | 110 | 19042 | 100.144 | 1.09 |
| 2 | 111 | 22271 | 101.714 | 1.09 |
| 3 | 111 | 18466 | 100.504 | 1.10 |
| 4 | 111 | 16468 | 101.285 | 1.09 |
| 5 | 111 | 12770 | 100.596 | 1.10 |
| 平均 | 110 | 17803 | 100.788 |
1.09 |
從數(shù)據(jù)來看，提高了burst值，明顯nginx成功的請求數(shù)上去了。
Nginx配置樣本三
在樣本二的基礎(chǔ)上，我們把nodelay去除掉
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
limit_req zone=one burst=10;
}
}
| 數(shù)據(jù) | 成功的請求數(shù) | 失敗的請求數(shù) | 請求時間 | 每秒成功的請求數(shù) |
|---|---|---|---|---|
| 1 | 96 | 0 | 100.223 | 1.09 |
| 2 | 98 | 0 | 100.238 | 0.97 |
| 3 | 100 | 0 | 100.761 | 0.99 |
| 4 | 96 | 0 | 100.074 | 0.95 |
| 5 | 97 | 0 | 100.021 | 0.96 |
| 平均 | 97.4 | 0 | 100.263 | 0.97 |
從這里的數(shù)據(jù)可以看到將nodelay的參數(shù)去掉的話，成功的請求數(shù)在100左右而失敗的請求數(shù)變成0了，為什么呢？
- 有nodelay參數(shù)的時候，nginx正常是及時處理當(dāng)前的請求的并響應(yīng)數(shù)據(jù)給客戶端，但是如果超過limit_req_module的限制，那么會統(tǒng)一返回503給客戶端。
- 無nodelay參數(shù)的時候，nginx正常是及時處理當(dāng)前的請求的并響應(yīng)數(shù)據(jù)給客戶端，但是如果超過limit_req_module的限制，那么會將此此請求緩存「就先這么理解」起來稍后再處理，所以也就不會出現(xiàn)大量的失敗請求數(shù)了。
存在的問題
雖然用limit_req_module可以一定上的防止CC攻擊，但是有誤殺概率；國內(nèi)寬帶用戶的IP地址已經(jīng)大量內(nèi)網(wǎng)化，幾百人共享一個IP的可能性是很大的。
五、應(yīng)用層DDoS的防御理論：
問題模型描述：
每一個頁面，都有其資源消耗權(quán)重，靜態(tài)資源，權(quán)重較低，動態(tài)資源，權(quán)重較高。對于用戶訪問，有如下：
用戶資源使用頻率=使用的服務(wù)器總資源量/s
命題一：對于正常訪問的用戶，資源使用頻率必定位于一個合理的范圍，當(dāng)然會存在大量正常用戶共享ip的情況，這就需要日常用戶訪問統(tǒng)計，以得到忠實用戶ip白名單。
命題二：資源使用頻率持續(xù)異常的，可斷定為訪問異常的用戶。
防御體系狀態(tài)機：
1.在系統(tǒng)各項資源非常寬裕時，向所有ip提供服務(wù)，每隔一段時間釋放一部分臨時黑名單中的ip成員；
2.在系統(tǒng)資源消耗達到某一閾值時，降低Syn包接受速率，循環(huán)：分析最近時間的日志，并將訪問異常的ip加入臨時黑名單；
3.若系統(tǒng)資源消耗慢慢回降至正常水平，則恢復(fù)Syn包接受速率，轉(zhuǎn)到狀態(tài)1；若目前策略并未有效地控制住系統(tǒng)資源消耗的增長，情況繼續(xù)惡劣至一極限閾值，轉(zhuǎn)到狀態(tài)4；
4.最終防御方案，使用忠實用戶ip白名單、異常訪問ip黑名單策略，其他訪問可慢慢放入，直到系統(tǒng)資源消耗回降至正常水平，轉(zhuǎn)到狀態(tài)1。
上述的防御狀態(tài)機，對于單個攻擊IP高并發(fā)的DDOS，變化到狀態(tài)3時，效果就完全體現(xiàn)出來了，但如果防御狀態(tài)機進行到4狀態(tài)，則有如下兩種可能：
1.站點遭到了攻擊群龐大的、單個IP低并發(fā)的DDOS攻擊；
2.站點突然間有了很多訪問正常的新用戶。
六、建議后續(xù)工作：
保守：站點應(yīng)盡快進行服務(wù)能力升級。
積極：盡所能，追溯攻擊者。
追溯攻擊者：
CC：proxy-forward-from-ip
單個IP高并發(fā)的DDOS：找到訪問異常的、高度可疑的ip列表，exploit，搜集、分析數(shù)據(jù)，因為一個傀儡主機可被二次攻占的概率很大（但不建議這種方法）
單個IP低并發(fā)的DDOS：以前極少訪問被攻擊站點，但是在攻擊發(fā)生時，卻頻繁訪問我們的站點，分析日志得到這一部分ip列表
追溯攻擊者的過程中，snat與web proxy增加了追蹤的難度，如果攻擊者采用多個中繼服務(wù)器的方法，追溯將變得極為困難。
防御者：
1.應(yīng)對當(dāng)前系統(tǒng)了如指掌，如系統(tǒng)最高負載、最高數(shù)據(jù)處理能力，以及系統(tǒng)防御體系的強項與弱點
2.歷史日志的保存、分析
3.對當(dāng)前系統(tǒng)進行嚴格安全審計
4.上報公安相關(guān)部分，努力追溯攻擊者
5.網(wǎng)站，能靜態(tài)，就一定不要動態(tài)，可采取定時從主數(shù)據(jù)庫生成靜態(tài)頁面的方式，對需要訪問主數(shù)據(jù)庫的服務(wù)使用驗證機制。
6.防御者應(yīng)能從全局的角度，迅速及時地發(fā)現(xiàn)系統(tǒng)正在處于什么程度的攻擊、何種攻擊，在平時，應(yīng)該建立起攻擊應(yīng)急策略，規(guī)范化操作，免得在急中犯下低級錯誤
對歷史日志的分析這時將會非常重要，數(shù)據(jù)可視化與統(tǒng)計學(xué)的方法將會很有益處：
1.分析每個頁面的平均訪問頻率
2.對訪問頻率異常的頁面進行詳細分析 分析得到ip-頁面訪問頻率
3.得到對訪問異常頁面的訪問異常ip列表
4.對日志分析得到忠實用戶IP白名單
5.一般一個頁面會關(guān)聯(lián)多個資源，一次對于這樣的頁面訪問往往會同時增加多個資源的訪問數(shù)，而攻擊程序一般不會加載這些它不感興趣的資源，所以，這也是一個非常好的分析突破點
防御思路
因為CC攻擊通過工具軟件發(fā)起，而普通用戶通過瀏覽器訪問，這其中就會有某些區(qū)別。想辦法對這二者作出判斷，選擇性的屏蔽來自機器的流量即可。
初級
普通瀏覽器發(fā)起請求時，除了要訪問的地址以外，Http頭中還會帶有Referer，UserAgent等多項信息。遇到攻擊時可以通過日志查看訪問信息，看攻擊的流量是否有明顯特征，比如固定的Referer或UserAgent，如果能找到特征，就可以直接屏蔽掉了。
中級
如果攻擊者偽造了Referer和UserAgent等信息，那就需要從其他地方入手。攻擊軟件一般來說功能都比較簡單，只有固定的發(fā)包功能，而瀏覽器會完整的支持Http協(xié)議，我們可以利用這一點來進行防御。
首先為每個訪問者定義一個字符串，保存在Cookies中作為Token，必須要帶有正確的Token才可以訪問后端服務(wù)。當(dāng)用戶第一次訪問時，會檢測到用戶的Cookies里面并沒有這個Token，則返回一個302重定向，目標地址為當(dāng)前頁面，同時在返回的Http頭中加入set cookies字段，對Cookies進行設(shè)置，使用戶帶有這個Token。
客戶端如果是一個正常的瀏覽器，那么就會支持http頭中的set cookie和302重定向指令，將帶上正確的Token再次訪問頁面，這時候后臺檢測到正確的Token，就會放行，這之后用戶的Http請求都會帶有這個Token，所以并不會受到阻攔。
客戶端如果是CC軟件，那么一般不會支持這些指令，那么就會一直被攔在最外層，并不會對服務(wù)器內(nèi)部造成壓力。
高級
高級一點的，還可以返回一個網(wǎng)頁，在頁面中嵌入JavaScript來設(shè)置Cookies并跳轉(zhuǎn)，這樣被偽造請求的可能性更小
Token生成算法
Token需要滿足以下幾點要求
1，每個IP地址的Token不同
2， 無法偽造
3， 一致性，即對相同的客戶端，每次生成的Token相同
Token隨IP地址變化是為了防止通過一臺機器獲取Token之后，再通過代理服務(wù)區(qū)進行攻擊。一致性則是為了避免在服務(wù)器端需要存儲已經(jīng)生成的Token。
推薦使用以下算法生成Token，其中Key為服務(wù)器獨有的保密字符串，這個算法生成的Token可以滿足以上這些要求。
Token = Hash( UserAgent + client_ip + key )
本文主要講述了DDoS攻擊之一的CC攻擊工具實現(xiàn)，以及如何防御來自應(yīng)用層的DDoS攻擊的理論總結(jié)。接下來的文章，筆者將會實現(xiàn)一個工作于內(nèi)核態(tài)的、具有黑名單功能的防火墻模塊，以對應(yīng)于上述防御狀態(tài)機中的防火墻單元，它實現(xiàn)了自主地動態(tài)內(nèi)存管理，使用hash表管理ip列表，并可以自定義hash表的modular。
七、 簡易CC攻擊防御策略
確定Web服務(wù)器正在或者曾經(jīng)遭受CC攻擊，那如何進行有效的防范呢?
(1).取消域名綁定
一般cc攻擊都是針對網(wǎng)站的域名進行攻擊，比如我們的網(wǎng)站域名是“www.abc.com”，那么攻擊者就在攻擊工具中設(shè)定攻擊對象為該域名然后實施攻擊。 對于這樣的攻擊我們的措施是取消這個域名的綁定，讓CC攻擊失去目標。
(2).域名欺騙解析
如果發(fā)現(xiàn)針對域名的CC攻擊，我們可以把被攻擊的域名解析到127.0.0.1這個地址上。我們知道127.0.0.1是本地回環(huán)IP是用來進行網(wǎng)絡(luò)測試的，如果把被攻擊的域名解析到這個IP上，就可以實現(xiàn)攻擊者自己攻擊自己的目的，這樣他再多的肉雞或者代理也會宕機，讓其自作自受。
(3).更改Web端口
一般情況下Web服務(wù)器通過80端口對外提供服務(wù)，因此攻擊者實施攻擊就以默認的80端口進行攻擊，所以，我們可以修改Web端口達到防CC攻擊的目的。運行IIS管理器，定位到相應(yīng)站點，打開站點“屬性”面板，在“網(wǎng)站標識”下有個TCP端口默認為80，我們修改為其他的端口就可以了。
(4).屏蔽IP
我們通過命令或在查看日志發(fā)現(xiàn)了CC攻擊的源IP，就可以在防火墻中設(shè)置屏蔽該IP對Web站點的訪問，從而達到防范攻擊的目的。
