最初始的時候是安全部門告知我們"伺服器疑似被攻擊"，然後和客戶協調了安全部門的兩位人員協助排查一下，主要排查了系統日誌(messages和secure)、nginx日誌和tomcat日誌，還排查了一些系統登入、操作異常(登入資訊、歷史命令等)。排查後沒有發現什麼異常，所以當時判斷伺服器沒有被攻擊
過了大概3周左右，我登入上伺服器後發現cpu負載一直處在3.0，然後檢視是哪些程序占用的cpu較高，經檢視發現了3個python的程序(每個程序的cpu佔用率都在100%)。因為我們沒有用到python，就覺得有異常，就檢視了一下程序的詳細命令，是如下命令：
/bin/bash –i,python -c 『import pty; pty.spawn("/bin/sh")』
當時雖然已經覺得有異常，但因為還有別的其它事情，再加上安全知識的欠缺，所以就選擇了將此程序記錄下來，然後忙完了當時的事情後，回到公司開始查此程序的一些資訊。
查詢的第一條就是"如果某一天當你登入伺服器發現 /bin/bash –i,python -c 『import pty; pty.spawn("/bin/sh")』 等命令在伺服器上出現的時候，那麼恭喜你，伺服器被入侵了"。這下確認是被攻擊了，因為3週前讓安全部門的人員排查時沒有發現什麼異常，然後個人就覺得應該是一次簡單的攻擊，不會存在較大的問題，就想著找一些解決方法再去解決後並告知客戶(伺服器在客戶內網，和公司有一點距離)
期間過了一周，再次去辦理一些其它事情的時候，因為沒有找到解決方法，就告知了客戶，讓客戶協調安全部門的幫助排查加提供解決方案。這次安全部門的人員按照此程序，推斷此伺服器已經被攻擊，建議停止所有服務，備份重要資料，重做系統後再進行部署上線。
我們是想知道被攻擊的原因是什麼，如果重做系統的話，再想找出原因可能會比較難了。然後安全部門的人員推薦了chkrootkit(後門檢測工具)，經過掃瞄，沒有發現木馬檔案。當時因為我們沒有備用的伺服器，不想立即停止服務加上經掃瞄也沒有發現木馬檔案和安全意識的薄弱；就選擇了將python的程序殺掉後再觀察兩天。
一周後我們再次去辦理一些其它事情的時候，發現伺服器遠端登入不上去了；讓客戶協調到伺服器物理層面的環境進行排查，發現伺服器多出兩個使用者(乙個普通使用者和乙個管理員使用者)並且所有檔案的所有者屬性都被修改為admin1。
然後我們開始修復ssh遠端連線。先將所有檔案的所有者屬性修改為root，然後可以ssh遠端，但是密碼一直提示失敗。到這個程度的時候已經是下午6點以後了，提供物理層面環境的人員要下班了，我們也不能再繼續使用(安全部門的人也在場)。
此次被攻擊主要是我們的應用有乙個上傳檔案的功能，在上傳檔案時的判斷&限制不夠嚴禁導致的；
再加上這個應用是用管理員使用者執行的。所以攻擊者可以完全控制我們的伺服器。雖說刪除木馬檔案後系統就可以正常使用了，但是查詢攻擊者對系統進行的一些修改並修復的工作量比起重做系統的工作更麻煩更複雜一些，所以我們重做了系統。
這次重做系統後，我們進行了各種安全配置(系統層、應用層和**優化)，再進行掃瞄修復，直到非常安全才部署應用上線。
記一次伺服器被攻擊經歷
從接手公司伺服器兩個半星期經常性的無法正常ssh登陸，十次裡面有九次半都是顯示 ssh exchange identification read connection reset by peer 也谷歌很多種原因和解決方案，無非是分兩種 一是執行緒滿了，需要更改配置檔案把max session 調大...
記一次伺服器被攻擊的處理
今天早上上班看了一下京東雲的控制台，發現有一系列被攻擊的記錄。如下圖 如圖所示，被攻擊的埠是xshell遠端訪問的預設埠號22和mysql的預設埠號3306，明顯是ip被公開後的暴力破解，一旦被破解後果則不堪設想了。於是，馬上改預設的埠號。第一步，改ssh埠號 找到ssh服務配置檔案路徑一般都是在 ...
記一次伺服器被惡意攻擊的情況
今天上午，我正在維護一台linux伺服器，使用vnc viewer遠端桌面，突然看見桌面上乙個控制台在自動換行，剛開始我還以為是眼花了，本來想繼續幹活，可是還沒等滑鼠點下去，又被開啟乙個控制台，繼續輸入命令，主要輸入的命令如下圖 自從看見自動輸入命令的控制台，大約持續了十幾分鐘，期間還出現了對話部分...