淺談大型網際網路企業入侵檢測及防護政策

本人轉自美團安全技術團隊,原文連結https://tech.meituan.com/2018/11/08/intrusion-detection-security-meituan.html

１.前言

如何知道自己所在的企業是否被入侵了？是沒人來“黑”，還是因自身感覺能力不足，暫時還無法發現？其實，入侵檢測是每一個大型網際網路企業都要面對的嚴峻挑戰。價值越高的公司，面臨入侵的威脅也越大，即便是Yahoo這樣的網際網路鼻祖，在落幕（被收購）時仍遭遇全量資料失竊的事情。安全無小事，一旦網際網路公司被成功“入侵”，其後果将不堪想象。

基于“攻防對抗”的考量，本文不會提及具體的入侵檢測模型、算法和政策，那些希望直接照搬“入侵政策”的同學可能會感到失望。但是我們會将一部分營運思路分享出來，請各位同行指點，如能對後來者起到幫助的作用，那就更好了，也歡迎大家跟我們交流探讨。

２.入侵的定義

典型的入侵場景：

黑客在很遠的地方，通過網絡遠端控制目标的筆記本電腦/手機/伺服器/網絡裝置，進而随意地讀取目标的隐私資料，又或者使用目标系統上的功能，包括但不限于使用手機的麥克風監聽目标，使用攝像頭偷窺監控目标，使用目标裝置的計算能力挖礦，使用目标裝置的網絡能力發動DDoS攻擊等等。亦或是破解了一個服務的密碼，進去檢視敏感資料、控制門禁/紅綠燈。以上這些都屬于經典的入侵場景。

我們可以給入侵下一個定義：就是黑客在未經授權的情況下，控制、使用我方資源（包括但不限于讀寫資料、執行指令、控制資源等）達到各種目的。從廣義上講，黑客利用SQL注入漏洞竊取資料，或者拿到了目标域名在ISP中的帳号密碼，以篡改DNS指向一個黑頁，又或者找到了目标的社交帳号，在微網誌/QQ/郵箱上，對虛拟資産進行非授權的控制，都屬于入侵的範疇。

3.針對企業的入侵檢測

企業入侵檢測的範圍，多數情況下比較狹義：一般特指黑客對PC、系統、伺服器、網絡（包括辦公網、生産網）控制的行為。

黑客對PC、伺服器等主機資産的控制，最常見的方法是通過Shell去執行指令，獲得Shell的這個動作叫做GetShell。

比如通過Web服務的上傳漏洞，拿到WebShell，或者利用RCE漏洞直接執行指令/代碼（RCE環境變相的提供了一個Shell）。另外，通過某種方式先植入“木馬後門”，後續直接利用木馬內建的SHELL功能對目标遠端控制，這個也比較典型。

是以，入侵檢測可以重點關注GetShell這個動作，以及GetShell成功之後的惡意行為（為了擴大戰果，黑客多半會利用Shell進行探測、翻找竊取、橫向移動攻擊其它内部目标，這些差別于好人的特性也可以作為重要的特征）。

有一些同行（包括商業産品），喜歡報告GetShell之前的一些“外部掃描、攻擊探測和嘗試行為”，并美其名曰“态勢感覺”，告訴企業有人正在“試圖攻擊”。在筆者看來，實戰價值并不大。包括美團在内的很多企業，基本上無時無刻都在遭受“不明身份”的攻擊，知道了有人在“嘗試”攻擊，如果并不能有效地去行動，無法有效地對行動進行告警，除了耗費心力之外，并沒有太大的實際價值。

當我們習慣“攻擊”是常态之後，就會在這樣的常态下去解決問題，可以使用什麼加強政策，哪些可以實作常态化的營運，如果有什麼政策無法常态化營運，比如需要很多人加班臨時突擊守着，那這個政策多半在不久之後就會逐漸消逝掉。跟我們做不做這個政策，并沒有本質上的差別。

類似于SQL注入、XSS等一些不直接GetShell的Web攻擊，暫時不在狹義的“入侵檢測”考慮範圍，建議可以劃入“漏洞”、“威脅感覺”等領域，另行再做探讨。當然，利用SQL注入、XSS等入口，進行了GetShell操作的，我們仍抓GetShell這個關鍵點，不必在乎漏洞入口在何處。

