引言~
今天登上去我的小vps修改一下CS配置，登錄之後感覺vps異常的卡頓，第一時間使用top確認服務器是不是中了挖礦，簡單排查後並未發現有挖礦的存在，隨後習慣性的使用lastb查看服務器是否存在異常登錄事件；回車後一看，發現俺的小vps慘遭爆破，爆破失敗次數高達18w次！並且就在我登錄成功之後，仍舊有爆破的日誌在產生，之前天天過去甲方應急，現在終於輪到自己了~~
身爲一名安全從業者，立馬展開對vps的安全檢查，一頓操作過後，並未發現服務器受到實質性的危害，但目前爆破的動作還在，由於是廉價vps，這樣不要命的爆破會嚴重拉低服務器性能，爲了應對此次事件，故有了下文：
事件排查及處理
由於大量的爆破導致服務器異常卡頓，目前首要任務就是先把服務器穩定下來；netstat -anpt 查看端口情況，發現22端口和80端口存在異常外鏈；因爲這個vps部署了個測試站點，查看web日誌時，發現大量可疑目錄請求，這裏初步判斷攻擊者的動作爲:web目錄掃描和ssh弱口令爆破,得出這兩個異常點後，馬上對這兩個異常端口進行流量封堵
關於linux下的病毒查殺可參考下面文章：
https://blog.csdn.net/chest_/article/details/106338221
由於我vps上的web服務萬年不用，所以直接簡單粗暴的把web服務停了，之後直接把web端口更改，80端口停用~~
對於ssh的處理，我這邊是選擇直接更改ssh端口，把22端口改爲其它高位端口，從而減少被掃描成功的風險
vim /etc/ssh/sshd_config #修改ssh默認端口
service sshd restart #重啓ssh
一切修改完成後，重啓服務器；當再次登錄服務器檢查，發現服務器流暢的飛起(假的)，廉價vps，再怎麼優化也還是卡啦，不過相比剛剛，確實流暢了不少
既然事情處理完成了，那就簡單分析一下這個殭屍網絡吧
殭屍網絡分析
查看日誌可清晰的看出攻擊者爆破痕跡，再次分析日誌後，可得出攻擊者最早開始爆破的時間爲：2020.6.15 12.25 ，由於我寫這篇文章時，已經處理好該事件，故停止攻擊時間爲：2020.6.25 23.30 ；通過分析可知，攻擊者在接入殭屍網絡後，採取了多個常用賬號對我的vps進行爆破，但由於本vps口令複雜，故爆破失敗；
通過分析，可以確認以下爆破ip均爲殭屍網絡，由於ip數量較爲龐大，故選取了top20樣本分析
樣本ip:
106.112.141.204
106.53.58.58
106.55.43.74
106.53.226.91
106.52.6.46
106.52.142.15
106.55.145.129
45.141.84.10
106.53.250.19
91.134.153.184
45.85.219.189
106.12.242.93
52.4.246.20
106.13.114.206
61.2.141.136
31.184.198.75
106.55.248.142
51.91.100.177
176.223.126.113
137.74.54.147
隨機挑了幾個樣本IP進行分析，發現這些IP或多或少都存在一些高危漏洞，攻擊者也正是利用這些漏洞，纔將這些受害IP納入了殭屍網絡的一員，比如下圖的redis未授權訪問漏洞：
這些樣本IP多數來着境外，由於IP數量龐大，所以沒有逐個分析，本來還想着滲透一波這些站點，但後來想到，雖說是境外的站點，但是滲透測試還是授權的情況下再搞吧，國內非授權測試被獎勵銀手鐲的案件並不少見，何況咱是遵紀守法的好公民~~
之後經過多手法分析，發現這些殭屍網絡只針對弱口令和網站備份文件這類漏洞進行利用，但由於服務器均不存在此類漏洞，故沒被納入殭屍網絡的一員；看了下時間，凌晨12點多了，如果真的要溯源，那得消耗大量時間，況且是一個這麼龐大的殭屍網絡，所以也就洗洗睡了~~
小結
由於服務器沒有受到實質性的危害，所以也就簡單分析下了事了，對於應急溯源，前前後後共做了10多次，每次應急事件出現，幾乎都是自己一個去搞的，所以對於應急，雖然不能說是很強了，都是處理起來還是不差的；應急響應和滲透測試也做了挺長一段時間了，存了好多實戰的報告，這裏面大多都包含了我滲透測試和處理應急事件的一些個人思路及方法，但目前實習階段，也正準備跳槽了~~，這個就有時間在寫吧。
下面是一些處理建議，因業務而異：
1.定期對系統進行全面的安全檢查和安全評估；
2.禁掉不必要的端口，在不影響業務的情況下，可將常見端口更改爲高位端口，以避免掃描成功的風險；
3.網站的備份文件不要就刪除，千萬不要放到web目錄下！對於弱口令，千萬不要用，尤其是在公網業務，做好這幾點，可大大減少被攻擊成功的概率；