tdi過濾驅動udp

㈠ 數據防泄露的技術變革

透明加密技術是近年來針對企業數據保密需求應運而生的一種數據加密技術。所謂透明，是指對使用者來說是透明的，感覺不到加密存在，當使用者在打開或編輯指定文件時，系統將自動對加密的數據進行解密，讓使用者看到的是明文。保存數據的時候，系統自動對數據進行加密，保存的是密文。而沒有許可權的人，無法讀取保密數據，從而達到數據保密的效果。

自WindowsNT問世以來，微軟提出的分層的概念，使透明加密有了實現的可能。自上而下，

應用軟體，應用層APIhook(俗稱鉤子), 文件過濾驅動，卷過濾驅動，磁碟過濾驅動，另外還有網路過濾驅動，各種設備過濾驅動。其中應用軟體和應用層apihook在應用層(R3), 從文件過濾驅動開始，屬於內核層(R0).

數據透明加密技術，目前為止，發展了3代，分別為

第一代APIHOOK應用層透明加密技術；

第二代文件過濾驅動層（內核）加密技術；

第三代內核級縱深加密技術 ；

第一代：APIHOOK應用層透明加密技術

應用層透明加密技術俗稱鉤子透明加密技術。這種技術起源於win98時代，後來隨著windows2000而流行起來。就是將上述兩種技術（應用層API和Hook）組合而成的。通過windows的鉤子技術，監控應用程序對文件的打開和保存，當打開文件時，先將密文轉換後再讓程序讀入內存，保證程序讀到的是明文，而在保存時，又將內存中的明文加密後再寫入到磁碟中。應用層APIHOOK加密技術，特點是實現簡單，缺點是可靠性差，速度超級慢，因為需要臨時文件，也容易破解。但由於直接對文件加密直觀感覺非常好，對於當初空白的市場來講，這一旗號確實打動了不少企業。

第二代：文件過濾驅動加密技術

驅動加密技術是基於windows的文件系統（過濾）驅動技術，起源於WindowsNT發布之後，其工作在windows的內核層，處於應用層APIHook的下面，卷過濾和磁碟過濾的上面。設計思想是建立當應用程序(進程)和文件格式(後綴名)進行關聯，當用戶操作某種後綴文件時對該文件進行加密解密操作，從而達到加密的效果。

內核層文件過濾驅動技術，分IFS和Minifilter2類。IFS出現較早，Minfilter出現在xp以後。兩者的區別可以理解為VC++和MFC的區別，IFS很多事情需要自己處理，而Minifilter是微軟提供了很多成熟庫，直接用。由於windows文件保存的時候，存在緩存，並不是立即寫入文件，所以根據是否處理了雙緩bug，後來做了些細分，但本質還是一樣，都是問題的修正版本而已。但由於工作在受windows保護的內核層，運行速度比APIHOOK加密速度快，解決了很多問題和風險。

文件過濾驅動技術實現相對簡單，但穩定性一直不太理想。

第三代：內核級縱深沙盒加密技術

之所以叫內核級縱深沙盒加密技術，主要原因是使用了磁碟過濾驅動技術，卷過濾驅動技術，文件過濾驅動技術，網路過濾驅動(NDIS/TDI)技術等一系列內核級驅動技術，從上到下，縱深防禦加密。該技術也起源於WindowsNT之後，但由於技術復雜，開發要求高，公開資料少，而發展較慢。但隨著微軟公布了部分Windows源代碼之後，此技術開始逐漸成熟。內核級沙盒加密，是當使用者操作涉密數據的時候，對其存儲過程進行控制，對其結果進行加密保存，每個模塊只做自己最擅長的那塊，所以非常穩定。加密的沙盒是個容器，把涉密軟體，文件扔到容器中加密。而這個容器是透明的，使用者感覺不到它的存在。，