4.“入侵”和“内鬼”

與入侵接近的一種場景是“内鬼”。入侵本身是手段，GetShell隻是起點，黑客GetShell的目标是為了之後對資源的控制和資料的竊取。而“内鬼”天然擁有合法的權限，可以合法接觸敏感資産，但是基于工作以外的目的，他們對這些資源進行非法的處置，包括拷貝副本、轉移外洩、篡改資料牟利等。

内鬼的行為不在“入侵檢測”的範疇，一般從内部風險控制的視角進行管理和審計，比如職責分離、雙人審計等。也有資料防洩密産品（DLP）對其進行輔助，這裡不展開細說。

有時候，黑客知道員工A有權限接觸目标資産，便定向攻擊A，再利用A的權限把資料竊取走，也定性為“入侵”。畢竟A不是主觀惡意的“内鬼”。如果不能在黑客攻擊A的那一刻捕獲，或者無法區分黑客控制的A竊取資料和正常員工A的通路資料，那這個入侵檢測也是失敗的。

5.入侵檢測的本質

前文已經講過，入侵就是黑客可以不經過我們的同意，來操作我們的資産，在手段上并沒有任何的限制。那麼如何找出入侵行為和合法正常行為的差別，将其跟合法行為進行分開，就是“入侵發現”。在算法模型上，這算是一個标記問題（入侵、非入侵）。

可惜的是，入侵這種動作的“黑”樣本特别稀少，想通過大量的帶标簽的資料，有監督的訓練入侵檢測模型，找出入侵的規律比較難。是以，入侵檢測政策開發人員，往往需要投入大量的時間，去提煉更精準的表達模型，或者花更多的精力去構造“類似入侵”的模拟資料。

一個經典的例子是，為了檢測出WebShell，安全從業人員可以去GitHub上搜尋一些公開的WebShell樣本，數量大約不到1000個。而對于機器學習動辄百萬級的訓練需求，這些資料遠遠不夠。況且GitHub上的這些樣本集，從技術手法上來看，有單一技術手法生成的大量類似樣本，也有一些對抗的手法樣本缺失。是以，這樣的訓練，試圖讓AI去通過“大量的樣本”掌握WebShell的特征并區分出它們，原則上不太可能完美地去實作。

此時，針對已知樣本做技術分類，提煉更精準的表達模型，被稱為傳統的特征工程。而傳統的特征工程往往被視為效率低下的重複勞動，但效果往往比較穩定，畢竟加一個技術特征就可以穩定發現一類WebShell。而構造大量的惡意樣本，雖然有機器學習、AI等光環加持，但在實際環境中往往難以獲得成功：自動生成的樣本很難描述WebShell本來的含義，多半描述的是自動生成的算法特征。

另一個方面，入侵的差別是看行為本身是否“授權”，而授權與否本身是沒有任何顯著的區分特征的。是以，做入侵對抗的時候，如果能夠通過某種加強，将合法的通路收斂到有限的通道，并且給該通道做出強有力的區分，也就能大大的降低入侵檢測的成本。例如，對通路來源進行嚴格的認證，無論是自然人，還是程式API，都要求持有合法票據，而派發票據時，針對不同情況做多緯度的認證和授權，再用IAM針對這些票據記錄和監控它們可以通路的範圍，還能産生更底層的Log做異常通路模型感覺。

這個全生命周期的風控模型，也是Google的BeyondCorp無邊界網絡得以實施的前提和基礎。

是以，入侵檢測的主要思路也就有2種：

• 根據黑特征進行模式比對（例如WebShell關鍵字比對）。
• 根據業務曆史行為（生成基線模型），對入侵行為做異常對比（非白既黑），如果業務的曆史行為不夠收斂，就用加強的手段對其進行收斂，再挑出不合規的小衆異常行為。

6.入侵檢測與攻擊向量

根據目标不同，可能暴露給黑客的攻擊面會不同，黑客可能采用的入侵手法也就完全不同。比如，入侵我們的PC/筆記本電腦，還有入侵部署在機房/雲上的伺服器，攻擊和防禦的方法都有挺大的差別。

