熱門搜索:大學畢業論文 碩士畢業論文 博士畢業論文 碩士英語論文 碩士mba論文 無憂論文網

當前位置:無憂論文網 > 碩士畢業論文 >

代寫計算機網絡安全碩士論文樣本《基于agent分布式防火墻原型系統》

  • 發布日期:2012-03-19
  • 責任編輯:計算機網絡安全碩士論文
  • 論文字數:0
  • 點擊:
  • 論文編號:
  • 論文類型:
  • 論文價格:0

前  言

自從有了人類社會人們就不斷追求快速、高效、安全的通信方式,通信技術的每一次大發展都會大大地加快人類社會的文明進程。特別是計算機網絡的出現正在并將繼續深刻地改變人們的生產和生活方式。然而,如同其他任何一種科學技術的發展在給人們帶來好處的同時也給人們帶來災害一樣,計算機網絡也有負面效應,這就是網絡信息安全問題。機密泄露、數據被盜和篡改、系統因為受到攻擊而癱瘓,諸如此類的事件在網絡上時有發生。1986年美國digital公司安裝第一個商用防火墻,然而直到1988年的蠕蟲事件才使人們真正認識到網絡安全問題的存在。最近幾年網絡迅猛發展,安全問題也越來越突出,銀行、股票部門是攻擊的主要目標。特別是從2001年的5月份中美黑客大戰以來,安全問題更加得到重視。中國的五星紅旗飄揚在美國的許多網站主頁中,然而許多中國政府網站也被黑。網絡安全問題上升為國家安全問題。在2001年中安全軟件保持100%的增長率,居軟件行業之首,其中有三大賣點:加密、反毒和防火墻。目前,防火墻仍然是人們解決網絡安全問題的首選辦法。

然而隨著網絡的爆炸式發展,網絡新技術的不斷出現,傳統防火墻的弊端開始顯露,如瓶頸問題、防外不防內、單點失效等。于是人們針對這些問題提出了一種新解決方案——分布式防火墻。分布式防火墻從根本上克服了傳統集中式防火墻缺陷的根源,即網絡的拓撲依賴性,所以它能克服集中式防火墻的缺陷而又保留它的優點。分布式防火墻一經提出便得到廣泛關注,進而設計并實現原型系統,美國Network_1(網屹)公司在2001年率先推出了商用分布式防火墻CyberWallPLUS。而國內還沒有分布式防火墻產品出現,在這種形勢下我們展開了分布式防火墻的研究。

本文是在南京郵電學院科研項目“基于agent分布式防火墻原型系統”的基礎上寫成。原理是實現的基礎,實現是原理的具體化,本文充分體現了理論與實踐的緊密結合,既有理論高度,又有模型實現。原理的探索是艱難的(資料少),代碼的實現更是困難。雖然傳統防火墻開發技術已成熟,但由于網絡安全問題涉及到太多的機密問題,所以這項技術總是以原理的形式出現,具體實現方法很少有人提及,防火墻代碼是不公開的,微軟操作系統內核也是不公開的。然而所有這些困難在自己的努力下被一一化解,最終完成了項目和論文。在經過一年時間深入、系統、全面的研究之后,我取得了“一項突破,四項成果”。一項突破是:掌握了Windows主機防火墻的開發方法。四項成果是:①深刻地概括了分布式防火墻(簡稱DFW)的基本原理、體系結構、運作機制等一系列理論問題。②設計了DFW模型的實現方案。③實現了DFW模型。④提出了DFW模型的改進方案。

本文內容安排如下:

 在第一章中主要介紹了在DFW研究中所涉及到的基本理論和基本技術。DFW研究的基礎是掌握防火墻技術和分布式技術。介紹了Windows網絡協議結構和Windows主機防火墻的各種實現方法;介紹了數據庫和網絡編程等基本的分布式技術。

 在第二章中主要闡述了DFW的基本原理、本質特征、體系結構和運作機制等基本問題,這是至關重要的,因為只有掌握了本質特征才能把握研究的方向。首先全面地概括了目前傳統防火墻的主要缺陷,分布式防火墻提出的背景;接著闡述了DFW的一系列基本理論問題;介紹了目前實現的一些原型系統的基本原理;

 在第三章中闡述了實現應用層防火墻的關鍵技術——Winsock 2 SPI技術。

 在第四章中闡述了實現核心層防火墻的關鍵技術——TDI鉤子驅動程序、NDIS中間驅動程序和NDIS鉤子驅動程序的實現技術。

 第五章具體介紹了DFW模型的設計與實現。設計本著實現DFW的本質所要求的功能,基于C/S模式設計,并且只在應用層實現封包過濾。

 第六章提出了DFW模型的改進方案和努力方向。

 

第一章 防火墻技術與分布式技術概述

本論文的主題是研究分布式防火墻并予以實現,分布式防火墻是防火墻技術與

分布式技術相結合并融安全策略的分發和日志的收集機制的產物,所以掌握這兩項技術是研究分布式防火墻的基礎,本章對這兩方面的技術進行了概述。

1.1 防火墻技術概述

1.1.1  防火墻的定義

防火墻一詞的原始含義是指能阻擋火蔓延的墻,具有隔離作用。在計算機中借用這一詞來表示類似的含義。計算機科學中,防火墻是指能將局域網與外部網絡隔離開來的軟件或硬件實體。傳統上認為,防火墻是指設置在不同網絡(如可信任的企業內部網和不可信任的公共網)或網絡安全域之間的一系列部件(包括軟件和硬件)的組合。它處在不同網絡或網絡安全域之間數據傳輸的唯一出入口處,在兩個網絡環境之間提供一個安全網關,對所有進出的數據流進行檢查和過濾,在被保護網絡和外部網絡之間架起一道屏障,以阻止外部用戶非法使用內部網的資源,保護內部網絡的設備不被破壞,防止內部網絡的敏感數據被盜取。

    目前一般認為,防火墻是一個分離器、限制器、也是一個分析器,它有效地監控了內部網和外部網之間的活動,從而保證了內部網絡的安全。通過制訂安全策略,它可監測、限制、更改跨越它的數據流,盡可能地對外部屏蔽網絡內部的信息、結構和運行狀況,有選擇地接受外部訪問,以實現網絡的安全保護。

1.1.2  防火墻的基本原理

 根據防火墻實施的依據可分為兩種基本類型:包過濾防火墻和代理防火墻(或稱代理服務器)。

⑴ 包過濾型防火墻的基本原理

包過濾防火墻是基于數據包的頭部信息(或數據包的內容)來決定轉發還是

丟棄的。原則上每一層的包頭都可以作為檢查的對象,包括數據鏈路層頭、IP頭、TCP/UDP頭等。由于在廣域網上主機的硬件地址即MAC地址很難與IP地址綁定,所以檢查數據鏈路層包頭沒有多大意義,但在局域網內部可以將MAC地址與IP綁定,從而可以為內部網的安全防范增加一個依據。另外,在應用層所有的包頭已全部被剝去,沒有包頭可以檢查,但可以對包的內容進行檢查,提取有關信息作為判斷是放行還是拒絕的依據。

在TCP/IP層,包過濾的一般過程是,在網絡層對IP包頭處理之前搶先截取包,檢查包頭(包括IP頭和TCP/UDP頭)中的有關字段是否與規則集中的規則匹配,如果允許轉發就將包交給網絡層按常規往下處理,否則丟棄。

表1-1概括了各層包過濾所要檢查的包頭字段(或內容信息),要理解為什么要檢查這些字段和內容,需要對TCP/IP協議以及黑客的攻擊方法有較深入的理解。

表1-1 網絡協議各層包頭的作用、檢查的字段及防范的攻擊類型

包類型 包頭的功能 檢查的包頭字段(或包內容) 檢查該字段可以防范的攻擊類型

應用

層包 無包頭 1.分析Socket連接,可獲取有關信息,如哪個應用程序連網,源和目的端口、IP地址,協議。

2.分析包中的內容,可獲得網址、郵箱地址、FTP文件名等。 1.防范木馬攻擊。

2.對本機的服務和端口進行控制。

3.對訪問的時間進行控制(雙向)。

4.對訪問的網絡進行控制(雙向)。

TCP包 連接的可靠性;發送報文的順序等。 序列號;確認號;ACK標志位;SYN標志位;端口等。 拒絕服務攻擊;攔截TCP連接等

UDP包 只提供端口和校驗 端口 對端口進行控制

IP包 主要用于路由 協議;IP地址;任選項;分段偏移量 對協議、IP地址和路由進行控制

ICMP包 在雙方之間發送控制和管理信息 如下幾種報文類型可被黑客利用,應阻止: 流入的echo請求和echo響應;流入的重定向報文;流出的目的不可達報文;流出的服務不可用報文。 向路由器發送錯誤報文來擾亂路由表;探測網絡

鏈路

層包 局域網中尋址 MAC地址 對主機進行確認

⑵ 代理型防火墻的基本原理

這種防火墻的基本特征是針對每一種應用設計一個代理軟件,使運行代理軟

件的主機代表內部網絡的所有主機與外部網絡通信,充當兩個通信點之間的中介,從而屏蔽了內部的所有細節,使之對外不可見,從而起到保護作用。代理防火墻與本文的關系不是很密切,所以詳細情況從略。

1.1.3  Windows 網絡協議結構與用戶編程接口 

本文要研究基于 Windows平臺的分布式防火墻,防火墻在Windows主機上實現,采用包過濾的方法,因而要在網絡協議(TCP/IP)中找到編程接口,從而編程來截獲網絡封包,因此必須透徹、深刻地研究Windows的網絡協議結構,找出所有的網絡編程接口。圖1.1給出了Windows網絡協議的詳細結構[8]。圖1.2是簡化圖。從圖我們可以看出,整個網絡協議由四大部分和四個接口組成,下面分別加以簡要介紹。

◆四大部分:

① 應用程序:實現與用戶的交互。

② Winsock與傳輸提供者:Windows Sockets規范本意在于提供給應用程序者一套簡單的API,成為各家網絡軟件供應商共同遵循的標準,因此這份規范定義了應用程序開發者能夠使用,并且網絡軟件供應商能夠實現的一套庫函數調用和相關語義。傳輸提供者實現協議和功能的擴展。

③ TCP/IP協議驅動程序:完成分段、打包(解包)、添加(剝去)包頭等協議功能,實現傳輸層和網絡層協議。

④ 網卡驅動程序:添加(剝去)適宜于特定網卡硬件的包頭,實現鏈路層協議。

◆四個接口:

① API接口:應用程序接口(Application Programming Interface)。

② SPI接口:服務提供者接口(Service Provider Interface)。

③ TDI接口:傳輸數據接口(Transport Data Interface)。

④ NDIS接口:網絡驅動程序接口規范(Net Driver Interface Specifacation)。

1.1.4  幾種常用Windows網絡封包截獲技術概述

 目前,常用的Windows網絡封包截獲技術有以下幾種:Winsock 2 SPI傳輸服

務提供者、TDI鉤子過濾驅動程序、NDIS中間過濾驅動程序和NDIS鉤子過濾驅

 

   

          圖1.1  Windows網絡協議結構

 

圖1.2  Windows網絡協議結構簡化圖及其與TCP/IP協議的對照

動程序。下面分別加以介紹。

⑴ 使用Winsock 2 SPI技術截獲網絡封包

利用系統提供的傳輸服務提供者接口,添加一層傳輸提供者DLL,使得過往

的封包經過自定義的傳輸提供者DLL程序,實現對封包的截獲、分析與處理。

Winsock 2 SPI的技術特點:Winsock 2 SPI工作在API之下Driver之上,屬于應用層的范疇。利用這項技術可以截獲所有的基于Socket的網絡通信。比如:IE、OUTLOOK等常見的應用程序都是使用Socket進行通信。它的技術特點主要有:

◆優點:

①工作在應用層,以DLL的形式存在,編程、調試方便。

②跨 Windows 平臺,可以直接在 Windows 98/ME/NT/2000/XP上通用,

Windows 95 只需安裝上 Winsock 2 for 95,也可以正常運行。

③效率高,由于工作在應用層,CPU 占用率低。

④封包還沒有按照低層協議進行切片,所以比較完整,很容易做內容過濾。

⑤做防色情之類的軟件,不用根據具體的瀏覽器進行分別編程,既簡單又安全。

◆缺點:

①不用 Socket 的網絡通信無法攔截,比如:使用NetBios的網上鄰居,和使

用ICMP協議的Ping所發送的包無法截獲。

②微軟對SPI設計的問題,導致如果安裝順序出錯很容易造成網絡癱瘓。這

意味著如果同時安裝幾個使用SPI技術的軟件,而且有使用非標準安裝方式的軟件,很容易有的被繞過或者不能正常網絡通信。所以建議編寫SPI程序一定要用標準的安裝方式。

SPI在操作系統中的結構如圖1.3所示,我們需要處理的是傳輸服務提供者。

 

        圖1.3  SPI在Windows網絡協議結構中的位置

⑵ 使用TDI hook技術截獲網絡封包

Windows網絡協議結構的TDI部分的結構如圖1.4所示,在Socket接口和

TDI接口中間有一層TDI客戶驅動程序(Socket仿真器、NetBIOS仿真器、重定向器、服務器等)。傳輸驅動程序接口(TDI)是定義在傳輸協議棧上邊界的內核模式網絡接口,利用該接口我們可以編寫自己的具有過濾功能的Socket仿真器來替代原來的Socket仿真器。我們也可以編寫一個過濾驅動程序利用“鉤子”技術將其掛接到TDI客戶驅動程序和協議傳輸驅動程序之間來截獲網絡封包。

 

        圖1 .4  Windows網絡協議的TDI部分

⑶ 使用NDIS中間驅動程序截獲網絡封包

NDIS是Network Driver Interface Specification的縮寫,即網絡驅動程序接口

規范。NDIS是一個接口函數庫,其中包括幾百個NDISXxx函數,NDIS 橫跨傳輸層、網絡層和數據鏈路層,為網絡傳輸提供標準的網絡接口,所有的網絡通信

最終必須通過 NDIS 完成。它在DDK的NDIS.h中定義,在NDIS.lib中調

用。NDIS在Windows網絡協議中所處的位置如圖1.5所示。

 

                圖1.5  NDIS在Windows網絡協議中所處的位置

NDIS支持編寫3種類型的驅動程序:Miniport驅動程序,中間驅動程序,

Protocol驅動程序。

Miniport驅動程序可以通過NDIS接口來完成對網卡的操作,同時開放Miniport接口供上層驅動程序調用。可以用Miniport驅動程序來實現網卡驅動程序。

 中間驅動程序位于Miniport和Protocol驅動程序之間,在它的上邊界是Miniport接口,在它的下邊界是Protocol接口,理論上可在這里插入幾層中間驅動程序。

 Protocol驅動程序開放Protocol接口供底層驅動程序調用,可以用它來實現協議驅動。

 由上述可知,利用NDIS中間驅動程序可以在網卡驅動程序和傳輸協議驅動程序之間插入一層自己的處理,從而可以用來截獲網絡封包并重新進行封包、加密、網絡地址轉換及過濾等操作。由于NDIS中間驅動程序位于網卡和傳輸驅動程序之間所以它可以截獲較為底層的封包,從而可以完成很底層的操作,用來編寫網絡安全軟件安全系數很高。

⑷ 使用NDIS hook技術截獲網絡封包

 微軟提供了以下幾種標準的驅動程序接口編程方式:

①TDI傳輸層過濾驅動程序(TDI Filter,比如常見的Tcp Filter Driver)。

