本發(fā)明屬于網(wǎng)絡(luò)安全技術(shù)領(lǐng)域，涉及網(wǎng)絡(luò)安全中的訪問控制，尤其涉及一種在tcp連接報文中段傳遞客戶端進程詳細信息的方法，該客戶端進程詳細信息可供tcp監(jiān)聽端進行訪問授權(quán)。

背景技術(shù)：

為了支持異構(gòu)網(wǎng)絡(luò)之間的互聯(lián)互通，減少網(wǎng)絡(luò)設(shè)計的復(fù)雜性，簡化網(wǎng)絡(luò)設(shè)備的實現(xiàn)，傳輸控制協(xié)議/因特網(wǎng)互聯(lián)協(xié)議(tcp/ip)采用分層結(jié)構(gòu)實現(xiàn)。以tcp/ip的四層模型為例，從上至下分別有：應(yīng)用層、傳輸層、網(wǎng)絡(luò)互連層、主機到接口層。所有的主流操作系統(tǒng)都遵從此分層模型實現(xiàn)tcp/ip(協(xié)議棧)?；ヂ?lián)網(wǎng)發(fā)展到今天的規(guī)模，分層模型功不可沒，但分層實現(xiàn)的也有其弱點：隨著信息的逐級傳遞，過程中高層次的部分信息會被丟棄，這使得以信息安全為目標的網(wǎng)絡(luò)訪問控制難以實現(xiàn)，也使得以服務(wù)保障為目標的包篩選缺少了依據(jù)。

tcp是面向連接的通信協(xié)議，通過三次握手建立連接，通訊完成時要拆除連接，由于tcp是面向連接的，所以只能用于端到端的通訊。其握手過程如下：客戶端發(fā)送帶有syn(“同步”)標志的包，以請求連接；服務(wù)端發(fā)送帶有syn和ack(“確認”)標志的包，以應(yīng)答連接；客戶端發(fā)送帶有ack標志的包，連接建立完畢。以典型的基于tcp的客戶端/服務(wù)器通訊為例：服務(wù)端程序在指定的tcp端口上監(jiān)聽連接，客戶端程序發(fā)起連接，連接請求發(fā)送到協(xié)議棧時，客戶端的進程信息還是已知的，請求經(jīng)過協(xié)議棧從應(yīng)用層傳遞到傳輸層后，進而構(gòu)造成syn報文后，進程相關(guān)的信息(諸如進程名稱、用戶賬號等)均被丟棄，取而代之網(wǎng)絡(luò)地址和端口號。例如，一個web服務(wù)在tcp80端口監(jiān)聽，預(yù)期響應(yīng)瀏覽器發(fā)起的連接請求，但是當(dāng)一個連接請求到達后，僅根據(jù)網(wǎng)絡(luò)地址和端口信息，是無法確定對方到底是一個瀏覽器，還是一個惡意的工具。套用訪問控制模型，這種情況就是因主體不明確而導(dǎo)致控制失效。

網(wǎng)際網(wǎng)路安全協(xié)議(internetprotocolsecurity，ipsec)是一個協(xié)議組合，透過對ip報文進行加密和認證來保護ip協(xié)議的網(wǎng)絡(luò)傳輸協(xié)議族(一些相互關(guān)聯(lián)的協(xié)議的集合)。ipsec由兩大部分組成：

(一)建立安全分組流的密鑰交換協(xié)議，即互聯(lián)網(wǎng)密鑰交換(ike)協(xié)議；

(二)保護分組流的協(xié)議，包括加密分組流的封裝安全載荷協(xié)議(esp協(xié)議)或認證頭協(xié)議(ah協(xié)議)協(xié)議，用于保證數(shù)據(jù)的機密性、來源可靠性(認證)、無連接的完整性并提供抗重播服務(wù)。ipsec用來提供：

(一)入口對入口通信安全，在此機制下，分組通信的安全性由單個節(jié)點提供給多臺機器(甚至可以是整個局域網(wǎng))；

(二)端到端分組通信安全，由作為端點的計算機完成安全操作。

