如何知道自己所在的企業是否被入侵了？
是沒人來“黑”，
還是因自身感知能力不足，
暫時還無法發現？
其實，入侵檢測是每一個大型互聯網企業都要面對的嚴峻挑戰。價值越高的公司，面臨入侵的威脅也越大，即便是 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 無邊界網絡得以實施的前提和基礎。
因此，入侵檢測的主要思路也就有兩種：
1、根據黑特徵進行模式匹配（例如 WebShell 關鍵字匹配）。
2、根據業務歷史行爲（生成基線模型），對入侵行爲做異常對比（非白即黑），如果業務的歷史行爲不夠收斂，就用加固的手段對其進行收斂，再挑出不合規的小衆異常行爲。
入侵檢測與攻擊向量
根據目標不同，可能暴露給黑客的攻擊面會不同，黑客可能採用的入侵手法也就完全不同。
比如，入侵我們的 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 漏洞（遠程命令執行），只要端口開放，黑客就能利用現成的 exp，直接 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（advanced persistent thread高級持續性威脅） 報告裏，黑客是先對人（辦公終端）下手，比如發個郵件，哄騙我們打開後，控制我們的 PC，再進行長期的觀察/翻閱，拿到我們的合法憑據後，再到內網漫遊。
所以這些報告，多數集中在描述黑客用的木馬行爲以及家族代碼相似度上。而反觀APT 的產品、解決方案，多數也是在辦公終端的系統調用層面，用類似的方法，檢驗“免殺木馬”的行爲。
因此，EDR 類的產品+郵件安全網關+辦公網出口的行爲審計+APT 產品的沙箱等，聯合起來，可以採集到對應的數據，並作出相似的入侵檢測感知模型。
而最重要的一點，是黑客喜歡關注內部的重要基礎設施，包括但不限於 AD 域控、郵件服務器、密碼管理系統、權限管理系統等，一旦拿下，就相當於成爲了內網的“上帝”，可以爲所欲爲。
所以對公司來說，重要基礎設施要有針對性的攻防加固討論，微軟針對 AD 的攻防甚至還發過專門的加固白皮書。
大型的互聯網公司，本身就處在互聯網中。網絡安全事件十分複雜，網絡安全問題是一件不可鬆懈的事情，不要被“狼來了”的信息所困擾從而放鬆警惕，安全無小事，“黑客”一旦攻擊入侵，接下來面對的結果損失是無法預計的！