②協議驅動程序(Protocol Driver)。

③中間驅動程序(IM Driver)。

④小端口驅動程序(Miniport Driver)。

 其中TDI Filter Driver 和IM Driver通常做封包過濾。也是防火墻和VPN軟件常用的技術。但是它們都有一些缺陷:

 TDI Filter Driver屬于Upper Driver,位于TcpIp.sys之上,這就意味著由TcpIp.sys接收并直接處理的數據包就不會傳送到上面,從而無法過濾某些接收的數據包,典型的就是ICMP,ICMP的應答包直接由TcpIp.sys生成并回應,上面的過濾驅動程序全然不知。IM Driver功能比較強大,但編程接口比較復雜。最麻煩的是安裝,自動化安裝太困難。

 NDIS-HOOK克服了上面的缺陷。NDIS-HOOK的工作原理是直接替換NDIS的函數庫中的函數地址,這樣只要發向NDIS的請求就會先經過我們自己函數的處理,這樣就非常簡單,處理完轉發給系統函數就完成了。NDIS-HOOK技術有以下特點:①編程方便、接口簡單、思路明確、性能穩定。②更靈活,可以僅僅截獲自己需求的,不需要冗余的代碼。③功能強大,可以截獲所有NDIS和TDI函數完成的功能。當然比標準方式功能強大許多。還可以用這項技術延伸到HOOK所有系統函數。④安全性高,這樣截獲封包較為低層,不容易被穿透。⑤安裝簡單。

1.1.5  實用防火墻技術的進一步討論

從上面的討論可看出,實現防火墻有兩類方法:“插入法”和“鉤子法”。所

謂“插入法”是指在現有的網絡協議棧結構中插入一層來實現封包過濾,典型的方法有Winsock SPI分層服務提供者和NDIS中間驅動程序;所謂的“鉤子法”是指對網絡中現有的接口庫函數的功能進行擴充,就相當于在庫函數上掛接了一段新的代碼,用這段新的代碼來實現過濾。鉤子法的例子有Winsock SPI基礎服務提供者、TDI鉤子驅動程序和NDIS鉤子驅動程序。

  二者相比較,插入法的實現難度較大,鉤子法的實現較為方便一些。

1.2 分布式技術概述

1.2.1 分布式系統的概念與模式

(1) 分布式系統的概念。

分布式系統有很多不同的定義,但其中沒有一個是令人滿意的或者還是令所有人接受的。下面給出大致的描述:

“一個分布式系統是一些獨立的計算機的集合,但是對這個系統的用戶來說,系統就像一臺計算機一樣。”

這個定義有兩方面的含義:第一,從硬件角度來說,每臺計算機都是自主的。第二,從軟件角度來說,用戶將整個系統看作一臺計算機。二者都是必須的,缺一不可的。

其硬件特征有:總線式系統和交換式系統兩種類型。

其軟件特征有:分成松耦合系統和緊耦合系統兩種。松耦合的分布式軟件允許分布式系統的機器和用戶基本上各自獨立,但也在必要的情況下進行一定程度的相互作用,一般為客戶/服務器模式。真正的分布式系統是緊耦合的。緊耦合的分布式軟件能將各臺計算機硬件緊密地結合在一起。這樣一個系統的目標是使用戶產生一個錯覺:整個計算機網絡是一個分時系統,而不是一個互不相同的機器的集合。另一些人認為,分布式系統是在網絡計算機的集合上運行,但行為卻像一個虛擬的單處理機。不管人們如何對它進行描述,根本思想是:用戶不必意識到系統中有多個CPU的存在。目前真正的分布式系統還沒有完全實現。

(2)分布式系統的工作模式

 ◆客戶/服務器模式:這是傳統分布處理技術。客戶為服務和資源的消費者,服務器為服務和資源的提供者。這種模式下服務器對所能提供的資源(如數據庫)服務進行廣播,而實現服務的代碼同時駐留在本地服務器上,如果客戶方對服務器上的某些信息資源感興趣,它只需調用一個或多個服務器提供的服務,但客戶方需要某些“智能”來決定該使用哪個服務。這樣由服務器擁有主要處理器資源、軟件資源和信息資源,客戶端只需提供界面讓用戶選擇服務。到目前為止,大多數分布式系統都是屬于這種模式。它們的技術支撐有RPC、CORBA。

 ◆移動智能代理模式:這是新一代網絡分布處理技術。該模式的關鍵特征就是資源和方法(或服務)的分離,網絡中的任一主機都擁有一定的處理資源,方法(在移動智能代理的形式下)沒有鎖定在一臺主機上,而是在整個網絡內可共享。因而它具有資源和方法任意組合的高度靈活性。

 比較這兩種模式,可以發現計算模式的靈活性在增加:第一種模式中客戶機和服務器融合為主機概念,資源和方法都被鎖定在服務器上;第二種模式中資源和方法可以分離和重新組合,因而系統的效率提高。

1.2.2 客戶/服務器(C/S)模式基本技術介紹

 由于C/S模式是最為成熟的技術,在目前的絕大多數分布式系統中都采用這種模式,在本文的DFW模型實現中也采用這種模式,所以這里對C/S模式的技術要點給予簡介,主要涉及網絡編程和數據庫編程。

(1)網絡編程技術概述

 分布式防火墻是一個分布式系統,數據要在不同主機之間傳送,因而要進行網絡編程,網絡編程的技術十分廣泛,這里只討論本課題中用到的網絡編程技術。

①認識幾個MFC類。

 CSocket類是CAsyncSocket的派生類,它繼承了CAsyncSocket類的許多封裝了API的成員函數,并且管理了通信的大多數方面。它提供了對于同步操作CArchive對象十分重要的阻塞功能,且與類CSocketFile和CArchive一起來管理對數據的發送和接收,使收發數據就象在本地硬盤上存取文件一樣簡單。

 CSocketFile類是從CFile繼承的,但它并不和真正的物理文件相關聯,而是和CSocket類對象關聯在一起,它并不支持CFile里與位置有關的函數,也不支持CFile中與鎖有關的函數。CSocketFile類調用與之關聯的CSocket類中的函數來收發數據。

 CArchive類和CSocketFile類相關聯,它維護一個緩沖區,當存儲文檔的緩沖區滿時,與之相關的CSocketFile將緩沖區的內容讀出來,對應到CSocket類中的函數為Send。相應地,當裝載緩沖區滿時,這時它停止讀數據,調用CSocketFile類函數將內容讀進來,對應到CSocket類中的函數就是Receive。

②服務器端實現方法。目前網絡通信多以客戶/服務器(C/S)的方式進行,服務器被動等待連接,客戶主動建立連接。所以客戶端與服務端的實現方法有所不同。圖1.7說明了服務器端的編程模式。

 

圖1.7  服務端的編程模式

③客戶端實現方法。

 圖1.8說明了客戶端的編程模式。

 

圖1.8  客戶端的編程模式

(2)數據庫編程技術概述

 一個分布式系統常常需要數據庫的支持,分布式防火墻也需要數據庫的支持。下面討論在DFW模型實現中要用到的數據庫編程技術。由于課題選用Visual C++

作為編程工具,所以下面的討論是在VC中進行的。

①認識ODBC。開放數據互連(ODBC,Open DataBase Connectivity)是Microsoft Windows開放服務體系結構的一部分,是一個數據庫訪問的標準接口。Microsoft ODBC標準不僅定義了SQL語法的規則,而且定義了C語言同SQL數據庫之間的程序設計接口,經過編譯的C或C++程序就有可能對任何帶有ODBC驅動程序的DBMS進行訪問。所以,ODBC是應用程序和數據庫之間的接口,利用該接口,應用程序可以獨立于數據庫,數據庫也可以不依賴于特定的應用程序。

②認識記錄集。在MFC中兩個最主要的ODBC類為CRecordset和CDatabase。

類CDatabase的對象代表了和數據源的ODBC連接,而類CRecordset的對象代表了可滾動記錄集(通常為快照)。我們很少需要從類CDatabase中派生出類,但卻總是要從類CRecordset中派生出一些類,以便和數據庫表中的列相匹配。

 一個記錄集代表數據庫中的表或視圖等到一個VC++類的映射,是VC程序中的一個派生于CRecordset類的類,記錄集中的一個變量對應于表中的一個列。數據庫編程主要是使用記錄集中的函數進行編程。

③數據庫的創建。可以使用任何一種數據庫管理系統來建立數據庫。數據庫建立好后,使用控制面板中的ODBC管理器將數據庫與ODBC連接起來,這時就可以在應用程序中添加記錄集來對數據庫中的表進行操縱。

④使用記錄集對數據庫進行操作。數據庫的操作主要包括添加、刪除和更新記錄。圖1.6說明使用記錄集進行數據庫編程的一般方法。

 

               圖1.6  使用記錄集進行數據庫編程的一般法

1.2.3 移動代理模式簡介

 隨著微機的發展與普及,分布式系統應運而生。但目前的分布式系統主要是客戶/服務器模式,這種模式有它的局限性,在某些情況下甚至無能為力,agent技術是分布式計算發展的結果,它克服了傳統分布式計算的不足,增強了分布式系統的性能。

在agent研究的基礎上,20世紀90年代初人們提出了移動agent的概念。簡

單地說,移動agent是一個能在異構網絡中自主地從一臺主機遷移到另一臺主機,并可與其他agent或資源交互的程序。傳統的RPC客戶和服務器交互需要連續的通信支持,而移動agent可以遷移到服務器上,與之進行本地高速通信,這種本地通信不占用網絡資源。移動agent不需要統一的調度,由用戶創建的agent可以異步地在不同接點上運行,待任務完成后再將結果傳送給用戶。為了完成某項任務,用戶可以創建多個agent,同時在一個或若干個節點上運行,形成并行求解的能力。此外它還具有自治性和智能路由等特性。

1.3 小結

 本章對DFW系統開發中涉及到的防火墻技術和分布式技術進行了簡要的闡述,主要包括:防火墻的概念、Windows網絡協議結構與編程接口、Windows防火墻的各種開發方法、分布式系統的概念、數據庫編程、網絡編程等。

第二章 DFW的基本原理、運作機制與目前研究

2.1 傳統邊界防火墻的工作模型及其缺陷

2.1.1 傳統邊界防火墻的工作模型

 傳統邊界防火墻(Traditial Perimeter Firewall)建立在受限拓撲(Restricted Topology)和受控入口點(Controlled Entry Point)的概念之上,準確地說,它們建立在這樣的假定之上,每個入口點即防火墻內部的人是可信的,每個外部的人是或者至少是潛在的敵人[1]。這種防火墻在物理上嚴格區分內部網和外部網,內部網和外部網之間只有唯一的通道,防火墻則死守這一“咽喉要道”。它通過兩種方法區分數據流是來自內部網還是外部網:一是防火墻的接口,進入內部接口的就是內部網數據流,進入外部接口的就是外部數據流;二是主機的IP地址。

2.1.2 傳統邊界防火墻存在的主要問題

 上述工作模型能很好地工作在中小網絡中,但當網絡規模增大、網絡新技術不斷出現,這種工作模型的缺陷日益暴露出來,主要表現在以下幾個方面:

①防外不防內。傳統防火墻對內部數據流無法監視,全然不知,自然談不上阻止內部攻擊。有關資料表明,多數網絡攻擊來自內部,防范內部攻擊已必不可少。

②“瓶頸”問題。一方面網絡帶寬越來越高,這要求防火墻有很高的吞吐量,另一方面,黑客的攻擊方法也越來越多,防火墻處理的規則也必然越來越復雜,使防火墻處理速度下降。因而防火墻的功能(即防范攻擊的能力)和性能(即處理速度)之間是一對矛盾。

③“單點失效”問題。防火墻集萬千重任于一身,因而一旦防火墻配置不當或出現問題,則全網皆暴露于攻擊者面前。

④未授權訪問問題。多樣化的聯接方法諸如隧道、無線連接和撥號訪問等可使個人很容易建立一個繞過防火墻的連接,給網絡留下一個后門,造成網絡安全隱患。 

⑤網絡新業務受到限制。外聯網、移動用戶和通過網絡在家辦公(Telecommuting)等新業務新需求的出現使得內網的概念難以維持。

⑥端到端的加密對防火墻造成威脅。傳統的網絡協議沒有使用加密,因而防火墻能對數據流實施過濾。當加密技術和新一代網絡協議被使用的時候,防火墻因為沒有密鑰而不能理解流過的數據包的內容,從而不能實施檢查。

⑦安全模式單一。傳統防火墻的安全策略是針對全網制定的,全網中的所有主機遵從單一的安全模式,網絡中的主機和服務器在安全性上不具針對性和個性特點。

2.2 DFW概念的提出

由于傳統防火墻的缺陷不斷顯露,于是有人認為防火墻是與現代網絡的發展

不相容的,并認為加密的廣泛使用可以廢除防火墻。但加密不能解決所有的安全問題[1],防火墻依然有它的優勢,比如通過防火墻可以關閉危險的應用,通過防火墻管理員可以實施統一的監控,也能對新發現的bug快速作出反應等。也有人提出了對傳統防火墻進行改進的方案,如多重邊界防火墻,內部防火墻(Intrawall)等,但這些方案都沒有從根本上擺脫拓撲依賴(Topology-dependent),因而也就不能消除傳統防火墻的固有缺陷,反而增加了網絡安全管理的難度。為了克服以上缺陷而又保留防火墻的優點,美國AT&T實驗室研究員Steven M. Bellovin在他的論文“分布式防火墻”[1]中首次提出了分布式防火墻(Distributed Firewalls ,DFW)的概念,給出了分布式防火墻的原型框架,奠定了分布式防火墻研究的基礎。

2.3 DFW的基本原理

傳統防火墻缺陷的根源在于它的拓撲結構,分布式防火墻打破了這種拓撲限制,將內部網的概念由物理意義變成邏輯意義。按照Steven的說法[1],分布式防火墻是由一個中心來制定策略,并將策略分發到主機上執行。它使用一種策略語言(如KeyNote ,在RFC 2704文擋中說明[8])來制定策略,并被編譯成內部形式存儲于策略數據庫中,系統管理軟件將策略分發到被保護的主機上,而主機根據這些安全策略和加密的證書來決定是接受還是丟棄包,從而對主機實施保護。在DFW中主機的識別雖然可以根據IP地址,但IP地址是一種弱的認證方法,容易被欺騙。在DFW中建議采用強的認證方法,用IPsec加密的證書作為主機認證識別的依據,一個證書的擁有權不易偽造,并獨立于拓撲,所以只要擁有合法的證書不管它處于物理上的內網還是外網都被認為是“內部”用戶。加密認證是徹底打破拓撲依賴的根本保證。另外,在DFW系統中,各臺主機的審計事件要被上傳到中心日志數據庫中統一保存。

2.4 DFW的本質特征

弄清DFW的本質特征有助于正確認識DFW,從而劃清分布式防火墻和非分布式防火墻之間的界限。首先,安全策略必須由管理員統一制定。這是DFW區別于個人防火墻的根本所在。雖然它們都是主機駐留防火墻,但個人防火墻中的所有行為都是用戶個人行為,別人不能干涉。而分布式防火墻中的行為是集體行為,用戶個人不能干涉,每臺主機的安全策略都是整個組織安全策略的一個子集,全部主機的安全策略子集的并集構成一個組織的整體安全策略。所以DFW要求實行統一的策略管理。第二,策略必須被推到網絡的邊緣即主機上實施,這是分布式防火墻的又一本質特征。因為DFW的本意就是要將策略從邊界集中實施點遷移到網絡末端即主機中來實施,只有這樣才能徹底打破拓撲依賴。第三,日志必須統一收集、集中管理。因為管理員要對全網進行安全監控,他必須掌握充分的信息。日志是管理員了解信息、追蹤攻擊者的主要依據。綜上所述,DFW的本質特征可以概括為“策略集中制定分散實施,日志分散產生集中保存”。這一本質特征保證了從管理員的角度來看,他管理DFW就象管理邊界防火墻一樣,由他負責制定全網的安全策略并對全網的安全狀況進行監控,只不過策略的實施不在單一節點上而是分散到了多個節點處而已。