ipsec最主要的用途是構(gòu)造虛擬專用網(wǎng)絡(luò)(vpn)，通常實現(xiàn)為專用的設(shè)備。上述的任意一種模式都可以用來構(gòu)建虛擬專用網(wǎng)(vpn)。但是，受限于分層框架，ipsec的認證過程僅是針對用戶身份的，與具體的網(wǎng)絡(luò)應(yīng)用程序無關(guān)，也就是說，基于ipsec的隧道建立起來之后，客戶端和服務(wù)端之間的訪問仍然是不限制的，此時，如果有惡意代碼嘗試攻擊服務(wù)端，數(shù)據(jù)仍然是可達的。此外，ipsec在應(yīng)用時，會明顯的改變用戶的使用習(xí)慣，例如，在訪問指定的網(wǎng)絡(luò)資源前需要先進行一個需要用戶干預(yù)的認證過程，例如輸入賬號口令或插入智能卡。再有，ipsec被設(shè)計為端到端的(隧道)，與現(xiàn)有互聯(lián)網(wǎng)的開放特征不盡匹配，難以廣泛應(yīng)用。

技術(shù)實現(xiàn)要素：

為了克服上述現(xiàn)有技術(shù)的不足，本發(fā)明提供一種在tcp連接階段傳遞客戶端信息的方法，在兼容現(xiàn)有的tcp/ip規(guī)范、不影響上層應(yīng)用開發(fā)的前提下改造協(xié)議棧的實現(xiàn)，通過在tcp的握手過程中附加交換客戶端的應(yīng)用程序信息，實現(xiàn)精細的訪問控制，從而達到增強的網(wǎng)絡(luò)安全效果，還可為服務(wù)質(zhì)量保證(qos)提供附加的支持。

本發(fā)明提供的技術(shù)方案是：

一種在tcp連接階段傳遞客戶端信息的方法，通過改造通訊雙方的協(xié)議棧，在tcp的握手過程(包括約定模式和協(xié)商模式)中附加交換客戶端的應(yīng)用程序信息，實現(xiàn)精細的訪問控制，從而達到增強的網(wǎng)絡(luò)安全效果，并為服務(wù)質(zhì)量保證(qos)提供附加支持；

具體地，通過改寫tcp/ip協(xié)議棧驅(qū)動(針對開源系統(tǒng))或過濾器/掛鉤技術(shù)(針對開源系統(tǒng)或非開源系統(tǒng))，改造通訊雙方的協(xié)議棧，對于客戶端系統(tǒng)：在其傳輸層的上端接口處，過濾應(yīng)用層發(fā)起的連接請求；在其下端與網(wǎng)絡(luò)層之間的接口處，過濾網(wǎng)絡(luò)包的發(fā)送與接收；對于tcp服務(wù)端系統(tǒng)：在其傳輸層與網(wǎng)絡(luò)層之間的接口處，過濾網(wǎng)絡(luò)包的接收。

在對tcp連接的握手過程處理中，本方法定義了兩種工作模式以適應(yīng)不同的應(yīng)用場景：一、約定模式，在此模式下，客戶端和服務(wù)方均假定對方能夠處理握手報文中攜帶的客戶端應(yīng)用程序信息；二、協(xié)商模式，在此模式下，客戶端假定服務(wù)方不需要或不能夠處理握手報文中攜帶的客戶端應(yīng)用程序信息，直到服務(wù)端顯式的回送客戶端應(yīng)用程序信息請求時，客戶端才構(gòu)造并發(fā)送攜帶客戶端應(yīng)用程序信息的握手報文。

本方法在tcp連接階段的處理包括如下步驟：

步驟一，當(dāng)客戶端進程的連接請求送達協(xié)議棧時，開始采集客戶端的進程信息，可包括進程的賬號、名稱、哈希值、代碼簽名狀態(tài)及當(dāng)前線程的調(diào)用棧信息，將此信息緩存起來。

步驟二，當(dāng)協(xié)議棧的傳輸層模塊對tcp連接請求解析完成后，會構(gòu)造syn報文，發(fā)送到網(wǎng)絡(luò)層，在約定模式下，將提取出步驟一中緩存的客戶端進程信息，將其編碼到syn報文的載荷中；在協(xié)商模式下，則提取出syn報文中的連接信息，在緩存中建立其與步驟一中提取到的客戶端進程信息的映射，以便后續(xù)處理。

進一步的，所述步驟二在約定模式下具體包括：

步驟a1，提取出緩存的客戶端進程信息，用預(yù)定的封裝算法將其轉(zhuǎn)換為字節(jié)數(shù)組，添加到syn報文的傳輸層載荷數(shù)據(jù)；

封裝算法將信息編碼為字節(jié)數(shù)組，例如：將信息的中包含的內(nèi)容逐一添加到一個c語言的結(jié)構(gòu)(struct)中，然后使用aes加密算法加密后，再將加密后的結(jié)構(gòu)的內(nèi)存復(fù)制到syn報文的載荷數(shù)據(jù)里。

步驟a2，重新計算syn報文tcp首部的校驗和；

