第一次訪問的時候，不是直接返回網頁內容，而且返回這段JS程序。
作用就是計算出入口變量的值，然后在訪問的網址后面加上類似于”?jdfwkey=hj67l9″的字串，組合成新的網址，然后跳轉，當防火墻驗證了jdfwkey的值(hj67l9)是正確的之后，就放行，一段時間內就不會再出這個判斷程序的頁面。

2)301或者302轉向方式輸出入口
原理和1類似，區別在于把入口直接輸出在了HTTP頭部信息里，不重復敘述了。

2.5)還有一些把入口通過其他方式輸出的，比如cookie，類似于1和2，原理都是在第一次訪問的時候設置一道檻。這個就不單獨計算為一條了。

3)屏蔽代理
由于一部分的CC攻擊是利用代理服務器發起的，所以有些時候防CC會屏蔽掉帶x-forward-for這個值的IP，對匿名代理無效。

4)判斷速率
由于CC攻擊是持續的發起請求，所以發起攻擊的IP在單位時間內的請求數量會明顯比正常多出很多，通過把請求頻率過高的IP屏蔽掉來防御。

5)驗證碼
這個基本是最后的無敵大招了，必須在用戶輸入驗證碼后才能訪問。

二，防御效果(突破方式)
1中的防護方式用的最早并且用的最多的是金盾防火墻。也正是由于用的人太多了，市面上已經有突破金盾防火墻的軟件在出售，原理就是通過JS解析引擎計算出jdfwkey的值。

突破2的方式更簡單，和1差不多，只不過是直接在HTTP頭中，連JS引擎都省了。

3無法硬性突破，也就是說，如果屏蔽了帶x-forward-for的IP，那么它就不可能訪問到。

突破4的方式就是限制請求速度，但是這對于攻擊者是一個挑戰，限制單個攻擊源的請求速度，并且保證攻擊效果，這就要求攻擊者擁有更多倍的攻擊源(肉雞)。

對于5，驗證碼識別是個大話題，目前階段幾乎不可能應用到CC攻擊中，未來也不太可能。但是網絡上有很多的打碼平臺，如果和這些平臺對接的話，人工識別驗證碼，就OVER了(應該不會有人去搞，太麻煩)。

對于所有的防護方式，如果是把網站域名解析到了別處，通過其他機器轉發請求來防御CC攻擊流量的(比如CDN)，都可以通過添加HOST值的方式將流量發到真實機器上，使這些防護失效。找查網站真實IP的方法很多很復雜，不能保證100%都能找得到，本文不做敘述。

三，負作用
有些IP，我們會要求它一直可以訪問到網站內容，比如蜘蛛，比如交易類網站的支付寶異步通知。
但是收集這些IP，幾乎是無法100%準確的收集到的(可能有人會想到useragent，一句話：攻擊者可以偽造)。

下面要講的，就不再考慮上述的這個問題了。

對于1和2，對訪客幾乎不會造成影響，判斷過程是由瀏覽器自動完成的。

對于3，由于個別的網絡環境，在沒有使用代理的情況下，也會在瀏覽器訪問時強行加上x-forward-for的值，最終的導致的就是這個訪問無法訪問。其實在現在這個年代，除了CC攻擊中使用的代理IP外，剩的帶x-forward-for的IP，幾乎都是這樣的情況，也就是訪客本地網絡環境強加上的。早些年設置代理主要是因為那個時候網速差，用于提高速度。現在翻墻時設置的SSH代理一般不會加上x-forward-for。

對于4，可能會造成誤封。而且這個判斷攻擊的閥值也沒法精確的設置，只能憑經驗以及分析網站的具體情況。

對于5，對用戶體驗會產生影響，并且長期下去，對網站形象也會產生影響。

總結下來就是，幾乎所有方式，都會產生或多或少的負作用，所以，任何一種防護方式，在沒事的時候不要開，只在被攻擊的時候開啟。

四，什么樣的網站容易被CC攻擊
在我處理過的CC攻擊中，主要消耗的是CPU和內存，通常在帶寬被占滿前CPU和內存已經爆掉。
而對于靜態網站，也就是生成HTML頁面的網站，靜態請求占用的CPU和內存是極低的，所以幾乎不太可能出現生成HTML后被CC攻擊掛掉的情況。
所以，被CC的主要都是動態網站，比如Discuz，Wordpress等。

五，都是什么人在攻擊
1)無聊惡作劇
2)打擊報復
3)敲詐勒索
4)同行惡意競爭

六，尾聲
今天遇到的一起攻擊事件，某網站被敲詐1萬塊(也就是前文中的截圖，網站有金盾防護，但是被肉雞穿透)。于是理了理思緒，寫下了這些經驗之談，與大家分享。