專利名稱：一種狀態(tài)跟蹤方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及操作系統(tǒng)中運用遠程過程調(diào)用協(xié)議領(lǐng)域，具體地說，涉及一種狀態(tài)跟蹤方法及系統(tǒng)。
背景技術(shù)：
主動防御是基于程序行為自主分析判斷的實時防護技術(shù)，不以特征碼作為判斷惡意程序的依據(jù)，而是從最原始的定義出發(fā)，直接將程序的行為作為判斷惡意程序的依據(jù)，其中衍生出在本地使用特征庫、在本地設(shè)置行為閾值以及在本地啟發(fā)式殺毒的方式來判別、攔截惡意程序的行為，從而一定程度上達到保護用戶個人電腦或計算機的目的?，F(xiàn)有的主動防御系統(tǒng)包括 l、HIPS(Host_based Intrusion Prevention System,基于主機的入侵防御系統(tǒng))、沙箱等防御型產(chǎn)品需要對危險操作進行攔截，但是windows操作系統(tǒng)十分靈活，有多種進程間通信(IPC, Inter-Process Communication)機制，一旦惡意代碼通過IPC利用系統(tǒng)進程來進行危險操作，那么對這種操作就難以攔截，需要改，而攔截惡意代碼是通過IPC向系統(tǒng)服務(wù)發(fā)出的惡意請求。尤其是RPC (Remote Procedure Call Protocol,遠程過程調(diào)用協(xié)議)方式就是最難以攔截的IPC機制之一。RPC是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。2、Windows操作系統(tǒng)下對RPC攔截需要識別發(fā)起請求的目的，即請求的是什么接口(含⑶ID (Global unique identifier,全局唯一標識符)標識)、什么函數(shù)、什么參數(shù)等內(nèi)容。Windows操作系統(tǒng)下RPC的載體有很多，例如本地過程調(diào)用(LPC)、命名管道(NamedPipe)、TCP/IP網(wǎng)絡(luò)等。在本機系統(tǒng)(不跨網(wǎng)絡(luò)時)上最常見的是LPC與NamedPipe?？蛻粝蚍?wù)器發(fā)起RPC請求首先會先對接口進行綁定(binding),隨后才能發(fā)出請求(Request)調(diào)用指定的程序(Procedure)(通過指明ProcNum或API number)。現(xiàn)有的RPC攔截都是針對請求(Request)階段的，即只能獲得ProcNum和參數(shù)，并不能獲得⑶ID標識(這時僅能獲得由binding時的數(shù)字標識)，這樣就難以獲得完整的請求信息。現(xiàn)有技術(shù)中，針對RPC攔截(狀態(tài)跟蹤)僅僅知道ProcNum和參數(shù)，然后根據(jù)一些條件(如port名稱、棧回朔參數(shù)等內(nèi)容)去猜測來判斷客戶端發(fā)送的是否為惡意的請求程序是不準確的。RPC采用客戶端/服務(wù)器模式，實際上請求程序就是一個客戶端，而服務(wù)提供程序就是一個服務(wù)器。首先，客戶端調(diào)用進程發(fā)送一個有進程參數(shù)的調(diào)用信息到服務(wù)進程，然后等待答復(fù)信息。在服務(wù)器端，服務(wù)進程保持睡眠狀態(tài)直到調(diào)用信息的到達為止。當一個調(diào)用信息到達，服務(wù)器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個調(diào)用信息，最后，客戶端調(diào)用進程接收答復(fù)信息，獲得進程結(jié)果，然后調(diào)用信息繼續(xù)進行。
所以當客戶端為一惡意的請求程序，調(diào)用服務(wù)器完成惡意操作時，攔截程序(狀態(tài)跟蹤程序)在調(diào)用階段介入攔截，攔截獲得調(diào)用參數(shù)，但是現(xiàn)有技術(shù)中并不知道調(diào)用過程中所使用的調(diào)用指令的含義，所以也無從知曉這個調(diào)用指令是要執(zhí)行什么操作，也就不能判斷出操作是否為惡意。現(xiàn)在技術(shù)中，可以根據(jù)攔截程序在調(diào)用階段介入攔截到的一些其它信息，去猜測調(diào)用指令的含義，當調(diào)用指令僅涉及少量函數(shù)功能時，這種猜測是具備一定操作基礎(chǔ)的。但是往往一個調(diào)用指令中會涉及很多個功能，此時根據(jù)一個調(diào)用指令無法準備獲知客戶端具體要調(diào)用服務(wù)器完成什么操作。綜上所述，如何準確地獲取客戶端與服務(wù)器之間進行RPC調(diào)用時，調(diào)用的接口和函數(shù)號的準確含義，從而就可以判定客戶端發(fā)送的是否為惡意的請求程序，這樣就能夠進行防御操作，所以上述問題便成為亟待解決的技術(shù)問題。

