網站日志作為服務器重要的組成部分，具體的記載了服務器運轉期間客戶端對WEB運用的拜訪懇求和服務器的運轉狀況，相同，進犯者對網站的侵略行為也會被記載到WEB日志中，因而，在網站日常運營和安全應急呼應進程中，我們能夠經過剖析WEB日志并結合其他一些狀況來跟蹤進犯者，復原進犯進程。

　　本文主要敘述了網站日志安全剖析時的思路和常用的一些技巧，并經過兩個完好的實例敘述了在發作安全事情后，怎樣經過剖析網站日志并結合其他一些頭緒來對進犯者進行清查。

　　一、WEB日志結構

　　在對WEB日志進行安全剖析之前，我們需求先了解下WEB日志的結構，從現在干流WEB服務器支撐的日志類型來看，常見的有兩類：

　　1、Apache選用的NCSA日志格局。

　　2、IIS選用的W3C日志格局。

　　其間NCSA日志格局又分為NCSA一般日志格局（CLF）和NCSA擴展日志格局（ECLF）兩類，具體運用那一種能夠在WEB服務器裝備文件中定義，Apache也支撐自定義日志格局，用戶能夠在裝備文件中自定義日志格局，如在Apache中能夠經過修正httpd.conf裝備文件來實現。

　　?

　　接著我們來看一條Apache的拜訪日志：

　　192.168.1.66 - - [06/Sep/2012:20:55:05 +0800] "GET /index.html HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0"

　　下面是具體的解釋：

　　192.168.1.66：表明客戶端IP地址

　　[06/Sep/2012:20:55:05 +0800]：拜訪時刻及服務器地點時區

　　GET：數據包提交方法為GET方法。常見的有GET和POST兩種類型。

　　/index.html：客戶端拜訪的URL

　　HTTP/1.1：協議版別信息

　　404：WEB服務器呼應的狀況碼。404表明服務器上無此文件；200表明呼應正常；500表明服務器過錯。

　　287：此次拜訪傳輸的字節數

　　Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0：客戶端瀏覽器和體系環境等信息。

　　IIS拜訪日志格局及保存路徑能夠在IIS辦理器中裝備：

　　下面是IIS的W3C擴展日志格局：

　　值得注意的是IIS的W3C日志格局中的拜訪時刻選用的是格林威治時刻，和我們的北京時刻差8個小時，并且沒有辦法修正（具體可檢查博客《怎樣檢查及剖析網站IIS日志文件》的相關介紹）。

　　二、WEB日志安全剖析原理

　　經過上面的知識，我們知道WEB日志會記載客戶端對WEB運用的拜訪懇求，這其間包括正常用戶的拜訪懇求和進犯者的歹意行為，那么我們怎樣區別正常用戶和歹意進犯者呢？經過許多的剖析，我們發現進犯者在對網站侵略時，向網站建議的懇求中會帶有特定的進犯特征，如運用WEB掃描器在對網站進行縫隙掃描時往往會發生許多的404過錯日志。

　　當有人對網站進行SQL注入縫隙探測時，WEB拜訪日志中一般會呈現如下日志：

　　因而，我們能夠經過剖析WEB日志中是否存在特定的進犯特征來區別進犯者和正常用戶的拜訪行為。

　　可是，WEB拜訪日志并不是全能的，有些進犯行為并不會被記載到WEB拜訪日志中，比方POST型SQL注入就不會記載在WEB拜訪日志中，這時我們就需求經過其他方法來監測這種進犯行為（具體可檢查博客《怎樣經過IIS日志剖析網站的隱形信息》的相關介紹）。

　　三、WEB日志安全剖析思路

　　在對WEB日志進行安全剖析時，能夠依照下面兩種思路打開，逐漸深入，復原整個進犯進程。

　　1、首要斷定遭到進犯、侵略的時刻規模，以此為頭緒，查找這個時刻規模內可疑的日志，進一步排查，終究斷定進犯者，復原進犯進程。

　　2、一般進犯者在侵略網站后，一般會上傳一個后門文件，以方便自己今后拜訪，我們也能夠以該文件為頭緒來打開剖析。

　　四、WEB日志安全剖析技巧

　　WEB日志文件一般比較大，包括的信息也比較豐富，當我們對WEB日志進行安全剖析時，我們一般只重視包括進犯特征的日志，其他的日志對于我們來說是無用的，這時我們能夠經過手藝或借助東西來將我們重視的日志內容提取出來獨自剖析，以進步效率。

　　在日志剖析中常常用到的幾個指令有“find”，“findstr”，“grep”，“egrep”等，關于這幾個指令的用法請自行查找相關材料。

　　1、將數據提交方法為“GET”的日志提取出來

　　上面這條指令的意思是從iis.log這個文件中查找存在GET字符的日志內容，并將結果保存到iis_get.log中。

　　2、查找WEB日志中是否存在運用IIS寫權限縫隙的進犯行為。