針對一個明确的“目标”，它被通路的管道可能是有限集，被攻擊的必經路徑也有限。“攻擊方法”+“目标的攻擊面”的組合，被稱為“攻擊向量”。

是以，談入侵檢測模型效果時，需要先明确攻擊向量，針對不同的攻擊路徑，采集對應的日志（資料），才可能做對應的檢測模型。比如，基于SSH登入後的Shell指令資料集，是不能用于檢測WebShell的行為。而基于網絡流量采集的資料，也不可能感覺黑客是否在SSH後的Shell環境中執行了什麼指令。

基于此，如果有企業不提具體的場景，就說做好了APT感覺模型，顯然就是在“吹噓”了。

是以，入侵檢測得先把各類攻擊向量羅列出來，每一個細分場景分别采集資料（HIDS+NIDS+WAF+RASP+應用層日志+系統日志+PC……），再結合公司的實際資料特性，作出适應公司實際情況的對應檢測模型。不同公司的技術棧、資料規模、暴露的攻擊面，都會對模型産生重大的影響。比如很多安全工作者特别擅長PHP下的WebShell檢測，但是到了一個Java系的公司……

7.常見的入侵手法與應對

如果對黑客的常見入侵手法了解不足，就很難有的放矢，有時候甚至會陷入“政治正确”的陷阱裡。比如滲透測試團隊說，我們做了A動作，你們竟然沒有發現，是以你們不行。而實際情況是，該場景可能不是一個完備的入侵鍊條，就算不發現該動作，對入侵檢測效果可能也沒有什麼影響。每一個攻擊向量對公司造成的危害，發生的機率如何進行排序，解決它耗費的成本和帶來的收益如何，都需要有專業經驗來做支撐與決策。

現在簡單介紹一下，黑客入侵教程裡的經典流程（完整過程可以參考殺傷鍊模型）：

入侵一個目标之前，黑客對該目标可能還不夠了解，是以第一件事往往是“踩點”，也就是搜集資訊，加深了解。比如，黑客需要知道，目标有哪些資産（域名、IP、服務），它們各自的狀态如何，是否存在已知的漏洞，管理他們的人有誰（以及如何合法的管理的），存在哪些已知的洩漏資訊（比如社工庫裡的密碼等）……

一旦踩點完成，熟練的黑客就會針對各種資産的特性，醞釀和逐個驗證“攻擊向量”的可行性，下文列舉了常見的攻擊方式和防禦建議。

7.1高危服務入侵

所有的公共服務都是“高危服務”，因為該協定或者實作該協定的開源元件，可能存在已知的攻擊方法（進階的攻擊者甚至擁有對應的0day），隻要你的價值足夠高，黑客有足夠的動力和資源去挖掘，那麼當你把高危服務開啟到網際網路，面向所有人都打開的那一刻，就相當于為黑客打開了“大門”。

比如SSH、RDP這些運維管理相關的服務，是設計給管理者用的，隻要知道密碼/秘鑰，任何人都能登入到伺服器端，進而完成入侵。而黑客可能通過猜解密碼（結合社工庫的資訊洩露、網盤檢索或者暴力破解），獲得憑據。事實上這類攻擊由于過于常見，黑客早就做成了全自動化的全網際網路掃描的蠕蟲類工具，雲上購買的一個主機如果設定了一個弱密碼，往往在幾分鐘内就會感染蠕蟲病毒，就是因為這類自動化的攻擊者實在是太多了。

或許，你的密碼設定得非常強壯，但是這并不是你可以把該服務繼續暴露在網際網路的理由，我們應該把這些端口限制好，隻允許自己的IP（或者内部的堡壘主機）通路，徹底斷掉黑客通過它入侵我們的可能。

與此類似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等，凡是自己用來管理伺服器或者資料庫、檔案的服務，都不應該針對網際網路無限制的開放。否則，蠕蟲化的攻擊工具會在短短幾分鐘内攻破我們的服務，甚至直接加密我們的資料，甚至要求我們支付比特币，進行敲詐勒索。

還有一些高危服務存在RCE漏洞（遠端指令執行），隻要端口開放，黑客就能利用現成的exploit，直接GetShell，完成入侵。

