Oracle通信TNS協議中請求報文的解析①

侯方杰, 王 雷, 王 嵩, 盛 捷

(中國科學技術大學 信息技術學院 自動化系, 合肥 230001)

1 概述

數據庫作為各類信息系統的核心部分, 其安全性在整個安全體系結構中舉足輕重. 根據Verizon 2016數據泄露調查報告[1], 分析已確認的 2260 起數據泄露事件中, 泄露源 7 成以上和數據庫相關. 且由內部違規, 即公司內部人員的操作失誤和權限誤用造成的數據泄露事件占總事件的20%. 在外部攻擊方面,2016年數據庫漏洞中, 80%以上都屬于SQL 層入侵范疇, 主要是利用數據庫系統SQL語言漏洞[2]. 諸多的安全隱患也催生了大批數據庫安全審計軟件, 在事中發現并阻斷違規和入侵語句, 在事后審計和分析, 對泄密行為追根溯源, 保證數據庫的安全. 而Oracle數據庫作為最流行的數據庫產品之一[3], 在各種數據庫安全軟件中均被廣泛支持.

將網絡數據報文轉化為數據庫會話是數據庫安全審計中必不可少的一部分. 由于Oracle公司并未公布數據庫通信細節, 當前的安全審計重點針對Oracle數據庫的通信協議TNS(Transparent Network SubStrate Protocol)進行分析. 文獻[4,5]都基于TNS協議設計與實現了Oracle審計系統, 并進行了性能評價. 文獻中給出了TNS數據包頭的格式、數據包分類及會話流程,但對于數據包的內部格式細節卻沒有太多說明, 并且僅覆蓋一兩個協議版本. 文獻[6]則通過WireShark抓包工具研究數據包的結構來對TNS協議進行解析, 對客戶端與服務器建立連接的過程進行了細致的分析,并給出了網絡選項協商、類型編組、認證過程, 分析了TNS協議中的5種數據包結構. 但該文獻并未給出抓包測試的操作系統、服務器、客戶端以及TNS協議版本, 并且對于關鍵的Data類型數據包中的請求與響應報文的結構并沒有更深入的分析, 難以從中提取出SQL以及響應的內容.

當前公開的TNS協議解析總的來說有3個問題.一是重點放在安全軟件的系統設計與實現上, 對于TNS協議的分析較為簡略;二是對TNS協議分析的層次不夠深入, 難以還原出用戶的操作和數據庫的響應;三是覆蓋的數據庫服務器、客戶端、操作系統和協議版本不夠全面, 只適用于特定的協議版本、服務器, 甚至是特定的連接.

本文針對市場上多種常用的TNS協議版本、數據庫服務器與客戶端, 分析其TNS數據包尤其是請求數據包的格式細節. 使用Wireshark抓包工具, 獲取數據包樣本;通過人工分析, 初步獲取報文規則;通過數據挖掘的方法, 確定報文中的關鍵字節, 及其與SQL的偏移量的關系, 生成匹配規則;設計實驗, 使用匹配規則提取數據包中的SQL語句做驗證;分析匹配失敗的用例, 配合后期校正規則, 提高測試通過率.

2 TNS協議概述

TNS協議是Oracle數據庫遠程通信協議. 根據數據庫服務器和客戶端的選擇, TNS可以使用Plain TCP、SSL TCP、命名管道、IPC傳輸. 其中命名管道是進程間通信, IPC是本地通信, Plain TCP明文傳輸,SSL TCP是加密傳輸. 考慮到絕大多數遠程客戶端連接用的是Plain TCP和SSL TCP, 本文僅分析Plain TCP下的TNS協議. 理論上獲得SSL秘鑰后對SSL TCP解密得到的報文, 也適用于本文的分析.

Oracle通信的流程在文獻[4–6]中都有詳細的說明, 并且和本文請求報文解析的關系不大, 在此略過.本節重點介紹對分析過程至關重要的TNS報文頭部結構.

TNS報文通用首部格式如圖1所示, 共8個字節,包括數據包長度、數據包校驗和、數據包類型、保留位、數據包頭部校驗和. 需要注意的是, 最新的315版本TNS協議中, 數據包長度和校驗和位置進行了對調.目前數據包校驗和、保留位、數據包頭部校驗和均以0填充. 數據包類型的取值與含義見表1. 其中, 類型為0x06的是Data類型數據包. 在連接建立完成之后, 客戶端的請求、服務器的響應都是Data類型, 因此本文分析的對象主要也是該類型數據包.

圖1 TNS通用首部格式

表1 TNS通用頭部中類型的取值與含義

Data類型第一個問題是協議中數據包格式包括8個字節的TNS通用首部位置和格式不固定. 對于提取協議請求內容來說, 后面依次重要的是DATA

