久久国产成人av_抖音国产毛片_a片网站免费观看_A片无码播放手机在线观看,色五月在线观看,亚洲精品m在线观看,女人自慰的免费网址,悠悠在线观看精品视频,一级日本片免费的,亚洲精品久,国产精品成人久久久久久久

分享

阿里云CentOS木馬查殺

 liang1234_ 2017-10-01

一,、背景

這兩天發(fā)現(xiàn)自己的阿里云服務器上CPU基本都是打滿的,,$> top查看了一下,,盡是些亂七八糟命名的進程,,也是醉了:

1.png

$> ll /proc/22303看了一下,擦,,我啥時候在/usr/bin/下放過這東西了,。。,。

2.png

且殺之:

kill 22303 rm -f /usr/bin/lrzzxgbatw

以為一切都好了,,過了兩分鐘再$> top看了一下,尼瑪,,又一個不認識的東西出來了,,CPU又吃滿了,重復之前的方式,,再殺了一次,。。,。

repeat,。。,。repeat,。。,。repeat,。,。。

二,、排查

寫了一個簡單的crontab程序來監(jiān)控CPU占用最多的程序,,都是啥:

#! sh mail_to='[email protected]' virus_found=1 log_path='/home/work/what-virus.log' # 白名單進程 process_white_list='svn node mysql memcache redis nginx' # 找到CPU占用最大的進程 process_result=$(ps auxw --sort=-%cpu | head -n 2 | tail -n 1 | awk '$3>50{print $0'\n'}') for $w in $process_white_list;do gpr=$(echo $process_result | grep $w) if [[ x'$gpr' != x ]];then virus_found=0; break; fi done # 發(fā)現(xiàn)真的有異常進程,則郵件報警 if [[ $virus_found == 1 ]];then echo $process_result >> $log_path echo $process_result | mail -s 'virus found!' $mail_to fi

的確,,短短的時間內,,報警一直在持續(xù),而且,,從報警內容中能看到,,真正在執(zhí)行的命令,都太簡單:

root 24000 63.7 0.0 21316 468 ? Ssl Jan13 275:03 pwd root 24000 63.7 0.0 21316 468 ? Ssl Jan13 275:03 su root 24000 63.7 0.0 21316 468 ? Ssl Jan13 275:03 ls

好吧,,就是這些簡單的命令,,大批量執(zhí)行,搞掛了,。,。。

三,、重啟

想著,,實在懶得花時間去跟到底了,試一試萬能的重啟吧,,結果,,事不遂人愿,重啟了還尼瑪一個樣,,那沒辦法,,我只能猜測,這玩意兒已經(jīng)是自動啟動了,,于是檢查了一下這兩個東西:

1,、chkconfig --list

lrzzxgbatw 0:關閉 1:啟用 2:啟用 3:啟用 4:啟用 5:啟用 6:關閉 qzaclxgbjwo 0:關閉 1:啟用 2:啟用 3:啟用 4:啟用 5:啟用 6:關閉

果然發(fā)現(xiàn)多出來這兩個,什么鬼東西,,果斷chkconfig --del掉,!

2、vi /etc/rc.local

cp /lib/udev/udev /lib/udev/debug && /lib/udev/debug

這又是什么東西,,也不是我親自加的啊,,陌生的東西都刪掉!

這尼瑪一定有鬼,,看來,,是必須要花時間繼續(xù)分析的了。。,。

四,、定位

猜測應該是用crontab定時拉起來的一堆木馬,于是查了下crontab的內容,,果然:

1,、/etc/crontab

*/3 * * * * root /etc/cron.hourly/cron.sh */3 * * * * root /etc/cron.hourly/kill.sh

這兩個定時任務,并非我親自加的,,那就應該有鬼了,,繼續(xù)看這兩個*.sh文件

2、/etc/cron.hourly/cron.sh

#!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done cp /lib/udev/udev /lib/udev/debug /lib/udev/debug

3,、/etc/cron.hourly/kill.sh

#!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done cp /lib/libkill.so /lib/libkill.so.6 /lib/libkill.so.6

為毛別的系統(tǒng)都沒有這兩個東西,,而且內容還這么古怪,單看cron.sh基本能分析出來它的毒害原理了,,我的猜測:

  • /lib/udev/udev是病原體
  • 通過cron.sh每隔3min自動檢測一次,,如果木馬程序不存在,就從病原體復制一份兒到/lib/udev/debug
  • 副本/lib/udev/debug執(zhí)行,,生成一個隨機命名的程序,丟到/usr/bin/,、/boot等目錄
  • 同時修改了自啟動配置chkconfig --add xxx
  • 同時修改自啟動項/etc/rc.local

五,、解決

問題定位了,就好解決了

  • 刪除病原體/lib/udev/udev以及其副本`/lib/udev/debug
  • 刪除/usr/bin/,、/boot/下可疑的程序
  • 刪掉自啟動配置中可疑的item:chkconfig --del xxx
  • 刪掉可疑的自啟動項:vi /etc/rc.local
  • 刪除/etc/crontab下可疑的任務
  • 刪除/etc/cron.hourly/下可疑的sh腳本
  • 重啟,,這一步可能只是一個心理安慰

六、回頭再想想

木馬程序為毛會出現(xiàn),,而且是root賬號下,,應該是之前風靡的redis漏洞引起的吧,只怪我修復的太晚,! 另外,,從/var/log/sercure日志也能分析出來,系統(tǒng)的確存在root賬號暴力破解,,算了,,root太危險,索性禁用掉吧,!

    本站是提供個人知識管理的網(wǎng)絡存儲空間,,所有內容均由用戶發(fā)布,不代表本站觀點,。請注意甄別內容中的聯(lián)系方式,、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權內容,,請點擊一鍵舉報,。
    轉藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多