當(dāng)前位置：新聞中心云主機(jī)專(zhuān)題 CC攻擊原理及防范方法

07-022009

觀(guān)點(diǎn)

云主機(jī)專(zhuān)題

CC攻擊原理及防范方法

2009-07-02 云主機(jī)專(zhuān)題

一、 CC攻擊的原理：

CC攻擊的原理就是攻擊者控制某些主機(jī)不停地發(fā)大量數(shù)據(jù)包給對(duì)方服務(wù)器造成服務(wù)器資源耗盡，一直到宕機(jī)崩潰。CC主要是用來(lái)消耗服務(wù)器資源的，每個(gè)人都有這樣的體驗(yàn)：當(dāng)一個(gè)網(wǎng)頁(yè)訪(fǎng)問(wèn)的人數(shù)特別多的時(shí)候，打開(kāi)網(wǎng)頁(yè)就慢了，CC就是模擬多個(gè)用戶(hù)(多少線(xiàn)程就是多少用戶(hù))不停地進(jìn)行訪(fǎng)問(wèn)那些需要大量數(shù)據(jù)操作(就是需要大量CPU時(shí)間)的頁(yè)面，造成服務(wù)器資源的浪費(fèi)，CPU長(zhǎng)時(shí)間處于100%，永遠(yuǎn)都有處理不完的連接直至就網(wǎng)絡(luò)擁塞，正常的訪(fǎng)問(wèn)被中止。

二、CC攻擊的種類(lèi)：

CC攻擊的種類(lèi)有三種，直接攻擊，代理攻擊，僵尸網(wǎng)絡(luò)攻擊，直接攻擊主要針對(duì)有重要缺陷的 WEB 應(yīng)用程序，一般說(shuō)來(lái)是程序?qū)懙挠袉?wèn)題的時(shí)候才會(huì)出現(xiàn)這種情況，比較少見(jiàn)。僵尸網(wǎng)絡(luò)攻擊有點(diǎn)類(lèi)似于 DDOS 攻擊了，從 WEB 應(yīng)用程序?qū)用嫔弦呀?jīng)無(wú)法防御，所以代理攻擊是CC 攻擊者一般會(huì)操作一批代理服務(wù)器，比方說(shuō) 100 個(gè)代理，然后每個(gè)代理同時(shí)發(fā)出 10 個(gè)請(qǐng)求，這樣 WEB 服務(wù)器同時(shí)收到 1000 個(gè)并發(fā)請(qǐng)求的，并且在發(fā)出請(qǐng)求后，立刻斷掉與代理的連接，避免代理返回的數(shù)據(jù)將本身的帶寬堵死，而不能發(fā)動(dòng)再次請(qǐng)求，這時(shí) WEB 服務(wù)器會(huì)將響應(yīng)這些請(qǐng)求的進(jìn)程進(jìn)行隊(duì)列，數(shù)據(jù)庫(kù)服務(wù)器也同樣如此，這樣一來(lái)，正常請(qǐng)求將會(huì)被排在很后被處理，就象本來(lái)你去食堂吃飯時(shí)，一般只有不到十個(gè)人在排隊(duì)，今天前面卻插了一千個(gè)人，那么輪到你的機(jī)會(huì)就很小很小了，這時(shí)就出現(xiàn)頁(yè)面打開(kāi)極其緩慢或者白屏。

三、CC攻擊與DDOS的區(qū)別

1) 什么是DDoS攻擊？

DDoS攻擊就是分布式的拒絕服務(wù)攻擊，DDoS攻擊手段是在傳統(tǒng)的DoS攻擊基礎(chǔ)之上產(chǎn)生的一類(lèi)攻擊方式。單一的DoS攻擊一般是采用一對(duì)一方式的，隨著計(jì)算機(jī)與網(wǎng)絡(luò)技術(shù)的發(fā)展，DoS攻擊的困難程度加大了。于是就產(chǎn)生了DDoS攻擊，它的原理就很簡(jiǎn)單：計(jì)算機(jī)與網(wǎng)絡(luò)的處理能力加大了10倍，用一臺(tái)攻擊機(jī)來(lái)攻擊不再能起作用，那么DDoS就是利用更多的傀儡機(jī)來(lái)發(fā)起進(jìn)攻，以比從前更大的規(guī)模來(lái)進(jìn)攻受害者。常用的DDoS軟件有：LOIC。

