即時通訊軟件文件傳輸審計系統的研究與實現

(中南大學 信息科學與工程學院，湖南 長沙，410083)

隨著互聯網的發展，即時通訊軟件(IM)以實時性強、反饋速度快、費用低廉等優點風靡全球，受到廣大網民的喜歡[1]。即時通信服務處于開放的網絡環境下，是一種公共服務，在為企業及個人帶來高效便捷通信的同時，也帶來來自公眾網絡的信息干擾，存在影響工作效率甚至信息安全的隱患，因此，對 IM進行管理和控制具有重要意義[2]。針對即時通訊軟件的監控問題，理論上已有一些研究成果。Lin[3]研究分析IM的特征和行為模式，并基于此提出使用支持向量機阻斷IM的方法。Xiao等[4]在對IM流量特征分析的基礎上提出利用IM的流量特征實現對IM的監控。Liu等[5]研究阻斷 IM 垃圾廣告和可能引起的拒絕服務問題。Kim等[6]首先采用風險分析的方法對 IM 的安全功能需求進行分析，然后制定IM 的安全策略，并設計和實現一個即時通訊軟件實時監控系統Messenger-i。黃紅桃等[7]設計并實現基于MSN協議的網絡行為審計系統，對基于 MSN協議傳輸的文件審計還原。付安民等[8]在對IM協議分析的基礎上，設計實現即時通監控系統。文獻[9]中對IM文件傳輸協議分析不完備，無法實現對QQ文件傳輸的審計。與此同時，國內外市場上均出現對即時通訊軟件監控的工具。國外的監控產品有 McAfee公司開發的 McAfee Wireless Protection和Symantec公司開發的Symantec IM Manager等。國內市場上也出現一系列針對即時通訊軟件進行監控的軟件，如揚州安達信源網絡科技有限公司的“第三只眼”、上海百絡信息技術有限公司的百絡網警、同易信息技本有限公司開發的同易企業監控軟件等。這些軟件可以實現對QQ和MSN等IM聊天內容的監控，記錄聊天行為。綜上可知，盡管對IM監控的研究及產品比較豐富，但目前對即時通訊軟件的監控仍然存在以下問題：

(1) 對即時通訊軟件監控的研究基本都集中在文本信息(實時聊天信息)方面，而很少研究即時通訊文件傳輸監控。

(2) 現有的監控系統幾乎只能對ICQ，MSN等少數國外的即時通訊軟件進行監控，而對國內廣泛使用的IM如：騰訊QQ、中國移動飛信等無能為力。

(3) 即時通訊軟件更新速度快，因此對其的監控還面臨著IM升級和加入新型即時通訊軟件的問題。

因此，深入分析即時通訊軟件文件傳輸的通信協議，并能準確高效地對使用即時通訊軟件傳輸的文件進行審計很有意義。本文作者對多種IM(QQ，Fetion，MSN和雅虎通等)文件傳輸協議進行分析，設計并實現IM文件傳輸審計系統FAudit，對即時通用戶的文件傳輸行為進行審計，包括用戶信息、文件大小及具體的文件內容等信息。該系統具有良好的擴展性、健壯性等性能特性，可以實現對 IM 各類文件(DOC，PDF，TXT和視頻等)傳輸的審計。

1 IM文件傳輸協議分析

雖然互聯網工作任務組(IETF)制定的標準即時通信協議有IMPP[9]，SIMPLE[10]及XMPP[11]3個國際協議，但目前市場上常用的即時通訊軟件如QQ，Fetion，MSN和雅虎通等并未完全遵守這些標準，而是使用自己的私有協議進行文件傳輸。因此，對各個即時通信協議進行分析，建立系統特征庫，是FAudit實現的前提，也是重點和難點。

通過搭建協議分析環境，根據主流即時通通信數據明文傳輸的特點，在局域網內部及網間有目的、大量重復的發送包含特殊字符(如文件內容全為 1)的文件，采用逆推的方法，比較應用層數據中固定字節或者規律性字節的含義[12]，總結出 QQ，Fetion，MSN和雅虎通4種主流即時通訊軟件，當前使用的多種版本完整詳細的文件傳輸協議基本特征信息。表1所示為4種IM文件傳輸協議的基本特征。從表1可知：目前國內廣泛使用的幾個 IM軟件文件傳輸時傳輸層采用TCP或UDP協議，通信模式采用C/S或P2P的方式。

