數據科學在Web威脅感知中的應用(一)

前言?

從一開始我們就試圖把分析處理對象指定為大規模環境中的Web威脅,不是為了浮夸與博眼球,也不是為了刻意拔高姿態,而是寄希望與能找到一種普世通用的數據方法論能適用于各種不同類別的中小型站點所面臨的威脅。這里的「大規模」,指的是有著成百萬乃至上千萬的站點的環境。這些站點使用著不同的編程語言、不同的框架、不同的Web組件,有著不同的業務、不同的邏輯以及不同的用戶,唯一相同的是它們每天都在遭受著各式各樣的攻擊。

同時,大規模的環境之下充斥著各種轉瞬既逝的信息,消逝之快快到我們來不及停下來諦聽,新的信息又聯翩而至。對于威脅,沒有什么是比「大規模」與「轉瞬既逝」還更好的庇護。相比茫然,我們更多的是恐懼,恐懼的不是看到了這么多威脅,而是那些還沒看到的威脅。我們甚至回答不出還有多少是未知,而未知,永遠又是最為可怕的。我們一次次為新的未知感到驚喜,而又一次次的面對著新的未知,懷疑自己懷疑著這個世界。

這個系列至少有三個部分,我們希望能在不斷探索的過程中,嘗試摸索楚一些科學的數據方法,用有別于經典安全產品的思路來嘗試解決一些新問題,以及對老問題的解法「re-design」。由于篇幅有限,第一部分只能先鋪墊一些淺層次的知識,感知的也注定只是一些淺層次的線索。同時,第一部分的所有思路都不是任何一個人的功勞,是多少個日夜大家一起碰撞后的成果。他們是:

@碳基體、@Rainy_zh、@zhouxiangrong、@mkods、@醬油男高漸離、@yuklin_、@破-見、@FlyR4nk、@fangzheng_rhw、@_X110、@ThomasBright、@Olonglong、@楚安、@tata

1. 異常模型

1.1 參數異常模型

回顧一下Web威脅中的幾大類攻擊,SQLi、XSS、RCE……等雖然攻擊方式各不相同,但基本都有一個通用的模式,即通過對參數進行注入payload來進行攻擊,參數可能是出現在GET、POST、COOKIE、PATH等等位置。所以第一個異常模型,我們希望能覆蓋掉參數中出現的異常,這樣就能覆蓋掉很大一部分的常見的Web攻擊。

1.1.1 模型原理

假設有這樣一條url:www.xxx.com/index.php?id=123。如果我們拉出所有這條url的訪問記錄,不難發現:正常用戶的正常請求雖然不一定完全相同,但總是彼此相似;攻擊者的異常請求總是彼此各有不同,同時又明顯不同于正常請求。

正常總是基本相似 異常卻各有各的異常

正常總是基本相似,異常卻各有各的異常。基于這樣一條觀測經驗,如果我們能夠搜集大量參數id的正常的參數值,建立起一個能表達所有正常值的正常模型,那么一切不滿足于該正常模型的參數值,即為異常。

異常由正常決定

如果我們把參數id的每個參數值看作一個序列(Sequence),那么參數值中的每個字符就是這個序列中的一個狀態(State)。同時,對于一個序列,為123或者124甚至是345,其背后所表達的安全上的解釋都是「數字 數字 數字」,我們用「N」來表示「數字」,這樣就得到了對應的隱含序列。

參數值安全上的解釋

到這里已經隱約看到了隱馬爾可夫的影子。對于數字我們用N來表示,相應的對于其他unicode字符,也做類似的泛化對應關系。英文字符、中文字符、中文標點字符以及其他語言的所有字符對應狀態「A」,對控制字符以及英文標點字符,對應隱含狀態為自身。

觀測序列與隱含序列

這樣做的原因是因為通常一個參數注入式的Web攻擊payload是由一些攻擊關鍵詞,加上一些特殊符號構成。特殊符號起到閉合前后正常語句,分隔攻擊關鍵詞的作用。通常這些特殊字符為英文標點符號、控制字符等,所以對這些字符不做泛化的對應。

