從一個案例來看日志分析的重要性

   這是一個真實的案例，發(fā)生在2016年一月份，作者做了完整的記錄并發(fā)表在51cto的博客中，題目為《記錄一次linux病毒清除過程》，這篇文章在16年一月中旬的51cto一周熱贊排行中占據(jù)了好多天的第一。大概的內(nèi)容是作者的服務(wù)器受到了***，被***者植入了***，然后此***不停的對外發(fā)起ddos工具，占用了大量的帶寬，可見危害還是相當(dāng)之大。文章中記錄了作者是如何手動清除此***的過程，在此不準(zhǔn)備闡述如何解決此問題的，詳細(xì)的解決辦法請詳見源文章。在這里我想反過來看待這個問題，就是如何能在事前預(yù)防此問題，事中時時的發(fā)現(xiàn)此問題，如果能提前預(yù)知，或者盡早的發(fā)現(xiàn)此問題，就可以極大的減少很多損失。

  簡單介紹一下***過程，文章中沒有仔細(xì)描述，只能從個人的經(jīng)驗中進(jìn)行猜測。文中有一句話是我檢查了一下WEB日志，沒有發(fā)現(xiàn)什么異常，查看數(shù)據(jù)庫也都正常，也沒有什么錯誤日志，查看系統(tǒng)日志，也沒有看到什么異常，但是系統(tǒng)的登錄日志被清除了。從中可以判斷一定有***進(jìn)入了系統(tǒng)，這個***多少有些***的經(jīng)驗，不能算是個新手，因為他刪除了完整的登陸日志，這樣就可以把自己隱藏起來，比如登錄的ip地址等信息，這樣就對溯源帶來很大的挑戰(zhàn)，也許就沒有辦法溯源了。引起這個問題的主要原因可能有如下幾個：1、弱口令，可能被別人掃描到了；2、系統(tǒng)漏洞，也許操作系統(tǒng)等有漏洞沒有及時的修復(fù)；3、業(yè)務(wù)邏輯漏洞；4、后門，也有可能是之前的人員故意留了后門在此服務(wù)器上。但這些問題大部分在平時的監(jiān)控中是可以發(fā)現(xiàn)的，比如日志監(jiān)控；性能監(jiān)控等；這樣就可以在事前，事中，甚至事后發(fā)現(xiàn)問題。這些工具有很多，大家可以自行查找，下面以筆者熟悉的SeciLog來分析一下如何在第一時間發(fā)現(xiàn)問題。

  在一個系統(tǒng)中部署集中日志分析系統(tǒng)是非常有必要的，如果發(fā)生了像文章中所說的本地日志被清除的情況，還有集中日志系統(tǒng)可以找到當(dāng)時的日志信息，這樣對排查問題就很有幫助，對溯源取證也很有幫助。集中日志收集系統(tǒng)除了集中收集日志外還能做什么呢，還可以時時分析日志，并對此產(chǎn)生告警。

  任何的***行為首先的要做事情就是踩點，測試，踩點的作用就是知道這里有一個活的系統(tǒng)，一般通過掃描，dns查詢等很容易的知道，這個基本沒有辦法避免，每天在互聯(lián)網(wǎng)上都會發(fā)生大量的主機掃描等行為。當(dāng)我們知道了這有個活的機器后下一步要做什么呢，就是端口掃描，弱口令掃描，漏洞掃描等幾個步驟，現(xiàn)在很多機器都是云服務(wù)，硬件不再自己的控制中，所以很難有效的對此進(jìn)行防范。但弱口令掃描我們是可以發(fā)現(xiàn)并記錄的，因為既然是弱口令掃描就會有大量的登錄行為，就會產(chǎn)生大量的登錄失敗的日志。我們首先看一下linux下登錄失敗日志。