2.5 DFW的體系結構

一個典型的DFW的體系結構如圖2.1所示,它由三部分組成:邊界防火墻,主機防火墻和中心策略服務器組成。在DFW的體系結構中并沒有廢棄邊界防火墻,因為物理上的邊界依然存在,只是減輕了其肩上的擔子,邊界防火墻仍然執行傳統防火墻看守大門的任務,但由于它只處理與全網有關的安全問題,規則較少,因而效率較高。策略服務器是整個DFW的核心,主要包括中心管理接口、策略數據庫、審計數據庫和加密認證等模塊。中心管理接口負責人機交互,包括制定規則。規則的制定是通過使用規則定義語言或圖形用戶接口完成。管理員可以針對每臺機器制定規則,也可以將全網分成若干個域,然后針對每個域制定規則,各個域內使用相同的規則,域外使用不同的規則。主機防火墻駐留在主機中,負責策略的實施。在主機防火墻中如果不允許用戶干預,則只包含包過濾引擎、上載審計事件的模塊、加密模塊等,防火墻對用戶透明,即用戶感覺不到防火墻的存在,用戶不能修改規則,也不能繞過防火墻。如果允許用戶部分修改規則,并參與定制個性化的安全策略,則還要包含用戶接口。在一個典型的DFW系統中,所有主機防火墻(包括分支機構和移動用戶)和邊界防火墻皆受控于中心策略服務器。

 

圖2.1  DFW的體系結構

2.6 DFW的運作機制

2.6.1 策略的制定與分發機制

在DFW中,策略是針對主機制定的。當網絡較小,管理員可為每臺主機制定一套策略。當網絡較大時可對關鍵服務器單獨制定策略,而對一般用戶可分成若干組或域,如銷售組、研發組等,在每個組內使用相同的規則,組間使用不同的規則。

 策略如何分發到主機,有兩種機制。一種是策略服務器“推送式”。在該方式中,策略服務器監視網絡,如發現有主機欲進入本網,則對其進行檢查,如發現該主機無本網的安全策略,則將其策略推送給該機。當策略更新時,所更新的策略隨即被推送給相應主機。另一種是主機“索取式”。在該方式中,主機開機時主動向策略服務器索取自己的安全策略。當策略服務器中的策略被更新時,主機端得到通知,然后取回更新的策略。

2.6.2 日志的收集機制

 在DFW中,日志如何由主機傳送到中心策略服務器也有多種機制,第一種方式是服務器“定期采集式”。在該方式中,服務器定期掃描網絡,將各臺主機中的日志采集回來。第二種方式是主機“定期傳送式”。在該方式中,主機定期將自己的日志信息傳送給策略服務器。第三種方式是“定量傳送式”,即當主機中的日志信息量達到一定程度時,日志即被傳送到策略服務器。

2.6.3 加密認證機制

 任何分布式系統自身都面臨安全問題,DFW也不例外。DFW自身的安全至關重要,而傳統的認證方式是客戶機向服務器提供用戶名、密碼并用明文傳送,即使用一般的方法加了密,也容易被竊聽和破譯。還有一種是主機認證方式,根據IP地址進行認證,容易受到IP地址欺騙。在DFW中主機與策略服務器間的通信可以采用強認證方法,將認證協議如kerberos、X.509、IPsec等運用到本系統。

2.7 集中式防火墻向分布式防火墻演進的合理性及其面臨的困難

集中式防火墻在網絡發展的初期能很好地實現它的功能,因為那時網絡規模較小,黑客的攻擊方法種類有限。但隨著網絡的發展,網絡規模迅速擴大,應用類型日益豐富,情況越來越復雜,傳統防火墻開始顯得力不從心。而分布式防火墻順應了網絡發展的新情況,符合網絡技術發展的潮流。首先,它打破了拓撲限制,增強了網絡的開放性,使內部網進一步與因特網相容。其次,安全策略的實施被推向網絡邊緣,有利于制定個性化的和有針對性的安全策略。防火墻越是靠近邊緣即主機,它對數據流的理解就越充分,過濾就越細致,保護能力也就越強。第三,分布式技術符合技術的發展潮流。第四,便于構筑立體化全方位的安全陣營。另外,在主機中運行防火墻程序,幾乎對主機的性能沒有影響。

 DFW運行于企業(或其它組織)環境,它既防范外部惡意攻擊,也對內部人員的行為加以約束,因而用戶可能不會給予配合,甚至想方設法破壞主機中的防火墻。這是DFW面臨的主要困難[1]。所以防火墻在主機中必須是不可刪除的,最好嵌入到操作系統內核或網卡中。DFW也有一些技術上的缺陷,如它易于受到拒絕服務攻擊(如smurf攻擊)[5],比傳統防火墻難以實施入侵檢測[1],使用強的加密使傳統應用難以受到保護,因為它們不能理解加密數據[5]。另外日志文件的傳送增加了網絡通信量。

2.8 目前國內外DFW的研究進展情況

 自從1999年11月Steven的論文“分布式防火墻”發表以來,一些人們對分布式防火墻的實現進行了研究,提出了一些實現方法,并實現了原型系統。第一個商用分布式防火墻CyberwallPLUS也于2001年問世。下面對這些著名的實現方法加以分析。

2.8.1 基于OpenBSD UNIX的實現[2]

 這是提出DFW概念的Steven等人實現的原型系統。該原型系統在OpenBSD UNIX操作系統上修改內核并利用KeyNote、IPsec等技術加以實現的。OpenBSD是理想的開發安全應用的平臺,因為它有一體化的安全特性和庫(IPsec棧、KeyNote、SSL等)。該原型系統(主機部分)包括三個組件:內核擴展程序,用于實施安全機制;用戶層后臺處理程序,用于執行DFW策略;設備驅動程序,為內核和策略后臺程序之間的雙向通信提供接口。該原型系統在主機一端的功能模塊如圖2.2所示。

                 

        圖2.2  基于OpenBSD UNIX的實現方案

⑴ 基于OpenBSD實現原型系統的主要組件

 ①內核擴展部件。在UNIX操作系統中用戶使用系統調用connect(2)創建連接請求,使用accept(2)接受連接請求,一般情況下這兩個系統調用不對數據流進行安全檢查。為了在內核中實現包過濾功能需要對它們進行修改。

 ②策略后臺程序。它運行在用戶層,作用是根據策略服務器傳送過來的安全策略和通信中對方傳送的信任書(Credential,相當于證書)來決定接受還是丟棄包,并將判斷結果返回內核。

 ③策略設備驅動程序。該組件的功能是在用戶策略后臺程序和內核中被修改的系統調用之間建立一個通路。它運行于內核態,并向策略后臺程序提供read(2)、write(2)等功能調用,后臺程序通過調用這些函數與內核交互。

⑵ 基于OpenBSD實現原型系統的工作過程

 以入站連接請求為例,首先,遠端主機使用IPsec機制與本地主機進行安全協商,作為IKE(Internet Key Exchange)交換的一部分,KeyNote信任書被提交給本地主機。一旦內核收到TCP連接,就會建立一個上下文,其中包括IP地址、端口等,這些信息連同經由IPsec取得的信任書被一起提交給策略后臺程序。后臺程序調用read(2)讀取這些信息,再結合本地安全策略執行KeyNote評估,以決定連接是否允許。然后調用write(2)將判斷結果寫回內核,內核以此作為丟棄和接受包的依據。

2.8.2 基于網卡(NIC)的實現[3]、[4]

 該方案是美國國防部資助的研究項目,它是基于硬件—一種特殊的網卡(3Com 3CR990系列網卡)實現的,稱為EFW(Embeded Firewall)。這種網卡有內置的處理器和存儲器,它能獨立于主機操作系統而運行。它還有內置的加密引擎,使NIC之間可以通過IPsec加密通信。另外這種網卡使用廣泛且價格相對便宜。

⑴ EFW組件。

 EFW的主要組件分為主機端組件和服務器端組件,如圖2.3所示。

 ①EFW主機端組件。主要包括EFW增強的NIC、NIC驅動程序與運行時映像和EFW助理三部分。EFW增強的NIC中的固件(firmware)是在安裝EFW時裝

入的,它包括包過濾引擎和管理接口。包過濾引擎能根據標準的參數決定接受或拒絕包。管理接口負責從服務器下載策略并上載審計事件到審計數據庫,它也負

 

        圖2.3  基于NIC的實現方案

責管理本NIC與服務器之間的安全隧道。驅動程序在機器啟動時下載運行時映像(Runtime Image)并放入固件中,運行時映像的完整性如果受到破壞,NIC將無法正常工作,從而保證一旦EFW NIC被安裝,用戶將不能廢除它,除非通過策略服務器進行適當的操作,因為用戶的改動會破壞運行時映像的完整性。EFW助理的作用有兩個,一是給NIC傳送本機的IP地址,另一個作用是定期向策略服務器發送“心跳(heartbeat)”,這是為了防止惡意的用戶用其它NIC取代EFW NIC,因為這樣心跳就會停止,從而引起管理員的注意。

  ②EFW策略服務器端組件。主要包括三部分:前端管理組件、策略組件和審計組件。前端管理組件的主要目的是給管理員提供一個工具去建立和分發策略,也提供一個事件日志瀏覽器。策略組件的作用是接受管理員定義的策略并編譯成過濾規則,然后放入策略數據庫中。被保護的機器啟動時自動到策略數據庫中取回自己的安全策略。當服務器中的策略被修改時,策略組件能自動地將它“推”到相應主機上執行。審計組件收集并整理從各個NIC傳送過來的審計事件,并提供給管理組件處理。

⑵ EFW的集中管理模式

 EFW將主機分成若干個策略域,每個策略服務器管理一個策略域,一個策略域可以包含整個組織,也可只包含一兩個部門。在每個策略域中,NICs被根據主機執行的功能分成若干個組,每個組被分配相同的策略。策略中的規則也可以進行分組,以簡化策略的制定、分發和更新。審計事件的設置可建立在整個策略、策略類型或單個策略上。

 該實現方案的主要優點是基于硬件,不依賴操作系統,因而難以被繞過(No-Bypassable),具有堅固的基礎(Temper-Resistance)。缺陷是NIC的處理能力有限。

2.8.3 基于Windows平臺實現的實例

 CyberWallPLUS是Network-1(網屹)公司于2001年發布的分布式防火墻產品,基于Windows平臺實現,用于保護Windows NT/2000桌面機和服務器,包括中心管理部件、桌面機防火墻部件、服務器防火墻部件,邊界防火墻部件等。在這些部件中主機防火墻是最有特色的部件,用戶可以針對該主機上的具體應用和對外提供的服務設定個性化的安全策略,其主要模塊在系統中的位置如圖2.4所示,包

                          

        圖2.4  Windows主機防火墻模塊在系統中的位置

括包過濾引擎和用戶配置接口(可選的)。包過濾引擎采用嵌入內核的方式運行,處于鏈路層和網絡層之間。包過濾引擎提供精細顆粒度的訪問控制、狀態檢測和入侵檢測。用戶配置接口在安裝時是可選的,如果選擇安裝,則用戶或管理員可在本地配置安全策略。如果不安裝用戶配置接口,則策略只能由管理員從管理中心加以配置或使用遠程管理模塊進行配置。                  

包過濾引擎不單是一個主機防火墻,還集成了入侵檢測功能。過濾引擎的模塊結構如圖2.5所示[21]。首先,它結合有訪問控制能力的主機防火墻作為初始化的入侵防護技術,提供主機層次的訪問控制。其次,它運用過濾引擎,集成簡單的對包的結構化分析、狀態檢測和入侵檢測,以決定是否允許該信息包通過。CyberWallPLUS的過濾引擎主要執行如下一些任務:

 ①包過濾。通過用戶定義的訪問控制規則,決定是否將信息包傳給服務器或工作站。

 ②包檢測。根據協議,評估和驗證每一個包的大小和結構,確保它們同協議關聯的規則具有一致性。

 ③狀態檢測。根據協議,檢測通訊會話中的每一次交換(握手),確保其是預期格式或實時格式。

④簽名機制。根據已知攻擊(如端口掃描)的特征,進行實時的入侵防護。

 ⑤漏洞阻塞。利用所掌握的主機系統(如Windows NT/2000服務器)的弱點知識,通過參數過濾器查看數據包,檢查其是否企圖侵犯系統的薄弱環節。

                   圖2.5  過濾引擎的模塊結構

該產品具有中心管理功能,管理員通過中心管理模塊可對各臺主機實施全方位的控制,包括分發安全策略和遠程配置。該產品也具有較完善的申計功能,審計日志可通過建立的連接、阻塞的數據包、入侵嘗試和應用類型等來建立(可配置選項)。中心管理模塊可對日志和報警信號進行匯集。

2.9小結

 本章主要闡述了DFW的基本原理、本質特征、體系結構和運作機制等基本問題,這是至關重要的,因為只有掌握了本質特征才能把握研究的方向。首先全面地概括了目前傳統防火墻的主要缺陷,分布式防火墻提出的背景;接著闡述了DFW的一系列基本理論問題;最后介紹了目前國外實現的一些原型系統的基本原理。

 

第三章 關鍵技術之一:Winsock 2 SPI與應用層防火墻技術

很多人都熟悉網絡應用程序編程接口Winsock API,但很少有人知道Winsock

SPI。1997年5月,Winsock 2的正式規范版本2.2.1發布,SPI(Service Provider Interface)是Winsock 2 新增的功能,即服務提供者接口,是在Winsock的下方開放給程序員的一個編程接口,從而可以在Winsock的下方插入一層或幾層處理程序,對協議的功能進行擴展,對數據封包進行附加處理,如傳輸質量控制(QoS)、數據加密、封包過濾等,所以SPI是一個功能強大而有用的接口。

3.1 SPI基本原理

SPI在網絡協議結構中所處的位置如圖3.1所示,通常情況下,Ws2_32.dll的下方直接面對的是基礎服務提供者,現在我們可以編寫出符合SPI規范要求的DLL模塊插在Ws2_32.dll和基礎服務提供者之間,讓該模塊實現對封包的處理。這里聽起來好象很神秘,其實上面這句話已經概括出了我們要做的兩件事:編寫出符合SPI規范要求的DLL模塊;插入到Ws2_32.dll和Base Provider之間。前者屬于模塊的編寫,后者屬于模塊的安裝。在詳細闡述如何完成這兩件事情之前,先來析傳輸服務提供者DLL模塊安裝前后的工作機理。

 

                        圖3.1 SPI在網絡協議中的位置

3.1.1 沒有安裝傳輸服務提供者情況下網絡傳輸的執行過程

網絡應用程序(如IE)運行并開始調用Ws2_32.dll,Ws2_32.dll只是一個接

口,它需要調用下層的協議來完成數據傳輸,在Ws2_32.dll的下方有若干個傳輸服務提供者存在,Ws2_32.dll怎么知道要調用哪一個傳輸服務提供者呢?問題的關鍵就在這里。原來在注冊表(Win2K)的HKEY_LOCAL_MACHINESYSTEM

