淺談大型互聯網企業入侵檢測及防禦策略

前言

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

基於「攻防對抗」的考量，本文不會說起具體的入侵檢測模型、算法和策略，那些但願直接照搬「入侵策略」的同窗可能會感到失望。可是咱們會將一部分運營思路分享出來，請各位同行指點，如能對後來者起到幫助的做用，那就更好了，也歡迎你們跟咱們交流探討。

入侵的定義

典型的入侵場景：

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

咱們能夠給入侵下一個定義：就是黑客在未經受權的狀況下，控制、使用我方資源（包括但不限於讀寫數據、執行命令、控制資源等）達到各類目的。從廣義上講，黑客利用SQL注入漏洞竊取數據，或者拿到了目標域名在ISP中的賬號密碼，以篡改DNS指向一個黑頁，又或者找到了目標的社交賬號，在微博/QQ/郵箱上，對虛擬資產進行非受權的控制，都屬於入侵的範疇。

針對企業的入侵檢測

企業入侵檢測的範圍，多數狀況下比較狹義：通常特指黑客對PC、系統、服務器、網絡（包括辦公網、生產網）控制的行爲。

黑客對PC、服務器等主機資產的控制，最多見的方法是經過Shell去執行指令，得到Shell的這個動做叫作GetShell。

好比經過Web服務的上傳漏洞，拿到WebShell，或者利用RCE漏洞直接執行命令/代碼（RCE環境變相的提供了一個Shell）。另外，經過某種方式先植入「木馬後門」，後續直接利用木馬集成的SHELL功能對目標遠程控制，這個也比較典型。

所以，入侵檢測能夠重點關注GetShell這個動做，以及GetShell成功以後的惡意行爲（爲了擴大戰果，黑客多半會利用Shell進行探測、翻找竊取、橫向移動攻擊其它內部目標，這些區別於好人的特性也能夠做爲重要的特徵）。

有一些同行（包括商業產品），喜歡報告GetShell以前的一些「外部掃描、攻擊探測和嘗試行爲」，並美其名曰「態勢感知」，告訴企業有人正在「試圖攻擊」。在筆者看來，實戰價值並不大。包括美團在內的不少企業，基本上無時無刻都在遭受「不明身份」的攻擊，知道了有人在「嘗試」攻擊，若是並不能有效地去行動，沒法有效地對行動進行告警，除了耗費心力以外，並無太大的實際價值。

當咱們習慣「攻擊」是常態以後，就會在這樣的常態下去解決問題，可使用什麼加固策略，哪些能夠實現常態化的運營，若是有什麼策略沒法常態化運營，好比須要不少人加班臨時突擊守着，那這個策略多半在不久以後就會逐漸消逝掉。跟咱們作不作這個策略，並無本質上的區別。

相似於SQL注入、XSS等一些不直接GetShell的Web攻擊，暫時不在狹義的「入侵檢測」考慮範圍，建議能夠劃入「漏洞」、「威脅感知」等領域，另行再作探討。固然，利用SQL注入、XSS等入口，進行了GetShell操做的，咱們仍抓GetShell這個關鍵點，沒必要在意漏洞入口在何處。

「入侵」和「內鬼」

與入侵接近的一種場景是「內鬼」。入侵自己是手段，GetShell只是起點，黑客GetShell的目標是爲了以後對資源的控制和數據的竊取。而「內鬼」自然擁有合法的權限，能夠合法接觸敏感資產，可是基於工做之外的目的，他們對這些資源進行非法的處置，包括拷貝副本、轉移外泄、篡改數據牟利等。

內鬼的行爲不在「入侵檢測」的範疇，通常從內部風險控制的視角進行管理和審計，好比職責分離、雙人審計等。也有數據防泄密產品（DLP）對其進行輔助，這裏不展開細說。

有時候，黑客知道員工A有權限接觸目標資產，便定向攻擊A，再利用A的權限把數據竊取走，也定性爲「入侵」。畢竟A不是主觀惡意的「內鬼」。若是不能在黑客攻擊A的那一刻捕獲，或者沒法區分黑客控制的A竊取數據和正常員工A的訪問數據，那這個入侵檢測也是失敗的。

入侵檢測的本質

前文已經講過，入侵就是黑客能夠不通過咱們的贊成，來操做咱們的資產，在手段上並無任何的限制。那麼如何找出入侵行爲和合法正常行爲的區別，將其跟合法行爲進行分開，就是「入侵發現」。在算法模型上，這算是一個標記問題（入侵、非入侵）。