防禦建議： 針對每一個高危服務做入侵檢測的成本較高，因為高危服務的具體所指非常的多，不一定存在通用的特征。是以，通過加強方式，收斂攻擊入口成本效益更高。禁止所有高危端口對網際網路開放可能，這樣能夠減少90%以上的入侵機率。

7.2 Web入侵

随着高危端口的加強，黑客知識庫裡的攻擊手法很多都會失效了。但是Web服務是現代網際網路公司的主要服務形式，不可能都關掉。于是，基于PHP、Java、ASP、ASP.NET、Node、C寫的CGI等等動态的Web服務漏洞，就變成了黑客入侵的最主要入口。

比如，利用上傳功能直接上傳一個WebShell，利用檔案包含功能，直接引用執行一個遠端的WebShell（或者代碼），然後利用代碼執行的功能，直接當作Shell的入口執行任意指令，解析一些圖檔、視訊的服務，上傳一個惡意的樣本，觸發解析庫的漏洞……

Web服務下的應用安全是一個專門的領域（道哥還專門寫了本《白帽子講Web安全》），具體的攻防場景和對抗已經發展得非常成熟了。當然，由于它們都是由Web服務做為入口，是以入侵行為也會存在某種意義上的共性。相對而言，我們比較容易能夠找到黑客GetShell和正常業務行為的一些差別。

針對Web服務的入侵痕迹檢測，可以考慮采集WAF日志、Access Log、Auditd記錄的系統調用，或者Shell指令，以及網絡層面Response相關的資料，提煉出被攻擊成功的特征，建議我們将主要的精力放在這些方面。

7.3 0day入侵

通過洩漏的工具包來看，早些年NSA是擁有直接攻擊Apache、Nginx這些服務的0day武器的。這意味着對手很可能完全不用在乎我們的代碼和服務寫成什麼樣，拿0day一打，神不知鬼不覺就GetShell了。

但是對于入侵檢測而言，這并不可怕：因為無論對手利用什麼漏洞當入口，它所使用的Shellcode和之後的行為本身依然有共性。Apache存在0day漏洞被攻擊，還是一個PHP頁面存在低級的代碼漏洞被利用，從入侵的行為上來看，說不定是完全一樣的，入侵檢測模型還可以通用。

是以，把精力聚焦在有黑客GetShell入口和之後的行為上，可能比關注漏洞入口更有價值。當然，具體的漏洞利用還是要實際跟進，然後驗證其行為是否符合預期。

7.4 辦公終端入侵

絕大多數APT報告裡，黑客是先對人（辦公終端）下手，比如發個郵件，哄騙我們打開後，控制我們的PC，再進行長期的觀察/翻閱，拿到我們的合法憑據後，再到内網漫遊。是以這些報告，多數集中在描述黑客用的木馬行為以及家族代碼相似度上。而反APT的産品、解決方案，多數也是在辦公終端的系統調用層面，用類似的方法，檢驗“免殺木馬”的行為。

是以，EDR類的産品+郵件安全網關+辦公網出口的行為審計+APT産品的沙箱等，聯合起來，可以采集到對應的資料，并作出相似的入侵檢測感覺模型。而最重要的一點，是黑客喜歡關注内部的重要基礎設施，包括但不限于AD域控、郵件伺服器、密碼管理系統、權限管理系統等，一旦拿下，就相當于成為了内網的“上帝”，可以為所欲為。是以對公司來說，重要基礎設施要有針對性的攻防加強讨論，微軟針對AD的攻防甚至還發過專門的加強白皮書。

8.入侵檢測基本原則

不能把每一條告警都徹底跟進的模型，等同于無效模型。入侵發生後，再辯解之前其實有告警，隻是太多了沒跟過來/沒查徹底，這是“馬後炮”，等同于不具備發現能力，是以對于日均告警成千上萬的産品，安全營運人員往往表示很無奈。

我們必須屏蔽一些重複發生的相似告警，以集中精力把每一個告警都閉環掉。這會産生白名單，也就是漏報，是以模型的漏報是不可避免的。

由于任何模型都會存在漏報，是以我們必須在多個緯度上做多個模型，形成關聯和縱深。假設WebShell靜态文本分析被黑客變形繞過了，在RASP（運作時環境）的惡意調用還可以進行監控，這樣可以選擇接受單個模型的漏報，但在整體上仍然具備發現能力。