發(fā)明內(nèi)容
鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決或者減緩上述問題的一種狀態(tài)跟蹤方法及系統(tǒng)。根據(jù)本發(fā)明的一個方面，提供了一種狀態(tài)跟蹤方法，用于遠程過程調(diào)用協(xié)議，其包括攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則；當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為；其中，攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，還包括攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的請求和響應(yīng)的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，其中所述調(diào)用規(guī)則包括接口及所配置的接口的代號的對應(yīng)關(guān)系和/或，所述接口中包括的各應(yīng)用程序編碼接口及所配置的接口標識的對應(yīng)關(guān)系。進一步地，其中，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，還包括根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，通過判斷所述業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業(yè)務(wù)行為為正常，繼續(xù)監(jiān)測下一請求或響應(yīng)的數(shù)據(jù)包；如判定所述業(yè)務(wù)行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數(shù)據(jù)包。進一步地，其中，當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令，還包括當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；其中，所述數(shù)據(jù)包為本地過程調(diào)用的請求報文，所述調(diào)用指令攜帶接口的代號和/或接口標識。
進一步地，其中，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，還包括根據(jù)所述調(diào)用規(guī)則，對該調(diào)用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調(diào)用的接口和函數(shù)。進一步地，其中，所述數(shù)據(jù)包為采用本地過程調(diào)用、命名管道、UDP協(xié)議網(wǎng)絡(luò)消息或TCP/IP網(wǎng)絡(luò)消息的數(shù)據(jù)包。進一步地，其中，所述調(diào)用規(guī)則，包括所述調(diào)用指令與業(yè)務(wù)行為的對應(yīng)關(guān)系；所述調(diào)用指令，包括服務(wù)器根據(jù)客戶端的請求所配置的接口的代號、以及服務(wù)器為接口中包含的應(yīng)用程序編碼接口配置的接口標識；所述業(yè)務(wù)行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應(yīng)用程序編碼接口。進一步地,其中，所述接口的代號為通過表達上下文字段PresentationContext來表示；所述接口標識為通過函數(shù)號ProcNum來表示。根據(jù)本發(fā)明的一個方面，還提供了一種狀態(tài)跟蹤系統(tǒng)，用于遠程過程調(diào)用協(xié)議，其包括攔截模塊、監(jiān)測模塊和判斷模塊；其中，所述攔截模塊，用于攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則；所述監(jiān)測模塊，用于當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；

