記錄惡意SQL隱碼攻擊引發的RDS只讀資料庫CPU飈100%

lucky_tomato發表於2024-03-19
SQL資料庫

前言: 在廣州這座城市下著小雨的晚上，我正在廚房洗著碗，突然手機有來電，脫下手套，一看是來自阿里雲的告警電話。開啟飛書檢視告警內容，發現某個業務的RDS只讀例項CPU飈到100%，下意識覺得是不是有慢查詢導致，想著不會有啥問題，上去kill慢查就好了，結果發現是大問題....
一、發現問題

2024年3月10號 21:22分左右，手機響起來自阿里雲的告警通知，確定了是阿里雲RDS報警,MySQL有一波連線數進來，資料庫CPU瞬間100%，MySQL連線數也觸發告警，10分鐘不到有35000多條慢日誌，同時阿里雲只讀庫進行了例項主備切換（故障切換）
問題影響了線上使用者登入和充值，當時工作群運營反饋問題，技術這邊也關注起來。

二、分析造成原因

業務執行的RDS是1主4只讀的架構，然後開啟資料庫代理，讀寫分離。
一開始以為是管理後臺有人在查資料，全表掃描或者檢視日期時間範圍很長導致只讀庫有慢查，因為之前出現過這種情況，結果看到控制檯幾萬條慢查詢。影響我判斷的告警來了，只讀例項出現故障進行主備切換，以為是例項出現問題，我立馬去找阿里雲客服問例項是否有問題，為什麼會主備切換了。結果技術客服回答，是因為有一波連線數進來，慢查裡面執行SQL有掃描行數很大的可以看看。然後就發現了下面這個關鍵語句,執行1127次，每次掃描3789828行導致CPU漲到100%，

SELECT *
FROM `table_info`
WHERE user_name = '　　      　              　'
        AND game_xxxx = '123abc'
        AND platform = 'xxxpay'
LIMIT 1

於是立馬反饋給該業務的開發，複製貼上到群裡，開發說user_name是空的，開發也很快修改程式碼釋出到線上，本以為就要結束了，結果還是有這樣的SQL進來，這就神奇了....然後懷疑user_name不是空的，會不會是空格，結果我複製出來到文字編輯器，因為開了符號顯示，發現user_name的值是空+空格，真想大白了，太可惡了。

三、解決辦法

開發同事修改程式碼，正則匹配過濾，業務恢復

四、個人反思

1、遇到類似問題，細心按照流程思路找問題，不要急
2、第一時間先把阿里雲告警臨時關閉，不然一直打電話影響排錯
3、檢視告警的只讀活躍會話，如果有執行特別長時間的SQL，立馬kill別影響業務。
4、如果慢查特別多，先對掃描行欄位進行排序，找出掃描行特別多的SQL再分析
5、事後總結，做好記錄，處理事故同時也得到積累和進步

　　

　　



相關文章