既然每一個單一場景的模型都有誤報漏報，我們做什麼場景，不做什麼場景，就需要考慮“成本效益”。比如某些變形的WebShell可以寫成跟業務代碼非常相似，人的肉眼幾乎無法識别，再追求一定要在文本分析上進行對抗，就是成本效益很差的決策。如果通過RASP的檢測方案，其成本效益更高一些，也更具可行性一些。

我們不太容易知道黑客所有的攻擊手法，也不太可能針對每一種手法都建設政策（考慮到資源總是稀缺的）。是以針對重點業務，需要可以通過加強的方式（還需要常态化監控加強的有效性），讓黑客能攻擊的路徑極度收斂，僅在關鍵環節進行對抗。起碼能針對核心業務具備兜底的保護能力。

基于上述幾個原則，我們可以知道一個事實，或許我們永遠不可能在單點上做到100%發現入侵，但是我們可以通過一些組合方式，讓攻擊者很難繞過所有的點。

當老闆或者藍軍挑戰，某個單點的檢測能力有缺失時，如果為了“政治正确”，在這個單點上進行無止境的投入，試圖把單點做到100%能發現的能力，很多時候可能隻是在試圖制造一個“永動機”，純粹浪費人力、資源，而不産生實際的收益。将節省下來的資源，高成本效益的布置更多的縱深防禦鍊條，效果顯然會更好。

9.入侵檢測産品的主流形态

入侵檢測終究是要基于資料去模組化，比如針對WebShell的檢測，首先要識别Web目錄，再對Web目錄下的檔案進行文本分析，這需要做一個采集器。基于Shell指令的入侵檢測模型，需要擷取所有Shell指令，這可能要Hook系統調用或者劫持Shell。基于網絡IP信譽、流量payload進行檢測，或者基于郵件網關對内容的檢查，可能要植入網絡邊界中，對流量進行旁路采集。

也有一些集大成者，基于多個Sensor，将各方日志進行采集後，彙總在一個SOC或者SIEM，再交由大資料平台進行綜合分析。是以，業界的入侵檢測相關的産品大緻上就分成了以下的形态：

主機Agent類：黑客攻擊了主機後，在主機上進行的動作，可能會産生日志、程序、指令、網絡等痕迹，那麼在主機上部署一個采集器（也内含一部分檢測規則），就叫做基于主機的入侵檢測系統，簡稱HIDS。

典型的産品：OSSEC、青藤雲、安騎士、安全狗，Google最近也釋出了一個Alpha版本的類似産品 Cloud Security Command Center。當然，一些APT廠商，往往也有在主機上的Sensor/Agent，比如FireEye等。

網絡檢測類：由于多數攻擊向量是會通過網絡對目标投放一些payload，或者控制目标的協定本身具備強特征，是以在網絡層面具備識别的優勢。

典型的産品：Snort到商業的各種NIDS/NIPS，對應到APT級别，則還有類似于FireEye的NX之類的産品。

日志集中存儲分析類：這一類産品允許主機、網絡裝置、應用都輸出各自的日志，集中到一個統一的背景，在這個背景，對各類日志進行綜合的分析，判斷是否可以關聯的把一個入侵行為的多個路徑刻畫出來。例如A主機的的Web通路日志裡顯示遭到了掃描和攻擊嘗試，繼而主機層面多了一個陌生的程序和網絡連接配接，最後A主機對内網其它主機進行了橫向滲透嘗試。

典型的産品：LogRhythm、Splunk等SIEM類産品。

APT沙箱：沙箱類産品更接近于一個雲端版的進階防毒軟體，通過模拟執行觀測行為，以對抗未知樣本弱特征的特點。隻不過它需要一個模拟運作的過程，性能開銷較大，早期被認為是“成本效益不高”的解決方案，但由于惡意檔案在行為上的隐藏要難于特征上的對抗，是以現在也成為了APT産品的核心元件。通過網絡流量、終端采集、伺服器可疑樣本提取、郵件附件提煉等拿到的未知樣本，都可以送出到沙箱裡跑一下行為，判斷是否惡意。

典型産品：FireEye、Palo Alto、Symantec、微步。