判斷模塊，用于根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為；其中，所述攔截模塊還用于攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的請求和響應(yīng)的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，其中所述調(diào)用規(guī)則包括接口及所配置的接口的代號的對應(yīng)關(guān)系，和/或，所述接口中包括的各應(yīng)用程序編碼接口及所配置的接口標識的對應(yīng)關(guān)系。進一步地，其中，所述判斷模塊，還用于根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，通過判斷所述業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業(yè)務(wù)行為為正常，繼續(xù)監(jiān)測下一請求或響應(yīng)的數(shù)據(jù)包；如判定所述業(yè)務(wù)行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數(shù)據(jù)包。進一步地，其中，所述監(jiān)測模塊，還用于當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；其中，所述數(shù)據(jù)包為本地過程調(diào)用的請求報文，所述調(diào)用指令攜帶接口的代號和/或接口標識。進一步地，其中，所述判斷模塊，還用于根據(jù)所述調(diào)用規(guī)則，對該調(diào)用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調(diào)用的接口和函數(shù)。進一步地，其中，所述數(shù)據(jù)包為采用本地過程調(diào)用、命名管道、UDP協(xié)議網(wǎng)絡(luò)消息或TCP/IP網(wǎng)絡(luò)消息的數(shù)據(jù)包。進一步地，其中，所述調(diào)用規(guī)則，包括所述調(diào)用指令與業(yè)務(wù)行為的對應(yīng)關(guān)系；所述調(diào)用指令，包括服務(wù)器根據(jù)客戶端的請求所配置的接口的代號、以及服務(wù)器為接口中包含的應(yīng)用程序編碼接口配置的接口標識；所述業(yè)務(wù)行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應(yīng)用程序編碼接口。
進一步地,其中，所述接口的代號為通過表達上下文字段PresentationContext來表示；所述接口標識為通過函數(shù)號ProcNum來表示。與現(xiàn)有的方案相比，本發(fā)明所獲得的技術(shù)效果I)完全準確地獲取客戶端與服務(wù)器之間進行RPC調(diào)用時，調(diào)用的接口和函數(shù)號的準確含義，從而還可以判定是否為惡意程序；2)通過本發(fā)明能夠進行有效的防御操作，從而避免惡意請求程序的攻擊，達到保護用戶個人電腦或計算機的目的。上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式
。


通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中圖1示意性示出了客戶端與服務(wù)器在發(fā)生運用遠程過程調(diào)用協(xié)議調(diào)用之前預(yù)先進行綁定的過程流程
圖2示意性示出了根據(jù)本發(fā)明一個實施例所述狀態(tài)跟蹤方法流程圖；圖3是示意性示出了根據(jù)本發(fā)明另一個實施例所述狀態(tài)跟蹤方法流程圖；圖4示意性示出了根據(jù)本發(fā)明一個實施例所述狀態(tài)跟蹤系統(tǒng)結(jié)構(gòu)框圖。
具體實施例方式下面結(jié)合附圖和具體的實施方式對本發(fā)明作進一步的描述。如圖1所示，在客戶端與服務(wù)器之間發(fā)生RPC調(diào)用之前，會預(yù)先進行綁定(binding),其過程為步驟101，客戶端向服務(wù)器發(fā)送綁定請求，告知服務(wù)器自己要使用哪個Interface(接口);其中，每個Interface劃分出一類服務(wù)函數(shù)集合。所謂Interface是面向?qū)ο缶幊陶Z言中接口操作的關(guān)鍵字，功能是把所需成員組合起來，以封裝一定功能的接口 ；步驟102,服務(wù)器為Interface配置一個ID,并為這個Interface所包括的所有API (Application Programming Interface,應(yīng)用程序編程接口)均配置一個標識 number ;其中，該Interface可能包含一個或多個的API，完成各種功能；這里因為Interface可能是一個非常復(fù)雜而且冗長的名字，因此配置一個簡單的標識ID以方便之后的交互，而且標識ID也更為機器可讀，API number也是同理，即API (ApplicationProgramming Interface,應(yīng)用程序編程接口)的編號；步驟103，服務(wù)器向客戶端發(fā)送綁定請求的響應(yīng)，告知客戶端所配置的Interface的標識ID以及API的編號(即API number)；步驟104，客戶端記錄Interface對應(yīng)的標識ID以及API對應(yīng)的編號(APInumber)；步驟105，客戶端向服務(wù)器發(fā)送ID和API number，從而告知服務(wù)器自己需要調(diào)用哪個接口的哪個函數(shù)；此時因為步驟102已經(jīng)完成配置約定，所以客戶端僅向服務(wù)器發(fā)送ID和APInumber 即可；步驟106，服務(wù)器解析ID和API number，從而獲知客戶端需要調(diào)用地端口和函數(shù)，也即哪個接口的哪個函數(shù)?，F(xiàn)有技術(shù)中RPC攔截都是針對步驟105之后的階段，僅僅能夠捕獲ProcNum，并沒有捕獲請求過程中對于RPC狀態(tài)追蹤有用的完整的請求信息，比如PresentationContext ；其中 ProcNum 即接口編號 API number 中的一種，PresentationContext是表征一個接口的代號(句柄)，其他人拿到這個句柄并不知道其含義(即代表哪個接口)，所以只能去進行推測或者猜或是?；厮愤M行猜。因此現(xiàn)有技術(shù)只能利用不完整的捕獲信息ProcNum，根據(jù)如port名稱、?；厮穮?shù)等去猜測捕獲到的ProcNum的含義，狀態(tài)分析的準確性相對較低。而本發(fā)明首先確認了 PresentationContext參數(shù)對于解析所追蹤的狀態(tài)的重要意義，追蹤了上述的整個過程(主要是之前的綁定過程)，通過監(jiān)控請求的通訊過程捕獲完整的請求信息，所以可以清楚的解釋這個句柄代表了哪個接口。這樣通過監(jiān)控請求的通訊過程捕獲完整的請求信息從而完全掌握PresentationContext和ProcNum的含義,保證了狀態(tài)分析的準確性。

