前言

在分享這個事件前，筆者先和大家一起來了解一下CC***：

創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于成都網(wǎng)站制作、成都做網(wǎng)站、建德網(wǎng)絡推廣、微信平臺小程序開發(fā)、建德網(wǎng)絡營銷、建德企業(yè)策劃、建德品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供建德建站搭建服務，24小時服務熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com

【 CC***】

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

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

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

酸爽的時刻

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

服務器CPU爆了，緊接著又來收到好幾條短信，短信內(nèi)容和上一條短信是一樣的，這個項目集群中所有的服務器CPU都爆了，這還得了。網(wǎng)站可用性的報警短信也來了，打開網(wǎng)站和APP一看，打不開了，一直在“菊花中”，此時筆者的心情是很酸爽的，不知道各位有沒有體會過。

往往很多問題都是發(fā)生在一瞬間，讓你感覺很“驚喜”， 所以運維人員的心理素質(zhì)是要很強大的，在任何時候都要能從容的面對一切刺激。

哪里出了問題

先登錄服務器，服務器CPU干滿的情況下，登錄服務器的操作也會受影響的，先top看一下吧：

在登錄集群中其它服務器看一下，也是一樣的：

這個項目以php程序為主，所以集群中的服務器除了php-fpm進程大量占用了CPU以外，沒看到其它進程占用，注意看上面的running值，正在運行的進程數(shù)量一直居高不下，大量的進程不釋放，莫非是調(diào)的PHP進程參數(shù)有問題，先來看下php的進程配置：

公司所有的服務器都是標準配置（CPU是16核，內(nèi)存為32G）。平均一個php-fpm進程占用2M的內(nèi)存左右，設置最大子進程數(shù)量為800個，啟動進程為100，這么計算的話，參數(shù)都在合理的范圍內(nèi)，不應該出問題。

pm.max_children = 800 #php-fpm最大的子進程數(shù)量
pm.start_servers = 100 #動態(tài)方式下的起始php-fpm進程數(shù)量
pm.min_spare_servers = 100 #動態(tài)方式空閑狀態(tài)下的最小php-fpm進程數(shù)量
pm.max_spare_servers = 200  #動態(tài)方式空閑狀態(tài)下的最大php-fpm進程數(shù)量

說明：php-fpm進程池開啟進程有兩種方式，一種是static，直接開啟指定數(shù)量的php-fpm進程，不再增加或者減少；
另一種則是dynamic，開始時開啟一定數(shù)量的php-fpm進程，當請求量變大時，動態(tài)的增加php-fpm進程數(shù)到上限，當空閑時自動釋放空閑的進程數(shù)到一個下限。這兩種不同的執(zhí)行方式，可以根據(jù)服務器的實際需求來進行調(diào)整。

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

先解決問題，拿一臺服務器重啟一下nginx、php服務。不行，重啟過后還是一樣，CPU瞬間滿了。會不會php請求redis服務的時候找不到，一直卡在那里。

登錄redis查看一下，redis內(nèi)存、cpu、連接數(shù)等使用情況都很穩(wěn)定，服務器和redis的連通性測了也都Ok的：

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

問題來自CC***

查看一下nginx日志，error.log并沒有拋出異常日志，在來看看access.log：

發(fā)現(xiàn)可疑的請求了，tail -f access.log跟蹤了一段時間后，發(fā)現(xiàn)很多ip不停的請求這個url “https://公司域名/captcha/new.html?height=35&********************=9999” ，為什么會這么多IP會不停的請求這個url呢？查看并測試，發(fā)現(xiàn)這個url是登錄頁的驗證碼，如下圖所示的驗證碼，用戶登錄時需要驗證碼才能登錄進去：

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

從waf的數(shù)據(jù)可以看到，業(yè)務訪問量突然抖增，我們又沒搞活動，也沒有搞秒殺，這個點正常訪問量不會出現(xiàn)這樣的情況的。在來看下waf全量日志、waf總覽訪問情況：

在來看看上面這張圖，筆者隨便截的一頁圖，每條GET都是來自于不同的IP，大概統(tǒng)計了一下，不少于上千個IP，此時有些朋友是不是想到了，把這些IP給限了。如果你去做IP限制，上千個IP去限制腦袋是不是要抓狂，況且你也不知道哪個IP是真實用戶的請求IP。