終端入侵檢測産品：移動端目前還沒有實際的産品，也不太有必要。PC端首先必備的是防毒軟體，如果能夠檢測到惡意程式，一定程度上能夠避免入侵。但是如果碰到免殺的進階0day和木馬，防毒軟體可能會被繞過。借鑒伺服器上HIDS的思路，也誕生了EDR的概念，主機除了有本地邏輯之外，更重要的是會采集更多的資料到後端，在後端進行綜合分析和關聯。也有人說下一代防毒軟體裡都會帶上EDR的能力，隻不過目前銷售還是分開在賣。

典型産品：防毒軟體有Bit9、SEP、賽門鐵克、卡巴斯基、McAfee ；EDR産品不枚舉了，騰訊的iOA、阿裡的阿裡郎，一定程度上都是可以充當類似的角色；

10.入侵檢測效果評價名額

首先，主動發現的入侵案例/所有入侵 = 主動發現率。這個名額一定是最直覺的。比較麻煩的是分母，很多真實發生的入侵，如果外部不回報，我們又沒檢測到，它就不會出現在分母裡，是以有效發現率總是虛高的，誰能保證目前所有的入侵都發現了呢？（但是實際上，隻要入侵次數足夠多，不管是SRC收到的情報，還是“暗網”上報出來的一個大新聞，把客觀上已經知悉的入侵列入分母，總還是能計算出一個主動發現率的。）

另外，真實的入侵其實是一個低頻行為，大型的網際網路企業如果一年到頭成百上千的被入侵，肯定也不正常。是以，如果很久沒出現真實入侵案例，這個名額長期不變化，也無法刻畫入侵檢測能力是否在提升。

是以，我們一般還會引入兩個名額來觀測：

• 藍軍對抗主動發現率
• 已知場景覆寫率

藍軍主動高頻對抗和演習，可以彌補真實入侵事件低頻的不足，但是由于藍軍掌握的攻擊手法往往也是有限的，他們多次演習後，手法和場景可能會被羅列完畢。假設某一個場景建設方尚未補齊能力，藍軍同樣的姿勢演習100遍，增加100個未發現的演習案例，對建設方而言并沒有更多的幫助。是以，把已知攻擊手法的建成覆寫率拿出來，也是一個比較好的評價名額。

入侵檢測團隊把精力聚焦在已知攻擊手法的優先級評估和快速覆寫上，對建設到什麼程度是滿足需要的，要有自己的專業判斷（參考入侵檢測原則裡的“成本效益”原則）。

而宣布建成了一個場景的入侵發現能力，是要有基本的驗收原則的：

1. 該場景日均工單 < X單，峰值 < Y單；目前所有場景日平均<XX，峰值 <YY，超出該名額的政策不予接收，因為過多的告警會導緻有效資訊被淹沒，反而導緻此前具備的能力被幹擾，不如視為該場景尚未具備對抗能力。
2. 同一個事件隻告警首次，多次出現自動聚合。
3. 具備誤報自學習能力。
4. 告警具備可讀性（有清晰的風險闡述、關鍵資訊、處理指引、輔助資訊或者索引，便于定性），不鼓勵Key-Value模式的告警，建議使用自然語言描述核心邏輯和響應流程。
5. 有清晰的說明文檔，自測報告（就像傳遞了一個研發産品，産品文檔和自測過程是品質的保障）。
6. 有藍軍針對該場景實戰驗收報告。
7. 不建議調用微信、短信等接口發告警（告警和事件的差別是，事件可以閉環，告警隻是提醒），統一的告警事件架構可以有效的管理事件確定閉環，還能提供長期的基礎營運資料，比如止損效率、誤報量/率。

政策人員的文檔應當說明目前模型對哪些情況具備感覺能力，哪些前提下會無法告警（考驗一個人對該場景和自己模型的了解能力）。通過前述判斷，可以對政策的成熟度形成自評分，0-100自由大緻估算。單個場景往往很難達到100分，但那并沒有關系，因為從80分提升到100分的邊際成本可能變的很高。不建議追求極緻，而是全盤審視，是否快速投入到下一個場景中去。

