一種即時通信監(jiān)控系統(tǒng)的設計與實現(xiàn)
隨著科技的發(fā)展和計算機網(wǎng)絡的普及,即時通信軟件已逐漸融人人們的生活。即時通信軟件為個人和企業(yè)提供了便捷、快速、高效的溝通方式。常用的即時通信軟件有微軟的MSN Messenger、騰訊QQ、Googletalk等。即時通信技術在給個人及企業(yè)帶來高效便捷溝通的同時也產(chǎn)生了一系列的安全問題。隨著即時通信軟件的普及和用戶數(shù)量的快速增長,其已成為病毒和黑客攻擊的主要對象。對于企業(yè)而言,即時通信技術使得員工的行為更加難以控制,容易導致泄露機密、竊取資料等事件的發(fā)生,這將給企業(yè)造成無法估量的損失。針對中小規(guī)模企業(yè)網(wǎng)對即時通信安全的實際需求,對企業(yè)廣泛使用的MSN Messenger進行了協(xié)議分析,并在此基礎上設計實現(xiàn)了一個基于網(wǎng)絡嗅探技術的MSN協(xié)議監(jiān)控分析系統(tǒng)——MSNAnalyzer。該系統(tǒng)可以對企業(yè)內部網(wǎng)絡進行實時監(jiān)控,監(jiān)督員工的上網(wǎng)行為,預防重要資料泄露等情況的發(fā)生,保護企業(yè)的信息安全,減少不必要的經(jīng)濟損失。
1、體系結構
該監(jiān)控系統(tǒng)采集企業(yè)網(wǎng)絡出口處的所有數(shù)據(jù)幀,通過對幀的IP地址進行分析提取出被監(jiān)控客戶機的數(shù)據(jù)幀并以一定的格式保存到文件中。然后,從文件中讀取數(shù)據(jù)幀并將數(shù)據(jù)幀交給協(xié)議分析處理模塊處理,處理后的結果以文件的形式保存在磁盤中。圖1所示為該系統(tǒng)的總體結構示意圖。圖中,Sniffer是運行MSNAnalymr程序的主機,Clientl、Client2、Client3為內網(wǎng)主機。

? 圖1 系統(tǒng)體系結構
MSNAnalyzer工作的基本過程為:
(1)基于Sniffer技術從網(wǎng)絡總出入口處采集網(wǎng)絡數(shù)據(jù)(抓包)。
(2)存儲數(shù)據(jù)幀。
(3)提取數(shù)據(jù)幀并進行分析。
根據(jù)分析,系統(tǒng)實現(xiàn)模型如圖2所示。

? 圖2 系統(tǒng)總體實現(xiàn)模型及模塊劃分
2、數(shù)據(jù)采集及存儲
系統(tǒng)采用基于網(wǎng)絡嗅探技術的數(shù)據(jù)采集方法,以WinPcap 4.0.1作為開發(fā)工具,Windows平臺下使用WinPcap從網(wǎng)絡適配器嗅探數(shù)據(jù)十分方便,圖3是使用WinPeap捕獲網(wǎng)絡數(shù)據(jù)包的基本流程。
使用WinPcap開發(fā)應用程序除可以捕獲數(shù)據(jù)包外,最大的優(yōu)點在于WinPcap可以對數(shù)據(jù)包進行過濾。WinPeap從網(wǎng)絡適配器上嗅探到的是最原始的數(shù)據(jù)幀,這包括了所有流經(jīng)的數(shù)據(jù)。如果不對數(shù)據(jù)包進行相應的過濾,將會捕獲到許多無關的數(shù)據(jù),這會增加系統(tǒng)的負擔,使系統(tǒng)工作效率降低。

