中 華 大 學
碩 士 論 文
題目：企業資訊危機處理系統
The Enterprise Information Emergency Response System
系 所 別：資訊管理學系碩士班 學號姓名：M09110010 翁子明 指導教授：王 偉 德 博士
中華民國 九十三年 六月
中文摘要
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
企業資訊危機處理系統
研究生：翁子明 指導教授：王偉德 博士
中華大學資訊管理學系
摘要
隨著公司營運的擴大，企業內部各種平台的伺服器增加，系統管理成為單 調冗長卻又重要的課題。伺服器必須 24 小時不停的提供服務。當有問題發生，
目前的解決方式都是發送郵件或簡訊給 MIS 人員而已，對於如何即時的解決問 題幫助不大。因此本論文提出利用軟體代理人(Software Agent)偵測系統，配合企 業內部政策(Policy)以及透過 Web Service 的方式，讓 MIS 人員可以於任何時間 地點，透過 Mobile 裝置線上解決問題的完整架構。另外本系統對網路安全課題 亦提供解決方案。目前，hacker 盡可能利用作業系統本身的安全漏洞，破壞或竊 取系統系統資源。或是利用 TCP/IP 通訊協定的弱點，藉以傳送大量封包以阻絕 系統服務(DoS)。為了有效解決入侵問題，本研究利用已知的 Java 技術、Script Language、資料庫與入侵偵測軟體(Snort)，提出一積極式網路防禦架構，並配合 前述之 Policy，整合成較完整的危機處理系統，以有效提升組織內部系統與網路 安全，並避免企業產生巨大損失。
Abstract
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿
The Enterprise Information Emergency Response System
Student：Tz-Ming Weng Advisor：Dr. Wai-Tak Wong
Department of Information Management, Chung-Hua University, HsinChu, Taiwan, ROC
Abstract
As many companies have expanded the business scope and increased servers for all kinds of platforms in internal organization, system management has become a tedious but crucial subject. When a problem occurs, most solutions are only notifying to MIS employees. It is helpless to solve the problems at all. In this paper, we propose an integrated architecture which utilizes Software Agent Detection System with Enterprise Policy management, the technology of Java Web Service and Mobile instruments. Our system enables MIS employees to solve the problem on-line at any time. Besides, our system provides a solution for security issues. Usually hackers may take advantage of multiple security holes to destroy or steal system resources, or utilize the weakness of TCP/IP to transmit volumes of packets. In order to prevent the intrusion effectively, we adopt java technology, script language, database and snort to construct a network defense architecture. This system will give a total solution for network security crisis to avoid the huge loss in enterprise.
致謝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿
致謝
本論文能順利完成，要感謝很多人，包括那陪我一路走來於背後支持我的長 輩和朋友。首先，要感謝我的父母，於求學過程中不斷地給予我鼓勵與關懷。再 者，要感謝指導教授王偉德老師於求學上給予很大的啟發與教導，並指引我正確 的學習態度與方向。亦感謝口試委員鄭伯炤、陳育亮、劉立民等教授能於繁忙之 餘，不辭勞苦撥冗前來指導論文，予以我很多很寶貴的意見。
另外，也要感謝同學忠平、子睿、德峰、小胖及育政、建豪、文銘等學弟，
於學業上給予指點和豐富了研究所的兩年生活，沒有大家相伴與鼓勵，要走過那 奮鬥的歲月勢必更加辛苦。當然也要感謝女朋友熊熊的陪伴，讓我能夠安心於課 業之上。
最後，慶幸能於中華大學做研究，有幸認識許許多多相扶持的好友，並陪我 一路走來度過很多的挫折與難關，終能在此留下美好的回憶。願在此與我的父 母、師長及所有好友分享我的榮耀，也祝福他們永遠都健康快樂。
致謝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿
目錄
中文摘要……….. I 英文摘要……….. II 致謝………... III 目錄………... IV 圖目錄……….. VI 表目錄……….. VIII
第一章 緒論……… 1
1.1 研究背景與動機……….. 1
1.2 研究目標……….. 3
第二章 文獻探討………... 4
2.1 記錄檔分析……….. 4
2.2 軟體代理人……….. 6
2.3 網路攻擊手法……….. 6
2.3.1 DoS 攻擊……….. 6
2.3.2 DDoS 攻擊………... 7
2.4 入侵偵測系統……….. 8
2.4.1 IDS 種類……….….. 9
2.4.2 不當使用 vs 異常使用………... 9
2.4.3 主機型 IDS vs 網路型 IDS……….… 10
第三章 企業資訊危機處理系統……….. 13
3.1 系統概觀與架構……….. 13
致謝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿
3.1.1 系統偵測架構……….. 14
3.1.2 系統通知與解決架構……….. 15
3.1.3 系統設設……….. 16
3.1.4 資料庫……….. 16
3.1.5 前端系統……….. 18
3.1.6 偵測系統……….. 20
3.1.7 代理人角色定義……….. 22
3.2 系統實做……….. 23
3.3 系統限制……….. 28
第四章 積極式網路防禦架構……….... 29
4.1 架構介紹……….. 29
4.1.1 入侵偵測系統……….. 30
4.1.2 中央控管伺服器……….. 31
4.1.3 企業資訊危機處理系統……….. 32
4.1.4 服務登錄伺服器……….. 33
4.1.5 ISP 服務提供者………... 33
4.2 架構運作方式……….. 34
4.3 架構測試……….. 35
4.4 架構可行性探討……….. 38
第五章 結論……….... 41
參考文獻………... 43
圖目錄
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿
圖目錄
圖 1-1 一般防禦架構………... 2
圖 3-1 系統架構……….……..…... 14
圖 3-2 系統偵測架構………...……….…….…… 15
圖 3-3 系統通知與解決架構……….…… 16
圖 3-4 系統登入流程圖………. 19
圖 3-5 Troubleshooting 流程圖……….…. 20
圖 3-6 訊息製作流程……….… 22
圖 3-7 發送訊息流程……….… 23
圖 3-8 實驗環境圖……….… 25
圖 3-9 記憶體偵測圖……….… 25
圖 3-10 系統目前狀況……….… 26
圖 3-11 警告訊息………..…..………. 27
圖 3-12 線上 Troubleshooting……….…. 27
圖 4-1 ANDA 架構圖………...……….…. 30
圖 4-2 IDS 放置圖………..……….…...…... 31
圖 4-3 封包經過節點示意圖………... 34
圖 4-4 架構運作示意圖………. 35
圖 4-5 防禦架構測試環境圖………. 36
圖 4-6 攻擊測試主機………. 37
圖 4-7 攻擊 IP 紀錄………... 38
表目錄
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
表目錄
表 3-1 資料庫 table……….... 18
表 3-2 系統開發平台與工具………...….. 24
表 4-1 測試機器 IP 與作業系統………... 37
表 4-2 追蹤方法……….….……… 40
緒論
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿＿＿
第一章 緒論
在一切都資訊化的今天，企業內部伺服器是否能夠正常運作，攸關企業整體 的競爭力。如何即時偵測到伺服器問題，與立即運用手邊的儀器設備解決問題，
避免企業損失，是如今我們需要面對的課題。而在網路安全上，也攸關企業是否 能夠正常提供營運、保護內部機密資料避免外洩的重要因素。因此本論文將在伺 服器本身的監控與提供有效的主動積極防禦做兩方面的探討與研究。
1.1 研究背景與動機：
隨著企業規模的擴大，依賴電腦的程度也越來越深。在公司的伺服器上，
放置著各式各樣的資料，例如 Web Server、PDC、File Server、防火牆、Proxy Server 等提供各種服務。當伺服器運作正常，一般人的警覺性就容易降低，忽略了電腦 可能發生的問題。一旦發生問題，若正值休假或是管理人員出差在外，不能即時 解決問題，就會讓公司蒙受巨大的損失。
目前作業系統本身對於提供的 Service 也會做記錄，記載於固定的目錄中供 管理人員分析管理。但是可能發生的問題多如牛毛，記錄檔也過於龐大，服務繁 忙的主機，記錄檔甚至到十幾 Gigabytes，難以用一般的方式分析。目前對於電 腦運作的分析監控研究相當多，也都有公司實作出來。而 Anand, Tanvir, Sumedh 和 Carney[1-2]也提出使用 Agent 的方式，可以遠端監測分析記錄檔。但是其對 於即時解決問題仍沒有提出有效的方法。
為了瞭解公司內部伺服器運作狀況，並且在發生問題時可以即時解決問 題，本研究提出一個企業資訊危機處理的架構，透過自行設定的 Policy，可以讓 主機管理人員即時知道問題現況，並且線上除錯以減少企業損失。
在此之前，曾經實際訪問過台灣 IBM 的資深網路工程師，表示目前像台灣 IBM 自己內部本身也無類似 Policy 機制，而他也幫國家高速網路與區網中心建
緒論
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿＿＿
置過網路環境，就其了解也並無類似機制。所以目前欠缺一套解決方案，可以幫 助企業立即也有效的解決伺服器發生問題的危機，此為主要的研究動機。
除了系統本身問題之外，來自網路的威脅也與日俱增。現今的網路攻擊行 為，可以利用木馬程式、系統缺失或網路協定的疏漏等，發展出複雜且多樣化的 攻擊方式。不但能夠隱藏來源，並成功入侵系統主機竊取機密資料、竄改文件，
之後再修改系統記錄。又或者 hacker 事先入侵某幾台電腦，之後在一特定時間 共同對某一台伺服器發出許多的 request，使其疲於應付，進而讓伺服器無法對 正常的使用者提供服務，就達成攻擊者預期的目標。Yahoo 在 2000 年 2 月即遭 到此「阻斷服務」(Denial of Service，DoS)的攻擊，在系統資源耗竭，負荷過重 而癱瘓，無法服務正常的網路使用者，時間長達三小時。之後還有 eBay.com、
Amazone.com 和 CNN.com 亦遭受到 DoS 的攻擊，損失超過數百萬美元。
現行防禦駭客所採用的方法[3-4]，大部分是用防火牆配合入侵偵測系統 (Intrusion Detection System)[5-7]，如圖 1-1 所示。
圖 1-1 一般防禦架構
緒論
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿＿＿
遭受攻擊時，雖然可以利用增加防火牆規則的方式來阻擋駭客的入侵，但 是若攻擊的機器數量一多，無疑將增加防火牆的 Loading。封包雖然可以丟棄，
但是仍需先到達防火牆的網路介面，一旦封包數過多，網路頻寬依舊會壅塞不 堪。傳統的被動丟棄封包方式，似乎不盡理想，其較屬於消極的被動防禦方式，
如何有效的解決此問題，也是促成本研究的重要動機。
1.2 研究目標：
本研究利用 JAVA 跨平台的特性，設計了一套企業資訊危機處理系統。每家 公司對於伺服器都有不同的 Policy，藉由訂定 Policy 的方式，偵測程式動態的偵 測系統現況，分析系統記錄檔。當發生問題的時候，偵測程式會將發生問題的狀 況通知維護人員。通知的方式可以透過 Email、B.B.Call 或是手機 Message 的方 式，當維護人員收到訊息，就可以利用手邊的裝置，例如 Desktop、NoteBook、
PDA 甚至是其他的 Mobile 裝置，連線到公司 Web Server。
在 Web Server 上就可以傳送指令或是 Script，藉由防火牆內部的 Web Container 轉送給問題主機，再將執行結果傳回給外部人員。達到即時解決問題 的目的。並且若第一線維護人員沒有解決，透過 Policy 的訂定，可以自動升高 層級通知第二線維護人員或是相關單位主管，讓其知道公司內部伺服器發生問題 等待解決。
網路攻擊方面，為了可以針對發生網路攻擊或入侵行為時可以主動且較積 極 性 的 防 禦 ， 我 們 提 出 一 個 積 極 式 網 路 防 禦 架 構 (Active Network Defense Architecture，ANDA)，其可利用現有之IDS，當偵測到入侵行為，可以使用防火 牆做防禦之外，亦可整合Java Web service的架構，配合ISP的聯防，將惡意攻擊 封包阻擋在加入聯防ISP的Router上，如此可有效降低企業防火牆的Loading、減 少惡意阻塞企業頻寬行為。另一正面的意義，是讓惡意的攻擊封包不至於在 Internet上流竄，進而提高整個Internet的利用率。
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
第二章 文獻探討
本章節藉由軟體代理人、Log 分析等相關文獻來闡述監控系統之需求與特 性，由學者論點來印證監控系統與即時回應處理仍有待加強的地方。而在網路攻 擊的防禦方面，首先介紹一些攻擊手法，歸納出其特徵，並以偵測方式與建置方 式分別探討入侵偵測系統的基本觀念。之後再探討近年來 IP 追溯機制的研究，
並研究其所能追溯形式的優缺點。
2.1 記錄檔分析
系統執行各種服務或程序時，都會留下記錄(log)以供管理人員參考，所以當 發生各式問題時，log 檔的存在就很重要。但是面對龐大的 log 檔，該如何擷取 出我們需要的資訊，就是一個很重要的課題。目前有許多的研究著重在此方面，
也有很多的軟體實作出來來做監控。
Tetsuji and Hideki[8]提出使用視覺化的資訊系統來做電腦安全方面 log 的監 控與調整。他認為監控 log 有幾個困難的地方：
i. 每個 log 都是文字檔，閱讀並了解他是件令人厭惡且浪費時間的工作，
另外只從單一的 log 中分析實際的侵入行為是不太可能的，因為每一個 log 大概都只提供有關使用者行為的破碎資訊而已。
ii. log 檔太大了，不可能只靠人工監控，這也是為何管理員都盡量避免完 成此工作的原因之一。
iii. log 很難直接套用某個規則就做監控。例如針對使用者的行為與連線地 點做監控，目前只能判斷是否有問題的二分法，但卻不能彈性的判斷”
可疑的”(suspicious)事件。。
因此他們提出使用視覺化的方式來做 log 資訊的分析系統，稱為”Tudumi”。
此系統可以將數個 log 的資訊做關連，將其形象化(visualized)成圖形。建立一個
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
有意義的模型(meaningful model)，便可以輕易的從破碎資訊中，萃取資訊讓人們 判斷資訊間的相關性。
Anand 提出使用 mobile agent 的方式[2]，可動態的擴充條件來監控記錄檔。
他認為一個完整的監控系統至少需要以下條件：
i. 動態設定(Dynamic Configuration)：在監控、收集與處理資訊時，需要 可以動態改變 Policy，以應付新增軟硬體元件時，可以動態的安裝監控 agent 與將其整合至現有系統中。
ii. 動態擴充(Dynamic Extensibility)：可以擴充現有監控、收集、處理的機 制，並且可以在不中斷現有操作下做擴充。
iii. 主動式監控(Active Monitoring)：在偵測範圍內，可以自動針對的緊急 事件做出應變。例如偵測到緊急事件時，監控系統可以增加警戒的層 級，並且額外監控其他平時沒有發生的事件。
iv. 可提供管理上的安全政策(Support for Administrative Security Policies)：
大型系統通常都會分割成好幾個管理區塊。一個好的監控系統應該提供 安全性政策，避免資訊外流到不同的組織區塊去。
v. 監控環境可受到保護(Protection of Monitoring Infrastructure)：監控系統 應該可以保護自己避免遭受攻擊。
vi. 效能和延展性(Performance and Scalability)：在大型網路中，監控系統應 該可以提供組織對於收集和處理資訊所需要的等級。
另外現今很多是用 SNMP 的方式做收集資訊，再利用 Script 做週期性的分 析或記錄，但是其方式並不彈性[1]。例如此方法無法動態的擴充監控程式，或 者當受監測的主機數量開始增長時，仍得利用人工方式一個一個增加，而且若程 式有更改，也不能自動 update。但是此方法仍有強悍之處，例如配合正規表示式 (Regular Expression)，對於 log 檔的字串做分析比較，可以說非常強悍。同樣的 工作若以 C 語言完成，可能要多出數倍的工作才可達到同樣的效果。
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
2.2 軟體代理人
軟體代理人(Software Agent)在網際網路的推波助瀾下，有越來越多的研究著 重在此方面。例如網路監控[2]、網頁瀏覽輔助、資訊檢索[9]。 Maes[10-11] 定 義代理人程式能夠提供不同層次的協助，並隱藏工作的複雜性以代替人們工作。
另外它也能夠監測周遭環境的變動。他也認為代理人程式是存在於變動環境中，
可以自主性感測環境的改變，並且採取適當行動以因應變化的計算系統，以完成 當初設計所交付的任務。
Smith[12]認為代理人是為了特定目的而持續運作的軟體，代理人了解該如 何完成其工作項目或任務。「特定目的」是要讓代理人和副程式(Subroutines)做區 別，「持續運作」是要區別代理人和多功能應用程式的不同。
Koller[9]定義代理人程式需可以持續的執行三項功能：(1)可以動態的感知周 遭環境的改變。(2)可以執行動作來影響環境條件。(3)可以根據偵測到環境的變 化，進而做出適當的行動。另外 Selker[13] 認為代理人應具備類似人際關係的能 力，例如溝通(communication)、協調(coordination)以協助人們完成工作。
2.3 網路攻擊手法
瞭解目前常用的攻擊手法，有助於提升管理人員在網路安全的應變能力，
保障系統安全。並且在追蹤與人工判斷上可以正確抉擇，避免誤判。以下分別敘 述各種網路攻擊的手法[14][15]：
2.3.1 DoS 攻擊
阻絕服務 (Denial of Service，DoS)攻擊，是藉由傳送大量的封包，或是利用 TCP/IP 協定的疏漏，消耗網路的頻寬或是使伺服器的資源耗竭，無法提供服務 給正常的使用者。常見的攻擊手法大致上可分為：
i. TCP SYN flood DoS
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
攻擊者 A 利用 TCP 連線的三段式交握(Three-Way Handshake)機制的疏 漏，以每秒傳送數千個 TCP SYN 封包給受害主機 V 請求(Request)連 線，V 收到 Request 時，會傳回 SYN/ACK 封包確認，但 A 並不再接收 V 所送出來的封包，使的 V 在 SYN Queue 中累積過多的等待回覆確認。
因系統預設的 SYN Queue 長度有其限制，而且為考慮網路狀態，預設 均會等待到一特定時間，若一直沒有回應才會予以丟棄。但 V 的 SYN Queue 塞滿了 A 的請求封包，導致 V 一直無法讓其他使用者建立連線 來提供正常服務。
ii. UDP flood DoS
UDP flood DoS 又稱為 Fraggle 攻擊，攻擊者透過偽造來源的 UDP 封 包，送到目標網路的廣播位址(Broadcast IP)，讓該網域的所有主機回應 echo 封包至受害主機 V，產生擴大效應的資料流，使的 V 忙於回應，
造成網路壅塞或使 V 的 CPU 負荷過重而無法提供服務。即使該網域關 閉 echo 功能，路由器仍會產生 ICMP(Destination Unreachable)封包，一 樣達到 DoS 消耗頻寬的效果。
iii. Ping of Death
攻擊者對受害主機 V 發送過長的 Ping 封包甚至將長度改為負的，此時 若 V 沒有做好資料長度的限制時，過長的資料覆蓋到 V 的其他部分資 料或系統，有可能造成 V 發生錯誤而當機。
2.3.2 DDoS 攻擊
分散式阻絕服務(Distributed DoS，DDoS)是攻擊者事先侵入、控制許多主機 Z，在特定時間時，遙控這些傀儡主機下達攻擊指令，讓受害主機 V 疲於應付而 無法服務。常見攻擊分類如下：
i. TFN DDoS
Tribe Flood Network(TFN)[16]是針對 UNIX 作業系統的 DDoS 攻擊工
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
具，攻擊者 A 先侵入許多機器，之後在透過遠端遙控方式，共同對受 害主機 V 傳送大量封包(SYN、UDP、ICMP、Smurf 等)，造成 V 無法 提供服務。
ii. TFN2k DDoS
TFN2k 是 TFN 的更新版本，他允許使用隨機的連接埠，並提供加密功 能，而且還可以在 SYN、UDP、ICMP、Smurf 攻擊型態之間互換，以 避免網路設施(如防火牆、路由器或目標主機)與入侵偵測系統無法有效 偵測防範，達到癱瘓網路頻寬或目標主機無法提供服務的目標。
iii. Trin00 DDoS
攻擊者 A 藉由 UDP 封包入侵許多傀儡主機 Z，在 Z 上面值入木馬，該 木馬受控於 A 的 Trin00 Master，當 A 對 Z 下達攻擊指令，Z 會對目標 主機 V 送出大量的 UDP 攻擊封包，並不斷的改變目的地埠號，造成 V 產生大量的 ICMP Port Unreachable 訊息，使 V 無法提供服務。
iv. 蠕蟲(Worm)
蠕蟲多利用作業系統或應用程式本身漏洞，例如緩衝區溢位(Buffer Overflow)、微軟的 IIS、遠端程序呼叫(Remote Procedure Call，RPC)等 漏洞進行攻擊。常見蠕蟲如 CoreRed、Sobig、Blaster、Sasser 等不勝枚 舉。遭遇的狀況可能是資料庫或文件損毀、寄發病毒信、DDoS 攻擊或 被安置木馬而遭竊取帳號密碼等等。
2.4 入侵偵測系統(Intrusion Detection System，IDS)
IDS 係針對網路上或主機上的可疑活動進行偵測與分析，藉由「不當使用」
（Misuse Detection）及「異常使用」（Anomaly Detection）方式[17]，偵測出外 部攻擊者及內部人員對未經授權之資訊系統所做的不正當存取或攻擊行為。單獨 建置 IDS 並不能夠保證網域的安全性，通常需配合防火牆、連線追蹤、安全政 策、網路弱點稽核和權限稽核等等，方能建構較為完整的入侵偵測的解決方案。
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
2.4.1. IDS 種類
一般而言，IDS 可以三種方法來分類，一、依入侵偵測所使用的資訊“來源”；
二、依所蒐集資訊的分析方法；三、資訊的分析型態。
IDS 依所使用的資訊來源可分為[18]：主機型入侵偵測系統（Host-based IDS，
HIDS）、網路型入侵偵測系統（Network-based IDS，NIDS）及混合型入侵偵測 系統（Hybrid IDS，Hybrid IDS）三大類。HIDS 安裝在重點檢測的主機上，主要 是對該主機的網路連接與系統審計日誌進行智慧分析與判斷。在 Windows NT 環 境下通常監測系統、事件與安全日誌，在 UNIX 環境下則監控系統日誌。NIDS 以網路原始封包作為監測來源，其使用「混亂模式」(promiscuous mode)來偵測 與分析過往的網路封包，通常是建置在網路的骨幹上。而 Hybrid IDS 以 HIDS 為基礎，監測系統的日誌及重要檔案的變化，亦有 NIDS 監督網路流量的功能，
但其在佈署的位置較有疑問，故一般較少人使用此種方式。
IDS 的分析型態計包括：不當使用(misuse)與異常使用(anomaly)，前者需先 蒐集攻擊活動的規則，再採用比對方式，與建立的規則相同或相似者即判定為疑 似攻擊行為。後者以統計的方法歸納系統或網路正常使用的活動樣本（pattern）， 依此找出異常活動，而入侵行為其實就是異常活動的子集合。也有利用兩者的混 合型態做入侵分析，主要以不當使用做基礎，輔助以異常使用確認疑似攻擊，以 提升偵測正確性，降低誤判的機率。
一般而言，IDS 是以不當使用及異常使用或 HIDS 及 NIDS 來分類類，以下 敘述之。
2.4.2. 不當使用 vs. 異常使用
「不當使用」的偵測方式又稱為「特徵比對」（Signature-based matching）方 式，為負面表列，凡是符合特徵的封包才會予以攔截，類似病毒碼的機制。比對 的方式是將所有入侵行為和手段及其變種，包括系統的誤用，表達為一種模式或 特徵，建立一個入侵模式庫。之後將封包特徵與系統事先定義的攻擊模式資料庫
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
進行分析比對，一旦發現是相似的攻擊模式，即視為攻擊行為。
「異常使用」的偵測方式又可稱為「政策比對」（Policy-based matching）方 式，為正面表列。其先假定凡是發生入侵行為時，必定異常於正常的主體活動。
其先建立主體正常活動的模式檔案，再將目前正在活動的主體狀況跟模式檔案相 比較，當違反其統計規律，則其可能就是「入侵」行為。主體可能是 CPU 或記 憶體的使用率、用戶登入時間、密碼錯誤次數，甚至是鍵盤打字速率都可以當作 主體的模式檔案。
此兩種方式各有其優缺點：
1. 網路上攻擊模式日新月益，因此，「不當使用」的攻擊模式資料庫亦需不 斷更新，才能防範新的攻擊手法。但是其可以詳細、準確地報告出遭受的攻擊類 型，並且誤報率低，但是對於未知的入侵攻擊行為卻無法得知。
2. 「異常使用」優點是可以偵測到未知的入侵，並且可以藉由 Training 的 方式，讓其學習使用者的習慣，從而具有較高的檢出性與可用性。但如何建立正 常活動的模式檔案，以及設計正確的統計或基因、類神經等方式來 Training，以 避免將正常的活動誤判為入侵行為。甚至可能駭客已經先行入侵，系統 Training 已被蓄意將之後的入侵活動都視為正常活動。另外其誤報、漏報率較高也是缺點 之一。
2.4.3. 主機型 IDS vs. 網路型 IDS
HIDS 是一軟體程序（Process），在 UNIX 系統，檢查的項目通常包括 Syslog、
Messages、Lastlog、Wtmp 等。在 Window 系統上，則檢視系統、安全、事件日 誌紀錄等檔案。由系統管理者設定或 HIDS 程式預設固定間隔時間 t，HIDS 每隔 t 時間，就會讀取日誌紀錄，並與事先定義的規則比對；若為「不當使用」偵測 方式，一旦發現某筆日誌紀錄符合某項攻擊規則，就會發出警告。若依「異常使 用」偵測方式，則發現某筆日誌紀錄不在事先建立的正常使用模型中，才發出警 告。
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
近年來，也發展出一種以作業系統執行程式呼叫(System Call)的方式，配合 日誌檔的稽核，可以針對使用者的打字速度、軟體使用習慣、密碼錯誤率等，事 先建立統計模型用於 HIDS 上，若不符合使用者的正常使用習慣，則會判定為入 侵行為。
NIDS 是以軟體程序或硬體形式建置於特定的硬體系統上，通常是將網路介 面設定成錯亂模式，以接收到該網域的所有傳輸封包，再利用 Sniffer 機制擷取 有用的封包資訊，其次和事先定義的攻擊規則相比對，來判斷可能的攻擊封包。
通常，NIDS 是以「不當使用」偵測方式為原則；當然，也可以根據來源位址、
目的地位址、來源通訊埠及目的地通訊埠來檢查封包，判斷其是否為攻擊封包。
i. 主機型 IDS 之優缺點 優點：
a. 只要有攻擊行為就會產生紀錄訊息或是作業系統呼叫，不會遺漏任何針 對其所在主機的攻擊。
b. 可以依據日誌紀錄或檢視系統檔案或設定檔是否被竄改、存取權限是否 得宜及企圖暴力破解密碼等行為，來判斷是否已經遭到攻擊。
c. 安裝於主機上，較能和作業系統整合。
d. 在意合法使用者的異常使用甚於外部攻擊者可採用此法。
缺點：
a. HIDS 亦為作業系統的程序之一，需佔用系統資源，可能會影響其他軟 體的執行效率，特別是檢查系統呼叫的 HIDS。
b. 很難將所有主機用 HIDS 保護，只能選擇部份主機保護，而入侵者可能 選擇未安裝 HIDS 的機器作為攻擊目標。
c. 在反應的時間上，依賴於定時檢測的時間間隔，所以反應較差。
d. 不同的作業系統，需要不同的 HIDS 偵測引擎，當作業系統升級時，相 對也需要升級 HIDS，在安裝與維護管理上較不方便。
文獻探討
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿＿＿＿＿
ii. 網路型 IDS 之優缺點 優點：
a. 通常 NIDS 是配置私有 IP，NIDS 可以完全在網路上隱形，所以攻擊者 並不會知道自己的攻擊行為己經被監控了。
b. 一部 NIDS 可以監控其內部網域對外及對內的所有封包，因此不需要改 變主機的配置，也不會影響主機的效能，所以成本效益較高，不像 HIDS 僅監控其所在主機。
c. NIDS 故障並不會影響日常業務，部署一個 NIDS 比部署一個 HIDS 的 風險小的多。
缺點：
a. 可能因網路流量太大，來不及蒐集封包，而遺漏了部份封包資訊。因此 在網路用量尖峰時刻，準確度會降低。
b. 無法判斷疑似攻擊封包是否已對內部的主機進行攻擊。
c. 其常採用特徵檢測的方式，可以檢測出普通的攻擊，但對於需要大量的 運算與分析時間卻很難實現。
d. 無法檢視加密過的封包，如：IPSec。雖然目前以加密通道攻擊較少，
但隨著 IPv6 普及此問題將日漸受到重視。
兩種 IDS 均有其使用風險考量，端看組織主要用途與防範何種安全議題而 定。另外在 NIDS 上，有許多現成的軟體，例如 Snort、NetRanger 和 ISS RealSecure 等。HIDS 在軟體上則有 BlackICE 和 Rainbow。硬體也有廠商實作，例如 Cisco、
SonicWall 均有 IDS 產品，並且可配合該公司的其他產品，能夠更有效的擴充其 防禦能力。
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
第三章 企業資訊危機處理系統
近年來企業倚賴資訊系統日深，甚至已成為主要的營收來源，雖然系統本 身也有記錄檔，但是發生問題時仍須人工察看才能發現，或是臨時在外不能解決 問題。目前雖有許多系統能夠在發生問題時就發出 mail 或手機簡訊通知管理人 員，但是仍有跨平台的整合問題，以及後續的管理與能否線上解決等諸多缺陷。
因此本企業資訊危機處理系統(Emergency Response of Enterprise Information System，EREIS)之設計即為解決上述問題，並增加管理彈性與擴充機制，進而 增加企業原始系統之可用性，此為本系統之主要目標。
3.1 系統概觀與架構
EREIS 為使用 Java Web Services、Perl、網頁程式與關連式資料庫所架構而 成。平時是由 Perl 所寫成的監控程式來監控系統狀況，至於監控的條件，是依 據預先訂定的 Policy。每一家企業均有其不同的 Policy，每台伺服器所著重監控 的部份也不盡相同。藉自由訂定 Policy 或使用 default 設定，偵測程式動態的偵 測系統現況，一旦發生問題就執行 JAVA 的遠端程序呼叫(Remote Procedure Call，RPC)，將目前狀況傳送給分析主機做後續處理，系統架構如圖 3-1 所示。
從概觀的角度看，EREIS 主要是對公司內部伺服器做監控，平常收集資訊，
觀看伺服器是否有正常運作。若出現問題，除了調高對此機器監控層級之外，也 將有問題的訊息記錄到資料庫，並將其萃取過的資訊，透過 Mail、B.B.Call 或是 手機 message 的方式傳送給相關人員。收到通知訊息人員，就知道目前是哪台機 器發生問題，並且再馬上利用手邊的裝置，如 PC、Notebook 或是手機，利用 JAX-RPC 的方式連到 Web Server。Web Server 之上可以撰寫 Script 或指令，之 後再將撰寫好的 Script 跨越防火牆傳送給中央控管主機。控管主機此時只做轉送 的工作，除了將 Script 轉送給發生問題的伺服器之外，亦將顯示出來的結果轉送
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
給使用者，讓其了解送進去執行之後的反應。
Agent Server 受測主機
受測主機
Web Server
Firewall
偵測程式 人員資料
歷史記錄
行動電話 B.B Call
PDA
筆記型電腦 Policy
圖 3-1 系統架構
3.1.1 系統偵測架構
圖 3-2 為系統偵測的架構。Client 端的主機平常做自我監控，監控分為兩個 Module，一個是 Information Collection Module，一個是 Policy Analyzing Module。
Information Collection Module 中的 Log Monitor 負責收集系統資訊或是監看 log file，系統資訊可能是 log 檔平常不會特別記錄的資訊，例如硬碟剩餘空間，
記憶體使用率等等。之後再將得到的資訊送給 Policy Analyzing Module 做分析比 對，比對的依據就是系統設定的 Policy。此不同的重要性做彈性的設定。當發生 異常狀況時，系統再將得到資訊做簡單的摘要，傳送給 Agent Server 儲存在資料 庫中。資料庫包含了異常狀況的歷史資料、偵測 Script、Policy 和人員連絡資料 等等。
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
透過 Policy 的訂定，可以自動升高層級通知第二線維護人員或是相關單位 主管，讓其知道公司內部伺服器發生問題等待解決。另外在擴充偵測的功能上，
可以透過 Agent 方式攜帶最新或是更新過的偵測程式，透過 JAX-RPC 的方式給 受測端的每一台主機，達到動態更新與擴充的功能，以增進系統分析的有效性與 可攜性。
3.1.2 系統通知與解決架構
圖 3-3 為系統通知與解決架構。傳送的訊息類型包括了 Email 的通知、
B.B.Call 上的訊息通知以及手機上的訊息傳送。一般的 Desktop PC 或是 Notebook 可經由 Email 得知問題狀況。另外現今技術不斷的演進，許多 mobile 裝置都可 跟網際網路做溝通，當 IT 人員不在機房辦公時，也能隨身攜帶某些裝置做即時 的接收與處理。我們針對的 mobile 裝置包括了手機的簡訊傳送，PDA 訊息傳送，
讓訊息的接收者能在第一時間內接收。當接收到異常問題訊息時，mobile 裝置 就能上網，透過遠端的 Web Container 連接，就能知道即時的狀況並遞送正在處
History, data, program, policy
Storing and retrieving System information and log file
Client
Agent Server
Client
Log Monitor
Log Monitor
Log Monitor
Data Collector and Analyzing
Data Summarization Information Collection Module
Policy Analyzing Module
圖 3-2 系統偵測架構圖
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
理的訊號給偵測系統。並且可以用撰寫 Script 的方式，讓 Web Container 做轉送 的動作到內部主機，藉此跨越防火牆的屏障，如此既可做到安全性，又可同時兼 顧到系統問題處理。
3.2 系統設計
EREIS 主要利用 Java Web Services 所建構而成，系統偵測使用 Perl 做分析 處理，前端搭配 JSP 做使用者登入的管理界面。以下就本系統各資料庫、前端 系統與偵測系統分敘如下：
3.2.1 資料庫
資料庫架構分成幾個部份，包含「Policy」、「人員資料」、「偵測程式」與「偵 測與歷史記錄」等等。Policy 儲存整個系統監控的政策，例如偵測條件、偵測週 期、反應門檻值等等。人員資料儲存相關負責人員的連絡方式。偵測程式資料庫 則是儲存實際偵測程式的樣本，以供 agent server 提取傳給眾多的受測端。偵測 與歷史記錄則是儲存所偵測到的問題，以供 Server 發送通知以及讓使用者觀察
History, data, Storing and retrieving Client
Firewall
Web Server Forward
Information retrieval and troubleshooting
圖 3-3 系統通知與解決架構
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
歷史記錄。訊息排程則是發送訊息時，須預先做排程發送管理的資料庫。
i. Policy
Policy 資料庫中儲存了整個系統監控的完整政策。因為每家公司自 己的政策均不一樣，機器也各不相同，所以我們提供彈性化的設計，供 使用者自定需求。主要須訂定各種發生問題的門檻值、偵測的頻率、多 久傳送給不同等級人員等等，在做完相關定義，偵測程式才可以據此加 以比對。
ii. 人員資料
主要儲存受測端主機的連絡人員資料，可能是 Email 的格式，也可 能是 B.B.Call 或手機的號碼。偵測程式會根據資料格式的不同做相對 應的處理。因為採層級通報制度，外加每台機器的負責人員不盡相同，
所以須訂定每台機器各人員層級(Level)資料。例如公司檔案分享伺服器 (File Server)和 ERP 負責的人應該就不一樣，File Server 的 Level 1 人員，
可能是監控的技工，Level 2 的人員才是網管人員。而 ERP 機器的 Level 1 可能是網管人員，Level 2 是 AP 維護人員。Level 3 就是各部門的 manager，但是大公司中，manager 可能還有劃分等級，這也是我們考 慮的因素。因為屬性各異，權責不同，所以才需要為不同的機器訂定不 同的連絡人資料。
iii. 偵測程式
當使用者自行撰寫偵測 Script 或是修改原先的 Script，儲存到此資 料庫中，便可以藉由 Server Agent 攜帶此程式碼傳遞給各 client 端。
Server Agent 會比對先前是否有此偵測程式。若沒有則新增，若之前已 存在則做更新的動作。如此就不用以人工的方式一台一台新增偵測程 式，只要在此資料庫中新增偵測程式，便可以達到自動更新的效果。
iv. 偵測與歷史記錄
當偵測程式偵測到有問題時，便將偵測的結果寫到此資料庫內，
以供偵測程式將結果用 Email 或是發送 message 的方式傳送出去。另外
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
若管理人員連上 Web Server，則可以做訊息確認與觀看歷史記錄的動 作。
本系統的資料庫 table 如表 3-1 所示：
表 3-1 資料庫 table
Tables 敘述
Employee Table
紀錄了公司內部人員聯絡方式的資料，及其主 管人員的識別碼
Administrator Table 紀錄人員與所管理的機器
Machine Table 紀錄機器的相關資訊及目前的狀態 MachineEvent Table 紀錄著機器所包含的事件 Policy
EventCondition Table 訂定公司內部機器出現異常狀況的 Policy MachineStatus Table 紀錄機器的狀況
Status Table 紀錄機器所有定義的狀態及其相關資訊 Message Table 主機發生警告訊息的紀錄
Receive Table 紀錄主機發生錯誤訊息
Program Table 儲存系統偵測程式，作為新增與更新之用
3.2.2 前端系統
在本系統的前端需要提供管理人員登入、管理與線上除錯的功能。所以我 們設計一個 Web 界面供管理人員使用。在登入後，就可以通知系統已經收到訊 息，此時前端系統會將資料庫中的計時器歸零重計，但計數器尚不歸零，直到系 統在固定時間內不再收到或偵測到同樣的問題事件，計數器才會歸零。所以當計 數器歸零，也代表問題真正有被解決，此為避免管理人員只通知系統，卻不解決 或無法解決問題的設計，圖 3-4 為系統登入流程圖。
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-4 系統登入流程圖
管理人員登入後，除了通知系統已收到訊息外，最重要的就是解決伺服器 的問題。圖 3-5 為線上 Troubleshooting 流程圖。因為主機發生的問題狀況相當多 種，有些仍須人力判斷。例如偵測到記憶體或 CPU 資源不足，原因是某位使用 者開啟特定程式所致，但是偵測系統並無法判斷該位使用者是否工作需要或是不 當使用，此時就須管理人員判斷或詢問。所以我們除了在 Web Page 上直接建立 幾個常用功能按鈕(如 restart 某幾個 Service 或是 reboot 之類)，這樣可以減少一 些重複性高的動作。此外提供線上除錯的方式，可以直接在網頁上編寫指令或是 script，Web Server 會將其送入防火牆內的偵測主機，透過偵測主機再轉送給內 部發生問題的機器上執行。而執行結果將會再由偵測主機轉送給外部 Web Server 上的使用者，讓其了解送入指令的情況為何。
系統登入
訊息紀錄查詢 線上除錯
拒絕服務
判斷使用者
選擇執行指令
訊息紀錄 尋找偵測訊息紀錄
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-5 Troubleshooting 流程圖
3.2.3 偵測系統
在偵測系統的 Server 端遠端偵測外，受測的 client 端也做自我偵測。在偵測 時，可以根據 Policy 做偵測與傳送依據，若新增或修改偵測程式，除了儲存在 本身的資料庫外，也會呼叫 deliver_agent，傳送新的偵測程式到欲偵測的機器，
達到動態更新的效果。
EREIS 平常就在背景監控受測端主機狀況，當主機發生異常的情況時，偵 錯系統就即時性的傳送訊息給 IT 人員，IT 人員可以透過一些行動裝置，利用遠 端連線的操作，希望在第一時間之內可以即時的對異常的主機進行修復，而達到 即時修復的成效，若不能修復還是可以在短時間回公司內去修復異常狀態的機
輸入 script
確認是否傳送
網頁伺服器 轉送給 偵測主機
偵測主機 轉送給 受測端 來源是否允許
回傳受測端 執行結果 拒絕轉送
線上除錯
偵測主機 轉送給 網頁伺服器
受測端 轉送給 偵測主機
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
器。利用這個偵錯系統，即時的通知訊息，再給予修復，可以有效的降低企業營 運的損失，而傳送訊息的成員，則參照系統內部所訂定的政策來決定通知的對象。
在發生比較輕微的異常情況下，僅先傳送給最底層的基層人員去作處理，即為 IT 人員。如果 IT 人員能在有限時間的情況下，了解狀況並回報偵錯系統異常狀 況且解決之，則偵錯系統就停止訊息的傳送；當異常狀況危急程度較高時，則依 狀況的程度大小來決定通知人員的層級高低。嚴重的事件，就同時傳送給高階的 經理及 IT 人員做處理。當 IT 人員在有限的時間的情況下不能對異常狀況作處 理，則系統就傳送給高階的主管去做處理。只要異常狀況在特定時間內，未能作 有效的掌控，則偵錯系統將把訊息提高處理層級以傳送給更高階的部門人員，讓 較高階的部門人員來做處理。
Detect System 的 Server 端平常除了主動監控受測端主機外，也要負責接收 受測端自我監測產生的危機訊息。當收到訊息通知，Server 端除了寫入資料庫，
也要將得到的訊息萃取後做排程傳送出去。在初始傳送時，就啟動計時器與計數 器，此兩者主要做為門檻標的。計時器從發送訊息時開始累積秒數，當到達 T1 時間時，系統會發送第二次訊息給同一位管理人員，當到達 T2時間，系統會再 次發送訊息通知。每發送一次，計數器會累加 1，當計數器的次數累計到 C1， Detect System 會提高通知人員層級到 Level 2。此時傳送訊息的對象就是 Level 2 的人員。當計數器累計到 C2，再提高層級到 Level 3。
T1 、T2、 C1和 C2等門檻值，皆在當初系統初始化時自由設定，之後也可 以因應需要而有所更動。因為各家公司的 Policy 不盡相同，不同類型的公司對 於主機發生危機時，應花多少時間提高層級反應也都不太一樣，所以我們採用讓 管理人員自訂適合公司環境的門檻值。例如證券金融業對於系統問題的要求水準 很高，但也有像小型工作室，公司成員不多，對於發生系統問題的反應時間當然 就不如證券金融或是大型企業。另外通知人員的資料也都不一樣，除了連絡方式 不同外，也可能因為企業規模不同，通知層級數量會有所差異。在此方面我們也 採取彈性設計，若層級較少，例如只有兩層，系統也會只通知到第二層級。
在訊息發送方面，系統會依據計時器來判斷是否要傳送給聯絡人，以及根 據計數器判斷是否要提升聯絡人等級，再依據訊息製成傳過來的資料，來製作訊
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
息排程內部資料，最後以此資料來判斷目前的要傳送那些訊息，而偵測主機會將 此訊息轉送給網頁伺服器，此時網頁伺服器會先向偵測主機要求聯絡人資料，再 根據訊息排程內容來判斷要以何種方式〈例如：PDA、手機、E-mail〉傳送給聯 絡人，圖 3-6 為訊息製作流程，圖 3-7 為發送訊息流程圖。
3.2.4 代理人角色定義
在企業資訊危機處理系統的代理人主要是 deliver_agent。其功能在攜帶新的 偵測程式給其他受測端。因為要攜帶程式碼到不同的平台上，所以我們需要可以 提供跨平台的語言作為設計代理人的基礎。Java 提出了虛擬機器(Virtual Machine) 的概念，讓不同平台之間的溝通得以實現。所以我們採用 Java 來設計
deliver_agent。
在傳統的架構中，雖然也有偵測程式負責監控，但是一旦有新增或更新時，
往往需要每台機器手動更新。若受測端主機只有幾台還可以操作，但是像大企業 或是跨國公司有著很多的機器，人工操作就很曠日費時。所以我們可以藉由代理 人的方式，當管理人員新增偵測程式或是更新修正之前的程式，在儲存到資料庫 後，除了 Server 在做遠端偵測時更新外，透過代理人就可以幫我們攜帶程式到 遠端機器。此時若遠端機器本身無此偵測程式，則代理人會將新程式安插到適當 的地方。若原本已有偵測程式，則代理人會做取代的動作。
圖 3-6 訊息製作流程圖 監控主機
訊息製成 政策
計數器規格 計時器規格 訊息內容 訊息製作
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-7 發送訊息流程圖
3.3 系統實作
本系統主要以 Linux 為開發平台，以 Tomcat 為網頁伺服器，使用 Perl 做為 監控系統的分析工具，前端則使用 Windows 平台，配合 JSP 做為管理人員之 Troubleshooting 與系統管理之界面。依前章節所述之系統架構，實作出 EREIS 環境。系統平台與工具如表 3-2 所示。
在監控受測端的偵測程式使用 Perl 的主要原因，是其具有正規表示式 (Regular Expression)的特性，而且也具有直譯性，無須經過 Compile 即可執行。
在系統記錄檔中，充滿著各種程式所產生的記錄。小的幾 Kbytes，大者可到十 幾 Giga Bytes。若利用傳統語言找到特定字串，往往事倍功半。而 Perl 具有 Regular Expression 的特性，對於字串的比對、擷取、搜尋等各方面都具有相當強悍的功
訊息製作
判斷傳送方式 問題訊息發送
E-MAIL 手機
訊息排程
偵測主機 轉送給 網頁伺服器
計時器
聯絡人升級
訊息發送 計數器
訊息排程
聯絡人資料
執行動作
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
能。而且 Perl 可攜性也很高，除了在 UNIX 或 Linux 平台外，在 Windows 平台 也有支援。在 JAVA 中，也內建呼叫 Perl 的函示，讓使用者可以在程式中呼叫 Perl。
表 3-2 系統開發平台與工具
系統開發平台 Windows 2000 Professional Linux Redhat 9.0
系統開發工具
MySQL database Forte for Java CE
Java web service develop pack Perl
我們撰寫了一個偵測範例作為實驗之用，我們希望可以依據 Policy，當 偵測到 memory 使用率超過某一門檻值時，程式就會記錄並且傳送給 Detect System 主機，讓其寫進資料庫，並通知相關管理人員，實驗環境如圖 3-8 所示。
在 DMZ(Demilitarized zone，非軍事保護區)放置一台 Linux 平台的機器，做 為模擬日常提供服務的伺服器。而偵測系統的 Server 與 Web Server 原本就建置 於 DMZ 之內，但只有 Web Server 藉由防火牆做 NAPT(Network Address Port Translation)，讓外部的電腦可直接連線到 Web Server。其他兩台電腦則使用防火 牆過濾規則，限制來源進入以增加安全性。
模擬實驗中，PC 中的偵測程式運作時，即會收集系統運作的各項數據，並 連線至 Detect Server 查詢其設定之門檻值，若未達條件則不做任何通知，一旦偵 測到符合該台機器的條件，即做事件的分析與摘要處理。以偵測記憶體為例，萃 取之後的資訊如圖 3-9 所示，並將其傳送至 Detect Server。
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-9 記憶體偵測圖
當 Detect Server 收到 Client 端傳送過來的訊息，其本身在參考 Policy 之後將 做成摘要的警告訊息製作成 mail 或簡訊傳送出去。而收到訊息的管理人員藉由 電腦或 mobile 裝置登入 Web Server 觀看現在現時狀況，並且可利用線上 Troubleshooting 方式送入 script 以解決問題。
圖 3-10 為登入 Web Server 之後所得知的目前狀況，若收到訊息尚未做確認 圖 3-8 實驗環境圖
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
動作，則系統將出現警告字樣，若做完確認動作則會出現維修中的字樣。
圖 3-11 為進入問題機器時，偵測程式摘要出來後的警告訊息。以監控 Memory 而言，將列出使用 Memory 的前五個 Process，供管理人員參考，讓其判 斷是否正常使用或應限制其使用程度，甚至是 kill 掉該 process。
圖 3-10 系統目前狀況圖
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-11 警告訊息圖
圖 3-12 線上 Troubleshooting
企業資訊危機處理系統
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿＿＿＿
圖 3-12 為線上 Troubleshooting 畫面，管理人員可在欄位中輸入指令或是一 串的 Script，Detect Server 會將指令轉送給內部發生問題的主機執行，並將執行 指令後的畫面再轉送給 Web 前端，讓其有如直接登入問題主機一樣。執行 Script 之後若能解決問題，則系統顯示成功解決的訊息，並將系統狀況恢復為一般狀 態，解除升高通知層級的 Policy。
在此架構下，依照以上範例，我們可以擴充偵測程式，針對我們需要的部份 做偵測，撰寫好適當的偵測程式，儲存到偵測程式資料庫。此時中央控管主機將 扮演 agent server 的角色，根據管理人員所指定派送的主機發送 deliver_agent 做 比對傳送的動作，deliver_agent 就會攜帶偵測程式到受測端進行安裝。不只記憶 體，其他例如 CPU、磁碟使用率、疑似入侵偵測等等，都可使用此模式應用。
3.4 系統限制
本架構專門針對系統出現問題時，可透過網路即時傳送通知，並且可透過 行動裝置解決問題。但若符合下列情況則使用上會有無法立即解決的缺點。
i. 受測主機 Crash 或是網路故障，除了受測端無法傳送通知外，中央控管 主機也沒有辦法作 Double check 的檢查，此時仍須管理人員到機器前 面操作。
ii. 中央控管主機若 Crash 或是資料庫損毀，除了受測主機沒有 Policy 可供 比對之外，亦無法將問題通知傳送出去，此時可能需要備援機制。
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
第四章 積極式網路防禦架構
近年來資訊安全問題層出不窮，網路攻擊的事件持續發生。除了一般入侵 行為之外，尚有使用大量封包阻絕系統服務的惡意攻擊。少量的攻擊與入侵，都 可在監控系統記錄檔之後利用防火牆予以阻擋，但是最難以防禦的則屬於 DoS 與 DDoS 等送出大量封包的攻擊行為，此種攻擊相當難以防禦。目前阻擋此類 攻擊仍使用防火牆阻擋，或限制單位時間內只接收一定數量的 SYN 封包，但其 Loading 與頻寬的消耗仍在受害者這一方。若能設計一完整的網路防禦架構解決 網路攻擊的危機，並且相容於現有的網路設備與環境即能達成，讓企業不用再一 直擴充昂貴的設備與投入更多的人力來解決網路攻擊問題，進而提高企業服務的 可用性，即是本研究的主要目標。
4.1 架構介紹
本架構利用已知的封包偵測技術、入侵偵測系統、Java Web Services、Shell Script 與關連式資料庫來建構。除了以上所提技術外，尚須 ISP 與第三方提供服 務登錄的 Registry Server 共同配合，方能建構出完整的積極式網路防禦架構 (Active Network Defense Architecture，ANDA)。圖 4-1 為 ANDA 架構圖。本研究 架構能在不更改原來的網路環境與設備的情況下，阻止入侵與攻擊者持續對企業 所造成的損害。
在圖 4-1 中，共有入侵偵測系統、中央控管伺服器、企業危機處理系統、服 務登錄伺服器、ISP 服務提供者等五個系統元件，茲分別說明如下：
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
PC PC
PC
DMZ
Registry Server PC
Attacks ISP
Attacks
Attacks Attacks
Attacks
PDA NB Smart Phone
Mobile
Central Server N-IDS
Mail Server
Web Server Agent
Server
EREIS
圖 4-1 ANDA 架構圖
4.1.1 入侵偵測系統
入侵偵測系統建置於防火牆之後，負責監控入侵與攻擊行為。在本研究中 主要是部署網路型的入侵偵測系統(N-IDS)作為偵測感應器。當 N-IDS 偵測到入 侵或攻擊行為發生時，便會將偵測到的攻擊訊息傳送給 Central Server 來進行後 續處理。根據 Base[19]的說法，IDS 可以部署如圖 4-2 的四個地方：
i. Location 1：在外部防火牆之後，但在 DMZ(非交戰保護區)內 ii. Location 2：在外部防火牆的外面
iii. Location 3：在主要骨幹網路(backbone)上 iv. Location 4：在某關鍵子網路上
我們將其部署在 Location 1 的位置上，其優點包括：
i. 可以看到來自外部世界，並且穿透網路周邊防禦的攻擊行為
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
ii. 可以突顯出防火牆設定的 Policy 或效能的問題 iii. 能夠看到在 DMZ 中各式 Server 所受到的攻擊
iv. 違反防火牆 Policy 的封包已經經過防火牆過濾，IDS 的 loading 較輕 v. 即使進來的攻擊行為沒有被偵測出來，IDS 有時仍然可以辨識出受害主
機所產生的異常網路流量
vi. 一般企業環境大部分均設置於 DMZ 內，設置於此符合實際環境
圖 4-2 IDS 放置圖
4.1.2 中央控管伺服器(Central Server)
Central Server 為本架構之主要核心模組，其主要負責：
i. 接收由 IDS 系統傳送而來的入侵或攻擊訊息
ii. 解析攻擊來源的 IP 相關訊息。由於目前利用 DoS 或 DDoS 攻擊大部分 均會偽造自己的身份，所以如何防制 IP 偽裝攻擊與攻擊者的來源回溯
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
追蹤(IP Traceback)機制也是一項重要的議題。但 IP Traceback 課題廣 泛，故其不在本研究之內，我們將只在第四小節做討論。
iii. 經 Traceback 所得知的 Router 資訊，向 Registry Server 查詢所屬之 ISP 為何，並取得與該 ISP 伺服器聯繫之 Web Service 相關資訊。
iv. 利用由 Registry Server 所取得之 URL 與相關資訊，通知該 ISP 對攻擊 者 IP 位進行封鎖的動作。
v. 內含 Policy，可依據設定判斷是否需要 ISP 聯防亦或是由企業本身防火 牆阻擋即可。
vi. 針對 IDS 偵測的 rule 做自動化更新排程。
當 Central Server 接收到 IDS 偵測到的入侵或攻擊訊息時，首先比對 Policy，
判斷是否需要通知 ISP 與其共同聯防，亦或是只要在防火牆阻擋即可。可依據封 包數多寡與是否偽造來源 IP 進行判斷，封包數量少與沒有偽造來源的 IP，通常 是入侵行為，欲進行竊取資料或是破壞行動，其以防火牆阻擋 loading 並不重。
封包數量多或來源 IP 偽造，通常是 DoS 或 DDoS 的攻擊手法，此時即可透過與 ISP 聯防，將真正發送大量封包的攻擊方由 ISP 予以阻絕，無須佔用企業本身的 頻寬與防火牆 loading。
另外為了因應攻擊手法日新月異，如何讓 IDS 偵測 rule 保持最新狀態也是 考量之一。例如以 snort 此種 N-IDS 而言，其採用特徵比對的 Signature-based matching 方式，凡符合負面表列的封包特徵，均判斷為攻擊行為，故其正確率極 高。而 snort 官方網站，本身每日有兩次的 rule 更新。其他的 IDS 產品，原廠也 提供更新服務。Central Server 可針對 IDS 做 Proxy，預先抓取更新過的 rule，之 後再統一排程派送給 IDS。
4.1.3 企業資訊危機處理系統
積極式網路防禦架構可整合至第三章所提之 EREIS 系統之內。當 IDS 系統
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
偵測出有異常的攻擊事件發生時，會將訊息傳遞給 Central Server，Central Server 除了將攻擊訊息傳給 EREIS 之外，並根據 EREIS 中 Agent Server 所訂定的 Policy 做適當的防禦。而 Agent Server 會利用 JAX-RPC 的方式，在第一時間內將訊息 傳送給 MIS 管理人員，並且可以透過 Policy 的制訂，依事件危急的程度來轉送 不同管理階層。而管理人員可以利用手邊的 Mobile 裝置得知相關的訊息，並且 可透過 mobile 裝置登入 Web Server，進行線上緊急處理。
4.1.4 服務登錄伺服器
Registry Server 是建構於第三方具有公信力的一個組織，而 Registry Server 在 Web Service 的架構中，主要的功能類似於提供服務查詢(Yellow Page)的機 制。與我們締結同盟的 ISP 將與其聯絡的公司資料(如公司名稱、聯絡方式、RPC 呼叫的 Method)以標準格式發佈於 Registry Server，以提供本架構之盟友能彈性 的取得與各家 ISP 聯繫的方式。而 Registry Server 之功用為當 Central Server 藉由 Traceback 查詢到惡意攻擊位址所經的路由器資訊，經查詢比對得知所屬之 ISP，
再向 Registry Server 查詢該 ISP 所提供之 WSDL 連結，以便取得所經 Router 所 屬 ISP 的相關連接訊息。
因為 Registry Server 提供的服務就類似電話簿上商家的電話，讓使用者查詢 之後再打電話給商家，也類似入口網站提供網站的連結一般，故目前提供 Registry Server 也都是較大型的企業所推出的服務，如目前有 IBM、Microsoft、
HP 等公司提供服務。
4.1.5 ISP 服務提供者
本架構經由與 ISP 網路服務提供者的合作，以確實的將攻擊者的惡意封包阻 絕於企業網路之外；若攻擊者所屬之 ISP 網路服務提供者未與企業同盟的話，那 便將網路攻擊的阻斷點延後至距離企業網路次近且與企業同盟之 ISP 所擁有之 網路節點。而 ISP 網路服務提供者負責接收 Central Server 所發出的 block
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
request，依據攻擊描述的事項，主動且即時的進行封鎖攻擊方 IP 位址的動作。
如圖 4-3 所示，攻擊者傳送的封包會經過許多 router 轉送，最後傳到目標受 害主機。當發生攻擊時，最佳阻斷點為 Router 1，但其所屬之 ISP 可能沒有加入 共同防禦之運作，此時將阻斷點延後，直到有參與共同防禦 ISP 之網路節點內，
其可能是 Router 2 或 Router 3，甚至是 Router 5 為止。
Target host Attack host
Router 2
Router 1
Router 5 Router 3
Router 4
Router 6
Router 7
圖 4-3 封包經過節點示意圖
4.2 架構運作方式
本系統架構之運作方式，如圖 4-4 所示，其描述了 N-IDS、Central Server、
Registry Server 與 ISP 服務提供者間相互運作之步驟如下：
i. 送出攻擊相關資訊：
IDS 系統偵測到入侵或攻擊行為，除了將偵測訊息傳送給 Central Server 進行處理之外，也將攻擊資訊寫進資料庫，做為事後分析與比對之用。
ii. Traceback 得知路由資訊：
Central Server 依據 N-IDS 傳送之訊息，來進行 IP Traceback 的動作，以 找出攻擊者至企業間所有經過之網路節點。
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
iii. 通知 EREIS：
得知攻擊者之路由節點，Central Server 便將此攻擊訊息再傳送予 EREIS 中的 Agent Server，Agent Server 除了記錄該事件之外，並依據 Policy 設定，判斷是否需要 ISP 聯防，或是只要防火牆阻隔即可，Central Server 將依照 Agent Server 傳回之訊息做後續動作。另外 Agent Server 將此紀 錄摘要後製成訊息，傳送通知與管理人員，並依照 Policy 來提高通知 層級。
iv. 查詢 ISP 聯絡方式：
Central Server 以最靠近攻擊者的網路節點位址，向 Registry Server 查詢 攻擊者 IP 位址所屬 ISP 的聯絡方式。(如最近之網路節點所屬之 ISP 業 者並無參與本架構，便以距離攻擊者次近之網路節點來查詢，以此類 推)。
v. 發出 block request：
Central Server 藉由分析自 Registry Server 所取得之相關資訊與 URL 位 址，利用 JAX-RPC 的方式，通知該 ISP 封鎖攻擊主機連往企業網路的 路由。
圖 4-4 架構運作示意圖
積極式網路防禦架構
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_＿＿
4.3 架構測試
本小節就本架構做模擬環境實驗測試，驗證其是否可正常運作，實驗環境 如圖 4-5 所示。
我們以簡單的環境來模擬實際運作，驗證架構的可行性。在測試環境中將 機器分為兩個區段，其中 172.16.10.0/24 放置一台 PC 與 Central Server，其中 PC 模擬為受害主機。IDS 方面，我們以 Snort 2.1.0 做為入侵偵測依據，並將其裝在 Central Server 上監聽同網段之封包。192.168.0.0/24 網段則放置 Registry Server 與一台 PC 扮演攻擊者(Attack)，兩個網段經由一台 Linux 主機模擬成 Router，將 其網段做連接，讓彼此網域可以互通。其中 Registry Server 亦扮演 ISP 所提供 Web Service 之機器，接收 Central Server 的 block request 後，再控制 Cisco 2500 路由器做阻擋動作。
Firewall
Cisco 2500
Snort Victim
172.16.10.0/24
192.168.0.0/24 Registry Server Attack Router
10.0.1.0/24
10.0.0.0/24
圖 4-5 防禦架構測試環境圖
