淺談大型網絡入侵檢測建設

博文作者：xti9er[TSRC]

釋出日期：2013-07-10

博文内容：

一、前言

    伊朗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攻擊通常較為隐蔽不易觸發單點的安全政策和檢測，需要更多緯度和大視角的資料分析。

    傳統安全産品單純依靠特征庫的檢測模式，效果已大打折扣。黑客工具千變萬化，攻擊手法層出不窮，但他們的目的不變，行為就是殊途同歸的。是以，在原有特征檢測技術之外，用行為模型能更好的檢測入侵，我們提出以下檢測模型：

3.1、單點事件描述資料的行為分析

    例如一個程序的啟動，程序自身的行為與環境資訊。

 圖4 異常程序

    這裡你看到了什麼？以下均可作為惡意程序檢測規則。

 1) 父程序為IE；

 2) 程序運作在IE緩存目錄；

 3) 程序PE資訊：加殼,未簽名, 多個PE頭部 等

3.2、上下文事件關聯分析

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

圖5 ProFTPD 漏洞

    這是ProFTPD的一個遠端緩沖區溢出漏洞攻擊後的結果，從pstree可以看到proftpd程序派生了一個bash子程序。正常情況下bash通常隻會從系統登入後的sshd\login等程序啟動，這可作為一個異常告警邏輯。大家再想想這個場景還會有那些特征？

規則描述

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

規則邏輯:

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

 1、同樣滿足父程序權限低，子程序權限高的正常場景有哪些，如何去除誤報？

 2、資料關聯分析中，分析流程向前追溯還是向後追溯更易實作，更符合你自己分析系統的架構？

 3、提權攻擊除了上述提到的場景，還有那些？

    我們可以看到，從行為描述很容易刻畫攻擊場景，進而實作檢測，縱使攻擊手法千變萬化，而關鍵路徑是不易改變的。通過行為模型實作檢測能力，避免了各自漏洞技術細節差異帶來的規則庫備援(且影響安全系統性能)，也避免因檢測規則過分針對細節(特征庫\漏洞庫)可能導緻的被繞過。

五、總結

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

    在不同網絡環境，安全威脅形勢，對抗要求時，還須結合自身情況作不少優化和變化。個人認為前述無論是架構還是資料分析模型，是在現有網絡海量資料、業務環境苛刻、外部威脅多變的情況下一種較為經濟易行的入侵檢測思路。