【轉載】淺談大型網絡入侵檢測建設

原文連接：https://security.tencent.com/index.php/blog/msg/21

1、前言

    伊朗2010年被報出核工廠遭受「超級工廠」(Stuxnet)病毒攻擊，蠕蟲經過多個漏洞潛伏在工控系統近兩年未被發現。相信諸如上述案例中的伊朗核工廠，大多網絡中都會部署有各類形形色色的安全產品，殺毒軟件,waf或IDS。但爲何那麼大範圍的攻擊卻依然久未被察覺？大型網絡怎樣才能更有效的作好入侵檢測呢？本文講介紹一些建設經驗。

2、監測體系

2.一、架構選擇

    常規的安全產品多是一個殺毒軟件，一個IDS，一個WAF，這能解決一個單點安全問題，但若是沒有全局的信息匯聚與分析，很難實現對全局態勢的感知。

    雲計算與雲安全是常被提起的概念，在大型網絡中，因應用服務器對於性能消耗較爲敏感，不少複雜的安全分析邏輯不易被業務部門接受，部署於主機和網絡上的設備只被限制在實現提取數據功能。分析與計算在後端也就是所謂的雲端來實現。

    同時，採集與計算的分離帶來了諸多優勢：

1. 假設(幾乎是必然出現)單點系統被黑客攻陷，安全策略不易被逆向與竊取，避免因策略失竊帶來的，對手針對性研究繞過手法；

2. 可快速更新檢測策略，減小對各子節點和探測設備的變動，避免干擾業務系統的穩定；

3. 原始數據的短時存儲，便於對事件演變過程的重現，方便追溯審計，以及預研新檢測邏輯的驗證。

2.二、功能模塊

    大型網絡的安全監測產品一般有各種SOC系統，分佈式安全產品，以及雲安全產品。產品形式變幻無窮，但功能模塊這裏將其簡化以下概括:

 
圖 1 入侵檢測體系模塊

2.三、態勢感知能力

    一般SOC系統會收集各類日誌，各類NIDS\HIDS 都有數據採集功能。儘量多的採集數據對於入侵分析是頗有幫助的。

    但咱們面對入侵事件時，經常面臨兩種尷尬局面：

    2.3.一、數據不多：僅有部分系統\應用默認日誌

    如偵探破案通常，發現入侵事件最重要的是有證據。一般系統默認的日誌等數據沒法知足入侵事件分析需求，必須開發專門的探測器。先須要梳理場景對抗需求，搞清楚檢測某類攻擊所需數據類別與緯度，並將此做爲數據採集系統的開發需求。

 圖 2數據需求

    2.3.二、數據不少：大型網絡中各種數據不少，甚至多至沒法記錄。

    數據並不是越多越好，特別是大型網絡的海量數據，如所有聚集存儲是難以支撐的。且大量的噪音數據也只會帶來硬件與人力成本的增長。真正流入最後存儲與分析系統的數據，必然是通過精簡與格式化以後的。

 圖3 數據精簡

2.四、數據分析

    有了數據不等於有檢測能力，首先第一個問題就是如何理解你得到的數據，這就是數據格式化。

    如何定義格式化數據：

    1)  分析規則決定數據緯度

    2) 關聯邏輯定義字段擴展

    有了格式化好的數據，就實現了數據自動化分析的第一步，接下來纔是分析引擎與規則建設。

3、分析能力

    但凡是有一點滲透經驗的人，對於不管是殺毒軟件仍是waf\ids 系統都知道使用各類逃避檢測的手段。如今咱們面對的是有必定反檢測能力的攻擊者，特別是高級APT攻擊一般較爲隱蔽不易觸發單點的安全策略和檢測，須要更多緯度和大視角的數據分析。

美國《2013年財年國防受權法案》:國防部下一代主機安全系統不能再是殺毒軟件或任何基於簽名的技術

    傳統安全產品單純依靠特徵庫的檢測模式，效果已大打折扣。黑客工具變幻無窮，攻擊手法層出不窮，但他們的目的不變，行爲就是異曲同工的。因此，在原有特徵檢測技術以外，用行爲模型能更好的檢測入侵，咱們提出如下檢測模型：

