一、問題背景

某日袋鼠云運維小哥進行例行運維巡檢，通過監(jiān)控視圖發(fā)現(xiàn)客戶應(yīng)用服務(wù)器cpu使用率突然呈上升趨勢。通過專屬服務(wù)群第一時間與業(yè)務(wù)方聯(lián)系，與業(yè)務(wù)方確認是否有正在執(zhí)行的定時任務(wù)，或者大范圍拉取賬單等業(yè)務(wù)操作。然而仔細分析了業(yè)務(wù)日志后，確認當時業(yè)務(wù)上并沒有進行會消耗大量計算資源和網(wǎng)絡(luò)資源的操作。

二、異常現(xiàn)象

隨著時間推移，運維人員收到不同應(yīng)用系統(tǒng)主機系統(tǒng)資源占用過高的告警通知，但客戶反饋業(yè)務(wù)上并沒有受到明顯影響，且處于業(yè)務(wù)低峰期。

進一步分析排查，發(fā)現(xiàn)異常實例cpu使用率，負載，網(wǎng)絡(luò)流量，磁盤IO，TCP連接數(shù)都先后出現(xiàn)上升趨勢，現(xiàn)象如下圖：

CPU使用率：持續(xù)10分鐘維持在90%

系統(tǒng)平均負載：平均1分鐘負載超過25

網(wǎng)絡(luò)流量：持續(xù)10分鐘高于日常水平

磁盤IO：每秒寫入的字節(jié)數(shù)迅速上升

TCP 連接數(shù)：established連接數(shù)持續(xù)10分鐘上升

三、異常分析

1) 在排除業(yè)務(wù)上并沒有相關(guān)的異常操作后，運維人員進一步分析了系統(tǒng)是否有受到外部攻擊。通過阿里云云盾安全產(chǎn)品，確認基線檢查及流量檢測并無異常，業(yè)務(wù)入口SLB流入流出流量也呈正常趨勢，可以排除受到外部攻擊的可能。

2) 運維人員登錄機器繼續(xù)排查，連接服務(wù)器間接出現(xiàn)請求被拒絕的情況，提示connection reset by peer錯誤信息。

成功登入機器后發(fā)現(xiàn)有大量ssh登入鏈接。

大量的sshd進程引起cpu占用過高。

四、異常處理

經(jīng)過上述分析，與業(yè)務(wù)方確認ssh 連接客戶端是否為內(nèi)部系統(tǒng)IP地址，最終定位異常實例被內(nèi)網(wǎng)其他機器惡意破解，進行非法訪問入侵。運維人員第一時間對異常實例進行恢復操作，包括關(guān)閉已建立的連接，清除可疑執(zhí)行程序，修改sshd服務(wù)默認端口，重置服務(wù)器登錄密碼，調(diào)整安全組訪問策略，檢查服務(wù)器是否有其它后門等一些列安全加固操作后，主機性能恢復正常。

五、案例總結(jié)

從服務(wù)器安全防護的角度出發(fā)，應(yīng)將業(yè)務(wù)部署在云上隔離的網(wǎng)絡(luò)環(huán)境，并修改默認遠程服務(wù)監(jiān)聽端口，按需開放安全組訪問限制。如果業(yè)務(wù)部署早期未做相關(guān)規(guī)劃，建議盡快遷移經(jīng)典網(wǎng)絡(luò)下的服務(wù)器到專有網(wǎng)絡(luò)環(huán)境，同時需要定期對服務(wù)器進行體檢及安全檢查，以確保服務(wù)器安全。

本文首發(fā)于：數(shù)棧研習社

數(shù)棧是云原生—站式數(shù)據(jù)中臺PaaS，我們在github上有一個有趣的開源項目：FlinkX。FlinkX是一個基于Flink的批流統(tǒng)一的數(shù)據(jù)同步工具，既可以采集靜態(tài)的數(shù)據(jù)，比如MySQL，HDFS等，也可以采集實時變化的數(shù)據(jù)，比如MySQL binlog，Kafka等，是全域、異構(gòu)、批流一體的數(shù)據(jù)同步引擎，大家如果有興趣，歡迎來github社區(qū)找我們玩~