惋惜的是，入侵這種動做的「黑」樣本特別稀少，想經過大量的帶標籤的數據，有監督的訓練入侵檢測模型，找出入侵的規律比較難。所以，入侵檢測策略開發人員，每每須要投入大量的時間，去提煉更精準的表達模型，或者花更多的精力去構造「相似入侵」的模擬數據。

一個經典的例子是，爲了檢測出WebShell，安全從業人員能夠去GitHub上搜索一些公開的WebShell樣本，數量大約不到1000個。而對於機器學習動輒百萬級的訓練需求，這些數據遠遠不夠。何況GitHub上的這些樣本集，從技術手法上來看，有單一技術手法生成的大量相似樣本，也有一些對抗的手法樣本缺失。所以，這樣的訓練，試圖讓AI去經過「大量的樣本」掌握WebShell的特徵並區分出它們，原則上不太可能完美地去實現。

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

另外一個方面，入侵的區別是看行爲自己是否「受權」，而受權與否自己是沒有任何顯著的區分特徵的。所以，作入侵對抗的時候，若是可以經過某種加固，將合法的訪問收斂到有限的通道，而且給該通道作出強有力的區分，也就能大大的下降入侵檢測的成本。例如，對訪問來源進行嚴格的認證，不管是天然人，仍是程序API，都要求持有合法票據，而派發票據時，針對不一樣狀況作多緯度的認證和受權，再用IAM針對這些票據記錄和監控它們能夠訪問的範圍，還能產生更底層的Log作異常訪問模型感知。

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

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

• 根據黑特徵進行模式匹配（例如WebShell關鍵字匹配）。
• 根據業務歷史行爲（生成基線模型），對入侵行爲作異常對比（非白既黑），若是業務的歷史行爲不夠收斂，就用加固的手段對其進行收斂，再挑出不合規的小衆異常行爲。

入侵檢測與攻擊向量

根據目標不一樣，可能暴露給黑客的攻擊面會不一樣，黑客可能採用的入侵手法也就徹底不一樣。好比，入侵咱們的PC/筆記本電腦，還有入侵部署在機房/雲上的服務器，攻擊和防護的方法都有挺大的區別。

針對一個明確的「目標」，它被訪問的渠道多是有限集，被攻擊的必經路徑也有限。「攻擊方法」+「目標的攻擊面」的組合，被稱爲「攻擊向量」。

所以，談入侵檢測模型效果時，須要先明確攻擊向量，針對不一樣的攻擊路徑，採集對應的日誌（數據），纔可能作對應的檢測模型。好比，基於SSH登陸後的Shell命令數據集，是不能用於檢測WebShell的行爲。而基於網絡流量採集的數據，也不可能感知黑客是否在SSH後的Shell環境中執行了什麼命令。

基於此，若是有企業不提具體的場景，就說作好了APT感知模型，顯然就是在「吹噓」了。

因此，入侵檢測得先把各種攻擊向量羅列出來，每個細分場景分別採集數據（HIDS+NIDS+WAF+RASP+應用層日誌+系統日誌+PC……），再結合公司的實際數據特性，做出適應公司實際狀況的對應檢測模型。不一樣公司的技術棧、數據規模、暴露的攻擊面，都會對模型產生重大的影響。好比不少安全工做者特別擅長PHP下的WebShell檢測，可是到了一個Java系的公司......

常見的入侵手法與應對

若是對黑客的常見入侵手法理解不足，就很難有的放矢，有時候甚至會陷入「政治正確」的陷阱裏。好比滲透測試團隊說，咱們作了A動做，大家居然沒有發現，因此大家不行。而實際狀況是，該場景可能不是一個完備的入侵鏈條，就算不發現該動做，對入侵檢測效果可能也沒有什麼影響。每個攻擊向量對公司形成的危害，發生的機率如何進行排序，解決它耗費的成本和帶來的收益如何，都須要有專業經驗來作支撐與決策。

如今簡單介紹一下，黑客入侵教程裏的經典流程（完整過程能夠參考殺傷鏈模型）：