在這里補(bǔ)充兩點(diǎn)：第一就是DDOS攻擊不僅能攻擊計(jì)算機(jī)，還能攻擊路由器，因?yàn)槁酚善魇且慌_(tái)特殊類(lèi)型的計(jì)算機(jī)；第二是網(wǎng)速?zèng)Q定攻擊的好和快，比如說(shuō)，如果你一個(gè)被限制網(wǎng)速的環(huán)境下，它們的攻擊效果不是很明顯，但是快的網(wǎng)速相比之下更加具有攻擊效果。

2)什么是CC攻擊？

3)兩者區(qū)別

DDoS是針對(duì)IP的攻擊，而CC攻擊的是服務(wù)器資源。

四、CC攻擊的變異品種慢速攻擊

1)什么是慢速攻擊

一說(shuō)起慢速攻擊，就要談?wù)勊某擅麣v史了。HTTP Post慢速DoS攻擊第一次在技術(shù)社區(qū)被正式披露是2012年的OWASP大會(huì)上，由Wong Onn Chee 和 Tom Brennan共同演示了使用這一技術(shù)攻擊的威力。

這個(gè)攻擊的基本原理如下：對(duì)任何一個(gè)開(kāi)放了HTTP訪(fǎng)問(wèn)的服務(wù)器HTTP服務(wù)器，先建立了一個(gè)連接，指定一個(gè)比較大的content-length，然后以非常低的速度發(fā)包，比如1-10s發(fā)一個(gè)字節(jié)，然后維持住這個(gè)連接不斷開(kāi)。如果客戶(hù)端持續(xù)建立這樣的連接，那么服務(wù)器上可用的連接將一點(diǎn)一點(diǎn)被占滿(mǎn)，從而導(dǎo)致拒絕服務(wù)。

和CC攻擊一樣，只要Web服務(wù)器開(kāi)放了Web服務(wù)，那么它就可以是一個(gè)靶子，HTTP協(xié)議在接收到request之前是不對(duì)請(qǐng)求內(nèi)容作校驗(yàn)的，所以即使你的Web應(yīng)用沒(méi)有可用的form表單，這個(gè)攻擊一樣有效。

在客戶(hù)端以單線(xiàn)程方式建立較大數(shù)量的無(wú)用連接，并保持持續(xù)發(fā)包的代價(jià)非常的低廉。實(shí)際試驗(yàn)中一臺(tái)普通PC可以建立的連接在3000個(gè)以上。這對(duì)一臺(tái)普通的Web server，將是致命的打擊。更不用說(shuō)結(jié)合肉雞群做分布式DoS了。

鑒于此攻擊簡(jiǎn)單的利用程度、拒絕服務(wù)的后果、帶有逃逸特性的攻擊方式，這類(lèi)攻擊一炮而紅，成為眾多攻擊者的研究和利用對(duì)象。

2)慢速攻擊的分類(lèi)

發(fā)展到今天，慢速攻擊也多種多樣，其種類(lèi)可分為以下幾種：

Slow headers：Web應(yīng)用在處理HTTP請(qǐng)求之前都要先接收完所有的HTTP頭部，因?yàn)镠TTP頭部中包含了一些Web應(yīng)用可能用到的重要的信息。攻擊者利用這點(diǎn)，發(fā)起一個(gè)HTTP請(qǐng)求，一直不停的發(fā)送HTTP頭部，消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見(jiàn)，攻擊客戶(hù)端與服務(wù)器建立TCP連接后，每30秒才向服務(wù)器發(fā)送一個(gè)HTTP頭部，而Web服務(wù)器再?zèng)]接收到2個(gè)連續(xù)的\r\n時(shí)，會(huì)認(rèn)為客戶(hù)端沒(méi)有發(fā)送完頭部，而持續(xù)的等等客戶(hù)端發(fā)送數(shù)據(jù)。

Slow body：攻擊者發(fā)送一個(gè)HTTP POST請(qǐng)求，該請(qǐng)求的Content-Length頭部值很大，使得Web服務(wù)器或代理認(rèn)為客戶(hù)端要發(fā)送很大的數(shù)據(jù)。服務(wù)器會(huì)保持連接準(zhǔn)備接收數(shù)據(jù)，但攻擊客戶(hù)端每次只發(fā)送很少量的數(shù)據(jù)，使該連接一直保持存活，消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見(jiàn)，攻擊客戶(hù)端與服務(wù)器建立TCP連接后，發(fā)送了完整的HTTP頭部，POST方法帶有較大的Content-Length，然后每10s發(fā)送一次隨機(jī)的參數(shù)。服務(wù)器因?yàn)闆](méi)有接收到相應(yīng)Content-Length的body，而持續(xù)的等待客戶(hù)端發(fā)送數(shù)據(jù)。