CurrentControlSetServicesWinSock2ParametersProtocol_Catalog9鍵下保存著所有傳輸服務提供者的信息,Ws2_32.dll通過查找注冊表來獲知調用哪個傳輸服務提供者DLL,如圖3-2所示。

               

                圖3.2 安裝前的執行過程

3.1.2 安裝LSP后網絡傳輸的執行過程

再來看一下自己的傳輸服務提供者被安裝后的情況。自己的傳輸服務提供者編譯完成后,將其拷貝到相應的系統目錄(在Win2K中是WINNTSYSTEM32)下,然后必須執行安裝程序對其進行安裝,安裝的過程也就是修改注冊表的過程。安裝程序執行過后,注冊表中相應的鍵值不再指向系統基礎服務提供者,而是指向了自己的服務提供者。所以Ws2_32.dll查閱注冊表后將調用自己的傳輸服務提供者,自己的服務提供者執行完后,再調用下層的服務提供者,完成傳輸任務的中轉。其過程如圖3.3所示。

                  圖3.3 安裝后的執行過程

3.2 SPI傳輸服務提供者安裝程序的編寫方法

Winsock 2 SPI是為Winsock API提供服務的接口程序,由于程序為動態鏈接庫,

不能夠單獨運行,需要按系統提供的接口安裝到系統中,由系統加載才能運行,所以必須編程對SPI程序進行安裝。傳輸服務提供者有兩種形式:基礎服務提供者和分層服務提供者。這兩種形式的安裝方法有所不同,下面分別加以介紹。

3.2.1 基礎服務提供者的安裝程序

基本思路是從注冊表中找到需要替換的系統基礎服務提供者,將其路徑信息替換成自己的服務提供者路徑,并將原來的路徑信息保存到另一注冊表鍵值下。整個執行過程如圖3.4所示:

 

                    圖3.4  基礎服務提供者安裝程序的執行過程

3.2.2 分層服務提供者的安裝程序

需要在服務提供者所在的鍵下增加新的鍵值。其過程如圖3.5所示。讀者請注意,以上只說明了安裝過程,卸載的過程與安裝正好相反,這里不在贅述。

3.3 SPI傳輸服務提供者的編寫方法

上面提到要編寫符合SPI規范要求的模塊,這里所說的SPI規范的含義是指在模塊中要實現的函數名以及函數的參數已被系統確定,它們都是固定的,不能改動,能夠做的是在函數的框架以內編程。因為自定義的函數要被上層的系統模塊

 

圖3.5 分層服務提供者安裝程序的執行過程

Ws2_32.dll或上層的SPI程序調用,所以自定義的函數必須是標準的,即函數名和函數的參數都是標準的。至于函數內部的實現則由設計時的需求來確定。在SPI的規范中有一個入口函數WSPStartup和30個服務函數,關于這些函數的規范(即函數名和函數參數)請參閱有關資料[9]、[28]。實現一個傳輸服務提供者關鍵要實現一個入口函數WSPStartup和若干服務函數。下面分別加以說明。

3.3.1 WSPStartup函數的實現方法

WSPStartup是自己的傳輸服務提供者DLL的導出函數,是必須要實現的一個函數,其功能是將本SPI程序中的服務函數的地址指針傳遞給上層,原型如下所示:

int  WSPAPI  WSPStartup(

 WORD      ersionRequested,

 LPWSPDATA     WSPData,

 LPWSAPROTOCOL_INFOW      lpProtocolInfo,

 WSPUPCALLTABLE        pcallTable,

 LPWSPPROC_TABLE       pProcTable    )

其中理解lpProtocolInfo和pProcTable這兩個參數的含義和作用是理解整個SPI工作機理的關鍵(詳細情況可參閱本文所列的參考資料[28]),前者是導入的結構參數,通過這個參數,可以知道下一層服務提供者的信息,通過這個信息可以將下一層服務提供者裝入內存,并獲取其服務函數的指針,從而在自定義的服務提供者完成任務后可以調用下層服務提供者的服務函數完成數據傳輸。pProcTable是導出的參數,自定義的服務提供者的所有服務函數的指針保存在該結構中,并導出給上層調用者,上層DLL有了該結構就可以直接調用自定義的服務提供者的服務函數。WSPStartup函數的一般實現過程如圖3.6所示:

 

圖3.6 入口函數WSPStartup的實現方法

3.3.2 服務函數的實現方法

 

圖3.7 截獲的服務函數的實現方法

通常需要截獲的服務函數主要有WSPSocket、WSPCloseSocket、WSPConnect、WSPAccept、WSPSend、WSPSendTo、WSPRecv和WSPRecvFrom等,這些函數的編寫通常有一個統一的模式,只是輸出類服務函數(如WSPSend)和輸入類服務函數(如WSPRecv)略有不同。圖3.7以輸出類為例說明截獲的服務函數的編寫方法。

3.3.3 兩種傳輸服務提供者在安裝和實現上的異同點的比較

  表2-1給出了兩種傳輸服務提供者在安裝和DLL實現上的異同。

表2-1  兩種傳輸服務提供者在安裝和實現上的異同點的比較

安裝程序 DLL程序

相同點 不同點 相同點 不同點

都是對注冊表進行操作。 1.安裝的原理不同。對于基礎服務提供者主要是注冊表鍵值的替換,對于分層服務提供者主要是增加注冊表項。

2.使用的函數不同。基礎提供者主要是使用注冊表操作函數,分層提供者主要是使用Sporder.dll提供的安裝函數。 除了獲取下層提供者的方法不同外,其他模式基本相同,包括入口函數WSPStartup和30個服務函數的實現方法都基本相同。 獲取下一層提供者路徑的方法不同。對于基礎服務提供者,利用注冊表操作函數直接讀出安裝時保存在某一鍵下的路徑信息;對于分層服務提供者,需要調用WSCGetProvidePath函數來獲取下一層提供者的路徑信息。

3.4 SPI hook技術在防火墻中的應用

  在SPI接口的30個服務函數中大多數都是直接與API函數相對應的,也就是說當自己編寫的SPI程序安裝到系統后,所有的Winsock請求都會先發送到該程序,應用程序調用Winsock(即Ws2_32.dll)時,Winsock會調用下層傳輸服務提供者相應的函數。例如,當應用程序調用Send(或WSASend)時,Winsock就調用SPI的WSPSend。所以我們只要截獲若干重要的連網函數,我們就可以對網絡應用程序的行為進行控管。由于系統已經提供了完成數據傳輸的SPI,所以我們在自己的SPI中沒有必要在實現這部分功能,我們只要將自己的SPI程序掛接到系統

SPI程序上即可,所以我們稱自己的SPI程序為“鉤子”程序,稱這種技術為“鉤子”技術。

  防火墻要實現對封包的控管,通常需要截獲幾個SPI函數,它們的功能及可截獲的封包信息如表3-2所示:

  用這種方法編寫的防火墻的工作過程如圖3.8所示:

  SPI型防火墻可實現的主要功能是對本機中的應用程序進行控管,包括連出和

   表3-2  應用層防火墻所要截獲的SPI函數、它們的功能及可獲得的封包信息

服務函數 函數功能 可截獲的信息

WSPStartup 入口函數,導入下層DLL的信息,導出本DLL的服務函數指針。 配合DLL的入口函數DllMain可獲得應用程序的完整路徑和名稱

WSPSocket 創建socket,并加入socket組 本地端口、IP,連接的協議類型

WSPCloseSocket 關閉socket連接 可利用該函數做封包信息的最后處理

WSPConnect 建立socket之間的連接 遠端端口、IP

WSPAccept 有條件地接受一個socket連接 遠端端口、IP

WSPSend 通過一個已連接的socket發送數據 發送數據的內容,如網址、收信人地址、FTP文件名等

WSPSendTo 使用重疊I/O操作發送數據 同上

WSPRecv 從一個socket上接收數據 接收數據的內容

WSPRecvFrom 接收一個數據報 同上

                                  

          圖3.8  SPI型防火墻的工作過程

連入的控管。具體說就是本機中的哪些應用程序可在什么時間、利用什么協議、通過什么端口訪問網絡中哪些主機,或接受網絡中的哪些主機的訪問。這樣,就在應用層實現了訪問控制的目的,典型的例子是防木馬攻擊。

 SPI型防火墻的缺陷是不能防范針對低層協議的攻擊,比如它不能阻止ping探測。

3.5小結

Winsock 2 SPI 是一項激動人心的技術,它可以對調用Winsock的網絡封包進

行完全的控管,可以對網絡協議的功能進行擴展,從而可以實現很多特殊的附加功能。本章首先介紹了SPI的基本原理,然后介紹了SPI安裝程序的編寫,接著介紹了SPI傳輸服務提供者的編寫,最后介紹了SPI技術在應用層防火墻開發中的應用。這些技術在DFW模型的實現中至關重要。

第四章 關鍵技術之二:網絡驅動程序與核心層防火墻技術

在應用層開發程序是大家所熟悉的,開發出來的程序后綴名是exe或dll。用戶能在Windows操作系統核心層開發程序嗎?回答是肯定的,這就是驅動程序,后綴名是vxd(在Win95/98/Me下)和sys(在WinNT/2000/XP下)。通過在Windows操作系統核心層開發具有過濾功能的網絡驅動程序可以實現核心層防火墻。

4.1驅動程序的一般原理

4.1.1驅動程序與應用程序的區別

應用程序位于上層,一個應用程序質量的好壞不會影響操作系統的運行,所以對應用層的程序要求較低,授予它的權限也較低。在Windows保護機制的作用下,應用程序受到許多限制。例如,應用程序無法直接操作CPU,不能直接操作其他應用程序的內存緩沖區等。而核心層的驅動程序就不一樣了,驅動程序是用戶可以編寫的、完成一定功能的、可以安裝到系統中的并與操作系統有同等級別權限的程序,驅動程序幾乎可以對所有資源進行直接讀寫操作,包括軟硬件。Windows95/98/me下的驅動程序的擴展名為.vxd,WindowsNT/2000/XP下的驅動程序的擴展名為.sys。

驅動程序有硬件驅動程序和軟件驅動程序之分。所謂硬件驅動程序,也叫設備驅動程序,它是連接硬件和操作系統的紐帶。它一方面對硬件直接進行操作,另一方面提供標準接口供操作系統調用。軟件驅動程序位于設備驅動程序之上,沒有直接操作硬件的動作,它們要在上層驅動程序和下層驅動程序之間做一個中間層,這種軟件驅動程序有著很重要的作用,它們可以提供分層式的服務。過濾驅動程序屬于軟件驅動程序。

4.1.2一個最小的驅動程序

 像DLL必須有入口函數(DllMain)一樣,驅動程序必須有入口函數DriverEntry。任何對驅動程序的調用都必須首先執行DriverEntry函數。對于高層的純軟件驅動程序來說,在DriverEntry函數里最重要的工作就是設置開放給其他驅動程序調用的函數指針。這樣,其他驅動程序就可以直接調用這個驅動程序的功能函數來完成任務。由此可見,驅動程序包括入口函數和功能函數,這與DLL程序是相似的。

下面分析一個最小的驅動程序來了解驅動程序的結構,源程序如下:

#include <ndis.h>

#include "MinDriver.h"

NTSTATUS  DriverEntry(

 IN PDRIVER_OBJECT  DriverObject,

 IN PUNICODE_STRING  RegistryPath  )

{

 DBGPRINT("DriverEntry Loading... ");

 DriverObject->DriverUnload = PacketUnload;

 return(0);

}

VOID  PacketUnload(

 IN PDRIVER_OBJECT  DriverObject  )

{

    PDEVICE_OBJECT     DeviceObject;

    PDEVICE_OBJECT     OldDeviceObject;  

    DBGPRINT("DriverEntry unLoading... ");

DeviceObject    = DriverObject->DeviceObject;

    while (DeviceObject != NULL)

 {

        OldDeviceObject=DeviceObject;

        DeviceObject=DeviceObject->NextDevice;

        IoDeleteDevice(OldDeviceObject);

    }

}

 在調用DriverEntry時,系統傳入兩個參數,一個是指向驅動程序對象的指針,另一個是指向注冊表路徑的指針。語句DriverObject->DriverUnload = PacketUnload指定卸載驅動程序的函數(一個功能函數)的指針。

4.1.3驅動程序的安裝

 驅動程序的安裝方法主要有:導入注冊表配置法(即做一些注冊表的操作);.inf法和.ini法;用程序調用安裝函數來進行安裝。

 驅動程序安裝后要啟動后才能被執行。啟動驅動程序除了可用net命令外,也可用程序調用函數來實現。

4.2網絡驅動程序概述

 網絡驅動程序包括TDI驅動程序和NDIS驅動程序,NDIS驅動程序又包括協議驅動程序、中間驅動程序和微端口驅動程序。

4.2.1什么是TDI驅動程序

 傳輸驅動程序接口(TDI)定義了一個內核模式的接口,它暴露在傳輸協議棧的上邊界。TDI客戶是內核模式的驅動程序,例如Socket仿真器、NetBIOS仿真器、重定向器等,它通過TDI與傳輸層相連接。傳輸驅動程序暴露了只能被TDI客戶方所使用的TDI接口。為了提供更多的對這種傳輸的訪問,Windows 2000為當前流行的網絡接口Windows Socket和NetBIOS提供了仿真器模塊,每個仿真器模塊暴露了它自己的一套函數,它們可以通過用戶模式中的標準調用機制來調用。當調用它們時,仿真器模塊將本地的函數、相關參數以及過程規則映射到TDI函數,然后通過TDI調用指定的傳輸驅動程序,其結構如圖1.4所示。

4.2.2什么是NDIS驅動程序

 首先認識網絡驅動程序接口規范庫(即NDIS庫),它為網絡驅動程序中抽象出網絡硬件,它還在網絡驅動之間指定了標準接口。因此它會從上層驅動程序(例如網絡驅動程序)中抽象出管理硬件的下層驅動程序。NDIS庫還維護著網絡驅動程序的狀態信息和參數,包括指向函數、句柄和用于鏈接的參數塊的指針,以及其他系統值。

 NDIS驅動程序就是根據網絡驅動程序接口規范編寫的驅動程序。NDIS驅動程序有三種類型:微端口驅動程序,中間驅動程序和協議驅動程序,下面簡要敘述它們的功能。

①NDIS微端口驅動程序(也叫微端口NIC驅動程序)有兩個功能:

◆管理一個網絡接口卡(NIC),包括通過NIC發送和接收數據。

◆與高層驅動程序(例如中間驅動程序和傳輸協議驅動程序)建立接口。

微端口驅動程序不是直接操縱網卡,也不是直接與上層驅動程序打交道,而

是通過NDIS庫。NDIS庫提供了一整套的函數(NdisXXX函數),這些函數封裝了微端口需要調用的所有操作系統函數。同時,微端口必須提供一組入口點(MiniportXxx函數),使NDIS可以為了自己的目的或代表高層驅動程序而訪問微端口。

 ②開發中間層協議驅動程序的最初目的是為傳輸驅動程序所無法識別的新介質類型在早期的傳輸驅動程序和NIC微端口之間實現介質轉換。現在利用NDIS中間驅動程序可以在網卡驅動程序和傳輸驅動程序之間插入一層自己的處理,從而可以用來截獲網絡封包并重新進行封包、加密、網絡地址轉換及過濾等操作。由于NDIS中間驅動程序位于網卡和傳輸驅動程序之間,所以它可以截獲較為底層的封包。從而可以完成更為低級的操作,用來編寫網絡安全軟件,安全系數也較高。

 ③NDIS協議驅動程序是NDIS驅動程序的最高層,它實現傳輸層和網絡層協議棧,例如TCP/IP或IPX/SPX棧。傳輸協議驅動程序分配包,從應用程序中將數據拷貝到包中,并且通過調用NDIS函數將這些包發送到低層驅動程序中,協議驅動程序還為從下層驅動程序接收包提供了協議接口。傳輸協議驅動程序將接收到的包傳給相應的客戶應用程序。

