故障說明
-
故障環境配置
開發測試服務器（騰訊雲）；
系統：centos7 ；
程序啟動模式：root用戶直接啟動；
網絡環境：所有端口全部對外開放（使用僅屏蔽部分關鍵端口ssh,redis,rabbitmq等）；
為方便服務器間數據傳輸方便，采用了ssh互信方式。 -
故障現象
開發使用過程中，發現經常有服務無故關閉，登錄服務器經檢查，發現CPU使用率達到100%。
在檢測異常進程中，未發現CPU使用率異常的進程（使用top以及ps -aux進行檢查），於是報障。
檢測過程
開始以為系統運行異常，將其中一台進行重啟，重啟后問題依舊。通過上網查詢一番，得出可能是進程被隱藏。
- 使用工具進行查找進程
搜索到sysdig監控檢測工具
安裝使用方式：
###安裝
curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
###檢測所有程序已隱藏進程
sysdig -c topprocs_cpu
厲害，果然看到一個top及ps無法看到的進程在肆虐占用CPU
根據pid ，進入 /proc/目錄檢查程序位置
很奇怪的現象，進入
/proc/目錄后，無法看到該pid的目錄，僅可以直接進入
ll -h /proc/16352/
查看到程序文件源自於/usr/bin/pamdicks
檢測該文件時發現使用搜索的方式都無法檢測到該文件，find ，ls /usr/bin/pamd*等等都無法顯示，唯有全路徑才可以
ls -hal /usr/bin/pamdicks
根據隱藏進程以及隱藏文件不可見的特性，進行搜索分析，得出系統內核被篡改，將文件名稱和進程信息給屏蔽。
初步根據PID將程序kill及文件刪除，但是重啟后又自行恢復，還有其他機器，也經過一夜，死灰復燃了。
臨時處理辦法
奈何技術有限，修改內核這個玩不轉，也未找到相關反向修改的案例。
只能想出其他辦法解決該問題。
解決辦法：
-
根據系統環境變量，檢查各目錄下是否存在
pamdicks
共計有兩個/usr/bin/pamdicks和/bin/pamdicks -
刪除原文件，並創建一個頂包空文件，然后使用系統chattr對其進行鎖定禁止修改。
rm -rf /usr/bin/pamdicks /bin/pamdicks
touch /usr/bin/pamdicks /bin/pamdicks
chattr +i /usr/bin/pamdicks /bin/pamdicks
- 再根據
sysdig -c topprocs_cpu查到的PID直接殺掉
kill -9 16352
世間清靜了。
其他工具又發現更多隱藏進程
雖然將炸彈的火給藏起來，但是炸彈還在。繼續查找其他辦法。
又找到另一個工具unhide （經網友提醒，需先安裝epel源yum -y install epel-release）
yum -y install unhide
unhide quick
掃描后又發現多個的異常進程。
進程狀態和文件狀態與pamdicks 如出一轍。
只有使用相同辦法對其進行處理。
本次異常程序名稱：
pamdicks,ip6network,kswaped,irqbalanced,rctlcli,systemd-network
后記
處理過程中，已經檢查了init啟動項，crontab定時任務，at定時任務等配置，均未發現異常。
本次故障起因由以下三點引起：
1、大部分程序端口均直接暴露在公網，是本次問題主要原因。
2、程序為省事，均用root用戶直接啟動，導致內核被修改，問題難度復雜化。
3、因為服務器之間的ssh互信，結果導致所有服務器全部中招。
以后得加強注意這三方面的安全問題，本次木馬程序並未涉及文件防篡改配置，不然也只能重裝系統進行處理了。
后續得繼續研究如何從內核中將相關配置刪除，才能徹底全部查找到根源對其進行處理。