入侵一個目標以前，黑客對該目標可能還不夠了解，因此第一件事每每是「踩點」，也就是蒐集信息，加深瞭解。好比，黑客須要知道，目標有哪些資產（域名、IP、服務），它們各自的狀態如何，是否存在已知的漏洞，管理他們的人有誰（以及如何合法的管理的），存在哪些已知的泄漏信息（好比社工庫裏的密碼等）......

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

高危服務入侵

全部的公共服務都是「高危服務」，由於該協議或者實現該協議的開源組件，可能存在已知的攻擊方法（高級的攻擊者甚至擁有對應的0day），只要你的價值足夠高，黑客有足夠的動力和資源去挖掘，那麼當你把高危服務開啓到互聯網，面向全部人都打開的那一刻，就至關於爲黑客打開了「大門」。

好比SSH、RDP這些運維管理相關的服務，是設計給管理員用的，只要知道密碼/祕鑰，任何人都能登陸到服務器端，進而完成入侵。而黑客可能經過猜解密碼（結合社工庫的信息泄露、網盤檢索或者暴力破解），得到憑據。事實上這類攻擊因爲過於常見，黑客早就作成了全自動化的全互聯網掃描的蠕蟲類工具，雲上購買的一個主機若是設置了一個弱口令，每每在幾分鐘內就會感染蠕蟲病毒，就是由於這類自動化的攻擊者實在是太多了。

或許，你的密碼設置得很是強壯，可是這並非你能夠把該服務繼續暴露在互聯網的理由，咱們應該把這些端口限制好，只容許本身的IP（或者內部的堡壘主機）訪問，完全斷掉黑客經過它入侵咱們的可能。

與此相似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等，凡是本身用來管理服務器或者數據庫、文件的服務，都不該該針對互聯網無限制的開放。不然，蠕蟲化的攻擊工具會在短短几分鐘內攻破咱們的服務，甚至直接加密咱們的數據，甚至要求咱們支付比特幣，進行敲詐勒索。

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

防護建議： 針對每個高危服務作入侵檢測的成本較高，由於高危服務的具體所指很是的多，不必定存在通用的特徵。因此，經過加固方式，收斂攻擊入口性價比更高。禁止全部高危端口對互聯網開放可能，這樣可以減小90%以上的入侵機率。

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相關的數據，提煉出被攻擊成功的特徵，建議咱們將主要的精力放在這些方面。

0day入侵

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

可是對於入侵檢測而言，這並不可怕：由於不管對手利用什麼漏洞當入口，它所使用的Shellcode和以後的行爲自己依然有共性。Apache存在0day漏洞被攻擊，仍是一個PHP頁面存在低級的代碼漏洞被利用，從入侵的行爲上來看，說不定是徹底同樣的，入侵檢測模型還能夠通用。

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

辦公終端入侵

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

所以，EDR類的產品+郵件安全網關+辦公網出口的行爲審計+APT產品的沙箱等，聯合起來，能夠採集到對應的數據，並做出類似的入侵檢測感知模型。而最重要的一點，是黑客喜歡關注內部的重要基礎設施，包括但不限於AD域控、郵件服務器、密碼管理系統、權限管理系統等，一旦拿下，就至關於成爲了內網的「上帝」，能夠隨心所欲。因此對公司來講，重要基礎設施要有針對性的攻防加固討論，微軟針對AD的攻防甚至還發過專門的加固白皮書。

入侵檢測基本原則

不能把每一條告警都完全跟進的模型，等同於無效模型。入侵發生後，再辯解以前其實有告警，只是太多了沒跟過來/沒查完全，這是「馬後炮」，等同於不具有發現能力，因此對於日均告警成千上萬的產品，安全運營人員每每表示很無奈。

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

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

既然每個單一場景的模型都有誤報漏報，咱們作什麼場景，不作什麼場景，就須要考慮「性價比」。好比某些變形的WebShell能夠寫成跟業務代碼很是類似，人的肉眼幾乎沒法識別，再追求必定要在文本分析上進行對抗，就是性價比不好的決策。若是經過RASP的檢測方案，其性價比更高一些，也更具可行性一些。

咱們不太容易知道黑客全部的攻擊手法，也不太可能針對每一種手法都建設策略（考慮到資源老是稀缺的）。因此針對重點業務，須要能夠經過加固的方式（還須要常態化監控加固的有效性），讓黑客能攻擊的路徑極度收斂，僅在關鍵環節進行對抗。起碼能針對核心業務具有兜底的保護能力。