XSS payload

但是,也有一些特殊情況,如上幾個XSS payload是利用了字符集編碼轉換:故也可以考慮對「??シセ??……」等幾個特殊字符單做處理。

隱馬爾可夫模型

回顧一下HMM的三類應用:

解碼問題,根據模型參數和觀測序列,找出該觀測序列最優的隱含狀態序列;評估問題,根據模型參數和觀測序列,計算該觀測序列是由該模型生成的概率;學習問題,根據一系列觀測序列,建立對應該系列序列最優的HMM模型。

這里我們只用得到后兩個。在訓練階段,對應「學習問題」,用大量正常的參數值訓練出站點www.xxx.com下index.php下的參數id的HMM模型;在檢測階段,對應「評估問題」,待檢測的參數值帶入模型檢測是否是正常。

參數異常模型

不同的參數,正常的值不同。同時,有參數傳遞的地方,就有可能發生參數注入型攻擊。所以,需要對站點下所有路徑下,所有GET、POST、PATH、COOKIE中的所有參數都訓練各自的正常模型。另外,對參數名本身,也訓練其正常的模型,見如下case:

dedecms payload

1.1.2 工程實現

整個模型包含4個主要模塊,抽取器「Extractor」、訓練器「Trainer」、檢測器「Detector」、重訓練器「reTrainer」。

對每條Http原始日志,先經過Extractor進行參數拆解,各種ETL,解碼等處理。這一步是最容易描述但確是最難做好的。比如URL中雖然都是百分號編碼,但字符集卻有GBK、UTF-8、GB2312等等,如何選擇正確的字符集來解碼?再比如POST傳遞參數,可以通過urlencoded、multipart/form-data、json或xml等,如何保證能夠正確的提取?

Extractor

良好的數據質量,才能保證上層建筑的精準。有句話是這么說的「寧愿去洗廁所,也不寧愿洗數據」,但是不經歷過數據之臟,如何有資格經歷數據之美?「Extractor」出來的數據,根據是否已經有對應的訓練好的模型,拆分為兩部分,沒有對應模型的數據進入Trainer開始訓練流程。

Extractor 分割

上文中我們提到,我們要訓練的是正常參數值從而得到正常模型。這就需要保證進入訓練集中的數據都必須是正常數據。如果都是異常數據,那么得到的將是關于異常的模型,也就是說模型將會被污染。那么問題來了,如何在不知道什么是正常的情況下保證正常?

Trainer 過濾

第一步,對某個ip,只要其當天內所有請求中有一條命中了WAF,其余所有請求不管是正常的還是異常的,均不進入Trainer;如果某個ip命中掃描器特征或掃描器行為(這個模型將在另外一篇文章中介紹),該ip所有請求也不進入Trainer。

Trainer 抽樣

第二步,對每個要訓練的參數,每個ip每天只能貢獻一次參數值。這樣能保證上述過濾失效的情況下也只能有一條異常數據混進該參數的Trainer中。只要大多數進入訓練池的數據是正常的,那么對模型的影響也不大。這就是「正常由大多數投票表決來決定」。同時,每個參數的訓練池有最低條數的限制,沒達到條數限制的參數不做訓練,繼續等待更多的數據進入Trainer。

有最低限制,就相應的有最高限制,對于部分數據量很大的參數,過多的訓練數據會導致訓練時間太長。對這種情況,我們再做一個分層抽樣。

觀測序列與隱含序列

在模型原理部分我們提到觀測序列與隱含序列的對應關系,但在工程實現中這樣去做,會存在很大的問題 。比如訓練集中id參數的觀測序列全為「123abc」,相應的隱含序列為「NNNAAA」,訓練好模型后,待檢測序列為「124abc」。由于「4」這個觀測狀態不在訓練集的狀態空間中,所以會被直接判定為異常。

工程實現中的觀測狀態數與隱含狀態數