4.3幾種核心層過濾驅動程序的實現方法

4.3.1用TDI 鉤子過濾驅動程序實現核心層過濾

⑴什么是IRP(I/O Request Packet)請求

 每個操作系統都有一個隱含的或明確的I/O模型,以處理與外圍設備之間的數據流,I/O管理器提供一致的接口給所有的內核模式驅動程序。所有的對驅動程序的I/O請求被作為I/O請求包(IRP)發送,所以IRP是發給驅動程序的I/O請求包。

⑵入口函數DriverEntry所要完成的功能

 在DriverEntry中要做三方面的事:將功能函數(如卸載函數)的指針賦給結構DriverObject中的相應變量;利用循環語句將驅動程序所有的IRP請求函數指針指向自定義的函數PacketDispatch(稱為派發函數),這樣所有的IRP請求將經過自己的函數PacketDispatch中轉(可在該函數中作過濾處理);調用自定義函數(如TCPFilter_Attach),將此驅動程序掛接到TCP/IP協議驅動程序上。

⑶如何創建自己的一個設備并透明地掛接到TCP設備之上

 自定義函數TCPFilter_Attach完成創建自己的一個設備并透明地掛接到TCP設備之上的任務,在TCPFilter_Attach中主要完成以下幾個步驟的處理:

①調用IoGetDeviceObjectPointer得到系統TCP設備的句柄等相關信息。

②調用IoCreateDevice創建自己的過濾設備。

③調用IoAttachDeviceToDeviceStack將自己的設備掛接到系統TCP設備之上。

④把各個設備的相關信息保存到pTDIH_DeviceExtension結構中。

⑤設置過濾驅動程序的標志位,標記為過濾驅動程序。

⑷有哪些功能函數

 必不可少的功能函數是卸載驅動程序的函數DriverUnload,在DriverEntry里指定的DriverUnload 例程函數為PacketUnload,這個函數執行大致與掛接函數TCPFilter_Attach相反的過程來完成驅動程序的卸載。首先需要解除過濾驅動程序的掛接(使用系統函數IoDetachDevice),然后刪除自己創建的設備(使用系統函數IoDeleteDevice)。

⑸如何截獲IRP請求并做過濾處理

 上面介紹的函數都是關于入口和卸載時的處理函數,它們僅僅在開始或卸載的時候執行一次,正常工作時調用的函數是IRP請求的派發函數,由于在入口函數中將驅動程序所有的IRP請求函數指針都指向了同一個函數PacketDispatch,所以只有這一個派發函數。在派發函數中使用case語句來區分不同IRP請求,我們可對幾個關鍵的IRP請求(如TDI_RECEIVE、TDI_SEND等)實施檢查,符合要求的就將其轉發給底層設備,不符合規則要求的則予以攔截。

4.3.2用NDIS中間驅動程序實現核心層過濾

 NDIS中間驅動程序位于Miniport和Protocol驅動程序之間并同時具有Miniport和Protocol兩種驅動程序接口,分別位于驅動程序的上方和下方。其中位于上面的Miniport接口同上層驅動程序的Protocol接口進行對接,下面的Protocol接口同底層驅動程序的Miniport接口進行對接,這樣中間驅動程序在兩個驅動之間插入一層。如圖4.1所示可形象地說明這一點。由此可見,要實現一個中間驅動程序必須實現兩個完整的接口。

       

圖4.1  NDIS中間驅動程序的結構及所處的位置

需要注意的是,NDIS中間驅動程序的安裝一般是通過網卡連接屬性面板在網卡上添加一個服務。下面闡述NDIS中間驅動程序的一般原理。

⑴ NDIS中間驅動程序的一般架構

同其他驅動程序一樣,NDIS中間驅動程序由入口函數和功能函數組成。中間

驅動程序通過入口函數DriverEntry向NDIS注冊一個Miniport接口和一個

Protocol接口。這兩個接口分別包括一組規定好的標準處理函數,需要分別對這些處理函數進行編碼。NDIS中間過濾驅動程序的一般架構應包括如下幾方面:

① 實現一個入口函數DriverEntry,其主要功能是導出功能函數,實現掛接,

具體包括:注冊MiniportXxx系列功能函數,并開放出為上層傳輸協議驅動提供的接口;注冊ProtocolXxx系列功能函數,并開放出為底層Miniport驅動提供的接口。

②實現MiniportXxx和ProtocolXxx系列功能函數。

③使用Miniport設備實現數據的發送;使用Protocol設備實現數據的接收。

④在PTReceive(自定義)和MPSend(自定義)等功能函數中實現對封包的

過濾。

⑵ NDIS中間驅動程序的入口函數DriverEntry

通常一個NDIS中間驅動程序的DriverEntry入口函數必須包含下面4個處理步驟:

①調用NdisMInitializeWrapper函數注冊miniport設備,得到設備句柄

NdisWrapperHandle。

②利用上一步得到的句柄,調用NdisIMRegisterLayeredMiniport函數,注冊

MiniportXxx系列功能函數,以開放出為上層協議驅動提供的接口。

③調用NdisRegisterProtocol函數,注冊ProtocolXxx系列功能函數以開放出為底層Miniport驅動提供的接口,并將本身綁定到底層驅動程序上。

④調用NdisIMAssociateMiniport函數,以通知NDIS庫這個中間驅動程序的存在,這樣既為底層的MiniportXxx提供了ProtocolXxx接口,又為上層的ProtocolXxx提供了MiniportXxx接口。

通過入口函數DriverEntry的處理后,Miniport和Protocol接口便會直接暴露出來,并和上層的Protocol、底層的Miniport進行結合。

⑶ Miniport設備和Protocol設備的注冊

在入口函數DriverEntry中必須要對Miniport設備和Protocol設備進行注冊,所謂注冊一個設備也就是完成功能函數與系統的掛接,那么注冊是如何完成的呢?將功能函數的指針賦給相應的結構變量(MiniportStruct和ProtocolStruct)的成員,然后分別調用NdisIMRegisterLayeredMiniport函數注冊MiniportXxx系列功能函數以開放出來供其他進程調用,調用NdisRegisterProtocol函數注冊ProtocolXxx系列功能函數以開放出來與底層Miniport驅動相互調用,并將本身保存到底層驅動程序上。

⑷ Miniport和Protocol接口函數(即功能函數)

 Miniport接口函數大約有幾十個,主要包括初始化函數、發送封包函數、狀態相關函數,以及PNP相關函數。與Protocol設備相關的接口函數也有幾十個,主要有綁定到適配器(Miniport)設備函數、接收封包函數、狀態函數,以及PNP函數。

⑸ 發送封包與接收封包的函數

 Miniport設備由于處在中間驅動程序的上方,所以僅重點處理封包的發送任務。Miniport提供的標準發送函數有MiniportSend和MiniportSendPackets,這兩個函數其實是不能并存的。如果在注冊Miniport設備時使用了MiniportSend,則每次只能處理一個數據封包。如果使用了MiniportSendPackets函數,則MiniportSend自動無效,停止使用。使用MiniportSendPackets可以用來發送一組數據封包。除此之外,Miniport還負責將Protocol接收的數據通過MiniportTransferData函數傳遞給上層的驅動程序。

 Protocol設備由于處在中間驅動程序的下方,所以重點處理封包的接收。Miniport提供的標準接收函數有ProtocolReceive和ProtocolReceivePacket。Protocol設備主要利用這兩個函數來完成數據封包的接收操作。

⑹ NDIS中間驅動程序如何實現封包過濾

 由上面的敘述可知,過往中間驅動程序的封包要經過MiniportSend和ProtocolReceive兩個函數的處理,所以可以在這兩個函數中對封包進行分析得出相關數據,如IP地址、端口號、TCP標志位等,將這些數據與控管規則進行比對以確定是放行還是拒絕。

4.3.3用NDIS鉤子驅動程序實現核心層過濾

用上面的NDIS中間驅動程序強大而有效,但實現難度較大,而用NDIS鉤子過濾驅動程序實現較為容易一些且可以達到同樣的效果。NDIS HOOK技術類似于SPI HOOK技術(即SPI基礎服務提供者),它是直接擴充系統接口函數的功能,通過安裝函數安裝后,所增加的代碼在執行的時候被掛接到相應的系統函數之上,所以形象地稱之為“鉤子技術”。圖4.3表示了“鉤子程序”(即圖中的NDIS HOOK)安裝前后的示意圖。鉤子程序執行封包過濾功能。

NDIS-HOOK 安裝前后的結構如圖4.2和4.3所示:

        

圖4.2  NDIS-HOOK 安裝前的結構示意圖        圖4.3  NDIS-HOOK 安裝后的結構示意圖    

4.4實現NDIS鉤子過濾驅動程序的關鍵問題

 由于NDIS鉤子過濾驅動程序是實現核心層防火墻的最方便實用的方法,所以這里對實現NDIS鉤子過濾驅動程序的關鍵問題進行進一步深入的討論。

4.4.1 DriverEntry入口函數的功能

 系統在啟動時會根據注冊表的配置先后加載Ndis.sys和xpacket.sys(假想的NDIS鉤子過濾驅動程序),接著系統會執行xpacket.sys的入口函數DriverEntry,其中一項重要的事情是將xpacket.sys中的過濾函數掛接到Ndis.sys中相應的系統函數上。此時,當網絡應用程序與外部通信時過往的封包就必須經過自定義的被掛接的函數,從而實現對封包的過濾。

4.4.2 NDIS系統功能函數是如何實現HOOK(掛接)的

 需要HOOK的三個系統函數是NdisSend、NdisRegisterProtocol和NdisOpenAdapter。

因為需要完成對 ProtocolSend 和 ProtocolReceive 函數的hook,由于ProtocolRecvive是在調用RegisterProtocol時注冊的,所以需要對NdisRegisterProtocol函數的hook。Windows 2000 與 Windows 9x 的NDIS處理模式有所不同,Win9x發送封包都是通過NdisSend,而 Windows 2000 則是通過Protocol的SendHandler,所以要完成對TCP/IP的過濾,只需要截獲Tcp/Ip的ProtocolSend 和 ProtocolReceive,這兩個函數可以通過NdisRegisterProtocol得到。掛接NdisOpenAdapter的目的是將協議驅動程序與網卡綁定。

在掛接之前需要知道Ndis.sys在內存中的基地址(通過調用系統函數得到)、需要掛接的系統函數的名稱、自己的函數的地址等。然后在Ndis.sys所在的內存地址空間中尋找保存所要的系統函數地址的地址,然后用我們自己的函數的地址替換該地址中原來的地址值,并將原來的系統函數地址保存到另一變量中。原先地址空間中的地址直接指向NdisSend函數,被替換后首先指向被掛接的自定義的過濾函數,執行完后再執行NdisSend函數。其過程如圖4.4所示。

 

圖4.4  自定義的過濾函數被掛接前后的執行流程

4.4.3 IP、TCP、UDP、ICMP包頭是如何被解析的

 由于包頭字段封裝在各自的結構中,如IP包頭封裝在PIP_HEADER結構中,TCP包頭封裝在PTCP_HEADER結構中,所以獲得封包緩沖區地址也就是獲得了各個結構變量在內存中的地址,因而包頭中的各個字段可通過讀取結構變量中的各分量的辦法方便地讀出。解析的大致過程如圖4.5所示。

 

圖4.5  協議包頭字段的解析

4.4.4 控管規則比對是如何被完成的

 取出在包頭解析中得到的相關包頭字段信息,如端口、IP地址、網上鄰居的名字等,將其與控管規則比對,以作出放行和丟棄的管制動作。

4.5 NDIS-HOOK與SPI-HOOK關鍵技術點的比較

 NDIS-HOOK和SPI-HOOK分別是實現核心層和應用層防火墻的關鍵技術,它們在原理上是相同的,都是在現有系統接口函數(或庫函數)原有功能基礎上掛接一段自編的代碼,以實現過濾功能。但在具體細節上也有一些差異,表4-1概括地說明了兩種鉤子技術的異同。

4.6小結

 本章首先簡要介紹了驅動程序的開發方法,然后著重探討了幾種核心層過濾驅動程序開發的主要思路,這幾種驅動程序是:TDI鉤子過濾驅動程序、NDIS中間過濾驅動程序和NDIS鉤子過濾驅動程序。其中NDIS鉤子過濾驅動程序是最實用的一種開發方法,因為它的實現和安裝相對來說較為簡單一些,而功能卻很強大。

表4-1 NDIS-HOOK與SPI-HOOK關鍵技術點的比較

 NDIS-HOOK SPI-HOOK

磁盤文件的位置 C:WinNTSystem32上的DLL文件 C:WinNTSystem32或安裝程序所在的目錄,SYS文件

裝入內存的方式 系統啟動時將鉤子SYS模塊裝入內存 界面程序運行時將過濾模塊DLL裝入內存

實現掛接的方式 執行安裝程序時通過注冊表修改實現掛接。 系統啟動當執行本模塊的入口函數時,通過修改NDIS庫函數在內存中的地址實現掛接。

初始化的方式 通過執行WSPStartup函數將自定義的服務函數開放給上層調用。 通過執行DriverEntry函數將自定義的鉤子函數的地址提交給系統。

截獲的主要服務函數 WSPStartup、 WSPSocket、WSPRecv 、 WSPCloseSocket、WSPRecvFrom、WSPSend 、WSPSendTo 、WSPConnect 、WSPAccept NdisRegisterProtocol、NdisOpenAdapter、NdisSend

可獲取的封包信息 源和目的IP和端口、應用程序名、所使用的協議、傳送包的時間、包的傳送方向、包中的內容信息。 TCP/IP包頭各字段(參見附錄三)

與界面程序通信的方式 SYS模塊被裝載到內存后界面程序保存其接口函數的指針,通過接口函數向SYS模塊發出指令或請求;SYS模塊保存著界面程序的框架窗口的句柄,利用該句柄向界面程序發Windows消息,以通知界面程序發生的事件。 與NDIS-HOOK相同。

模塊的安裝方法 將編寫的注冊表文件導入注冊表 執行安裝程序,修改注冊表。

 

第五章 DFW模型的設計與實現

 本章基于對DFW基本原理和運作機制等基本理論問題充分認識以及對關鍵技術深入研究的基礎上對DFW的模型進行設計與實現。該模型實現了DFW的兩大本質特征,即在中心策略服務器(即控管中心)一端可以進行安全規則配置與分發,日志的收集和查詢等功能;在主機防火墻一端可以在啟動防火墻時主動索取規則,當有數據包進出網絡時過濾引擎實施檢查并產生日志,當一條日志記錄形成時被實時傳送到控管中心保存,控管中心與主機防火墻之間采用C/S模式通信。本系統是用VC++在Windows平臺實現的。本章將深入介紹系統的實現方法。

5.1 DFW模型的設計

 搞清楚了DFW的原理后,容易設計一個僅實現DFW本質功能的DFW原型系統(模型)。考慮到Windows是目前最流行的平臺,所以本方案基于Windows平臺設計。模型的模塊結構如圖5.1所示。下面通過介紹系統的工作過程來說明各模塊的功能。