Slow read：客戶(hù)端與服務(wù)器建立連接并發(fā)送了一個(gè)HTTP請(qǐng)求，客戶(hù)端發(fā)送完整的請(qǐng)求給服務(wù)器端，然后一直保持這個(gè)連接，以很低的速度讀取Response，比如很長(zhǎng)一段時(shí)間客戶(hù)端不讀取任何數(shù)據(jù)，通過(guò)發(fā)送Zero Window到服務(wù)器，讓服務(wù)器誤以為客戶(hù)端很忙，直到連接快超時(shí)前才讀取一個(gè)字節(jié)，以消耗服務(wù)器的連接和內(nèi)存資源。抓包數(shù)據(jù)可見(jiàn)，客戶(hù)端把數(shù)據(jù)發(fā)給服務(wù)器后，服務(wù)器發(fā)送響應(yīng)時(shí)，收到了客戶(hù)端的ZeroWindow提示（表示自己沒(méi)有緩沖區(qū)用于接收數(shù)據(jù)），服務(wù)器不得不持續(xù)的向客戶(hù)端發(fā)出ZeroWindowProbe包，詢(xún)問(wèn)客戶(hù)端是否可以接收數(shù)據(jù)。

使用較多的慢速攻擊工具有：Slowhttptest和Slowloris。

3)哪些服務(wù)器易被慢速攻擊

慢速攻擊主要利用的是thread-based架構(gòu)的服務(wù)器的特性，這種服務(wù)器會(huì)為每個(gè)新連接打開(kāi)一個(gè)線(xiàn)程，它會(huì)等待接收完整個(gè)HTTP頭部才會(huì)釋放連接。比如Apache會(huì)有一個(gè)超時(shí)時(shí)間來(lái)等待這種不完全連接（默認(rèn)是300s），但是一旦接收到客戶(hù)端發(fā)來(lái)的數(shù)據(jù)，這個(gè)超時(shí)時(shí)間會(huì)被重置。正是因?yàn)檫@樣，攻擊者可以很容易保持住一個(gè)連接，因?yàn)楣粽咧恍枰诩磳⒊瑫r(shí)之前發(fā)送一個(gè)字符，便可以延長(zhǎng)超時(shí)時(shí)間。而客戶(hù)端只需要很少的資源，便可以打開(kāi)多個(gè)連接，進(jìn)而占用服務(wù)器很多的資源。

經(jīng)驗(yàn)證，Apache、httpd采用thread-based架構(gòu)，很容易遭受慢速攻擊。而另外一種event-based架構(gòu)的服務(wù)器，比如nginx和lighttpd則不容易遭受慢速攻擊。

4)如何防護(hù)慢速攻擊

Apache服務(wù)器現(xiàn)在使用較多的有三種簡(jiǎn)單防護(hù)方式。

mod_reqtimeout：Apache2.2.15后，該模塊已經(jīng)被默認(rèn)包含，用戶(hù)可配置從一個(gè)客戶(hù)端接收HTTP頭部和HTTPbody的超時(shí)時(shí)間和最小速率。如果一個(gè)客戶(hù)端不能在配置時(shí)間內(nèi)發(fā)送完頭部或body數(shù)據(jù)，服務(wù)器會(huì)返回一個(gè)408REQUEST TIME OUT錯(cuò)誤。配置文件如下：

< IfModule mod_reqtimeout.c > RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500 < /IfModule >

mod_qos：Apache的一個(gè)服務(wù)質(zhì)量控制模塊，用戶(hù)可配置各種不同粒度的HTTP請(qǐng)求閾值，配置文件如下：