但事實上我們并不需要這么「敏感」的異常。所以我們直接使用泛化后的序列「NNNAAA」作為觀測序列,而隱含狀態數取訓練集中所有觀測序列的觀測狀態數均值四舍五入。

模型完成訓練后,需要設定一個異常的閾值。什么樣的概率值的序列為異常?0.8,0.5?如果訓練集中所有參數值均為正常,那么只需取訓練集中的最低概率值為閾值即可。但即便之前我們做了這么多步,也是有可能混入一兩條異常數據進入訓練集的。這里我們可以簡單的使用3sigma來抵消,如果最低概率值位于3sigma區間外,取次低概率值,再求3sigma,如此反復。

「Trainer」部分結束后,開始「Detector」部分。從「Extractor」出來的有對應Model的數據,直接開始檢測,如果概率P<異常概率閾值H – epsilon小量,則認為是異常,epsilon = (1/100) H。異常的數據最終再由data_id還原出對應的原始Http數據。

任何模型都有衰減期,尤其是攻防模型。昨天的異常不一定今天就是異常,這就需要有一個重訓練模塊「reTrainer」來持續迭代訓練模型,用以抵消衰減的影響。比如/index.php?id=123在訓練時id為123是正常的,但之后該Web應用修改了代碼,正常的參數值變成了/index.php?id=abc+||+123,如果模型一層不變,所有之后的abc++123都會被認為是異常。

reTrainer

那么什么時候需要開始重訓練呢?當過去的「大多數」已經不能代表現在的「大多數」的時候。若大量不同人對某個參數出現大量相同序列的異常,且這些異常都不會命中威脅模型(下一節將介紹到)。同時,數量上遠大于對應的模型的訓練集中的數據量,訓練集中的參數值序列也持續一段時間沒有再出現過,則將這部分異常開始重訓練。至此,整個參數異常模型部分結束。

參數異常模型流程

1.2 節點異常模型

不能寄希望于一個模型就能覆蓋掉所有攻防上的異常,比如Webshell、敏感文件下載等這類Web威脅,在參數異常模型中,不會觸發任何異常。所以,我們考慮從另一個角度,來覆蓋這類節點異常。

1.2.1 模型原理

如果把站點看作一張大圖,站點下的每個頁面為這張大圖中的每個節點,而不同頁面之間的鏈接指向關系為節點與節點之間的有向邊,那么我們能畫出如下這張有向圖:

Web Directed Graph

節點是否是異常,由其所處的環境中的其他節點來決定。類似一個簡化版的PageRank,如果大量其他節點指向某個節點(入度較大),那么該節點是異常的概率就很小。相反,如果一個節點是Graph中的孤立點(入度為0),則是異常的概率就很大。

單有這張有向圖還不夠,諸如/robots.txt、/crossdomain.xml之類的正常節點卻又無其他節點指向的情況太多了,這個層面的異常能表達的信息量太少,所以我們還需要引入另一個異常。

通常一個異常節點(如Webshell),大多數正常人是不會去訪問的,只有少量的攻擊者會去訪問(這里不考慮修改頁面寫入webshell的情況,這個模型不能覆蓋這類case)。用一個簡單的二部有向圖就能很好表達。入度越少的節點,同樣越有可能是異常。

節點異常模型

聯合兩張圖中的異常,其聯合異常就會比單獨任一張圖產出的異常更具表達力。該模型較為簡單,不再贅述。

1.2.2?工程實現

整個模型包含3個主要模塊,抽取器「Extractor」、訓練器「Trainer」、檢測器「Detector」。對每條Http原始日志,同樣先經過「Extractor」進行路徑抽取,各種ETL,解碼等處理。這里需要由于有向圖中的邊關系由referer->path來確定,而referer是可以輕易偽造的,所以,需要對fake referer做個檢測。

Session Navigation Pattern