Jan  6 13:11:00 localhost sshd[3258]: Failed password for root from 192.168.21.1 port 53328 ssh3

  從日志中我們可以看出登錄的時間，進(jìn)程號，登陸失敗的行為，登錄的賬號，來源ip，登錄的端口，協(xié)議等信息，可見這些信息是非常豐富的。我們看下日志系統(tǒng)都分析了什么？

  從上圖中可以看到，日志分析系統(tǒng)中完整的分析處理登錄的主要維度，包括登錄的源地址，端口，登錄的賬號，協(xié)議，時間，類型，等非常多的有用信息。這就比直接看原始的日志方便了很多。但這還不夠，我們不能每天盯著日志不干別的吧。沒錯，所以當(dāng)系統(tǒng)發(fā)送***的時候能產(chǎn)生一個告警就更方便了，下面就是介紹系統(tǒng)如何產(chǎn)生報警，并減少誤報的分析。因為系統(tǒng)很多時候是人登錄的，人有時候也會輸錯密碼，如果把每次登陸錯誤的行為都產(chǎn)生告警，就會產(chǎn)生大量的誤報。那怎么樣更合理的。筆者認(rèn)為更合理的方式是，在短時間內(nèi)登錄失敗的次數(shù)超過閥值，比如在同一個ip在三分鐘內(nèi)有10次以上的登錄失敗行為，就認(rèn)為是一個密碼猜測***，這種告警是有意義的。當(dāng)然這個閥值每個人有自己的判斷，比如我認(rèn)為短時間有兩次就應(yīng)該產(chǎn)生告警。下面看一下告警信息。

  從上圖可以看到，當(dāng)系統(tǒng)發(fā)生了***行為后，系統(tǒng)會自動產(chǎn)生一條告警。而且這條告警可以通過郵件發(fā)送出來，如果你郵件和手機做了綁定，就可以在第一時間發(fā)現(xiàn)***行為。

  這種***的行為還只是還沒有成功，但這種行為是值得關(guān)注，比如可以封IP的行為，系統(tǒng)也支持自動封IP，但為了保險起見還是手工做比較好。上面的行為是登錄未成功的，但很多時候成功的登錄行為更應(yīng)該值得關(guān)注，但不能都關(guān)注這些行為，筆者認(rèn)為重點關(guān)注在非上班時間和非上班地點登錄的行為，這個行為是非常危險的。對這些SeciLog也做了支持。

  首先看一下定義：

  系統(tǒng)中默認(rèn)的非上班時間是早上0點到8點和晚上20點到24點，非上班地點的定義主要是IP地址的白名單，就不截圖了。

  看一下登錄成功的日志。

Jan 17 10:34:31 seciv sshd[2836]: Accepted password for tomcat from 172.206.160.155 port 38874 ssh3

  日志中同樣記錄的日志的時間和登錄的ip，通過對著兩個的判斷就可以分析出，非上班時間登錄和非上班地點登錄。

  從中可以看出系統(tǒng)很容易得到非上班地點登錄，同理非上班時間也是類似的，在此就不截圖了。

  當(dāng)然這些還不是監(jiān)控的全部，當(dāng)系統(tǒng)登錄后，發(fā)生了刪除secure，修改了rsyslog.conf文件的等操作，這就更加危險了，系統(tǒng)同時支持敏感文件操作的告警。

  從中可以看出當(dāng)用戶編輯了rsyslog.conf文件，系統(tǒng)也會產(chǎn)生告警。

 系統(tǒng)還支持系統(tǒng)性能的監(jiān)控，當(dāng)系統(tǒng)的某個性能指標(biāo)超過閥值的時候系統(tǒng)也會產(chǎn)生告警。系統(tǒng)支持cpu、內(nèi)存、swap、硬盤、網(wǎng)卡流量的監(jiān)控。

  針對《記錄一次linux病毒清除過程》的內(nèi)容我們分析了如何進(jìn)行預(yù)防并時時的發(fā)現(xiàn)問題的過程。如果文中的作者能事先部署一套集中日志審計系統(tǒng)，并做好配置。相信可以及時的發(fā)現(xiàn)問題，并解決問題，使問題的影響達(dá)到最小。

  但筆者有個疑惑就是人多人只有在發(fā)生問題的時候才回去重視安全，這個時候問題已經(jīng)發(fā)生了，損失已經(jīng)產(chǎn)生了。我感覺這就是意識問題。只能通過大量的***案例中慢慢的學(xué)習(xí)，希望此文章能對你產(chǎn)生幫助。感謝閱讀。