如前所述，各個 IM使用完全不同的協議，協議格式差別很大，因此，不可能總結出 IM的通用協議格式。這里，本文只以QQ文件傳輸為例進行分析，其他IM協議格式分析方法類似。

QQ文件傳輸模式主要有UDP方式，TCP直連及TCP中轉。TCP直連常見于臨近網絡(局域網絡內)傳送文件，這種模式傳輸速度快；UDP方式與 TCP中轉傳輸方式主要存在于廣域網中。2010SP1版本之后QQ又增加離線文件傳輸功能，可以在接收方離線的情況下，傳輸QQ文件。

表1 幾種主流IM文件傳輸協議對照表Table 1 Files transfer protocol of mainstream IM

QQ每種傳輸方式的數據包格式均不相同，不同版本的數據包格式也不相同。根據應用層協議特征的不同，可以將QQ傳文件的數據包分為4類：初始包(包含有應用識別QQ傳文件的特征和QQ號碼)、文件名包(包含文件名，文件長度等)、文件內容中間包(傳輸文件內容)以及文件內容結束包(標識文件傳輸結束)。

(1) 初始包。QQ文件傳輸的初始數據包包含QQ文件傳輸流識別特征和QQ號碼等信息。圖1所示為使用2009版本、UDP傳輸方式的初始數據包，該數據包大小為27 B，圖中加下劃線的部分識別特征，其中0x04代表傳輸方式為UDP，最后4字節為發送方QQ號。接收方回復數據包格式如圖2所示，前4字節代表應用層識別特征，最后 4字節為接收方 QQ號碼。

圖1 QQ初始數據包協議特征1Fig.1 Initial packet characteristics of sender

圖2 QQ初始數據包協議特征2Fig.2 Initial packet characteristics of receiver

(2) 文件名包。文件名數據包包含文件名、文件長度等信息。QQ文件名使用Unicode或GBK編碼后進行傳輸。圖3所示為QQ2009使用TCP直連進行文件傳輸時文件名數據包的格式。該數據中 0x12位置處出現的“0x58 0x58”是文件名數據包的識別特征。后面4字節是文件傳輸次數信息。之后的黑體斜體部分表示文件大小，再之后為文件名(最后一個黑體斜體部分)，這里文件名使用Unicode編碼方式，以0x00結束。

(3) 文件內容包中間包。文件內容中間包用于傳輸文件的具體內容，包括包識別特征、文件內容以及數據包序號信息。值得說明的是：在文件傳輸過程中，由于網絡丟包等各方面的原因，可能導致數據包亂序，這里的數據包序號信息保證文件內容審計的正確性。

圖3 QQ文件名數據包協議特征Fig.3 Characteristics of file name packet

圖4所示為QQ2009使用TCP直連傳輸文件內容的數據包的格式特征，其中偏移應用程序0x5處的“0x44 0x44”是命令號，表明該數據包為傳輸QQ文件內容的數據包，接下來的4位表示該文件被傳輸的次數，再接下來的 4位為傳輸的內容包的包序號，這里0x00000000表示該包為QQ文件內容傳輸的第1個數據包。

圖4 QQ文件內容中間包協議特征Fig.4 Characteristics of file content packet

(4) 文件內容結束包。該包為文件內容的最后一個數據包。這種數據包包含包識別特征及文件剩余長度信息。圖5所示為QQ2009 UDP方式傳輸時文件內容結束包特征，偏移應用程序 0x10位置處的 0x45 0x48是文件內容結束包的命令字段，標識此包結束后，文件內容已經傳輸完畢。命令號后面的 4位0x00000080表示當前包中文件內容的大小。

此外，QQ 2010SP1版本增加離線文件傳輸功能，QQ離線傳輸基于HTTP協議實現，以明文方式傳輸。在離線傳輸的初始包中不僅包含包識別特征，亦包含文件名信息，傳輸文件大小及當前傳輸的字節數信息。

圖5 QQ文件內容結束包協議特征Fig.5 Characteristics of last content packet

2 系統設計

2.1 FAudit網絡部署

系統詳細的網絡結構如圖6所示，FAudit部署在被監控局域網內任何1臺主機上，在交換機上使用端口映射或其他方式使得安裝有FAudit的計算機可以捕獲流入流出局域網或者在局域網內傳遞的所有網絡數據包。

