利用背景流量數據(contexual flow data) 識別TLS加密惡意流量


識別出加密流量中潛藏的安全威脅具有很大挑戰,現已存在一些檢測方法利用數據流的元數據來進行檢測,包括包長度和到達間隔時間等。來自思科的研究人員擴展現有的檢測方法提出一種新的思路(稱之為“dataomnia”),不需要對加密的惡意流量進行解密,就能檢測到采用TLS連接的惡意程序,本文就該檢測方法進行簡要描述,主要參照思科在AISec’16發表的文章《IdentifyingEncrypted Malware Traffic with Contextual Flow Data》[1][2][3]。

一、 主要思想

            屏幕快照 2017-03-21 下午5.42.05.png

圖1 TLS加密惡意流量檢測流程

首先,分析百萬級的正常流量和惡意流量中TLS流、DNS流和HTTP流的不同之處,具體包括未加密的TLS握手信息、TLS流中與目的IP地址相關的DNS響應信息(如圖2)、相同源IP地址5min窗口內HTTP流的頭部信息;然后,選取具有明顯區分度的特征集作為分類器(有監督機器學習)的輸入來訓練檢測模型,從而識別加密的惡意流量。本方法區別於已有研究方法的地方就是利用TLS流相關背景流量信息(包括DNS響應、HTTP頭部等)輔助加密惡意流量檢測。

圖片2.png

 

圖2TLS流和背景DNS流量

(紅色數據用於鏈接TLS流和DNS流、綠色數據表示背景信息、未標記顏色的數據表示TLS未加密的頭部信息) 

二、流量數據采集

思科研究人員自己寫了一款基於libpcap的通用工具,用於分析並提取捕獲到的數據流(惡意流量和正常流量)的數據特征,包含clientHello,serverHello, certificate和clien-tKeyExchange等信息。

1.   惡意流量

采集環境:ThreatGRID[4],一種商業的沙箱環境,提供惡意軟件分析功能

采集時間:2016年1月-2016年4月

說明: 沙箱環境接受用戶提交(usersubmissions),每個用戶提交允許運行5min,所有的網絡活動被記錄用於分析。

2.   正常流量(DMZ區流量,本文認為該區域包含少量的惡意流量)

采集環境:某大型企業網絡的DMZ區某5天的數據量

采集時間:2016年4月

三、流量數據特征

文中對惡意/正常流量中TLS流及背景流量信息(DNS響應信息、HTTP頭部信息)進行統計分析,尋找惡意流量和正常流量中具有明顯區分度的數據特征以及相應特征值的規律性。

1.   TLS握手信息:

選取擁有完整TLS握手信息的TLS流作為研究對象,通過分析TLS握手信息發現,惡意流量和正常流量使用的加密套件(ciphersuites )、支持的擴展(extensions)等方面有很大不同,詳見表1。 

表1 惡意流量與正常流量TLS握手信息區別

屏幕快照 2017-03-21 下午6.00.23.png

2.   DNS響應信息:

通過選取和目的IP地址相關的包含DNS響應信息的數據流作為研究對象,提取響應的域名信息進行分析。DNS域名信息也可以從SNI(Server NameIndication)擴展和SANs(subjectalternative names)中得知,但由於TLS版本信息等原因,這些字段有時候是不存在的。

通過分析數據發現, 惡意流量與正常流量的區別主要表現在: 域名的長度、數字字符及非數字或者字母(non-alphanumericcharacter) 的字符占比、DNS解析出的IP數量、TTL值以及域名是否收錄在Alexa網站等。

域名的長度:正常流量的域名長度分布為均值為6或7的高斯分布(正態分布);而惡意流量的域名(FQDN全稱域名)長度多為6(10)。

數字字符及非字母數字(non-alphanumericcharacter) 的字符占比:正常流量的DNS響應中全稱域名的數字字符的占比和非字母數字字符的占比要大。

DNS解析出的IP數量:大多數惡意流量和正常流量只返回一個IP地址;其它情況,大部分正常流量返回2-8個IP地址,惡意流量返回4或者11個IP地址。

TTL值:正常流量的TTL值一般為60、300、20、30;而惡意流量多為300,大約22%的DNS響應匯總TTL為100,而這在正常流量中很罕見。

域名是否收錄在Alexa網站:惡意流量域名信息很少收錄在Alexatop-1,000,000中,而正常流量域名多收錄在其中。

