[[319671]]

疫情仍在全世界蔓延，但在我國已得到有效控制，這不僅僅體現(xiàn)了一個國家的綜合實力，也體現(xiàn)了我們億萬國民團(tuán)結(jié)一心，才能一次一次的戰(zhàn)勝外界看起來不可抗擊的力量。國之戰(zhàn)神在于民心，團(tuán)結(jié)力量大。

同樣的道理，我們做為IT行業(yè)運維技術(shù)人員，不僅自身要實戰(zhàn)技術(shù)過硬，項目組組員也都要有質(zhì)量運維意識，才能一起共同做好線上線下系統(tǒng)運營運維技術(shù)保障，做好對眾多服務(wù)的非功能性、功能性等防控，確保服務(wù)的高可用性、高可靠性、高維護(hù)性、高穩(wěn)定性、高安全性等，確保企業(yè)業(yè)務(wù)運營正常。反之，如果組員對服務(wù)器上傳代碼工程包或者安裝部署某個服務(wù)控件時，不經(jīng)意間上傳了有危害性代碼、侵害性程序，會導(dǎo)致系統(tǒng)癱瘓。

在疫情期間，我們自身戴好口罩、強(qiáng)身健體;小區(qū)出入做好各種安防、出入證、量體溫;社區(qū)噴霧殺毒等。這就如同我們服務(wù)器設(shè)置好防火墻、配置好訪問端口、對于每個上傳文檔做好安全代碼掃描、定期做好性能測試等各類非功能指標(biāo)檢驗測試等，確保服務(wù)器正常運行。但一旦百密一疏，就會導(dǎo)致出問題。例如，這段時間我們某臺應(yīng)用測試服務(wù)器就出現(xiàn)CPU高、且無法正常登錄現(xiàn)狀，具體情況如下：

2月28日下午臨近六點時，開發(fā)人員突然發(fā)了截圖給我說187服務(wù)器無法登陸，問我是否修改了密碼，如下圖一：

(圖一)

想想這段時間只有安裝驗測運維監(jiān)控工具有用到187服務(wù)，但是也是10天前的事情，且沒有去修改過密碼，于是我也好奇登錄下看看，發(fā)現(xiàn)確實出現(xiàn)問題，重新輸入密碼也不行，如下圖二：

(圖二)

追根溯源：

發(fā)現(xiàn)187確實無法正常登錄，但是該提示信息說明該服務(wù)器沒有被關(guān)閉，只是ssh鏈接被篡改了，這時腦中第一反應(yīng)，入侵者使用了一個可執(zhí)行的SSH后門，而且這些組件以服務(wù)形式安裝來為惡意軟件提供駐留。

出于好奇和對剛部署監(jiān)控工具的可用性，我登錄運維服務(wù)監(jiān)控，發(fā)現(xiàn)還能收集187服務(wù)CPU等資源信息，如下圖三，只是CPU使用率偏高，應(yīng)該是使用了什么惡意軟件在為它自己提供服務(wù)，但也說明187服務(wù)還是可用，只是新建的ssh連接無法鏈接。

(圖三)

還好之前有一個惰性習(xí)慣，在另外一臺電腦打開一個CRT，用完很少去關(guān)。此時剛好有打開187等服務(wù)器沒關(guān)，還可以直接訪問，發(fā)現(xiàn)是TSM服務(wù)導(dǎo)致CPU 高，cron的內(nèi)存使用率偏高，問了下開發(fā)人員沒有該服務(wù)，發(fā)現(xiàn)都沒使用，就干掉為先。

于是就直接先kill掉，然后修改了下系統(tǒng)登錄密碼，但是還是要把問題追究到底，發(fā)現(xiàn)kill該進(jìn)程后發(fā)現(xiàn)CPU立馬掉下來，如下圖四：

(圖四)

通過查證：tsm64是負(fù)責(zé)通過SSH暴力破解傳播挖礦機(jī)和后門的掃描器，可以發(fā)送遠(yuǎn)程命令來下載和執(zhí)行惡意軟件。

看了下該進(jìn)程對應(yīng)的服務(wù)，安裝路徑配置路徑如下：

root 31803 31798 84 07:44 ? 08:36:57 /tmp/.X19-unix/.rsync/c/lib/64/tsm --library-path /tmp/.X19-unix/.rsync/c/lib/64/ /usr/sbin/httpd rsync/c/tsm64 -t 505 -f 1 -s 12 -S 8 -p 0 -d 1 p ip

發(fā)現(xiàn)該服務(wù)應(yīng)該只是一個shell服務(wù)，而且看了下遠(yuǎn)程監(jiān)控收集的記錄，發(fā)現(xiàn)是2月27日凌晨四點多的時候被侵入，植入病毒，導(dǎo)致CPU使用率高，也導(dǎo)致我們CRT無法正常登錄，如下圖五和圖六：

(圖五)

(圖六)

分析下應(yīng)該是有開啟服務(wù)進(jìn)程，才會導(dǎo)致CPU和內(nèi)存偏高，而引起內(nèi)存偏高的是cron進(jìn)程，于是通過crontab -e發(fā)現(xiàn)確實被開啟了進(jìn)程服務(wù)，如下圖七

(圖七)

接下來直截了當(dāng)，停止服務(wù)，然后刪除對應(yīng)路徑下文件和定時作業(yè)，繼續(xù)觀察兩天，如下圖8發(fā)現(xiàn)確實沒有再復(fù)現(xiàn)問題。

(圖八)

(圖九)

總結(jié)：

雖然本次問題從發(fā)現(xiàn)到解決總用時十來分鐘，但是純屬運氣下得以快速解決，也說明了服務(wù)非功能故障處理的多維性、運維技術(shù)人員技術(shù)思維發(fā)散性和知識全面性，主要還是要多實戰(zhàn)才是王道，本次問題主要原因是：

一、主因是服務(wù)器密碼設(shè)置過于簡單，導(dǎo)致被有機(jī)可乘。

二、服務(wù)器安全防護(hù)設(shè)置不夠完善。

三、項目組人員上傳文檔沒有進(jìn)行嚴(yán)謹(jǐn)審核導(dǎo)致上傳文件帶有病毒才導(dǎo)致本次問題引發(fā)。

四、服務(wù)器系統(tǒng)用戶登錄權(quán)限不夠完善。

五、碰到問題不恐慌、要靜心、要冷靜。

【作者】泊涯，公司分部測試經(jīng)理，集團(tuán)公司技術(shù)專家成員之一，目前主要在客戶現(xiàn)場做銀行系統(tǒng)的性能診斷分析優(yōu)化和測試管理工作。