這是一個真實的案例，發生在2016年一月份，做者作了完整的記錄並發表在51cto的博客中，題目爲《記錄一次linux病毒清除過程》，這篇文章在16年一月中旬的51cto一週熱贊排行中佔據了好多天的第一。大概的內容是做者的服務器受到了入侵，被入侵者植入了木馬，而後此木馬不停的對外發起ddos工具，佔用了大量的帶寬，可見危害仍是至關之大。文章中記錄了做者是如何手動清除此木馬的過程，在此不許備闡述如何解決此問題的，詳細的解決辦法請詳見源文章。在這裏我想反過來看待這個問題，就是如何能在事前預防此問題，事中時時的發現此問題，若是能提早預知，或者儘早的發現此問題，就能夠極大的減小不少損失。linux
簡單介紹一下入侵過程，文章中沒有仔細描述，只能從我的的經驗中進行猜想。文中有一句話是我檢查了一下WEB日誌，沒有發現什麼異常，查看數據庫也都正常，也沒有什麼錯誤日誌，查看系統日誌，也沒有看到什麼異常，可是系統的登陸日誌被清除了。從中能夠判斷必定有黑客進入了系統，這個黑客多少有些入侵的經驗，不能算是個新手，由於他刪除了完整的登錄日誌，這樣就能夠把本身隱藏起來，好比登陸的ip地址等信息，這樣就對溯源帶來很大的挑戰，也許就沒有辦法溯源了。引發這個問題的主要緣由可能有以下幾個：一、弱口令，可能被別人掃描到了；二、系統漏洞，也許操做系統等有漏洞沒有及時的修復；三、業務邏輯漏洞；四、後門，也有多是以前的人員故意留了後門在此服務器上。但這些問題大部分在平時的監控中是能夠發現的，好比日誌監控；性能監控等；這樣就能夠在事前，事中，甚至過後發現問題。這些工具備不少，你們能夠自行查找，下面以筆者熟悉的SeciLog來分析一下如何在第一時間發現問題。數據庫
在一個系統中部署集中日誌分析系統是很是有必要的，若是發生了像文章中所說的本地日誌被清除的狀況，還有集中日誌系統能夠找到當時的日誌信息，這樣對排查問題就頗有幫助，對溯源取證也頗有幫助。集中日誌收集系統除了集中收集日誌外還能作什麼呢，還能夠時時分析日誌，並對此產生告警。tomcat
任何的入侵行爲首先的要作事情就是踩點，測試，踩點的做用就是知道這裏有一個活的系統，通常經過掃描，dns查詢等很容易的知道，這個基本沒有辦法避免，天天在互聯網上都會發生大量的主機掃描等行爲。當咱們知道了這有個活的機器後下一步要作什麼呢，就是端口掃描，弱口令掃描，漏洞掃描等幾個步驟，如今不少機器都是雲服務，硬件再也不本身的控制中，因此很難有效的對此進行防範。但弱口令掃描咱們是能夠發現並記錄的，由於既然是弱口令掃描就會有大量的登陸行爲，就會產生大量的登陸失敗的日誌。咱們首先看一下linux下登陸失敗日誌。安全
Jan 6 13:11:00 localhost sshd[3258]: Failed password for root from 192.168.21.1 port 53328 ssh2服務器
從日誌中咱們能夠看出登陸的時間，進程號，登錄失敗的行爲，登陸的帳號，來源ip，登陸的端口，協議等信息，可見這些信息是很是豐富的。咱們看下日誌系統都分析了什麼？併發
從上圖中能夠看到，日誌分析系統中完整的分析處理登陸的主要維度，包括登陸的源地址，端口，登陸的帳號，協議，時間，類型，等很是多的有用信息。這就比直接看原始的日誌方便了不少。但這還不夠，咱們不能天天盯着日誌不幹別的吧。沒錯，因此當系統發送攻擊的時候能產生一個告警就更方便了，下面就是介紹系統如何產生報警，並減小誤報的分析。由於系統不少時候是人登陸的，人有時候也會輸錯密碼，若是把每次登錄錯誤的行爲都產生告警，就會產生大量的誤報。那怎麼樣更合理的。筆者認爲更合理的方式是，在短期內登陸失敗的次數超過閥值，好比在同一個ip在三分鐘內有10次以上的登陸失敗行爲，就認爲是一個密碼猜想攻擊，這種告警是有意義的。固然這個閥值每一個人有本身的判斷，好比我認爲短期有兩次就應該產生告警。下面看一下告警信息。ssh
從上圖能夠看到，當系統發生了攻擊行爲後，系統會自動產生一條告警。並且這條告警能夠經過郵件發送出來，若是你郵件和手機作了綁定，就能夠在第一時間發現攻擊行爲。工具
這種攻擊的行爲還只是尚未成功，但這種行爲是值得關注，好比能夠封IP的行爲，系統也支持自動封IP，但爲了保險起見仍是手工作比較好。上面的行爲是登陸未成功的，但不少時候成功的登陸行爲更應該值得關注，但不能都關注這些行爲，筆者認爲重點關注在非上班時間和非上班地點登陸的行爲，這個行爲是很是危險的。對這些SeciLog也作了支持。性能
首先看一下定義：
學習
系統中默認的非上班時間是早上0點到8點和晚上20點到24點，非上班地點的定義主要是IP地址的白名單，就不截圖了。
看一下登陸成功的日誌。
Jan 17 10:34:31 seciv sshd[2836]: Accepted password for tomcat from 172.206.160.155 port 38874 ssh2
日誌中一樣記錄的日誌的時間和登陸的ip，經過對着兩個的判斷就能夠分析出，非上班時間登陸和非上班地點登陸。
從中能夠看出系統很容易獲得非上班地點登陸，同理非上班時間也是相似的，在此就不截圖了。
固然這些還不是監控的所有，當系統登陸後，發生了刪除secure，修改了rsyslog.conf文件的等操做，這就更加危險了，系統同時支持敏感文件操做的告警。
從中能夠看出當用戶編輯了rsyslog.conf文件，系統也會產生告警。
系統還支持系統性能的監控，當系統的某個性能指標超過閥值的時候系統也會產生告警。系統支持cpu、內存、swap、硬盤、網卡流量的監控。
針對《記錄一次linux病毒清除過程》的內容咱們分析瞭如何進行預防並時時的發現問題的過程。若是文中的做者能事先部署一套集中日誌審計系統，並作好配置。相信能夠及時的發現問題，並解決問題，使問題的影響達到最小。
但筆者有個疑惑就是人多人只有在發生問題的時候纔回去重視安全，這個時候問題已經發生了，損失已經產生了。我感受這就是意識問題。只能經過大量的入侵案例中慢慢的學習，但願此文章能對你產生幫助。
感謝閱讀。