3.   HTTP頭部信息:

選取相同源IP地址5min窗口內的HTTP流作為研究對象,通過分析HTTP頭部信息發現,惡意流量和正常流量所選用的HTTP頭部字段有很大區別。詳見表2。此外,正常流量HTTP頭部信息匯總Content-Type值多為image/*,而惡意流量為text/*text/html、charset=UTF-8或者text/html;charset=UTF-8。

表2 惡意流量與正常流量HTTP頭部信息區別

屏幕快照 2017-03-21 下午6.02.22.png

四、建模分類

1.   實驗數據集

選取擁有完整TLS握手信息且有DNS響應和HTTP頭部信息的數據流進行分析建模。

選取的特征值包括兩部分(這里不贅述數據特征的表示方法,詳見論文):

(1)  可直接觀測到的元數據:包長度、包到達間隔時間以及字節分布。

(2) 第三章節提到TLS握手信息及對應的背景流量包含的數據特征,包括ciphersuites、extensions、publickey length等。

分析工具:Python 和 Scikit-learn[5]

2.    實驗過程:

本文利用10折交叉驗證(10-foldcross-validation)和l1正則化的邏輯回歸算法(l1-logistic regression)來進行分類(即判斷加密流量是否是惡意的)。文中也針對不同數據特征的組合的分類結果進行了統計(圖7-Table 1),可以發現利用背景流量信息進行分類的模型不僅准確率會更高,而且參數會更少(根據交叉驗證形成模型參數平均計算可得)。

圖7中Table 2 列出了對判別正常流量和異常流量影響權重比較大的數據特征。這些特征很容易解釋為什么網絡流是惡意的或者是正常的,例如絕大多數的惡意流量樣本不會和排名top-1,000,000的網站進行通信。 

屏幕快照 2017-03-21 下午5.49.58.png 

圖3 實驗結果分析

文中提到,使用FDR(偽發現率,FalseDiscovery Rate)作為假設檢驗錯誤率的控制指標(FDR不超過0.00%)。

我們收集的特征數據除了用於構造機器學習模型之外,還有其它的一些啟示。

1.    Client端的client-hello中的SNI與sever端的certificate中包含的SAN都表示服務器主機名,兩者的差異性可以用於惡意流量檢測;

2.    HTTP流中的User-Agent和從TLS流中ciphersuites和advertisedextensions推測出的User-Agent的差異性也可以用於惡意流量檢測。

3.   實驗驗證:

為了防止過擬合,除了上面提到的交叉驗證方法之外,我們額外收集了2016年5月這個月期間相同企業網絡中DMZ區的流量,用第五章節訓練形成的模型來進行驗證。從Table 3中可以看到,結合TLS流的背景流量信息DNS響應和HTTP頭部信息進行分類的效果最好,即報警數最少。當l1-logistic regression classifier的閾值(Probabilityof malicious)為0.95時,該分類器只有86個報警(包括29個獨立目的IP地址和47個獨立的源IP地址),其中有42個報警看似是“誤報”。經過分析發現,這些“誤報”中,主機是一直和Goolge和Akamai服務器通信,但是從該TLS流的背景流量HTTP流(contexualHTTP)中發現,其與可疑域名進行通信(HTTP中的Host字段),經VirusTotal確認,有50%的反病毒引擎認為和該域名相關的可執行程序是惡意的,這也進一步說明了該模型的有效性。

 屏幕快照 2017-03-21 下午5.48.09.png

 
 

圖4 實驗數據驗證

五、參考文章

[1]  Identifying Encrypted Malware Traffic withContextual Flow Data http://dl.acm.org/citation.cfm?id=2996768 

[2]  不解密數據竟也能識別TLS加密的惡意流量?http://www.freebuf.com/news/108628.html

[3]  傳輸層安全協議抓包分析SSL/TLS http://www.freebuf.com/articles/network/116497.html

[4]  Cisco AMP Threat Grid  http://www.threatgrid.com , 2016.

[5]  F. Pedregosa, G. Varoquaux, A. Gramfort, V. Michel, B.Thirion, O. Grisel, M. Blondel, P. Prettenhofer, R. Weiss, V. Dubourg, J.Vanderplas, A. Passos, D. Cournapeau, M. Brucher, M. Perrot, and E. Duchesnay.Scikit-learn: Machine Learning in Python. JMLR,12:2825-2830, 2011.


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM