記一次被自己DDOS攻擊

伺服器報警

初步分析

進一步分析

最終分析

總結toc

7月24號下午5點半開始，突然伺服器報警，檢查監控，發現cpu異常100%。

該伺服器正常情況下cpu使用率在40%已經算高了，另外負載經過除錯都保持在cpu承受範圍內。

系統負載同時飆公升

資料報的量直上雲霄

tcp連線數上2w，正常情況下最多6k

最開始沒有處理，一般來說ddos不會持續太久，結果7點伺服器開始響應變慢反饋，必須處理了，辛虧有隨身遠端應急預案。

此伺服器**半年沒動過，之前都正常的，只是中午的時候更新了下漏洞補丁，原則上是不會導致這個問題才對。通過linux命令分析了一下相關的程序，應該不是補丁導致的，否則打完補丁就應該出問題，而不是等到5點。

一開始為了應付cpu過高的問題，懷疑是我之前設定的php-fpm子執行緒過大（500），伺服器上下文頻繁切換，導致本身就已經高負載？索性就把值設為小到280試試看什麼情況，但是並沒有好轉，php-fpm慢日誌還建議調大，又調回之前的設定。

再來看資料報，已經要上天了，初步評估是ddos攻擊。

經過了1個多小時的日誌分析，定位到心跳寫資料庫異常，導致資料庫連線爆滿卡死，影響到了別的業務。所以禁用了該介面，伺服器相對可用。

晚上11點多回到家，依舊沒有恢復的意思，並且還出現了每隔5分鐘一次攻擊（00:16之後）。決定用cache的inc記錄看一下介面呼叫情況。

基本上是每秒1k+的訪問，偶爾會有高併發，短時間呼叫了76w+次，其他介面幾乎為0，現在是接近凌晨2點鐘，理論上裝置這個點鐘已經關的差不多了，而且預設裝置是5分鐘呼叫一次心跳介面，不可能在這個時候大面積併發。

ddos無誤，但是這個量好像有點小，並且一般也不會通過介面呼叫形式攻擊吧，阿里雲都沒有觸發ddos流量清洗。

接下來就是看哪個ip傳送的了。用netstate查了下感覺好像又比較正常。

根據該方法的日誌，看到這些ip在幾秒內呼叫介面300次左右，有些不可思議，但是這些ip確實是對應的裝置ip，難道是被自己的裝置ddos了？！

再來5分鐘一次心跳，不就是監控中後來的5分鐘一次異常情況？每五分鐘會出現一次峰值。

但是他們是如何做到秒級的百次呼叫呢？除非apk有問題，但是之前又沒見出現？

再次深入分析，嘗試禁封某些裝置ip無效，反而更加猖狂，應該是裝置apk集體出現bug了，導致例項化了n個執行緒同時進行介面呼叫……怎麼辦？裝置端的apk是友方開發，並且長時間沒有更新維護了，又沒辦法讓裝置重啟，最後決定分析裝置日誌。

第二天聯絡運維人員取了一台併發量很高的裝置日誌。剛好這台裝置記錄了事件的全過程，分析結果如下：

1、7月24號5點半之前，裝置運轉良好

2、之後出現心跳時token失效的情況，然後開始以指數級新增心跳執行緒。

可以看到重新獲取token之後，就出現了2個心跳包傳送請求

3、反編譯apk發現重新獲取token部分的**是有bug的

這裡應該是if和else，否則在沒有重新獲取到token的情況下，又立馬執行一次runnable，導致又再次報錯一次。

4、這個異常情況只會在token過期的時候出現，正常情況理論不會過期，所以這個bug一直沒有發現。

分析出問題之後，服務端臨時去掉了token校驗，聯絡友方修復bug，發布更新，問題解決。

昨晚搞到4點鐘，今天繼續分析到4點，歷時10個小時心中的石頭終於落下。

1、裝置端應至少有重啟指令，以防萬一。

2、乙個小小的邏輯**，可以使伺服器直接崩潰。

3、日誌監控真的很重要。

4、對於一些特殊情況，普通的測試很難遇到，除非是有經驗的測試人員，否則只能等線上才能發現了。