通過入侵行為分析IDS應用
IDS，即入侵檢測系統其關鍵就在于檢測能力。簡單的說，設立IDS的目的就是當場檢測到網絡入侵事件的發生。本篇文章將通過監測惡性入侵性網頁瀏覽行為，分析在企業安全防護中的IDS應用。
IDS就是一個網絡上的系統，這個系統包含了下面三個組件：
（1）網絡監測組件，用以捕捉在網絡線上傳遞的封包。
（2）接口組件，用以決定監測中的資料傳遞是否屬于惡意行為或惡意的使用。在網絡傳遞時，用來比較的資料樣式 （pattern），以監測惡意網絡活動。
（3）響應組件，針對當時的事件予以適當的響應。這個響應可以是簡單的，例如寄發一個電子郵件訊息給系統管理者，或者是復雜的，例如暫時將違規者的IP地址過濾掉，不要讓他連到這個網絡來。
IDS如何通過網頁監測網絡入侵事件
IDS系統不只必須監測各式各樣，從大到小，以及各種系列的系統上的網絡攻擊事件，它還必須能夠快速及時地的在第一時間內監測到入侵事件的發生。因此，IDS的數據庫以及式樣比對（pattern-matching）機制是復雜到令人難以置信的。
要使IDS能夠監測通過網頁的入侵事件，其中的網絡監測組件就必須要能夠捕捉所有通過網頁通訊端口上，借著HTTP 通訊協議傳遞的網絡資料往來。（注意，SSL的網絡交通是完全繞過IDS的網絡監測的，因為這些網絡交換資料都是經過加密的。）式樣比對組件在這里，主要是用于比較URL解析的結果，看看是否符合數據庫中的惡意的HTTP回詢（request）。
接下來，我介紹如何制作兩個快速而簡易的IDS應用軟件，用來監測可疑的網頁回詢活動。這些解決方案的目的是在于提供系統管理者，讓他們擁有一個特別針對他們網絡而設計的監測/響應系統。
制作快速而簡易的IDS應用軟件
（1）Network Grep 工具
我們先從一個簡單的網絡監視程序開始，這個程序是用來監測 HTTP 通訊協議的網絡資料往來。HTTP回詢的特色是，它使用以下的語法：
〈HTTP-Request-Method〉 〈URL〉 HTTP/〈version〉
這個可在Packetfactory入口網站尋獲的程序ngrep針對在網絡上傳遞往來的資料，執行正則表示法（regular expression）式樣比對。我們可以用以下的指令來利用ngrep攔截并顯示所有純文字形式的 HTTP 資料往來：
#ngrep-iqt“^GET|^HEAD|^TRACE|^POST|^PUT and HTTP”
以上指令中，-iqt 選項是指示ngrep不要區分資料中的大小寫，并且只有顯示封包中有符合式樣比對的資料，以及在顯示資料時加上日期以及時間的標題。（注：比對的式樣，是基于 GET，HEAD，TRACE，POST，PUT，以及 HTTP 等關鍵詞。欲知更多有關如何在ngrep使用正則表示法，你可以到http://www.packetfactory.net/Projects/Ngrep/查看相關資料。）
以上面我們建議的方式使用ngrep再加上運行越來越受歡迎的 Whisker程序，監測地址為 10.1.1.2 的IIS5.0 服務器平臺，我們得到了以下的結果：
T 03:37:30.041739 10.1.1.21:2425 -> 10.1.1.2:80 [AP]
HEAD / HTTP/1.0..User-Agent: Mozilla/5.0 [en] （Win95; U）..Referer: http://10.1.1.2/..Connection: close....
T 2001/01/16 03:37:30.108630 10.1.1.21:2426 -> 10.1.1.2:80 [AP]
GET /cfdocs/ HTTP/1.0..User-Agent: Mozilla/5.0 [en] （Win95; U）..Cookie: ASPSESSIONIDGQGQGLAC=HDJNBOGBIPOCPNCKOJOPBCFD;path=
/..Referer:http://10.1.1.2/..Connection: close....
T 2001/01/16 03:37:31.842452 10.1.1.21:2427 -> 10.1.1.2:80 [AP]
GET /scripts/ HTTP/1.0..User-Agent: Mozilla/5.0 [en] （Win95; U）..Cookie: ASPSESSIONIDGQGQGLAC=HDJNBOGBIPOCPNCKOJOPBCFD;path=
/..Referer:http://10.1.1.2/..Connection: close....
T 2001/01/16 03:37:31.854206 10.1.1.21:2428 -> 10.1.1.2:80 [AP]
GET /scripts/cfcache.map HTTP/1.0..User-Agent: Mozilla/5.0 [en]
（Win95; U）..Cookie: ASPSESSIONIDGQGQGLAC=HDJNBOGBIPOCPNCKOJOPBCFD;
path=/..Referer: http://10.1.1.2/..Connection: close....
T 2001/01/16 03:37:33.644534 10.1.1.21:2429 -> 10.1.1.2:80 [AP]
GET /cfcache.map HTTP/1.0..User-Agent: Mozilla/5.0 [en] （Win95; U）..Cookie: ASPSESSIONIDGQGQGLAC=HDJNBOGBIPOCPNCKOJOPBCFD;path=
/..Referer:http://10.1.1.2/..Connection: close....
（2）執行式樣比對
使用ngrep攔截網絡資料往來很簡單。然而，分析捕捉到的資料并從中抽取URL則略具難度。因為ngrep將資料輸出拆成一行一行的，所以我們必須額外耗費很多精力，去重組輸出的資料，并將該資料中的URL與已知的網絡攻擊行為模式做比對。
此時，我向大家介紹另一個用來監測網頁傳送的犀利工具軟件了。這個軟件就叫做urlsnarf，它是由Dug Song寫成的dsniff工具軟件套件的一部份。urlsnarf 從所攔截的網絡資料傳送中，捕捉所有的 HTTP 回詢，并且將結果以共享日記文件格式（Common Log Format ,CLF）顯示出來，這種格式就跟市面上的網頁服務器，諸如Apache或者是IIS所用的格式一樣。
跟當初我們用ngrep的方式一樣，我們使用urlsnarf并且在 10.1.1.2 的服務器上執行Whisker，所得到的結果如下：
# urlsnarf
urlsnarf: listening on eth0
10.1.1.21 - - [16/02/2001:03:58:43 +0530] "HEAD http://10.1.1.2/ HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:43 +0530] "GET http://10.1.1.2/cfdocs/ HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:45 +0530] "GET http://10.1.1.2/scripts/ HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:45 +0530] "GET http://10.1.1.2/scripts/cfcache.map HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:48 +0530] "GET http://10.1.1.2/cfcache.map HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:50+0530]"GET
http://10.1.1.2/cfide/Administrator/startstop.html HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
10.1.1.21 - - [16/02/2001:03:58:52 +0530] "GET http://10.1.1.2/cfappman/index.cfm HTTP/1.0" - - "http://10.1.1.2/" "Mozilla/5.0 [en] （Win95; U）"
使用urlsnarf唯一的缺點是，它現在的程序是寫死的，只監聽TCP通訊端口80（純文字HTTP），3128（MS-proxy）以及8080（generic/squid proxy）。從其它通訊端口傳輸的HTTP協議資料則完全被忽略。要想改變這種限制，你必須在urlsnarf的原始程序代碼中做一些小小的改變。然而，光是urlsnarf所提供的功能，就已經遠遠的超過它所給我們的限制了。
因為urlsnarf以CLF格式產生日記，我們可以將它的輸出結果，轉送到任何在網頁服務器上使用CLF格式分析日記的日記分析軟件。
監測惡性入侵性網頁瀏覽行為
通過urlsnarf的輸出，我們可以開始建立式樣比對程序，以尋找網絡入侵事件。在這里我利用一個簡單的Perl程序來跟urlsnarf一起監測一些基本的網絡入侵行為，假想體驗一下在企業防護中的IDS應用。我們會把urlsnarf的執行結果轉傳給這個式樣比對程序，通過式樣比對的方法監測網絡入侵行為。
式樣比對程序的第一步是，定義一連串入侵性的URL查詢。為了簡單起見，我們只列出某些URL如下:
%cgis = （"/msadc/msadcs.dll" => "mdac",
"/msadc/Samples/selector/showcode.asp" => "showcode",
"/cgi-bin/guestbook.cgi" => "guestbook",
"/cgi-bin/test-cgi" => "test-cgi",
"/cgi-bin/finger" => "finger",
"/cfdocs/expelval/exprcalc.cfm" => "exprcalc",
"/cgi-bin/phf" => "phf",
"/scripts/samples/search/webhits.exe" => "webhits",
"/scripts/iisadmin/ism.dll" => "ism",
"/scripts/tools/newdsn.exe" => "newdsn",
"/scripts/perl.exe" => "perl_exe",
"/scripts/proxy/w3proxy.dll" => "w3proxy"
）;
我們使用了%cg集中儲存所有我們需要的惡意URL查詢式樣。在這里，我們也可以從一個含有這些“特征”的檔案，動態建立這個查詢式樣庫。 注意，以上的URL本身并無害；然而，它們通常被黑客利用來做惡意的網頁攻擊的基礎。（例如：msdacs.dll就可以被用來破壞 MDAC/RDS）。
下一步，是設定容忍的最低程度，即：如果某個訪客查詢某個URL超過三次的話，這個訪客的IP地址就會被列在黑名單中。在我們的程序里，定義如下：
$threshold = 3;
下一段重要的程序代碼，是一個以while敘述開始的循環，這個循環會從urlsnarf讀取每一個CLF紀錄，并且做分析。為了避免談到太多Perl程序語言的細節，有關 while 循環的說明就像以下這樣：
while（〈 〉） {
# # parse incoming log line
# $logline = $_;
# # pick out the IP，timestamp andURLfrom theCLFline
# $logline =~ /（S+）.+?（[.+]）.+?（".+?"）.+/;
# $ip = $1;
# $time = $2;
# $url = $3;
# # select the resource from the URL
# $url =~ /w+s+.*//.+?（/.*）s+.*/;
# $resource = $1;
# check if there is a match with theURL
變量$resource的值為URL回詢中的resource字符串。例如，如果URL為 http://10.1.1.2/msadc/msadcs.dll，那么 resource 字符串的值就是 /msadcs/msadcs.dll。
接著是，尋找我們的URL“特征”庫，看看所查詢的URL字符串是否符合其中的一個特征。如果式樣符合，我們找出這個查詢出處的IP地址， 然后將它的訪客指數加一。如果訪客觀存在指數超過了我們的容忍底線，那么我們將這個IP地址標為黑客地址。
下面是式樣比對部分的程序代碼:
# check if there is a match with the URL
if（$cgis{$resource} ne ""） {
push（@{ $offender_list{$ip} }, $cgis{$resource}）;
# check if the threshold count is crossed
if（$offence_count{$ip}++ > $threshold） {
# response to intrusion detected
print STDERR "** $ip " . join（" "，@{ $offender_list{$ip} }） . "n";
} }
將這個程序取名為pattern_match.pl。開始使用urlsnarf以及 pattern_match.pl，urlsnarf 以及pattern_match.pl 得出來的結果應該是如下所示:
#urlsnarf| pattern_match.pl
一個Whisker掃描范例，執行urlsnarf以及pattern_match.pl，監測地址為 10.1.1.2 的IIS5.0 服務器平臺，我們得到了以下的結果:
** 10.1.1.21 webhits ism showcode newdsn
** 10.1.1.21 webhits ism showcode newdsn mdac
** 10.1.1.21 webhits ism showcode newdsn mdac w3proxy
** 10.1.1.21 webhits ism showcode newdsn mdac w3proxy perl_exe
這些結果告訴我們，來自IP地址 10.1.1.21 的訪客為惡意訪客，并且也列出了一連串針對 10.1.1.2 的相關可疑的URL回詢。黑客回報系統是在“特征 URL”已經被查詢三次了以后，第四次類似的查詢又發生（newdsn）才被激活的。
【編輯推薦】