? 圖3 WinPcap數(shù)據(jù)采集流程
在數(shù)據(jù)采集之后,采用什么樣的存儲策略來存儲數(shù)據(jù),以最大限度地保證采集到的網(wǎng)絡數(shù)據(jù)包(Pack.et)不丟失,是系統(tǒng)設計中必須面對的一個重要問題。網(wǎng)絡丟包的原因可能有很多,包括內存緩沖技術、磁盤I/O能力、包過濾及處理技術、數(shù)據(jù)流量大小、網(wǎng)絡接口性能、CPU處理能力等諸多方面。
網(wǎng)絡丟包的指標一般采用丟包率(Rate of PacketLoss,RPL)。計算公式為:L=((發(fā)送的數(shù)據(jù)包數(shù)一接收到的數(shù)據(jù)包數(shù))/發(fā)送的數(shù)據(jù)包數(shù))×100%。
眾所周知。頻繁的磁盤I/O顯然會影響到系統(tǒng)的性能和效率,這在大的數(shù)據(jù)流量下尤為明顯。為了避免頻繁的磁盤I/O,需要在數(shù)據(jù)存儲時引入內存緩沖處理技術。在基于WinPcap的網(wǎng)絡數(shù)據(jù)采集中,系統(tǒng)使用了多級內存緩沖,內核緩沖器和用戶緩沖器的大小分別設置為6MB和1MB,并設置內核緩沖器和用戶緩沖器之間一次傳送的最小數(shù)據(jù)塊的大小為512kB。
3、數(shù)據(jù)分析與處理
數(shù)據(jù)分析與處理分為四部分。首先是Ethernet數(shù)據(jù)幀處理,主要完成鏈路層數(shù)據(jù)驗證、拆包,并將數(shù)據(jù)提交給IP層進行處理。IP數(shù)據(jù)報的處理主要完成IP層數(shù)據(jù)驗證、拆包,并將數(shù)據(jù)提交給傳輸層進行處理。TCP分組的處理主要完成TCP層數(shù)據(jù)的驗證、拆分及TCP重復和無序分組的處理,完成TCP會話重建,并將重組后的應用層數(shù)據(jù)提交至協(xié)議分析層處理。協(xié)議分析主要完成應用層數(shù)據(jù)和最終用戶數(shù)據(jù)的處理。對應用層數(shù)據(jù)主要進行命令解析和協(xié)議數(shù)據(jù)重組,對最終用戶數(shù)據(jù)的處理包括聊天信息的提取、顯示圖片和自定義表情的提取、文件傳輸?shù)奶崛〉?。MSNP協(xié)議分析模型如圖4所示。
3.1、命令解析
命令解析的本質就是分析字符串的含義,它類似計算機高級語言編譯器中詞法分析的功能。MSNP協(xié)議涉及多達幾十個命令,服務器和客戶端使用的命令也不相同。系統(tǒng)對涉及信息傳輸?shù)拿钸M行了重點解析,主要包括握手命令和數(shù)據(jù)傳輸命令。對于客戶端命令。主要解析“ANS”和“MSG”。服務器端主要解析“IRO”、“USR”、“JOI”和“MSG”。

? 圖4 MSNP協(xié)議分析模型
3.2、協(xié)議數(shù)據(jù)重組
協(xié)議數(shù)據(jù)重組主要針對P2P消息,當二進制頭和二進制尾之間的消息內容大小超過1202字節(jié)時。消息會被分片傳輸。通常被拆分的P2P消息包括MSNSLP消息和實際傳輸?shù)母鞣N數(shù)據(jù)(如文件、表情)。二進制頭中共有9個字段,其中“Data Offset”、“Total Data Size”和“Message Length”3個字段和消息分片密切相關。這3個字段分別表示“總數(shù)據(jù)大小”、“數(shù)據(jù)偏移量”和“本條消息長度”。由于TCP處理模塊已對重復和無序的數(shù)據(jù)流進行了處理,協(xié)議分析模塊的輸入是順序的數(shù)據(jù)流。按順序將數(shù)據(jù)取出即可。如圖5所示。