圖6 系統網絡拓撲Fig.6 Network topology of system

2.2 FAudit系統結構

系統總體實現流程如圖7所示，FAudit包括數據采集存儲模塊、協議分析處理模塊及文件重組還原模塊。

2.2.1 數據采集處理模塊

數據采集處理模塊主要實現網絡數據包的捕獲及保存，系統在Linux平臺下使用Libpcap+PF_RING的方式實現網絡數據包的捕獲。Libpcap是一個與系統無關的網絡數據捕獲函數庫，它繞過 TCP層(UDP層)和IP層的處理過程，直接將數據包從數據鏈路層拷貝到應用程序緩沖區中，比傳統的Raw socket方式處理效率要高得多，并且避免 SOCKET_PACKET只在基于 Linux的操作系統中有效定義的問題。但對于Libpcap來講，傳統的處理有很多時間都消耗在系統調用、中斷、PCI總線帶寬以及內存拷貝上，而內存拷貝是在 LIBPCAP中占用處理時間最長的過程。通常1個數據包被用戶空間應用程序處理需要2次內存拷貝：一次是從網卡緩沖區到系統內核緩沖區，另一次

圖7 系統總體實現流程Fig.7 Structure and implementation process of system

是從內核緩沖區到用戶。應用程序每次對1 024 B內存的拷貝時問大約為 l μs[13]。為解決這問題，根據PF_RING對Libpcap接口原理，通過2層封裝實現該接口。PF_RING機制是Luca Deri在零拷貝的基礎上提出的。PF_RING機制不必修改網卡驅動。在內核中，它以一種帶緩存的協議簇 PF RING為依托，結合NAPI技術，改善網卡中斷響應頻率；在用戶空間，應用程序可以通過 MMAP手段，將網絡數據包直接傳送給應用層的用戶程序，提高系統性能。

2.2.2 協議分析處理模塊

協議分析模塊的目標是對捕獲的網絡數據包進行解析，層層解析后提取應用層數據。

利用 PCAP抓包類，可以在網絡上抓到符合TCP/IP協議棧結構的數據包，得到指向包頭的指針。通過指針偏移的定位(標準的數據包偏移54 B)，對網絡數據包進行解析，剝離以太網頭部、IP頭、TCP頭(UDP頭)得到應用層數據。

通過大量重復實驗分析發現：IM 文件傳輸使用TCP或 UDP協議實現。換而言之，系統需要的網絡數據包為IP包。系統協議分析過程為：數據鏈路層只分析以太網協議。根據以太網協議內容的分析結果，判斷以太網類型的值：0x0800，表示協議為IP協議，對其深入分析。在分析IP協議時，根據協議類型的值判斷傳輸層協議類型：如果IP協議類型字段的值為6或17，表示傳輸層協議為TCP或UDP，根據傳輸層協議特征，將指針偏移，提取應用層數據，然后，根據即時通文件傳輸協議特征匹配應用層數據，提取文件信息。

2.2.3 文件重組還原模塊

圖8所示為文件重組還原模塊處理流程。文件重組還原模塊是 FAudit的核心模塊，采用深度包檢測技術，實現基于TCP協議、UDP協議傳輸的文件屬性信息(文件名、文件大小)及文件內容信息的審計還原[14]。IM文件審計需首先識別標記出IM文件傳輸所在流(源、目的IP，源、目的端口)，在此基礎上通過讀取匹配數據庫中的協議特征，識別文件名包，提取文件屬性信息(文件大小、文件名等信息)，最后提取文件內容信息，對文件內容重組還原。識別1條文件傳輸流時將該流狀態設置為INITED，等待文件名數據數據包的到來，提取文件名信息后，等文件內容數據包的到來，對文件內容重組還原，審計得到原文件。

圖8 文件重組還原模塊處理流程Fig.8 Process of file reorganization module

3 關鍵技術

3.1 數據包捕獲