< 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：一個(gè)開(kāi)源的WAF模塊，有專(zhuān)門(mén)針對(duì)慢速攻擊防護(hù)的規(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è)備針對(duì)CC攻擊，主要通過(guò)閾值的方式來(lái)進(jìn)行防護(hù)，某一個(gè)客戶(hù)在一定的周期內(nèi)，請(qǐng)求訪(fǎng)問(wèn)量過(guò)大，超過(guò)了閾值，清洗設(shè)備通過(guò)返回驗(yàn)證碼或者JS代碼的方式。這種防護(hù)方式的依據(jù)是，攻擊者們使用肉雞上的DDoS工具模擬大量http request，這種工具一般不會(huì)解析服務(wù)端返回?cái)?shù)據(jù)，更不會(huì)解析JS之類(lèi)的代碼。因此當(dāng)清洗設(shè)備截獲到HTTP請(qǐng)求時(shí)，返回一段特殊JavaScript代碼，正常用戶(hù)的瀏覽器會(huì)處理并正常跳轉(zhuǎn)不影響使用，而攻擊程序會(huì)攻擊到空處。

而對(duì)于慢速攻擊來(lái)說(shuō)，通過(guò)返回驗(yàn)證碼或者JS代碼的方式依然能達(dá)到部分效果。但是根據(jù)慢速攻擊的特征，可以輔助以下幾種防護(hù)方式：1、周期內(nèi)統(tǒng)計(jì)報(bào)文數(shù)量。一個(gè)TCP連接，HTTP請(qǐng)求的報(bào)文中，報(bào)文過(guò)多或者報(bào)文過(guò)少都是有問(wèn)題的，如果一個(gè)周期內(nèi)報(bào)文數(shù)量非常少，那么它就可能是慢速攻擊；如果一個(gè)周期內(nèi)報(bào)文數(shù)量非常多，那么它就可能是一個(gè)CC攻擊。2、限制HTTP請(qǐng)求頭的最大許可時(shí)間。超過(guò)最大許可時(shí)間，如果數(shù)據(jù)還沒(méi)有傳輸完成，那么它就有可能是一個(gè)慢速攻擊。

簡(jiǎn)單的Nginx防CC方式

實(shí)驗(yàn)

Nginx配置

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
        #限制每ip每秒不超過(guò)20個(gè)請(qǐng)求，漏桶數(shù)burst為5
        #brust的意思就是，如果第1秒、2,3,4秒請(qǐng)求為19個(gè)，
        #第5秒的請(qǐng)求為25個(gè)是被允許的。
        #但是如果你第1秒就25個(gè)請(qǐng)求，第2秒超過(guò)20的請(qǐng)求返回503錯(cuò)誤。
        #nodelay，如果不設(shè)置該選項(xiàng)，嚴(yán)格使用平均速率限制請(qǐng)求數(shù)，
        #第1秒25個(gè)請(qǐng)求時(shí)，5個(gè)請(qǐng)求放到第2秒執(zhí)行，
        #設(shè)置nodelay，25個(gè)請(qǐng)求將在第1秒執(zhí)行。
        limit_req   zone=one  burst=1 nodelay;
    }
}

上面樣本的配置是什么意思呢？

$binary_remote_addr 表示：客戶(hù)端IP地址
zone 表示漏桶的名字
rate 表示nginx處理請(qǐng)求的速度有多快
burst 表示峰值
nodelay 表示是否延遲處理請(qǐng)求，還是直接503返回給客戶(hù)端，如果超出rate設(shè)置的情況下。

詳細(xì)的可以參考官方說(shuō)明文檔：

模擬請(qǐng)求

這里我們需要Apache Benchmark這個(gè)小工具來(lái)生成請(qǐng)求

//1個(gè)用戶(hù)持續(xù)100s的時(shí)間向服務(wù)器發(fā)送請(qǐng)求 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測(cè)試結(jié)果如下所示：

數(shù)據(jù)	成功的請(qǐng)求數(shù)	失敗的請(qǐng)求數(shù)	請(qǐng)求時(shí)間	每秒成功的請(qǐng)求數(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

以上失敗的請(qǐng)求在Nginx上生成的錯(cuò)誤日志如下顯示

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測(cè)試中如果是失敗的請(qǐng)求，nginx的limit_req模塊會(huì)統(tǒng)一返回503給客戶(hù)端，瀏覽器上面顯示的是這個(gè)樣子的。

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ù)	成功的請(qǐng)求數(shù)	失敗的請(qǐng)求數(shù)	請(qǐng)求時(shí)間	每秒成功的請(qǐng)求數(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ù)來(lái)看，提高了burst值，明顯nginx成功的請(qǐng)求數(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ù)	成功的請(qǐng)求數(shù)	請(qǐng)求時(shí)間	每秒成功的請(qǐng)求數(shù)
1	96	100.223	1.09
2	98	100.238	0.97
3	100	100.761	0.99
4	96	100.074	0.95
5	97	100.021	0.96
平均	97.4	100.263	0.97

