• 沒有找到結果。

第四章 系統設計與模擬

4.2 基於Snort之測試流程

4.2.2 Monitor Agents

此 Monitor Agents 為一主機型的入侵偵測系統,在所有需受保護的主機上都 必須安裝。平時 Monitor Agents 並不會主動運作,而是在異常封包被判斷為主機

型時,才會觸發受保護主機上的 Monitor Agents 做監控。監控流程如圖 4-7 所示,

監控內容主要是第二章所介紹過的主機之三種特性,分別為:完整性(Integrity)、

私密性(Confidentiality)與可用性(Availability)。本論文採用 Norton Intruder Alert 來擔任 Monitor Agents 的角色。

如果在監控時間內主機有發生任何的異常狀況,例如,關鍵檔案被更改或系 統資源耗損不正常等任何符合上述三種特性之異常狀況時,Monitor Agents 即會 立即判定有入侵行為產生並發出警告;反之,若系統在監控期間內沒有發生任何 的異常,系統將會自動結束監控活動並將此主機型異常封包判定為 False Positive 封包,以觸發 False Positive 計數器模組來針對 False Positive 類型之攻擊作額外 的監控。

圖 4- 7 Monitor Agents 監控流程

4.2.3 DoS 封包攔截模組

封包攔截的動作是存在風險的,因為有可能因系統之入侵特徵判斷不準確而 截斷了正常的網路溝通,進而造成比遭受入侵攻擊更大的損失,因此一般採用攔 截機制所處理的異常封包必定含有以下兩個特徵:

1.肯定此異常封包確實含有入侵行為。

2.此異常封包必定會造成嚴重的影響。

基於上述因素的考量,本系統所設計之封包攔截模組僅針對 DoS 類型的攻 擊封包進行處理,因為此類型的攻擊行為明顯,常伴隨異常的網路流量,且會造

成系統無法正常服務的嚴重影響,因此適合採用。

為了更加確認 DoS 的異常封包是否含有攻擊行為,本模組攔截機制的設計 並非一開始即馬上啟動,而是需經過門檻值的再次確認,證實有被攻擊的實際狀 況才會啟動。所以要觸發攔截機制必需同時符合下面兩個條件,流程如圖 4-8:

圖 4- 8 DoS 封包攔截模組處理流程

z 必須經「異常封包分類模組」判斷為 DoS 型之異常封包:

一般而言,DoS 攻擊會造成被攻擊的目標主機當機、重新啟動,或是該主機 所處的網路壅塞,以致無法正常提供服務。而本 DoS 封包攔截模組僅是針對造 成網路壅塞的攻擊封包進行處理,其餘會造成主機狀況明顯影響的類型則屬於 Monitor Agents 的監控範圍。

z 必須超過門檻值

在此,門檻值所指的對象是含有 DoS 特徵之異常封包總數,例如 ICMP 封 包與廣播封包等,而非指所有的網路流量狀況,如此可以避免剛好因系統正在進 行大量資料傳輸時所可能造成的誤判。

另外,本模組還有一個機制,稱之為「動態攔截」。意指 DoS 異常封包流量 一超過門檻值即會啟動封包攔截機制,但如果一段時間過後又低於門檻值時,即 又會停止攔截。如此一來,便可讓入侵讓偵測系統在可接受的攻擊風險下適度地 調整異常封包的管控政策。例如,當超過門檻值時,即關閉 ICMP Echo Reply 與 區網廣播的功能,當低於門檻時又開放此類的封包流通,以達到彈性管理的優點。

4.2.4 False Positive 計數器模組

此模組用來處理經過 Monitor Agents 監控而沒有出現異常狀況的封包,特別 是用來偵測 Squealing 類型的攻擊。主要處理的程序分成兩個部分:(1)記錄下 表 4-3 所列出的相關資訊以供需要時使用,(2)計算次數判斷是否有超過門檻

False Positive 發生的原因有下列幾項:

z 入侵偵測系統的誤判: 活動發生。尤其當 Squealing 新攻擊類型被提出後,許多原本拿來測試入侵 偵測系統的 False Positive 封包產生程式(例如,stick、sneeze 等相關程式),

也變成了駭客的攻擊工具,這使得入侵偵測系統的設計廠商及組織內的網路 管理員不得不正視 False Positive 所產生的相關問題與挑戰。

4.2.5 系統模擬架構

依照前一章節所定義的系統需求與模組設計,模擬一個共同刺激機制的入侵 偵測系統架構,系統流程圖如下:

False Positive 計數器 Monitor Agents

DoS 阻擋模組 異常封包分類模組 Snort 偵測模組

第一階段的偵測 第二階段的偵測

受保護之主機上

網路型入侵偵測系統

圖 4- 9 共同刺激機制之入侵偵測系統架構模疑圖

如圖 4-9 所示,系統架構共分為五個部分,其中異常封包分類模組與 DoS 阻擋模組存在於 Snort 入侵偵測系統的內部之中,負責擷取、偵測異常以及異常 封包分類處理的工作。而 Monitor Agents 模組與 False Positive 計數器模組為一支

獨立的程式,安裝在受保護的主機上,負責監控主機的系統狀況,以判斷主機上 是否有入侵行為的產生。

DoS 阻擋模組,會針對 DoS 型的攻擊封包及門檻值判斷,來動態阻擋異常 封包,以避免遭受 DoS 型的攻擊。而 False Positive 計數器模組則會針對異常的 False Positive 頻率發出警告,以偵測出 Squealing 類型的攻擊。

4.3 模擬結果與分析

本小節主要針安全性來進行實驗,驗證本論文基於共同刺激機制所提出之入 侵偵測架構的安全性。實驗主要分為二個部分:(1)False Positive 攻擊,與(2)一 般長期監控狀況。