第三代透明加密技術的特點是，涉密數據使用前，先初始化涉密沙盒，沙盒加密一旦成功，之後所有的數據都是數據實體，不針對文件個體，所以無數據破損等問題。特點是速度快，穩定。

第一代，第二代本質都是採用的針對單個文件實體進行加密，如a.txt內容為1234, 加密後變成@#$%% +標記。@#$%%是把原文1234進行加密之後的密文。而標記的用途是用來區分一個a.txt文件是否是已經被加密。當系統遇到一個文件的時候，首先判斷這個標記是否存在，如果存在，表明是被系統加密過的，則走解密讀取流程，如果不是加密的，就無需解密，直接顯示給使用者，只是當保存的時候，再進行加密，使其成文密文+標記。

這就帶來一個巨大的風險 ：如果是一個較大文件，加密過程中發生異常，標記沒加上，那麼下次讀這個文件的時候，因為沒有讀到表記，而採用原文讀取，然後再加密，那麼這個文件就徹底毀壞了。這個現象在第一代APIHOOK透明加密技術的產品中特別明顯，在第二代文件過濾驅動產品中，因為速度變快了，使文件破損發生概率減低了很多，但並沒有本質解決這個問題。

另外， 由於是進程和文件後綴名進行關聯，也造成了一個缺陷 ：很多編程類軟體，復雜制圖軟體的編譯，曬圖等操作，都是很多進程同時操作某個文件，這個時候進行進程和文件關聯顯然太牽強了，因為進程太多了。即使進行關聯，多個進程交替訪問文件，加密解密混在一起，極容易造成異常。所以才會出現VC等環境下如不能編譯，調試等。

其他方面，版本管理無法對比，伺服器上存放的是密文（伺服器存密文，是個極大的風險，目前沒有哪家大企業敢這么做，畢竟太依賴加密軟體，持續性沒有了），大文件速度慢等，一系列問題，無法解決。

而第三代內核縱深加密技術是在前者2個基礎之上發展而來的，每個過濾層都只做自己最擅長的事情，所以特別穩定，速度快，性能可靠，不存在第一代和第二代的問題。由於內核級縱深透明加密技術要求高，涉及技術領域廣，極其復雜，開發周期長，所以國內的能做開發的廠商不多。目前， 深信達公司推出的SDC機密數據保密系統， 給人一眼前一亮的感覺，其產品是第三代透明加密保密技術的典型產品，其產品主要特點是：

1）採用了磁碟過濾，卷過濾，文件過濾，網路過濾等一系列縱深內核加密技術，採用沙盒加密，和文件類型和軟體無關，沙盒是個容器。

2）在操作涉密數據的同時，不影響上外網，QQ,MSN等。

3）保密徹底，包括網路上傳，郵件發送，另存，復制粘貼，屏幕截取等，特別是屏幕保密，做得非常炫。

4）服務上存放的是明文，客戶端存放的是密文，文件上傳伺服器自動解密，到達客戶端自動加密。伺服器上明文，減少了業務連續性對加密軟體的依賴。

5）不但可以針對普通文檔圖紙數據進行保密需求，同時更是研發性質的軟體公司( 游戲 ，通訊，嵌入式，各種BS/CS應用系統)源代碼保密首選。

㈡ 求個簡單的防火牆源代碼

防火牆源代碼網路上是有的，我也寫過一套，不過我寫的不是針對客戶端計算機的，是針對伺服器的， 目前客戶端防火牆開發上使用 大致分為3種技術 1、SPI 會話層過濾的，做行為控制比較好。2、TDI 傳輸層過濾驅動，性能要比SPI好。3、NDIS中間層過慮驅動，也是目前幾大防火牆廠家常用的計算機。 第一種防火牆 可以滿足你需要的功能，下載地址 http://down.cnzz.cn/info/6548.aspx 開發語言VC++6.0如果你想研究 第三種技術，並且也順帶 第一種技術的源代碼，目前沒有免費的。要通過付款購買的 http://www.filseclab.com/procts/source.htm