如果某個不到滿分的場景經常出現真實對抗，又沒有交叉的其它政策進行彌補，那自評結論可能需要重審并提高驗收的标準。至少解決工作中實際遇到的Case要優先考慮。

11.影響入侵檢測的關鍵要素

讨論影響入侵檢測的要素時，我們可以簡單看看，曾經發生過哪些錯誤導緻防守方不能主動發現入侵：

• 依賴的資料丢失，比如HIDS在當事機器上，沒部署安裝/Agent挂了/資料上報過程丢失了/Bug了，或者背景傳輸鍊條中丢失資料。
• 政策腳本Bug，沒啟動（事實上我們已經失去了這個政策感覺能力了）。
• 還沒建設對應的政策（很多時候入侵發生了才發現這個場景我們還沒來得及建設對應的政策）。
• 政策的靈敏度/成熟度不夠（比如掃描的門檻值沒達到，WebShell用了變形的對抗手法）。
• 模型依賴的部分基礎資料錯誤，做出了錯誤的判斷。
• 成功告警了，但是負責應急同學錯誤的判斷/沒有跟進/輔助資訊不足以定性，沒有行動起來。

是以實際上，要讓一個入侵事件被捕獲，我們需要入侵檢測系統長時間、高品質、高可用的運作。這是一件非常專業的工作，超出了絕大多數安全工程師能力和意願的範疇。是以建議指派專門的營運人員對以下目标負責：

• 資料采集的完整性（全鍊路的對賬）。
• 每一個政策時刻工作正常（自動化撥測監控）。
• 基礎資料的準确性。
• 工單營運支撐平台及追溯輔助工具的便捷性。

可能有些同學會想，影響入侵檢測的關鍵要素，難道不是模型的有效性麼？怎麼全是這些亂七八糟的東西？

實際上，大型網際網路企業的入侵檢測系統日均資料量可能到達數百T，甚至更多。涉及到數十個業務子產品，成百上千台機器。從數字規模上來說，不亞于一些中小型企業的整個資料中心。這樣複雜的一個系統，要長期維持在高可用标準，本身就需要有SRE、QA等輔助角色的專業化支援。如果僅依靠個别安全工程師，很難讓其研究安全攻防的時候，又兼顧到基礎資料品質、服務的可用性和穩定性、釋出時候的變更規範性、各類營運名額和運維故障的及時響應。最終的結果就是能力範圍内可以發現的入侵，總是有各種意外“恰好”發現不了。

是以，筆者認為，以多數安全團隊營運品質之差，其實根本輪不到拼政策（技術）。當然，一旦有資源投入去跟進這些輔助工作之後，入侵檢測就真的需要拼政策了。

此時，攻擊手法有那麼多，憑什麼先選擇這個場景建設？憑什麼認為建設到某程度就足夠滿足當下的需要了？憑什麼選擇發現某些樣本，而放棄另一些樣本的對抗？

這些看似主觀性的東西，非常考驗專業判斷力。而且在上司面前很容易背上“責任心不足”的帽子，比如為困難找借口而不是為目标找方法，這個手法黑客攻擊了好多次，憑什麼不解決，那個手法憑什麼說在視野範圍内，但是要明年再解決？

12.如何發現APT？

所謂APT，就是進階持續威脅。既然是進階的，就意味着木馬很大可能是免殺的（不能靠防毒軟體或者普通的特征發現），利用的漏洞也是進階的（加強到牙齒可能也擋不住敵人進來的步伐），攻擊手法同樣很進階（攻擊場景可能我們都沒有見過）。

是以，實際上APT的意思，就約等于同于不能被發現的入侵。然而，業界總還有APT檢測産品，解決方案的廠商在混飯吃，他們是怎麼做的呢？

木馬免殺的，他們用沙箱+人工分析，哪怕效率低一些，還是試圖做出定性，并快速的把IOC（威脅情報）同步給其它客戶，發現1例，全球客戶都具備同樣的感覺能力。

流量加密變形對抗的，他們用異常檢測的模型，把一些不認識的可疑的IP關系、payload給識别出來。當然，識别出來之後，也要營運人員跟進得仔細，才能定性。

攻擊手法進階的，他們還是會假定黑客就用魚叉、水坑之類的已知手法去執行，然後在郵箱附件、PC終端等環節采集日志，對使用者行為進行分析，UEBA試圖尋找出使用者異于平常的動作。