基於上述幾個原則，咱們能夠知道一個事實，或許咱們永遠不可能在單點上作到100%發現入侵，可是咱們能夠經過一些組合方式，讓攻擊者很難繞過全部的點。

當老闆或者藍軍挑戰，某個單點的檢測能力有缺失時，若是爲了「政治正確」，在這個單點上進行無止境的投入，試圖把單點作到100%能發現的能力，不少時候可能只是在試圖製造一個「永動機」，純粹浪費人力、資源，而不產生實際的收益。將節省下來的資源，高性價比的佈置更多的縱深防護鏈條，效果顯然會更好。

入侵檢測產品的主流形態

入侵檢測終究是要基於數據去建模，好比針對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的能力，只不過目前銷售仍是分開在賣。

  • 典型產品：殺毒軟件有Bit九、SEP、賽門鐵克、卡巴斯基、McAfee ；EDR產品不枚舉了，騰訊的iOA、阿里的阿里郎，必定程度上都是能夠充當相似的角色；

入侵檢測效果評價指標

首先，主動發現的入侵案例/全部入侵 = 主動發現率。這個指標必定是最直觀的。比較麻煩的是分母，不少真實發生的入侵，若是外部不反饋，咱們又沒檢測到，它就不會出如今分母裏，因此有效發現率老是虛高的，誰能保證當前全部的入侵都發現了呢？（可是實際上，只要入侵次數足夠多，無論是SRC收到的情報，仍是「暗網」上報出來的一個大新聞，把客觀上已經知悉的入侵列入分母，總仍是能計算出一個主動發現率的。）

另外，真實的入侵實際上是一個低頻行爲，大型的互聯網企業若是一年到頭成百上千的被入侵，確定也不正常。所以，若是好久沒出現真實入侵案例，這個指標長期不變化，也沒法刻畫入侵檢測能力是否在提高。

因此，咱們通常還會引入兩個指標來觀測：

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

藍軍主動高頻對抗和演習，能夠彌補真實入侵事件低頻的不足，可是因爲藍軍掌握的攻擊手法每每也是有限的，他們屢次演習後，手法和場景可能會被羅列完畢。假設某一個場景建設方還沒有補齊能力，藍軍一樣的姿式演習100遍，增長100個未發現的演習案例，對建設方而言並無更多的幫助。因此，把已知攻擊手法的建成覆蓋率拿出來，也是一個比較好的評價指標。

入侵檢測團隊把精力聚焦在已知攻擊手法的優先級評估和快速覆蓋上，對建設到什麼程度是知足須要的，要有本身的專業判斷（參考入侵檢測原則裏的「性價比」原則）。

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

• 該場景日均工單 < X單，峯值 < Y單；當前全部場景日平均<XX，峯值 <YY，超出該指標的策略不予接收，由於過多的告警會致使有效信息被淹沒，反而致使此前具有的能力被幹擾，不如視爲該場景還沒有具有對抗能力。
• 同一個事件只告警首次，屢次出現自動聚合。
• 具有誤報自學習能力。
• 告警具有可讀性（有清晰的風險闡述、關鍵信息、處理指引、輔助信息或者索引，便於定性），不鼓勵Key-Value模式的告警，建議使用天然語言描述核心邏輯和響應流程。
• 有清晰的說明文檔，自測報告（就像交付了一個研發產品，產品文檔和自測過程是質量的保障）。
• 有藍軍針對該場景實戰驗收報告。
• 不建議調用微信、短信等接口發告警（告警和事件的區別是，事件能夠閉環，告警只是提醒），統一的告警事件框架能夠有效的管理事件確保閉環，還能提供長期的基礎運營數據，好比止損效率、誤報量/率。

策略人員的文檔應當說明當前模型對哪些狀況具有感知能力，哪些前提下會沒法告警（考驗一我的對該場景和本身模型的理解能力）。經過前述判斷，能夠對策略的成熟度造成自評分，0-100自由大體估算。單個場景每每很難達到100分，但那並無關係，由於從80分提高到100分的邊際成本可能變的很高。不建議追求極致，而是全盤審視，是否快速投入到下一個場景中去。

若是某個不到滿分的場景常常出現真實對抗，又沒有交叉的其它策略進行彌補，那自評結論可能須要重審並提升驗收的標準。至少解決工做中實際遇到的Case要優先考慮。

影響入侵檢測的關鍵要素

