以封包路由為基礎之分散式阻斷攻擊偽造封包過濾
86
0
0
全文
(2) 以封包路由為基礎之分散式阻斷攻擊偽造封包過濾. 研 究 生：陳偉羣. 76 頁. 指導教授：魏大雅 博士. 國立屏東商業技術學院資訊管理系(所). 摘. 要. 網際網路的迅速發展，使得整個社會產生莫大的變動，靠著網路力 量的無遠弗屆，拉近了世界的每個角落，也帶來了全球化的競爭環境。 但是在這樣的同時，網路上的威脅也相對提高了。尤其是近年來的 DDoS 攻擊威脅，使得網際網路上的各種服務產生莫大的危機，而 DDoS 之所 以那麼防不勝防，主要因為其攻擊的來源難以追蹤，其利用假冒的封包 混淆受害端的主機，使其無法找出真正的攻擊端及隱藏在背後的操縱 者，並使用各種合法或非法的流量癱瘓受害端的主機。所以，在這裡我 們提出一封包檢測過濾系統，藉此判斷流進主機封包的真實性，將一些 可疑或不合法的封包給予過濾，以抵抗攻擊者的惡意攻擊。. 關鍵字 : 網路安全、分散式阻斷服務攻擊、偽造封包過濾、入侵偵測系 統. I.
(3) Routing-Based Distributed Denial-of-Service Spoofed Packets Filtering. Student : Wei-qun Chen. Advisor : Dr. Dahyea Wei. Dept. of Information Management, National Pingtung Institute of Commerce. Abstract With the popularity of Internet, the variation of the society is amazing. Internet facilitates the information transmission and globalization. However, some risks emerge immediately. The DDoS attack causes the services of internet in danger. The reason why DDoS hard to deal with is because the attacker source is difficult to track. It uses the spoofed packets to confuse the victim making the real attack source hard to find, and the attacker behind the scenes can using the legitimate or illegitimate traffic to crash the victim’s host. In this paper, we propose a packet filter system to determine the truthfulness of the incoming packets to the host in order to defense the DDoS attack.. Keyword：Network Security、Distributed Denial of Service、Spoofed Packet Filtering、Intruder Detection System. II.
(4) 誌. 謝. 時光冉冉，兩年時光匆匆而逝，猶記剛進校園的青澀模樣，掩不住 的稚氣臉旁，在這兩年中，都一一的蛻變了。兩年的點滴，首先要感謝 的是指導教授魏大雅博士。全賴老師的細心指導，使得本篇論文得以順 利的完成。老師的句句勵言，一直是催促我們前進的原動力，兩年所學 到的知識的挖掘，更是讓我從老師身上得到的最豐富的寶藏。另外要感 謝的是兩年來一起一路走過的團隊成員峻富以及成祥，他們在生活中的 相互照顧，更在我不懂或迷惑時適時的幫忙以及提供意見，使我在學業 上受益良多。 更感謝研究室的成員們，陪伴著我兩年屏東的研究生活，在我生活 上及研究上更不吝的給予幫助，心中只有無限感激，在此獻上我最高的 敬意。 最後要感謝的是我的父母以及家人，沒有他們對我的關心以及在背 後提供我無虞的生活，讓我能無後顧之憂的專心在學業上，我也不能一 路的順利升學。也感謝我的女朋友，在我遇到瓶頸遲滯不前時給我加油 打氣，陪伴我渡過一個又一個的難關。在這裡跟你們說一聲：您們辛苦 了，謝謝。 讀屏商院的兩年，所學到的真的是很多，感謝生命中的每一個過客， 使我成長茁壯，這些難忘的回憶，會一直珍藏在我心裡。. 謹將此論文獻給我親愛的家人以及所有關心我、幫助我的人。. -III-.
(5) 目 錄 摘. 要 ............................................................................................................... I. ABSTRACT ....................................................................................................II 誌. 謝 ............................................................................................................ III. 目. 錄 .............................................................................................................IV. 圖索引 .............................................................................................................VI 表索引 ......................................................................................................... VIII 1. 緒 論 .......................................................................................................... 1 1.1. 研究背景 ............................................................................................. 1. 1.2. 研究動機與目的 ................................................................................. 2. 1.3. 論文架構 ............................................................................................. 4. 2. 相關研究 .................................................................................................... 5 2.1. DDOS攻擊簡介................................................................................... 5. 2.1.1. DDoS 攻擊類型 .......................................................................... 7. 2.1.2. DDoS攻擊手法 ............................................................................ 8. 2.1.3. DDoS 攻擊工具 ........................................................................ 12. 2.2. DDOS攻擊防制................................................................................. 16. 2.2.1. DDoS攻擊追溯 .......................................................................... 16. 2.2.2. DDoS攻擊防禦 .......................................................................... 20. 3. 研究方法與內容 ...................................................................................... 24 3.1. 研究方法 ........................................................................................... 24. 3.1.1. 來源端與接收端間Hop Count 檢測 ....................................... 25. 3.1.2. 封包Hop Count 檢測 ............................................................... 28. -IV-.
(6) 3.1.3. 歷史接觸記錄 ............................................................................ 30. 3.2. 可行性分析 ....................................................................................... 30. 3.3. 系統架構 ........................................................................................... 31. 3.3.1. 各模組功能說明 :..................................................................... 33. 3.3.2. 封包檢測流程演算法 ................................................................ 36. 4. 系統實現 .................................................................................................. 40 4.1. NETFILTER ......................................................................................... 40. 4.1.1 4.2. IPTables ..................................................................................... 43. LOADABLE KERNEL MODULE .......................................................... 44. 4.2.1. 登錄Hook 點............................................................................. 45. 4.2.2. 利用Hook 函式進行封包過濾................................................. 47. 4.2.3. Kernel space and User space ................................................... 49. 4.2.4. 與Kernel 進行溝通 .................................................................. 50. 4.2.5. 記憶體使用 ................................................................................ 53. 5. 實驗結果與評估 ...................................................................................... 56 5.1. HOP COUNT 檢測.............................................................................. 56. 5.2. 誤判率分析 ....................................................................................... 57. 5.3. 識別率分析 ....................................................................................... 59. 5.4. 流量過濾 ........................................................................................... 64. 5.5. 實驗結果分析 ................................................................................... 68. 6. 結論與未來工作 ...................................................................................... 71 參考文獻 ......................................................................................................... 73 作者簡介 ......................................................................................................... 77. -V-.
(7) 圖索引 圖 1-1 1995 年到 2004 年漏洞數目....................................................... 2 圖 1-2 1995 年到 2004 年安全回報數目............................................... 2 圖 1-3 DOLLAR AMOUNT OF LOSSES BY TYPE ........................................ 3 圖 2-1 DDOS 攻擊示意圖 ....................................................................... 6 圖 2-2 利用 LINKING TESTING 進行追溯............................................. 17 圖 2-3 利用 LOGGING 進行追溯 ......................................................... 18 圖 2-4. ITRACE 追溯............................................................................... 19. 圖 2-5 利用 PACKET MARKING 進行追溯 ........................................... 20 圖 3-1 IP 封包標頭 ............................................................................... 24 圖 3-2 TCP/IP 封包溝通 ...................................................................... 26 圖 3-3 HOP COUNT FILTER SYSTEM 網路架構圖................................ 32 圖 3-4 HOP COUNT FILTER SYSTEM 模組架構圖................................ 32 圖 3-5 封包檢測流程 ............................................................................ 37 圖 3-6 封包過濾決策圖 ........................................................................ 39 圖 4-1 NETFILTER HOOK 點所在位置.................................................. 42 圖 4-2. HOOK. 點設定與登錄 ................................................................. 46. 圖 4-3 LINUX KERNEL 2.4 封包處理流程............................................ 47 圖 4-4 HOOK FUNCTION 及封包欄位擷取 .......................................... 49 圖 4-5. MODULE. 插入及 MYSQL 資料傳送 ........................................... 53. 圖 4-6 MEMORY USAGE ......................................................................... 54 圖 4-7 過濾模組比對畫面(A) ............................................................... 54 圖 4-8 過濾模組比對畫面(B)................................................................ 55 圖 5-1 資料庫內樣本 HOP COUNT 資料分配圖 ................................. 57. -VI-.
(8) 圖 5-2 流入封包 HOP COUNT 分配圖 .................................................. 58 圖 5-3 不同容許範圍之系統誤判率 .................................................... 58 圖 5-4 不同封包數時之系統誤判率 .................................................... 59 圖 5-5 SYNATTACK 攻擊封包 HOP COUNT 分配圖 ............................. 60 圖 5-6 TFN2K 攻擊封包 HOP COUNT 分配圖.................................... 61 圖 5-7 SYNATTACK 攻擊下不同容許誤差範圍誤判次數分配........... 61 圖 5-8 TFN2K 攻擊下不同容許誤差範圍誤判次數分配 .................. 62 圖 5-9 SYNATTACK 攻擊下不同封包數時之系統識別率................... 63 圖 5-10 TFN2K 攻擊下不同封包數時之系統識別率 ....................... 63 圖 5-11 一般狀態下網路流量圖........................................................... 64 圖 5-12 一般狀態下 TCP 連線狀態圖 ................................................ 65 圖 5-13 ETHEREAL 封包監控 ............................................................... 66 圖 5-14 TCP SYN FLOOD 攻擊時網路流量圖.................................... 66 圖 5-15 TCP SYN FLOOD 攻擊時 TCP 連線狀態圖 ......................... 66 圖 5-16 封包過濾模組載入後網路流量圖 .......................................... 67 圖 5-17 封包過濾模組載入後 TCP 連線狀態圖................................ 67 圖 5-18 封包類型與系統判斷 CONFUSION MATRIX ........................... 69. -VII-.
(9) 表索引 表 2-1 TRINOO 通訊埠號...................................................................... 13 表 2-2 STACHELDRAHT 通訊埠號 ........................................................ 15 表 2-3 DDOS 攻擊軟體可實現之攻擊方法 ........................................ 15 表 3-1 各作業系統之TTL 初始值 ....................................................... 28 表 3-2 HOP COUNT 轉換演算法........................................................... 29 表 3-3 AHCT 欄位表 ........................................................................... 35 表 4-1 IPV4 所定義之HOOK點及其支援之IPTABLE模組................. 41 表 4-2 HOOK 點結構 ............................................................................ 41 表 4-3 處理函式優先權等級 ................................................................ 43 表 4-4 內建之IPTABLES 及其功能 ...................................................... 44 表 4-5 HOOK 函式原型 ........................................................................ 48 表 5-1 各容許誤差範圍之封包誤判率 ................................................ 59 表 5-2 各容許誤差範圍封包判斷率 .................................................... 64 表 5-3 不同容許範圍之F-MEASURE ..................................................... 70. -VIII-.
(10) 1. 緒 論. 1.1 研究背景 網際網路的迅速發展，使得整個社會產生莫大的變動，靠著網路力 量的無遠弗屆，拉近了世界的每個角落，也帶來了全球化的競爭環境。 另一方面，近幾年電子商務快速竄起，嚴然成為明日之星，其大量簡化 了商業的交易流程，加速了產業供需鍊的運行，使得現今的企業，不僅 要跟競爭對手相互競爭，也要跟時間賽跑。但是由於目前網路上存在著 各種大大小小的漏洞。根據CERT的統計結果顯示[13]，2004 年的漏洞 數目以經上升達 3,780，網路安全回報事件也逐年增加，這些結果充份 顯示網際網路的不安全性。而潛在的危機也大大的提升了主機在網路上 的威脅性，小則個人主機被攻擊入侵，大則公司企業機密資料外泄，這 對金融業者而言，無疑是一個非常大的惡耗。一旦任何有心人士想要進 行不法的攻擊行為，這些在網路上存在漏洞的主機將是攻擊行動的幫 兇。所以，建構一完整的安全防護網，杜絕網路攻擊的事件，以經是刻 不容緩，急待解決的事情了。. -1-.
(11) 圖 1-1 1995 年到 2004 年漏洞數目 (資料來源 CERT/CC). 圖 1-2 1995 年到 2004 年安全回報數目 (資料來源 CERT/CC) 1.2 研究動機與目的 而近年來由於阻斷服務攻擊 (DoS/DDoS) 的出現，更是使得網際網 路上的各種服務產生莫大的危機，根據 2004 CSI/FBI的電腦罪案及安全 調查的研究結果顯示[7]，DDoS 攻擊所產生的金額損失達兩千多萬美 元，在所有的類型中排名第二，再再都顯示DDoS攻擊之嚴重性。. -2-.
(12) 圖 1-3 Dollar Amount of Losses by Type (資料來源 CSI/FBI 2004 Computer Crime and Security Survey). DoS/DDoS是目前資訊安全領域中最難防範的攻擊手法之一，全球的 駭客們對於此類的攻擊手法正醉心的研究著，而網路上資訊安全概念薄 弱的使用者則可能將成為他們的幫凶。近幾年DoS/DDoS的攻擊目標， 已經由一般的公司Web站台慢慢轉變為瞄準網際網路上的基礎設施，如 DNS服務等等，其中幾個有名的例子為在 2001 年時美國微軟公司 (Microsoft Corp.)所管理的相關網路系統，遭受網路駭客的DDoS攻擊， 加上管理者的不當處置，使得全球各個地區的用戶，在接近 24 小時內， 沒有辦法連接上該公司的網站[23]。另外在 2002 年，全球互聯網系統核 心也遭到DDoS攻擊[25]，十三座root網域名稱伺服器遭長達一小時的攻 擊。一旦DNS服務失效，其後果將是全球網路癱瘓之危險。更由於網路 的迅速發展，各種不同的DDoS工具不斷的被開發撰寫出來。這些程式. -3-.
(13) 如同瘟疫一樣的在網路上散播開來，使得我們的防禦力顯的更加的薄 弱。 而DoS/DDoS攻擊之所以那麼難以防範，主要在於我們很難去得知攻 擊者的來源，由於TCP/IP協定的缺陷，使得DoS/DDoS的攻擊封包內的 來源位址可以被攻擊者隨意的假造[20][35]，也使得我們往往無法判別封 包的真假性及真實攻擊封包的來源位址，所以我們不得不找出一套應對 的安全解決模式來應付黑暗中的攻擊。 在本研究中，我們實作出一偽造封包檢測的系統，利用這套系統來 過濾以假冒來源端封包進行攻擊的攻擊行為。試著對 DDoS 網路攻擊事 件，提供一個解決方案。. 1.3 論文架構 本論文共分為六章，第一章為概述，主要為描述目前網際網路之潛 在危機，並說明研究背景及動機。第二章為相關研究，主要將 DDoS 攻 擊方式與手法作一介紹，並整理出目前現有之防制方法。第三章為研究 方法，說明我們如何檢測判斷偽造封包，並提出我們所利用之原理及本 文所建置之系統架構。第四章說明我們利用何種方法實現本系統之封包 檢測過濾。第五章為應用本系統經 DDoS 攻擊後之實驗結果及探討。最 後第六章則為結論，並提出改進方向與目標。. -4-.
(14) 2. 相關研究. 2.1 DDoS 攻擊簡介 DDoS 全名為 Distributed Denial-of-Service (分散式阻斷服務攻擊)， 其原理最主要是利用多台主機大量的流量(traffic)、要求(request)壅塞或 癱瘓受害端主機，由於網路的頻寬及電腦系統的資源有限，在同一時間 如果有大量的流量或要求流入，將使得主機無法進行處理及負荷，進而 造成系統的崩潰。 通常，在發動攻擊前，攻擊者會入侵網路上有漏洞或安全防護不完 全的主機，利用許多已知系統的安全漏洞，入侵系統取得管理者權限及 控制權，往後攻擊發生時，該台主機在發動攻擊時將能聽從攻擊者的發 號施令進行攻擊與監看攻擊成果。 接著，攻擊者會再次在網路各地找尋更多有安全漏洞的網站，目標 包括各式的 Unix、Windows 等系統，然後再植入一些特定的網路服務 程式 (Daemon)，潛藏在該系統中，這些服務程式，可能會在主機中悄 悄的開啟一個 Port，伺機等候接收前述攻擊者所控制的 Host，發動網路 攻擊的命令。 在攻擊方面，攻擊者首先會從自己的電腦連線到第一階段所控制入 侵的數台電腦，這些所控制的主機我們稱為 master 或 handler。這些 master. -5-.
(15) 及 handler 主要是用來控制其它大量的 zombies 及 agents 電腦。由於被 入侵的電腦將會被入侵者植入特定的 agent 或 daemon 後門程式，其會開 一個 port 聆聽由 master 或 handler 所傳送過來的命令。如此一來，攻擊 者只需在 master 及 handler 下達指令，便可控制龐大的 agents 電腦群， 如圖 2-1 所示。. 圖 2-1 DDoS 攻擊示意圖. 在攻擊時，攻擊者會利用遠端搖控的模式控制 master 或 handler 並 下達指令給被植入後門程式的 zombies 及 agents 發動攻擊，自己則隱身 幕後藉此躲過受害端主機的追蹤。由於攻擊時是由 zombies 及 agents 進 行攻擊，而且要命的是，這些特定的攻擊程式，往往都被設計成具有將 封包放大的特異功能，且通常也同時隱藏封包的真實來源，而偽裝成其 他來源，所以在攻擊中或事後追查兇手時顯得更加困難，往往只能查到 直接對受害端主機發動攻擊的 zombies 及 agents。. -6-.
(16) 2.1.1 DDoS 攻擊類型 DDoS 攻擊所使用的方法主要可分為下列幾種 : 1.. 頻寬消耗 (Bandwidth Consumption) 這個方法主要就是藉著利用多台的主機傳送出大量的封包淹沒受害 端主機的網路，如果受害端的網路段所能承受的網路傳輸量比起所 接收的封包量要來的小的話，則網路就會呈現癱瘓的現象，外來的 正常封包也無法順利的送入主機內。這個方法最消極的抵抗方法就 是增加自己網路的頻寬。. 2. 系統資源消耗 (System Resource Starvation) 這一類的攻擊主要為送出大量的要求(request)，使得受害端主機必須 忙於處理這些要求，造成系統的資源耗盡，由於每台主機都有一定 的資源限制，透過大量的要求，將使得主機系統的疲於應付這些要 求，最後導致崩潰。一般常見的此類攻擊為 SYN Flood attack。利用 一些負載平衡機制來取代單一服務系統，將所要處理的要求平分給 多台主機分攤將可以減低此類攻擊之成功率。 3. 漏洞攻擊(Exceptional Condition Exploitation) 漏洞攻擊主要利用 TCP/IP 協定上的漏洞達到 DDoS 攻擊。攻擊者會 發送出有缺陷或不正常的 IP 封包給受害端。試圖造成受害端的不正 常運作，進而導致崩潰。如 Ping of Death 送出超大的封包；TearDrop. -7-.
(17) 送出重覆偏移量的封包碎片；LAND 攻擊則會利用"IP Spoofing"的技 術送出來源與目的端同樣位址的封包給系統。當系統在處理這些有 缺陷的封包時，將會耗用大量的系統資源或造成系統的不正常處 理，而造成系統當機。 4.. DNS 欺騙 (Domain Name Service Manipulation) DNS 主要的功能是進行域名與 IP 位址的轉換，當我們欲連上某台 主機進行它們所提供的服務時，就必須先進行域名與 IP 的轉換取得 主機的 IP。而攻擊者會利用各種不同的方法試圖污染 DNS 的記錄 資訊，使得正常使用者無法正確解析出目的端 IP 位址，以致於連不 上主機，達到另一種變相的 DDoS 攻擊。. 2.1.2 DDoS 攻擊手法 基於上述的各種攻擊類型，世界各地的駭客們無不每日絞盡腦汁的 想出新的攻擊手法，以在這廣大的網路世界裡展現他們高超的電腦技能 及深厚的專業知識，而達到攻敵不備，讓目標主機防不勝防。目前較常 見之 DoS/DDoS 攻擊手法則有以下幾種 : 1. TCP SYN 洪水攻擊 (TCP SYN Flood attack)： 主要利用TCP/IP協定本身的漏洞。由於TCP 建立連線需要經過三向 交握(three-way handshake)，攻擊者對被害者發出連續的連線要求. -8-.
(18) (SYN 封包) 並將這些SYN封包填入不存在或不正確的來源位址，當 被害者收到這些封包時，會回傳SYN ACK 封包並等待原先發送端的 ACK封包，但是由於來源是不存在或不正確的，所以被害者不可能收 到要求端的ACK，造成被害者的等候佇列被所需傳回的ACK回應所 填滿而無法再接受建立連線的要求，最後造成系統崩潰。 2. UDP 洪水型攻擊 (UDP Flood attack)： 攻擊者送出大量會執行惡意代碼的UDP 封包(可能偽造來源位址以 避免被追蹤)給被害者，使被害者的網路擁塞甚至中斷。 3. ICMP 洪水型攻擊 (ICMP echo reply Flood attack)： 攻擊者產生大量的ICMP echo request 封包(可能偽造來源位址以避免 被追蹤)給被害者，被害者必需回應等量的ICMP echo reply 封包，使 得被害者的電腦 CPU 負載增加或網路擁塞甚至中斷，不過，通常一 般的主機為了防止駭客的掃描，會拒絕 ICMP 封包的傳回。 4. Smurf 攻擊 (Smurf attack)： Smurf 利用了ICMP (Internet控制訊息協定)。ICMP在Internet上用於錯 誤處理和傳遞控制訊息。它的功能之一是與主機聯繫，透過發送一個 回應請求（echo request）訊息包看看主機是否“活著”。最普通的 ping 程式就使用了這個功能。攻擊者將會連續的送出偽造來源的 ICMP echo request封包送到網路上的廣撥位址( broadcast addresses)，並且將. -9-.
(19) 來源位址設成被害者的位址，這樣的話將會造成所有收到此封包的主 機回傳的大量ICMP echo reply 封包給被害者，使被害者的網路擁塞 甚至中斷。 5. 混合型攻擊 (Mix attack)： 攻擊者依序使用 UDP Flood 攻擊、ICMP Flood 攻擊和 TCP Syn Flood攻擊法，以避免Router 偵測單一型式的攻擊，給予過濾。 6. Targa3 攻擊 (Targa3 attack)： 由於各個作業系統廠商在實作TCP/IP 時，有些灰色區域RFC 並沒有 定義的很清楚，如例外處理程序OOB(Out-of-Band)的處理，IP stack 的 作法，IP 封包切割與重組等等。攻擊者送出這些介於臨界點的封包， 可能會導致作業系統當掉，網路停止運作或其它不可預期的行為發 生。而Targa3 是收集19 種這類型程式的程式。 7. Ping of Death : 根據 TCP/IP 規範，一個封包最大的長度為 65535 位元組，攻擊者 產生超過 IP標準的最大長度 65535 位元組的IP封包並發送給受害 端。當這個"浮腫的"封包到達的時候，它會使得一個脆弱的TCP/IP 協 定軟體和作業系統的伺服器癱瘓。 8. Teardrop : 它主要是利用了系統重組 IP 封包過程中的漏洞工作。當資料經由網 路傳送，IP封包經常會被切割成許多小片段。每個小片段和原來封包. -10-.
(20) 的結構大致都相同，除了一些記載位移的資訊。而 Teardrop 則產生 一些IP片段，這些片段包含重疊的位移值。如第一個 IP片段偏移量 為0，長度為N，第二個 IP片段的偏移量小於N。當這些片段到達目 的地而被重組時，為了重組這些封包，TCP/IP 堆疊會分配超乎尋常 的巨大資源進而造成系統資源的缺乏及系統當機。 9. Land-based : "LAND"攻擊則會送出一連串的SYN封包給受害端主機，並且利用"IP Spoofing"的技術將封包的來源與目的位址都設置成受害端主機，讓受 害端系統以為這些封包都是他自己發送的。當系統在處理這些封包 時，可能造成受害端試圖與自己建立連接，由於它並不能回應給自 己，而造成系統當機。 10. CPU Hog : 一種透過耗盡系統資源使NT系統的主機癱瘓的阻斷服務攻擊，利用 Windows NT排定當前運作程式的模式所進行的攻擊。 11. Win Nuke : 是以阻斷目的主機服務為目標的網路層次的攻擊。攻擊者向受害主機 的端口53、113、137、138、139，即 Netbios 發送大量並且URG 設 為”1”的緊急狀態封包。因為這些資料並不是目的主機所需要的，所 以會導致目的主機的當機。 12. RPC Locator :. -11-.
(21) 攻擊者透過 telnet 連接到受害者機器的端口 135 上，發送資料，導 致 CPU 資源完全耗盡。依照程式設置和是否有其他程式運作，這種 攻擊可以使受害主機運作緩慢或者停止回應。無論哪種情況，要使 主機恢復正常速度必須重新啟動。. 2.1.3 DDoS 攻擊工具 為了能更方便及快速的進行攻擊，許多駭客們把攻擊的程序編寫成 了軟體，藉由軟體的簡易操作，往往只需幾個按鍵就能輕易地發動攻 擊，大量的縮短了攻擊時的指令步驟，也縮短了受害端主機之存活時 間。這一方面是為了提高了攻擊的成功率，另一方面也是為了證實自己 的能力。目前較有名的DDoS軟體工具有以下幾種[16] : 1. Trinoo Trinoo 是一個主從式架構的分散式阻斷服務攻擊程式，它使用 「master 程式」對實際實施攻擊的「代理(agent) 程式」實現了自動 控制。攻擊者首先連接到已安裝了master 程式的主機，啟動 master 程式，然後根據一個 IP 位址的列表，裡面記載所有要進行通訊的 agent 主機 IP位址，由master 程式負責啟動所有的代理(agent) 程式 並下達攻擊命令(如攻擊目標的IP 位址，何時發動攻擊和其它參數)。 接著，代理程式將會使用UDP 封包對受害端目標進行攻擊。在攻擊 之前，攻擊者為了安裝軟體，必需先取得攻擊主機之控制權。. -12-.
(22) Trinoo的攻擊方法是向被攻擊目標主機的隨機端口發出全部為零 的4位元組UDP 封包，在處理這些超出其處理能力的垃圾封包的過程 中，被攻擊主機的網路性能會不斷下降，直到不能提供正常服務，最 後崩潰。它對IP位址不進行偽造，採用的通訊埠號如表2-1 所示。. 表 2-1 Trinoo 通訊埠號 主機. 協定. 埠號. 攻擊者主機到主控端(Master)主機. TCP. 27665. 主控端主機(master)到代理端(agent)主機 UDP. 27444. 代理端(agent)主機到主控端(master)主機 UDP. 31335. 2. Tribe Flood Network : TFN與trinoo一樣，由主控端程式和代理端程式兩部分組成，使 用一個「master程式」與位於多個網路上的攻擊代理主機(agent) 進 行通訊。TFN可以並行發動數個DoS攻擊，而且還可產生偽裝來源 位址的訊息封包。可以由TFN發動的攻擊包括︰UDP Flood、TCP SYN Flood、ICMP Echo Request Flood 以及 SMURF，並且具有偽 造封包的能力。攻擊者、主控端和代理端主機相互通訊時使用ICMP Echo和ICMP Echo Reply封包。但TFN對ICMP的通訊訊息並沒有進 行加密。. -13-.
(23) 3. Tribe Flood Network 2000 : TFN2K 是由 TFN 發展而來的，在 TFN 所具有的特性上，TFN2K 又新增一些特性 : (1) 在 TFN2K 下，主控端(Master)與代理端(Agent) 之間的通訊 可以使用許多協定，例如 TCP、UDP 或 ICMP，這使得利用 協定進行過濾變得不可能實現。並且攻擊者、主控端及代理 程式之間的網路通訊是經過加密的，中間可能還混雜了許多 虛假封包，將使得我們更加難以攔截軟體間之通訊活動。 (2) TFN2K 能夠發送破壞訊息封包，導致系統癱瘓或不穩定。 (3) TFN2K 偽造來源位址，讓訊息封包看起來好像是從 LAN 上 的一個臨近機器來的，以抵抗 Ingress Filtering 及 Egress Filtering。 (4) 攻擊方法增加了 Mix 和 Targa3。 4. Stacheldraht Stacheldraht 是從 TFN 衍生出來的，所以它跟 TFN 及 trinoo 一 樣都是伺服器/客戶端模式，也因此它具有 TFN 的特性，同樣利用 Master 程式與潛在的成千個代理程式進行通訊。此外它增加了主控 端與代理端的加密通訊能力，在下命令時的來源位址是偽造的，可 以防範一些路由器的 RFC2267 過濾。此外，Stacheldrah 中有一個內 嵌的代理升級模塊，可以自動下載並安裝最新的代理程式。. -14-.
(24) Stacheldraht 跟 TFN一樣，可以並行發動多種的DoS攻擊，類型 繁多，而且還可產生帶有偽裝來源IP位址的封包。Stacheldraht所可 以發動的攻擊包括UDP Flood、TCP SYN Flood、ICMP Echo request 以及SMURF。而攻擊者與主控端(Master)和代理端(Agent)間相互通 訊時所使用的協定及埠號如表 2-2 所示。. 表 2-2 Stacheldraht 通訊埠號 主機. 協定. 埠號. 攻擊者主機到主控端(Master)主機. TCP. 16660 60001. 主控端主機(master)到代理端(agent)主機、 TCP、 65000 代理端(agent)主機到主控端主機(master) ICMP echo reply. 表 2-3 為 DDoS 攻擊軟體可實現之攻擊方法整理 :. 表 2-3 DDoS 攻擊軟體可實現之攻擊方法 軟體/攻擊 類型. Syn Flood UDP Flood ICMP Flood SMURF Mix Targa3 ˇ. Trinoo TFN. ˇ. ˇ. ˇ. ˇ. TFN2K. ˇ. ˇ. ˇ. ˇ. Stacheldraht. ˇ. ˇ. ˇ. ˇ. -15-. ˇ. ˇ.
(25) 2.2 DDoS 攻擊防制 根據相關的文獻探討，對於防範 DoS/DDoS 攻擊的方法以不同的角 度來說可以有幾種的分類，以追溯的機制角度而言，可以分為 proactive 與 reactive ， 以 防 禦 的 機 制 角 色 而 言 ， 可 以 分 為 router-based 及 victim-based。. 2.2.1 DDoS 攻擊追溯 目前現行的 DDoS 攻擊追溯，大致來說有以下幾種，我們就針對這 幾種方式，作一簡單的描述[8,10,18,22,28,37]。 (一)、Link Testing 這一類的方法，主要是由最接近受害端的 Router 開始，使用統計及 樣本分析，偵測所連接的連結裡，哪一個連結帶有大量的攻擊流量，經 由這樣持續不斷的判斷監測，追溯到最上層的攻擊來源主機。這類的方 法必需考慮到網路管理者間的協調問題，同時也必需懂得將攻擊封包與 合法封包區分開來。這種方法主要有兩種實現： 1. Input Debugging 當 Router 管理者發現網路中帶有攻擊特徵的封包時，就會判斷 封包是由哪一連結進入，並告知上游管理此區域的 ISP，藉由如此 不斷的重複的往上尋找直到攻擊的來源被找到。這個方式必須在遭 受攻擊時才能使用。. -16-.
(26) 2. Controlled Flooding 這一種技術原理主要是從受害端主機產生大量的網路流量到上 游的網路區段中，重覆的往最靠近受害端主機的每個連結送出，並 觀察路由器的狀態來判斷攻擊路徑。由於攻擊端與受害端同時共用 了路由器，將使得路由器丟棄封包的機率大大的增加而藉此判斷攻 擊路徑。. 圖 2-2 利用 Linking Testing 進行追溯 (二)、Logging 在封包送往目標的網段上，把關鍵的路由器上所經過的封包記錄起 來，並使用data mining的技術從中萃取出有關攻擊者攻擊來源的資訊。 但是這個方法卻有一個缺點，就是以現今網路的速度而言，勢必要佔用 掉大量的儲存空間[33]。 後來也有人提出一個名為SPIE的改進的方法，就是只儲存相關聯有. -17-.
(27) 意義的封包部份之雜湊，而不是全部封包，並記錄在一個有效率的記憶 結構Blood Filter裡，藉此降低所要儲存封包的空間需求[9]。. 圖 2-3 利用 Logging 進行追溯. (三)、ICMP-based Traceback 這個方法是由IETF所提出，稱為iTrace，主要是當封包通過時，Router 會有很低的機率(如 1/200000)產生一個ICMP封包給受害端，裡面包含一 些封包的來源、發送時間、認證等資訊。而DDoS所產生的大量封包將 可使得Router 發送出許多封包，這可使的網路管理者利用這些所接收到 的封包拼湊出攻擊者的路徑[10]。 此方法的缺失就是比較擁擠的路由器可能送出較多的追蹤封包，而 比較少封包通過的路由器可能就發出比較少的追蹤封包。雖然 DDoS 的 攻擊路徑將會產生大量的封包通過，但不能肯定比較少封包通過的路由 器在封包增加後能大於那些本來就很擁擠的路由器。而且當攻擊者利用. -18-.
(28) 大量的發送端發送封包時，如果每個發送端都只是總流量的一小部份 時，在這樣的情況下，受害端將會收到許多較接近的 Router 的 ICMP 封 包，而較靠近發送端的 ICMP 封包則會少很多。. 圖 2-4 iTrace 追溯. (四)、Packet Marking Packet marking 主要就是在個別的封包經過 router 時，router 會有一 定的機率在封包的表頭前加入有關 router 的資訊，而由於 DDoS 產生 的大量封包，將使得受害端那邊有足夠的資訊可以重新建構出攻擊的路 徑。值得注意的是，為了要有效率，Packet Marking 應盡可能的不要增 加 packet 的大小，這是為了避免封包遭受切割而增加了多餘的網路流 量[12,18,27,32,34,37]。. -19-.
(29) 圖 2-5 利用 Packet Marking 進行追溯. 2.2.2 DDoS攻擊防禦 DDoS 防禦的機制可以分為 Router-based 及 Victim-based 兩種。 Router-based 的方法就是對大量的封包流量進行離線的分析，或者是在 router 內進行線上的 DDoS 流量過濾，所謂離線分析的 IP 追溯就是在 DDoS 攻擊發生過後試著運用一些方法追溯攻擊的來源，雖然離線分析 的方法是有可能追查出攻擊來源，但是它在遭受攻擊時卻不能幫助我們 維持服務的穩定性。而在 router 上進行線上的過濾，如有發現攻擊封包 的樣本特徵，就進行封包的過濾，其所仰賴的就是 router 偵測不正常流 量的能力，這種方法雖然在攻擊進行中能有效的阻斷攻擊，但也需要個 各網路管理者之間的協調合作[19,28]。 而 Victim-based 的方法，就是受害端在自己本機運用某些機制去進 行攻擊流量的過濾，或者是攻擊來源的過濾 [4,5,20,24,35]。. -20-.
(30) 針對 DoS/DDoS 攻擊來說，攻擊的目的主要為癱瘓受害端的系統， 使其無法正常運作及提供正常服務，而根據攻擊技術方面來探討，DDoS 可以藉由上述的幾種方法來達成 : 1. 發出超出受害端可以負荷的大量垃圾封包，或是改變封包的控制 資料，使受害主機無法正確的處理所收到的封包。 2. 利用 ICMP 封包做洪水或倍增式的攻擊，塞爆受害端的網路頻 寬。 3. 利用 TCP/IP 協定的三向交握，使受害主機產生大量等待的 TCP 連接，進而停滯或癱瘓。 上述是比較常見的幾種 DDoS 攻擊的方法，一般來說我們可以單靠 一些比較簡單的方法就可以偵測出攻擊的發生，如設定ㄧ時間區間來測 量單位時間的封包流量，藉以訂定一個封包量的門檻值，若是超過門檻 則發出警報。或是檢查封包中欄位異常的部份，當系統收到這些封包時 會造成無法處理或當機，所以最好的方法就是找出這樣的封包，丟棄或 不處理。Victim-based 的偵測過濾方法一般來說有以下幾種： (一)、Rule-based 分析 將 DDoS 攻擊已知的樣本存入資料庫內，並藉由不斷進行的資料庫 更新來偵測出 DDoS 攻擊，這種方式的缺點就是只能偵測出已知的攻擊 型態，對於那些未知及變種的攻擊並沒有辦法偵測出來。. -21-.
(31) 對於消耗系統資源的 DDoS，由於是在單位時間內出現大量的封包 數，所以我們可以訂出在固定單位時間所允許接收的門檻值，而針對違 反協定的封包導致系統無法處理或當機這一類的 DDoS 攻擊，可以針對 異常的部分建立起 rule 做檢查比對的工作[4,5]。 (二)、統計分析 利用統計分析來偵測 DDoS，對於第一種技術的 DDoS 可以針對各 個 IP 觀察其傳送進來的封包數量，以及測量單位時間內的封包抵達率， 如發現不合理或異常之狀況，可以給予警報[17]。 (三)、IP 封包表頭進行分析 雖然在攻擊發生時，IP 封包內的欄位資訊將會被偽造，使得受害端 無法得知攻擊端的來源位址，但是藉由其中的一些資訊，還是可以有效 的過濾偽造封包[20,35]。 (四)、根據網路異常現象偵測 DDoS 攻擊的工具在進行攻擊前，常需要進行溝通，而其通常有兩 種情況，控制資訊通訊及攻擊時的網路通訊，控制資訊通訊主要發生在 DDoS Client 及 Server 間，在攻擊發動前，Server 一定需要跟 Client 進 行通訊以發動攻擊，而網路通訊通常發生在 Server 端與目標主機之間， 在攻擊前，Server 端可能會對目標主機進行一些查詢的動作，這類的動 作，將可能被記錄在目標主機裡[6]。. -22-.
(32) (五)、History-based IP Filtering 這方法分為兩個部份，主要是依靠平時的網路連線記錄。在第一階 段，一般正常的網路情況下，如果有任何連線跟主機進行溝通的話，主 機會記錄每個流入封包的網路位址，並且利用 Hash function 將之存放 在資料庫內。在第二階段，等到網路攻擊發生時，發現大量的異常網路 流量時。由於 DDoS 會使用大量的偽造來源封包攻擊主機，所以將會產 生許所多不同而且從沒見過的位址的網路封包，這時主機會對流進的封 包進行跟資料庫內的記錄進行比對動作，進而進行封包的丟棄動作 [30,31]。. -23-.
(33) 3. 研究方法與內容. 3.1 研究方法 由於 TCP/IP 協定的缺陷，使得 IP 封包內的表頭資料可以被有心人 任意的假造，進行不法之行為。但雖然如此，IP 封包的表頭也並不是一 無所用，從封包表頭中的某些欄位我們還是可以看出一些封包的活動狀 態，而我們所要利用的資料就是封包欄位內的 TTL (Time To Live)。. 圖 3-1 IP 封包標頭. IP 封包的路由過程必須靠沿途所有路由器通力合作才能完成。但是 網路上這麼多路由器，難免會有意外發生，而使得 IP 封包無法到達目 的裝置，從此在網路中無止盡的漂流。所以為了避免封包一直充斥在網 路上面，當來源裝置送出 IP 封包時，會設定封包的存活時間初始值。. -24-.
(34) 因此在 IP 表頭中記錄了封包的存活時間，限制 IP 封包在路由器之間傳 送的次數。在 IP 協定中，TTL 是以 hop 為單位，每經過一個 router 就 減 1。如果封包 TTL 值降到為 0 的時候，這個封包就會被進行丟棄。 針對這個特性，在接收封包主機這邊我們可以藉由查看流進封包的 TTL 值，進而推算封包所經過的 Router 數。那假如我們接收端這邊已經存 放接收端到封包來源位址間的 Hop Count 數，我們便可以將流進封包所 經過的 Hop count 與本機內部存放的 Hop count 進行比較，判斷這個封 包以這個來源端發送所經過的 Hop count 是否正確，而給予通過或過 濾。所以我們所要進行的就是 : z 大量探測接收端本機到各個來源端間的 Hop Count。 z 得知流進封包所經過的 Hop Count。. 3.1.1 來源端與接收端間 Hop Count 檢測 要探測接收端到來源端之間的 router 數，最簡單的做法為 tracert 指 令[20,35]，例如 Windows 下的 tracert 及 linux 下的 tracerouter，都可以 列舉出來源端到接收端之間所經過的 router。其原理為持續送出慢慢遞 增的 TTL 值的 UDP 封包，當封包到達目的地途中而 TTL 降到 0 的時 候，路由器就會丟棄這個封包，並且同時向來源端送出一個 time_exceeded 的 ICMP 封包，所以當我們發送第一個 TTL 為 1 的 UDP. -25-.
(35) 封包時，封包會在第一個 router 被丟棄，並傳回 ICMP 封包告知我們， 而第二個 TTL 為 2 的 UDP 封包將會在第二個 router 被丟棄，以此類 推，所以我們將能得知主機與目的地間中途所要經過的 router 及其個數。 在本研究系統中，我們並不是利用 tracert 指令去取得來源端與目的 端間的 router 個數，而是直接跟目標主機進行 TCP 交握，根據 TCP/IP 協定規則，雙方主機欲進行 TCP 通訊時，並須先進行 TCP 三向交握， 當 A 端主機發送標有 SYN Flag 的封包給 B 主機時，B 主機如果正在 Listen 這個 Port，則會傳送回標有 SYN 及 ACK Flag 的 TCP 封包，而 如果 B 主機此時並沒有 Listen 這個 Port 的話，則會送回標有 RST Flag 的封包中斷這個連線，如圖 3-2 所示。. 圖 3-2. TCP/IP 封包溝通. 藉由這個方式，我們可以順利取得網路中廣大網域的主機所傳回的. -26-.
(36) 封包，並取得其封包中的 TTL 值，記錄到資料庫內以便進行以後的比對 動作。利用這個方式跟 tracert 比起來，有三點的好處。 1. tracert 是持續送出遞增的 TTL 值封包，所以從來源端到接收端間的 router 數有多少個，tracert 就必須送出多少次的封包，比較起來， 直接對目標主機發出 SYN 封包將會大大的減少我們的時間與網路 流量，尤其是在我們需對廣大的主機進行檢測的動作時。 2. 如果 tracert 途中，有 router 或是主機端被設置為拒絕或是不允許回 應 ICMP 封包，則可能會影響到我們收集 Hop Count 的精準性及正 確性。 3. 使用 tracert 所得到的 Hop count 雖然正確，但如果某些主機所發送 的初始 TTL 值並不是一般的固定數值(32、64、128、255)，則可能 產生誤差的情況。例如，我們探得到某處電腦 A 的 Hop count 為 5， 則我們在本機的資料庫這邊將電腦 A 的 Hop Count 記錄為 5，那往 後如果電腦 A 傳送封包來時，由於其初始 TTL 值的不同，封包 TTL 值經過轉換後皆不在合理範圍，便會將此封包視為偽造封包，影響 了封包接收的正常性。而利用其所傳回的 TCP 封包，將封包內的 TTL 經過轉換，不管電腦 A 初始的 TTL 值為多少，在往後收到此主 機所傳送之封包進行檢測時，在本機端這邊都是由相同的數值(32、 64、128、255)轉換，將可解決這個問題。. -27-.
(37) 3.1.2 封包 Hop Count 檢測 我們雖然可以觀察到封包內的 TTL 值是多少，但是由於不同主機 所發出封包的 TTL 初始值卻是不一樣的[36]，如表 3-1 所示。. 表 3-1 各作業系統之 TTL 初始值 TCP TTL 初始值. 作業系統. UDP TTL 初始值. AIX DEC Pathworks V5 FreeBSD 2.1R HP/UX 9.0x. 60 30 64 30. 30 30 64 30. HP/UX 10.01. 64. 64. Irix 5.3、Irix 6.x Linux MacOS/MacTCP 2.0.x OS/2 TCP/IP 3.0 OSF/1 V3.2A Solaris 2.x SunOS 4.1.3/4.1.4 Ultrix V4.1/V4.2A VMS/Multinet VMS/TCPware VMS/Wollongong 1.1.1.1 VMS/UCX (latest rel.) MS WfW MS Windows 95 MS Windows NT 3.51 MS Windows NT 4.0. 60 64 60 64 60 255 60 60 64 60 128 128 32 32 32 128. 60 64 60 64 30 255 60 30 64 64 30 30 32 32 32 128. (資料來源：http://secfr.nerim.net/docs/fingerprint/en/ttl_default.html). -28-.
(38) 例如 Windows 95/98/98SE/ME 所送出的封包 TTL 值為 32，Linux Kernel 2.2.x 以 及 2.4.x 的 TTL 初 始 值 為 64 ， Windows NT4 WRKS/Server/2000/XP TTL 初始值為 128，FreeBSD 3.4、4.0、4.1；Sun Solaris 2.5.1、2.6、2.7、2.8；OpenBSD 2.6、2.7 及 NetBSD HP UX 10.20 為 255，所以我們必需要經過轉換計算後才能得到真正的 Hop Count。 所幸目前大部份 OS 的 TTL 值多為以上的幾個數值，且一般封包在網路 傳送時所經過的 Hop Count 也很少超過 30，所以我們可以利用這原理推 算出封包的 TTL 初始值及所經過的 Hop Count。我們用一簡單的演算法 去進行封包 Hop Count 的轉換，如表 3-2 所示。. 表 3-2 Hop Count 轉換演算法 If (TTL > 128) Hop Count = 255- TTL; else If (TTL > 64) Hop Count = 128- TTL; else If (TTL > 32) Hop Count = 64- TTL; else Hop Count = 32- TTL;. 例如，一個流進封包其 TTL 值為 60，那我們就可推算出其 TTL 初 始值為 64，不可能為 128，則其所經過的 Hop Count 為 64 – 60 = 4。. -29-.
(39) 3.1.3 歷史接觸記錄 為了進一步增加系統的效用及準確性，我們加入了歷史接觸記錄 (History Touch Record)，將所有曾經與本機接觸過的 IP 位址，在資料庫 內作一標示。由於 DDoS 攻擊時會產生許多假冒的 IP 位址封包，利用 這個方式我們可以更進一步的過濾從來沒有和我們連繫過的 IP 位址。 當然，所有被標示接觸過的 IP 位址有一定的期限值，這是為了避免 曾經只接觸過一次的 IP 位址就從此免疫，而被攻擊者進行假冒。所以 必需訂定一段時間週期來限定 IP 位址之有效性。而在期限值之內的 IP 位址我們都視為有效。做法是我們對於所每一次與本機有所接觸的 IP 位址給予一積分值，由於積分值是採取累加的計算方式，所以連線頻繁 的 IP 位址其積分將會進行累加。而積分值將於固定週期後進行一次右 位移(right shift)動作，直到積分值為零，也就是期限。當一個 IP 位址的 期限到達時，除非再增加積分值，否則還是將由此 IP 位址而來之封包 判斷為可疑之偽造封包。. 3.2 可行性分析 由於攻擊者在發動 DDoS 攻擊時，所控制的是成千上百的 zombie 及 agent 主機，這些主機散佈在各個不同之地理位置，故每台主機發送之 封包到達本機之 TTL 值絕對是不相同。在目前現有的 DDoS 工具中，只. -30-.
(40) 允許攻擊者去控制封包來源位址的變異程度，以躲避路由器的防偽功 能，但卻無法對每個不同的主機所發送的封包設定特定的 TTL 初始值。 另外，由於攻擊者攻擊時為了避免受到追溯，攻擊封包所用的來源位址 都是隨機捏造。但是攻擊者又無法得知封包所假冒的來源位址其到達受 害端所要經過的 Hop Count，如此一來，封包內的假冒來源位址與封包 內的假冒 TTL 值並無法符合。由於這樣，將使得我們很容易的去判別出 偽造的 IP 封包。而為了避免攻擊者使用大量的亂數去猜測 IP 位址的 TTL，在必要時候，我們也將過濾沒有接觸過的 IP 位址所傳送之 IP 封 包。 假設另一情況，攻擊者事先以經知道某台主機到受害端主機途中所 要經過的 router 數，而欲假冒此 IP 位址進行攻擊，則在受害端主機上 將會接收到重覆性很高之 IP 位址的攻擊封包，這將使得我們可以很容 易的在路由器或主機上設定條件規則去過濾此來源位址之 IP 封包。. 3.3 系統架構 本系統建構在 Linux 平台上，搭配 MYSQL 作為 AHCT(Address & Hop Count Table)資料庫，AHCT 內存放著各個 IP 網段的 Hop Count 及 接觸記錄等相關資料，使我們能順利的與流進本機的封包進行比對的動 作。圖 3-3 為本研究之系統網路環境架構。. -31-.
(41) 圖 3-3 Hop Count Filter System 網路架構圖. 而圖 3-4 為系統內部模組架構圖[2,3,21]。AHCT 資料庫的建置，我們將 在下一小節說明。. 圖 3-4 Hop Count Filter System 模組架構圖. -32-.
(42) 3.3.1 各模組功能說明 : 1. HC 探測模組 : 在系統中，我們利用「HC 探測模組」掃描廣大 的主機網域，藉由模組所發送的 TCP SYN 標誌封包，我們能大 量的取得網路主機所返回的 SYN.ACK 或是 RST 封包，並經由 封包剖析探得本機與各個 IP 網域中途的 Hop Count，再與 MYSQL 資料庫進行連接，將所取得的 Hop Count 存入 MYSQL 資料庫中，以便將來進行封包過濾時所需進行之比對動作。 2. 狀態轉換模組 : 依據封包的比對錯誤率高低而將系統轉換為不 同之狀態。系統本身有三種狀態，Normal、Alert 與 Action 狀態， 當處在 Normal 狀態時，系統並不會丟棄任何封包，而只會判斷 流進封包的 Hop Count 範圍值，並計算封包比對錯誤率。當錯誤 率達管理者所設定的一「警告比例」x 後，系統便進入 Alert 狀 態。當系統狀態進入 Alert 狀態後，系統會發出警訊通知管理者 系統接收太多的不合理封包，系統管理者需注意是否有可疑狀 況發生，例如流量的爆增，或是路徑 router 受到改變等需更新 AHCT 資料之現象。而當封包比對錯誤率到達「臨界比例」y 後， 系統狀態將會轉換成 Action，在這狀態下的不合理封包，將被 進行丟棄動作。. -33-.
(43) 3. 封包檢測過濾模組 : 藉由「封包檢測過濾模組」 ，我們能對所流 進系統的封包與資料庫內之探測資料(Hop Count 及 History Record)作一比對，如不在合理範圍之內則將之判斷為非法及偽 造的封包，必要時將之丟棄。 4. 位址解析模組 : 這個模組主要監控資料庫內的位址資料，當系 統處於 Normal 狀態時，經由封包檢測模組檢測通過後，判斷為 合理的 Hop Count 範圍之封包，便進行 IP 位址的「接觸記錄」， 其會在資料庫內的 Touch 欄位增加一定之積分值。而為了避免 攻擊者的事前準備動作，在攻擊前事先用假冒的 IP 位址來增加 History Record，所以必須是合理範圍的 Hop Count 封包資料才 給予記錄。當系統處於 Alert 狀態時，表示系統目前可能接收到 一些不尋常之 IP 封包，所以在這系統狀態下時，封包之 Hop Count 即使是在合理範圍內，我們也不進行 IP 位址的「接觸記 錄」。當系統處於 Action 狀態時，此時系統可能正處於大量偽 造封包接收之情況，所以對於未曾接觸過之 IP 位址將採取丟棄 之動作。 5. AHCT 資料庫 : 資料庫內容欄位如表 3-3 所示。 (1) IP Address 代表所掃描 IP 位址前 24 bits 網段位址。由於在 同一個子網段之主機其到達本機所要經過的 Hop Count 是相. -34-.
(44) 同的，所以我們只記錄前 24 bits 網段位址，以節省儲存空間 及提升比對效率。 (2) Hop Count 為上述之 IP 網段到達本機時所要經過之路由數 (3) Range 為此 IP 網段之 Hop Count 可以容忍之誤差值，由於 封包路由過程是不固定的，其可能因路徑的不同或是路由器 的增減而使得所經過的路由器數有些許的變動，所以增加此 一欄位以提高比對命中率。 (4) Mismatch times 為該網段之累積錯誤次數。 (5) Time 為這筆資料記錄之產生時間。 (6) Touch 則為此 IP 位址所累計之積分值，當積分值為零時則 代表此 IP 位址從沒接觸過。. 表 3-3 AHCT 欄位表 IP Address. 所掃描之 IP 前 24 bit 網段位址. Hop Count. 所對應之 Hop Count. Range. 所容許之誤差範圍值 <0,1,2>. Mismatch times. 該網段封包比對錯誤次數. Time. 所掃描之時間. Touch. 過去曾經接觸記錄. -35-.
(45) 3.3.2 封包檢測流程演算法 Step 1 : 封包流入，擷取封包來源位址 S 並找尋對應之資料紀錄 Step 2 : 如果紀錄存在，取出資料並計算流入封包所經過的 Hop Count 數，如果資料紀錄不存在則進行 Step 5 Step 3 : 比對流進封包之 Hop Count 是否與資料庫內資料相符， 「是」則進入 Step 4，「否」則進入 Step 5 Step 4 : 判斷目前系統狀態，一般(Normal) 狀態則增加 IP 接觸記 錄，活動(Action)狀態則判斷 IP 位址是否接觸過，「是」則 給予通過，「否」則丟棄，並皆進行 Step 6 Step 5 : 判斷系統狀態，一般(Normal) 狀態及警戒 (Alert) 狀態則 給予封包通過，活動(Action)狀態則進行封包丟棄 Step 6 : 計算封包正確率 Step 7 : 判斷是否超過封包錯誤率臨界值 Step 8 : 「是」則系統進入緊戒狀態，「否」則進入一般狀態. 如圖 3-5 封包檢測流程所示，當系統在 Normal 狀態時，我們利用封 包檢測過濾模組來對每個流進封包進行檢測動作。. -36-.
(46) 圖 3-5 封包檢測流程. -37-.
(47) 當封包流進後，藉由封包檢測過濾模組，取出封包的來源 IP 及 TTL 值，經由轉換成 Hop Count 並取出資料庫內該 IP 網段所記錄之對應 Hop Count，判斷是否在合理範圍內，如果是則允許封包通過，並進行 IP 位 址的「接觸記錄」。如果否則檢測系統目前所處的狀態，再決定是否丟 棄封包，並計算封包比對的錯誤率。當系統轉變為 Alert 狀態時，縱使 封包經過了 Hop Count 的比對正確，其 IP 位址也不會進行 IP 位址的「接 觸記錄」，原因為此封包可能是攻擊者對攻擊事件的事前準備。當系統 狀態轉為 Action 時，此時對所流入的封包會先進行 Hop Count 的比 對，如果比對結果為落在不合理範圍之 Hop count 封包則進行丟棄。如 果比對通過則再檢查此 IP 位址是否有接觸過之紀錄。如果沒有則直接 丟棄此封包。 而當所接收的封包正確率慢慢提升後，便將系統狀態轉換成原來的 Normal 狀態。封包的錯誤率是由系統接收到第一個錯誤封包後算起，在 固定時間內所收到的封包數裡計算封包的錯誤率。如果在這段期間內系 統轉換為 Alert 或 Action 狀態，則封包錯誤率將被持續計算到系統恢復 成 Normal 狀態才停止，並在接到下一個錯誤封包後重新開始計算。如 果在這段時間內系統還是維持 Normal 狀態，則系統將在接收到下一個 錯誤封包後開始算起。 為了更清處的了解封包過濾的程序，我們利用決策樹的模式來表現. -38-.
(48) 所進行之決策判斷過程，如圖 3-6 所示。. 圖 3-6 封包過濾決策圖. -39-.
(49) 4. 系統實現 為了過濾偽造封包，所以我們在 Linux Kernel 2.4.20 平台上利用C 語言完成 Netfilter 模組實現封包過濾功能。. 4.1 Netfilter Netfilter 建立在 Linux Kernel 2.4 及2.6 中，是 Linux 核心中一個通 用的框架架構，可以讓其它東西(例如 iptables 模組) 插入(plug into)，其 目的是讓 Kernel 內部提供支援封包過濾及變更的機制，並且可以讓使用 者於 User Space 執行各種所需的控制指令。Netfilter 被設計成模組化和 可擴充性，也因為這樣，所以它可以由使用者自行設計所需的程式及所 要的功能，並且以模組的方式加到 Netfilter 架構中，使 Netfilter 的使用 上更具有彈性，這種程式模組 Netfilter中稱為 Extension。利用Netfilter 我 們 可 以 進 行 封 包 過 濾 (packet filtering) 、 位 址 及 埠 號 的 轉 換 (network address and port translation)以及封包的修改 (packet mangling)等動作[26]。 Netfilter 框架在 Linux Kernel 中是一個 hook 的集合，它允許 Kernel Module 在 網 路 堆 疊 中 去 登 錄 callback 函 數 ， 而 一 個 已 登 錄 過 的 callback 函數在每個封包流經在網路堆疊的 hook 點時將被進行呼叫。 在 Linux 中定義了五個關於 ipv4 的 hook 點，如表 4-1 所示。. -40-.
(50) 表 4-1 IPv4 所定義之 Hook 點及其支援之 IPTable 模組 Hook 點. 呼叫時間. 支援之 IPTable 模組. (1) NF_IP_PRE_ROUTING. 封包進入本機， 在判斷路由前. Conntrack Mangle NAT( Dst). (2) NF_IP_LOCAL_IN. 通過路由表後， 目的地為本機. Filter Conntrack Mangle. (3) NF_IP_FORWARD. 通過路由表後， 目的地不是本機. Mangle Filter. (4) NF_IP_LOCAL_OUT. 由本機主動建立 的封包，在通過 路由表前. Conntrack Mangle NAT (Dst) Filter. (5) NF_IP_POST_ROUTING. 通過路由表後，要 發送出去前. Mangle NAT (Src) Conntrack. 這些 hook 點的定義可以在 linux/netfilter_ipv4.h 中找到。我們將以 如表 4-2 所示之結構定義每個 hook 點。 表 4-2 Hook 點結構 struct nf_hook_ops { struct list_head list; nf_hookfn *hook; int pf; int hooknum; int priority; };. -41-.
(51) 封包流經這些 hook 點的過程如圖 4-1 所示。在這些 Netfilter hook 點中，封包將被進行分析以決定是否允許通過或進行丟棄。. 圖 4-1 Netfilter hook 點所在位置. 在 nf_hook_ops 結構中，hook 代表我們所要執行之 hook 函式名 稱，由於我們在 IP 層工作，所以 pf 需設為 PF_INET。hooknum 則代表. -42-.
(52) hook 點所在之位置。由於同一個位置可以掛載許多 hook 點，所以我們 必須指定 priority 來排定每一個點的優先順序。Netfilter_ipv4.h 中也定 義了一些優先權的等級。 表 4-3 處理函式優先權等級 enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_MANGLE = -150, NF_IP_PRI_NAT_DST = -100, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, NF_IP_PRI_LAST = INT_MAX, };. 4.1.1 IPTables Netfilter-Iptable. 由兩個部份所組成，一部份為 Netfilter 的 hook. 點，另一部份則是這些 hook 函數如何動作的一套規則，這些規則儲存 在被稱為 iptables 的數據結構中。利用上述之 Netfilter hook 點，當封包 穿過 kernel 裡的網路堆疊時，我們便可在適當的時機調用其所支援的表 格(table) 對封包進行過濾攔截或修改。而 Kernel Module 更可以登錄新 的模組或者要求封包經過某些模組的檢驗。Hook 函數通過訪問 iptables 來判斷應該回傳什麼值給 Netfilter 框架，決定封包之去留。在 Netfilter 中，已內建三種 iptables，分別是 Filter、Nat、Mangle。其功能如表 4-4 所 示。. -43-.
(53) 由 於 iptables 是 核 心 Netfilter 的 使 用 界 面 ， 所 以 我 們 也 把 Netfilter-IPTables 簡稱 iptables。iptables 是處於 user space 下用來控制核 心的過濾規則工具，雖然利用 iptable 可以快速的插入或移除核心封包過 濾表格(packet filtering table) 中的一些規則(rules)。不過它卻是沒有彈性 的。在 iptable 內定過濾的格式中並沒有我們所想要的功能。所以為了達 到我們所需的功能。我們必須自己去寫一個 Linux Kernel Module 並把它 安插在 Netfitler 中，進行封包的比對過濾動作。. 表 4-4 內建之 IPTables 及其功能 表格 (Table). 功能. Filter. 對流進封包進行過濾. Nat. 以 Connection Tracking 模組為基礎，改變封包之來源或目 的位址，並將結果交由 Connection Tracking 模組應用到該 連接之後的所有封包. Mangle. 對封包內容進行修改，包括 MARK、TOS、TTL. 4.2 Loadable Kernel Module 在上一節我們提到，Netfilter 是 Linux 核心裡的一個封包過濾框 架，Linux Kernel 是一個整體式的架構，因此向 Kernel 進行修改加入任 何東西，或者刪除某些功能，都是十分困難的。為了解決這個問題，於 是引入了 Kernel 模組機制。讓我們可以動態的從 Kernel 中加入或者刪 除模組。. -44-.
(54) Linux 的 Kernel 模組 (loadable kernel module, LKM)，是 Linux Kernel 的擴展，我們可以在需要的時候將之插入到 Kernel 中，或者是從 Kernel 中刪除。LKM 基本上是設備驅動程式的軟體實現，也就是說 LKM 通常是用來載入設備驅動程式和其它的硬體驅動程式。它與真實 的或者虛擬的硬體設備協同工作。當 LKM 載入到 Kernel 中時，它們 會監聽和處理對設備的任何請求。 由於模組沒有被編譯在 Kernel 中，所以控制了 Kernel 的大小，而且 只載入所需的 LKM，將可以使 Kernel 變得輕便、模塊化、靈活和可伸 縮。然而模組一旦被插入 Kernel 中後，它就和 Kernel 中的其他部分一 樣，將會增加一部分的系統開銷。接下來，我們將利用 LKM 完成一個 可以安插到 Netfilter 框架中的封包過濾機制。. 4.2.1 登錄 Hook 點 每一個程式都有開始與結束，模組當然也是，所以每一個模組都至 少會有兩個函式，也就是 Init_module() 及 cleanup_module。我們從字 面就可以很清楚的了解，Init_module 為模組初始化之函式。當模組被 載入到核心時，系統便會執行這個函式去進行模組的初始化動作。由於 模組是 Kernel 的一部份，其不能隨意的中斷，所以當我們要移除模組 時，系統則會呼叫 cleanup_module() 這個函式去進行一些記憶體清除釋. -45-.
(55) 放的動作。那既然我們的任務是在網路堆疊中登錄一個 hook 點進行封 包的過濾，自然在模組一開始時就必須去進行登錄動作，所以我們可以 在 Init_module 函式中進行 hook 點的登錄。在 Netfilter 中提供一個函 式 nf_register_hook(struct nf_hook *reg) 可以讓我們去進行 hook 點的登 錄。此函式以如表 4-2 之 nf_hook_ops 結構為參數，當我們設定好 hook 點的各項參數後，便可以利用 nf_register_hook() 將此 hook 點結構的位 址傳入 Kernel 進行登錄，如圖 4-2 所示。. 圖 4-2 hook 點設定與登錄. 當 hook 點登錄完畢後，每個流經這個點的網路封包，都必須受到 相對應的 hook 函數檢測，圖 4-3 為封包自網路卡接收後所經過之處理 函式流程，而我們的 hook 函式即是安插於流程中，經由函式的檢測， 以決定封包的保留或丟棄。相對的，既然有登錄的函式，當然也必須有 移除的函式，Netfilter 以 nf_unregister_hook() 進行 hook 點的移除，所 以我們將它擺在模組要結束時之呼叫函式 cleanup_module() 內，當此模 組被移除時，也一併進行 hook 點的移除。. -46-.
(56) 圖 4-3 Linux Kernel 2.4 封包處理流程 (資料來源：http://open-source.arkoon.net/kernel.php#pkthand). 4.2.2 利用 Hook 函式進行封包過濾 我們之前提到，Netfilter 由兩個部份所組成，一部份為 netfilter 的 hook 點，另一部份則是這些 hook 函式如何動作的一套規則，既然我們 以經進行完 hook 點的登錄動作，接下來就要完成 hook 函式進行封包 的過濾規則。Hook 函式我們可以在 linux/netfilter.h 中找到，原型如表 4- 5 所示。. -47-.
(57) 表 4-5 Hook 函式原型 typedef unsigned int nf_hookfn(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *));. 其中 hook 函式的名稱必須跟表 4-2 我們所登錄的 hook 點結構中的處理 函式是一樣的名稱，使得每一個 hook 點可以找到相對應之 hook 函式。 函式的第一個參數為表 4-1 中 hook 點的類型，其指出 hook 點所擺放 的位置，這個參數我們會在 hook 點的結構中先行設定，第二個參數為 一個指標的指標，其指向一個 sk_buff 結構，網路堆疊利用這個結構存 放所流進的封包，此結構內容我們可以在 linux/skbuff.h 中找到。接下來 的兩個參數 net_device 用來描述所有類型的網路裝置，in 代表封包到 達的裝置，out 代表封包離開的裝置，在一般的情況下，這兩個參數只 有其中一個是有值的，最後一個參數 okfn 為當所登錄的 hook 點其所設 定的 hook 函數為空時，Netfilter 所呼叫的替代函式。 在 sk_buff 結構中，分別定義了各種不同層級以及不同類別之封包 表頭結構，利用這些結構，我們可以將每個流進封包之各個欄位內容讀 取出，並設定規則進行比對。當然，我們在這裡所要檢測的封包內容為 封包之來源位址及 TTL 值，所以我們只需取出封包中此兩欄位之值， 並將它與本機內所存放之資料紀錄進行比對即可。圖 4-4 為 hook 函式. -48-.
(58) 中封包來源位址與 TTL 之擷取。. 圖 4-4 Hook Function 及封包欄位擷取. 但問題是我們要如何從資料庫提取資料與封包進行比對，因為資料 庫內之資料與 hook 函式所處在的位置分屬系統中兩個不同的地方，也 就是使用者空間(user space)與核心空間(kernel space)，而兩空間的資料 交換必需經過一些手續，否則是無法進行溝通的。所以我們還要進行額 外的動作才能在 Kernel 中取得 mysql 資料庫之資料。. 4.2.3 Kernel space and User space 我們常常提到 kernel space 及 user space，其代表的不僅是兩個模式 權限的不同，事實上兩個模式都有各自的記憶體對映(mapping)，也就是 程式代碼使用不同的位址空間。Module 的角色就是延伸 Kernel 的功 能，其工作於 Kernel space。值得注意的是，在 Kernel 中所進行的工作 必須嚴謹處理，其跟一般應用程式中所存在的 user space 空間是不同. -49-.
(59) 的，如果模組出錯的話，將會導致整個系統的崩潰。 Module 並不像一般user space 的應用程式，只要經由連結(link) Library 就可以進行外在函式的呼叫，Module 被限定只可與Kernel 進行 連結。當我們插入一個Module 進去Kernel 時，代表Module以經連結到 Kernel並且可以使用Kernel 內公開的symbol (function and variable)，所以 其所可以呼叫的函式也僅只限於Kernel 所開放出來的，並沒有其它的 library 可以連結。這也就代表我們在程式中無法使用一般基本的C library 函式及API來處理我們的工作。另外，因為模組需要在Kernel 模 式下運作，所以會遇到在Kernel space和User space間資料交換的問題。 而一般的資料複製函數並沒有辦法完成這一交換過程。因此系統已加入 了一些特殊的函數以用來完成Kernel空間和User空間資料的交換[15]，在 下一小節中，我們將會介紹如何與Kernel 進行溝通。. 4.2.4 與Kernel 進行溝通 為了能順利在 Kernel 中過濾封包，所以我們必須將資料庫內所存放 的與封包來源 IP 相對應的 TTL 等資料記錄傳送到我們之前所寫的 Kernel Module 裡。想要與 Kernel 進行溝通有兩種方法，一是產生一個 /proc 檔案系統。/proc 是一個虛擬的檔案系統，它並非真正存在，而是 和正在執行的各程序間的連結，我們可以讀取 /proc 檔案系統得到系統. -50-.
(60) 一 些 相 關 資 訊 ， 如 /proc/cpuinfo 可 以 顯 示 CPU 的 相 關 資 訊 ， /proc/meminfo 顯示記憶體使用資訊。所以利用這檔案系統的讀寫可以 讓 kernel module 輸入輸出我們所想要之資訊。另一個方法是登錄 (register) 一個裝置驅動程式(Device Driver)，並產生相對應之裝置檔 案，藉此與裝置進行溝通，傳送我們想要之資料。所以，我們在所寫的 Kernel Module 中登錄了一個虛擬裝置並產生其檔案，接著在 User space 下寫一應用程式，其任務為連結 Mysql 資料庫內之資料並傳送給我們所 產生的虛擬裝置，在裝置中也必須設置好接收資料的動作。我們使用一 個特別的函式 IOCTL (Input Output ConTroL)去進行資料的傳輸。IOCTL 是設備驅動程式中對設備的 I/O 通道進行管理的函數。也就是對設備的 一些特性進行控制，在 user space 中這個函式並沒有特定結構，其原形 為 int iotcl( int fd, unsigned long cmd, ...). 由於每一個裝置都擁有自己的 IOCTL 控制，使得我們可以從 Process 送資料到 Kernel 中或是從 Kernel 中傳送資料給 Process。IOCTL 的參 數，第一個為利用 open 函式打開對應此裝置的裝置檔案所得到之描 述，而 cmd 則是使用者所希望裝置執行之動作命令，我們將在 kernel 裡 依所傳進來不同之命令將有對應之執行動作。其中後面的 "..."則可以隨 使用者所想傳送之資料而變動，也就是說在使用者空間中我們可以傳送. -51-.
(61) 任何想要之資料與系統進行溝通，其可以為數值，也可以為一指標，使 得大量的資料經由指標從 user space 傳送到 kernel space。 在 kernel 中，我們同樣也必需宣告 IOCTL，不過在 kernel 中的 IOCTL 其原型跟在使用者空間中是不同的，其原型為. int (*ioctl) (struct inode * inode, struct file *filp, unsigned int cmd, unsigned long arg). 其中 inode 與 filp 指標對應到由應用程式利用 open 函式得到而傳送 過來的 file descriptor fd，而 cmd 與 arg 則是由使用者所自行設定所想 傳送之資料，由於 device 可以運作多種不同動作(如開啟、關閉、寫入、 讀取等)，而其中 cmd 就是用來選擇我們所想要執行之動作，我們可以 在 Module 中利用 switch 敘述對應所傳進來之指令，並執行我們所要執 行之動作。arg 則為我們執行此動作時所需要之資料內容。圖 4-5 為將 module 插入 kernel 後利用應用程式將 mysql 資料傳送給 module 之畫面。. -52-.
(62) 圖 4-5 module 插入及 mysql 資料傳送. 4.2.5 記憶體使用 為了有效率的使用記憶體，當資料傳入到 Kernel 中時，必須有效率 的進行存放。所以我們在 Kernel 中採用 Link List 連結串列的資料結構 進行比對資料的存放，如圖 4-6 所示。 在函式中的資料內容，指向一個連結串列的位址，而在串列中的一 個節點裡，包含著資料的存放位址與下一節點資料所在的位址，經由這 樣的方法，我們把所有的資料內容串連存放在記憶體中。 當封包由網路卡接收，經過我們所登錄的 hook 點後，Module 便會 從記憶體中取出此與封包來源位址所對應之 Hop count，進行比對動作， 以決定是否丟棄此封包。. -53-.
(63) 圖 4-6 Memory Usage. 圖 4-7 及圖 4-8 為我們在 module 中進行封包檢測時，利用 printk 指 令將封包資料與資料庫資料比對過程結果顯示出來之畫面。. 圖 4-7 過濾模組比對畫面(a). -54-.
(64) 圖 4-8 過濾模組比對畫面(b). -55-.
(65) 5. 實驗結果與評估 我們利用 Linux 作為實驗平台，並在其上建置本研究之系統，搭配 Mysql 與系統做資料的存取連結。系統之建置環境為 CPU Pentium 4 2.0 GHz；256 MB RAM；Linux Kernel 2.4.20；Mysql-3.23。 在實驗中，我們將對此系統發送封包進行兩個階段的系統測試，分 別計算本系統之誤判率及識別率之高低。另外，並使用封包監聽軟體與 流量分析軟體監控過濾模組載入前與載入後本機之封包流量數與連線 狀態，使我們能更加清楚本系統之封包流出入狀態。. 5.1 Hop Count 檢測 AHCT 資料庫的準確性是影響 HCFS (Hop Count Filter System) 最關 鍵的地方。根據文獻，大多數的 routing 路徑大多持續數天到一個禮拜， 而路徑 Hop Count 期望值的變動也是非常小[20][35]，這樣的結果使得 系統的可信賴度增高。在實驗中，我們藉由 HC 探測模組取得本機與各 IP 網段間之樣本 Hop Count [1]。探測了近 611,000 個網段的 Hop Count 資料。圖 5-1 為我們所取得之 Hop Count 分配統計圖。我們將以此資料 為系統之比對樣本，在資料更新的一個星期內，對系統進行接下來之實 驗。. -56-.
(66) 資料庫 Hop Count 分配. 網段數 樣本Hop Count 數. 80000 70000 60000 50000 40000 30000 20000 10000 0. 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 Hop Count. 圖 5-1 資料庫內樣本 Hop Count 資料分配圖. 5.2 誤判率分析 在第一階段的實驗，我們所要檢測的部份為系統對於正常封包之誤 判情形。實驗中，我們將不發送任何偽造的封包給系統，而是由網路上 接收所流進的封包，意即系統所接收到的皆是在網路上流動的正確封 包，藉此判斷系統的 False-Positive 誤判情形，而給予最佳的誤差容許範 圍，也就是表 3-3 AHCT 欄位中之 Range 值，以減少系統的誤判率。圖 5-2 為系統所接收封包之 Hop Count 分配圖，圖 5-3 為經實驗後不同容 許誤差範圍值下各個 Hop Count 錯誤判斷的次數。實驗中，我們在固定 週期以不同的封包數計算系統在不同容許誤差範圍下對於正常封包之 誤判率，圖 5-4 為不同封包數時，系統之誤判率表現。. -57-.
(67) 流入封包 Hop Count 分配 封包數 8000. 流入封包. 6000 4000 2000 0 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 Hop Count. 圖 5-2 流入封包 Hop Count 分配圖. 封包數. 不同容許範圍下封包誤判次數. 1000 900 Range 0. 800. Range 1. 700. Range 2. 600. Range 3. 500. Range 4 Range 5. 400 300 200 100 0 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 Hop Count. 圖 5-3 不同容許範圍之系統誤判率. -58-.
(68) 不同封包數時之系統誤判率. 誤判率 35 30. Range 0. 25. Range 1. 20. Range 2. 15. Range 3. 10. Range 4 Range 5. 5 0 5000. 10000 15000 20000 30000 40000 50000 53333. 封包數. 圖 5-4 不同封包數時之系統誤判率. 表 5-1 各容許誤差範圍之封包誤判率 單位：封包. 誤差 容許範圍. 誤判 封包數. 正確判斷 封包數. 總共 封包數. 誤判率. 容許範圍 0. 16,300. 37,033. 53,333. 30.56 %. 容許範圍 1. 8,307. 45,026. 53,333. 15.57 %. 容許範圍 2. 5,630. 47,703. 53,333. 10.55 %. 容許範圍 3. 4,061. 49,272. 53,333. 7.61 %. 容許範圍 4. 3,204. 50,129. 53,333. 6.00%. 容許範圍 5. 2,321. 51,012. 53,333. 4.35%. 5.3 識別率分析 這一階段的實驗，我們以不同的 Hop Count 誤差範圍值去承受對系 統之 DDoS 攻擊測試，分別討論在不同的誤差範圍值下，系統對於偽造. -59-.
數據
![圖 1-1 1995 年到 2004 年漏洞數目 (資料來源 CERT/CC) 圖 1-2 1995 年到 2004 年安全回報數目 (資料來源 CERT/CC) 1.2 研究動機與目的 而近年來由於阻斷服務攻擊 (DoS/DDoS) 的出現，更是使得網際網 路上的各種服務產生莫大的危機，根據 2004 CSI/FBI的電腦罪案及安全 調查的研究結果顯示[7]，DDoS 攻擊所產生的金額損失達兩千多萬美 元，在所有的類型中排名第二，再再都顯示DDoS攻擊之嚴重性。](https://thumb-ap.123doks.com/thumbv2/9libinfo/9012052.297910/11.892.200.701.153.802/研究動服務產生的危機根CSIFBI電腦罪案及安調查研究結果攻擊所重性.webp)
+7
相關文件
* All rights reserved, Tei-Wei Kuo, National Taiwan University,
– stump kernel: succeeded in specific applications infinite ensemble learning could be better – existing AdaBoost-Stump applications may switch. not the
1 Embedding Numerous Features: Kernel Models Lecture 1: Linear Support Vector Machine.
2 Distributed classification algorithms Kernel support vector machines Linear support vector machines Parallel tree learning.. 3 Distributed clustering
2 Distributed classification algorithms Kernel support vector machines Linear support vector machines Parallel tree learning?. 3 Distributed clustering
Conducting binary morphological operations: dilation, erosion, opening, closing and hit-and-miss.. Dynamic gray morphological operation kernel assignment with color depth showing
建模時，若我們沒有實際的物理定律、法則可以應用，我們 可以構造一個經驗模型 (empirical model) ，由所有收集到
From Remark 3.4, there exists a minimum kernel scale σ min , such that the correspondence produced by the HD model with the kernel scale σ ≥ σ min is the same as the correspondence