先做一個session identification,對每個session塊中的數據,分析其導航模式。正常的referer必然會出現在當前session中之前的path數據中,同時,能夠與當前session之前的數據形成連通路徑。當然,導航模式并不能完全檢測所有的偽造referer,攻擊者完全可以先訪問A,再構造一個referer為A訪問B的請求。不過沒關系,后面還有方法能避免這些數據進入Trainer。

「Extractor」出來后的數據,直接進入「Detector」,Detector檢測path是否在有向圖中,如果在,則更新有向圖中節點的最后訪問時間;如果不在則認為是有向圖異常,進入到二部圖中。二部圖維護一個N天的生命周期,如果某path節點總的入度小于L,則為最終異常。

「Trainer」每天從二部圖中過濾掉當天命中WAF、掃描器特征或掃描器行為的源ip所有請求,若節點總入度大于M的節點,則迭代節點極其鏈接關系加入到有向圖中,并在二部圖中去除該節點以及對應邊。同時,對于有向圖中最后訪問時間超過30天的節點直接丟棄。

節點異常模型 流程

2. 威脅模型

2.1 攻擊識別

99%的異常事實上都不是什么攻擊,異常的發現并不難,難的是對異常的解讀,或者說賦予異常一個安全業務上的解釋。理論上來說,如果能有足夠豐富的各個層面的數據,能夠對每個異常都做出一個合理的解釋。

上文中我們提到,多數的普通Web攻擊都是由「特殊字符」加上「攻擊關鍵詞」這種模式構成。而參數異常模型本身就能夠很好的表達「特殊字符」,剩下的我們其實只要能表達「攻擊關鍵詞」這一層的信息即可。

所以我們想嘗試在參數異常數據的基礎上,注入一些領域知識,從而構成一個分類器,從異常中剝離出攻擊,并且能夠對不同種類的攻擊進行分類。但我們又不太想人為構造樣本人工打標記,因為這樣又會帶來一些個體因素的影響,我們希望能用真實世界中的流量來獲得領域知識。

首先第一步,我們先從WAF中提取近幾年的數據,對各個類別的攻擊payload做一個簡單的分詞。然后再從參數異常模型的歷史數據中提取大量的「絕對正常」樣本,也做一個簡單的分詞。顯而易見,如果某一個詞(Term)在一類攻擊payload樣本中出現的次數越多,那么我們認為該詞與該類攻擊的相關程度越大。同時,不同的詞的重要程度是不同的,如果該詞只在這類攻擊中出現,而在正常樣本中幾乎沒有出現,那么該詞對與該類攻擊重要性更高。

TF-IDF

自然就聯想到了TF-IDF。數學意義上,TF用來表達相關程度,IDF用來表達重要程度。在TF中,分子部分,表示i這個term在攻擊類別j中出現的次數。為了避免對「短payload攻擊」的不利,需要將詞數(term count)轉換為詞頻(term frequency),所以分母部分表示在攻擊類別j中所有term出現的總次數。在IDF中,分子部分表示所有樣本庫中(包含正常和攻擊)的樣本總數,分母部分表示包含term的樣本數,加1是為了避免為0,取對數是為了表達tearm的信息量。最終TF與IDF二者相乘,用來刻畫一個term對該類攻擊的描述程度。

接下來就涉及到分類器的選擇,事實上我們在測試了多個分類器后,發現在該場景下,僅僅就用簡單的基于規則的分類器就已能滿足大部分的情況。如果還想繼續提高精度,可以嘗試再表達term與term之間的順序關系,如二元gram、長亭科技提到的基于編譯原理的語法分析等等。另外一種思路是直接描述整個payload的「結構」特征。例如如下兩個payload,如果采用類似參數異常模型中對序列泛化的思路(長度上也做壓縮泛化),將得到一條相同的泛化序列:

payload 結構

不難發現,其結構上是相同的。事實上我們抽取了WAF 1000w+真實環境中的SQLi payload分析后發現,其泛化后的序列只有幾萬。所以從「結構」這條路上去探索,也是個不錯的選擇。

2.2 識別成功的攻擊