　　五、實例剖析：怎樣經過剖析WEB日志追尋進犯者

　　上面我們講了一些關于在WEB日志安全剖析進程中常常用到的技巧，現在我們經過一個實例來完好的了解下怎樣經過剖析WEB日志追尋進犯者，復原進犯進程。

　　1、布景介紹

　　某日，公司網站服務器WEB目錄下俄然多了一個名為shell.php.jpg的文件，經過檢查文件內容，發現該文件是一個網站后門文件，也就是常說的WebShell，所以置疑網站被黑客侵略。

　　接下來網站辦理員經過剖析WEB日志，并結合其他一些狀況，成功追尋到了進犯者，復原了整個進犯進程，在這個進程中還發現了網站存在的安全縫隙，過后及時修正了縫隙，并對網站進行了全面的安全檢測，進步了網站的安全性。

　　2、剖析思路

　　依據現在得到的信息剖析，得知WEB目錄下存在一個可疑的文件，我們就以該文件為頭緒，先來查找都有哪些IP拜訪了該文件，然后并一步排查這些IP都做了哪些操作，終究承認進犯者以及他運用的進犯方法。

　　3、剖析進程

　　（1）、首要找到存在的網站后門文件，也就是上面說到的WebShell文件，發現該文件是在2013年2月7日被創立的。

　　（2）、我們先來查找下都有哪些IP拜訪了這個文件，可經過如下指令將相關日志內容提取出來。

　　（3）、經過上圖我們能夠斷定現在只要192.168.1.2拜訪了該文件，這個IP十分可疑，下面我們來查找下該IP都做了哪些操作。

　　（4）、從上面的日志中我們能夠看到這是典型的SQL注入，經過進一步剖析，發現進犯者運用SQL注入獲取到了網站后臺辦理員帳號和暗碼。

　　192.168.1.2 - - [07/Mar/2013:22:50:21 +0800] "GET /leave_show.php?id=40%20and%201=2%20union%20select%20unhex(hex(concat(0x5e5e5e,group_concat(id,0x5e,user,0x5e,pwd,0x5e,userclass,0x5e,loginip,0x5e,logintimes,0x5e,logintime),0x5e5e5e))),0,0,0,0,0,0,0,0%20from%20(select%20*%20from%20(select%20*%20from%20admin%20where%201=1%20order%20by%201%20limit%201,100)%20t%20order%20by%201%20desc)t%20-- HTTP/1.1" 200 18859 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)"

　　（5）、接著進犯者運用獲取到的帳號成功進入了網站后臺，詳見下面的日志：

　　192.168.1.2 - - [07/Mar/2013:22:51:26 +0800] "GET /mywebmanage/web_manage.php HTTP/1.1" 200 5172 "http://192.168.1.107/mywebmanage/" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　192.168.1.2 - - [07/Mar/2013:22:51:44 +0800] "POST /mywebmanage/check.php HTTP/1.1" 200 47 "http://192.168.1.107/mywebmanage/web_manage.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　192.168.1.2 - - [07/Mar/2013:22:51:45 +0800] "GET /mywebmanage/default.php HTTP/1.1" 200 2228 "http://192.168.1.107/mywebmanage/check.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　（6）、然后進犯者拜訪了add_link.php這個頁面，該頁面是一個增加友情鏈接的頁面：

　　經過剖析網站源碼，發現該頁面上傳圖片處存在一個文件上傳縫隙，進犯者正是運用這個縫隙上傳了一個名為shell.php.jpg的后門文件，并且運用Apache的解析縫隙成功獲取到一個WebShell。

　　192.168.1.2 - - [07/Mar/2013:22:53:40 +0800] "GET /mywebmanage/link/add_link.php HTTP/1.1" 200 3023 "http://192.168.1.107/mywebmanage/LeftTree.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　192.168.1.2 - - [07/Mar/2013:22:54:50 +0800] "POST /mywebmanage/link/add_link_ok.php HTTP/1.1" 200 77 "http://192.168.1.107/mywebmanage/link/add_link.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　192.168.1.2 - - [07/Mar/2013:22:55:48 +0800] "GET /link/shell.php.jpg HTTP/1.1" 200 359 "-" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　192.168.1.2 - - [07/Mar/2013:22:55:54 +0800] "POST /link/shell.php.jpg HTTP/1.1" 200 132 "http://192.168.1.107/link/shell.php.jpg" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

　　（7）、到這兒，我們現已能夠了解到進犯者的進犯進程了，具體如下：

　　首要對網站進行縫隙檢測，發現存在SQL注入縫隙--->運用SQL注入縫隙獲取到網站后臺辦理員帳號、暗碼及其他信息--->以辦理員身份登錄網站后臺--->運用某頁面存在的文件上傳縫隙，成功上傳一個名為shell.php.jpg的后門文件，并結合Apache的解析縫隙，成功獲取到一個WebShell。

　　六、實例剖析：運用IIS日志清查BBS網站侵略者