討論影響入侵檢測的要素時，咱們能夠簡單看看，曾經發生過哪些錯誤致使防守方不能主動發現入侵：

• 依賴的數據丟失，好比HIDS在當事機器上，沒部署安裝/Agent掛了/數據上報過程丟失了/Bug了，或者後臺傳輸鏈條中丟失數據。
• 策略腳本Bug，沒啓動（事實上咱們已經失去了這個策略感知能力了）。
• 還沒建設對應的策略（不少時候入侵發生了才發現這個場景咱們還沒來得及建設對應的策略）。
• 策略的靈敏度/成熟度不夠（好比掃描的閾值沒達到，WebShell用了變形的對抗手法）。
• 模型依賴的部分基礎數據錯誤，作出了錯誤的判斷。
• 成功告警了，可是負責應急同窗錯誤的判斷/沒有跟進/輔助信息不足以定性，沒有行動起來。

因此實際上，要讓一個入侵事件被捕獲，咱們須要入侵檢測系統長時間、高質量、高可用的運行。這是一件很是專業的工做，超出了絕大多數安全工程師能力和意願的範疇。因此建議指派專門的運營人員對如下目標負責：

• 數據採集的完整性（全鏈路的對帳）。
• 每個策略時刻工做正常（自動化撥測監控）。
• 基礎數據的準確性。
• 工單運營支撐平臺及追溯輔助工具的便捷性。

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

實際上，大型互聯網企業的入侵檢測系統日均數據量可能到達數百T，甚至更多。涉及到數十個業務模塊，成百上千臺機器。從數字規模上來講，不亞於一些中小型企業的整個數據中心。這樣複雜的一個系統，要長期維持在高可用標準，自己就須要有SRE、QA等輔助角色的專業化支持。若是僅依靠個別安全工程師，很難讓其研究安全攻防的時候，又兼顧到基礎數據質量、服務的可用性和穩定性、發佈時候的變動規範性、各種運營指標和運維故障的及時響應。最終的結果就是能力範圍內能夠發現的入侵，老是有各類意外「剛好」發現不了。

因此，筆者認爲，以多數安全團隊運營質量之差，其實根本輪不到拼策略（技術）。固然，一旦有資源投入去跟進這些輔助工做以後，入侵檢測就真的須要拼策略了。

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

這些看似主觀性的東西，很是考驗專業判斷力。並且在領導面前很容易背上「責任心不足」的帽子，好比爲困難找藉口而不是爲目標找方法，這個手法黑客攻擊了好屢次，憑什麼不解決，那個手法憑什麼說在視野範圍內，可是要明年再解決？

如何發現APT？

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

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

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

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

• 攻擊手法高級的，他們仍是會假定黑客就用魚叉、水坑之類的已知手法去執行，而後在郵箱附件、PC終端等環節採集日誌，對用戶行爲進行分析，UEBA試圖尋找出用戶異於日常的動做。

那麼，咱們呢？筆者也沒有什麼好的辦法，能夠發現傳說中的「免殺」的木馬，可是咱們能夠針對已知的黑客攻擊框架（好比Metasploit、Cobalt Strike）生成的樣本、行爲進行一些特徵的提取。咱們能夠假設已經有黑客控制了某一臺機器，可是它試圖進行橫向擴散的時候，咱們有一些模型能夠識別這個主機的橫向移動行爲。

筆者認爲，世界上不存在100%能發現APT的方法。可是咱們能夠等待實施APT的團隊犯錯，只要咱們的縱深足夠的多，信息足夠不對稱，想要徹底不觸碰咱們全部的鈴鐺，絕對存在必定的困難。

甚至，攻擊者若是須要當心翼翼的避開全部的檢測邏輯，可能也會給對手一種心理上的震懾，這種震懾可能會延緩對手接近目標的速度，拉長時間。而在這個時間裏，只要他犯錯，就輪到咱們出場了。

前面全部的高標準，包括高覆蓋、低誤報，強制每個告警跟進到底，「掘地三尺」的態度，都是在等待這一刻。抓到一個值得敬佩的對手，那種成就感，仍是很值得回味的。

因此，但願全部從事入侵檢測的安全同行們都能堅持住，即便聽過無數次「狼來了」，下一次看到告警，依然能夠用最高的敬畏心去迎接對手（告警虐我千百遍，我待告警如初戀）。

AI在入侵檢測領域的正確姿式

