先說網站的狀態(tài)，BT面板，NGINX php，然后是用了cloudflare的才cnd.。表現癥狀，就是cpu滿載，然后負載也是滿的，就這下面兩個圖，然后訪問很慢，還會出現404錯誤。

　　看到這個癥狀可不行啊，本屌像呵護孩子一樣的站點一下子壞了可不行啊，馬上找原因，要么是服務器被人黑了占用服務器資源干些挖礦的勾當，要么就是網站被攻擊了，然后我就去把網站先關閉，cpu立刻使用率就下來了，毫無疑問問題就出在了網站層面，我再看看連接管理（這讓我走了很大的彎路）。

　　因為我用了cloudflare的才cnd，所以跟你網站本身連接的是cloudflare的IP（之前我是不知道的），看到都是那幾個IP在連接，而且一查還是美國的IP，錯誤的認為就是這幾個IP的大量請求，我就去把這幾個IP段給屏蔽掉，結果就是502錯誤。一開始我以為是CND那邊需要緩存我的頁面所以才會大量鏈接網站（這一錯誤的以為讓我耽誤很久，我想著緩存總是需要時間的，那會剛好是中午，就查了下美國的時間正好是半夜，想想也合理，人家半夜給你緩存呀）。后面等了很久，也沒見好轉，就感覺不對了。

　　認識到這一點后，我就去cloudflare的cdn去掉，DNS解析是要時間的不是，這里有浪費了很多時間，CND去掉了后，癥狀依然存在，可見這次的攻擊是基于網址的而不是IP地址，再去查看鏈接管理，就是下圖（這是正常后的截圖，攻擊的時候誰還有空截圖），框框里會有大量的IP 進程在等待，造成網站崩潰。

　　把這些IP都查了下，大部分是國外的IP，現在攻擊手段就明了了，用大量IP去請求網站內容，造成擁堵，正常訪問發(fā)生錯誤?，F在解決辦法就是怎么把這些IP給屏蔽掉，開始笨到一個個去屏蔽，太多了，而且都不是一個IP段的，這樣弄肯定會累死還解決不了。

　　后面一下既然大部分都是國外的，那就把國外的IP都屏蔽掉，然后網上找啊找方法，解決辦法就是在服務器上的防火墻給國內IP加白名單，然后禁止所有80端口，后面也確實實現了，下圖是實現后的防火墻狀態(tài)。

　　到這里呢，我再看了下cup使用率，確實下降了很多，這一招確實很有效，CPU使用率下降到了30%，在我以為問題解決之后，我就去研究cloudflare，然后發(fā)現里面有個防火墻很容易就達到屏蔽或者放行某一國家的IP，設置好規(guī)則（這里也告訴大家少走點彎路）。

　　到這里我就想了，創(chuàng)建防火墻規(guī)則容易呀，但是要知道了解了攻擊者的特征，才好添加規(guī)則不是，不然要么達不到效果要么造成誤殺。那會我也是這么想的，那怎么才能知道攻擊特征呢，答案就是日志，日志是這篇文的重點，就是因為沒有看日志的習慣，可以這么說，上述的經歷、解決辦法都是彎路。

　　我查看到當天的訪問日志后，不看不知道，一看就知道問題在哪，有大量的不同IP請求同一個頁面，并且referer都是同一個值，關于這個網站，我也去看了是個游戲輔助的，想不通干嘛要攻擊我，我網站又沒用戶數據，攻擊了也導不了流，難道只是在我后臺留下網址讓我去看看，好吧這個目的你達到了，還有比較小的可能就是他也是受害者。

　　既然你有這種特征那就比較好辦了，就又網上搜辦法了，就是下面的代碼了，

　　在nginx.conf的server配置項中加入

　　if （$http_referer ~* "www.xxx.com"） {

　　return 403;

　　}

　　然后給加上了，阿里云服務器的cpu終于正常了，就像第一張圖那樣的，今天我再去看日志，發(fā)現還在攻擊，不過現在都被403了。其實對于這次攻擊，有上面一句話就夠了，之前弄得防火墻都是不需要的，但是既然都設置了，本身網站也不需要國外的流量，就干脆留著了。

　　最后想說說的是，這次的攻擊八成是某個攻擊軟件，設定特定攻擊對象，然后改寫referer，所以才會這么有特征，要是厲害點的估計就會變寫參數，讓防攻擊工作更難。這次的經歷讓我白白浪費了一個周末，一是攻擊者的可惡，二也是自己沒有經驗，走了好多彎路，浪費時間。也告誡大家出了問題一定要先看日志，看日志，看日志！