一種基于ETW的高性能PDF文件實時監(jiān)控系統(tǒng)

◆王飛平 施可著

（1.衢州職業(yè)技術(shù)學(xué)院 設(shè)備與實訓(xùn)管理中心（信息中心）浙江 324000；2.格力電器（杭州）有限公司生產(chǎn)科 浙江 311200）

傳統(tǒng)的服務(wù)器數(shù)據(jù)保護方式比較單一，主要包括透明加密與訪問控制[1]，該方式不關(guān)注電子文檔本身的內(nèi)容信息。隨著電子文檔格式愈來愈多，安全泄密事件屢見不鮮的情況下，人們開始更加注重文檔內(nèi)容本身是否包含敏感信息。以往一刀切的加密或粗力度的強訪問控制方式在實際的數(shù)據(jù)流通中帶來了諸多不便，因此針對文檔內(nèi)容精準管控的需求應(yīng)運而生。有的方案通過正則表達式匹配內(nèi)容[2]，該方式存在匹配簡單的優(yōu)點，但也存在面臨大量模式匹配性能不足的問題。鑒于此，本文在深入研究已存在DLP[3]系統(tǒng)的基礎(chǔ)上提出一種基于ETW 內(nèi)核技術(shù)[4]與Aho-Corasick 算法[5]結(jié)合的高性能PDF 內(nèi)容實時監(jiān)控系統(tǒng)。該系統(tǒng)工作在操作系統(tǒng)內(nèi)核層，其基于內(nèi)核層面的緩沖和日志記錄機制實現(xiàn)，極大地保證了Windows Server 上的實現(xiàn)性能。終端主機一般部署Minifilter 等文件過濾框架，在服務(wù)器上容易發(fā)生藍屏、死機等情況，影響服務(wù)器上的實際使用。ETW 監(jiān)控框架與以往過濾驅(qū)動監(jiān)控框架最大的不同在于其是Windows Server Kernel 自帶組件的監(jiān)控技術(shù)，保證了技術(shù)向后兼容性與自身的穩(wěn)定性。因電子文檔格式繁多，本文選擇常用的PDF 格式論證該系統(tǒng)的實用性與可行性。

1 ETW 文件監(jiān)控原理

Event Tracing for Windows（ETW）是Windows 操作系統(tǒng)提供的內(nèi)核級事件跟蹤機制，具有低CPU 占用高性能、完全異步的特點，即使在應(yīng)用程序crash 情況下，監(jiān)控事件也會被記錄在內(nèi)核中。ETW包含以下組件：控制器（Controller）、提供者（Provider）、消費者（Consumer），其中控制器完成監(jiān)控會話的啟動和停止，提供者會預(yù)先注冊到ETW 框架上并實時提交監(jiān)測數(shù)據(jù)到ETW 框架。消費者亦需注冊到ETW 框架上，在注冊時通過配置篩選器設(shè)置接收處理的事件與回調(diào)函數(shù)，若滿足篩選器條件ETW就會觸發(fā)所設(shè)置的回調(diào)函數(shù)。

2 系統(tǒng)的設(shè)計與分析

2.1 系統(tǒng)的架構(gòu)與設(shè)計

為解決現(xiàn)有產(chǎn)品無法審計Windows Server 文檔內(nèi)容的問題，本文提出基于ETW 的PDF 文檔內(nèi)容實時監(jiān)控系統(tǒng)。系統(tǒng)首先以事件跟蹤的方式注冊ETW 回調(diào)實現(xiàn)對Windows 文件訪問行為的采集，其次將采集的數(shù)據(jù)通過PDF 文字提取模塊解析形成文本，最后將文本提交Aho-Corasick 算法處理模塊檢索敏感信息并生成檢測報告。該系統(tǒng)提供友好的界面方便查看PDF 文檔敏感信息列表，運行過程中對操作系統(tǒng)無明顯影響。該系統(tǒng)主要有如下幾個模塊：ETW 數(shù)據(jù)源采集模塊、線程池業(yè)務(wù)調(diào)度模塊、PDF 文本內(nèi)容解析模塊、Aho-Corasick算法處理模塊、敏感信息日志管理模塊，系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)圖

Windows Server Agent 工作流程如下：

（1）通過注冊ETW 中GUID 為FileIoGuid 的消費者；

（2）啟動ETW 監(jiān)控會話，會話啟動成功后ETW 會將監(jiān)控日志寫入內(nèi)核緩沖區(qū)；

（3）注冊的回調(diào)函數(shù)會實時收到操作系統(tǒng)中發(fā)生的所有文件訪問操作；

（4）解析文件操作結(jié)構(gòu)體EVENT_RECORD 數(shù)據(jù)提取文件訪問信息，將其存儲至隊列后通知業(yè)務(wù)線程池；

（5）業(yè)務(wù)線程池使用muPDF[6]提取PDF 文檔中的文本信息，同時生成JSON 格式數(shù)據(jù)；

（6）將JSON 數(shù)據(jù)使用Aho-Corasick 算法處理模塊匹配敏感信息，生成PDF 文檔內(nèi)容敏感檢測報告.

3 關(guān)鍵技術(shù)及實現(xiàn)

3.1 ETW 文件訪問數(shù)據(jù)的采集

本系統(tǒng)原始數(shù)據(jù)的采集依賴于ETW 追蹤機制，下面介紹注冊ETW 會話的關(guān)鍵代碼。