? 圖5 P2P消息重組方法
3.3、數(shù)據(jù)存儲
在協(xié)議數(shù)據(jù)重組之后,對重組的數(shù)據(jù)進行分析及數(shù)據(jù)提取。分析主要針對MSNSLP消息,MSNSLP消息負責會話的建立和結束。對MSNSLP的分析除取得傳輸?shù)念愋屯?,最重要的是提取文件名,以備存儲時使用。顯示圖片和自定義表情的文件名封裝在各自的MSNObi對象中,而傳輸文件的文件名以Unicode格式存儲在INVITE方法的Context中類CFileName用于存儲文件名,其結構如下:
//name of file transfered in asession
class CFileName{
public:CHIcNanle();
~CFileNameTram();
public:
U_int m_nSessioID;//Session ID
char*m_pszFileName;//Name of current file
};
其中數(shù)據(jù)成員m_nSessionID用于確定文件名和文件數(shù)據(jù)的對應關系。在數(shù)據(jù)提取完畢后根據(jù)CHle.Name和CDataTrans的m_nSessionID大小得到對應關系,進行數(shù)據(jù)存儲。
3.4、性能方面的考慮
在數(shù)據(jù)流量比較大的時候,數(shù)據(jù)處理會導致大量的內存占用,從而降低系統(tǒng)的效率。對于協(xié)議數(shù)據(jù)重組模塊,尤其是傳輸文件的提取,系統(tǒng)使用定時器機制和定量存儲機制進行控制。
當接收到第1個分片的時候對相應的CDataTrans對象設置定時器。如果在定時器超時的時候仍沒有接收到新的分片,就認為此次傳輸失敗,將之前緩存的數(shù)據(jù)清除,釋放所占用的空間。若有新的分片到達,還原定時器的超時時間。系統(tǒng)預設的定時器為10分鐘,管理員可以重設超時時間。
對于大小超過1MB的文件,系統(tǒng)采用定量存儲。當接收的數(shù)據(jù)大小達到一定量,便進行一次存儲操作。當然。頻繁的存儲操作會增加磁盤讀寫的開銷。系統(tǒng)預設大小為1MB,管理員同樣可以更改大小,以減少磁盤讀寫的開銷。
4、系統(tǒng)測試
系統(tǒng)測試主要是對系統(tǒng)進行性能測試。目標是測試系統(tǒng)在給定工作環(huán)境下的性能,檢查系統(tǒng)對指定數(shù)據(jù)的監(jiān)聽提取能力。監(jiān)控服務器主機一臺,客戶機(目標主機)若干,客戶機通過交換機連接在一個局域網(wǎng)中,并與Internet互聯(lián)。對上述測試環(huán)境進行一個工作周(周一到周五)測試。每個工作日測試時間為12小時(早8點到晚8點),每個工作日客戶機數(shù)量維持在124--168之間,測試結果如表1所示。
表1測試結果

從上表可以看出顯示圖片和自定義表情的提取率均在96%以上。數(shù)據(jù)丟失的原因主要是由于丟包造成的,由于系統(tǒng)采用過濾策略進行數(shù)據(jù)包捕獲,在網(wǎng)絡流量比較大的時候,可能會導致一定的丟包率,而顯示圖片和自定義表情文件比較都比較小,若干數(shù)據(jù)包的丟失對結果會有一定影響。文件傳輸?shù)奶崛÷手挥?1.7%,原因主要有3個方面:一是丟包率;二是協(xié)議分析中對NAT穿越的判斷結果;第三點,也是最重要的一點,當傳輸?shù)碾p方位于同一局域網(wǎng)時,實際數(shù)據(jù)傳輸僅在局域網(wǎng)中進行,而不會通過服務器中轉,這樣系統(tǒng)僅能監(jiān)聽到傳輸邀請,而無法監(jiān)聽到實際傳輸?shù)臄?shù)據(jù)。測試結果沒有對文字信息進行評估,因為文字信息的傳輸沒有握手過程,難以評估。系統(tǒng)的設計實現(xiàn)能夠保證在丟包率較小的情況下,使文字信息的提取率接近100%。
5、結束語
針對中小規(guī)模企業(yè)網(wǎng)對即時通信安全的實際需求,研究、設計并實現(xiàn)了MSN協(xié)議的監(jiān)控分析系統(tǒng)。首先分析了系統(tǒng)的功能和性能需求,并給出了系統(tǒng)的體系結構、總體實現(xiàn)模型。接著詳細討論了數(shù)據(jù)采集與存儲策略,數(shù)據(jù)分析與處理的過程,重點研究了MSNP協(xié)議的分析。最后,對系統(tǒng)性能進行測試,并對測試結果進行了分析。
電子發(fā)燒友App












評論