3.一、單點事件描述數據的行爲分析

    例如一個進程的啓動，進程自身的行爲與環境信息。

 圖4 異常進程

    這裏你看到了什麼？如下都可做爲惡意進程檢測規則。

1) 父進程爲IE；

2) 進程運行在IE緩存目錄；

3) 進程PE信息：加殼,未簽名, 多個PE頭部 等

3.二、上下文事件關聯分析

    例如：一個進程狀態的變化，以及父子進程狀態的變化。

圖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.三、多數據緯度關聯分析

    例如：NIDS與HIDS的數據聯動分析。

圖 6 多系統數據關聯

    IDS上出現來至非正常業務邏輯的文件上傳事件，於此幾乎同時，HIDS出現一個CGI文件生成事件，可做爲可疑webshell上傳行爲規則。上傳漏洞變幻無窮，致使入侵者能上傳webshell的緣由也千奇百怪，咱們勿需爲每個web漏洞創建檢測規則，造成臃腫的規則庫，只要符合上述行爲特徵，就能被發現。

    總結上訴架構與分析邏輯，咱們得出如下總體架構圖。

圖7 入侵檢測系統簡化架構

4、實戰推演

    前面洋洋灑灑那麼多，仍是實戰來得實際。下面咱們經過對一個確切的攻擊場景實現檢測能力來實踐前面的思路。

4.一、場景分析

    在黑客入侵過程當中，一般有一個環節，就是經過漏洞對自身擁有的權限進行提高，簡稱提權。常見的提權手法是，發現系統存在的漏洞，執行漏洞利用程序，exp利用漏洞獲取一個高權限的shell。

圖8 提權行爲分析

 

4.二、檢測思路

    經過對上述漏洞的分析和測試，咱們會發現一個提權攻擊中的特色，那就是exploit工具自身在執行時是低權限，而獲得的shell是高權限。

有了對場景的清晰認識，檢測邏輯也就很清楚了：

某個高權限(system?uid=0?)進程(bash?cmd.exe?)的父進程爲低權限，則告警。

4.三、系統實現

    數據採集需求:根據前面大節中的思路，咱們有了場景有了規則，能夠考慮採集那些數據以及數據緯度了。在這個場景中，規則分析至少須要用到幾個必備的進程數據緯度：進程權限；進程ID；父進程ID

規則邏輯:

{
	"dsc":"Local Privilege Escalation", "cache":{ uid>0 }, "rule":{ ip=cache.ip, ppid=cache.ip.pid uid=0 } }

以上檢測規則基本上能知足多數提權場景，但實際運用中還有一些細節需讀者本身去思考完善：

一、一樣知足父進程權限低，子進程權限高的正常場景有哪些，如何去除誤報？
二、數據關聯分析中，分析流程向前追溯仍是向後追溯更易實現，更符合你本身分析系統的架構？
三、提權攻擊除了上述提到的場景，還有那些？ 

    咱們能夠看到，從行爲描述很容易刻畫攻擊場景，從而實現檢測，縱使攻擊手法變幻無窮，而關鍵路徑是不易改變的。經過行爲模型實現檢測能力，避免了各自漏洞技術細節差別帶來的規則庫冗餘(且影響安全系統性能)，也避免因檢測規則過度針對細節(特徵庫\漏洞庫)可能致使的被繞過。

5、總結

    本文是在實際入侵對抗實踐中，根據公司網絡自身環境，外部威脅特色不斷總結出來一些淺顯經驗。總的概括爲：入侵事件數據化、入侵檢測模型化、事件分析平臺化。

    在不一樣網絡環境，安全威脅形勢，對抗要求時，還須結合自身狀況做很多優化和變化。我的認爲前述不管是架構仍是數據分析模型，是在現有網絡海量數據、業務環境苛刻、外部威脅多變的狀況下一種較爲經濟易行的入侵檢測思路。