BOOL QZRegisterETW（）{

TRACEHANDLE hHandle=NULL；

TRACEHANDLE hSessionHandle=NULL；

EVENT_TRACE_LOGFILE trace；

DEFINE_GUID（/*90cbdc39-4a3e-11d1-84f4-0000f80464e3*/

FileIoGuid，0x90cbdc39，0x4a3e，0x11d1，

0x84 ，0xf4，0x00，0x00，0xf8，0x04，0x64，0xe3

）；

BOOL bResult=FALSE；

EnableTraceEx（&FileIoGuid，NULL，hSessionHandle，1，TRACE_LEVEL_INFORMATION，0，0，0，0）；ZeroMemory（&trace，sizeof（EVENT_TRACE_LOGFILE））；

trace.LoggerName="TestFilemon"；

trace.EventRecordCallback=QzctCallbackFunc；

trace.LogFileMode=EVENT_TRACE_REAL_TIME_MODE；

hHandle=OpenTrace（&trace）；

ProcessTrace（&hHandle，1，0，0）；

return bResult；

}

其中QzctCallbackFunc 為設(shè)置的回調(diào)函數(shù)，ProcessTrace 啟動監(jiān)控會話成功后，QzctCallbackFunc 會收到文件訪問操作信息。需注意EnableTraceEx 第四個參數(shù)用來控制監(jiān)控會話的啟動和停止。采集的數(shù)據(jù)異步通知業(yè)務(wù)線程池處理，數(shù)據(jù)采集流程如圖2所示。

圖2 數(shù)據(jù)采集流程圖

3.2 PDF 文檔內(nèi)容提取

本系統(tǒng)采用線程池處理提取業(yè)務(wù)以保證監(jiān)控框架的高性能，為極大地提高處理性能，本文利用IOCP 設(shè)計線程池，整個存儲隊列由操作系統(tǒng)維護，規(guī)避自己設(shè)計隊列多線程競爭加鎖造成性能低下的問題。線程池設(shè)計如下：

（1）CreateIoCompletionPort 創(chuàng)建完成端口，調(diào)用CreateThread創(chuàng)建與CPU 核數(shù)目一致的線程，形成線程池；

（2）線程池調(diào)用GetQueuedCompletionStatus 獲取IOCP 隊列的任務(wù)；

（3）新增IOCP 任務(wù)調(diào)用PostQueuedCompletionStatus 完成。

PDF 文檔內(nèi)容的提取引擎采用muPDF 庫，muPDF 是一個輕量級的pdf 解析庫，其具有小巧、解析效率高的特點，muPDF 庫主要包括Fitz、pdf 兩部分，F(xiàn)itz 是pdf 的渲染引擎，將pdf 文檔渲染成圖片，而pdf 模塊主要完成文檔打開、數(shù)據(jù)解析以及繪制。分析fitz.h頭文件發(fā)現(xiàn)，它實現(xiàn)了xml 文件解析，基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)如tree，文件讀寫、圖像、字體、顏色等結(jié)構(gòu)體函數(shù)的定義。而pdf 模塊部分的doucument.h 聲明了文檔讀取、解析的具體方法，是Fitz 模塊的具體實現(xiàn)。為方便數(shù)據(jù)解析，解析后的JSON 數(shù)據(jù)格式如圖2所示。

圖2 JSON 數(shù)據(jù)格式

提取PDF 文檔內(nèi)容的工作流程如下：

（1）使用接口fz_new_context、fz_register_document_handlers完成初始化；

（2）使用接口fz_open_document 打開文件，調(diào)用pdf_dict_gets獲取標題、文檔生成軟件名稱、作者、修改時間等信息；

（3）調(diào)用fz_load_page 分頁加載pdf 單頁信息，依次調(diào)用以下API 接口：fz_new_display_list、fz_run_page、fz_run_display_list、fz_new_output_with_buffer 獲取文本內(nèi)容；

（4）將fz_buffer 數(shù)據(jù)內(nèi)容按圖2 格式生成JSON 緩存數(shù)據(jù)；

3.3 Aho-Corasick 算法匹配

Aho-Corasick 算法是通過將多模式字符串建立一個確定性的有限自動機，以待匹配的文本作為該狀態(tài)機的輸入，當?shù)竭_狀態(tài)機的特定狀態(tài)時說明算法匹配成功。AC 自動機是基于前綴搜索的原理實現(xiàn)的，是Tire 樹[7]與KMP 算法的擴展。在AC 自動機的構(gòu)造階段，為每個狀態(tài)生成對應(yīng)的轉(zhuǎn)移函數(shù)、失效函數(shù)與輸出函數(shù)信息。因AC 自動機實際匹配性能高，本系統(tǒng)選擇其作為敏感信息串的匹配算法。算法匹配偽代碼如下：

其中T 為待匹配的目標文本字符串，n 為字符串的長度，m 為字典樹節(jié)點指針，Next 函數(shù)返回從節(jié)點m 經(jīng)路徑T[i]到達的下一個節(jié)點指針，pre 函數(shù)返回節(jié)點m 的回溯節(jié)點指針，node_flag 檢查節(jié)點是否為標記節(jié)點。

4 實驗結(jié)果

4.1 測試環(huán)境

Windows Server 2008 系統(tǒng)：Intel Core I5-3320M，16GB 內(nèi)存。

4.2 性能測試

為測試該實時監(jiān)控框架對CPU 的性能影響，在文本字符串為2MB，模式串規(guī)模為10000 條的前提下，利用Windows Server 自帶的資源管理器對該框架進行測試，十分鐘內(nèi)CPU 平均占用率的對比如圖3所示。

圖3 CPU 平均占用率對比圖

5 結(jié)論

本文分析并闡述了基于ETW 與AC 自動機的高性能PDF 文件實時監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)方法。實驗結(jié)果表明：該框架占用CPU 占用率控制在5%左右，基本不會降低服務(wù)器的使用性能，綜上述，該框架具有一定的實用價值。