0x00 CC攻擊的基本原理
　　CC攻擊利用代理服務器向網站發送大量需要較長計算時間的URL請求，如數據庫查詢等，導致服務器進行大量計算而很快達到自身的處理能力而形成DOS。而攻擊者一旦發送請求給代理后就主動斷開連接，因爲代理并不因爲客戶端這邊連接的斷開就不去連接目標服務器。因此攻擊機的資源消耗相對很小，而從目標服務器看來，來自代理的請求都是合法的。
　　以前防CC攻擊的方法
　　為了防范CC，以前的方法一個是限制每個IP的連接數，這在地址范圍很廣闊的情況下比較難實現;二是限制代理的訪問，因為一般的代理都會在HTTP頭中帶 X_FORWARDED_FOR字段，但也有局限，有的代理的請求中是不帶該字段的，另外有的客戶端確實需要代理才能連接目標服務器，這種限制就會拒絕一些正常用戶訪問。
　　CC攻擊用硬防難防住
　　CC攻擊比DDOS攻擊更可怕的就是，CC攻擊一般是硬防很難防止住的。
　　個人分析原因有三：
　　一、因為CC攻擊來的IP都是真實的，分散的;
　　二、CC攻擊的數據包都是正常的數據包;
　　三、CC攻擊的請求，全都是有效的請求，無法拒絕的請求。
　　防CC攻擊思路
　　防CC有效性在于攻擊方不接受服務器回應的數據，發送完請求后就主動斷開連接，因此要確認連接是否是CC，服務器端不立即執行URL請求命令，而是簡單的返回一個頁面轉向的回應，回應中包含新的URL請求地址。如果是正常訪問，客戶端會主動再次連接到轉向頁面，對用戶來說是透明的;而對于CC攻擊者，由于不接收回應數據，因此就不會重新連接，服務器也就不需要繼續進行操作。

0x01 驗證瀏覽器行為

簡易版

我們先來做個比喻。

社區在搞福利，在廣場上給大家派發紅包。而壞人派了一批人形的機器人(沒有語言模塊)來冒領紅包，聰明工作人員需要想出辦法來防止紅包被冒領。

于是工作人員在發紅包之前，會給領取者一張紙，上面寫著“紅包拿來”，如果那人能念出紙上的字，那么就是人，給紅包，如果你不能念出來，那么請自覺。于是機器人便被識破，灰溜溜地回來了。

是的，在這個比喻中，人就是瀏覽器，機器人就是攻擊器，我們可以通過鑒別cookie功能(念紙上的字)的方式來鑒別他們。下面就是nginx的配置文件寫法。

if ($cookie_say != "hbnl"){   add_header Set-Cookie "say=hbnl";   rewrite .* "$scheme://$host$uri" redirect;}

讓我們看下這幾行的意思，當cookie中say為空時，給一個設置cookie say為hbnl的302重定向包，如果訪問者能夠在第二個包中攜帶上cookie值，那么就能正常訪問網站了，如果不能的話，那他永遠活在了302中。你也可以測試一下，用CC攻擊器或者webbench或者直接curl發包做測試，他們都活在了302世界中。