㈢ 個人防火牆的數據類型

用戶態（user-mode）和內核態（kernel-mode）。
1）用戶態（user-mode）。
在用戶態下進行網路數據包的攔截有三種方法：WinsockLayeredServiceProvider(LSP)、Windows2000包過濾介面、替換系統自帶的WINSOCK動態連接庫。在用戶態下
進行數據包攔截最致命的缺點就是只能在Winsock層次上進行，而對於網路協議棧中底層協議的數據包無法進行處理。因此，這些方法並不適合個人防火牆。
2）內核態（kernel-mode）。
a)TDI過濾驅動程序（TDIFilterDriver）。當應用程序要發送或接收網路數據包的時候，都是通過與協議驅動所提供的介面來進行的。協議驅動提供了一套系統預定義的標准介面來和應用程序之間進行交互。因此，只需要開發一個過濾驅動來截獲這些交互的介面，就可以實現網路數據包的攔截。在Windows2000/NT下，ip,tcp,udp是在一個驅動程序里實現的，叫做tcp.sys，這個驅動程序創建了5個設備：DeviceRawIp，DeviceUdp，DeviceTcp，DeviceIp，DeviceMULTICAST。應用程序所有的網路數據操作都是通過這些設備進行的。因此，我們只需要開發一個過濾驅動來截獲這些交互的介面，就可以實現網路數據包的攔截。另外，TDI層的網路數據攔截還可以得到操作網路數據包的進程詳細信息，這也是個人防火牆的一個重要功能。但是，TDI傳輸驅動程序有一個缺陷，TDIFilterdriver屬於Upperdriver,位於TcpIP.sys之上，這就意味著由TcpIP.sys接收並處理的數據包不會傳送到上層，從而無法過濾某些接收的數據包，例如ICMP包。ICMP的應答包直接由TcpIP.sys生成並回應，而上面的過濾驅動程序全然不知。另外，該方法需要在系統核心層編寫驅動程序，需要編寫人員對Windows操作核心層的工作機制非常熟悉，同時，驅動程序對代碼質量要求非常高，稍有不慎就會使系統崩潰，
b)Win2kFilter-HookDriver。這是從Windows2000開始系統所提供的一種驅動程序，該驅動程序主要是利用Ipfiltdrv.sys所提供的功能來攔截網路數據包。Filter-HookDriver的結構非常簡單，易於實現。但是正因為其結構過於簡單，並且依賴於Ipfiltdrv.sys，Microsoft並不推薦使用Filter-HookDriver。
c)NDISHookDriver。該方法在Windows2000/xp下是非公開的，因此這種方法對平台的依賴性比較大，需要在程序中判斷不同的操作系統版本而使用不同的方法。
d)NDIS中間層驅動程序（NDISIntermediateDriver）。NDIS（）是Microsoft和3Com公司開發的網路驅動程序介面規范的簡稱，它支持如下三種類型的網路驅動程序：微埠驅動程序、中間層驅動程序（IntermediateDriver）和協議驅動程序。其中中間層驅動介於協議層驅動和小埠驅動之間，其功能非常強大，可以提供多種服務，能夠截獲所有的網路數據包（以太幀），過濾微埠驅動程序，實現特定的協議或其他諸如數據包加密、認證等功能。綜上所述，在NDIS中間層進行網路數據包截獲的方法結構規范，功能強大，該技術極其適合個人防火牆所採用。
中間層驅動程序（NDIS）的內部結構
NDIS支持3種驅動：微埠驅動，中間層驅動和協議驅動。
1） 微埠驅動。就是網卡驅動，它負責管理網卡，包括通
過網卡發送和接受數據，它也為上層驅動提供介面。
2） 中間層驅動。它通常位於微埠驅動和傳輸協議驅動之間，是基於鏈路層和網路層之間的驅動，由於中間層驅動在驅動層次中的中間層位置，它必須與其上層的協議和下層的微埠驅動通信，並且導出兩種協議的函數。雖然中間層驅動導出MINIPORTXX函數，但它並不真正的管理物理網卡，而是導出一個或者多個虛擬適配器，上層協議可以綁定到上面。對於協議驅動來說，中間層導出的虛擬適配器看起來像一個物理網卡，當它向這個虛擬適配器發送封包或者請求時，中間層驅動將這些封包和請求傳播到下層微埠驅動；當下層微埠驅動向上指示接收封包或者狀態時，中間層驅動向上到綁定虛擬適配器上的協議驅動。中間層驅動的主要作用就是過濾封包，其優點是能夠截獲所有的網路數據包。
3） 協議驅動，即網路協議。它位於NDIS體系的最高層，經常用作實現傳輸協議堆棧的傳輸驅動中的最底層驅動。傳輸協議驅動申請封包，從發送應用程序將數據復制到封包中，通過調用NDIS函數將這些封包發送到下層驅動。協議驅動也是提供了一個協議介面來接收來自下層驅動的封包。傳輸協議驅動將收到的封包傳遞給相應的客戶應用程序。在下層，協議驅動與中間層微埠驅動交互。協議驅動調用NDISXX函數發送封包，讀取和設置下層驅動維護的信息，使用操作系統服務。協議驅動也要導出一系列的入口點，NDIS調用它來指示封包的接受，指示下層驅動的狀態，或者是和其他協議驅動的通信。
中間層內部的工作流程
1) 中間層對數據包的管理
中間層驅動程序從高層驅動程序接收數據包描述符，並在網路上發送，該包描述符與一個或多個鏈式數據緩沖區相關聯。中間層驅動程序能夠對數據進行重新打包，並使用新的數據包描述符進行數據傳輸，也可以直接將數據包傳遞給低層驅動程序，如果驅動程序下邊界面向無連接，可調用NdisSend或NdisSendPackets函數完成該功能，如果驅動程序下邊界是面向連接的，可調用NdisCoSendPackets函數完成此項功能。中間層驅動程序也可以進行一些操作改變鏈式緩沖區的內容，或者調整內入數據包相對於其他發送任務的發送次序或發送定時。但是，即使中間層驅動程序只是向下層傳遞上層引入的數據報，例如，僅僅只是對數據包進行計數，也必須分配新的數據包描述符，並且要管理部分或者全部新的包結構。
每一個中間層驅動程序都必須分配自己的包描述符來代替高層的數據包描述符。如果中間層驅動程序要把數據包從一種格式轉化為另一種格式，也必須分配緩沖區描述符來映射用於復制轉配數據的緩沖區，該緩沖區由中間層驅動程序進行分配。如果有與復制的包描述符相關的OOB數據，那麼可以將這些數據復制到與包描述符（中間層驅動程序分配的）相關的新OOB數據塊，其過程是，首先，用NDIS_OOB_DATA_FROM_PACKET宏獲取OOB數據區的指針，然後，調用disMoveMemory將其內容移入與新包描述符相關的OOB數據區。該驅動程序也能夠用NDIS_GET_PACKET_XXX或NDIS_SET_PACKET_XXX宏從與老的包描述符相關的OOB數據區中，讀取相關的內容，並寫入與新包描述符相關的OOB數據區。
包描述符通過調用以下NDIS函數進行分配
a)調用NdisAllocatePacketPool或者NdisAllocatePacketPoolEx，為固定尺寸包描述符（由呼叫器指定數量）分配並初始化一組非可分頁池。
b)調用NdisAllocatePacket函數，從NdisAllocatePacketPool(Ex)已經分配的池中分配包描述符。根據中間層驅動程序目的的不同，驅動程序能夠對引入包描述符連接的緩沖區進行重新打包。例如，中間層驅動程序可以在接下來的情況下分配包緩沖池、對引入包數據重新打包.如果中間層驅動程序從高層協議驅動程序接收到的數據緩沖區，比低層介質能夠發送的單個緩沖區更大，那麼中間層驅動程序必須將引入的數據緩沖分割成更小的、滿足低層發送要求的數據緩沖。中間層驅動程序在將發送任務轉交低層驅動程序之前，可以通過壓縮或加密數據方式來改變內入數據包的長度。調用以下NDIS函數分配上面所要求的緩沖區：
NdisAllocateBufferPool獲取用於分配緩沖區描述符的句柄；
NdisAllocateMemory或NdisAllocateMemoryWithTag分配緩沖區；
c)調用NdisAllocateBuffer分配和設置緩沖區描述符，映射由NdisAllocateMemory(WithTag)分配的緩沖區，並鏈接到NdisAllocatePacket分配的包描述符上。驅動程序可以通過調用NdisChainBufferAtBack或NdisChainBufferAtFront函數，將緩沖區描述符和包描述符進行鏈接。調用NdisAllocateMemory(WithTag)返回的虛擬地址和緩沖區長度，將被傳遞給NdisAllocateBuffer函數來初始化其所映射的緩沖區描述符。符合典型要求的包描述符能夠在驅動程序初始化時根據要求進行分配，也可以通過ProtocolBindAdapter函數調用來實現。如果必要或者出於性能方面的考慮，中間層驅動程序開發者可以在初始化階段，分配一定數量的包描述符和由緩沖區描述符映射的緩沖區，這樣，就為ProtocolReceive復制內入數據（將向高層驅動程序指示）預先分配了資源，也為MiniportSend或MiniportSendPackets向相鄰低層驅動程序傳遞引入的發送數據包，准備了可用的描述符和緩沖區。如果在中間層驅動程序復制接收/發送數據到一個或多個緩沖區時，最末的一個緩沖的實際數據長度比緩沖區的長度小，那麼，中間層驅動程序將調用NdisAdjustBufferLength把該緩沖區描述符調節到數據的實際長度。當該包返回到中間層驅動程序時，應再次調用該函數將其長度調節到完整緩沖區的實際尺寸。
2)下邊界面向無連接的中間層驅動程序的工作流程
通過ProtocolReceivePacket函數，從低層NIC驅動程序以完整數據包形式接收內入數據，該數據包由NDIS_PACKET類型的包描述符指定，也能夠通過將內入數據指示給ProtocolReceive函數，並將數據復制到中間層驅動程序提供的數據包中。下邊界面向連接的中間層驅動程序總是用ProtocolCoReceivePacket函數，從低層NIC驅動程序接收數據作為一個完整的數據包。
在如下情況下，中間層驅動程序能夠保持對接收數據包的所有權：當下邊界面向無連接的中間層驅動程序向ProtocolReceivePacket函數指示完整數據包時,當下邊界面向連接的中間層驅動程序向ProtocolCoReceivePacket函數指示數據包時，其中DIS_PACKET_OOB_DATA的Status成員設置為除NDIS_STATUS_RESOURCES以外的任何值。在這些情況下，中間層驅動程序能夠保持對該包描述符和其所描述的資源的所有權，直到所接收數據處理完畢，並調用NdisReturnPackets函數將這些資源返還給低層驅動程序為止。如果ProtocolReceivePacket向高層驅動程序傳遞其所接收的資源，那麼至少應該用中間層驅動程序已經分配的包描述符替代引入包描述符。根據中間層驅動程序目的的不同，當其從低層驅動程序接收完整數據包時，將有幾種不同的包管理策略。例如，以下是幾種可能的包管理策略：復制緩沖區內容到中間層驅動程序分配的緩沖區中，該緩沖區被映射並鏈接到一個新的包描述符，向低層驅動程序返回該輸入包描述符，然後可以向高層驅動程序指示新的數據包；創建新的包描述符，將緩沖區（與被指示包描述符相關聯）鏈接到新的包描述符，然後將新的包描述符指示給高層驅動程序。當高層驅動程序返回包描述符時，中間層驅動程序必須拆除緩沖區與包描述符間的鏈接，並將這些緩沖區鏈接到最初從低層驅動程序接收到的包描述符，最後向低層驅動程序返還最初的包描述符及其所描述的資源。即使下邊界面向無連接的中間層驅動程序支持ProtocolReceivePacket函數，它也提供ProtocolReceive函數。當低層驅動程序不釋放包描述符所指示資源的所有權時，NDIS將調用ProtocolReceive函數，當這類情況出現時，中間層驅動程序必須復制所接收的數據到它自己的緩沖區中。對於下邊界面向連接的中間層驅動程序，當低層驅動程序不釋放包描述符所指示資源的所有權時，則將數據包的NDIS_PACKET_OOB_DATA的Status成員設為NDIS_STATUS_RESOURCES，然後驅動程序的ProtocolCoReceivePacket函數必須將接收到數據復制到自己的緩沖區中
5） 中間層驅動過濾數據包的原理
NDIS中間層驅動程序在NDIS中起著轉發上層驅動程序送來的數據包，並將其向下層驅動程序發送的介面功能。當中間層驅動程序從下層驅動程序接收到數據包時，它要麼調用NdisMXxxIndicateReceive函數，要麼調用NdisMindicateReceivePacket函數向上層指示該數據包中間層驅動程序通過調用NDIS打開和建立一個對低層NIC驅動程序或者NDIS中間層驅動程序的綁定。中間層驅動程序提供MiniportSetInformation和MiniportQueryInformation函數來處理高層驅動程序的設置和查詢請求，某些情況下，可能還要將這些請求向低層NDIS驅動程序進行傳遞，如果其下邊界是面向無連接的可通過調用NidsRequest實現這一功能，如果其下邊界是面向連接的則通過調用NidsCoRequest實現該功能。中間層驅動程序通過調用NDIS提供的函數向網路低層NDIS驅動程序發送數據包。例如，下邊界面向無連接的中間層驅動程序必須調用NdisSend或NdisSendPackets來發送數據包或者包數組，而在下邊界面向連接的情況下就必須調用NdisCoSendPackets來發送包數組數據包。如果中間層驅動程序是基於非NDISNIC驅動程序的，那麼在調用中間層驅動程序的MiniportSend或Miniport(Co)SendPackets函數之後，發送介面對NDIS將是不透明的。NDIS提供了一組隱藏低層操作系統細節的NdisXxx函數和宏。例如，中間層驅動程序可以調用NdisMInitializeTimer來創建同步時鍾，可以調用NdisInitializeListHead創建鏈表。中間層驅動程序使用符合NDIS標準的函數，來提高其在支持Win32介面的微軟操作系統上的可移植性。
在防火牆的設計中，最核心的部分應該是數據包的過濾。
其他的功能都是建立在數據包過濾的基礎之上，如：入侵檢測功能和郵件檢測功能都是建立在數據包過濾的基礎之上。數據包過濾中主要是IP包頭的分析，例如：在乙太網中，得到的數據報大致是如下結構，以太幀頭14個位元組，放在PUCHAR結構數組的第0個元素到第13個元素中，其中前六個位元組是目的MAC地址，然後六個位元組源MAC地址，然後兩個位元組是協議類型，通常的協議類型有0x080x00->IP，0x080x06->ARP，0x080x35->RARP，所以，可以通過數組的第12個元素和第13個元素來判斷協議類型。過濾規則就是在這個基礎之上建立。如果要過濾特定協議，只要在相應的位元組讀取數據，判斷是否符合要過濾的規則就可以了，當然實際的過濾規則要復雜的多的多，比如對指定的埠指定的IP的過濾。