（CC）與（WAF）之間的較量

前言

在分享這個事件前，筆者先和你們一塊兒來了解一下CC***：

【 CC***】

 者藉助代理服務器生成指向受害主機的合法請求，實現DDOS和假裝就叫：CC(ChallengeCollapsar)。
CC主要是用來頁面的。CC的原理就是者控制某些主機不停地發大量數據包給對方服務器形成服務器資源耗盡，一直到宕機崩潰。CC主要是用來***頁面的，每一個人都有這樣的體驗：當一個網頁訪問的人數特別多的時候，打開網頁就慢了，CC就是模擬多個用戶（多少線程就是多少用戶）不停地進行訪問那些須要大量數據操做（就是須要大量CPU時間）的頁面，形成服務器資源的浪費，CPU長時間處於100%，永遠都有處理不完的鏈接直至就網絡擁塞，正常的訪問被停止。

 CC是DDOS（分佈式拒絕服務）的一種，相比其它的DDOSCC彷佛更有技術含量一些。這種***你見不到真實源IP，見不到特別大的異常流量，但形成服務器沒法進行正常鏈接。

引用百度百科https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545?fr=aladdin

酸爽的時刻

 某天下午，正要到下班點的時候，筆者的手機忽然振動一下，打開一看，是一條阿里雲發的短信。點進去一看，是公司某個項目中的服務器CPU報警的短信，報警內容震驚了!!!!!!

 服務器CPU爆了，緊接着又來收到好幾條短信，短信內容和上一條短信是同樣的，這個項目集羣中全部的服務器CPU都爆了，這還得了。網站可用性的報警短信也來了，打開網站和APP一看，打不開了，一直在「菊花中」，此時筆者的心情是很酸爽的，不知道各位有沒有體會過。

每每不少問題都是發生在一瞬間，讓你感受很「驚喜」， 因此運維人員的心理素質是要很強大的，在任什麼時候候都要能從容的面對一切刺激。

哪裏出了問題

先登陸服務器，服務器CPU幹滿的狀況下，登陸服務器的操做也會受影響的，先top看一下吧：

在登陸集羣中其它服務器看一下，也是同樣的：

這個項目以php程序爲主，因此集羣中的服務器除了php-fpm進程大量佔用了CPU之外，沒看到其它進程佔用，注意看上面的running值，正在運行的進程數量一直居高不下，大量的進程不釋放，莫非是調的PHP進程參數有問題，先來看下php的進程配置：

公司全部的服務器都是標準配置（CPU是16核，內存爲32G）。平均一個php-fpm進程佔用2M的內存左右，設置最大子進程數量爲800個，啓動進程爲100，這麼計算的話，參數都在合理的範圍內，不該該出問題。

pm.max_children = 800 #php-fpm最大的子進程數量
pm.start_servers = 100 #動態方式下的起始php-fpm進程數量
pm.min_spare_servers = 100 #動態方式空閒狀態下的最小php-fpm進程數量
pm.max_spare_servers = 200  #動態方式空閒狀態下的最大php-fpm進程數量

說明：php-fpm進程池開啓進程有兩種方式，一種是static，直接開啓指定數量的php-fpm進程，再也不增長或者減小；
另外一種則是dynamic，開始時開啓必定數量的php-fpm進程，當請求量變大時，動態的增長php-fpm進程數到上限，當空閒時自動釋放空閒的進程數到一個下限。這兩種不一樣的執行方式，能夠根據服務器的實際需求來進行調整。

ps、
iostat、
free、
iftop、等方式查看進程、io、內存及帶寬等狀況都沒有異常，也沒有收到其它的報警，ecs服務器、slb負載的流量均無異常，奇怪了？

先解決問題，拿一臺服務器重啓一下nginx、php服務。不行，重啓事後仍是同樣，CPU瞬間滿了。會不會php請求redis服務的時候找不到，一直卡在那裏。

登陸redis查看一下，redis內存、cpu、鏈接數等使用狀況都很穩定，服務器和redis的連通性測了也都Ok的：

這個時間點也沒有活動啊，趕忙查看下日誌吧。

問題來自CC***

查看一下nginx日誌，error.log並無拋出異常日誌，在來看看access.log：

發現可疑的請求了，tail -f access.log跟蹤了一段時間後，發現不少ip不停的請求這個url 「https://公司域名/captcha/new.html?height=35&********************=9999」 ，爲何會這麼多IP會不停的請求這個url呢？查看並測試，發現這個url是登陸頁的驗證碼，以下圖所示的驗證碼，用戶登陸時須要驗證碼才能登陸進去：

筆者開始猜想，會不會驗證碼被***了。先進入waf查看一下這段時間的業務量訪問狀況：