為提高高速復雜網絡傳輸環境中的數據包捕獲效率，系統使用一種新型的數據包捕獲方式，即基于PF_RING套接字的數據包捕獲技術。PF_RING 技術融合設備輪詢機制、NAPI技術和零拷貝技術，使用環形緩沖區，用來實現內核空間和用戶空間的內存共享。通過PF_RING 技術，即使1臺常規PC 機也能在千兆網絡環境下捕獲所有數據而不產生丟包。PF_RING 以通用性為目標，提供套接口封裝函數和Libpcap接口。重新編譯安裝PF_RING補丁的Libpcap后，加載 PF_RING內核模塊，就可以通過Socket/Libpcap接口使用PF_RING。

3.2 數據包解析

在數據包解析過程中，為提高驅動程序的效率，要盡早丟棄非目標數據包。對于每一個數據包，算法如下：

(1) 檢查是否是IP 協數據包，不是則對此包不做處理；

(2) 進一步檢查是否是TCP或者UDP 數據包，不是則對此包不做處理；

(3) 根據相應的IM協議，采用深度包檢測技術匹配應用層數據，提取文件信息，審計還原文件。若匹配不成功，則對此包不做處理。

對于具體的IM 包在解析時，將不同的編碼轉換為可顯示打印的ASCII 字符。一般IM 包解析后包括的信息有源IP 原地址和端口號、目標IP 地址和端口號、數據包長度和消息內容等。

3.3 深度包檢測

深度包檢測[15]是相對傳統包檢測技術而言的。傳統包檢測技術主要檢測OSI模型中網絡層及傳輸層的數據，通常是傳輸層的TCP頭和網絡層的IP頭。系統審計的4種IM軟件QQ，Fetion，MSN及雅虎通文件傳輸并非采用固定端口實現。因此，要正確高效的審計 IM 傳輸的文件，必須進行深度包檢測。FAudit在大量測試分析獲得即時通訊軟件文件傳輸應用特征分析的基礎上，對應用層有效載荷匹配分析，提取文件信息。

采用深度包檢測技術，可以大幅度提升系統性能，使系統獲得更高效率的同時，能夠滿足復雜的安全策略和高可用性要求。

4 系統測試

為對FAudit的性能進行分析，以QQ2010 SP2為例，測試FAudit使用各種傳輸方式在各種網絡環境下文件傳輸性能。測試功能點包括：普通文件傳輸、多文件傳輸、斷點續傳、離線文件傳輸及網絡異常情況下文件傳輸性能。

圖9 測試環境網絡拓撲圖Fig.9 Network topology of simulation environment

為保證網絡測試環境的可控性與可再現性，本文選擇在實驗室搭建的網絡實驗測試床與實際測試相結合的方式進行。測試床實驗的網絡拓撲如圖9所示，2臺計算機部署在不同的子網之間，中間通過專用的廣域網模擬器WANem連接。廣域網模擬器對網絡參數如帶寬、網絡速度、丟包率等進行設置來模擬真實的廣域網環境。在實驗中，本文將初始帶寬設置為 10 Mb/s，往返時延(RTT)設置為100 ms，來模擬現實中的廣域網網絡環境。在測試過程中，對帶寬、丟包率等參數進行梯度設置，直至網速限制在6 kB/s左右，丟包率為10%左右。測試過程中，對文件大小及文件類型不予限制，但測試離線文件傳輸方式限制文件大小最大為20 MB(QQ支持的最大的離線傳輸文件的大小)。當在局域網內測試 FAudit性能時，使用真實網絡。局域網環境中，默認情況丟包0%，延時低于5 ms。

測試的文件類型包括DOC,PDF，RAR，ZIP，EXE，PNG和ISP等22種文件類型，傳輸的文件最大值為37 566 kB，最小為1 kB。測試結果如表2所示。在局域網環境中，QQ使用TCP直連方式進行文件傳輸，廣域網環境中使用UDP或者TCP中轉方式實現。從測試結果可知：FAudit幾乎可以在任何的網絡環境下完全正確的審計文件。但當速度限制到10 kB/S、丟包率為10%時，發現1個文件基于IP傳輸，并且使用UDP協議，但沒有 UDP頭，分析發現是抓包工具LIBPCAP的問題，導致審計出來的內容不完整。由于這種現象的不可重復性，系統對此未作處理。

表2 模擬廣域網環境實驗床測試結果Table 2 Simulation results based on WANem

5 結論

(1) 在對即時通訊軟件文件傳輸應用層特征分析的基礎上，對即時通訊文件審計系統提出有效、可行的設計方案，并基于此，在Linux平臺下實現一個功能完備、性能良好、可擴展的 IM 文件審計系統(FAudit)。

