一次騰訊雲centos服務器被入侵的處理

　　昨天一大早，我還沒到公司呢，就收到騰訊雲安全中心發來的服務器異常登陸告警，登陸控制檯一看，ip仍是美國的，一臉懵逼。因爲本人以前也沒有過處理服務器入侵的經驗，並且這臺服務器目前尚未部署商用系統，因此也就沒怎麼在乎，照着雲安全中心提示的可疑文件的位置，將其刪除，就這樣交差了。其實我知道這樣確定是不行的，可是確實很煩去處理這種事情。果真，下午又收到了告警。這是公司的電腦，老闆很在乎，恰好手上的事情忙完了，今天就特地花時間查了查，記錄一下排查過程。

　　首先，仍是上控制檯，看一下告警的信息，告警顯示的登陸ip來自美國，登陸帳號居然仍是 root （感受好牛批。以前我本身我的的服務器被入侵，仍是被建了一個 test 用戶進行操做的。），告警信息提示能夠文件有兩處：

　　　　/tmp/SzdXM 和 /usr/bin/dznqfa4

　　　　

 

 

 　　　　

 

 

 　　此次我沒有急着把他們刪除，而是先查看一下進程，果不其然，有幾個對應的進程：

　　　　

 

 

 　　查看完進程，再看一下鏈接，發現這些進程打開了 100 多個鏈接，而且鏈接的目標ip都不一樣：

　　　　

 　　雖然查到了進程和鏈接，但這隻能證實服務器確實被入侵了。可是怎麼入侵的呢？其實個人 root 密碼是20+位數字大小寫字母和特殊符號組合密碼，想來應該不會是暴力破解吧。而後想起了雲服務器上的提示提升redis安全性告警，又想起了以前看到網上說 redis 任意文件寫入的漏洞。因而去網上查了下 redis 的安全性問題。從下面這篇博文中獲得了提示：

　　　　https://blog.csdn.net/u011574239/article/details/78892174

　　　　這篇文章中提到了 redis 的三條入侵特徵：

　　　　　

 

 

　　　　因而我就對照這三條逐一檢查：

　　　　　　1. 查看redis 的執行記錄，查看 /root/.rediscli_history 文件，結果以下圖。能夠看出，確實執行了 flushall 命令（正常業務誰去執行這玩意啊）。好了，第一條應驗了：

　　　　　　　　

 

 

 　　　　　   2. 查看能夠鍵值對。這個沒有查到，沒查到很正常啊，都執行過 flushall 了。

　　　　　　3. 查看 /root/.ssh/authorized_keys 文件，確實存在一個 rsa 公鑰。好了，第三條也應驗了。

　　　　　　　　

 

 

 　　既然特徵都應驗了，那看來極可能就是經過 redis 入侵的了。既然如此，redis 配置確定是要改了。結合上面提到的那篇博客的內容提示，咱們能夠對 redis 作以下修改：

　　　　1. 以低權限運行redis。爲 redis 單首創建用戶和主目錄，配置該用戶禁止遠程登陸；

　　　　2. 爲 redis 添加密碼校驗；

　　　　3. 添加 redis 訪問白名單，拒絕陌生ip的訪問；

　　　　4. 禁止一些 redis 高危命令；

　　　　5. 修改 redis 服務端口，在安全組中關閉默認的 6379 端口；

　　

　　另外，不要覺得查到了緣由，就能夠動刀子，開始殺進程、刪文件、改端口、改密碼重啓，而後就萬事大吉了。服務器既然已經被入侵過了，說明極可能還留有其它後門。咱們應該還須要檢查開機自啓動項和定時任務。說實話，開機自啓動的那些服務，我是真看不懂都是幹嗎的（這就很慌了）。幸虧的是咱們還有另一臺跟這一臺軟硬件版本徹底同樣的服務器，那一臺沒有被入侵，我就將兩臺服務器的開機啓動項對比着看，卻是沒有發現什麼可疑啓動項。

　　不過查到了定時任務有問題：

　　　　

 

　　說明咱們還須要刪除定時任務。

　　從定時任務下載的文件內容看，定時任務執行時會從遠程主機下載 i.sh 腳本，查看其內容：

　　　　

 

 

 　　能夠看出，這個定時任務自己會下載腳本建立新的定時任務，因此爲了防止死而復生，咱們應該先從雲控制檯安全組將這個腳本的下載地址和端口拉入黑名單。同時將 redis 端口禁用掉。

 

　　排查完了，接下來捋一下思路：

　　　　1. 安全組配置，將 68.183.140.39:8000 禁止出方向訪問；

　　　　2. 禁用 6379 端口；

　　　　3. 中止 redis 服務；

　　　　4. 刪除定時任務；

　　　　5. 刪除可疑的開機啓動項（若是有）；

　　　　6. 清空 /root/.ssh/authorize_keys；

　　　　7. 中止對應的黑客進程；

　　　　8. 刪除黑客文件；

　　　　9. 關閉服務器；

　　　　10. 修改服務器 root 密碼；

　　　　11. 配置 ssh 設置，禁用公私鑰登陸（看須要）；

　　　　12. 從新配置 redis 服務，開放新的 redis 服務端口；

 

　　思路理清楚了，接下來動手操做：

　　　　1. 登陸雲服務控制檯，修改安全組配置，禁止對黑客服務器的訪問，禁止 6379 端口；

　　　　2. 中止 redis 服務：

　　　　　　ps -ef|grep redis

　　　　　　kill -9 pid

　　　　3. 刪除定時任務：

　　　　　　crontab -r /var/spool/cron/root

　　　　　　crontab -r /var/spool/cron/crontabs/root

　　　　　　若出錯：

　　　　　　　　cat /dev/null > /var/spool/cron/root

　　　　　　　　cat /dev/null > /var/spool/cron/crontabs/root

 

　　　　4. 清空公私鑰受權文件：

　　　　　　　　cat /dev/null > /root/.ssh/authorized_keys

　　　　　　　　cat /dev/null > /root/.ssh/known_hosts

　　　　5. 中止對應的黑客進程：

　　　　　　　　ps -ef|grep dznqfa

　　　　　　　　kill -9 pid

　　　　6. 刪除黑客文件：

　　　　　　　　rm -rf /usr/bin/dznqfa*

　　　　7. 上控制檯，關閉服務器

　　　　8. 上控制檯，修改服務器密碼

　　　　9. 開機，配置 ssh ，禁用公私鑰登陸

　　　　10. 從新配置 redis，啓動服務，開放新端口，從新部署應用

 

【附：參考文章】

　　1. 查看 Linux 開機啓動項：http://www.javashuo.com/article/p-fdxfuucg-gd.html

　　2. redis 安全配置，漏洞和入侵檢查：https://blog.csdn.net/u011574239/article/details/78892174

　　3. Linux 配置取消密鑰登陸：https://blog.csdn.net/u013344860/article/details/80431835

　　4. ssh 私鑰存放位置（本文無關）：http://www.javashuo.com/article/p-zygxjurl-mw.html

　　5. Linux 查看鏈接相關命令：http://www.javashuo.com/article/p-nfumyvhj-mw.html

　　6. Linux 定時任務操做：http://www.javashuo.com/article/p-gwzfnwuc-mv.html

　　7. 另外，我還把黑客定時任務下載的腳本拷貝下來了，也對黑客進程的鏈接進行了抓包（找時間分析分析哈哈，不過使用加密傳輸的，估計沒戲），抓包命令教程：

　　　　https://blog.csdn.net/chinaltx/article/details/87469933

　　　　https://www.runoob.com/linux/linux-comm-tcpdump.html

 

　　好了，下班~