• 沒有找到結果。

一個新的以共同刺激機制為基礎之入侵偵測架構需求

第三章 一個新的以共同刺激機制為基礎之入侵偵測架構

3.1 一個新的以共同刺激機制為基礎之入侵偵測架構需求

關於 False Positive 的解決辦法,主要可以分為兩個不同的進行方向:一個是 針對入侵偵測系統的架構作改良;另一個方向是針對分析模組所選取的分析技術

(2) Cisco Threat Response 的技術:利用虛擬 主機來判斷異常狀況,以確認入侵行為。並 採用 Pattern Marching 的技術,而第三代則 加入了網路協定分析技術。

(2) Signature 比對的範圍從 String-based 再增 加 Context-based 比對,也就是能針對活動、

語意、前後之關系進行判斷。

基於「分析技術」上的改良相對於「入侵偵測系統架構」上的改良需要有較 高之運算能力與處理能力,因此較容易因所需偵測的資料量超過負荷而造成系統 出現不正常運作的狀況。經評估系統所需要處理的資料量後,本論文以架構上的 改進為主要方向。

在 Yan Qiao 與 Xie Wei Xin 所提出的「共同刺激機制」[9]之系統架構擁有 可降低 False Positive 的特性。雖然此機制需要進行第二階段額外的 Monitor Agents 監控偵測動作,但此是交由受保護的主機來執行,並不會耗費網路型入侵 偵測系統太多資源。因此本論文以此架構為基礎,並考量下列幾點需求,設計一 個入侵偵測系統架構。

z 異常封包分類處理的能力

由 Monitor Agents 所監控的私密性(Integrity)、私密性(Confidentiality)、可 用性(Availability)可知 Monitor Agents 其實是輕量級之主機型入侵偵測系統 (Light Host-IDS)。由於主機型入侵偵測系統先天上偵測範圍之限制,所以並不 是所有網路型入侵偵測系統所能偵測出的攻擊,主機型也都能偵測得出來[15]。

此狀況衍生出以下兩個問題:

(1) Monitor Agents 做白工:

Monitor Agents 在系統一開始時並未啟動,而是需等到有異常封包通過 第一階段偵測之後,被判定為異常才會被觸發而開始運作。但如果此時 Monitor Agents 監控的是一些超過本身偵測範圍之外,而無法掌控與辨 別之異常封包時,就會造成系統資源無效監控的浪費。

(2) 產生 False Negative:

當第一階段網路型入侵偵測系統所判別出的異常封包是在主機上不會 產生明顯異常狀況的攻擊封包時,若再將此類可疑封包進行第二階段 Monitor Agents 之判斷處理,則系統最後會將此類異常封包判斷為正常 封包,而造成 False Negative 型誤判之狀況,也就是入侵偵測判斷漏失 的現象。

針對上述的問題,本論文提出在第一階段被網路型入侵偵測系統判別為異常

的封包都必須先進行過濾的處理程序。將一些在主機上並不會產生明顯異常狀況 的 Monitor Agents 發現網路頻寬異常或系統狀況異常時,可能再也無法順利發出 警告封包告知防火牆把此類攻擊封包阻擋下來。因此在共同刺激機制之下,此類

現今入侵偵測系統之設計,大多僅考量該如何降低 False Positive 型誤判的機 率,而沒有考慮 Squealing 類型攻擊的偵測與判斷。但 Squealing 攻擊所造成的嚴 重性在 2-2-2 小節已經討論過,此問題也已經提報給 CERT,其重要性可知。

再者,降低 False Positive 型誤判的機率並不意味著完全不會有 False Positive 狀況的產生。若入侵者以試探式的攻擊來尋找可能的 False Positive 漏洞時,共同 刺激機制僅會把此類攻擊當成無實際攻擊的無效入侵行為,而不會做任何的反應 或記錄機制,因此系統管理員並無法察覺有人正試圖攻擊,造成系統潛在的安全 風險。由上述可知在設計入侵偵測系統時,對於針對 False Positive 弱點之

Squealing 攻擊類型不得不重視,必須擬定有效的偵測方法。

3.2 一個新的以共同刺激機制為基礎之入侵偵測架構