4.3.1 安全性

„ False Positive 攻擊 實驗步驟:

1.先將 Snort 規則中,屬於主機型攻擊之入侵規則挑選出來,以供測試。

2.利用 False Positive 之封包產生程式"sneeze"來讀取上步驟所挑選出 之主機型攻擊規則,以產生多次偽造封包的攻擊來進行測試。由於這些封 包是針對 Snort 的設定檔所產生,所以皆會符合 Snort 的入侵偵測規則,

而沒有實際的攻擊行為。

3.監控被攻擊端主機的狀況,看看是否有符合預期狀況。

實驗結果:

在實驗步驟一中,可能由於"sneeze"程式尚未隨 Snort 版本更新,造成原 本 Snort 規則中有 46 種規則類別,經過濾後僅剩 11 種規則類別能正常運作且能 產生 False Positive 的無效攻擊封包,而這 11 種規則類別還必需扣除三種不屬於

主機型異常封包所對應的規則類別,最後符合實驗需求的僅剩 8 種規則類別,如 階段的 Monitor Agents 監控後皆被過濾掉,且沒有產生任何主機型的警告。但隨 著 False Positive 攻擊次數的不同,會觸發 False Positive 警告數也不同。

表 4- 4 攻擊的次數與所觸發 False Positive 警告整理表

經由 False Positive 攻擊實驗之結果,可知本論文所提出的共同刺激架構確實 能大量過濾掉僅有攻擊特徵而無攻擊行為的警報,並且能針對異常的 False Positive 頻率發告警告。

„ 長期網路監控 實驗操作:

持續監控 25 天交通大學網路環境下的入侵偵測狀況。並根據所記錄的數據 作解讀與分析。

實驗結果:

警告

時間日期

圖 4- 10 監控交通大學內網路異常狀況記錄

上圖為監控期間的每日警報數示意圖,每日主機在網路上遭受異常攻擊的次 數大約介於 100 至 8500 間,幅度相當的大。我們可以發現當主機可能成為被攻 的目標時,當日的異常記錄會特別地多,例如在監控的第五日時,我們可以看到 警報次數記錄異常的高,這是由於主機當日遭受大量的掃描行為所造成,而掃描 的動作為一般入侵行為的前置作業,因此當遭遇到此現象時,必須特別留意主機 的狀況。

表 4-5 為整個監控期間內的相關統計數據,由此表可知在此監控期間內總共 web-application-activity

535

(2%)

535(0) 0

misc-activity

1963

(7%)

71(0) 1892

protocol-command-decode

2361

(8%)

2361(1) 0

attempted-admin

2426

(8%)

2426(1) 0

attempted-recon

144

(0%)

12 132

misc-attack

71

(0%)

71 0

web-application-attack

115

(0%)

115 0

shellcode-detect

1438

(5%)

1438(2) 0

4.3.2 效率分析

由 4.3.1 小節之「長期網路監控實驗」的數據可知,本系統架構能減少因 False Positive 所造成的無效警報數,及減少 Monitor Agents 所需監控之封包 數目以提升系統的效率,詳細的介紹如下所述: 減少。這是因為原共同刺激機制並沒有考量到偵測 Squealing 類型的攻擊,以及 沒考慮到「並非所有網路型入侵偵測系統所偵測到的異常封包皆能讓 Monitor Agents 偵測出異常狀態」所造成,因此所減少警告的部分是屬於 False Positive 警報與 False Negative 遺漏警告的狀況。由以上的推論可知,本系統的設計確實 可以降低 False Positive 而減少無效的警告數,並且降低原共同刺激機制所可能發 生 False Negative 的問題。

0

Monitor Agents所需 監控的封包數

z 減少 Monitor Agents 所需監控之封包數目

由 4.3.1 之「長期網路監控實驗」的數據可知,原共同刺激機制所需進行第 二階段監控的異常封包數目為 29373 個,而本論文利用異常封包分類處理的機制 後,所需監控的異常封包大幅度降至 7029 個,整體來說,大約減少了 76%之 Monitor Agents 所需監控封包,如下圖所示。

29373

Monitor Agents,耗損主機額外的系統資源,但如此的設計,卻可有效地增加入 侵判斷的準確性與降低 False Positive 型誤判的機率。

因此,本論文所建構的共同刺激機制之入侵偵測系統架構,對於 False Positive 問題的解決確實是具有可行性與有效性。

第五章 結論及未來發展

5.1 結論

本論文主要貢獻為提出一個基於共同刺激機制的入侵偵測系統架構,內容除 了兩階段式之「網路型」與「主機型」的入侵偵測外,還包含了異常封包分類處 理、DoS 攔截機制、以及偵測 False Positive 攻擊等。由實驗結果顯示本架構確 實可降低系統分析判斷時所造成的 False Positive,並可偵測出 Squealing 新類型 的攻擊以增加網路的安全性。與 Yan Qiao 和 Xie Wei Xin 在 [9]一文中所提出之 架構相較下可減少所需進行第二階段監控的異常封包數目等優點。

由於主要的偵測效率還是基於原本系統的分析能力,所以異常封包分類模組 的正確性,將對偵測結果產生重大影響。例如,把監控代理人所無法監控異常的 網路型異常封包判斷為主機型的封包時,會因此而產生 False Negative,也就是 會漏失掉此入侵攻擊警告。

由於 Monitor Agents 是直接監控主機上的狀況,因此當發現異常時,大多是 入侵行為早已發生,接著我們只能做些急救的措施來補救。這和僅僅使用網路型 的入侵偵測系統比較起來,網路型入侵偵測系統所做的大多是預測的行為,因為 封包尚未送達攻擊目標,所以入侵行為還尚未產生。針對此問題未來可改良

相關文件