在異常中,99%的異常都不是攻擊,而在攻擊中,99%的攻擊又都是無害的攻擊。而我們的精力總是有限的,我們希望能關注那些危害程度更高的攻擊,這就迫使我們需要從攻擊中識別出哪些是成功的攻擊。

Kill Chain的思想本身是很好的,在攻擊者的攻擊鏈路上的幾個關鍵節點,如果能串聯起來,說明這是一次成功的攻擊。但是Kill Chain設計最初是為了檢測APT,所以在Web威脅中,我們只需要借鑒這種思路,而沒必要生搬硬套7個階段。

Kill Chain Model

Kill Chain的本質還是多源異構數據的關聯,攻擊路徑上不同層面的數據來建立聯系。我們可以采用很簡單的二步驗證,如,一個Http層出現的SQLi paylaod,相同的payload同時出現在SQL層的異常,即形成一個確認的SQLi攻擊;同理,一個Http層的異常相同的payload出現在了命令日志層面的異常中,即形成一個確認的RCE。(對于其他非Http層數據的異常,會在之后的文章中介紹)

異構數據關聯

相同的思路,我們也可以同安全產品的數據來關聯。如,關聯WAF數據,關聯不上的即為WAF Bypass;成功的攻擊數據同掃描器數據來關聯,關聯不上的即為掃描器漏報等等。

2.3 CMS Nday識別

涉及到Http這一層的數據,想必大家最感興趣的,就是如何挖掘出一些Web CMS Nday。值得一提的是,如果只是挖出一些「可能」是Nday的請求,意義并不是很大,在大規模的環境中這樣的請求每天實在是太多了,多到讓人力不從心。抽象這個過程,我們希望能做到兩點:1. 明確知道這是一個Nday;2. 明確知道這是哪個CMS的Nday。

Nday首先一定是一個攻擊,所以不需要再從異常數據開始,攻擊分類器中出來的數據可以直接作為源數據。但反過來攻擊卻不一定是Nday,通常情況下,大多數Nday是帶Exp性質而非PoC性質的。比如SQLi的CMS Nday多數是直接讀管理員表數據之類的「利用」行為,而非是「and 1=1」之類的「證明」行為。

而對于第二點,「知道這是哪個CMS」背后對應的其實是一個Web應用指紋識別的過程,不過比傳統的應用指紋識別更具挑戰的是,因為無法知道哪個頁面會出現Nday,所以只能通過一條Http數據,就要識別出對應的CMS。

另外,如果站在攻擊者角度來考慮的話,Nday通常不會只出現在一個站點上。這一點很重要,能幫助我們過濾掉很多噪聲數據的同時,也能讓我們感知某個Nday是否在大規模利用。

Nday 行為

我們先從SQLi Nday嘗試入手,觀察如下這條payload:

SQLi Nday

多數的SQLi Nday,都會有一個「from xxx」的pattern,而xxx為具體某個CMS數據庫的表名,同時payload中也會出現CMS數據庫的字段名。豁然開朗,我們需要做的,其實只是建立一個CMS DB Schema指紋庫,以CMS表名和字段名作為指紋。一舉兩得,既能判定出是Nday,又能同時找到對應的CMS。

下面再來看看GetShell類型的Nday。多數的Getshell Nday,都會有「<? eval」「<? fputs」之類的webshell代碼特征,或者是文件包含特征等等。同時,我們可以取路徑以及參數名作為uri指紋用來識別CMS。

GetShell Nday

db指紋很容易建立,相比之下uri指紋就不那么容易建立了,我們需要借力于Web指紋識別產品。從指紋識別產品中提取CMS為wordpress的站點top 10000個,然后提取這1w個站點7天內的所有200的請求。去參數值后,分別對每條uri提取路徑指紋和參數值指紋。只有多個wordpress站點都同時具有該指紋,并且其他CMS沒有該指紋的,才最終進入wordpress的uri指紋庫。同理,其他CMS的建立過程也類似。

CMS Nday 識別流程