①中心策略服務器(控管中心)啟動工作,管理員通過圖形用戶接口配置規則并存入中心策略數據庫。控管中心的通信模塊(服務器)開始監聽網絡連接。

②受保護主機啟動,主機防火墻啟動,過濾模塊因為沒有規則而封鎖套接字,阻塞內外通信。

③當有本機用戶(桌面機)啟動網絡應用程序或外部主機請求服務(服務器)時,過濾模塊會向控制模塊發送一個消息,控制模塊判斷后知道有應用程序要求連網,首先它會彈出一個對話框要求輸入用戶名和密碼。

④用戶輸入完畢并OK后,控制模塊會調用通信模塊將用戶名和密碼信息發送給控制中心,控制中心查詢數據庫,判斷用戶的合法性。

⑤如果用戶認證通過,控管中心的控制模塊會取出該主機的安全策略,并傳送給主機端。主機端控制模塊調用過濾模塊的接口函數將規則寫入緩沖區。若沒有通過認證,則返回一個用戶非法的消息。

⑥過濾模塊開始檢查封包,符合規則的封包被放行,不符合的被丟棄。同時采集日志數據放入本地日志數據庫,并調用通信模塊將日志記錄傳送給控管中心。

⑦本地用戶可通過主機端用戶接口查詢本地日志數據庫,系統管理員可通過控管中心的用戶接口查詢整個系統的日志。

 

圖5.1  DFW模型的設計方案

該模型涉及的主要技術有網絡編程技術、數據庫技術、Winsock 2 SPI技術等。上述技術的具體情況請參閱第一章和第三章。

模型只實現了DFW的本質功能,即策略的分發與日志的收集。雖然該模型功能還不強大,但該方案的設計具有重要意義,它的作用在于為設計實現復雜的功能強大的DFW提供了一個入口和參照。

5.2 模型實現的總體類結構及其功能

 DFW模型雖然只實現了基本功能,但螞蟻雖小,五臟具全,該模型有完善的服務端和主機端界面,有完善的應用層主機防火墻系統,有功能較強的網絡通信模塊和數據庫模塊等,整個系統有50多個VC++類,約7000行代碼,可執行程序(控管中心與主機防火墻)的總大小約3M多。下面對系統進行分析。

5.2.1 模塊工作的層次圖

 模型實現中總共有三大模塊,各模塊工作的層次如圖5.2所示。DFWserver.exe是控管中心的工作模塊,界面程序DFWclient.exe工作于主機端應用層,完成與用戶的交互,它再跟過濾模塊DFWclient.dll進行交互,圖中的箭頭表示兩大模塊之間的交互。如何實現交互是問題的關鍵之一,后面將要介紹兩大模塊是怎樣交互的。

      

  圖5.2  DFW模型各模塊工作的層次

5.2.2 總體類結構及其功能

 整個系統有著錯綜復雜的類關系,圖5.3給出了類之間的主要關系。

 下面還是以系統的啟動運行過程來說明類之間的關系。

 控管中心啟動運行,管理員通過圖形界面(視圖類)制訂規則并存入數據庫,文檔類(相當于模型設計中的通信模塊)作為C/S通信模式中的服務器啟動并處于守侯狀態。

 然后,主機端防火墻啟動運行。DFWclient.exe啟動時CProperty類中的InitInstance()函數首先執行,完成一系列初始化工作,包括將框架窗口的句柄傳送給DLL模塊保存起來,將過濾程序DLL模塊加載到內存并取得DLL接口函數fIoControl()的指針,接著人工啟動過濾引擎,安裝程序被執行,完成注冊表修改,此時防火墻鉤子已被掛接到系統中。當網絡應用程序(如IE、Outlook Express等)啟動運行時,過濾模塊(即截獲的8個服務函數)截獲封包,再交給CProtocolInfo類進行協議解析,最后執行CCheckAcl類將獲得的有關封包信息與控管規則進行比對,但發現規則緩沖區中還沒有規則,CCheckAcl類將自己掛起并發一條消息

 

                   圖5.3  DFW總體類結構框圖

給CMainFrame類,說“我還沒有得到控管規則”。CMainFrame類隨即彈出一個對話框要求對用戶進行認證。當用戶信息輸入完畢后,CMainFrame類調用通信類(相當于模型設計中的通信模塊)的網絡通信函數向控管中心發出報告。控管中心接到報告后對該用戶的身份進行驗證,如果合法,則將該用戶的規則發送給主機防火墻。如果不合法,則返回一個非法用戶的消息。當主機防火墻的通信類獲得規則后,它會調用DLL的接口函數取走規則并保存到規則緩沖區中。此時CCheckAcl類中的管制函數即可從掛起的地方重新運行。當一個封包處理完后,一條日志記錄已形成,CCheckAcl類會向界面程序中的框架類發Windows消息,通知CMainFrame類取走日志。CMainFrame類得到該條日志后,一方面把它會交給屬性頁類在界面中顯示,另一方面調用文件處理類的函數將其寫入本地日志文件中。同時它調用通信類的函數將其發送給控管中心,控管中心的文檔類獲得日志后將其寫入日志數據庫。到此已完成一條日志的收集,后面將重復上面日志的收集過程。

5.3 控管中心DFWserver.exe的功能