從這里的數(shù)據(jù)可以看到將nodelay的參數(shù)去掉的話(huà)，成功的請(qǐng)求數(shù)在100左右而失敗的請(qǐng)求數(shù)變成0了，為什么呢？

有nodelay參數(shù)的時(shí)候，nginx正常是及時(shí)處理當(dāng)前的請(qǐng)求的并響應(yīng)數(shù)據(jù)給客戶(hù)端，但是如果超過(guò)limit_req_module的限制，那么會(huì)統(tǒng)一返回503給客戶(hù)端。
無(wú)nodelay參數(shù)的時(shí)候，nginx正常是及時(shí)處理當(dāng)前的請(qǐng)求的并響應(yīng)數(shù)據(jù)給客戶(hù)端，但是如果超過(guò)limit_req_module的限制，那么會(huì)將此此請(qǐng)求緩存「就先這么理解」起來(lái)稍后再處理，所以也就不會(huì)出現(xiàn)大量的失敗請(qǐng)求數(shù)了。

存在的問(wèn)題

雖然用limit_req_module可以一定上的防止CC攻擊，但是有誤殺概率；國(guó)內(nèi)寬帶用戶(hù)的IP地址已經(jīng)大量?jī)?nèi)網(wǎng)化，幾百人共享一個(gè)IP的可能性是很大的。

五、應(yīng)用層DDoS的防御理論：

問(wèn)題模型描述：

每一個(gè)頁(yè)面，都有其資源消耗權(quán)重，靜態(tài)資源，權(quán)重較低，動(dòng)態(tài)資源，權(quán)重較高。對(duì)于用戶(hù)訪(fǎng)問(wèn)，有如下：

用戶(hù)資源使用頻率=使用的服務(wù)器總資源量/s

命題一：對(duì)于正常訪(fǎng)問(wèn)的用戶(hù)，資源使用頻率必定位于一個(gè)合理的范圍，當(dāng)然會(huì)存在大量正常用戶(hù)共享ip的情況，這就需要日常用戶(hù)訪(fǎng)問(wèn)統(tǒng)計(jì)，以得到忠實(shí)用戶(hù)ip白名單。

命題二：資源使用頻率持續(xù)異常的，可斷定為訪(fǎng)問(wèn)異常的用戶(hù)。

防御體系狀態(tài)機(jī)：

1.在系統(tǒng)各項(xiàng)資源非常寬裕時(shí)，向所有ip提供服務(wù)，每隔一段時(shí)間釋放一部分臨時(shí)黑名單中的ip成員；

2.在系統(tǒng)資源消耗達(dá)到某一閾值時(shí)，降低Syn包接受速率，循環(huán)：分析最近時(shí)間的日志，并將訪(fǎng)問(wèn)異常的ip加入臨時(shí)黑名單；

3.若系統(tǒng)資源消耗慢慢回降至正常水平，則恢復(fù)Syn包接受速率，轉(zhuǎn)到狀態(tài)1；若目前策略并未有效地控制住系統(tǒng)資源消耗的增長(zhǎng)，情況繼續(xù)惡劣至一極限閾值，轉(zhuǎn)到狀態(tài)4；

4.最終防御方案，使用忠實(shí)用戶(hù)ip白名單、異常訪(fǎng)問(wèn)ip黑名單策略，其他訪(fǎng)問(wèn)可慢慢放入，直到系統(tǒng)資源消耗回降至正常水平，轉(zhuǎn)到狀態(tài)1。

上述的防御狀態(tài)機(jī)，對(duì)于單個(gè)攻擊IP高并發(fā)的DDOS，變化到狀態(tài)3時(shí)，效果就完全體現(xiàn)出來(lái)了，但如果防御狀態(tài)機(jī)進(jìn)行到4狀態(tài)，則有如下兩種可能：

1.站點(diǎn)遭到了攻擊群龐大的、單個(gè)IP低并發(fā)的DDOS攻擊；

2.站點(diǎn)突然間有了很多訪(fǎng)問(wèn)正常的新用戶(hù)。