如圖2所示，本發(fā)明一個實施例所述的狀態(tài)跟蹤方法，其中，該方法包括步驟201，攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則；步驟202，當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；步驟203，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為。如圖3所示，為了實現(xiàn)本發(fā)明所要解決的技術(shù)問題，同時通過判斷業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意，本發(fā)明另一個實施例所述的方法，包括步驟301，攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則；步驟302，當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；步驟303，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，通過判斷所述業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業(yè)務(wù)行為為正常，繼續(xù)監(jiān)測下一請求或響應(yīng)的數(shù)據(jù)包；如判定所述業(yè)務(wù)行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數(shù)據(jù)包。如下以一個基于LPC (本地過程調(diào)用)媒介(數(shù)據(jù)包)的RPC部分數(shù)據(jù)包格式(本地過程調(diào)用的請求報文LPC_REQUEST_MESSAGE)為例，在Vista系統(tǒng)中的一些系統(tǒng)數(shù)據(jù)包定義，說明采用上述實施例所述的狀態(tài)跟蹤方法中“根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為”這個操作過程，請注意看里面的開頭都是LPC_PACKET_HEADER，而這個結(jié)構(gòu)的開頭又是一個標準的PORT_MESSAGE (LPC消息包頭)。

權(quán)利要求
1.一種狀態(tài)跟蹤方法，用于遠程過程調(diào)用協(xié)議，包括 攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則； 當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令； 根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為； 其中，攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，還包括 攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的請求和響應(yīng)的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，其中所述調(diào)用規(guī)則包括接口及所配置的接口的代號的對應(yīng)關(guān)系，和/或，所述接口中包括的各應(yīng)用程序編碼接口及所配置的接口標識的對應(yīng)關(guān)系。
2.如權(quán)利要求1所述的狀態(tài)跟蹤方法，其特征在于，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，還包括 根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，通過判斷所述業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意； 如判定所述業(yè)務(wù)行為為正常，繼續(xù)監(jiān)測下一請求或響應(yīng)的數(shù)據(jù)包；如判定所述業(yè)務(wù)行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數(shù)據(jù)包。
3.如權(quán)利要求1或2所述的狀態(tài)跟蹤方法，其特征在于，當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令，還包括 當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；其中，所述數(shù)據(jù)包為本地過程調(diào)用的請求報文，所述調(diào)用指令攜帶接口的代號和/或接口標識。
4.如權(quán)利要求3所述的狀態(tài)跟蹤方法，其特征在于，根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，還包括 根據(jù)所述調(diào)用規(guī)則，對該調(diào)用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調(diào)用的接口和函數(shù)。
5.如權(quán)利要求1至2中任一所述的狀態(tài)跟蹤方法，其特征在于，所述數(shù)據(jù)包為采用本地過程調(diào)用、命名管道、UDP協(xié)議網(wǎng)絡(luò)消息或TCP/IP網(wǎng)絡(luò)消息的數(shù)據(jù)包。
6.如權(quán)利要求1所述的狀態(tài)跟蹤方法，其中， 所述調(diào)用規(guī)則，包括所述調(diào)用指令與業(yè)務(wù)行為的對應(yīng)關(guān)系； 所述調(diào)用指令，包括服務(wù)器根據(jù)客戶端的請求所配置的接口的代號、以及服務(wù)器為接口中包含的應(yīng)用程序編碼接口配置的接口標識； 所述業(yè)務(wù)行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應(yīng)用程序編碼接口。
7.如權(quán)利要求1或2或6所述的狀態(tài)跟蹤方法，其中， 所述接口的代號為表達上下文字段PresentationContext ； 所述接口標識為函數(shù)號ProcNum。
8.一種狀態(tài)跟蹤系統(tǒng)，用于遠程過程調(diào)用協(xié)議，包括攔截模塊、監(jiān)測模塊和判斷模塊;其中， 所述攔截模塊，用于攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則； 所述監(jiān)測模塊，用于當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令； 判斷模塊，用于根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為； 其中，所述攔截模塊還用于 攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的請求和響應(yīng)的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，其中所述調(diào)用規(guī)則包括接口及所配置的接口的代號的對應(yīng)關(guān)系，和/或，所述接口中包括的各應(yīng)用程序編碼接口及所配置的接口標識的對應(yīng)關(guān)系。
9.如權(quán)利要求8所述的狀態(tài)跟蹤系統(tǒng)，其特征在于， 所述判斷模塊，還用于根據(jù)所述調(diào)用規(guī)則判斷該調(diào)用指令所完成的業(yè)務(wù)行為，通過判斷所述業(yè)務(wù)行為是否為惡意來判定所述客戶端進程是否為惡意； 如判定所述業(yè)務(wù)行為為正常，繼續(xù)監(jiān)測下一請求或響應(yīng)的數(shù)據(jù)包；如判定所述業(yè)務(wù)行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數(shù)據(jù)包。
10.如權(quán)利要求8或9所述的狀態(tài)跟蹤系統(tǒng)，其特征在于，所述監(jiān)測模塊，還用于 當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；其中，所述數(shù)據(jù)包為本地過程調(diào)用的請求報文，所述調(diào)用指令攜帶接口的代號和/或接口標識。
11.如權(quán)利要求10所述的狀態(tài)跟蹤系統(tǒng)，其特征在于，所述判斷模塊，還用于 根據(jù)所述調(diào)用規(guī)則，對該調(diào)用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調(diào)用的接口和函數(shù)。
12.如權(quán)利要求8至9中任一所述的狀態(tài)跟蹤系統(tǒng)，其特征在于，所述數(shù)據(jù)包為采用本地過程調(diào)用、命名管道、UDP協(xié)議網(wǎng)絡(luò)消息或TCP/IP網(wǎng)絡(luò)消息的數(shù)據(jù)包。
13.如權(quán)利要求8所述的狀態(tài)跟蹤系統(tǒng)，其特征在于， 所述調(diào)用規(guī)則，包括所述調(diào)用指令與業(yè)務(wù)行為的對應(yīng)關(guān)系； 所述調(diào)用指令，包括服務(wù)器根據(jù)客戶端的請求所配置的接口的代號、以及服務(wù)器為接口中包含的應(yīng)用程序編碼接口配置的接口標識； 所述業(yè)務(wù)行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應(yīng)用程序編碼接口。
14.如權(quán)利要求8或9或13所述的狀態(tài)跟蹤系統(tǒng)，其特征在于， 所述接口的代號為表達上下文字段PresentationContext ； 所述接口標識為函數(shù)號ProcNum。
全文摘要
本發(fā)明公開了狀態(tài)跟蹤方法及系統(tǒng)，其中，該系統(tǒng)包括攔截模塊、監(jiān)測模塊和判斷模塊；其中，所述攔截模塊還用于攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的請求和響應(yīng)的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則，其中所述調(diào)用規(guī)則包括接口及所配置的接口的代號的對應(yīng)關(guān)系，和/或，所述接口中包括的各應(yīng)用程序編碼接口及所配置的接口標識的對應(yīng)關(guān)系。本發(fā)明解決了在現(xiàn)有客戶端與服務(wù)器之間進行RPC調(diào)用時，獲取調(diào)用的接口和函數(shù)號的準確含義。
文檔編號H04L29/06GK103036895SQ20121055998
公開日2013年4月10日 申請日期2012年12月20日 優(yōu)先權(quán)日2012年12月20日
發(fā)明者潘劍鋒, 王宇 申請人:北京奇虎科技有限公司, 奇智軟件(北京)有限公司