在來看看其它圖表：

從上圖可以看出，在waf的全量日志中，也同樣發(fā)現(xiàn)和nginx一樣的日志請求，被訪問次數(shù)顯示中，這個url一被請求了快30萬次了，試想一下，正常用戶誰會沒事一直點擊你的驗證碼。由此可以得出被cc***了。

waf和cc之間的較量

即然被cc***了，肯定要處理，如果不用waf的話，單靠在服務器上處理會如何解決呢？利用nginx或iptables限制單ip訪問次數(shù)、更改web端口、還是屏蔽ip等，大家可以一起討論一下，有好的建議和方法可以在留言一起學習進步。

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

1、首先，進入自定義cc配置，如下圖：

2、根據(jù)之前查找到被***的URI，新增一條自定義規(guī)則,如下圖所示：

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

說明：

• URI：指定需要防護的具體地址。例如防護一個用戶注冊的接口，/register。支持輸入?yún)?shù)，如 /user?action=login。
• 匹配規(guī)則：完全匹配或前綴匹配。
  完全匹配即精確匹配，請求地址必須與此處配置完全一樣才會統(tǒng)計。
  前綴匹配是包含匹配，只要是請求的URI以此處配置開頭就會統(tǒng)計（例如，/register.html會被統(tǒng)計）。
• 檢測時長：指定統(tǒng)計訪問次數(shù)的周期。需要和訪問次數(shù)配合。
• 單一IP訪問次數(shù)：指定在統(tǒng)計周期內(nèi)，允許單個源IP訪問該URL的次數(shù)。
• 阻斷類型：指定觸發(fā)條件后的操作，可以是封禁或人機識別。
  封禁：觸發(fā)條件后，直接斷開連接。
  人機識別：觸發(fā)條件后，用重定向的方式去訪問客戶端，通過驗證后才放行。
• 阻斷時間：指定執(zhí)行阻斷動作的時間。

3、配置好了自定CC，我們來看下效果有沒有起作用呢？如下圖所示：

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

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

打開APP，網(wǎng)站，訪問公司的業(yè)務果然已恢復正常了。

等待了一段時間后，還是有小部分用戶反饋打不開，這是什么原因呢，分析一下waf吧：

a,其實在waf上面自定義的CC規(guī)則配置是非常嚴格，在5秒鐘之內(nèi)，單IP訪問訪問超過3次就封禁掉，這種嚴格的規(guī)則會誤殺掉很多真實的用戶請求，你需要根據(jù)公司的業(yè)務反饋，有沒有正常的用戶被攔截了，等CC***沒了，你在把策略規(guī)則調(diào)寬松一點（比如5秒、單IP40次/50次/60次等等去調(diào)整它），一句話，動態(tài)調(diào)整waf，不要調(diào)死。

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

c,waf防火墻，通過人機識別、大數(shù)據(jù)分析、模型分析等技術識別，對進行攔截。但不同于與程序交互，安全是人與人的對抗，每個網(wǎng)站的性能瓶頸也不同，會在發(fā)現(xiàn)一種無效后，分析網(wǎng)站后進行定向。此時，需要根據(jù)業(yè)務情況來動態(tài)調(diào)整的，達到更高的防護等級和防護效果。

d,特別是首頁內(nèi)容，很多時候是需要運維人員和開發(fā)一起去分析、判斷哪個接口或者URI容易受***（比如短信接口、驗證碼接口等），提前在代碼層，和安全層面做好防護，防范于未然。

總結

?總體說來CC的防護沒那么簡單的，偽裝手段也是千萬變化，CC屬于技術技巧強的。防御CC可以通過多種方法，禁止網(wǎng)站代理訪問，盡量將網(wǎng)站做成靜態(tài)頁面，限制連接數(shù)量，修改最大超時時間等。除了利用上述方法外，還可以通過第三方的防火墻進行防范，也可以省不少心。

本章內(nèi)容到此結束，喜歡我的文章，請點擊最上方右角處的《關注》?。?！