網絡安全是當前的熱門話題，互聯網安全性差的重要表現是服務器軟件大多存在漏洞，黑客的入侵行為大多是利用服務器漏洞實現的。現在，筆耕論文新浪博客，每天都有新的服務器軟件出現，但這些軟件基本上都存在著漏洞，按照傳統的測試方法，依靠測試人員去分析代碼來完成測試，顯然是滿足不了需求的。網絡服務器軟件的漏洞測試是一個十分重要的問題，設計一個較為自動化、通用的漏洞測試工具是十分必要的。
一般漏洞研究方法是先熟悉軟件功能，分析服務協議，檢查程序代碼，然后再推測什么情況下會出現漏洞。這是一個工作量很大的過程，而且開發出來的測試程序也是針對特定軟件，不能通用。我們的測試軟件要做到通用，就要找出網絡服務器軟件的共同特性，采用易于配置，易于擴展的結構。

1.網絡服務的共性及漏洞產生原因
網絡服務基本上都是基于客戶機-服務器模型。
                              
 請求數據包

 響應數據報

  圖1 
                  
客戶機發出請求數據包，服務器返回響應數據包，即Request-Response方式。服務的共性就在于客戶機與服務器通過數據包進行通信。每個服務都有自己的應用層協議。服務器軟件的應用層協議決定了服務器對請求數據包里的內容怎么解釋，所以協議也就體現在數據包中。服務器軟件的漏洞一般是因為服務器對異常的請求數據包不能正確響應。對于異常的請求數據包，像數據包里有太長的文件名或文件目錄路徑包含特殊字符等，如果服務器軟件不能正確處理，就可能導致緩沖區溢出、泄露服務器重要信息、拒絕服務等問題，使得入侵者有機可乘。如IIS服務器的UNICODE編碼漏洞，對于未打補丁的IIS服務器，如果入侵者輸入類似的請求,IIS服務器會將文件路徑中的%255c解釋為“/”，繞過系統安全策略，在服務器上執行dir 命令，并將結果返回給客戶端。利用這種方法，可在服務器上執行任何系統命令，能輕而易舉的控制整個服務器。我們的測試程序就是要能自動生成各種可能導致服務器不正常工作的請求數據包，并分析返回的響應信息，找出漏洞所在。

2.測試程序的設計方案
為了通用，測試程序不能過多涉及到具體協議，而測試數據包的格式又要符合具體協議，這是一個矛盾。我們采用樣本包和動態鏈接庫的方法來解決這個矛盾。樣本包，即有代表性的數據包，依www服務為例，請求數據包“GET /pub/index.htm HTTP/1.1”可以很好的代表一類請求，就可以作為一個樣本包。如果只對這個樣本包中的某個數據域進行變換，則生成數據包的格式一般也是滿足www服務通信協議的。對于一個具體服務，它的協議體現在通信所用的數據包中，我們可以收集一個足以體現該服務協議的樣本包集，采用一個腳本來描述這些樣本包，要測試不同的服務軟件，只須編寫與之對應的腳本即可。測試程序只對腳本進行處理，不必與具體協議相關，也就實現了通用性。整個測試程序的系統框圖如圖2所示，測試數據包生成模塊處理腳本，生成測試數據包，發送給服務器；響應信息分析模塊分析返回信息，并將分析結果保存在記錄文件中。

腳本

記錄文件
                                圖2
2.1腳本
腳本是對樣本包集的描述，服務器軟件的協議體現在腳本中。測試數據包就是對樣本包的某個域進行變換后得到的數據包。
為了便于程序處理，定義了幾個關鍵字：
SAMPS , 樣本包開始；ITEM , 數據項;  SAMPE ，樣本包結束； RESULT ,返回結果特征串；
“ ; ”，注釋，如果一行以 “;” 打頭，則這一行是注釋行。
腳本中依次列出各個樣本包，每個樣本包分成幾個數據域，每個數據域用一個數據項來表示。
GET /pub/index.htm HTTP/1.1的腳本描述為：

SAMPS
ITEM COMM GET
    ITEM  PATH  /pub/
    ITEM  FILE  index.htm
ITEM  VER  HTTP/1.1
RESULT …
  SAMPE

每個數據項由三部分組成，以第一個數據項ITEMS COMMI GET 為例： ITEMS，關鍵字，標識數據項開始（每個數據項占一行，因此無須關鍵字標識數據項結束）；COMM：數據項類型名，數據項類型名決定了它的變換處理函數；GET： 數據項的內容。

2.2測試數據包生成模塊
 測試數據包生成模塊是整個測試工具的關鍵所在，只有生成最可能導致服務器出問題的請求數據包，才能發現服務器軟件的漏洞所在。但又不能產生過多的數據包，使得測試效率太低。從統計測試的角度來說,就是要生成最可能導致服務器出錯的數據包的樣本集。
測試數據包生成模塊對腳本的處理過程為：從腳本中讀出一個樣本包，腳本處理函數構造描述樣本包的鏈表，鏈表的結構為:
typedef struct RULELIST
{
     rulenode* rulelisthead;
     rulenode* rulelistend;
}RULELIST;
樣本包中的每一項為鏈表中的一個節點rulenode；
結點rulenode的定義為
   typedef struct _rulenod
{  
  char  type[8];        //數據項類型名
char item[128];       //數據項內容
  _rulenode *nextnode;  //指向下一個結點的指針
}rulenode;

構造好鏈表后，對該樣本包里一個數據項的內容進行變換，而保持其它數據項不變，生成測試數據包，發送給服務器，分析返回信息，將測試結果寫入記錄文件，處理完該樣本包的所有數據項后，釋放鏈表，讀出下一樣本包，重復上面的處理過程，直至腳本結束。
模塊中對數據項內容進行變換的處理函數做成DLL動態鏈接庫，調用時根據數據項類型名進行調用。這樣使得該測試程序易于擴展，如果被測試軟件的數據包中有原測試程序未定義的數據項類型，只需在腳本中加入新的數據項類型， 同時將對應的處理函數做成DLL動態鏈接庫的形式，拷貝至測試程序目錄下即可，而原有的程序一點也不必改動。

2.3響應信息分析模塊
   響應信息分析模塊主要對返回信息進行特征串搜索,記錄下服務器軟件出現異常時的情況。特征串定義在腳本中,特征串搜索采用Boyer-Moore字符串匹配算法.如果返回信息中有匹配的字符串,就意味著服務器可能出錯.例如，IIS 返回 “The remote procedure call failed ” ,就是RPC 服務出現錯誤。由于很多情況下返回信息很難預料，即便采用人工智能的方法也難判斷服務器到底出了什么問題。所以響應信息分析模塊只是檢測異常，將異常記錄下來，進一步的分析判斷還需要人工介入。    
 

 

本文編號：6512