步驟a3，可調(diào)整syn報文ip首部中的報文長度字段，并重新計算ip首部的校驗和。

進一步的，所述步驟二在協(xié)商模式下具體包括：

步驟b1，提取出syn報文中包含的初始連接信息，具體有目標ip地址，目標端口號，syn序號。

步驟b2，在緩存中建立初始連接信息到客戶端進程信息的映射，以便在服務(wù)端回送請求時重新構(gòu)造syn報文。

這里映射指的是在內(nèi)存中維護初始連接信息與客戶端進程信息的一一對應(yīng)關(guān)系，在實現(xiàn)時可以使用哈希表存儲，以加速查找速度。

步驟b3，為步驟b2中建立的映射創(chuàng)建一個定時器處理過程，以便在連接超時后從緩存中銷毀初始連接信息、客戶端進程信息及其映射的數(shù)據(jù)結(jié)構(gòu)。

步驟三，syn報文傳送至服務(wù)端，如果服務(wù)端的協(xié)議棧沒有經(jīng)過前面所述的協(xié)議棧改造，將按常規(guī)的方式應(yīng)答syn+ack響應(yīng)或rst(復(fù)位)拒絕。否則服務(wù)端將嘗試提取報文中攜帶的客戶端進程信息，如果客戶端工作在約定模式下，報文中將攜帶客戶端進程信息，服務(wù)端將根據(jù)預(yù)設(shè)的規(guī)則驗證是否允許此連接，如果不允許，將回送普通的rst報文拒絕連接，如果允許，將回送syn+ack報文；如果客戶端工作在協(xié)商模式下，syn報文中沒有客戶端進程信息，服務(wù)端將回送rst報文，并在rst報文中附加客戶端進程信息請求數(shù)據(jù)，以期望客戶端重新發(fā)送syn報文。

在rst報文中附加的客戶端進程信息請求數(shù)據(jù)，可包含加密算法的選擇及其密鑰協(xié)商等信息，編碼時可以用共鑰加密算法保證其安全性。

步驟四，客戶端接收到服務(wù)器的應(yīng)答后，根據(jù)不同的情況可能有：情況一，服務(wù)端應(yīng)答syn+ack報文確認連接，則發(fā)送ack應(yīng)答，連接建立成功；情況二，服務(wù)端應(yīng)答普通的rst拒絕連接報文，則向應(yīng)用層返回連接失?。磺闆r三，服務(wù)端應(yīng)答帶有客戶端進程信息請求數(shù)據(jù)的rst報文，則從緩存中提取出連接信息和進程信息，按客戶端進程信息請求數(shù)據(jù)中的要求重新構(gòu)造syn報文，在報文中攜帶上客戶端進程信息。

進一步的，在步驟四的第三種情況下，包括以下步驟：

步驟c1，從rst報文中提取出客戶端進程信息請求數(shù)據(jù)。

步驟c2，從rst報文中還原出初始連接信息。

步驟c3，在緩存中用初始連接信息查找其映射的客戶端進程信息。

步驟c4，根據(jù)步驟c1中提取出的客戶端進程信息請求數(shù)據(jù)中要求的算法和密鑰，將客戶端進程信息用封裝算法將其轉(zhuǎn)換為字節(jié)數(shù)組，添加到syn報文的傳輸層載荷數(shù)據(jù)；

步驟c5，重新計算syn報文tcp首部的校驗和；

步驟c6，可調(diào)整syn報文ip首部中的報文長度字段，并重新計算ip首部的校驗和。

步驟c7，發(fā)送新構(gòu)造的syn報文。

步驟五，連接建立成功或者連接失敗，均將銷毀前述步驟中創(chuàng)建的各項緩存，至此，客戶端的處理流程完畢，在tcp連接階段實現(xiàn)客戶端信息的傳遞。

本發(fā)明具體實施中，采用本發(fā)明方法對客戶端在約定模式下主動攜帶進程信息(三路握手)和客戶端在協(xié)商模式下被動攜帶進程信息(五路握手)的情況進行處理，均在tcp連接階段實現(xiàn)了客戶端信息的傳遞。

與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是：

本發(fā)明提供一種在tcp連接階段傳遞客戶端信息的方法，通過在tcp的握手過程中附加交換客戶端的應(yīng)用程序信息，實現(xiàn)精細的訪問控制，從而達到增強的網(wǎng)絡(luò)安全效果，還可為服務(wù)質(zhì)量保證(qos)提供附加的支持。本發(fā)明是在兼容現(xiàn)有的tcp/ip規(guī)范、不影響上層應(yīng)用開發(fā)的前提下改造協(xié)議棧的實現(xiàn)，由此實現(xiàn)以信息安全為目標的網(wǎng)絡(luò)訪問控制，同時也可為以服務(wù)保障為目標的包篩選提供依據(jù)。本發(fā)明在tcp連接報文中段傳遞客戶端進程詳細信息，該客戶端進程詳細信息可供tcp監(jiān)聽端進行訪問授權(quán)，可廣泛應(yīng)用于網(wǎng)絡(luò)安全中的訪問控制。