從waf的數據能夠看到，業務訪問量忽然抖增，咱們又沒搞活動，也沒有搞秒殺，這個點正常訪問量不會出現這樣的狀況的。在來看下waf全量日誌、waf總覽訪問狀況：

在來看看上面這張圖，筆者隨便截的一頁圖，每條GET都是來自於不一樣的IP，大概統計了一下，很多於上千個IP，此時有些朋友是否是想到了，把這些IP給限了。若是你去作IP限制，上千個IP去限制腦殼是否是要抓狂，何況你也不知道哪一個IP是真實用戶的請求IP。

在來看看其它圖表：

從上圖能夠看出，在waf的全量日誌中，也一樣發現和nginx同樣的日誌請求，被訪問次數顯示中，這個url一被請求了快30萬次了，試想一下，正經常使用戶誰會沒事一直點擊你的驗證碼。由此能夠得出被cc***了。

waf和cc之間的較量

即然被cc***了，確定要處理，若是不用waf的話，單靠在服務器上處理會如何解決呢？利用nginx或iptables限制單ip訪問次數、更改web端口、仍是屏蔽ip等，你們能夠一塊兒討論一下，有好的建議和方法能夠在留言一塊兒學習進步。

即然筆者這裏用了waf，下面來看看waf和cc之間會怎麼玩呢？

一、首先，進入自定義cc配置，以下圖：

二、根據以前查找到被***的URI，新增一條自定義規則,以下圖所示：

其含義爲：單個IP訪問目標地址（前綴匹配，也就是匹配到/captcha這一前綴URI的時候）時，一旦在5秒內訪問超過3次，就封禁該 IP20 分鐘。

說明：

• URI：指定須要防禦的具體地址。例如防禦一個用戶註冊的接口，/register。支持輸入參數，如 /user?action=login。
• 匹配規則：徹底匹配或前綴匹配。
  徹底匹配即精確匹配，請求地址必須與此處配置徹底同樣纔會統計。
  前綴匹配是包含匹配，只要是請求的URI以此處配置開頭就會統計（例如，/register.html會被統計）。
• 檢測時長：指定統計訪問次數的週期。須要和訪問次數配合。
• 單一IP訪問次數：指定在統計週期內，容許單個源IP訪問該URL的次數。
• 阻斷類型：指定觸發條件後的操做，能夠是封禁或人機識別。
  封禁：觸發條件後，直接斷開鏈接。
  人機識別：觸發條件後，用重定向的方式去訪問客戶端，經過驗證後才放行。
• 阻斷時間：指定執行阻斷動做的時間。

三、配置好了自定CC，咱們來看下效果有沒有起做用呢？以下圖所示：

從上圖黃顏色的線條能夠看出，自定義配置的CC***攔截起做用了，沒有攔截以前的時間段×××線條是不顯示的。

即然CC被攔住了，業務正常了嗎？回到服務器上查看，服務器的CPU確實已經恢復正常了，看下業務正常了嗎？

打開APP，網站，訪問公司的業務果真已恢復正常了。

等待了一段時間後，仍是有小部分用戶反饋打不開，這是什麼緣由呢，分析一下waf吧：

a,其實在waf上面自定義的CC規則配置是很是嚴格，在5秒鐘以內，單IP訪問訪問超過3次就封禁掉，這種嚴格的規則會誤殺掉不少真實的用戶請求，你須要根據公司的業務反饋，有沒有正常的用戶被攔截了，等CC***沒了，你在把策略規則調寬鬆一點（好比5秒、單IP40次/50次/60次等等去調整它），一句話，動態調整waf，不要調死。

b,還有，有些公司出口就一個Ip地址，客戶端有n多個，共用1個IP出去，像這種狀況可能每秒請求的數量就會比較多，這也是正經常使用戶的請求，像上面這種嚴格的規則也可能會被攔截了。

c,waf防火牆，經過人機識別、大數據分析、模型分析等技術識別，對進行攔截。但不一樣於與程序交互，安全是人與人的對抗，每一個網站的性能瓶頸也不一樣，會在發現一種無效後，分析網站後進行定向。此時，須要根據業務狀況來動態調整的，達到更高的防禦等級和防禦效果。

d,特別是首頁內容，不少時候是須要運維人員和開發一塊兒去分析、判斷哪一個接口或者URI容易受***（好比短信接口、驗證碼接口等），提早在代碼層，和安全層面作好防禦，防範於未然。

總結

 整體說來CC的防禦沒那麼簡單的，假裝手段也是千萬變化，CC屬於技術技巧強的。防護CC能夠經過多種方法，禁止網站代理訪問，儘可能將網站作成靜態頁面，限制鏈接數量，修改最大超時時間等。除了利用上述方法外，還能夠經過第三方的防火牆進行防範，也能夠省很多心。

本章內容到此結束，喜歡個人文章，請點擊最上方右角處的《關注》！！！