數棧雲MSP運維服務案例：某客戶生產服務器CPU異常抖動

1、問題背景

某日袋鼠雲運維小哥進行例行運維巡檢，經過監控視圖發現客戶應用服務器cpu使用率忽然呈上升趨勢。經過專屬服務羣第一時間與業務方聯繫，與業務方確認是否有正在執行的定時任務，或者大範圍拉取帳單等業務操做。然而仔細分析了業務日誌後，確認當時業務上並無進行會消耗大量計算資源和網絡資源的操做。

 

2、異常現象

隨着時間推移，運維人員收到不一樣應用系統主機系統資源佔用太高的告警通知，但客戶反饋業務上並無受到明顯影響，且處於業務低峯期。

進一步分析排查，發現異常實例cpu使用率，負載，網絡流量，磁盤IO，TCP鏈接數都前後出現上升趨勢，現象以下圖：

CPU使用率：持續10分鐘維持在90%

系統平均負載：平均1分鐘負載超過25

網絡流量：持續10分鐘高於平常水平

磁盤IO：每秒寫入的字節數迅速上升

TCP 鏈接數：established鏈接數持續10分鐘上升

 

3、異常分析

1) 在排除業務上並無相關的異常操做後，運維人員進一步分析了系統是否有受到外部***。經過阿里云云盾安全產品，確認基線檢查及流量檢測並沒有異常，業務入口SLB流入流出流量也呈正常趨勢，能夠排除受到外部***的可能。

2) 運維人員登陸機器繼續排查，鏈接服務器間接出現請求被拒絕的狀況，提示connection reset by peer錯誤信息。

成功登入機器後發現有大量ssh登入連接。

大量的sshd進程引發cpu佔用太高。

 

4、異常處理

通過上述分析，與業務方確認ssh 鏈接客戶端是否爲內部系統IP地址，最終定位異常實例被內網其餘機器惡意破解，進行非法訪問***。運維人員第一時間對異常實例進行恢復操做，包括關閉已創建的鏈接，清除可疑執行程序，修改sshd服務默認端口，重置服務器登陸密碼，調整安全組訪問策略，檢查服務器是否有其它後門等一些列安全加固操做後，主機性能恢復正常。

 

5、案例總結

從服務器安全防禦的角度出發，應將業務部署在雲上隔離的網絡環境，並修改默認遠程服務監聽端口，按需開放安全組訪問限制。若是業務部署早期未作相關規劃，建議儘快遷移經典網絡下的服務器到專有網絡環境，同時須要按期對服務器進行體檢及安全檢查，以確保服務器安全。

---

本文首發於：數棧研習社

數棧是雲原生—站式數據中臺PaaS，咱們在github上有一個有趣的開源項目：FlinkX。FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，好比MySQL，HDFS等，也能夠採集實時變化的數據，好比MySQL binlog，Kafka等，是全域、異構、批流一體的數據同步引擎，你們若是有興趣，歡迎來github社區找咱們玩~