轉載：https://security.tencent.com/index.php/blog/msg/21
一、前言
伊朗2010年被報出核工廠遭受“超級工廠”(Stuxnet)病毒攻擊，蠕蟲通過多個漏洞潛伏在工控系統近兩年未被發現。相信諸如上述案例中的伊朗核工廠，大多網絡中都會部署有各種形形色色的安全產品，殺毒軟件,waf或IDS。但爲什麼那麼大範圍的攻擊卻依然久未被察覺？大型網絡怎樣才能更有效的做好入侵檢測呢？本文講介紹一些建設經驗。
二、監測體系
2.1、架構選擇
常規的安全產品可能是一個殺毒軟件，一個IDS，一個WAF，這能解決一個單點安全問題，但如果沒有全局的信息匯聚與分析，很難實現對全局態勢的感知。
雲計算與雲安全是常被提起的概念，在大型網絡中，因應用服務器對於性能消耗較爲敏感，很多複雜的安全分析邏輯不易被業務部門接受，部署於主機和網絡上的設備只被限制在實現提取數據功能。分析與計算在後端也就是所謂的雲端來實現。
同時，採集與計算的分離帶來了諸多優點：
1. 假設(幾乎是必然出現)單點系統被黑客攻陷，安全策略不易被逆向與竊取，避免因策略失竊帶來的，對手針對性研究繞過手法；
2. 可快速更新檢測策略，減少對各子節點和探測設備的變更，避免干擾業務系統的穩定；
3. 原始數據的短時存儲，便於對事件演變過程的重現，方便追溯審計，以及預研新檢測邏輯的驗證。
2.2、功能模塊
大型網絡的安全監測產品通常有各類SOC系統，分佈式安全產品，以及雲安全產品。產品形式千變萬化，但功能模塊這裏將其簡化如下歸納:
圖 1 入侵檢測體系模塊
2.3、態勢感知能力
通常SOC系統會收集各種日誌，各種NIDS\HIDS 都有數據採集功能。儘可能多的採集數據對於入侵分析是很有幫助的。
但我們面對入侵事件時，常常面臨兩種尷尬局面：
2.3.1、數據很少：僅有部分系統\應用默認日誌
如偵探破案一般，發現入侵事件最重要的是有證據。通常系統默認的日誌等數據無法滿足入侵事件分析需求，必須開發專門的探測器。先需要梳理場景對抗需求，搞清楚檢測某類攻擊所需數據類別與緯度，並將此作爲數據採集系統的開發需求。
圖 2數據需求
2.3.2、數據很多：大型網絡中各類數據很多，甚至多至無法記錄。
數據並非越多越好，特別是大型網絡的海量數據，如全部彙集存儲是難以支撐的。且大量的噪音數據也只會帶來硬件與人力成本的增加。真正流入最後存儲與分析系統的數據，必然是經過精簡與格式化之後的。
圖3 數據精簡
2.4、數據分析
有了數據不等於有檢測能力，首先第一個問題就是如何理解你獲得的數據，這就是數據格式化。
如何定義格式化數據：
1) 分析規則決定數據緯度
2) 關聯邏輯定義字段擴展
有了格式化好的數據，就實現了數據自動化分析的第一步，接下來纔是分析引擎與規則建設。
三、分析能力
但凡有一點滲透經驗的人，對於無論是殺毒軟件還是waf\ids 系統都知道使用各種逃避檢測的手段。現在我們面對的是有一定反檢測能力的攻擊者，特別是高級APT攻擊通常較爲隱蔽不易觸發單點的安全策略和檢測，需要更多緯度和大視角的數據分析。
美國《2013年財年國防授權法案》:國防部下一代主機安全系統不能再是殺毒軟件或任何基於簽名的技術
傳統安全產品單純依靠特徵庫的檢測模式，效果已大打折扣。黑客工具千變萬化，攻擊手法層出不窮，但他們的目的不變，行爲就是殊途同歸的。所以，在原有特徵檢測技術之外，用行爲模型能更好的檢測入侵，我們提出以下檢測模型：
3.1、單點事件描述數據的行爲分析
例如一個進程的啓動，進程自身的行爲與環境信息。
圖4 異常進程
這裏你看到了什麼？以下均可作爲惡意進程檢測規則。
1) 父進程爲IE；
2) 進程運行在IE緩存目錄；
3) 進程PE信息：加殼,未簽名, 多個PE頭部 等
3.2、上下文事件關聯分析
例如：一個進程狀態的變化，以及父子進程狀態的變化。
圖5 ProFTPD 漏洞
這是ProFTPD的一個遠程緩衝區溢出漏洞攻擊後的結果，從pstree可以看到proftpd進程派生了一個bash子進程。正常情況下bash通常只會從系統登錄後的sshd\login等進程啓動，這可作爲一個異常告警邏輯。大家再想想這個場景還會有那些特徵？
規則描述
{
"dsc":"Remote code execute",
"cache":{
Socket=1,
cmd!=sshd|logoin
},
"rule":{
ip=cache.ip,
ppid=cache.ip.pid,
cmd=/bin/shell
}
}
3.3、多數據緯度關聯分析
例如：NIDS與HIDS的數據聯動分析。
圖 6 多系統數據關聯
IDS上出現來至非正常業務邏輯的文件上傳事件，於此幾乎同時，HIDS出現一個CGI文件生成事件，可作爲可疑webshell上傳行爲規則。上傳漏洞千變萬化，導致入侵者能上傳webshell的原因也千奇百怪，我們勿需爲每一個web漏洞建立檢測規則，形成臃腫的規則庫，只要符合上述行爲特徵，就能被發現。
總結上訴架構與分析邏輯，我們得出以下整體架構圖。
圖7 入侵檢測系統簡化架構
四、實戰推演
前面洋洋灑灑那麼多，還是實戰來得實際。下面我們通過對一個確切的攻擊場景實現檢測能力來實踐前面的思路。
4.1、場景分析
在黑客入侵過程中，通常有一個環節，就是通過漏洞對自身擁有的權限進行提升，簡稱提權。常見的提權手法是，發現系統存在的漏洞，執行漏洞利用程序，exp利用漏洞獲取一個高權限的shell。
圖8 提權行爲分析
4.2、檢測思路
通過對上述漏洞的分析和測試，我們會發現一個提權攻擊中的特點，那就是exploit工具自身在執行時是低權限，而得到的shell是高權限。
有了對場景的清晰認識，檢測邏輯也就很清楚了：
某個高權限(system?uid=0?)進程(bash?cmd.exe?)的父進程爲低權限，則告警。
4.3、系統實現
數據採集需求:根據前面大節中的思路，我們有了場景有了規則，可以考慮採集那些數據以及數據緯度了。在這個場景中，規則分析至少需要用到幾個必備的進程數據緯度：進程權限；進程ID；父進程ID
規則邏輯:
{
"dsc":"Local Privilege Escalation",
"cache":{
uid>0
},
"rule":{
ip=cache.ip,
ppid=cache.ip.pid
uid=0
}
}
以上檢測規則基本上能滿足多數提權場景，但實際運用中還有一些細節需讀者自己去思考完善：
1、同樣滿足父進程權限低，子進程權限高的正常場景有哪些，如何去除誤報？
2、數據關聯分析中，分析流程向前追溯還是向後追溯更易實現，更符合你自己分析系統的架構？
3、提權攻擊除了上述提到的場景，還有那些？
我們可以看到，從行爲描述很容易刻畫攻擊場景，從而實現檢測，縱使攻擊手法千變萬化，而關鍵路徑是不易改變的。通過行爲模型實現檢測能力，避免了各自漏洞技術細節差異帶來的規則庫冗餘(且影響安全系統性能)，也避免因檢測規則過分針對細節(特徵庫\漏洞庫)可能導致的被繞過。
五、總結
本文是在實際入侵對抗實踐中，根據公司網絡自身環境，外部威脅特點不斷總結出來一些淺顯經驗。總的歸納爲：入侵事件數據化、入侵檢測模型化、事件分析平臺化。
在不同網絡環境，安全威脅形勢，對抗要求時，還須結合自身情況作不少優化和變化。個人認爲前述無論是架構還是數據分析模型，是在現有網絡海量數據、業務環境苛刻、外部威脅多變的情況下一種較爲經濟易行的入侵檢測思路。
評論留言
沙發？
正巧昨天看的梧桐雨大牛寫的類似文章 感覺不錯 推薦一下
http://wutongyu.info/qiantan-daxinghulianwang-anquan/