在 3.1 小節說明了基於共同刺激機制之入侵偵測系統的相關需求。因此在本 節我們依據這些需求,提出一個能降底 False Positive 的入侵偵測系統架構,如下 圖所示。本論文架構除第一階段網路型入侵偵測系統的偵測與第二階段 Monitor Agents 的監控外還加入了三個模組:異常封包分類模組、DoS 封包攔截模組以 及 False Positive 計數器模組,在本小節會一一介紹。

第一階段的偵測

第二階段的偵測

圖 3- 1 以共同刺激機制為基礎之入侵偵測流程

一、異常封包分類模組:

此模組的功能最主要是解決 Monitor Agents 對於第一階段網路入侵偵測系統 所偵測出來的某些無法監控之異常封包(因不會在主機上造成異常變化),或是偵 測出來已經無法做出反應(因網路已被癱瘓)的狀況。解決方法是此模組會把被網 路型入侵偵測系統所偵測出的異常封包預先分為兩大類:一是「網路型異常封 包」,另一類為「主機型異常封包」。以下是網路型與主機型分類原則的介紹:

1.網路型異常封包

因不會在主機上造成明顯異常而超出 Monitor Agents 偵測範圍的異常封 包,主要是針對「網路頻寬」與「網路協定的漏洞」進行攻擊。可以分為下列 幾種封包類型:

(1)可疑的網路流量封包 (2)掃瞄類型封包

(3)偵測系統漏洞-弱點掃瞄程式 (4)不符網路協定規格之異常封包 2.主機型異常封包

會明顯造成主機上產生異常狀況且可被 Monitor Agents 所偵測的異常封 包,主要是針對主機上之「作業系統與應用服務程式的漏洞」進行攻擊。可以 分為下列幾種封包類型:

(1)使用異常網路埠(Port) (2)不符合字串標準

(3)可疑存取行為 (4)異常的網路控制

隨著這兩種不同的異常封包分類會有著不同的處理流程,如圖 3-2 所示。網 路型異常封包就同一般的網路型入侵偵測系統的處理流程;而主機型就必須再進 一步接受 Monitor Agents 的監控,看看是否有異常狀況發生再做入侵偵測判斷,

如此一來即可避免監控代理人處理到無能為力之封包的問題。

圖 3- 2 異常封包分類處理

二、DoS 封包攔截模組:

如 3.1 小節所說明,關於 DoS 的攻擊應當交由網路型入侵偵測系統配合防火 牆來處理會比較恰當,而不須再透過 Monitor Agents 的監控判斷程序,如此才能 即時阻擋此類異常封包。下圖為本系統的架構圖,防火牆與網路型入侵偵測系統 皆配置於所有網路封包必須經過之位址,以完整監控整個網路狀況。

圖 3- 3 系統架構配置圖

此模組判斷是否為 DoS 攻擊封包的方式主要是針對網路型的異常封包來進 行處理,下述步驟為整個攔截程序的流程:

步驟 1:若異常封包所符合之特徵規則為 DoS 攻擊類別時,系統會啟動門檻 值的機制。

步驟 2:系統會同時監控區網內與區網外的網路流量狀態一段時間,判斷網 路流量是否有超過門檻值。

步驟 3:如果當網路流量超過門檻值時,就會觸發動態封包攔截的機制,直 接攔截可疑的封包。

步驟 4:當網路流量低於門檻值時,攔截程序即終止。並會返回步驟 1 的狀

三、False Positive 計數器模組:

當主機型異常封包被 Monitor Agents 監控時,主機若發生任何異常狀況,此 主機型異常封包即會被判定為攻擊封包;反之沒有出現任何異常狀況時,該異常 封包則會被判定為 False Positive 封包,如圖 3-4 所示。一般 False Positive 如果 出現頻率不高時可能屬於正常的狀況,但如果頻率過高時,則表示可能有人在嘗

False Positive 封包 主機型異常封包

圖 3- 4 False Positive 封包的判斷

針對此點本論文提出一 False Positive 計數器模組。當 False Positive 產生時 即開始計數,直到 False Positive 的產生暫停一段時間後才會終止計數。若在計數 期間內 False Positive 產生頻率超過了門檻值,此模組會自動產生警告以告知系統 管理員。除此之外,此模組還必須可以記錄一些簡易且重要的資訊以供管理員追 蹤調查,例如:攻擊位址、時間、False Positive 次數等相關資訊。

相關文件