控管中心的主要功能是制定規則、保存日志,使管理員能對全網進行監控,圖5.4是控管中心的界面圖(圖中顯示的是封包實時監視界面)。該模塊用到較多的VC編程技術,以及網絡編程和數據庫編程等技術。在本系統中用到的網絡編程和數據庫編程的基本原理已在第一章中闡述,VC編程不在本文討論范圍內。

 

      5.4  DFW模型實現中控管中心的界面

 控管中心在系統中首先啟動,管理員先建立各種安全域,一個安全域代表具有相同安全特性的用戶的集合,因而一個安全域代表一個規則集,不同的安全域有不同的規則集。然后往域中添加用戶,設置每個用戶的用戶名和密碼等信息。上面這些信息各自對應數據庫中的一個表,管理員可以通過界面對各個表進行增、刪、改等操作。界面如圖5.5所示。

 

          圖5.5  域管理界面

 接著管理員針對每個域(或組)制定規則,規則是針對每一個應用程序制定的,也就是說,應用層的防火墻是針對每一個網絡應用程序來進行控管的。規則的項(也就是對應用程序實施哪些方面的控管)主要有:應用程序名、遠端網絡(可與什么樣的遠端網絡建立連接)、訪問時間(可在什么時間訪問網絡)、管制動作(是放行還是拒絕)、進出方向(是對進入進行控制還是對出去進行控制)、服務類型(該程序可使用哪個協議訪問網絡)、服務端口(該應用程序可使用哪個端口進行通信、備注(附加說明)。控管規則設置界面如圖5.6所示。

 

圖5.6  控管規則設置界面

模型實現支持幾種日志查詢方式:按時間段進行查詢(可設置)、按用戶進行查詢、按管制動作(放行或拒絕)查詢、按應用程序所使用的協議進行查詢。圖5.7是日志查詢設置的界面。

 

圖5.7  日志查詢設置界面

系統啟動后,在文檔類中實例化一個監聽Socket類對象,開始監聽主機防火墻的連接請求。如果有用戶的連接請求到來,則首先查閱數據庫,判斷用戶的合法性。若合法則接受連接,并為其實例化一個連接套接字,然后通過該套接字將用戶規則傳送給該用戶,隨后也通過該套接字接收該用戶的日志信息。日志信息在封包監視界面上實時顯示出來,同時被保存到數據庫的日志表中。若用戶非法,則拒絕連接并反饋拒絕消息。

 以上概述了控管中心的主要功能。

5.4 主機防火墻界面模塊DFWclient.exe的功能分析與實現機制

 界面程序DFWclient.exe是人機交互的圖形化界面,用戶通過它監視封包、查詢日志和進行其他的輔助設置,如圖5.8所示。

 

圖5.8  主機防火墻界面

 其封包監視界面如圖5.9所示。

 

5.9  日志查詢界面

5.4.1 DFWclient.exe的功能分析

 主機防火墻界面實現是基于屬性頁(非文檔-視圖結構),表5-1給出了主要類的功能描述。

程序的啟動是在CPropertyApp類InitInstance()中完成的,首先要獲取dll程序文件在磁盤上的路徑,然后根據該路徑用API函數LoadLibrary將dll程序加載到內存,再根據返回的dll模塊的句柄獲得其控制函數XfIoControl的指針,

接著通過調用控制函數將主框架窗口的句柄傳送給dll模塊。

表5-1  界面程序中各主要類的功能

類名稱 功能描述

CPropertyApp 完成啟動時的初始化工作和程序退出時的收尾工作

CMainFrame 隱藏的主窗口接收dll程序發送的消息和系統托盤上圖標消息,并作出處理

ClocalAgent等 完成與控管中心的通信

CXLogFile等 對日志文件和控管規則文件進行讀、寫等操作

屬性頁與對話框 完成與用戶的交互

安裝程序 修改注冊表,使自己的dll模塊可以截獲連網動作和網絡封包

5.4.2 DFWclient.exe啟動時索取規則以及工作時傳送日志的機理

 當網絡應用程序(如IE)啟動時,程序開始運行。在第一次控管規則比對時由于沒有控管規則,于是彈出認證對話框,與控管中心建立聯系以索取規則,策略服務器認證通過后,將控管規則傳送給主機端。

 當一條日志記錄形成時,dll模塊根據界面程序框架窗口的句柄向它發送一條消息,框架窗口接到消息后,通過XfIoControl函數取得記錄的指針,然后將這條記錄發送給控管中心保存起來,同時也保存到本機的日志文件中。

5.4.3 DFWclient.exe與DFWclient.dll之間的交互

 二者的交互是通過界面的框架類和dll的XfIoControl函數來完成的。界面在啟動的時候將框架窗口的句柄傳給dll保存,同時在裝載dll時取得它的XfIoControl函數的指針并保存起來。Dll是用消息與界面聯系的,而界面是通過函數調用來與dll通信的。

5.5 主機防火墻過濾模塊DFWclient.dll的結構和功能實現

 DFWclient.dll是主機防火墻的核心部件,關鍵技術是SPI技術。其中封包信息的分析提取和控管規則比對的原理是關鍵。

5.5.1 DFWclient.dll模塊的執行流程

 DFWclient.dll模塊的執行流程和整體框架結構如圖5.8所示,DFWclient.dll實現了一個SPI傳輸服務提供者,一個SPI傳輸服務提供者的執行流程如圖左邊從開始到結束的部分,這里僅截獲了30個SPI服務函數中的9個。在9個服務函數中除了WSPStartup()外,在執行流程中每執行一個服務函數都要調用相應的檢查函數獲取相應的封包信息,并調用控管規則比對函數對封包信息實施檢查,并將判斷結果(放行或拒絕)返回給服務函數,服務函數以此決定是丟棄包還是繼續往下執行。

             圖5.10  DFWclient.dll模塊的執行流程

5.5.2 控管規則的比對過程

 關鍵函數——控管規則比對函數GetAccessFromAcl()的執行流程如圖5.4所示。該函數的功能是用網絡封包記錄和控管規則進行比對,得到對封包的管制動作。這個函數進行一些預判斷,若數據不完整則直接放行,目的地址若為本機或應用程序為超級進程則直接放行,否則利用控管規則繼續判斷。可以設想在規則緩沖區中有50條規則,則每一次控管規則比對都要遍歷規則緩沖區,當找到一條

 

圖5.11  控管規則比對函數GetAccessFromAcl()的執行流程

與該封包記錄完全匹配的規則時,則停止遍歷,根據這條規則的Action作出放行或拒絕的判斷,Action為pass,則返回pass;Action為deny,則返回deny。如果遍歷到頭在規則緩沖區中沒有該進程的規則,則主機防火墻會向控管中心發出詢問。如果遍歷到頭沒有發現完全匹配(即方向、協議、端口、時間、目的IP中有一個不符)的規則,但有匹配的進程名,這時也根據Action作出判斷,Action為pass,則返回deny;Action為deny,則返回pass。

5.5.3 封包內容的分析提取

 這里所要分析提取的封包內容包括HTTP協議的網站域名、FTP協議上傳和下載的文件名、SMTP和POP3協議的收發信人地址、用戶名和密碼。這些信息按協議格式包含在發送和接收的數據封包中。

 在HTTP封包中,某次連接的網站域名包含在“Host”關鍵字之后到回車換行符之間,利用這個規律可以從封包結構中把域名信息分離出來。

 在利用FTP進行文件傳輸時必須首先登錄FTP服務器,在登錄FTP服務器時需要用戶認證,在FTP協議中“USER”和“PASS”關鍵字就是分別標志登錄服務器的用戶名和密碼。“PETR” 是標志下載文件名的關鍵字,“STOR”是表示上傳文件名的關鍵字。利用這些關鍵字就可以分離出需要的信息。

 在SMTP協議中,“MAIL FROM:”和“RCPT TO:”關鍵字分別標志發件人和收件人地址。

 在POP3協議中,“USER”和“PASS”關鍵字分別標志用戶名和密碼,郵件內容里的“From:”和“To:”關鍵字分別標志發/收件人的地址。

 由以上可知,從數據包中分析需要的內容的關鍵就是過濾出關鍵字。程序的執行流程是:首先根據數據封包的結構來判斷是發送還是接收;再根據session中保存的協議類型來判斷該調用哪個處理函數;最后調用相應協議的信息提取函數獲得所需的信息。信息提取函數的機制就是根據關鍵字過濾出所要的信息。

5.5.4 日志記錄的形成過程

 對封包進行分析,獲取其相關信息并封裝在一個結構中,這就是session結構,圖5.5說明了該結構各個成員是在哪個步驟(參看圖5.10)中被填入的。

 

圖5.12  session結構各個成員變量在哪個步驟中被填入

5.6 DFW模型已完成的功能和存在的缺陷

 DFW模型已經實現了分布式防火墻的基本功能,即它能夠進行控管規則(安全策略)的制定與分發,進行日志的產生與收集;主機防火墻(作為應用層)已經比較完備;整個模型系統的界面已比較完善。

 就完成基本功能來說,DFW模型還存在一些缺陷:策略的制定機制還不健全;日志的收集機制還未優化,比較單調;健壯性還不強。

5.7小結

 DFW模型實現了分布式防火墻的本質特征所要求的功能,具備了DFW的雛形,但還不夠實用。要達到實用程度,還要在性能和可靠性上進一步作改進。

 

第六章 DFW模型的改進

6.1運用應用層+核心層雙層過濾增強系統的可靠性

6.1.1 雙層過濾的益處

 應該說應用層過濾和核心層過濾都有各自的優點和缺點,應用層可針對具體的應用程序進行控管,但對不調用Winsock的應用程序(如網上鄰居)無法控管,也不能阻止ping探測等攻擊;而核心層過濾可截獲底層數據包,不容易被繞過,但不便對具體的應用程序實施控管。由此可見,將二者結合起來可對數據包實施更有效的控管。

6.1.2 雙層過濾防火墻的模塊設計

 圖中有三大模塊,分別是exe模塊、dll模塊和sys模塊,三大模塊相互之間是通過接口程序進行通信的。SPI鉤子是dll模塊的組成部分,調用Socket的應用程序經過它過濾。NDIS鉤子是sys模塊的組成部分,通過 NDIS 進行網絡通信的應用程序、DLL和驅動程序都將通過它進行過濾。

 

        圖6.1  雙層過濾防火墻的模塊設計

6.1.3 雙層過濾防火墻的實現

 應用層防火墻可參閱第五章,核心層可參閱第四章,這里著重分析一下核心模塊是怎樣與exe模塊和dll模塊進行通信的。界面程序在啟動時通過某種辦法獲得sys模塊在內存中的地址,然后獲得它的接口函數的指針,通過該指針調用其接口函數來向它發指令或請求;與此同時將自身框架窗口的句柄傳送給它,sys模塊通過該句柄向界面程序發消息。這同exe模塊和sys模塊之間的通信方式是類似的。

6.2運用agent技術改造DFW模型

6.2.1在分布式防火墻中使用agent技術必要性的探討

⑴ DFW模型的一個缺陷

 在DFW模型中日志的傳送是這樣的,在主機防火墻中每當產生一條日志記錄的時候就將其傳送給控管中心,由控管中心統一保存日志并被管理員查閱,這種方法在如今的客戶機/服務器架構的網絡環境下已經無法有效地工作。因為當網絡規模較大時,這些日志信息的傳送將會消耗大量的網絡帶寬,而這些數據中絕大多數與入侵無關。

⑵ agent(或移動agent)技術的適用領域

 agent技術的適用領域:與用戶有靈活的相互作用;海量分布式信息檢索;在高度動態環境下能對多變的環境作出響應或自適應;要求應用程序能自主處理失效或沖突;要求能保證適宜的反映和應答時間;在不完全信息下的復雜或分散的資源分配問題等。

 移動agent技術的適用領域:能很好地解決諸如數據、控制、專家知識或資源分布問題,使大量的數據處理可在數據源處進行,只需交換少量的高層信息,就可以減少大量原始數據傳送到遠地的操作,提高了網絡的利用率。

⑶ 在DFW中使用agent(或移動agent)技術所能帶來的益處

 可以帶來如下一些益處:減少不重要日志的傳送,節約網絡帶寬;對異常情況(如發生黑客攻擊)能自主地作出反應(如發出報警或自動關閉機器);對安全策略進行自學習;當防火墻失效時能自主地作出處理等。

 由于移動agent具有降低網絡負載、克服網絡延遲、異步和自主執行功能、動態適應環境、健壯性和容錯性等優點而受到廣泛關注,所以下面重點討論移動agent技術。

6.2.2 移動agent技術探討

 移動agent系統由移動agent和移動agent服務設施兩部分組成。移動agent服務設施基于agent傳輸協議實現agent在主機間的轉移,并為其分配執行環境和服務接口。Agent在服務設施中執行通過agent通信語言ACL相互通信并訪問服務設施提供的服務。移動agent系統結構如圖6.2所示,體系結構的最外層為安

 

圖6.2 移動agent的結構模塊

全代理,它是agent與外界環境通信的中介,執行agent的安全策略,阻止外界環境對agent的非法訪問;agent通過環境交互模塊感知外部環境并作用于外部環境;任務求解模塊是針對具體問題的程序代碼;知識庫是agent所感知的世界和自身模型,并保存在移動過程中獲取的知識和任務求解結構;內部狀態集是agent執行過程中的當前狀態,它影響agent的任務求解過程,同時agent的任務求解又作用于內部狀態;約束條件是agent創建者為保證agent的行為和性能而作出的約束;路由策略決定agent的移動路徑,路由策略可能是靜態的服務列表(適用于簡單、明確的任務求解過程),或者是基于規則的動態路由以滿足復雜和非確定性任務的求解。

6.2.3 基于agent分布式防火墻的設計

 圖6.3給出了基于agent的分布式防火墻的設計方案。

 

圖6.3  基于agent分布式防火墻的設計方案

⑴基于agent的分布式防火墻的主要部件

這種新的基于移動agent的分布式防火墻由下面一些部件組成:

①總agent。總agent是整個系統的大腦和指揮部,它負責管理各主機防火墻中的本地代理,在某主機發生異常時向該主機派遣跟蹤agent,并匯集各個信息收集agent收集到的各種信息,存入中心日志數據庫,必要時發出報警。

②監控器。監控器出現在每一個主機防火墻中,它通過監視本地日志數據庫來發現異常,如果發現了異常,它將報告本地agent,本地agent再報告總agent。

③跟蹤agent。當總agent獲知某主機發生了入侵時,它就向該主機派遣一個跟蹤agent,跟蹤agent到達該主機后首先激活信息收集agent,然后智能地進行入侵路由跟蹤。它可以在安裝了agent執行環境的任何主機之間進行遷移。

④信息采集agent 。當有異常發生時并被跟蹤agent激活后開始采集數據,采集的數據包括日志信息以及所發生的異常的類型等信息。

⑤本地agent。負責向總agent報告異常情況,并在適當的時候向總agent索要本機的安全策略。

⑥日志和策略數據庫。保存日志信息和安全策略。

⑵基于agent的分布式防火墻的工作流程

 從監控器檢測到目標系統(主機防火墻)上的異常,直到總agent開始保存數據并發出報警,其工作流程如下:

①目標系統上的每個監控器從本地日志數據庫中尋找異常。

②如果監控器檢測到異常,就向本地agent報告,本地agent再向總agent報告。

③總agent得到報告后就向該目標系統派遣一個跟蹤agent。

④跟蹤agent到達目標系統后激活一個駐留在該系統中的信息收集agent。

⑤信息收集agent收集目標系統上與異常相關的信息。

⑥在激活信息收集agent之后,跟蹤agent調查異常發生的起始點以及黑客的去向。所有受攻擊主機上的跟蹤agent可以進行會合和聯防。

⑦在收集到信息以后,信息收集agent將獨立于跟蹤agent,向總agent返回報告。

⑧跟蹤agent轉移到跟蹤路由上的另一個目標系統中,并且激活一個新的信息收集agent,

⑨如果跟蹤agent到達入侵路由的起點,或者不能再轉移到別的任何其他地方,或者如果其他的跟蹤agent已經到達了它將要到達的路由,那么它將返回到總agent。

⑩總agent根據所掌握的信息,作出判斷并生成報告,該報告被保存到中心日志數據庫中待管理員查詢,如果是嚴重的入侵則發出報警。

6.3運用智能日志處理增強系統的智能性

6.3.1為什么要對日志進行處理

在黑客的攻擊與反攻擊的斗爭中是人與人的對抗,而不是防火墻與黑客的對抗,因為防火墻一旦安裝即一成不變,而黑客是具有智能的人,任何一種防火墻都不能聲稱可防范所有的攻擊,所以防火墻需要管理員來維護。如果沒有充足的日志信息,整個防火墻對于管理員來說就像是一個神秘的黑匣子,不知到其中發生了什么。設計良好的日志系統能準確地反映系統運行的狀態,系統中發生了什么,使管理員變得耳聰目明。DFW系統也是如此。在DFW系統中,一個性能良好的對管理員友好的日志系統是整個防火墻系統性能的重要組成部分。在分布式防火墻中每臺機器都產生大量的日志,再將它們匯集到控管中心數據庫中,數據量將會非常龐大,如果采用人工檢索將會非常困難。所以有必要對日志進行處理,提取有用信息,并使其具有入侵檢測、報警和非常事件處理等功能。

6.3.2 DFW系統中日志處理的一般過程

本日志處理系統的主要目標是對從各臺主機中收集到的日志數據進行歸納整理,以十分清晰的方式展現給管理員,并利用數據挖掘技術從大量凌亂的數據中提取重要信息如具有攻擊性行為的信息,向管理員報警。

 

圖6.4 日志處理系統結構圖

具體設計方案如圖6.4所示,日志采集模塊根據設定的參數標準采集相應的日志數據并放入本地日志數據庫,控制模塊定期讀取本地日志數據庫,然后加密后傳送給控管中心的控制模塊,解密后將其放入原始數據庫;后臺分析模塊對原始數據庫中的日志數據進行分析、加工和處理,重構出屬于各臺主機的日志信息,并與知識庫中的知識進行比較,知識庫中包含了諸如什么樣的行為是攻擊行為等知識,如具有攻擊行為則向管理員報警,否則直接寫入生成數據庫供管理員查詢。                       

6.4運用加密技術增強系統自身的安全性

6.4.1 DFW系統中為什么要進行身份認證 

認證是驗證通信對象是聲稱的那位而不是冒名頂替者的技術。DFW運行在復雜的網絡環境下,不僅穿越內部網還可能穿越因特網,主機與策略服務器之間的信息傳遞有可能被黑客劫持利用,因而防火墻自身安全至關重要,雖然加密認證不是DFW的本質特征,但只有使用加密認證才能從根本上擺脫拓撲依賴性而保持自身安全,所以加密認證是DFW系統中的重要組成部分。到目前為止,人們提出許多認證協議。其中最常用的一種認證協議是Kerberos。

6.4.2 kerberos基本原理

 kerberos采用對稱密碼體制,即共享私鑰密碼體制。它建立在可信第三方(即認證中心)的基礎上。需要認證的主體包括客戶和服務器,統稱為Principal。Principal預先在認證中心登記,并由認證中心分發一個密鑰,該密鑰只為認證中心和該Principal所擁有。認證的基本依據是:只有擁有密鑰的人才能解密,能解密的人必定是擁有密鑰的人。其認證過程如圖5所示。

 

1 c,tgs

  c表示client,tgs表示TGS

2 (Kc,tgs,(Tc,tgs)Ktgs)Kc

   Kc,tgs表示c與tgs的會話密鑰,Tc,tgs表示c向tgs證明身份的票據。

   Tc,tgs={tgs,c,addr,timestamp,life,Kc,tgs}Ktgs  addr表示c的地址,timestamp表示時間戳,life表示該票據的生命期,Ktgs表示tgs的私有密鑰,Kc表示c的私有密鑰。

3 s,(Tc,tgs)Ktgs,(Ac)Kc,tgs

  s表示server,Ac表示C發向tgs的Authenticator,Ac={c,addr,timestamp}Ks,c

4 (Tc,s)Ks,(Kc,s)Kc,tgs

  Tc,s與Kc,s跟上面的類似

5 (Ac)Kc,s ,(Tc,s)Ks

6 (timestamp+1)Kc,s

圖6.5   Client和Server相互證明身份的過程

 認證過程共有六步,每一步所傳送的信息如圖5所示。認證的大致思路是這樣的:客戶想得到服務器的服務,因而它要向服務器證明它的身份,客戶將自己的名字和服務器的名字用明文傳送給認證中心,認證中心查詢數據庫,找出二者的私有密鑰,然后生成客戶訪問服務器的票據和會話密鑰,再用客戶的私有密鑰將其加密后傳送給客戶。客戶用自己的私有密鑰解密,取出向服務器證明身份的票據和會話密鑰等信息,然后將它們發送給服務器,服務器檢查票據,發現其中的信息可以用自己的私有密鑰解密,因而可以知道該客戶已向認證中心驗證過身份,再加上時間戳等信息可以判斷該客戶就是聲稱的那位而不是冒名頂替者。如果服務器也需要向客戶驗證身份,則服務器再回送一個驗證信息即用會話密鑰加密的時間戳加1的信息,客戶椐此判斷服務器是否為冒名頂替者。當客戶和服務器相互驗證身份后,它們之間就可以通過從認證中心得到的臨時會話密鑰進行加密通信。詳細的認證過程請參見有關資料[3]。

 Kerberos協議的缺陷是客戶與服務器之間的會話密鑰是有時間限制的,超過了時間密鑰就會無效,對某些需要長時間工作的應用程序來說可能會造成不良影響。

6.4.3 kerberos認證協議在本系統中的應用

本系統擬采用kerberos認證方案,主機與策略服務器之間要求相互認證身份,以保證在它們之間傳遞信息的可靠性。在本系統中,本地代理相當于Client,總代理相當于Server。其結構如圖6所示,其工作過程跟上面一致。

  

                                 圖6.6  DFW中加密認證系統結構圖

6.5其他功能的展望

本系統有待進一步完善的地方還有如下幾方面:增加邊界防火墻組件以完善DFW的系統結構;利用跨平臺技術以擴大系統的應用范圍;自適應策略優化配置以減小管理員配置規則的復雜度;策略匹配優化算法以提高系統性能等;即插即用以方便用戶。具體敘述如下:

①增加邊界防火墻組件以完善DFW的系統結構。在DFW模型中沒有考慮邊界防火墻,但邊界防火墻是分布式防火墻系統的有機組成部分,邊界防火墻可采用雙網卡主機或路由器,并在核心層實現包過濾,且規則的配置受控管中心控制。

②利用跨平臺技術以擴大系統的應用范圍。 在一個網絡中可能存在多種類型的主機,如Windows、Linux等,要實現這種環境下的分布式防火墻,必須利用跨平臺技術進行聯絡,使分布式防火墻不受平臺的限制。

③自適應策略優化配置以減小管理員配置規則的復雜度。規則配置是防火墻維護的難點,如果規則配置不當,防火墻將不能發揮應有的作用。分布式防火墻規則配置更加困難,因為管理員要為每個域甚至每臺機器配置規則,所以一個好的規則配置方案對分布式防火墻來說非常重要。所謂自適應策略優化配置是指,管理員先配置若干通用規則,然后管理員只要輸入用戶的若干信息,程序就可自動生成該用戶的規則(從通用規則中選取若干個)。

④策略匹配優化算法以提高系統性能。當一個防火墻的規則較多較復雜時,防火墻會明顯降低主機的系統性能,這時要考慮使用優化的規則匹配算法,如hash表過濾算法等。

⑤集成入侵檢測技術以增強系統的可靠性。 現在黑客的攻擊種類是五花八門,任何一種防火墻都不敢聲稱可防御所有的攻擊,防火墻隨時都可能被攻破。入侵檢測是當黑客攻破防火墻進入網絡內部時的一種檢測技術,可以把它想象成報警器。所以在防火墻中集成入侵檢測技術無疑是增加了一道安全屏障。在分布式防火墻系統中也可集成入侵檢測系統來增加系統的可靠性。

⑥即插即用以方便用戶。傳統防火墻保護下的網絡,用戶無須考慮防火墻問題,分布式防火墻需要用戶安裝防火墻并給予配合,這給用戶造成了一定的不便。即插即用的目標就是要使用戶在分布式防火墻保護的環境下工作就象在傳統防火墻保護的環境下一樣工作,無須考慮安裝主機防火墻,所有的工作都是自動或半自動完成的。

6.6小結

 本章在上一章模型的基礎上提出了對模型作改進的若干方案,這些方案都是為了增強系統的性能和可靠性的。這些方案主要是:雙層過濾、日志的智能處理、運用移動agent技術和使用加密認證等。

參考文獻

[1] Steven M. Bellovin,  "Distributed Firewalls", login, November 1999, pp. 39-47.

[2] Sotiris Ioannidis, Angelos D. Keromytis, Steve M. Bellovin, Jonathan M. Smith,

   Implementing a Distributed Firewall,

[3] Tom Markham and Charlie Payne, Security at the Network Edge: A Distributed Firewall Architecture,

[8] Windows Network Data And Packet Filtering Freqently Asked Questions

[9] Wei Hua, Jim Ohlund, Barry Butterklee,  Unraveling the Mysteries of Writing a Winsock 2 Layered Service Provider,MSDN

[10] CyberwallPLUS 7.0 User’s Reference

[11] CIPRESS White Paper, The Network Security and Filtering Layers in the Microsoft Windows NT Operating System Family Environment

[12] StormRanger Computer Security, Service Provider, Layered Service Providers And the Network Driver Interface

[13] S.Kent and R.Atkinson,Security Architecture for the Internet Protocol,RFC 2401,IETF,November 1998

[14] M.Blaze,J.Feigenbaum,J.Ioannidis and A.Keromytis,The KeyNote Trust-Management System Version 2,RFC 2704,IETF,September 1999

[15] Network Driver Interface Specification (NDIS) Frequently Asked Questions

[16] J.Kohi 等,The Kerberos Network Authentication Service(V5), RFC1510

[17] 一個有許多關于防火墻文章的站點

[18] 有許多關于分布式防火墻文章的站點

[19]  美國一家銷售分布式防火墻軟件產品的公司(Network_1)站點

[20] 新型防火墻技術,中國計算機報,2000年10月16日

[21] 劉靜,李瑋,主機也需“防彈衣”,PC WORLD CHINA/FEB 25,2002 NO.4

[22] 張金玲,卿思漢,防火墻遠程管理系統的實現,第二界中國信息和通信安全學術會議論文集

[23] 張 雙,卿思漢,防火墻日志分析系統的設計和實現,第二界中國信息和通信安全學術會議論文集

[24] 段海新等,Policy-Based Access Control Framework for Large Networks,軟件學報,2001年12期

[25] 揚毅堅,肖德寶,基于Agent的分布式防火墻,數據通信,2001年第2期

[26] 張磊,卿斯漢,一個基于Agent的防火墻系統的設計與實現,軟件學報,2000年第11期

[27] 陳春玲,雷世榮,陳丹偉,分布式防火墻的原理、實現及應用,南京郵電學院學報,2002年第4期

[28] 朱雁輝,Windows 防火墻與網絡封包截獲技術,機械工業出版社,2002年7月出版

[29] Anthony Jones, Jim Ohlund著, Windows 網絡編程, 北京大學出版社影印版

[30] Terry William Ogletree 著,李之棠等翻譯,防火墻的原理與實施,電子工業出版社

[31] 蔣東興等,Windows Sockets 網絡程序設計大全,清華大學出版社

[32] TCP/IP詳解,機械工業出版社

[33] Windows 2000驅動程序開發大全,機械工業出版社

[34] 張云勇,移動agent及其應用,清華大學出版社

[35] MSDN中關于Winsock 2 SPI 方面的論述

[36] DDK for Windows2000 中關于NDIS技術的論述

[37] 費爾安全實驗室網站(網址:http://www.xfilt.com)關于費爾個人防火墻的論述

 

 

附錄一 常用注冊表操作函數

 名稱及參數 參數的含義 功能

LONG RegCloseKey(

HKEY hKey

) 

handle to key to close 釋放注冊表鍵的句柄

LONG RegCreateKeyEx(

  HKEY     hKey,                                

  LPCTSTR  lpSubKey,                         

  DWORD    Reserved,                           

  LPTSTR   lpClass,                           

  DWORD    dwOptions,                          

  REGSAM   samDesired,                        

  LPSECURITY_ATTRIBUTES

lpSecurityAttributes,

  PHKEY phkResult,                          

  LPDWORD  lpdwDisposition 

handle to open key

subkey name

reserved

class string

special options

desired security access inheritance

key handle

disposition value buffer 創建注冊表鍵

LONG RegDeleteKey(

  HKEY    hKey,       

  LPCTSTR lpSubKey 

 ) 

handle to open key

subkey name 刪除子鍵

LONG RegDeleteValue(

  HKEY    hKey,           

  LPCTSTR lpValueName 

 ) 

handle to key

value name 刪除注冊表鍵的命名值

LONG RegEnumKey(

  HKEY   hKey,    

  DWORD  dwIndex,

  LPTSTR lpName,

  DWORD  cchName  

handle to key to query

index of subkey to query

buffer for subkey name

size of subkey name buffer

 每次調用返回一個子鍵的名字

LONG RegEnumKeyEx(

  HKEY      hKey,                

  DWORD     dwIndex,             

  LPTSTR    lpName,            

  LPDWORD   lpcName,           

  LPDWORD   lpReserved,         

  LPTSTR    lpClass,             

  LPDWORD   lpcClass,           

  PFILETIME lpftLastWriteTime

 ) 

handle to key to numerate subkey name

size of subkey buffer

reserved

class string buffer

size of class string buffer

last write time

size of class string buffer

last write time 枚舉打開的注冊表鍵的全部子鍵

LONG RegQueryValueEx(

  HKEY    hKey,           

  LPCTSTR lpValueName, 

  LPDWORD lpReserved,  

  LPDWORD lpType,      

  LPBYTE  lpData,       

  LPDWORD lpcbData  

  ) handle to key

value name

reserved

type buffer

data buffer

size of data buffer 取得某一打開的注冊表鍵值的類型和數據

LONG RegOpenKeyEx(

HKEY    hKey,

  LPCTSTR lpSubKey,

DWORD   ulOptions,

REGSAM  samDesired,

PHKEY   phkResult

) 

handle to open key

subkey name

reserved

security access mask

handle to open key 打開特定的注冊表鍵

LONG RegSetValueEx(

  HKEY    hKey,          

  LPCTSTR lpValueName,

  DWORD   Reserved,    

  DWORD   dwType,       

  CONST   BYTE *lpData, 

  DWORD   cbData

 )         

handle to key

value name

reserved

value type

value dat

size of value data 設置某一特定注冊表鍵值的類型和數

附錄二 分層服務提供者安裝函數

函數 參數用途 功能

int WSCEnumProtocols (

  LPINT   lpiProtocols,

  LPWSAPROTOCOL_INFOW

lpProtocolBuffer,

  LPDWORD lpdwBufferLength,

  LPINT   lpErrno

); 

1.(輸入)數組,若為NULL,返回全部協議,否則只返回數組中協議。

2.(輸出)WSAPROTOCOL_INFOW結構的緩沖區。

3.輸入、輸出)字節數

4.指向錯誤代碼的指針 取得可用的傳輸協議信息

int WSCGetProviderPath(

  LPGUID lpProviderId,

  LPWSTR lpszProviderDllPath,

  LPINT  lpProviderDllPathLen,

  LPINT  lpErrno

); 

1.(輸入)提供者的全局唯一標識。

2.(輸出)指向含有提供者DLL路徑字符串的緩沖區。

3.(輸入、輸出)路徑長度。

4.錯誤代碼指針。 取得特定提供者DLL的路徑

int WSCIntallProvider (

  const LPGUID lpProviderId,

  const LPWSTR

lpszProviderDllPath,

  const LPWSAPROTOCOL_INFOW

 lpProtocolInfoList,

  DWORD  dwNumberOfEntries,

  LPINT  lpErrno

); 

1.(輸入)全局唯一標識符。

2.(輸入)提供者DLL的路徑。

3.(輸入)指向WSAPROTOCOL_INFOW結構數組,每一個結構包含該提供者支持的協議、地址族和Socket類型。

4.(輸入)lpProtocolInfoList數組中的入口數目。

5.(輸出)錯誤代碼指針。 將特定的傳輸提供者裝入系統配置數據庫

int WSCWriteProviderOrder (

  LPDWORD lpwdCatalogEntryId,

  DWORD   dwNumberOfEntries

); 1.(輸入) CatalogEntryId元素(WSAPROTOCOL_IN

FO結構中的成員)的數組,該數組決定了新的順序。

2.(輸入)上述數組中元素的數目。 重新調整提供者的順序

int WSCDeinstallProvider (

  LPGUID lpProviderId,

  LPINT  lpErrno

); 

1.(輸入)要撤消的提供者的全局唯一標識符。

2.(輸出)錯誤代碼指針。 從系統配置數據庫撤消一個提供者

 

附錄三 TCP/IP協議各層包頭中用于包過濾的字段

版本號(4位) IHL(4位) 服務類型(8位) 總長度(16位)

標識(16位) 標志(3位) 分段偏移量(13位)

生存期(8位) 協議(8位) 頭校驗和(16位)

源IP地址(32位)

目的IP地址(32位)

任選項,如果有(可變) 填充位(可變)

數據(可變)

圖1  IP包頭中用于包過濾的字段

16位源端口號 16位目的端口號

32位序列號

32位確認號

4位首部

長度 

保留(6位) U

R

G A

C

K P

S

H R

S

T S

Y

N F

I

16位窗口大小

16位TCP校驗和 16位緊急指針

選項(若有)

數據(若有)

圖2  TCP包頭中用于包過濾的字段

16位源端口號 16位目的端口號

16位UDP長度 16位UDP校驗和

數據(若有)

圖3  UDP包頭中用于包過濾的字段

8位類型 8位代碼 16位校驗和

                              (不同類型和代碼有不同的內容)

圖4  ICMP報文

 

致  謝

 在本文即將完稿之際,我不禁想起那些直接或間接為論文做出貢獻、給予我重要支持和有益幫助的人們。

 首先我要特別感謝我的導師陳春玲副教授,在他的指導、幫助和鼓勵下,我在三年的研究生學習中克服了學習上和生活上的各種困難,完成了學校規定的所有學習任務,完成了項目和畢業論文。陳老師不僅有淵博的學問、嚴謹的治學態度和誨人不倦的精神,還有良好的為人處世的品格,所有這些都給我留下了深刻的印象,使我終身受益。

 同時,我要感謝信息安全教研室的陳丹偉老師,在項目開始階段他的講解使我受益非淺。我還要感謝所有給過我幫助的同學,尤其是我的師弟李春強同學,在項目的模型實現過程中他給過我許多VC++技術上的幫助,他在某些問題上的觀點使我頗受啟發。還有王曄、楊邃、紀翀、胡靜等同學,他們在項目討論會上的觀點開闊了我的視野。

 最后,我要向不辭辛苦評審論文的各位老師表達最誠摯的謝意。

             二○○三年三月

 

目  錄

前  言 1

第一章 防火墻技術與分布式技術概述 3

1.1 防火墻技術概述 3

1.1.1  防火墻的定義 3

1.1.2  防火墻的基本原理 3

1.1.3  Windows 網絡協議結構與用戶編程接口 5

1.1.4  幾種常用Windows網絡封包截獲技術概述 5

1.1.5  實用防火墻技術的進一步討論 10

1.2 分布式技術概述 11

1.2.1 分布式系統的概念與模式 11

1.2.2 客戶/服務器(C/S)模式基本技術介紹 12

1.2.3 移動代理模式簡介 15

1.3 小結 15

第二章 DFW的基本原理、運作機制與目前研究 16

2.1 傳統邊界防火墻的工作模型及其缺陷 16

2.1.1 傳統邊界防火墻的工作模型 16

2.1.2 傳統邊界防火墻存在的主要問題 16

2.2 DFW概念的提出 17

2.3 DFW的基本原理 17

2.4 DFW的本質特征 18

2.5 DFW的體系結構 18

2.6 DFW的運作機制 19

2.6.1 策略的制定與分發機制 19

2.6.2 日志的收集機制 20

2.6.3 加密認證機制 20

2.7 集中式防火墻向分布式防火墻演進的合理性及其面臨的困難 20

2.8 目前國內外DFW的研究進展情況 21

2.8.1 基于OpenBSD UNIX的實現[2] 21

2.8.2 基于網卡(NIC)的實現[3]、[4] 22

2.8.3 基于Windows平臺實現的實例 24

2.9小結 25

第三章 關鍵技術之一:WINSOCK 2 SPI與應用層防火墻技術 26

3.1 SPI基本原理 26

3.1.1 沒有安裝傳輸服務提供者情況下網絡傳輸的執行過程 26

3.1.2 安裝LSP后網絡傳輸的執行過程 27

3.2 SPI傳輸服務提供者安裝程序的編寫方法 27

3.2.1 基礎服務提供者的安裝程序 28

3.2.2 分層服務提供者的安裝程序 28

3.3 SPI傳輸服務提供者的編寫方法 28

3.3.1 WSPStartup函數的實現方法 29

3.3.2 服務函數的實現方法 30

3.3.3 兩種傳輸服務提供者在安裝和實現上的異同點的比較 31

3.4 SPI HOOK技術在防火墻中的應用 31

3.5小結 32

第四章 關鍵技術之二:網絡驅動程序與核心層防火墻技術 33

4.1驅動程序的一般原理 33

4.1.1驅動程序與應用程序的區別 33

4.1.2一個最小的驅動程序 34

4.1.3驅動程序的安裝 35

4.2網絡驅動程序概述 35

4.2.1什么是TDI驅動程序 35

4.2.2什么是NDIS驅動程序 35

4.3幾種核心層過濾驅動程序的實現方法 36

4.3.1用TDI 鉤子過濾驅動程序實現核心層過濾 36

4.3.2用NDIS中間驅動程序實現核心層過濾 38

4.3.3用NDIS鉤子驅動程序實現核心層過濾 40

4.4實現NDIS鉤子過濾驅動程序的關鍵問題 41

4.4.1 DriverEntry入口函數的功能 41

4.4.2 NDIS系統功能函數是如何實現HOOK(掛接)的 41

4.4.3 IP、TCP、UDP、ICMP包頭是如何被解析的 42

4.4.4 控管規則比對是如何被完成的 43

4.5 NDIS-HOOK與SPI-HOOK關鍵技術點的比較 43

4.6小結 43

第五章 DFW模型的設計與實現 45

5.1 DFW模型的設計 45

5.2 模型實現的總體類結構及其功能 46

5.2.1 模塊工作的層次圖 47

5.2.2 總體類結構及其功能 47

5.3 控管中心DFWSERVER.EXE的功能 49

5.4 主機防火墻界面模塊DFWCLIENT.EXE的功能分析與實現機制 51

5.4.1 DFWclient.exe的功能分析 52

5.4.2 DFWclient.exe啟動時索取規則以及工作時傳送日志的機理 52

5.4.3 DFWclient.exe與DFWclient.dll之間的交互 52

5.5 主機防火墻過濾模塊DFWCLIENT.DLL的結構和功能實現 53

5.5.1 DFWclient.dll模塊的執行流程 53

5.5.2 控管規則的比對過程 54

5.5.3 封包內容的分析提取 55

5.5.4 日志記錄的形成過程 55

5.6 DFW模型已完成的功能和存在的缺陷 56

5.7小結 56

第六章 DFW模型的改進 57

6.1運用應用層+核心層雙層過濾增強系統的可靠性 57

6.1.1 雙層過濾的益處 57

6.1.2 雙層過濾防火墻的模塊設計 57

6.1.3 雙層過濾防火墻的實現 57

6.2運用AGENT技術改造DFW模型 58

6.2.1在分布式防火墻中使用agent技術必要性的探討 58

6.2.2 移動agent技術探討 59

6.2.3 基于agent分布式防火墻的設計 59

6.3運用智能日志處理增強系統的智能性 61

6.3.1為什么要對日志進行處理 61

6.3.2 DFW系統中日志處理的一般過程 62

6.4運用加密技術增強系統自身的安全性 62

6.4.1 DFW系統中為什么要進行身份認證 62

6.4.2 kerberos基本原理 63

6.4.3 kerberos認證協議在本系統中的應用 64

6.5其他功能的展望 64

6.6小結 65

參考文獻 66

附錄一 常用注冊表操作函數 68

附錄二 分層服務提供者安裝函數 70

附錄三 TCP/IP協議各層包頭中用于包過濾的字段 71

致  謝 72

 

發布寫論文需求
發布發表需求
發布發表轉讓

無憂論文網 網站公告

[無憂論文網]是專業論文寫作潤色及發表論文網站,提供論文精簡,論文寫作,專業輔導寫職稱論文,專業輔導寫畢業論文,專業輔導寫留學生論文等。
100%品質,100%通過,是您寫作的理想合作網站。我們的客戶風雨同舟,幫廣大客戶解決各類寫作和發表難題。

新疆时时开奖历史记录