[[319671]]

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

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

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

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

(圖一)

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

(圖二)

追根溯源：

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

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

(圖三)

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

于是就直接先kill掉，然后修改了下系統登錄密碼，但是還是要把問題追究到底，發現kill該進程后發現CPU立馬掉下來，如下圖四：

(圖四)

通過查證：tsm64是負責通過SSH暴力破解傳播挖礦機和后門的掃描器，可以發送遠程命令來下載和執行惡意軟件。

看了下該進程對應的服務，安裝路徑配置路徑如下：

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

發現該服務應該只是一個shell服務，而且看了下遠程監控收集的記錄，發現是2月27日凌晨四點多的時候被侵入，植入病毒，導致CPU使用率高，也導致我們CRT無法正常登錄，如下圖五和圖六：

(圖五)

(圖六)

分析下應該是有開啟服務進程，才會導致CPU和內存偏高，而引起內存偏高的是cron進程，于是通過crontab -e發現確實被開啟了進程服務，如下圖七

(圖七)

接下來直截了當，停止服務，然后刪除對應路徑下文件和定時作業，繼續觀察兩天，如下圖8發現確實沒有再復現問題。

(圖八)

(圖九)

總結：

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

一、主因是服務器密碼設置過于簡單，導致被有機可乘。

二、服務器安全防護設置不夠完善。

三、項目組人員上傳文檔沒有進行嚴謹審核導致上傳文件帶有病毒才導致本次問題引發。

四、服務器系統用戶登錄權限不夠完善。

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

【作者】泊涯，公司分部測試經理，集團公司技術專家成員之一，目前主要在客戶現場做銀行系統的性能診斷分析優化和測試管理工作。