六、建議后續(xù)工作：

保守：站點(diǎn)應(yīng)盡快進(jìn)行服務(wù)能力升級(jí)。

積極：盡所能，追溯攻擊者。

追溯攻擊者：

CC：proxy-forward-from-ip

單個(gè)IP高并發(fā)的DDOS：找到訪(fǎng)問(wèn)異常的、高度可疑的ip列表，exploit，搜集、分析數(shù)據(jù)，因?yàn)橐粋€(gè)傀儡主機(jī)可被二次攻占的概率很大（但不建議這種方法）

單個(gè)IP低并發(fā)的DDOS：以前極少訪(fǎng)問(wèn)被攻擊站點(diǎn)，但是在攻擊發(fā)生時(shí)，卻頻繁訪(fǎng)問(wèn)我們的站點(diǎn)，分析日志得到這一部分ip列表

追溯攻擊者的過(guò)程中，snat與web proxy增加了追蹤的難度，如果攻擊者采用多個(gè)中繼服務(wù)器的方法，追溯將變得極為困難。

防御者：

1.應(yīng)對(duì)當(dāng)前系統(tǒng)了如指掌，如系統(tǒng)最高負(fù)載、最高數(shù)據(jù)處理能力，以及系統(tǒng)防御體系的強(qiáng)項(xiàng)與弱點(diǎn)

2.歷史日志的保存、分析

3.對(duì)當(dāng)前系統(tǒng)進(jìn)行嚴(yán)格安全審計(jì)

4.上報(bào)公安相關(guān)部分，努力追溯攻擊者

5.網(wǎng)站，能靜態(tài)，就一定不要?jiǎng)討B(tài)，可采取定時(shí)從主數(shù)據(jù)庫(kù)生成靜態(tài)頁(yè)面的方式，對(duì)需要訪(fǎng)問(wèn)主數(shù)據(jù)庫(kù)的服務(wù)使用驗(yàn)證機(jī)制。

6.防御者應(yīng)能從全局的角度，迅速及時(shí)地發(fā)現(xiàn)系統(tǒng)正在處于什么程度的攻擊、何種攻擊，在平時(shí)，應(yīng)該建立起攻擊應(yīng)急策略，規(guī)范化操作，免得在急中犯下低級(jí)錯(cuò)誤

對(duì)歷史日志的分析這時(shí)將會(huì)非常重要，數(shù)據(jù)可視化與統(tǒng)計(jì)學(xué)的方法將會(huì)很有益處：

1.分析每個(gè)頁(yè)面的平均訪(fǎng)問(wèn)頻率

2.對(duì)訪(fǎng)問(wèn)頻率異常的頁(yè)面進(jìn)行詳細(xì)分析分析得到ip-頁(yè)面訪(fǎng)問(wèn)頻率

3.得到對(duì)訪(fǎng)問(wèn)異常頁(yè)面的訪(fǎng)問(wèn)異常ip列表

4.對(duì)日志分析得到忠實(shí)用戶(hù)IP白名單

5.一般一個(gè)頁(yè)面會(huì)關(guān)聯(lián)多個(gè)資源，一次對(duì)于這樣的頁(yè)面訪(fǎng)問(wèn)往往會(huì)同時(shí)增加多個(gè)資源的訪(fǎng)問(wèn)數(shù)，而攻擊程序一般不會(huì)加載這些它不感興趣的資源，所以，這也是一個(gè)非常好的分析突破點(diǎn)

防御思路

因?yàn)镃C攻擊通過(guò)工具軟件發(fā)起，而普通用戶(hù)通過(guò)瀏覽器訪(fǎng)問(wèn)，這其中就會(huì)有某些區(qū)別。想辦法對(duì)這二者作出判斷，選擇性的屏蔽來(lái)自機(jī)器的流量即可。

初級(jí)

普通瀏覽器發(fā)起請(qǐng)求時(shí)，除了要訪(fǎng)問(wèn)的地址以外，Http頭中還會(huì)帶有Referer，UserAgent等多項(xiàng)信息。遇到攻擊時(shí)可以通過(guò)日志查看訪(fǎng)問(wèn)信息，看攻擊的流量是否有明顯特征，比如固定的Referer或UserAgent，如果能找到特征，就可以直接屏蔽掉了。

中級(jí)