(2) FAudit在各種網絡環境下都能夠對IM傳輸的各類文件(DOC，ODF，TXT和視頻等)進行有效審計。

(3) FAudit具有良好的可擴展性。IM軟件升級頻繁，同時由于 IM市場巨大，依然不斷有新的廠商推出新型IM，對于這種IM的監控只需要通過協議研究和分析，總結出新型或者升級的IM協議格式和特征，并生成新的監控規則，然后添加到系統規則庫中，就能方便地實現對這類IM的監控。

[1] 李遠杰, 劉渭鋒, 張玉清, 等. 主流即時通信軟件通信協議分析[J]. 計算機應用研究, 2005, 22(7): 243?245.LI Yuan-jie, LIU Wei-feng, ZHANG Yu-qing, et al. Analysis of text message transmitting protocol in popular instant messenger software[J]. Application Research of Computers, 2005, 22(7):243?245.

[2] O’Sullivan S. Instant messaging vs. instant compromise[J].Network Security, 2006(7): 4?6.

[3] LIN Chun-kuan. A study of monitoring technologies in instant messenger[EB/OL]. [2011?06?15]. http://thesis.lib.ncu.edu.tw/ETD-db/ETD-search/getfile?URN=93523042&filename=93523042.pdf.

[4] Xiao Z, Guo L, Tracey J. Understanding instant messaging traffic characteristics[C]//Proc of 27th International Conference on Dislfibuted Computing Systems. Toronto: IEEE Press, 2007:51?58.

[5] LIU Zhi-jun, LIN Wei-li, LI na, et al. Detecting and filtering instant messaging sparn-a global and personalized approach[C]//Proc of 1st/EEE ICNP Workshop on Secure Network Protocols.Boston, USA: IEEE Press, 2005: 9?24.

[6] Kim S. Implementation of the security system for instant messengers[J]. Journal of Systems and Software, 2007, 80(10):1590?1593.

[7] 黃紅桃, 彭宏, 吳健培, 等. 基于 MSN 協議的網絡行為審計系統的設計與實現[J]. 計算機工程, 2007, 33(15): 255?257.HUANG Hong-tao, PENG Hong, WU Jian-pei, et al. Design and implementation of network behavior audit system based on MSN protocol[J]. Computer Engineering, 2007, 33(15): 255?257.

[8] 付安民, 張玉清. 即時通實時監控系統的設計與實現[J]. 通信學報, 2008, 29(10): 165?172.FU An-min, ZHANG Yu-qing. Design and realization of the real-time monitoring system for instant messenger[J]. Journal on Communications, 2008, 29(10): 165?172.

[9] Day M, Rosenberg J, Sugano H. RFC2778: A model for presence and instant messaging[S].

[10] 馬嚴. IPV6下基于SIP/SIMPLE協議IM的研究與實現[D]. 北京: 北京郵電大學計算機學院, 2009: 5?42.MA Yan. SIP/SIMPLE protocol based IM research and implementation under IPV6[D]. Beijing: Beijing University of Posts and Telecommunication. School of Computer Science,2009: 5?42.

[11] RFC 3921, Extensible messaging and presence protocol (XMPP):Instant messaging and presence[S].

[12] Jennings R B, Nahum E M, Olshefski D P, et al. A study of internet instant messaging and chat protocols[J]. IEEE Network,2006, 20(7): 16?21.

[13] 楊建華, 謝高崗, 李忠誠. 基于Linux內核的流量分析方法[J].計算機工程, 2006, 32(8): 67?69.YANG Jian-hua, XIE Gao-gang, LI Zhong-cheng. Linux kernel-based traffic analysis method[J]. Computer Engineering,2006, 32(8): 67?69.

[14] Leung K C, V.o.k. L, YANG Dai-qin. An overview of packet reordering in transmission control protocol (TCP): Problems,solutions, and challenges[J]. IEEE Transactions on Parallel and Distributed Systems, 2007, 18(4): 522?535.

[15] Kumar S, Turner J, Williams J. Advanced algorithms for fast and sealable deep packet inspection[C]//Proc of the 2006 ACM/IEEE symposium on Architecture for networking and communications systems. 2006: 81?92.