CC攻擊原理及防範方法和如何防範CC攻擊
1、 CC攻擊的原理：
CC攻擊的原理就是攻擊者控制某些主機不停地發大量數據包給對方服務器形成服務器資源耗盡，一直到宕機崩潰。CC主要是用來消耗服務器資源的，每一個人都有這樣的體驗：當一個網頁訪問的人數特別多的時候，打開網頁就慢了，CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行訪問那些須要大量數據操做(就是須要大量CPU時間)的頁面，形成服務器資源的浪費，CPU長時間處於100%，永遠都有處理不完的鏈接直至就網絡擁塞，正常的訪問被停止。html
2、CC攻擊的種類：
CC攻擊的種類有三種，直接攻擊，代理攻擊，僵屍網絡攻擊，直接攻擊主要針對有重要缺陷的 WEB 應用程序，通常說來是程序寫的有問題的時候纔會出現這種狀況，比較少見。僵屍網絡攻擊有點相似於 DDOS 攻擊了，從 WEB 應用程序層面上已經沒法防護，因此代理攻擊是CC 攻擊者通常會操做一批代理服務器，比方說 100 個代理，而後每一個代理同時發出 10 個請求，這樣 WEB 服務器同時收到 1000 個併發請求的，而且在發出請求後，馬上斷掉與代理的鏈接，避免代理返回的數據將自己的帶寬堵死，而不能發動再次請求，這時 WEB 服務器會將響應這些請求的進程進行隊列，數據庫服務器也一樣如此，這樣一來，正常請求將會被排在很後被處理，就象原本你去食堂吃飯時，通常只有不到十我的在排隊，今天前面卻插了一千我的，那麼輪到你的機會就很小很小了，這時就出現頁面打開極其緩慢或者白屏。node
3、CC攻擊與DDOS的區別
1) 什麼是DDoS攻擊？nginx
DDoS攻擊就是分佈式的拒絕服務攻擊，DDoS攻擊手段是在傳統的DoS攻擊基礎之上產生的一類攻擊方式。單一的DoS攻擊通常是採用一對一方式的，隨着計算機與網絡技術的發展，DoS攻擊的困難程度加大了。因而就產生了DDoS攻擊，它的原理就很簡單：計算機與網絡的處理能力加大了10倍，用一臺攻擊機來攻擊再也不能起做用，那麼DDoS就是利用更多的傀儡機來發起進攻，以比從前更大的規模來進攻受害者。經常使用的DDoS軟件有：LOIC。git
在這裏補充兩點：第一就是DDOS攻擊不只能攻擊計算機，還能攻擊路由器，由於路由器是一臺特殊類型的計算機；第二是網速決定攻擊的好和快，好比說，若是你一個被限制網速的環境下，它們的攻擊效果不是很明顯，可是快的網速相比之下更加具備攻擊效果。github
2)什麼是CC攻擊？web
CC攻擊全稱Challenge Collapsar，中文意思是挑戰黑洞，由於之前的抵抗DDoS攻擊的安全設備叫黑洞，顧名思義挑戰黑洞就是說黑洞拿這種攻擊沒辦法算法
3)二者區別數據庫
DDoS是針對IP的攻擊，而CC攻擊的是服務器資源。後端
4、CC攻擊的變異品種 慢速攻擊
1)什麼是慢速攻擊瀏覽器
一提及慢速攻擊，就要談談它的成名歷史了。HTTP Post慢速DoS攻擊第一次在技術社區被正式披露是2012年的OWASP大會上，由Wong Onn Chee 和 Tom Brennan共同演示了使用這一技術攻擊的威力。
這個攻擊的基本原理以下：對任何一個開放了HTTP訪問的服務器HTTP服務器，先創建了一個鏈接，指定一個比較大的content-length，而後以很是低的速度發包，好比1-10s發一個字節，而後維持住這個鏈接不斷開。若是客戶端持續創建這樣的鏈接，那麼服務器上可用的鏈接將一點一點被佔滿，從而致使拒絕服務。
和CC攻擊同樣，只要Web服務器開放了Web服務，那麼它就能夠是一個靶子，HTTP協議在接收到request以前是不對請求內容做校驗的，因此即便你的Web應用沒有可用的form表單，這個攻擊同樣有效。
在客戶端以單線程方式創建較大數量的無用鏈接，並保持持續發包的代價很是的低廉。實際試驗中一臺普通PC能夠創建的鏈接在3000個以上。這對一臺普通的Web server，將是致命的打擊。更不用說結合肉雞羣作分佈式DoS了。
鑑於此攻擊簡單的利用程度、拒絕服務的後果、帶有逃逸特性的攻擊方式，這類攻擊一炮而紅，成爲衆多攻擊者的研究和利用對象。
2)慢速攻擊的分類
發展到今天，慢速攻擊也多種多樣，其種類可分爲如下幾種：
Slow headers：Web應用在處理HTTP請求以前都要先接收完全部的HTTP頭部，由於HTTP頭部中包含了一些Web應用可能用到的重要的信息。攻擊者利用這點，發起一個HTTP請求，一直不停的發送HTTP頭部，消耗服務器的鏈接和內存資源。抓包數據可見，攻擊客戶端與服務器創建TCP鏈接後，每30秒才向服務器發送一個HTTP頭部，而Web服務器再沒接收到2個連續的\r\n時，會認爲客戶端沒有發送完頭部，而持續的等等客戶端發送數據。
慢速攻擊主要利用的是thread-based架構的服務器的特性，這種服務器會爲每一個新鏈接打開一個線程，它會等待接收完整個HTTP頭部纔會釋放鏈接。好比Apache會有一個超時時間來等待這種不徹底鏈接（默認是300s），可是一旦接收到客戶端發來的數據，這個超時時間會被重置。正是由於這樣，攻擊者能夠很容易保持住一個鏈接，由於攻擊者只須要在即將超時以前發送一個字符，即可以延長超時時間。而客戶端只須要不多的資源，即可以打開多個鏈接，進而佔用服務器不少的資源。
經驗證，Apache、httpd採用thread-based架構，很容易遭受慢速攻擊。而另一種event-based架構的服務器，好比nginx和lighttpd則不容易遭受慢速攻擊。
Apache服務器如今使用較多的有三種簡單防禦方式。
mod_reqtimeout：Apache2.2.15後，該模塊已經被默認包含，用戶可配置從一個客戶端接收HTTP頭部和HTTPbody的超時時間和最小速率。若是一個客戶端不能在配置時間內發送完頭部或body數據，服務器會返回一個408REQUEST TIME OUT錯誤。配置文件以下：
< IfModule mod_reqtimeout.c > RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500 < /IfModule >
mod_qos：Apache的一個服務質量控制模塊，用戶可配置各類不一樣粒度的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模塊，有專門針對慢速攻擊防禦的規則，配置以下：
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′」
傳統的流量清洗設備針對CC攻擊，主要經過閾值的方式來進行防禦，某一個客戶在必定的週期內，請求訪問量過大，超過了閾值，清洗設備經過返回驗證碼或者JS代碼的方式。這種防禦方式的依據是，攻擊者們使用肉雞上的DDoS工具模擬大量http request，這種工具通常不會解析服務端返回數據，更不會解析JS之類的代碼。所以當清洗設備截獲到HTTP請求時，返回一段特殊JavaScript代碼，正經常使用戶的瀏覽器會處理並正常跳轉不影響使用，而攻擊程序會攻擊到空處。
而對於慢速攻擊來講，經過返回驗證碼或者JS代碼的方式依然能達到部分效果。可是根據慢速攻擊的特徵，能夠輔助如下幾種防禦方式：一、週期內統計報文數量。一個TCP鏈接，HTTP請求的報文中，報文過多或者報文過少都是有問題的，若是一個週期內報文數量很是少，那麼它就多是慢速攻擊；若是一個週期內報文數量很是多，那麼它就多是一個CC攻擊。二、限制HTTP請求頭的最大許可時間。超過最大許可時間，若是數據尚未傳輸完成，那麼它就有多是一個慢速攻擊。
簡單的Nginx防CC方式
實驗
Nginx配置
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
#限制每ip每秒不超過20個請求，漏桶數burst爲5
#brust的意思就是，若是第1秒、2,3,4秒請求爲19個，
#第5秒的請求爲25個是被容許的。
#可是若是你第1秒就25個請求，第2秒超過20的請求返回503錯誤。
#nodelay，若是不設置該選項，嚴格使用平均速率限制請求數，
#第1秒25個請求時，5個請求放到第2秒執行，
#設置nodelay，25個請求將在第1秒執行。
limit_req zone=one burst=1 nodelay;
}
}
上面樣本的配置是什麼意思呢？
- $binary_remote_addr 表示：客戶端IP地址
- zone 表示漏桶的名字
- rate 表示nginx處理請求的速度有多快
- burst 表示峯值
- nodelay 表示是否延遲處理請求，仍是直接503返回給客戶端，若是超出rate設置的狀況下。
詳細的能夠參考官方說明文檔：Module ngx_http_limit_req_module
模擬請求
這裏咱們須要Apache Benchmark這個小工具來生成請求
//1個用戶持續100s的時間向服務器發送請求 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測試結果以下所示：
| 數據 | 成功的請求數 | 失敗的請求數 | 請求時間 | 每秒成功的請求數 |
|---|---|---|---|---|
| 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模塊會統一返回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;
}
}
| 數據 | 成功的請求數 | 失敗的請求數 | 請求時間 | 每秒成功的請求數 |
|---|---|---|---|---|
| 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 |
從數據來看，提升了burst值，明顯nginx成功的請求數上去了。
Nginx配置樣本三
在樣本二的基礎上，咱們把nodelay去除掉
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
limit_req zone=one burst=10;
}
}
| 數據 | 成功的請求數 | 失敗的請求數 | 請求時間 | 每秒成功的請求數 |
|---|---|---|---|---|
| 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 |
從這裏的數據能夠看到將nodelay的參數去掉的話，成功的請求數在100左右而失敗的請求數變成0了，爲何呢？
- 有nodelay參數的時候，nginx正常是及時處理當前的請求的並響應數據給客戶端，可是若是超過limit_req_module的限制，那麼會統一返回503給客戶端。
- 無nodelay參數的時候，nginx正常是及時處理當前的請求的並響應數據給客戶端，可是若是超過limit_req_module的限制，那麼會將此此請求緩存「就先這麼理解」起來稍後再處理，因此也就不會出現大量的失敗請求數了。
存在的問題
雖然用limit_req_module能夠必定上的防止CC攻擊，可是有誤殺機率；國內寬帶用戶的IP地址已經大量內網化，幾百人共享一個IP的可能性是很大的。
5、應用層DDoS的防護理論：
問題模型描述：
每個頁面，都有其資源消耗權重，靜態資源，權重較低，動態資源，權重較高。對於用戶訪問，有以下：
用戶資源使用頻率=使用的服務器總資源量/s
命題一：對於正常訪問的用戶，資源使用頻率一定位於一個合理的範圍，固然會存在大量正經常使用戶共享ip的狀況，這就須要平常用戶訪問統計，以獲得忠實用戶ip白名單。
命題二：資源使用頻率持續異常的，可判定爲訪問異常的用戶。
防護體系狀態機：
1.在系統各項資源很是寬裕時，向全部ip提供服務，每隔一段時間釋放一部分臨時黑名單中的ip成員；
2.在系統資源消耗達到某一閾值時，下降Syn包接受速率，循環：分析最近時間的日誌，並將訪問異常的ip加入臨時黑名單；
3.若系統資源消耗慢慢回降至正常水平，則恢復Syn包接受速率，轉到狀態1；若目前策略並未有效地控制住系統資源消耗的增加，狀況繼續惡劣至一極限閾值，轉到狀態4；
4.最終防護方案，使用忠實用戶ip白名單、異常訪問ip黑名單策略，其餘訪問可慢慢放入，直到系統資源消耗回降至正常水平，轉到狀態1。
上述的防護狀態機，對於單個攻擊IP高併發的DDOS，變化到狀態3時，效果就徹底體現出來了，但若是防護狀態機進行到4狀態，則有以下兩種可能：
1.站點遭到了攻擊羣龐大的、單個IP低併發的DDOS攻擊；
2.站點忽然間有了不少訪問正常的新用戶。
6、建議後續工做：
保守：站點應儘快進行服務能力升級。
積極：盡所能，追溯攻擊者。
追溯攻擊者：
CC：proxy-forward-from-ip
單個IP高併發的DDOS：找到訪問異常的、高度可疑的ip列表，exploit，蒐集、分析數據，由於一個傀儡主機可被二次攻佔的機率很大（但不建議這種方法）
單個IP低併發的DDOS：之前極少訪問被攻擊站點，可是在攻擊發生時，卻頻繁訪問咱們的站點，分析日誌獲得這一部分ip列表
追溯攻擊者的過程當中，snat與web proxy增長了追蹤的難度，若是攻擊者採用多箇中繼服務器的方法，追溯將變得極爲困難。
防護者：
1.應對當前系統瞭如指掌，如系統最高負載、最高數據處理能力，以及系統防護體系的強項與弱點
2.歷史日誌的保存、分析
3.對當前系統進行嚴格安全審計
4.上報公安相關部分，努力追溯攻擊者
5.網站，能靜態，就必定不要動態，可採起定時從主數據庫生成靜態頁面的方式，對須要訪問主數據庫的服務使用驗證機制。
6.防護者應能從全局的角度，迅速及時地發現系統正在處於什麼程度的攻擊、何種攻擊，在平時，應該創建起攻擊應急策略，規範化操做，省得在急中犯下低級錯誤
對歷史日誌的分析這時將會很是重要，數據可視化與統計學的方法將會頗有益處：
1.分析每一個頁面的平均訪問頻率
2.對訪問頻率異常的頁面進行詳細分析 分析獲得ip-頁面訪問頻率
3.獲得對訪問異常頁面的訪問異常ip列表
4.對日誌分析獲得忠實用戶IP白名單
5.通常一個頁面會關聯多個資源，一次對於這樣的頁面訪問每每會同時增長多個資源的訪問數，而攻擊程序通常不會加載這些它不感興趣的資源，因此，這也是一個很是好的分析突破點
防護思路
由於CC攻擊經過工具軟件發起，而普通用戶經過瀏覽器訪問，這其中就會有某些區別。想辦法對這兩者做出判斷，選擇性的屏蔽來自機器的流量便可。
初級
普通瀏覽器發起請求時，除了要訪問的地址之外，Http頭中還會帶有Referer，UserAgent等多項信息。遇到攻擊時能夠經過日誌查看訪問信息，看攻擊的流量是否有明顯特徵，好比固定的Referer或UserAgent，若是能找到特徵，就能夠直接屏蔽掉了。
中級
若是攻擊者僞造了Referer和UserAgent等信息，那就須要從其餘地方入手。攻擊軟件通常來講功能都比較簡單，只有固定的發包功能，而瀏覽器會完整的支持Http協議，咱們能夠利用這一點來進行防護。
首先爲每一個訪問者定義一個字符串，保存在Cookies中做爲Token，必需要帶有正確的Token才能夠訪問後端服務。當用戶第一次訪問時，會檢測到用戶的Cookies裏面並無這個Token，則返回一個302重定向，目標地址爲當前頁面，同時在返回的Http頭中加入set cookies字段，對Cookies進行設置，使用戶帶有這個Token。
客戶端若是是一個正常的瀏覽器，那麼就會支持http頭中的set cookie和302重定向指令，將帶上正確的Token再次訪問頁面，這時候後臺檢測到正確的Token，就會放行，這以後用戶的Http請求都會帶有這個Token，因此並不會受到阻攔。
客戶端若是是CC軟件，那麼通常不會支持這些指令，那麼就會一直被攔在最外層，並不會對服務器內部形成壓力。
高級
高級一點的，還能夠返回一個網頁，在頁面中嵌入JavaScript來設置Cookies並跳轉，這樣被僞造請求的可能性更小
Token生成算法
Token須要知足如下幾點要求
1，每一個IP地址的Token不一樣
2， 沒法僞造
3， 一致性，即對相同的客戶端，每次生成的Token相同
Token隨IP地址變化是爲了防止經過一臺機器獲取Token以後，再經過代理服務區進行攻擊。一致性則是爲了不在服務器端須要存儲已經生成的Token。
推薦使用如下算法生成Token，其中Key爲服務器獨有的保密字符串，這個算法生成的Token能夠知足以上這些要求。
Token = Hash( UserAgent + client_ip + key )
本文主要講述了DDoS攻擊之一的CC攻擊工具實現，以及如何防護來自應用層的DDoS攻擊的理論總結。接下來的文章，筆者將會實現一個工做於內核態的、具備黑名單功能的防火牆模塊，以對應於上述防護狀態機中的防火牆單元，它實現了自主地動態內存管理，使用hash表管理ip列表，並能夠自定義hash表的modular。
7、 簡易CC攻擊防護策略
肯定Web服務器正在或者曾經遭受CC攻擊，那如何進行有效的防範呢?
(1).取消域名綁定
通常cc攻擊都是針對網站的域名進行攻擊，好比咱們的網站域名是「www.abc.com」，那麼攻擊者就在攻擊工具中設定攻擊對象爲該域名而後實施攻擊。 對於這樣的攻擊咱們的措施是取消這個域名的綁定，讓CC攻擊失去目標。
(2).域名欺騙解析
若是發現針對域名的CC攻擊，咱們能夠把被攻擊的域名解析到127.0.0.1這個地址上。咱們知道127.0.0.1是本地迴環IP是用來進行網絡測試的，若是把被攻擊的域名解析到這個IP上，就能夠實現攻擊者本身攻擊本身的目的，這樣他再多的肉雞或者代理也會宕機，讓其自食其果。
(3).更改Web端口
通常狀況下Web服務器經過80端口對外提供服務，所以攻擊者實施攻擊就以默認的80端口進行攻擊，因此，咱們能夠修改Web端口達到防CC攻擊的目的。運行IIS管理器，定位到相應站點，打開站點「屬性」面板，在「網站標識」下有個TCP端口默認爲80，咱們修改成其餘的端口就能夠了。
(4).屏蔽IP
咱們經過命令或在查看日誌發現了CC攻擊的源IP，就能夠在防火牆中設置屏蔽該IP對Web站點的訪問，從而達到防範攻擊的目的。
轉：https://www.cnblogs.com/wpjamer/p/9030259.html
如何防範CC攻擊
服務器如何防範CC攻擊
CC攻擊是DDOS(分佈式拒絕服務)的一種,相比其它的DDOS攻擊CC彷佛更有技術含量一些.這種攻擊你見不到虛假IP,見不到特別大的異常流量,但形成服務器沒法進行正常鏈接,據說一條ADSL足以搞掂一臺高性能的Web服務器.因而可知其危害性,稱其爲「Web殺手」也絕不爲過.最讓站長們憂慮的是這種攻擊技術含量低,利用工具和一些IP代理一個初、中級的電腦水平的用戶就可以實施攻擊.所以,你們有必要了解CC攻擊的原理及若是發現CC攻擊和對其的防範措施.
一、攻擊原理
CC攻擊的原理就是攻擊者控制某些主機不停地發大量數據包給對方服務器形成服務器資源耗盡,一直到宕機崩潰.CC主要是用來攻擊頁面的,每一個人都有這樣的體驗：當一個網頁訪問的人數特別多的時候,打開網頁就慢了,CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行訪問那些須要大量數據操做(就是須要大量CPU時間)的頁面,形成服務器資源的浪費,CPU長時間處於100%,永遠都有處理不完的鏈接直至就網絡擁塞,正常的訪問被停止.
二、攻擊症狀
CC攻擊有必定的隱蔽性,那如何肯定服務器正在遭受或者曾經遭受CC攻擊呢?咱們能夠經過如下三個方法來肯定.
(1).命令行法
通常遭受CC攻擊時,Web服務器會出現80端口對外關閉的現象, 由於這個端口已經被大量的垃圾數據堵塞了正常的鏈接被停止了.咱們能夠經過在命令行下輸入命令netstat -an來查看,若是看到相似以下有大量顯示雷同的鏈接記錄基本就能夠被CC攻擊了：
……
TCP 192.168.1.3:80 192.168.1.6:2203 SYN_RECEIVED 4
TCP 192.168.1.3:80 192.168.1.6:2203 SYN_RECEIVED 4
TCP 192.168.1.3:80 192.168.1.6:2203 SYN_RECEIVED 4
TCP 192.168.1.3:80 192.168.1.6:2203 SYN_RECEIVED 4
TCP 192.168.1.3:80 192.168.1.6:2203 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攻擊了.(圖3)
默認狀況下,Web日誌記錄的項並非不少,咱們能夠經過IIS進行設置,讓Web日誌記錄更多的項以便進行安全分析.其操做步驟是：
「開始→管理工具」打開「Internet信息服務器」,展開左側的項定位到到相應的Web站點,而後右鍵點擊選擇「屬性」打開站點屬性窗口,在「網站」選項卡下點擊「屬性」按鈕,在「日誌記錄屬性」窗口的「高級」選項卡下能夠勾選相應的「擴展屬性」,以便讓Web日誌進行記錄.好比其中的「發送的字節數」、「接收的字節數」、「所用時間」這三項默認是沒有選中的,但在記錄判斷CC攻擊中是很是有用的,能夠勾選.另外,若是你對安全的要求比較高,能夠在「常規」選項卡下對「新日誌計劃」進行設置,讓其「每小時」或者「每一天」進行記錄.爲了便於往後進行分析時好肯定時間能夠勾選「文件命名和建立使用當地時間」.
三、CC攻擊防護策略
肯定Web服務器正在或者曾經遭受CC攻擊,那如何進行有效的防範呢?筆者依據我的經驗,提供以下防護措施.
(1).取消域名綁定
通常cc攻擊都是針對網站的域名進行攻擊,好比咱們的網站域名是「www.isbese.net」,那麼攻擊者就在攻擊工具中設定攻擊對象爲該域名而後實施攻擊.
對於這樣的攻擊咱們的措施是在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的訪問.
(5).IPSec封鎖
IPSec是優秀的系統防火牆,在排除其餘還有別的類型的DDOS攻擊時,針對CC攻擊能夠用設置IP策略來對付攻擊.以219.128.*.43這個IP爲例子,筆者實際操做對該IP的訪問封鎖.
第一步：「開始→管理工具」,打開「本地安全設置」,右鍵點擊「IP安全策略,在本地機器」選擇「建立IP安全策略」,而後點擊「下一步」,輸入策略「名稱」和「描述」.而後默認一路「下一步」建立了一個名爲「封CC攻擊」的IPSec策略.
第二步：右鍵點擊「IP安全策略,在本地機器」選擇「管理IP篩選器表和篩選器操做」,在打開的窗口中點「添加」,在「IP 篩選器列表」窗口添人同第一步的名稱和描述信息.取消「使用添加嚮導」的勾選,而後點擊「添加」.在「IP 篩選器 屬性」窗口的「地址」選項下設置「源地址」爲「192.168.1.6」,目標地址爲「個人IP地址」,取消對「鏡像」的勾選;點擊「協議」選項卡,設置「協議類型」爲「TCP」,設置「協議端口」爲「從任意端口」到「此端口80」最後肯定退出.
第三步：在「新規則 屬性」窗口中點選剛纔建立的「封CC攻擊」規則,點擊「篩選器操做」選項卡下的「添加」,點選「安全措施」下的「阻止」,在「常規」選項卡下爲該篩選器命名爲「阻止CC攻擊」而後肯定退出.
第四步：點選剛纔建立的「阻止CC攻擊」篩選器,一路「肯定」退出IP策略編輯器,能夠看到在組策略窗口的中建立成功一個名爲「封CC攻擊」的策略,而後右鍵點擊該策略選擇「指派」.這樣就實現了對該IP的封鎖.
(6).防火牆
除了利用上述方法外,還能夠經過第三方的防火牆進行防範,打開防禦牆建立相應防火牆規則就能夠了,筆者以天網防火牆爲例進行演示.
打開天網防火牆進入「IP規則管理」窗口,點擊「增長規則」,而後輸入規則的名稱、描述等信息.數據包協議類型選擇「TCP」,數據包方向爲「接收」,對方IP地址爲「指定地址」而後輸入該IP地址,本地端口勾選「已受權程序開放的端口」,對方端口不填表示全部端口,TCP標誌位勾選「SYN」,當知足上面條件是選擇「攔截」,同時還勾選「記錄」、「警告」、「發聲」.最後「肯定」退出,點「保存規則」應該該規則便可.
總結：本文以Web服務器爲例講述瞭如何判斷CC攻擊以及如何防CC攻擊.其實,除了Web服務器對於其餘的服務器也能夠進行相似的防CC攻擊設置.
DDoS攻擊相信你們多多少少都聽過一點，網絡上各類D闊、C闊，每天打這個打那個，處處接單，說本身能打多少流量，打死了就發羣上問別人，死了沒，死了沒???
那麼DDoS攻擊的原理究竟是什麼呢？DDoS全稱:分佈式拒絕服務(DDoS:Distributed Denial of Service)。信息安全的三要素——「保密性」、「完整性」和「可用性」中，拒絕服務攻擊，針對的目標正是「可用性」。該攻擊方式利用目標系統網絡服務功能缺陷或者直接消耗其系統資源，使得該目標系統沒法提供正常的服務。拒絕服務攻擊問題一直得不到合理的解決，目前仍是世界性難題，究其緣由是由於這是因爲網絡協議自己的安全缺陷形成的，（這裏不細說，詳情自行百度）從而拒絕服務攻擊也成爲了攻擊者的終極手法。攻擊者進行拒絕服務攻擊，實際上讓服務器實現兩種效果：一是迫使服務器的緩衝區滿，不接收新的請求；二是使用IP欺騙，迫使服務器把合法用戶的鏈接復位，影響合法用戶的鏈接。
那麼CC攻擊的原理又是什麼呢，咱們常常聽別人說，接D單、CC單，CC不也是拒絕服務攻擊嗎?和DDOS二者有什麼區別呢?不少人都分不清楚DDoS攻擊和CC攻擊的區別。CC攻擊全稱Challenge Collapsar，中文意思是挑戰黑洞，由於之前的抵抗DDoS攻擊的安全設備叫黑洞，顧名思義挑戰黑洞就是說黑洞拿這種攻擊沒辦法，新一代的抗DDoS設備已經更名爲ADS(Anti-DDoS System)，基本上已經能夠完美的抵禦CC攻擊了。CC攻擊的原理是經過代理服務器或者大量肉雞模擬多個用戶訪問目標網站的動態頁面，製造大量的後臺數據庫查詢動做，消耗目標CPU資源，形成拒絕服務。CC不像DDoS能夠用硬件防火牆來過濾攻擊，CC攻擊自己的請求就是正常的請求。咱們都知道網站的頁面有靜態和動態之分，動態網頁是須要與後臺數據庫進行交互的，好比一些論壇用戶登陸的時候須要去數據庫查詢你的等級、權限等等，當你留言的時候又須要查詢權限、同步數據等等，這就消耗不少CPU資源，形成靜態網頁能打開，可是須要和數據庫交互的動態網頁打開慢或者沒法打開的現象。這種攻擊方式相對於前兩種實現要相對複雜一些，可是防護起來要簡單的多，提供服務的企業只要儘可能少用動態網頁而且讓一些操做提供驗證碼就能抵禦通常的CC攻擊。
這裏能看出來DDoS和CC的區別，DDoS攻擊打的是網站的服務器，而CC攻擊是針對網站的頁面攻擊的，用術語來講就是，一個是WEB網絡層拒絕服務攻擊（DDoS），一個是WEB應用層拒絕服務攻擊（CC），網絡層就是利用肉雞的流量去攻擊目標網站的服務器，針對比較本源的東西去攻擊，服務器癱瘓了，那麼運行在服務器上的網站確定也不能正常訪問了。而應用層就是咱們用戶看獲得的東西，就好比說網頁，CC攻擊就是針對網頁來攻擊的，CC攻擊自己是正常請求，網站動態頁面的正常請求也會和數據庫進行交互的，當這種"正常請求"達到一種程度的時候，服務器就會響應不過來，從而崩潰。每次雙十一，在你們都忙着準備搶購商品的時候，各大電商平臺的機房每每是燈火通明，緊張觀察一切動態，各類流量清洗設備，軟件硬件都用上了，就是怕到時候服務器崩掉了，那損失可不止一點，電商平臺在這方面的投入資金也是比較大的。雙十一前夕曾有人笑說， xxxx年最大的DDOS攻擊即未來臨。
- 1. CC攻擊原理與防範
- 2. 什麼是CC攻擊？怎麼防範CC攻擊？
- 3. DDoS攻擊、CC攻擊的攻擊方式和防護方法
- 4. Nginx防CC攻擊
- 5. 高防CDN如何防護CC攻擊
- 6. DDOS攻擊如何防範
- 7. 如何防範DDoS攻擊
- 8. 網站遭遇到DDoS攻擊和CC攻擊如何防禦
- 9. csrf攻擊的原理和Django防範csrf攻擊的方法
- 10. CC攻擊有哪些特色以及如何防護CC攻擊？
- 更多相關文章...
- • XSD 如何使用? - XML Schema 教程
- • 如何僞造ARP響應？ - TCP/IP教程
- • ☆技術問答集錦（13）Java Instrument原理
- • Java Agent入門實戰（三）-JVM Attach原理與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. CC攻擊原理與防範
- 2. 什麼是CC攻擊？怎麼防範CC攻擊？
- 3. DDoS攻擊、CC攻擊的攻擊方式和防護方法
- 4. Nginx防CC攻擊
- 5. 高防CDN如何防護CC攻擊
- 6. DDOS攻擊如何防範
- 7. 如何防範DDoS攻擊
- 8. 網站遭遇到DDoS攻擊和CC攻擊如何防禦
- 9. csrf攻擊的原理和Django防範csrf攻擊的方法
- 10. CC攻擊有哪些特色以及如何防護CC攻擊？