FLAG、ID、SUB知道內容在報文中的偏移量. ID和但這個偏移量會根據數據部分. 其中DATA FLAG一般填充0庫服務器、客戶端版本不同而變化, ID還會受到協議版本號、SUB ID和數據部分可能會重復出現,類型、長度等影響. 如圖2因此需要根據報文中所示. ID和SUB ID可以唯一關鍵詞來確定后續數據部分的具體類型偏移量.

圖2 TNS協議Data類型數據包格式

3 TNS請求解析方案

本節將從樣本獲取、人工初步分析兩方面介紹TNS請求解析方案的設計依據.

3.1 樣本獲取

根據對市場上常用的TNS協議版本、數據庫服務器、客戶端的調研, 以及在某電信集團數據中心機房采集到的數據流量顯示, 常用的TNS協議版本包括308、310、312、313、314、315. 為了保證通用性, 本文解析支持TNS308到31的5全版本. 在數據庫服務器方面配置了Windows和Linux下的Oracle8i、9i、10g、11g、12c, 而客戶端采用了java連接(包括classes12、ojdbc14、ojdbc5、ojdbc6、ojdbc7的JAR包)、Navicat(主版本號包括 10、11、12)、PL/SQL Developer(主版本號包括6、7、8、9、10、11)、Oracle SQL Developer(主版本號包括2、3、4)和PowerDesigner, 使用到的動態連接庫包括instant client 10.2、11.2和12.2的oci.dll.

3.2 人工初步分析

對于采集到的數據包, 根據請求者的IP和數據包中ASCII碼是否包含連續的英文字母, 將請求報文單獨提取了出來. 統計了請求報文數據類型的ID和subID, 并結合前面一章的分析得到了請求報文的一個簡單結構, 如圖3所示. 初步分析揭示了TNS協議解析的兩個主要問題.

圖3 請求報文格式

第一個問題是協議中數據的位置和格式不固定.對于提取協議請求內容來說, 重要的是知道內容在報文中的偏移量. 但這個偏移量會根據數據庫服務器、客戶端版本不同而變化, 還會受到協議版本號、數據類型、長度等影響. 因此需要根據報文中關鍵詞來確定偏移量.

第二個問題是協議解析涉及的范圍廣, 數據量大,人工分析的方式耗時耗力, 并且無法精確定位偏移量.需要一個系統的分析方法. 而諸多協議逆向的方法[7–9]在不依賴先驗知識的情況下對協議格式進行分析, 對包含負載的報文格式解析效果并不好.

本文通過數據挖掘的方法, 提取基于位置的關鍵詞, 建立關鍵詞與偏移量的關系. 依次對不同TNS協議的版本獲取偏移量規則, 以提高工作效率. 之所以用協議版本作為樣本劃分, 是因為相對于操作系統、服務器、客戶端版本, 相同協議版本的報文顯示出更強的規律性.

4 關聯挖掘獲取偏移量

本節采用關聯挖掘的思想, 確定字段值與偏移量的關系. 關聯挖掘最早應用于顧客交易數據庫中項集的關聯規則[10], 隨后關聯規則的挖掘被廣泛研究. 在關聯挖掘中, 首先獲得頻繁集, 再從頻繁集中通過預設的置信度獲取關聯規則. 在確定關鍵詞與偏移量關系時,可以先找到特定偏移量的頻繁關鍵詞, 再從中獲取規則.

4.1 關聯挖掘的數據格式

假設第k個報文偏移量為s, 則它的SQL前面存在s個字節. 將第i個字節的偏移量與值組為2元組, 記為

并且有

也就是說僅當偏移量和值都相同時, 才認為兩個報文上的某個字節是相同的. 記F為字節與偏移量的映射關系, 則有

由于這個映射關系和某個具體的報文無關, 因此可以略去k, 即

報文中對結構有關鍵影響的字節只占少數. 也就是說, 只需部分關鍵字節的值, 就可以確定報文偏移量.轉化為數學語言, 即

滿足

使得

式(8)是一個關聯規則的形式. 在關聯挖掘中, 以ai和s的取值范圍作為項集, 將數據格式定為

并從樣本中獲取數據集, 使用Apriori算法, 可以挖掘出形如式(8)的關聯規則. 由于式(8)是針對偏移量的關聯規則, 可以將樣本數據先按照偏移量的不同劃分為若干個組, 對每個組分別求頻繁集. 每個組內偏移量是定值, 因此偏移量s一定在頻繁集中. 在求關聯規則時, 再將各組頻繁集匯總. 依據偏移量的不同進行劃分, 可以有效的降低計算量.

4.2 樣本數據提取

樣本數據提取指的是從初始網絡數據包中提取出a1,a2,···,ai,···,as和偏移s. 本文將SQL語句限制為select、insert、create、drop、delete等單詞開頭的常用語句. 然后采用字符串匹配的方式,即可確定SQL語句的起始位置, 以及從開頭到SQL的每一個字節, 從而自動而快速地生成樣本數據集.