附圖說明

圖1是本發(fā)明實施例中tcp/ip協(xié)議棧掛接位置的示意圖；

其中，實線表示報文的發(fā)送流程，虛線表示報文的接收流程；hookti表示在協(xié)議棧傳輸層的入口點攔截tcp連接請求的掛接點；hookto表示在傳輸層與網(wǎng)絡(luò)層之間的出口點攔截網(wǎng)絡(luò)包的發(fā)送的掛接點；hookri表示在傳輸層與網(wǎng)絡(luò)層之間的入口點攔截傳輸層包的接收的掛接點。

圖2是本發(fā)明方法的流程框圖。

圖3是本發(fā)明實施例一約定模式下傳遞客戶端信息的方法流程框圖。

圖4是本發(fā)明實施例二協(xié)商模式下傳遞客戶端信息的方法流程框圖。

具體實施方式

下面結(jié)合附圖，通過實施例進一步描述本發(fā)明，但不以任何方式限制本發(fā)明的范圍。

本發(fā)明提供一種在tcp連接階段傳遞客戶端信息的方法，通過改造通訊雙方的協(xié)議棧，在tcp的握手過程中附加交換客戶端的應(yīng)用程序信息，實現(xiàn)精細的訪問控制，從而達到增強的網(wǎng)絡(luò)安全效果，并為服務(wù)質(zhì)量保證(qos)提供附加支持；圖1示意了實施例一和實施例二中tcp/ip協(xié)議棧掛接位置。圖2示意了本發(fā)明方法的整體流程。

改造通訊雙方的協(xié)議棧，在具體實施中，針對開源系統(tǒng)，直接在源代碼級別改造協(xié)議棧更簡單，這在開發(fā)自主的系統(tǒng)時有效；過濾器、掛鉤技術(shù)是使用并行的模塊干預(yù)協(xié)議棧，兼容性更好一些，不用替換內(nèi)核模塊(刷機)。在實際實現(xiàn)中，主要通過過濾器、掛鉤技術(shù)改造通訊雙方的協(xié)議棧。

以下實施例分別具體說明了客戶端主動攜帶進程信息(三路握手)和客戶端被動攜帶進程信息(五路握手)的情況；圖3和圖4分別表示了實施例一和二采用本發(fā)明方法的實施流程。

實施例一：約定模式下客戶端主動攜帶進程信息(三路握手)的情況：

此實施例中，采用本發(fā)明方法在tcp連接階段傳遞客戶端信息包括如下步驟：

步驟一，掛接客戶端操作系統(tǒng)的協(xié)議棧驅(qū)動程序，在協(xié)議棧傳輸層的入口點攔截tcp連接請求，記作掛接點ti(hookti)；在傳輸層與網(wǎng)絡(luò)層之間的出口點攔截網(wǎng)絡(luò)包的發(fā)送，記作掛接點to(hookto)。

步驟二，當(dāng)客戶端進程嘗試發(fā)起tcp連接時，命中hookti，hookti處理例程即開始采集客戶端的進程信息，可包括進程的賬號、名稱、哈希值、代碼簽名狀態(tài)及當(dāng)前線程的調(diào)用棧信息，進程信息整體記作piset。

步驟三，將步驟二采集的進程信息piset，緩存起來，以供下一步驟或后續(xù)調(diào)用使用。

步驟四，當(dāng)協(xié)議棧的傳輸層模塊對tcp連接請求解析完成后，會構(gòu)造syn報文，發(fā)送到網(wǎng)絡(luò)層，即將命中hookto，hookto處理例程將提取緩存的piset，將其添加到syn報文的載荷數(shù)據(jù)。

進一步的，所述步驟四，具體包括：

步驟a，提取出緩存的piset信息，用預(yù)定的封裝算法將其轉(zhuǎn)換為字節(jié)數(shù)組，添加到syn報文的傳輸層數(shù)據(jù)。

步驟b，重新計算tcp首部的校驗和。

步驟c，如果需要，調(diào)整ip首部中的報文長度字段，并重新計算ip首部的校驗和。

步驟五，syn報文傳送至服務(wù)端，服務(wù)端驗證或忽略syn報文中的piset后，應(yīng)答標準的syn+ack報文。

