今天我們就來說說CC防護攻擊怎么配置規則。CC攻擊是DDOS（分布式拒絕服務）的一種，攻擊者通過代理服務器向受害主機大批量的發出合法的請求。

CC防護攻擊緊急模式

當網站碰到CC攻擊的時候，我們一般想到的是第一時間的恢復網站的業務，但這個時候我們可以直接在web應用防火墻上開啟CC防護攻擊緊急模式。開啟之后，能夠有效的對客戶端校驗。

但是這個模式有一個注重的點就是他這個模式只能對Web應用、網站應用及H5頁面有效。對于API以及Native的App會造成大量的誤殺，所以這兩個應用場景下是不支持攻擊緊急模式的。這種情況，我們建議的方案是使用CC自定義防護進行防御。

CC自定義防護

那么隨著自定義的一個防御怎么來配置呢？有兩個步驟，一是先要從攻擊的日志中分析找到攻擊的特征。然后使用工具或者對應的功能對我們發現的特征進行封禁，從而達到保護的目的。

特征分析

我們先來看一下CC攻擊有哪些特征，一般情況下面很主要很明顯的特征是某個URL的請求異常的集中。另外一方面，他請求的源IP異常的集中。第三點，他請求的Refer或者user-agent異常的集中。有了這幾個概念之后，我們就可以根據這幾個概念去分析日志，獲取對應的特征。

我們可以以下面這個為例，可以看一下對應的時間段。

從這個日志的一個趨勢來看，其實是被打得挺厲害的，峰值時間很高的時候有13萬的QPS。那我們怎么來對這種攻擊進行分析呢？我們采用了SLS的日志服務，快捷的自動化地進行分析分析的過程。

requestURL分析

我們通過對requestURL進行分析，可以看到他99%的請求全都請求了//index.php的路徑。這個請求占這么大的量絕對是有問題的，正常情況下面對比相同時間段，其實不會有這么大的量出現。那么我們要做的事情就是把惡意的請求給他分辨出來，然后把它攔截表對他進行自定義的CC防護。

規則配置

配置規則的時候，對這個URL進行完全匹配，然后配置我們檢測的周期是十秒或者五秒，然后對他進行的檢測的次數，在這個時間范圍內他訪問的次數十次或5次。然后對應的主端動作是可以是封禁，也可以是人機識別。很后是他封禁的時間，可以封禁他三十分鐘甚至更長。我的配置是采用封禁的策略，在十秒內訪問五次就直接對他進行封禁的一個動作，從而達到對網站業務的一個防護。

這里可以看到還有一個是人機識別的阻斷類型，人機識別它是對客戶端的請求進行一個腳印的一個過程，它會返回給客戶端一串尤其的代碼，可以理解為JS的代碼，讓客戶端去執行。

假如能夠正常的執行成功，那么說明這個客戶端是一個真實的客戶端。校驗成功過后，我們對他進行加白，讓他能夠正常訪問。假如不能執行，那么這個客戶端我們不認為他是一個正常的客戶端，會把他拉黑一段時間。這個時間就是我們配置上配的那個時間。

需要注重，在WAF前面假如有高防或者CDN的場景下，我們不建議使用封禁的策略，建議使用人機識別的策略。

經過這段配置，其實我們的網站業務能夠得到一定的緩解，假如不能緩解的話，可以根據我們上面配置的一個策略進行調整。由松到緊配置僅一點達到緩解業務的一個效果。

IP分析

得到一定緩解之后，我們繼續分析一只去分析更加正確的攻擊特征加以保護，提高我們防護的效果。

我們先看一下源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，同時滿足這兩個條件的，那我們市網站建設同時對他進行阻斷的操作。

通過這種方式能夠有效的將所有惡意的請求排除在外。真正回到原站的請求都是我們判定是可信的一個請求，從而達到防護的效果。