如果攻擊者偽造了Referer和UserAgent等信息，那就需要從其他地方入手。攻擊軟件一般來(lái)說(shuō)功能都比較簡(jiǎn)單，只有固定的發(fā)包功能，而瀏覽器會(huì)完整的支持Http協(xié)議，我們可以利用這一點(diǎn)來(lái)進(jìn)行防御。

首先為每個(gè)訪(fǎng)問(wèn)者定義一個(gè)字符串，保存在Cookies中作為T(mén)oken，必須要帶有正確的Token才可以訪(fǎng)問(wèn)后端服務(wù)。當(dāng)用戶(hù)第一次訪(fǎng)問(wèn)時(shí)，會(huì)檢測(cè)到用戶(hù)的Cookies里面并沒(méi)有這個(gè)Token，則返回一個(gè)302重定向，目標(biāo)地址為當(dāng)前頁(yè)面，同時(shí)在返回的Http頭中加入set cookies字段，對(duì)Cookies進(jìn)行設(shè)置，使用戶(hù)帶有這個(gè)Token。

客戶(hù)端如果是一個(gè)正常的瀏覽器，那么就會(huì)支持http頭中的set cookie和302重定向指令，將帶上正確的Token再次訪(fǎng)問(wèn)頁(yè)面，這時(shí)候后臺(tái)檢測(cè)到正確的Token，就會(huì)放行，這之后用戶(hù)的Http請(qǐng)求都會(huì)帶有這個(gè)Token，所以并不會(huì)受到阻攔。

客戶(hù)端如果是CC軟件，那么一般不會(huì)支持這些指令，那么就會(huì)一直被攔在最外層，并不會(huì)對(duì)服務(wù)器內(nèi)部造成壓力。

高級(jí)

高級(jí)一點(diǎn)的，還可以返回一個(gè)網(wǎng)頁(yè)，在頁(yè)面中嵌入JavaScript來(lái)設(shè)置Cookies并跳轉(zhuǎn)，這樣被偽造請(qǐng)求的可能性更小

Token生成算法

Token需要滿(mǎn)足以下幾點(diǎn)要求

1，每個(gè)IP地址的Token不同

2，無(wú)法偽造

3，一致性，即對(duì)相同的客戶(hù)端，每次生成的Token相同

Token隨IP地址變化是為了防止通過(guò)一臺(tái)機(jī)器獲取Token之后，再通過(guò)代理服務(wù)區(qū)進(jìn)行攻擊。一致性則是為了避免在服務(wù)器端需要存儲(chǔ)已經(jīng)生成的Token。

推薦使用以下算法生成Token，其中Key為服務(wù)器獨(dú)有的保密字符串，這個(gè)算法生成的Token可以滿(mǎn)足以上這些要求。

Token = Hash( UserAgent + client_ip + key )

本文主要講述了DDoS攻擊之一的CC攻擊工具實(shí)現(xiàn)，以及如何防御來(lái)自應(yīng)用層的DDoS攻擊的理論總結(jié)。接下來(lái)的文章，筆者將會(huì)實(shí)現(xiàn)一個(gè)工作于內(nèi)核態(tài)的、具有黑名單功能的防火墻模塊，以對(duì)應(yīng)于上述防御狀態(tài)機(jī)中的防火墻單元，它實(shí)現(xiàn)了自主地動(dòng)態(tài)內(nèi)存管理，使用hash表管理ip列表，并可以自定義hash表的modular。

七、簡(jiǎn)易CC攻擊防御策略

確定Web服務(wù)器正在或者曾經(jīng)遭受CC攻擊，那如何進(jìn)行有效的防范呢?

(1).取消域名綁定
一般cc攻擊都是針對(duì)網(wǎng)站的域名進(jìn)行攻擊，比如我們的網(wǎng)站域名是“www.abc.com”，那么攻擊者就在攻擊工具中設(shè)定攻擊對(duì)象為該域名然后實(shí)施攻擊。對(duì)于這樣的攻擊我們的措施是取消這個(gè)域名的綁定，讓CC攻擊失去目標(biāo)。

(2).域名欺騙解析
如果發(fā)現(xiàn)針對(duì)域名的CC攻擊，我們可以把被攻擊的域名解析到127.0.0.1這個(gè)地址上。我們知道127.0.0.1是本地回環(huán)IP是用來(lái)進(jìn)行網(wǎng)絡(luò)測(cè)試的，如果把被攻擊的域名解析到這個(gè)IP上，就可以實(shí)現(xiàn)攻擊者自己攻擊自己的目的，這樣他再多的肉雞或者代理也會(huì)宕機(jī)，讓其自作自受。

