一次Ubuntu下的排雷記錄

起因

某天,發現一臺服務器上出現了一個大量佔用cpu資源的進程。嘗試手動殺掉,但很快就會自動重新創建新的進程。

追查

用命令lsof -p 10316 查看其文件路徑:

該進程文件夾/proc/10316下:


看到該文件夾下的exe文件是指向/var/tmp/.../Word,也就是文件夾名字就是"...",查看簡要的信息:

其中:
cmdline — 啓動當前進程的完整命令
environ — 當前進程的環境變量列表,彼此間用空字符(NULL)隔開;變量用大寫字母表示,其值用小寫字母表示
cwd — 指向當前進程運行目錄的一個符號鏈接
exe — 指向啓動當前進程的可執行文件(完整路徑)的符號鏈接,通過/proc/N/exe可以啓動當前進程的一個拷貝
文件介紹

查看cmdline文件發現:

說明這個進程是通過該命令啓動的,通過查看進程狀態也證實了這一點:

爲了查找上面cpmg文件的路徑,使用find命令find / -name cpmg49nhiCCK4u2Lvt2Y9Tasf8wpnkEYBoeVanWwuFJJRaHMhfPTr5C6QFb4,找到一大堆文件的路徑:

文件路徑基本都是來源於/proc/

事情陷入了僵局。回到原處,嘗試從啓動進程的命令本身尋找線索。

postgres 10316  374  0.0 408984 13844 ?        Ssl  Aug29 202:19 sh                                                          cpmg49nhiCCK4u2Lvt2Y9Tasf8wpnkEYBoeVanWwuFJJRaHMhfPTr5C6QFb4 -o stratum+tcp://monerohash.com:5555 -p x -k -B -l Word.txt --donate-level=1

找到上述exe所指向的可執行文件Word,查看其目錄發現:

Word是可執行文件,Word.txt是一個不斷增長的類似於日誌一樣的文件,通過tail –f Word.txt的結果如下:

由此大概可以知道前面的啓動命令是什麼意思了,就是通過與其他機器建立連接,不斷地上傳數據。
但是仍然不知道它具體是怎麼操作的,於是乎上谷歌查了一下stratum+tcp://monerohash.com:5555這個東西,發現有網友出現過相同的問題,另有網頁1介紹:

原來是些挖礦的病毒程序,上面的情況說明了自己的服務器已經被別人用作挖礦了。相似的網站還有下面這些
stratum+tcp://mine.moneropool.com:8080
stratum+tcp://mine.moneropool.com:3336
stratum+tcp://xmr.hashinvest.net:443
stratum+tcp://xmr.hashinvest.net:5555
stratum+tcp://monero.crypto-pool.fr:3333
stratum+tcp://monerohash.com:5555
stratum+tcp://mine.xmr.unipool.pro:3333
stratum+tcp://xmr.prohash.net:5555
stratum+tcp://xmr.miner.center:2777
stratum+tcp://mine.xmr.unipool.pro:80
stratum+tcp://pool.minexmr.com:7777
stratum+tcp://cryptonotepool.org.uk:7777
stratum+tcp://mro.poolto.be:3000

這樣基本可以定位這裏就是挖礦程序的源頭。
仔細分析其中的文件:
/var/tmp/…/a

cron.d文件

run文件

udp文件

x文件

基本可以定位它無法殺死的原因就是加入了一個隨時的定時任務,一旦殺死就會自動重啓。

查看該用戶的定時任務列表,當前用戶默認只能看到自己的定時任務,所以需要sudo。

sudo crontab –l –u postgres

確實發現了該定時任務:

crontab命令選項基本只有對用戶操作的選項:
-u 指定一個用戶
-l 列出某個用戶的任務計劃
-r 刪除某個用戶的任務
-e 編輯某個用戶的任務

既然定位了問題,接下來就是解決該問題。
首先要做的就是刪掉該定時任務:

sudo crontab –u postgres –r 刪除

crontab命令

然後刪掉對應的執行文件:

sudo rm –r …/

最後關停掉對應的所有該用戶下的進程:

pkill –u postgres

kill -9 10316

至此該問題終於得到解決。

總結

是什麼原因導致該病毒文件被放到服務器中?
現在想到的一種可能是登錄用戶的密碼被破解了。由於前面涉及的用戶是postgres,所以可能的情況是有人用默認的用戶名和密碼進行嗅探登錄。幸虧該用戶沒有根權限。但是需要引起注意的就是:

1、 能不創建用戶就不創建用戶
2、 能禁止登錄就禁止登錄
3、 密碼要儘量複雜
4、 變更默認端口防止嗅探

完。

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