整個識別流程如上圖所示。先取出攻擊分類器中出來的攻擊數據,并且這些uri+payload出現在了多個站點上。緊接著,滿足SQLi pattern的數據同db指紋庫匹配,得到SQLi Nday;滿足GetShell pattern的數據同uri指紋庫匹配,得到GetShell Nday。

2.4 Webshell識別

以上幾個場景都是基于參數異常的數據的應用,而對于節點異常數據,最為直接的應用就是識別Webshell。先來回想一下,安全工程師在做入侵復盤時怎么來確認一個url是否為webshell:1.從Http數據中發現一個url有點「異常」;2.訪問一下該uri,通過安全經驗知識從返回頁面識別出是webshell(大馬);3.如果返回頁面為空白(疑似一句話),從代碼層面來識別。

2.4.1 大馬識別

先來看一下大馬的識別。對于第一點節點異常數據已有,而第二點,本質上其實是引入response層面信息做網頁相似度計算。對于相似度計算,不妨先將問題退化為「網頁相同計算」。

webshell phpspy

問題變得非常好解。搜集大量的webshell樣本,訓練階段對response數據計算md5,檢測時對待檢測樣本同樣算md5比對即可。顯而易見,這種方法準確率極高,同樣缺陷也足夠明顯,嚴重依賴訓練樣本庫,也就是只能檢測已知,不能感知未知。

而人總是貪婪的,一方面我們既想對已知保持高的檢測精度,同時又希望能保持一些對未知的感知能力。自然而然就想到了simhash之類的LSH。類似md5、sha1之類的屬于加密型hash,其設計的目的是為了讓整個分布盡可能地均勻。所以對輸入極其敏感,輕微變化的輸入,就會導致輸出大不一樣。而我們更希望對相似的輸入,產生相似的輸出。從而通過對輸出做相似計算,就能反映出輸出的相似性。然而事實上simhash在這個場景下效果并不是很好,原因是simhash主要適用于文本內容的相似性檢測。

拋開全文hash的想法,有一類方法是去關注全文中的片段。直觀經驗告訴我們,如果兩個全文比較相似,那么全文中的部分全片,也很有可能很相似。反過來我們如果能計算出片段的相似或相同,進而就能得到全文的相似性。在網頁判重領域,有一種簡單而又有效的方法叫做最長句子簽名。取網頁內容中最長的top3的句子作為簽名,檢測時對簽名做比對或者計算編輯距離。

webshell特征碼識別

同樣,殺毒領域的特征碼技術也是類似的思想。應用到webshell檢測的場景下就是,隨機或特意的選取webshell response中多個片段作為片段指紋,記錄下偏移位置和特征值,用來表征該webshell。這類方法都具有較高的對已知的檢測精度,缺點依然是對新樣本感知能力尚不夠。

回到業務場景,一個網頁主要包含兩大部分:網頁結構和網頁內容。通常情況下,黑客對自己使用的webshell會做各種修改,但修改的大多都是網頁內容,而不會去動網頁結構。所以其實我們在該場景下更需要關注結構的相似而不是內容的相似。