4.3 算法描述

關聯挖掘采用的是Apriori算法[11], 具體描述如下:

上述算法將置信度設置得接近于1是因為, 對于一個特定的字段組合, 其對應的偏移量也是通常固定的. 第5)步中, 僅搜索和偏移量相關的規則.

在挖掘的過程中發現, 小樣本集Di中數據報文存在著不少字節, 它們的偏移和值是完全固定的, 所以一定會出現在頻繁集中. 但是這部分字節并不會在計算時被忽略, 反而是出現在每一次頻繁集的迭代中. 為了減少計算量, 第2)步將這些偏移和值固定的字節在挖掘之前從樣本集中移除, 在第4)步挖掘結束后重新添入頻繁集.

5 實驗分析

本節首先用前述的挖掘算法, 獲取挖掘結果, 并對其含義做解釋. 然后在實際系統工作環境下, 使用挖掘得到的規則對請求報文做解析. 同時對規則的準確度做評價.

實驗環境采用3.1節描述的所有客戶端和服務器,分別在Windows和Linux環境下, 兩兩連接, 運行SQL腳本采集數據. 將采集數據按照TNS協議版本進行劃分, 再分別使用關聯挖掘的方法獲取偏移量的規則.

5.1 最大最小規則

挖掘結果顯示, 對于同一個偏移量, 得到規則不止一個. 記偏移量為s的集合為

定義最小規則rmin→s為:

定義最小規則rmax→s為

若rmin?rmax, 則rmin和rmax構成一對最大最小規則. 很明顯, 除非R為空集,rmin和rmax總是存在. 并且,對于一個偏移量s, 可能存在不止一對最大最小規則.

在規則集中, 最大最小規則有很多用處. 最小規則因為包含的字節數量最小, 沒有冗余, 適合直接用于請求報文SQL的提取. 而最大規則由于包含了更多的信息量, 適合對報文結構作進一步的分析. 對TNS315協議, 035e報文頭部到SQL的一對最大最小規則如圖4(a)和4(b)所示. 圖中最大規則因為篇幅原因, 省去了字節值前面的0x.

圖4 偏移量為40的最小規則及最大規則

5.2 細化協議格式

通過對各種最大規則的分析對比, 得到了請求報文的一個更詳細的格式. 圖5中是TNS315版本請求報文的部分格式. 圖中的Magic1、Magic2、Magic3為定長字段. 圖中的變長字段, 如SQL_LEN、VarD1、VarD2等, 均滿足len+data的結構. Len為1個字節,data長度為len個字節. 圖中的VarS1為變長字段, 一般為2個、4個或8個字節的填充字段. 實驗結果說明, 數據挖掘方法對獲取變長結構的關聯字段和報文中的定值字段非常有效.

5.3 規則解析效果測試

本文使用最小規則來解析并提取報文中SQL語句. 圖6顯示了各個TNS協議版本挖掘出的最小規則的數量. TNS 310版本支持的服務器和客戶端版本最多, 其格式最復雜, 挖掘出的規則數量也最多. 而TNS 314版本的格式則相對比較簡單.

本文根據挖掘出的最小規則, 進行Oracle報文解析的實際測試. 通過上海某電信集團機房的專業數據庫操作人員為期2個月的采集和測試, 初期的測試通過率僅為71%, 如圖7所示. 發現問題包括:部分報文結構的缺失、部分變長字段發現了新結構. 主要原因在于樣本集不夠全面, 無法覆蓋所有報文格式. 本文通過使用異常樣例擴充樣本集, 重新挖掘來完善規則, 提高測試通過率.

圖5 更詳細的報文格式

圖6 不同TNS協議版本的規則數量

在這之后, 本文一邊實地運行解析系統, 一邊更新解析系統的規則集. 采集到的數據包如果解析異常, 就會被添加進樣本集中, 重新進行挖掘. 挖掘出的新規則會被添加進正在運行的解析系統規則集中. 到目前為止, 解析系統已運作9個月. 除了開頭2個月有個別異常, 之后均能正常解析.

6 結論與展望

本文針對Oracle數據庫TNS協議的請求報文, 提出了一個解決方案, 適用于多種常用操作系統、服務器、客戶端和協議版本. 采用數據挖掘的方法來處理字節數多、意義不明的報文, 獲取對報文結構有重要影響的字段. 由于初期樣本采集覆蓋范圍不夠廣, 挖掘的結果對于樣本中出現頻率少的報文類型并不友好.后期校正使用解析過程中的異常樣例擴充樣本集, 反復挖掘, 提高對所有類型報文的適用性. 實地采集數據進行解析, 可以有效提取出請求報文中的SQL語句,數據挖掘的方法可以有效地從大量數據中提取出規則,省時省力. 下一步計劃采用現有方法繼續研究響應報文中的內容.

圖7 不同TNS協議版本的測試通過率