那麼，我們呢？筆者也沒有什麼好的辦法，可以發現傳說中的“免殺”的木馬，但是我們可以針對已知的黑客攻擊架構（比如Metasploit、Cobalt Strike）生成的樣本、行為進行一些特征的提取。我們可以假設已經有黑客控制了某一台機器，但是它試圖進行橫向擴散的時候，我們有一些模型可以識别這個主機的橫向移動行為。

筆者認為，世界上不存在100%能發現APT的方法。但是我們可以等待實施APT的團隊犯錯，隻要我們的縱深足夠的多，資訊足夠不對稱，想要完全不觸碰我們所有的鈴铛，絕對存在一定的困難。

甚至，攻擊者如果需要小心翼翼的避開所有的檢測邏輯，可能也會給對手一種心理上的震懾，這種震懾可能會延緩對手接近目标的速度，拉長時間。而在這個時間裡，隻要他犯錯，就輪到我們出場了。

前面所有的高标準，包括高覆寫、低誤報，強制每一個告警跟進到底，“掘地三尺”的态度，都是在等待這一刻。抓到一個值得敬佩的對手，那種成就感，還是很值得回味的。

是以，希望所有從事入侵檢測的安全同行們都能堅持住，即使聽過無數次“狼來了”，下一次看到告警，依然可以用最高的敬畏心去迎接對手（告警虐我千百遍，我待告警如初戀）。

12.AI在入侵檢測領域的正确姿勢

最近這兩年，如果不談AI的話，貌似故事就不會完整。隻不過，随着AI概念的火爆，很多人已經把傳統的資料挖掘、統計分析等思想，比如分類、預測、聚類、關聯之類的算法，都一律套在AI的帽子裡。

其實AI是一種現代的方法，在很多地方有非常實際的産出了。以WebShell的文本分析為例，我們可能需要花很長很長的時間，才能把上千個樣本裡隐含的幾十種樣本技術類型拆分開，又花更長的時間去一一建設模型（是的，在這樣的場景下，特征工程真的是一個需要更長時間的工作）。

而使用AI，做好資料打标的工作，訓練、調參，很快就能拿到一個實驗室環境不那麼過拟合的模型出來，迅速投産到生産環境上。熟練一點可能1-2個月就能做完了。

在這種場景下，AI這種現代的方法，的确能極大地提高效率。但問題是，前文也提到過了，黑客的攻擊黑樣本、WebShell的樣本，往往極其稀缺，它不可能是完備的能夠描述黑客入侵的完整特征的。是以，AI産出的結果，無論是誤報率還是漏報率，都會受訓練方法和輸入樣本的影響較大，我們可以借助AI，但絕對不能完全交給AI。

安全領域一個比較常見的現象是，将場景轉變成标記問題，要難過于通過數學模型把标記的解給求出來。此時往往需要安全專家先行，算法專家再跟上，而不能直接讓算法專家“孤軍奮戰”。

針對一個具體的攻擊場景，怎麼樣采集對應的入侵資料，思考這個入侵動作和正常行為的差別，這個特征的提取過程，往往決定了模型最終的效果。特征決定了效果的上限，而算法模型隻能決定了有多接近這個上限。

此前，筆者曾見過一個案例，AI團隊産出了一個實驗室環境效果極佳，誤報率達到1/1000000的WebShell模型，但是投放到生産環境裡初期日均告警6000單，完全無法營運，同時還存在不少漏報的情況。這些情況随着安全團隊和AI工程師共同的努力，後來逐漸地解決。但是并未能成功的取代原有的特征工程模型。

目前業界有許多産品、文章在實踐AI，但遺憾的是，這些文章和産品大多“淺嘗辄止”，沒有在真實的環境中實踐營運效果。一旦我們用前面的标準去要求它，就會發現，AI雖然是個好東西，但是絕對隻是個“半成品”。真正的營運，往往需要傳統的特征工程和AI并行，也需要持續地進行疊代。

未來必然是AI的天下，但是有多少智能，前面可能就要鋪墊多少人工。願與同行們一起在這個路上繼續探索下去，多多交流分享。