(注:以下思路和模型均歸屬李景陽先生專利所有[1])要做結構的相似計算,首先我們需要對整個DOM結構找一個合適的數學對象來描述。常見的適合比較運算的數學對象有標量、向量、矩陣等,借鑒Vector Space Model的思想,我們選用高維向量來描述DOM結構。VSM中以一個詞項作為向量空間的一個維度,詞頻作為權重,得到高維向量V(d)=(t1,ω1(d),…, (tn, ωn(d))。對應到DOM結構中,我們嘗試用N-gram片段來描述每個維度的向量。

每個tag作為一元gram,相鄰兄弟tag和相鄰父子tag作為二元gram,去除掉如html、head、body之類的通用tag。同時,僅僅使用tag名稱會損失掉很多表達結構樣式的信息,所以我們取tag+部分表達格式的屬性,hash之后映射到某一維度。同時,對不同的gram賦予不同的權值,用來體現其表達結構特點的能力,最終得到一個高維實向量。

特征向量抽取

直接計算高維向量一方面不同網頁結構大小各有不同,形成的向量會變得很稀疏,另一方面,過高的維度也會帶來「維數災難」,所以我們還需要做一個降維處理。但在該場景下,沒必要用太復雜的降維或projection手法,直接對M取模,將N維向量折疊壓縮到M維即可。

構造好低維實向量,接下來就該定義相似度計算了。直觀上,歐式距離和余弦距離是最容易想到的兩種計算向量相似的距離。但是對長網頁歐式明顯不公平,而余弦只關注向量夾角的差異性不關注絕對長度上的差異,也就是說只關注tag之間的比例而非絕對數值,又會存在存在對長網頁過分抑制。所以綜合考慮,我們借鑒杰卡德相似的思想,定義偽距離如下,表達的物理意義為兩個網頁相同部分與不同部分的比值。

定義偽距離

有了向量和相似性計算,我們就不得不面臨一個工程問題,這種笛卡爾積式的兩兩比較,在大規模環境中來應用就是災難。回想一下生物指紋識別領域中的待識別指紋同指紋庫中指紋匹配的過程:1.先比對指紋的模式區、核心區等大的總體特征;2.滿足總體特征的,再比對特征點等局部特征。借鑒此思想,我們可以對離散的樣本數據構造一個網格計算。

在向量空間中定義一套超立方網格,把空間切割成多個超網格,以超網格中心座標來表示其自身。對于待檢測樣本,先計算其會落到哪個超網格,然后再同該超網格中的訓練樣本進行一一比對,最終找到最相似的樣本。但是需要注意的是,一套網格會出現「區域隔離」的問題,可以通過構造不同的多套網格來避免。

離散樣本網格化

如圖T1是待檢測網頁的特征向量,在紅色網格中,命中了超網格L1,進而找到在紅色網格中最相似樣本為S1。而在黑色網格中,同樣的方法找到了樣本S2。最終再來比較與S1、S2的偽距離,得到最相似樣本S2。

2.4.2 一句話webshell識別

對于一句話webshell,response層面數據不需要做太復雜的模型,簡單的特征匹配就足夠。或者也可以采用2.2中二步驗證的方法來驗證。如,聯合主機agent做代碼層面的關聯,或者關聯命令日志異常,又或者關聯2.3中的GetShell Nday等等。

結語

在本文的最后,我們想表達一些對于數據驅動安全的看法。盡管在上文中我們介紹的都是模型在安全業務上的應用,但我們想強調的一點是,數據驅動的安全,一定不是靠模型來驅動。對模型的趨之若鶩與過于迷信,掩蓋的是對數據對威脅的認知不足。在安全數據科學領域,只有對業務領域有充分認識的前提下,才有可能將數學上的解釋對應到安全上的解釋,從而才有可能產生一些有用的淺層線索。

但是永遠記得,多數情況下模型產生的也只是淺層線索,最終數據驅動安全的頂層設計,一定是充分發揮機器智能與人的智能,機器做機器擅長的計算而人完成人擅長的分析。有機的結合二者,才能成為對抗威脅不對稱的強力武器。所以在之后的文章中,我們希望能夠回歸數據本身,探索一些數據與數據之間的聯系,以及通過這些聯系我們能感知什么。

本文中提到的這些嘗試永遠只能覆蓋小部分淺層的Web攻擊,同復雜而又殘酷的黑產威脅相比,這些都還只能算「溫室里的寶寶,把玩著自己的小玩具」。我們開開心心的在充滿陽光的溫室里搭建著自己的小城堡,以為以此就能抵擋得了小怪獸。但殊不知黑產的攻擊面,大多根本不在溫室里。而溫室的外面,沒有熟悉的陽光,有的只有一無所知的黑暗。需要我們去探索的還有很多,對于未知,我們都才剛剛起步。

參考

[1] 李景陽 張波. 網頁結構相似性確定方法及裝置

[2] 威脅感知的方法論