步驟六，客戶端接收到服務(wù)器應(yīng)答的syn+ack后，發(fā)送ack應(yīng)答。

至此，客戶端的處理流程完畢，在tcp連接階段實現(xiàn)客戶端信息的傳遞。

實施例二：協(xié)商模式下客戶端被動攜帶進程信息(五路握手)的情況：

此實施例中，采用本發(fā)明方法在tcp連接階段傳遞客戶端信息包括如下步驟：

步驟一，掛接客戶端操作系統(tǒng)的協(xié)議棧驅(qū)動程序，在協(xié)議棧傳輸層的入口點攔截tcp連接請求，記作掛接點ti(hookti)；在傳輸層與網(wǎng)絡(luò)層之間的出口點攔截網(wǎng)絡(luò)包的發(fā)送，記作掛接點to(hookto)；在傳輸層與網(wǎng)絡(luò)層之間的入口點攔截傳輸層包的接收，記作掛接點ri(hookri)。

步驟二，當(dāng)客戶端進程嘗試發(fā)起tcp連接時，命中hookti，hookti處理例程即開始采集客戶端的進程信息，可包括進程的賬號、名稱、哈希值、代碼簽名狀態(tài)及當(dāng)前線程的調(diào)用棧信息，進程信息整體記作piset。

步驟三，將步驟二采集的進程信息piset，緩存起來，以供后續(xù)步驟需要時使用。

步驟四，當(dāng)協(xié)議棧的傳輸層模塊對tcp連接請求解析完成后，會構(gòu)造syn報文，發(fā)送到網(wǎng)絡(luò)層，即將命中hookto，hookto處理例程此時不會修改報文，而是提取出連接相關(guān)的信息，緩存后留待使用。

進一步的，所述步驟四，具體包括：

步驟a1，記錄的syn報文的目標ip、目標端口以及syn序號，將其緩存起來，記作連接信息集ciset。

步驟a2，針對本次連接會話，建立ciset與piset的映射關(guān)系，記作ciset->piset。

步驟a3，啟動一個定時器citimer，在連接超時后銷毀相關(guān)的ciset->piset數(shù)據(jù)。

步驟五，syn報文傳送至服務(wù)端，如果服務(wù)端強制要求驗證客戶端的piset，會發(fā)送帶有特定數(shù)據(jù)pireq的rst報文，復(fù)位連接，要求客戶端提供piset。pireq數(shù)據(jù)中，可能包括與piset封裝算法相關(guān)的參數(shù)。

步驟六，客戶端接收到服務(wù)器的rst報文后，會命中掛接點hookri，hookti處理例程會提取出其攜帶的pireq數(shù)據(jù)，并從中還原出原始syn報文的ciset，查找出對應(yīng)的piset后，構(gòu)造新的syn報文。

進一步的，所述步驟六，具體包括：

步驟b1，從rst報文的載荷數(shù)據(jù)中提取出pireq數(shù)據(jù)。

步驟b2，從rst報文的ip首部和tcp首部中還原出原始的ciset，即源ip，源端口號及ack序號(減一)。

步驟b3，由ciset查找到映射的進程信息piset。

步驟b4，構(gòu)造新的syn報文，根據(jù)pireq中要求的封裝算法，將piset轉(zhuǎn)換為字節(jié)數(shù)組，添加到syn報文的傳輸層數(shù)據(jù)。

步驟b5，重新計算tcp首部的校驗和。

步驟b6，如果需要，調(diào)整ip首部中的報文長度字段，并重新計算ip首部的校驗和。

步驟b7，丟棄此rst報文，不提交到傳輸層模塊，以保持連接過程。

步驟b8，銷毀ciset，關(guān)閉定時器。

步驟七，新syn報文傳送至服務(wù)端，服務(wù)端驗證報文中的piset后，應(yīng)答標準的syn+ack報文。

步驟八，客戶端接收到服務(wù)器應(yīng)答的syn+ack后，發(fā)送ack應(yīng)答。

至此，客戶端的處理流程完畢，在tcp連接階段實現(xiàn)客戶端信息的傳遞。

需要注意的是，公布實施例的目的在于幫助進一步理解本發(fā)明，但是本領(lǐng)域的技術(shù)人員可以理解：在不脫離本發(fā)明及所附權(quán)利要求的精神和范圍內(nèi)，各種替換和修改都是可能的。因此，本發(fā)明不應(yīng)局限于實施例所公開的內(nèi)容，本發(fā)明要求保護的范圍以權(quán)利要求書界定的范圍為準。