最近這兩年，若是不談AI的話，貌似故事就不會完整。只不過，隨着AI概念的火爆，不少人已經把傳統的數據挖掘、統計分析等思想，好比分類、預測、聚類、關聯之類的算法，都一概套在AI的帽子裏。

其實AI是一種現代的方法，在不少地方有很是實際的產出了。以WebShell的文本分析爲例，咱們可能須要花很長很長的時間，才能把上千個樣本里隱含的幾十種樣本技術類型拆分開，又花更長的時間去一一建設模型（是的，在這樣的場景下，特徵工程真的是一個須要更長時間的工做）。

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

在這種場景下，AI這種現代的方法，的確能幾大的提升效率。但問題是，前文也提到過了，黑客的攻擊黑樣本、WebShell的樣本，每每極其稀缺，它不多是完備的可以描述黑客入侵的完整特徵的。所以，AI產出的結果，不管是誤報率仍是漏報率，都會受訓練方法和輸入樣本的影響較大，咱們能夠藉助AI，但絕對不能徹底交給AI。

安全領域一個比較常見的現象是，將場景轉變成標記問題，要難過於經過數學模型把標記的解給求出來。此時每每須要安全專家先行，算法專家再跟上，而不能直接讓算法專家「孤軍奮戰」。

針對一個具體的攻擊場景，怎麼樣採集對應的入侵數據，思考這個入侵動做和正常行爲的區別，這個特徵的提取過程，每每決定了模型最終的效果。特徵決定了效果的上限，而算法模型只能決定了有多接近這個上限。

此前，筆者曾見過一個案例，AI團隊產出了一個實驗室環境效果極佳，誤報率達到1/1000000的WebShell模型，可是投放到生產環境裏初期日均告警6000單，徹底沒法運營，同時還存在很多漏報的狀況。這些狀況隨着安全團隊和AI工程師共同的努力，後來逐漸地解決。可是並未能成功的取代原有的特徵工程模型。

目前業界有許多產品、文章在實踐AI，但遺憾的是，這些文章和產品大多「淺嘗輒止」，沒有在真實的環境中實踐運營效果。一旦咱們用前面的標準去要求它，就會發現，AI雖然是個好東西，可是絕對只是個「半成品」。真正的運營，每每須要傳統的特徵工程和AI並行，也須要持續地進行迭代。

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

關於美團安全

美團安所有的大多數核心開發人員，擁有多年互聯網以及安全領域實踐經驗，不少同窗參與過大型互聯網公司的安全體系建設，其中也不乏全球化安全運營人才，具有百萬級IDC規模攻防對抗的經驗。安所有也不乏CVE「挖掘聖手」，有受邀在Black Hat等國際頂級會議發言的講者，固然還有不少漂亮的運營妹子。

目前，美團安所有涉及的技術包括滲透測試、Web防禦、二進制安全、內核安全、分佈式開發、大數據分析、安全算法等等，同時還有全球合規與隱私保護等策略制定。咱們正在建設一套百萬級IDC規模、數十萬終端接入的移動辦公網絡自適應安全體系，這套體系構建於零信任架構之上，橫跨多種雲基礎設施，包括網絡層、虛擬化/容器層、Server 軟件層（內核態/用戶態）、語言虛擬機層(JVM/JS V8)、Web應用層、數據訪問層等，並可以基於大數據+機器學習技術構建全自動的安全事件感知系統，努力打形成業界最前沿的內置式安全架構和縱深防護體系。

隨着美團的高速發展，業務複雜度不斷提高，安所有門面臨更多的機遇和挑戰。咱們但願將更多表明業界最佳實踐的安全項目落地，同時爲更多的安全從業者提供一個廣闊的發展平臺，並提供更多在安全新興領域不斷探索的機會。

【安利個小廣告】

美團安所有正在招募Web&二進制攻防、後臺&系統開發、機器學習&算法等各路小夥伴。若是你想加入咱們，歡迎簡歷請發至郵箱zhaoyan17@meituan.com

具體職位信息可參考這裏

美團安全應急響應中心MTSRC主頁：security.meituan.com

發現文章有錯誤、對內容有疑問，均可以關注美團技術團隊微信公衆號（meituantech），在後臺給咱們留言。咱們每週會挑選出一位熱心小夥伴，送上一份精美的小禮品。快來掃碼關注咱們吧！