CC攻擊是網絡上很常見的一種大規模攻擊方案。流量超大，攻擊很猛，一般的網站根本無法抵禦。
什麼是 CC 攻擊
CC（Challenge Collapsar）該攻擊與我們常見的 DDOS（網絡層分布式拒絕服務攻擊）不同之處在于，CC 攻擊隻會導緻 WEB服務或者隻是 WEB 服務中的某一接口或單一頁面無法服務，相比網絡層的拒絕服務攻擊，其優勢在于能夠使用相對較少的資源對更為精确的目标進行攻擊。
攻擊方式
主要的攻擊方式分為快速和慢速兩種：
快速 CC 攻擊是指快速請求伺服器處理消耗較大的頁面或者接口，這種方式是通過大量占用伺服器的 CPU、IO 等資源，緻使伺服器無法正常響應其它使用者的請求。
慢速 CC 攻擊是指是通過與伺服器建立連接配接後，以最慢的速度發送請求/讀取響應，通過占用伺服器的程序、線程、網絡套接字等資源，達到導緻伺服器無法繼續服務的目的，這種攻擊一般針對 Apache、httpd 這類 thread-base 架構的伺服器。
防護手段
針對兩種不同類型的攻擊防護方式分别是：
快速攻擊： 限制單一源IP的請求速率、限制并發連接配接數
慢速攻擊： 限制單一請求的逾時時間
Nginx 和 Apache 都有相應的子產品來解決這類問題，隻要配置得當能夠抵擋住大多數的 CC 攻擊，以下我們以 Nginx 為例看看具體的配置。
限制單一源 IP 的請求速率，平均每秒不超過 1 個請求，并且突發不超過 5 個請求：
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
...
server {
...
location /limit_req/ {
limit_req zone=one burst=5;
} }
限制并發連接配接數，單一源 IP 最大并發數是 100，總的連接配接數不超過 1000：
limit_conn_zone $binary_remote_addr zone=one:10m;
limit_conn_zone $server_name zone=perserver:10m;
...
limit_conn one 100;
limit_conn perserver 1000;
... 限制單個請求的逾時時間：
...
client_header_timeout 60s; //等待用戶端發送請求頭的逾時時間，将這個值改小可以應對慢速發送請求頭的CC攻擊；
client_body_timeout 60s; //讀取用戶端發送請求體的逾時時間，将這個值改小可以應對慢速發送請求體的CC攻擊；
keepalive_timeout 75s; //與用戶端的連接配接逾時時間，如果連接配接大量被占用，可以将其改小一些，釋放被占用的連接配接，減輕伺服器壓力；
... 阿裡雲的Web應用防火牆對網站或者APP的業務流量進行惡意特征識别及防護，将正常、安全的流量回源到伺服器。避免網站伺服器被惡意入侵，保障業務的核心資料安全，解決因惡意攻擊導緻的伺服器性能異常問題。
更多參閱
阿裡雲web防火牆配置文檔CC防護攻擊緊急模式
當網站遇到CC攻擊的時候，我們一般想到的是第一時間的恢複網站的業務，但這個時候我們可以直接在web應用防火牆上開啟CC防護攻擊緊急模式。開啟之後，能夠有效的對用戶端校驗。
這個模式有一個注意的點就是他這個模式隻能對Web應用、網站應用及H5頁面有效。對于API以及Native的App會造成大量的誤殺，是以這兩個應用場景下是不支援攻擊緊急模式的。這種情況，我們建議的方案是使用CC自定義防護進行防禦。
CC自定義防護
那麼随着自定義的一個防禦怎麼來配置呢？有兩個步驟，一是先要從攻擊的日志中分析找到攻擊的特征。然後使用工具或者對應的功能對我們發現的特征進行封禁，進而達到保護的目的。
特征分析
我們先來看一下CC攻擊有哪些特征，一般情況下面最主要最明顯的特征是某個URL的請求異常的集中。另外一方面，他請求的源IP異常的集中。第三點，他請求的Refer或者user-agent異常的集中。有了這幾個概念之後，我們就可以根據這幾個概念去分析日志，擷取對應的特征。
我們可以以下面這個網站為例，可以看一下對應的時間段。
從這個日志的一個趨勢來看，其實是被打得挺厲害的，峰值時間最高的時候有13萬的QPS。那我們怎麼來對這種攻擊進行分析呢？我們采用了SLS的日志服務，快捷的自動化地進行分析分析的過程。
request URL分析
我們通過對request URL進行分析，可以看到他99%的請求全都請求了//index.php的路徑。這個請求占這麼大的量絕對是有問題的，正常情況下面對比相同時間段，其實不會有這麼大的量出現。那麼我們要做的事情就是把惡意的請求給他分辨出來，然後把它攔截表對他進行自定義的CC防護。
規則配置
配置規則的時候，對這個URL進行完全比對，然後配置我們檢測的周期是十秒或者五秒，然後對他進行的檢測的次數，在這個時間範圍内他通路的次數十次或5次。然後對應的主端動作是可以是封禁，也可以是人機識别。最後是他封禁的時間，可以封禁他三十分鐘甚至更長。我的配置是采用封禁的政策，在十秒内通路五次就直接對他進行封禁的一個動作，進而達到對網站業務的一個防護。
這裡可以看到還有一個是人機識别的阻斷類型，人機識别它是對用戶端的請求進行一個腳印的一個過程，它會傳回給用戶端一串特殊的代碼，可以了解為JS的代碼，讓用戶端去執行。
如果能夠正常的執行成功，那麼說明這個用戶端是一個真實的用戶端。校驗成功過後，我們對他進行加白，讓他能夠正常通路。如果不能執行，那麼這個用戶端我們不認為他是一個正常的用戶端，會把他拉黑一段時間。這個時間就是我們配置上配的那個時間。
需要注意，在WAF前面如果有高防或者CDN的場景下，我們不建議使用封禁的政策，建議使用人機識别的政策。
經過這段配置，其實我們的網站業務能夠得到一定的緩解，如果不能緩解的話，可以根據我們上面配置的一個政策進行調整。由松到緊配置僅一點達到緩解業務的一個效果。
IP分析
得到一定緩解之後，我們繼續分析一隻去分析更加精确的攻擊特征加以保護，提高我們防護的效果。
先看一下源IP分布沒有什麼特征，沒有在幾個段裡面，然後去查市裡面。其實各個市都有，也沒有市和省的次元，那這兩個不能作為一個明顯的一個特征去做防護。
refer或者user-agent分析
那麼第三個去通過refer或者user-agent去看，通過refer去看的時候，這邊就不說了，因為沒有特别明顯的特征，但是再去看user-agent的時候，發現99%的請求都是來自于microsoft和Firefox浏覽器的請求。
這個通路比例與我們請求的request，index.php的請求比例是非常接近的，然後我們拿着這個user-agent去對比前一天相同時間段的請求，是否有這個user-agent。
前一天的相同時間段下沒有出現過類似這樣的一個UA。那麼我們認為目前時間段出現這個UA的請求是異常的，是惡意的。那麼我們針對這個UA進行防護的時候，我們使用WAF的精準防護，控制精準的對這個UA進行配置阻斷。
WAF的精準防護配置
配置方式是為了更加準确而使用兩個條件，一個是user-agent，讓它包含Firefox，另外一個是URL包含上述所說的index.php，同時滿足這兩個條件的，那我們同時對他進行阻斷的操作。
通過這種方式能夠有效的将所有惡意的請求排除在外。真正回到原站的請求都是我們判斷是可信的一個請求，進而達到防護的效果。