昨天一大早，我還沒到公司呢，就收到騰訊雲安全中心發來的服務器異常登錄告警，登錄控制台一看，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 開機啟動項：https://blog.csdn.net/zyddj123/article/details/82497640
2. redis 安全配置，漏洞和入侵檢查：https://blog.csdn.net/u011574239/article/details/78892174
3. Linux 配置取消密鑰登錄：https://blog.csdn.net/u013344860/article/details/80431835
4. ssh 私鑰存放位置（本文無關）：https://www.cnblogs.com/liuyanerfly/p/9668426.html
5. Linux 查看連接相關命令：https://www.cnblogs.com/felixzh/p/7737160.html
6. Linux 定時任務操作：https://www.cnblogs.com/cqlb/p/9772207.html
7. 另外，我還把黑客定時任務下載的腳本拷貝下來了，也對黑客進程的連接進行了抓包（找時間分析分析哈哈，不過使用加密傳輸的，估計沒戲），抓包命令教程：
https://blog.csdn.net/chinaltx/article/details/87469933
https://www.runoob.com/linux/linux-comm-tcpdump.html
好了，下班~