(3).更改Web端口
一般情況下Web服務(wù)器通過(guò)80端口對(duì)外提供服務(wù)，因此攻擊者實(shí)施攻擊就以默認(rèn)的80端口進(jìn)行攻擊，所以，我們可以修改Web端口達(dá)到防CC攻擊的目的。運(yùn)行IIS管理器，定位到相應(yīng)站點(diǎn)，打開(kāi)站點(diǎn)“屬性”面板，在“網(wǎng)站標(biāo)識(shí)”下有個(gè)TCP端口默認(rèn)為80，我們修改為其他的端口就可以了。

(4).屏蔽IP
我們通過(guò)命令或在查看日志發(fā)現(xiàn)了CC攻擊的源IP，就可以在防火墻中設(shè)置屏蔽該IP對(duì)Web站點(diǎn)的訪(fǎng)問(wèn)，從而達(dá)到防范攻擊的目的。

上一篇：一文讀懂IPv6是什么？返回觀(guān)點(diǎn)列表下一篇：淺談DDoS攻擊和CC攻擊的區(qū)別

本文標(biāo)簽：

本文地址： http://www.bmwdream.cn/a/356.html

案例

網(wǎng)站建設(shè)

應(yīng)用開(kāi)發(fā)

觀(guān)點(diǎn)

CC攻擊原理及防范方法

一、 CC攻擊的原理：

二、CC攻擊的種類(lèi)：

三、CC攻擊與DDOS的區(qū)別

四、CC攻擊的變異品種慢速攻擊

實(shí)驗(yàn)

Nginx配置

模擬請(qǐng)求

Nginx配置樣本一

Nginx配置樣本二

Nginx配置樣本三

存在的問(wèn)題

五、應(yīng)用層DDoS的防御理論：

六、建議后續(xù)工作：

七、簡(jiǎn)易CC攻擊防御策略

相關(guān)專(zhuān)題

開(kāi)始您的數(shù)字化品牌體驗(yàn)！ 0571-85815193 期待您的來(lái)電！

企業(yè)微信

電話(huà)

浙江·杭州

郵箱

我們正使用 cookies 來(lái)改善您的訪(fǎng)問(wèn)體驗(yàn)

Cookie 偏好

管理cookie偏好

基本 cookies

性能 cookies

功能性 cookies

定位 Cookies

我們正使用 cookies 來(lái)改善您的訪(fǎng)問(wèn)體驗(yàn)

案例

網(wǎng)站建設(shè)

應(yīng)用開(kāi)發(fā)

觀(guān)點(diǎn)

CC攻擊原理及防范方法

一、 CC攻擊的原理：

二、CC攻擊的種類(lèi)：

三、CC攻擊與DDOS的區(qū)別

四、CC攻擊的變異品種 慢速攻擊

實(shí)驗(yàn)

Nginx配置

模擬請(qǐng)求

Nginx配置樣本一

Nginx配置樣本二

Nginx配置樣本三

存在的問(wèn)題

五、應(yīng)用層DDoS的防御理論：

六、建議后續(xù)工作：

七、 簡(jiǎn)易CC攻擊防御策略

相關(guān)專(zhuān)題

開(kāi)始您的數(shù)字化品牌體驗(yàn)！ 0571-85815193 期待您的來(lái)電！

企業(yè)微信

電話(huà)

浙江·杭州

郵箱

我們正使用 cookies 來(lái)改善您的訪(fǎng)問(wèn)體驗(yàn)

Cookie 偏好

管理cookie偏好

基本 cookies

性能 cookies

功能性 cookies

定位 Cookies

我們正使用 cookies 來(lái)改善您的訪(fǎng)問(wèn)體驗(yàn)

一、 CC攻擊的原理：

三、CC攻擊與DDOS的區(qū)別

四、CC攻擊的變異品種慢速攻擊

五、應(yīng)用層DDoS的防御理論：

六、建議后續(xù)工作：

七、簡(jiǎn)易CC攻擊防御策略

開(kāi)始您的數(shù)字化品牌體驗(yàn)！ 0571-85815193 期待您的來(lái)電！