　　如果你是網管你會怎樣去清查問題的來歷呢？程序問題就去檢查“事情檢查器”，如果是IIS問題當然是檢查IIS日志了！

　　體系文件夾的system32低下的logfile有一切的IIS日志，用來記載服務器一切拜訪記載，因為是虛擬主機的用戶，所以每個用戶都裝備獨立的IIS日志目錄，從里邊的日志文件就能夠發現侵略者侵略BBS的材料了，所以下載了有關時刻段的一切日志下來進行剖析，發現了許多我自己都不知道材料（具體可檢查博客《IIS日志的效果有哪些》的相關介紹），這下子就知道侵略者是怎樣侵略我的BBS了。

　　1、IIS日志的剖析

　　從第一天里日志能夠發現侵略者早就現已對我的BBS虎視耽耽的了，并且不止一個侵略者這么簡略，還許多啊，頭一天的IIS日志就全部都是運用程序掃描后臺留下的廢物數據。

　　看上面的日志能夠發現，侵略者61.145.***.***運用程序不斷的在掃描后臺的頁面，如同想運用后臺登陸縫隙然后進入BBS的后臺辦理版面，很可惜這位侵略者如同真的沒有什么思路，麻痹的運用程序作為協助去尋覓后臺，沒有什么效果的侵略方法。

　　檢查了第二天的日志，開端的時分還是一般的用戶拜訪日志沒有什么特別，到了中段的時分問題就找到了，找到了一個運用程序查找指定文件的IIS動作記載。

　　從上面的材料發現侵略者61.141.***.***也是運用程序去掃描指定的上傳頁面，然后斷定侵略方針是否存在這些頁面，然后進行上傳縫隙的侵略，還有就是掃描運用動網默許數據庫，一些比較常用的木馬稱號，看來這個侵略者還認為我的BBS是馬坊啊，掃描這么多的木馬文件能找著就是奇觀啊。

　　持續往下走總算被我發現了，侵略者61.141.***.***在黑了我網站主頁之前的動作記載了，首要在Forum的文件夾目錄建立了一個Myth.txt文件，然后在Forum的文件夾目錄下再生成了一只木馬Akk.asp

　　日志的記載下，看到了侵略者運用akk.asp木馬的一切操作記載。

　　具體侵略剖析如下：

　　GET /forum/akk.asp – 200

　　運用旁注網站的webshell在Forum文件夾下生成akk.asp后門

　　GET /forum/akk.asp d=ls.asp 200

　　侵略者登陸后門

　　GET /forum/akk.asp d=ls.asp&path=/test&oldpath=&attrib= 200

　　進入test文件夾

　　GET /forum/akk.asp d=e.asp&path=/test/1.asp&attrib= 200

　　運用后門在test文件夾修正1.asp的文件

　　GET /forum/akk.asp d=ls.asp 200

　　GET /forum/akk.asp d=ls.asp&path=/lan&oldpath=&attrib= 200

　　進入lan文件夾

　　GET /forum/akk.asp d=e.asp&path=/lan/index.html&attrib= 200

　　運用編輯指令修正lan文件夾內的主頁文件

　　GET /forum/akk.asp d=ls.asp 200

　　GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200

　　進入BBS文件夾（這下子真的進入BBS目錄了）

　　POST /forum/akk.asp d=up.asp 200

　　GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200

　　GET /forum/myth.txt – 200

　　在forum的文件夾內上傳myth.txt的文件

　　GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200

　　GET /forum/akk.asp d=e.asp&path=/forum/myth.txt&op=del&attrib= 200

　　POST /forum/akk.asp d=up.asp 200

　　GET /forum/myth.txt – 200

　　運用后門修正Forum文件夾目錄下的myth.txt文件。

　　之后又再運用旁注網站的webshell進行了Ubb.asp的后門建立，運用akk.asp的后門修正了主頁，又把主頁備份，暈死啊，不明白這位侵略者是怎樣一回事，整天換webshell進行運用，還真的摸不透啊。

　　2、剖析日志總結

　　侵略者是運用東西踩點，首要斷定BBS可能存在的縫隙頁面，經過測驗發現不能夠侵略，然后轉向服務器的侵略，運用旁注專用的程序或者是特定的程序進行網站侵略，拿到首要的webshell，再進行文件夾的拜訪然后侵略了我的BBS體系修正了主頁，因為是根據我空間的IIS日志進行剖析，所以不清楚侵略者是運用哪個網站哪個頁面進行侵略的！

　　不過都現已完結的材料收集了，斷定了侵略BBS的侵略者IP地址以及運用的木馬，還留下了許多侵略記載，整個日志追尋進程就結束了。

　　經過上面臨WEB日志進行的安全剖析，我們不僅追尋到了進犯者，也查出了網站存在的縫隙，下面就應該將進犯者上傳的后門文件刪除去，并修正存在的安全縫隙，然后對網站進行全面的安全檢測，并對WEB服務器進行安全加固，避免此類安全事情再次發作。