前言

?

前段時間客戶現場被攻擊，客戶找到了公司，公司找到了我，于是有了這一次的應急響應，因為第一次搞，所以記錄一下整個過程。

一、要做什么

剛開始不知道干啥，非常迷茫，通過老大的教導，事后總結了下面幾條個人覺得非常重要的點。

1.事件確認，發生什么事情了，什么事件，是否緊急，影響程度等。

2.確定攻擊動機，別人為什么攻擊我們。

3.確認攻擊手段，利用什么漏洞進行攻擊的，我們的應用是否存在高危漏洞，還是某一個中間件，還是其他攻擊手段。

4.制定解決方案，包括臨時解決方案和最終結局方案。臨時解決方案為了快速應對問題，最終解決方案為了徹底解決問題。

5.追蹤溯源，盡可能確定攻擊者的身份。

6.形成書面報告。說明時間的起因經過結果，說明事件的責任歸屬(誰的鍋)J。

二、詳細過程

有了上面的指導，就可以第一次的應急響應了。

1. 事件確認

客戶給公司反映有人投訴說收到了大量的短信驗證碼，然后登陸了服務器發現了大量短信驗證碼請求。

紅色標記的就是失敗的次數，非常的多，可以確認有人在利用短信驗證碼接口進行攻擊。

2. 攻擊動機

因為是大量短信驗證碼，所以攻擊動機就有了兩種：（1）有人盯上了我們的客戶，在惡意消耗我們的資源(但是我們客戶是公安),所以可能性不大。(2)我們的服務器被利用了，有人在利用服務器對特定的人進行短信驗證碼攻擊，我們只是其中的一條。所以很可能是短信驗證碼轟炸平臺利用了我們的資源。

后面給投訴用戶打了電話，投訴的人告訴我們，他收到了很多平臺的短信驗證碼，他的同事也收到了(可以確定是短信驗證碼轟炸).

3.攻擊點分析

首先先和開發確定了哪些接口都可以發送短信驗證碼，確定有三個可以發送短信驗證碼的。

#注冊接口，可獲取驗證碼 /api/user/smsxxxx?mobile=xxxx /api/user/sms?mobile=xxxx&xxxxx #登錄接口 可獲取驗證碼 /sendLoginMobilexxxx

通過開發確定了我們的應用存在下面的機制:每個用戶每天只能發10條，每個IP可以發送100條。所以我們先確定了自己的機制是否生效，確定短信驗證碼機制是生效的，這里不存在安全問題。

于是我繼續查看了我們的一個注冊接口，發現獲取短信驗證碼不需要輸入圖片驗證碼。如下圖所示，可以直接請求短信驗證碼，所以才導致可以大量的爆破。

看到這里就知道我們產品的問題了，好的產品都會在獲取短信驗證碼前需要一個手工驗證防止爆破的。

4. 制定解決方案

我以為到這里就結束了，直接上圖片驗證碼就好了。結果開發告訴我，這個功能他們原來有，下線了，因為很多老年機加了這個功能無法收到短信驗證碼？這是什么情況？事情果然不簡單，此處應該有圖片.jpg

臨時解決方案

所以我們先確定了臨時的解決方案，修改短信驗證碼發送配置:(1)每個用戶一天只能發五條，一個IP只能發10條。(2)當一個IP發送的數量超過100條后，日志中會記錄大量的錯誤+ip這樣的信息。所以我們可以根據這個信息來進行IP封鎖。

最終解決方案

上圖片驗證碼功能

5. 流量統計，進行封IP處理

因為日志都存儲在ES上，而訪問ES要先登錄VPN，再訪問堡壘機，再訪問虛擬機，然后從ES上導出日志，然后從堡壘機上下載日志。非常復雜，所以這一個階段花費了大量的時間，并且效果也不是很好。（只拿了兩天的日志量，大概有100G）

這是我下載下來的日志，日志中包含了大量的報錯等無用信息，因為我需要的日志都是以2020開頭的，所以寫了簡單的腳本將信息進行過濾。

fileDir= "F:\xxx\xxxx\log3" files=os.listdir(fileDir)with open("result3.txt", "w") as f:for file in files:filePath=fileDir+"\\"+filefor line in open(filePath, encoding="utf-8"):if line.startswith("2020-"):f.write(line) f.close()

過濾后的流量主要有兩種是我要的，第一種就是發送過多，會記錄ip和手機號碼。第二種是成功發送的。

2020-12-17 21:35:46.035 ERROR 7 --- [-8080-exec-1974] c.d.e.w.common.utils.CheckIpSmsPrevent : send.message.over.the.limit,ip=111.229.73.67,mobile=138xxxxx12 2020-12-17 21:35:46.072 INFO 7 --- [-8080-exec-1347] c.d.e.w.common.message.SmsCodeRedisDao : get code me 1350xxxxx70 redisKey [117, 97, 97, 58, 109, 101, 58, 99, 111, 100, 101, 58, 49, 51, 53, 48, 54, 56, 50, 54, 48, 55, 48]

因為數據量太大了，所以想著用sql去統計會方便一些，就寫了下面的腳本。提取了時間，ip地址和手機號。

import re#匹配時間 pattern=re.compile("2020-[0-9]{2}-[0-9]{2}.*[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}") #匹配電話號碼 pattern2=re.compile("1[0-9]{10}") #匹配ip地址 pattern3=re.compile("[0-9]{1,3}\.[0-9\{1,3}\.[0-9\{1,3}\.[0-9]{1,3}")filePath = "F:/xxxx/xxxx/results/result3.txt" with open("sqlResult3.txt", "w") as f:for line in open(filePath):try:if "INFO 7" in line:time =re.findall(pattern, line)[0]phone = re.findall(pattern2, line)[0]ip = '0.0.0.0'f.write(time + ',' + phone + ',' + ip + '\n')elif "ERROR 7" in line:time = re.findall(pattern, line)[0]phone = re.findall(pattern2, line)[0]ip = re.findall(pattern3, line)[0]f.write(time + ',' + phone + ',' + ip + '\n')except:pass f.close()

最后將數據導入到mysql中，一共有600w行數據，通過sql語句進行了查詢和判斷，如下圖所示，兩天的數據量失敗次數在2000次以上的就有500多個ip，這個池子還是很大的，然后查了一下其中的部分ip，發現都是阿里云，騰訊云什么的，應該都是肉雞。

因為存在大量的國內ip地址，又對ip地址的歸屬地進行了判斷。最后發送給一線同學進行ip封鎖。

總結

這次應急其實挺簡單的，但是因為vpn，堡壘機不好導出日志花費了很多時間。因為是第一次做，所以做一次整體思路的筆記，為下一次應急做好充足的理論和流程準備。

總結

以上是生活随笔為你收集整理的一次短信验证码攻击的应急响应的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。