P2P主動防禦系統之設計與實作

Transcription

1 國立交通大學 理學院網路學習學程 碩士論文 P2P 主動防禦系統之設計與實作 The Design and Implementation of Peer to Peer Network Intrusion Prevention System 研究生 : 劉建德 指導教授 : 蔡文能教授 中華民國九十八年五月

2 P2P 網路主動防禦系統之設計與實作 The Design and Implementation of Peer to Peer Network Intrusion Prevention System 研究生 : 劉建德 指導教授 : 蔡文能 Student:Jiamn-Der Liu Advisor:Wen-Nung Tsai 國立交通大學 理學院網路學習學程 碩士論文 A Thesis Submitted to Degree Program of E-Learning College of Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Master in Degree Program of E-Learning May 2009 Hsinchu, Taiwan, Republic of China 中華民國九十八年五月

3 P2P 網路主動防禦系統之設計與實作 學生 : 劉建德 指導教授 : 蔡文能 國立交通大學理學院碩士在職專班網路學習組 摘 要 P2P(Peer to Peer) 網路自 90 年代末開始崛起, 隨著近期 P2P 應用範圍越來越廣泛, 相對亦衍生出不少資安問題, 諸如著作權 頻寬問題 病毒偽檔 個人隱私等 教育部於 2008 年正式行文各級學校禁止使用 P2P 軟體進行非法檔案傳輸, 然而 P2P 軟體大量使用動態連接埠, 傳統 Layer3 防火牆已經無法有效阻擋其連線 本研究針對此問題, 以自由軟體為基礎, 設計一套傳輸層的防禦的方式 ( 稱之為 T4-terminator,T4 代表 Transport Layer4), 並引用兩套應用層的防禦套件 (L7-filter IPP2P), 證明能有效禁止 P2P 連線行為 另外, 本研究以免費軟體建構出測試環境, 分別對三套防禦系統進行效能測試, 最後分析其優缺點, 提供網管人員管理 P2P 網路之參考 關鍵字 :P2P IPS Linux L7-filter IPP2P T4-terminator Benchmark i

4 The Design and Implementation of Peer to Peer Network Intrusion Prevention System Students:Jiamn-Der Liu Advisor:Wen-Nung Tsai Degree Program of E-Learning College of Science National Chiao Tung University ABSTRACT P2P(Peer to Peer)applications have emerged since late 1990s. However, the widespread adoption of P2P applications lately have accounted for some concerns about information security, such as copyright bandwidth virus individual privacy and so on. In 2008, Ministry of Education in Taiwan composed an official document, which stated schools at all levels should forbid the illegal usage of P2P file transfer. However, since P2P applications used dynamic ports in a large amount and thus the traditional Layer3 firewalls were unable to block them. To resolve this problem, we designed an IPS based on transport layer inspection to drop P2P traffic.we named our IPS as T4-terminator(T4 for Transport Layer4).We also studied two other IPS,L7-filter and IPP2P,which are baesd on Open Source software. Furthermore, we also established a benchmarking environment with freeware, which is used to evaluate the performance of these approaches. The conclusions could offer a reference to MIS people for managing P2P network. Keywords:P2P IPS Linux L7-filter IPP2P T4-terminator Benchmark ii

5 誌 謝 這篇論文能夠順利完成首先要感謝蔡文能老師細心的指導, 蔡老師提綱挈領的功力高強, 總是能輕易點出我疏漏之處, 並指導我許多做研究的方法, 令我受益匪淺 再者感謝我老鄰居兼老學長林盈達老師, 提供不少寶貴的參考資料, 對我實驗設計有很大的幫助 其次在寫論文這一年, 有許多朋友提供我不少協助, 在此一併感謝 : 瑛旗 佳倫 裕峰 阿華 興能 ; 以及同研討室的金庭, 彼此砥礪督促, 論文才能如期付梓 最後謝謝我父母的鼓勵, 太太及岳父母協助我照顧寶寶, 因為你們的支持與包容, 我才可以無後顧之憂地完成學業 iii

6 目 錄 摘要... i ABSTRACT... ii 誌謝... iii 目錄... iv 表目錄... vi 圖目錄... vii 第一章緒論 研究背景與動機 研究方法與範圍 論文架構... 3 第二章背景知識 TCP/IP 與防火牆 TCP/IP 基本概念及運作方式 防火牆技術分類 IDS/IPS Netfilter/IPTables Netfilter 模組 IPTables 模組 L7-filter 與 IPP2P L7-filter classifier IPP2P classifier P2P 的演進與運用 P2P 的運作架構 集中式架構 (Centralized) 分散式架構 (Decentralized) 混合式架構 (Hybrid) 第三章相關研究 封包特徵辨識法之研究 (Signature-Based) 應用層特徵 (Application Layer Signature) 辨識 SNORT 入侵偵測系統規則辨識 連線行為辨識法之研究 (Behavior-Based) iv

7 3.2.1 傳輸層 (Transport Layer) 的辨識 封包重送的辨識法 (Based on the Content Redistribution) 應用層防火牆之效能改善 第四章實驗設計 模擬 (simulation) 或仿真 (emulation) 封包錄製 P2P 連線軟體的選擇 錄製工具 錄製方式 封包重播 效能測試 第五章系統實作與效能評估 實驗環境 實驗方法與步驟 實驗一 :T4-terminator 實驗二 :L7-filter classifier 實驗三 :IPP2P classifier 實驗結果與效能評估 Throughput Response Time CPU Utilization 分析與比較 第六章結論與未來方向 研究成果 未來方向 參考文獻 v

8 表目錄 表 2-1 核心版本與對應之防火牆機制... 8 表 2-2 IPTables 內建之 TABLE 及功能 表 2-3 L7-filter 的 pattern file 範例 表 2-4 L7-filter 的 QoS 範例 表 2-5 IPP2P 的 QoS 範例 表 2-6 P2P 應用領域 表 3-1 常見 P2P 連線的封包特徵 表 3-2 Port-based 與 Signatured-based 辨識結果之比較 表 3-3 SNORT Rules for OpenNap 表 3-4 SNORT Rules for WinMX 表 3-5 SNORT Rules for WinMX 表 3-6 同時使用 TCP/UDP 的非 P2P 應用程式 表 3-7 封包重送辨識法的準確率及誤判率 表 3-8 STATE 目標函數之參數 表 3-9 三種不同大小封包的測試數據 表 4-1 IPTables L7-filter Rules of packet capturing 表 4-2 錄製 15 分鐘後的封包總量 表 5-1 硬體設備與作業系統規格表 表 5-2 Web Server 五個 ISO 檔案 表 5-3 T4-terminator Rules 表 5-4 L7-filter Rules 表 5-5 IPP2P Rules 表 5-6 Throughput of different Packet Size 表 5-7 Response Time of different Packet Size 表 5-8 統計 500 秒 Burst Mode 封包重播之次數 表 5-9 CPU Utilization without Burst Mode 表 5-10 CPU Utilization with Burst Mode 表 5-11 三種 P2P 主動防禦方式之比較 vi

9 圖目錄 圖 2-1 OSI 與 TCP/IP 模型之對照... 5 圖 2-2 封包傳遞的過程... 6 圖 2-3 封包過濾式 Layer3 防火牆... 7 圖 2-4 狀態檢測式 Layer7 防火牆... 7 圖 2-5 Netfilter 在核心的位置及 5 個檢查點... 9 圖 2-6 集中式 P2P 架構 圖 2-7 分散式 P2P 架構 圖 2-8 混合式 P2P 架構 圖 3-1 {IP,port}pairs of Host A 圖 3-2 PTP 演算法與封包分析法的準確率比較 圖 3-3 PTP 演算法的誤判率 圖 3-4 BitTorrent 下載與上傳的模擬圖 圖 3-5 Content_hash_table 的表格內容 圖 3-6 演算法虛擬碼 圖 3-7 具狀態檢測的 Netfilter 圖 4-1 Microsoft Network Monitor 執行畫面 圖 4-2 Flowchart of packet capturing 圖 4-3 Nulog 的執行畫面 圖 4-4 封包錄製配置圖 圖 4-5 Packet Player 操作畫面 圖 4-6 Qcheck 執行畫面 圖 4-7 Localhost to Remote 效能測試圖 圖 4-8 Remote to Remote 效能測試圖 圖 5-1 實驗環境配置圖 圖 5-2 T4-terminator flowchart 圖 5-3 L7-filter Rules flowchart 圖 5-4 IPP2P Rules flowchart 圖 5-5 Throughput of different Packet Size 圖 5-6 Response Time of different Packet Size 圖 5-7 CPU Utilization without Burst Mode 圖 5-8 CPU Utilization with Burst Mode vii

10 第一章緒論 P2P(Peer to Peer) 技術尚未出現之前, 網際網路運作模式多採主從 (client /server) 架構 在 90 年代末 P2P 崛起, 打破了這個傳統架構 ; 且隨著近年來 P2P 的蓬勃發展, 它所消耗的頻寬幾乎佔了學術網路或 ISP 業者大半的資源 ; 此外, 尚有智慧財產權等相關資安議題等待處理 通常 ISP 業者會採用限制上傳速率的方式以降低 P2P 的衝擊, 然而中小學環境與企業不同, 中小學學生處於未成年階段, 但是 P2P 網路上卻充斥著良莠不齊的資訊, 這些未經篩選的資訊容易對青少年學生身心造成不良影響 另外, 教育部亦明文禁止校園使用 P2P 軟體, 因此網管人員必須設法阻擋 P2P 連線 無論採用阻擋或者限制連線速率, 都必須先準確的辨識出 P2P 連線, 才有辦法進行管理 P2P 剛開始發展時, 各軟體大多使用固定的 TCP 或 UDP 埠號, 因此很容易辨識 隨後 P2P 很快進化成連結埠供使用者自行設訂的方式, 甚至使用動態連結埠或者 Web port 以躲過偵測, 因此使得辨識工作變得困難 本研究以自由軟體為基礎, 整合出三種不同的主動防禦方式, 能夠有效地阻擋 P2P 的連線, 還給中小學學術網路乾淨的空間 1.1 研究背景與動機 P2P 是種分散式的網路技術, 在 P2P 網路中每台電腦同時扮演 Client 及 Server 的角色, 不需透過中央伺服器就可以對等地互相分享資源, 但此一劃時代的革命技術, 雖然帶來了檔案交換的新氣象, 卻也產生以下資安及著作權問題 : 1 頻寬危機:P2P 的搜尋洪流 (Query Flooding) 及上下載連線速率對等的方式, 使得頻寬迅速被佔滿, 造成網路壅塞 2 著作權問題:P2P 鼻祖 Napster 問世不久後, 就遭到美國唱片業協會 (RIAA) 提出告訴, 最後被迫終止服務 自 Napster 敗訴之後,P2P 著作權訴訟大戰開始在世界各國點燃 2001 年成功大學的學生下載 MP3 事件, 最後財團法人國際唱片業交流基金會 IFPI 雖然撤告, 但卻沒有為學術網路不當使用 P2P 的問題劃下句點 2005 年台北地院對當時經營 Kuro[21] 的飛行網判決有罪, 隔年 9 月飛行網以 3.8 億元與 IFPI 達成民事和解 2005 年當 Kuro 多位員工遭判刑時, 全球數碼的 EzPeer[20] 卻獲判無罪, 成為全球唯一被判無罪的業者,EzPeer 旋即在 2006 年 6 月與 IFPI 達成和解, 並將品牌及服務轉讓給另一家公司, 當時號稱是全球 1

11 第一家華人合法 P2P 音樂下載網站 結果在 2008 年, 改版後的 EzPeer Plus 侵權問題仍舊嚴重, 經舉發後第二度遭到台北地檢署起訴, 官司目前仍在訴訟中 2009 年 4 月, 台灣最火熱的 P2P 軟體 FOXY 涉及侵權逾五十八億元, 負責人遭板橋地檢署起訴, 可見 P2P 衍生而來的侵犯著作權問題相當嚴重 3 資料外洩: 許多 P2P 使用者安裝軟體後不懂設定, 造成硬碟資料全部被分享出去 新聞報導如軍方演習機密資料 警方筆錄 用戶帳號密碼 情侶自拍照等, 均在使用者不知情的狀況下被分享出去, 隱私完全暴露在網路上 4 病毒與後門程式: 部分 P2P 軟體缺乏檔案驗證或者評分回饋機制, 因此網路上充斥許多惡意程式, 卻是以假檔名的方式欺騙使用者下載, 以致使用者在不知情的狀況下中毒, 成為殭屍電腦, 或遭植木馬盜帳號 密碼者不知凡幾 目前全球最大的 P2P 用戶的軟體是 KaZaA[24], 但在台灣現今最火紅的 P2P 軟體非 FOXY[16] 莫屬,FOXY 採用 Gnutella[37] 分散式協定, 它最大特色是快速 容易使用, 除了在台灣大受歡迎外, 香港 澳門亦有大量的用戶 這波 FOXY 的熱潮也蔓延到國中小校園網路, 因為它找網路上的檔案就像使用 Google 搜尋一樣容易, 並不需要像 BitTorrent[17] 必須先至相關論壇取得種子, 此外操作介面也比 edonkey[19]/emule[18] 更簡單, 下載資料又不像 Kuro 及 EzPeer 需付費, 再加上用戶眾多下載檔案相當快速, 於是許多國中小學生在無師自通下, 學會了安裝 FOXY 來下載非法資料 國中小的學生均處未成年階段, 身心發展尚未臻健全,P2P 網路上充斥著色情 盜版 病毒等良莠不齊的資訊, 學生可能因為好奇而下載成人影片觀看, 而導致性觀念偏差 班級電腦也常因為學生隨意安裝 P2P 軟體, 在不知情的狀況下, 下載夾帶病毒的檔案而導致系統損毀, 讓網管人員疲於奔命 ; 或者下載資料時佔用太多頻寬, 拖垮學校網路效能 另外, 採用 P2P 傳輸技術的 IM(Instant Messenger) 軟體如 MSN Messenger 及 Yahoo 即時通也讓學生趨之若鶩 ; 通常教授資訊課程時, 許多學生都會偷偷安裝通訊軟體來聊天, 學習成效因而大打折扣 IFPI 於 2007 年 11 月 13 日發函教育部, 正視學術網路的非法下載的問題 ; 教育 1 部也在 2008 年正式發文要求各級學校確實清查並移除 P2P 軟體, 所以網管人員必須對學校 P2P 連線設法加以限制, 避免後續衍生的相關問題 1 教育部民國 97 年 5 月 8 日台電字第 號函, 有鑑於不當檔案傳輸行為對資訊安全造成嚴重危害, 要求各校清查非公務用的 P2P 分享軟體, 並確實移除 2

12 1.2 研究方法與範圍 本研究設定在國中小學術網路, 以目前中小學學生最常使用的 P2P 軟體作為研究對象 另者因為中小學經費普遍不足, 故本研究以 Open Source 的 Linux 為防火牆主體 由於 P2P 軟體具有動態選擇連接埠的特性, 傳統 Layer3 的防火牆無法準確判斷, 必須加上 Layer7 的封包檢驗才能有效辨別連線, 所以本研究搭配同屬開放原始碼的 L7-filter 及 IPP2P 來達成應用層主動防禦的目標 再者部分 P2P 軟體提供加密連線, 或者具備模糊運算技術, 使得應用層封包呈現混亂的內容, 無法準確辨識, 本研究亦提出一套 Layer4 的防禦方式 ( 稱之為 T4 terminator,t4 for Transport Layer4), 同樣也能達到阻擋的效果 1.3 論文架構 本論文共分六章節, 第一章為研究動機與目的, 第二章介紹相關背景知識, 包括 TCP/IP 理論與防火牆分析 Netfilter/IPTables 的運作方式 L7-filter 與 IPP2P 兩套外掛模組 P2P 的演進 應用領域與運作架構 第三章探討與本研究相關的五篇期刊論文, 分成以 Signature-Based 及 Behavior-Based 兩種不同方式來辨識 P2P 連線, 最後是應用層防火牆的效能改善方法 第四章提出實驗設計, 說明如何利用錄製的封包, 控制在封閉的環境下進行實驗 第五章分析比較三種不同 P2P 防禦方式下, 系統所呈現的效能及優缺點 第六章為結論及未來的研究方向 3

13 第二章背景知識 本章介紹與論文相關的技術及背景知識,2.1 節介紹 TCP/IP 的技術及防火牆的種類及特性 ;2.2 節介紹 Linux 核心及 Netfilter 與 IPTables 的相互應用 ;2.3 節為論文實驗採用的 L7-filter 及 IPP2P 兩套擴充程式 ;2.4 節為 P2P 的演進及運用 ;2.5 為常見 P2P 運作架構 2.1 TCP/IP 與防火牆 TCP/IP 是目前網際網路應用最廣泛的協定, 它具備強大的網路連結能力及免費開放的特色, 因此越來越多作業系統都將它列為預設的網路協定 無論傳統防火牆或者應用層防火牆, 甚至於 IDS 或者 IPS 系統, 都是架構在 TCP/IP 的技術上面發展而來的 本節先介紹 TCP/IP, 接著說明防火牆如何在 TCP/IP 上面運作 TCP/IP 基本概念及運作方式 1977 年, 國際標準組織 (ISO,Internetational Standard Organization) 開始發展一套標準化之通訊協定架構 於 1984 年頒布了 OSI(Open System Interconnection Reference Model) 基本參考模型, 訂定七個層次之功能標準, 它規範了通信協定 資料傳輸 封裝及接收的規則 OSI 七層由上而下分別為 : 應用層 展示層 會議層 傳輸層 網路層 資料連結層 實體層 網際網路的先驅 : 美國高級研究計畫署 (ARPANET,Advanced Research Project Agency NETwork), 最初是採用主機對主機 (Host-to-Host) 的網路控制協定 (NCP, Network Control Protocol),1974 年後 TCP/IP(Transmission Control Protocol /Internet Protocol) 逐漸取代 NCP 協定,1983 年 TCP/IP 成為網際網路的標準通訊協定,1990 年代中期網路的蓬勃發展,TCP/IP 成為全世界被利用最廣的通信協定 TCP/IP 模型共分為四層, 由上而下分別為 : 應用層 傳輸層 網路層 連結層 4

14 應用層 Application Layer 展示層 Presentation Layer 會議層 Session Layer 傳輸層 Transport Layer 網路層 Network Layer 資料連結層 Data Link Layer 應用層 Application Layer 傳輸層 Transport Layer 網路層 Network Layer 連結層 Link Layer 實體層 Physical Layer 圖 2-1 OSI 與 TCP/IP 模型之對照 上圖為 OSI 七層及 TCP/IP 整合為四層之比較, 可以看出 OSI 七層模型, 在實作應用上, 某些層級常會被整合在一起, 因此原理及概念與 TCP/IP 四層是一樣的 以下就 TCP/IP 四層之功能與任務簡介 : 1 應用層: 應用層通訊協定主要在定義點對點之間資料交換的方法, 常見的協定如 HTTP HTTPS SMTP POP3 FTP SSH TELNET 等 2 傳輸層: 定義資料傳遞的方法, 並規範兩個通訊協定, 分別是 TCP 及 UDP, 如下說明 : (1)TCP(Transmission Control Protocol):TCP 連線起始會先進行 三交握 的動作, 當接受方收到傳送方傳來訊息時, 會送出一個確認訊息給對方, 傳送方會等到收到確認訊息後, 才會繼續傳送資料 傳送過程會檢查資料完整性及區段順序, 因此 TCP 協定是可靠的連線方式 (2)UDP(User Datagram Protocol):UDP 協定在傳送過程中, 不會檢查資料的完整性, 允許資料遺失, 而且不管資料到達接受端的先後順序, 因此如 DNS 查詢 Multicast Broadcast VoIP 等, 在傳輸資料發生遺漏時, 並不會有太大影響, 才會使用 UDP 協定 由於兩個傳輸協定不同的特性, 對一般 P2P 軟體來說, 檔案查詢或者查詢回覆多半使用 UDP 協定, 而檔案交換則採用 TCP 協定 3 網路層: 用在定義 IP(Internet Protocol) ICMP(Internet Control Message Protocol) ARP(Address Resolution Protocol) RARP(Reverse Address Resolution Protocol) 四種協定, 並定義出封包路由 (Routing) 的方法, 讓不同網域的兩台電腦, 可以跨越網路交換資料 4 連結層: 該層就是 OSI 的 Data Link Layer, 也就是網路最基礎的建設, 包括乙 5

15 太網路 (Ethernet) 光纖 ( Fiber) 無線網路 (Wireless) 訊框傳送 (Frame Relay) 點對點實體網路(PPP), 連結層最主要的目的在傳送及接收實體層所傳送的光電訊號 圖 2-2 封包傳遞的過程 上圖為封包 (Packet) 傳遞示意圖, 當 Peer A 要和 PeerB 聯絡時, 會把應用層資料交給下一層來處理 傳輸層接到應用層交下來的資料, 會把它視為一個 Payload Data, 然後幫它加上一個傳輸層的控制表頭, 接著再往下一層傳遞, 最後由連結層封裝後, 把封包傳送出去 對方收到資料後, 反覆剝去表頭及向上傳遞 Payload, 最後到達應用層, 完成了的交談 防火牆技術分類 防火牆依過濾技術可分為封包過濾 (Packet Level Filter) 及應用層過濾 (Application Level Filter) 兩類, 各有其使用時機與優缺點, 分述如下 : 1 封包過濾防火牆: 即為傳統的 Layer3 防火牆, 檢查最小單位為 一個封包, 單純處理封包 IP 及 PORT 的資訊, 效能極高且應用廣泛, 但缺點為檢查範圍只有一個封包, 因此無法執行精準的過濾動作 6

16 圖 2-3 封包過濾式 Layer3 防火牆 2 應用層防火牆: 因為 Layer3 防火牆無法完整過濾進出 Router 的資訊, 因此發展出 Layer7 的防火牆, 通常此類防火牆會具有狀態檢測 (Statefull Inspection) 的機制, 讓 filter process 能夠完整分析連線資訊, 達成安全控管的目的 但此類防火牆最大問題在效能較低, 而且過濾協定必須定期更新, 才能辨識各式各樣的連線 圖 2-4 狀態檢測式 Layer7 防火牆 7

17 2.1.3 IDS / IPS IDS(Intrusion Detection System) 特色在於 分析 與 警示 就如同 sniffer 軟體一樣監聽流過的封包, 當發覺有不正常流量, 旋即發出警訊通報系統管理者 但通常在發出警訊之時, 病毒或者駭客正逐步攻陷了整個網域, 等到管理者收到通報時, 可能傷害已經造成了 在 OpenSource 的 IDS 當中, 最著名的就是稍後會提及的 SNORT[28] IPS(Intrusion Prevention System) 與 IDS 最大的不同在於 IPS 能夠在偵測到入侵的同時進行防禦 IPS 最大的特色就是 深層檢測 (deep inspection) 和 在線模式 (in-line mode), IPS 通常採用應用層的防火牆, 以便偵測更完整的入侵資訊, 一旦發現有異常網路行為, 即可丟棄攻擊封包 無論執行 IDS 或 IPS 都必須降低誤判 (false postive) 及漏判 (false negative) 的問題, 此外如果 IDS / IPS 主機運算能力無法負荷高速網路, 勢必拖垮整個連線效能 2.2 Netfilter/IPTables Linux Kernel 第一代的防火牆是移植自 BSD 的 ipfw, 後來在 Kernel 2.0(1996 年 ) 後, 開發了 ipfwadm 的工具程式, 提供使用者更容易設定過濾規則 到了 Kernel 2.2(1998 年 ) 推出了第二代的 ipchains, 大幅提升防護功能 Kernel 2.4 之後, 重新設計防火牆架構, 開發出第三代 Netfilter/IPTables 模組, 這版本的防火牆開始提供狀態檢測的機制, 而且因為它開放程式碼, 讓許多工程師投入外掛模組的編寫, 其強大 穩定 高效能的特性, 比起商用防火牆有過之而無不及 Kernel Version Kernel 2.0 Kernel 2.2 Kernel 2.4 / 2.6 Firewall Engine ipfwadm Ipchains Netfilter / IPTABLES 表 2-1 核心版本與對應之防火牆機制 8

18 2.2.1 Netfilter 模組 如圖 2-5 所示,Netfilter[14] 以模組的型態存在 Linux 核心中, 封包進入核心後, 提供 5 個檢查點 (5 Hook points), 分別是 PRE_ROUTING(#1) LOCAL_IN(# 2) FORWARD(#3) LOCAL_OUT(#4) POST_ROUTING(#5) 每一個 Hook 都可以被上層的許多模組註冊使用, 註冊時可以指定優先順序, 系統會依照順序決定過濾的順序 圖 2-5 Netfilter 在核心的位置及 5 個檢查點 PRE_ROUTING: 封包在進入系統的檢查點 ;POST_ROUTING: 封包離開系統的檢查點 ;LOCAL_IN: 封包進入本機, 給上層程式處理的檢查點 ;LOCAL_OUT: 本機程式要傳送資料出去的檢查點 ;FORWARD: 是當封包要做轉送時會經過的檢查點 當有封包進入檢查點時, 檢查點會啟動註冊的決策模組, 如 Connection Tracking L7-filter IPP2P 等 同時也 Netfilter 提供五種封包狀態回傳值, 交給檢查點的決策模組使用, 再藉由模組回傳之結果來決定封包的命運 五種回傳值如下所示 : 1 NF_ACCEPT : 允許該封包送往下個 Hook 2 NF_DROP: 拋棄該封包, 不再繼續傳送 3 NF_STOLEN: 由檢查函式接管封包, 不再繼續傳送 4 NF_QUEUE: 將封包放至佇列 (queue) 中, 由上層的 Userspace 應用程式處理 5 NF_REPEAT: 封包再一次進入這個 Hook 檢查 9

19 2.2.2 IPTables 模組 Netfilter 位在下層系統核心,IPTables 則是提供使用者操作的上層防火牆程式 如圖 2-5 及上個段落所述明,IPTables 提供使用者向 Netfilter 架構中的 hook 點作註冊動作, 所以每個通過核心的網路封包便可以送到 IPTables, 藉使用者定義 IPTables 規則來決定封包命運 目前 IPTables 內建了 4 個 TABLE, 各個 TABLE 的功能用途簡介如下表 : TABLE Chain Function INPUT 執行封包過濾, 可過濾 TCP UDP Filter FORWARD ICMP MacAddress 封包 OUTPUT PREROUTING NAT(Network Address Translation) Nat POSTROUTING OUTPUT 含 SNAT 及 DNAT, 可以提供 IP 偽裝, 或者當成企業 DMZ 防火牆 PREROUTING mangle INPUT FORWARD OUTPUT POSTROUTING 可經由該機制修改封包內容 Raw PREROUTING OUTPUT 加快穿越防火牆的速度, 提高效能 表 2-2 IPTables 內建之 TABLE 及功能 2.3 L7-filter 與 IPP2P Netfilter/IPTables 封包分析處理預設停留在 Layer3 Layer4 層級, 但是現在網路應用軟體大量運用 dynamic-port, 因此必須將封包辨識提升至 Layer7, 才足以應付與日具增的 P2P 程式 L7-filter[12] 及 IPP2P[13] 是本論文實驗所使用的 Netfilter 擴充模組, 可以辨識常見的 P2P 連線 10

20 2.3.1 L7-filter classifier 在 2003 年前,L7-filter[12] 團隊原本在開發 Linux kernel 的 QoS(Quality of Service) 延伸模組, 到 2003 年底才開始投入 Netfilter 的 Layer7 延伸過濾模組的開發,2005 年初推出了 v1.0 版, 截至本論文寫作期間, 最新版本為 v2.21 除了 Kernelspace 版本外,2005 年 12 月也推出 Userspace 版本, 目前為 v0.11 版 L7-filter 是透過 V8 regular expression[38] 字串比對方式來辨識封包, 預設比對連線前 10 個封包或前 2KBytes, 此預設值可以讓使用者依需求自行更改 目前協定運作效果被區分為 :Great Good Ok Marginal Poor 五種等級, 會如此區主要是因為有些協定 ( 如 HTTP FTP SMTP) 是公開的, 此類封包內容的關鍵字可以完全掌握 但是有些協定是不公開的, 對於此類的協定只能藉由分析封包出現的關鍵字來做 pattern, 因此比較容易發生誤判, 所以運作效果不是很好的便會歸到 marginal 或 poor 這兩類 以 msn 為例, 當我們使用 msn 帳號登入時,msn client 會送出 VER1 MSNP14 MSNP13 CVR0 的封包字串給 central server 歸納出各類網路程式每次送出的封包含哪些字串後, 我們可以寫出一個 pattern file, 提供關鍵字讓 L7-filter 判斷, 提供 IPTables 做後續的處理 Msn-login ^ver [0-9]+ msnp[1-9][0-9]? *cvr0\x0d\x0a$ Msn- filetransfer ^ver [ -~]*msnftp\x0d\x0aver msnftp\x0d\x0ausr Yahoo Messenger ^(ymsg ypns yhoo).?.?.?.?.?.?.?[lwt].*\xc0\x80 表 2-3 L7-filter 的 pattern file 範例 上表列舉三個官方提供的定義檔範例, 目前 L7-filter 官網提供辨識的網路協定多達 109 種, 此外還能夠辨識 16 種檔案格式及 2 種 malware 病毒 若使用者覺得官方網站提供的寫法不妥, 或是有其他網路協定尚未被納入規範, 均可自行撰寫 pattern file 以供判斷 另外 L7-filter 已經結合了 Connection Tracking 的模組, 可以透過 -j MARK 參數配合 tc 1 指令方便地達到頻寬管理之目的 表 2-4 為對 edonkey 連線進行 Qos 的範例,set-mark 的參數可隨意設定, 之後便可交由 tc 管理 1 tc 指的是 traffic control, 為 Linux Qos 常用的 Userspace 工具 11

21 iptables -t mangle -A POSTROUTING -m layer7 --l7proto edonkey -j MARK --set-mark IPP2P classifier 表 2-4 L7-filter 的 QoS 範例 IPP2P[13] 是另一套能夠辨識 Layer7 封包的自由軟體, 顧名思義即針對 P2P 連線所設計 此套件的運作方式和 L7-filter 相似, 都是掛在 Netfilter/IPTables 上的延伸擴充模組, 亦採用 String-match 的方式進行比對 不同的是 L7-filter 是有一個額外的 pattern file,netfilter 會依照 IPTables 的指令去 patter file 呼叫適合的定義檔比對 ; 但是 IPP2P 則是將 String-match 的內容以 16 進位碼直接寫入程式碼中, 安裝時直接編譯到模組內 相較於 L7-filter 的更新快速,IPP2P 維護頻率顯得少很多, 本論文寫作時官方網站的最新版本尚停留在 2006 年 9 月的 v0.8.2 版, 支援的 kernel version 較少, 太新或太舊的核心會造成編譯失敗 官方版本支援辨識的 P2P 協定有 9 種, 若想要自行新增協定, 必須先修改 source code, 再重新編譯後才能夠執行 IPP2P 不具有 Connection Tracking 的功能, 連線比對採 per packet match 的方式, 不像 L7-filter 只比對連線最前面的數據 也因為這特性, 使得 IPP2P 不容易對整個連線進行頻寬管理 如下表所示, 必須額外藉助 CONNMARK 模組來儲存 (Rule#03 Rule#04) 及還原 (Rule#01 Rule#02) 整個連線後, 才能交由 tc 指令管理 01# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark 02# iptables -t mangle -A PREROUTING -p tcp -m mark! --mark 0 -j ACCEPT 03# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1 04# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark 表 2-5 IPP2P 的 QoS 範例 12

22 2.4 P2P 的演進與運用 在 1998 年就讀於美國東北大學一年級的 Shawn Fanning 開發出 Napster, 同時也開啟了 P2P 技術的濫觴, 隨後 Napster 版權官司的敗訴, 並未停止 P2P 技術的發展 剛開始的 P2P 軟體多半使用固定的 port 來做資料傳送,2000 年之後的 P2P 大量使用動態 port, 甚至採用連線加密技術以躲避偵測 P2P 應用上也越來越多元, 包括檔案傳輸 串流影音 即時通訊 線上遊戲 分散計算等, 說明如下 : P2P Categories Application Programs Foxy(Gnutella) BT edonkey/emule Kuro P2P File Sharing EzPeer KaZaA FastTrack WinMX MSN Yahoo Messenger Skype Google Instant Message / VoIP Talk QQ PPLive PPStream Sopcast TVAnts P2P Streaming TVUPlay SETI@home Datasynapse P2P Distributed Computing Intel philanthropic P2P program 表 2-6 P2P 應用領域 1 P2P file sharing: 運用於檔案傳遞, 傳送類型多半為影片 音樂 圖片 軟體等, 此類型的連線通常佔用 ISP 或學術網路最大量的頻寬, 且最容易侵犯到智慧財產權 2 Instant Message / Voice over IP: 早期線上交談必須透過 BBS 電子布告欄或者線上 CGI 聊天室, 後來 ICQ AOL Microsoft NetMeeting 普及後, 才逐漸轉型為 P2P 即時通訊 目前 MSN 和 Yahoo 即時通是最受台灣學生歡迎的通訊軟體, 而 Skype 採用 GIPS isac and ilbc codecs 編碼技術, 採用應用層路由 (Application Layer Routing) 的輔助方式進行 Voice over IP, 穩定清晰的音質及便宜的通話費廣受業界的喜愛 3 P2P Streaming: 串流視訊需大量且即時的資料, 才能提供穩定的畫面品質 一般 VOD(Video on Demand) 或 MOD(Media on Demand) 是採用中央伺服器提供影像, 當使用者越多, 會造成 server 的負載增加 而 P2P Streaming 技術則是運用眾多 peers 間的視訊串流互為 sources, 將 central server 的流量分散至觀看同一節目的 peers, 然後 peers 之間再共享串流, 因此當某節目同 13

23 時越多人觀看, 反而會得到越穩定的收看品質 4 P2P Distributed Computing:P2P 分散式計算計算最有名的就是 SETI@home, SETI(Search for ExtraTerrestrial Intelligence) 是美國 NASA 進行的國際性科學計畫, 台灣亦有 mirror 站台 [26], 可至網站免費下載程式, 當螢幕保護裝置啟動時, 電腦會進行協同運算, 來分析由外太空傳來的無線電波協助尋找外星智慧 14

24 2.5 P2P 的運作架構 大多數的網路服務都採用主從 (client/server) 架構, 如 FTP WEB 等服務, 當越多 client 端加入連線,server 會耗費更多運算資源及網路頻寬, 而且 client 只能被動的接受 server 所提供的資源 但是 P2P 的技術打破了這個藩籬, 每個 peer 都是對等的, 同時扮演 client 以及 server 的角色, 當越多節點加入這個網路, 每個節點所能夠得到資源會越多 P2P 運作架構可分成三類, 分別是集中式 分散式 混合式, 將於本節敘述 集中式架構 (Centralized) Napster 是這個系統架構的代表, 此類 P2P 系統通常會使用固定的 TCP port 新節點的加入首先必須連接中央索引伺服器 (index server), 然後回報其擁有的檔案列表, 隨後各節點都透過詢問中央索引伺服器來得知擁有此檔案的使用者資訊, 再依此資訊, 直接向檔案所在端點要求下載 集中式架構的優點在於實作上較簡單, 搜尋檔案快速有效率 ; 而其主要缺點在於一旦中央索引伺服器故障, 整個系統便無法運作, 而且伺服器必須處理大量客戶端的請求, 容易形成系統運作的瓶頸 圖 2-6 集中式 P2P 架構 15

25 2.5.2 分散式架構 (Decentralized) 分散式架構的代表是 Gnutella[37], 為改良第一代架構的缺點及違法問題, 此類 P2P 系統普遍採用 dymanic port, 或直接利用 HTTP 作為通信協定, 以躲過防火牆偵測 另外也不需要任何中央伺服器, 所有參與連線的端點同時扮演 server 與 client 的角色, 地位完全對等 Gnutella 系統定義了四種訊息格式 :ping pong 係用來確認身份, 而 query 及 query-replies 則用來搜尋檔案 新的端點想要加入 Gnutella 網路, 會先連結到鄰近任意節點, 並且發出 Ping 訊息來表明自己身份, 被連結到的節點會回應 Pong 訊息, 內容包括 IP Port 及分享的檔案數量及大小, 同時被連結的節點會將該 Ping 訊息以遞迴 (Recursion) 的方式繼續往它的鄰居節點廣播, 直到 TTL(time-to-live) 歸零 也因為這個方式, 很容易造成搜尋洪流 (Query Flooding), 所以如何定義 TTL 值, 或者限制遞迴的深度, 以降低頻寬被佔滿的狀況, 是分散式架構最大的挑戰 圖 2-7 分散式 P2P 架構 16

26 2.5.3 混合式架構 (Hybrid) 混合式架構 ( 如 edonkey[19] FastTrack[23] WinMX[22]) 是以分散式 P2P 為基礎, 另外參考集中式 P2P 的特點, 增加了 Supernode 這個角色 通常具有較大的頻寬及運算能力的節點會被選為 Supernode, 負責提供以它為中心之小型網路的各項服務, 包括檔案索引及暫存等, 因此讓整體網路傳輸更有效率 為了避免防火牆阻擋, 部分混合式 P2P 程式, 如 FastTrack WinMX 會採用連線加密技術, 而 emule[18] 在 v0.47b 版發表了模糊運算技術, 讓封包看起來變成毫無規律的內容, 這些方法都增加了封包辨識的困難度 圖 2-8 混合式 P2P 架構 17

27 第三章相關研究 本章就近年來諸多 P2P 辨識技術文章, 擷取與本研究相關的文章討論 分別 於 3.1 節討論封包特徵的辨識法 ;3.2 節中以 P2P 常見連線行為作為辨識法 ;3.3 節為改善 Linux 防火牆的過濾效能 3.1 封包特徵辨識法之研究 (Signature-Based) P2P 檔案分享軟體越來越盛行, 佔用的網路頻寛越來越大, 對於網管人員或是 ISP 業者必須先準確的辨別 P2P 流量, 才能對 P2P 連線進行管理 因為 P2P 技術的進步, 且應用越來越廣泛, 以往藉由 Port-Based 來判斷 P2P 流量已經不夠準確, 因此必須透過應用層封包分析技術 (Application protocol analysis) 才能達到辨識效果 應用層特徵 (Application Layer Signature) 辨識 Subhabrata Sen 等人 [1] 就目前熱門的 P2P 軟體, 如 Gnutella edonkey BitTorrent KaZaA DirectConnect 等, 分析這些軟體所使用的通訊協定及封包的內容, 歸納出各種應用程式特徵 (Application Signature), 藉以判斷此封包是否為 P2P 連線 但是在大量封包中進行字串比對需要大量的計算時間, 為了能夠在高速網路環境下快速地進行辨識, 將所定義的 P2P 軟體特徵比對方式分成兩個部分 : (1) 固定位移比對 (Fixed Offset Match): 將 P2P 軟體特徵和 TCP 封包內容中, 特定的 Byte 進行比對, 比對方式為 16 進位具體代碼 (2) 變動位移比對 (Variable Offset Match): 透過正規表示式 (Regular expression) 來比對 各連線封包特徵分析及比對方式經歸納如下表 : 連線軟體 Gnutella 封包特徵及比對方式 封包開頭字串為 GNUTELLA" GET" HTTP" 若封包開頭字串為 GET" HTTP", 則其內容必包函含下面字串 User-Agent: <name>" UserAgent: 18

28 <name>" Server: <name>" edonkey 封包開頭的第一個 Byte 為 edonkey marker, 其值固定為 0xE3 封包的第二到第四個表示封包內容的長度 DirectConnect 封包開頭的第一個字元為 $", 最後一個字元為 " 在 $" 緊接一個以空白字元結束的字串, 此字串為 DirectConnect 命令 BitTorrent KaZaA 封包的第一個 Byte, 其值為 0x19 接下來的 19 個 Bytes, 為一個長度 19 的 BitTorrent protocol" 字串 封包開頭字串為 GET" HTTP", 且封包中包含 X-Kazaa 字串 表 3-1 常見 P2P 連線的封包特徵 將定義的 P2P 軟體特徵在 Gigascope 1 中進行驗證, 結果證明應用層特徵可精確的辨別出 P2P 軟體所產的流量, 且誤判率 (False Negative) 均低於 10%, 對於 DirectConnect 甚至能做到零誤判的程度 且與 Port-Based 方法相比,Signature- Basd 對於愈常使用 non-standard port 的 P2P 軟體有愈佳的辨識效果, 尤其對於 KaZaA 高到 3.47 倍, 如表 3-2 所示 表 3-2 Port-based 與 Signatured-based 辨識結果之比較資料來源 :Subhabrata Sen,et al. [1] 1 Gigascope 為一高速網路流量監測器, 所能監測的網路流量最高可到達 OC-48(2.4Gbps) 19

29 3.1.2 SNORT 入侵偵測系統規則辨識 SNORT[28] 這套入侵偵測系統 (IDS,Intrusion Detection System) 早在 1988 年就誕生了, 為 GPL & OpenSource 模式的入侵偵測系統 2005 年被防火牆大廠 Check Point 買下後, 從此不再以 GPL 授權釋出, 但仍然維持 OpenSource 模式 使用者可至官方網站免費下載安裝軟體, 但是最新的規則庫必須花錢購買, 若單純個人測試, 官網仍免費提供比付費資料庫晚一個月的規則下載 SNORT 支援多種平台, 又具備 OpenSource 模式, 再加上規則編寫容易, 擴充性極佳, 所以廣受歡迎 [2] 採用此套軟體, 先以 WinDump 分析 P2P 程式的封包特徵, 再以自編之 SNORT rules 來驗證其準確性 文中歸納 P2P 連線的週期行為大致上歸類為以下四點 : (1)Discovering and Booting: 使用者開啟軟體登入網路, 同時尋找線上節點 (2)Sharing: 送出自己分享的檔案列表 (3)Querying and lookup: 送出檔案請求查詢, 網路上有此檔案的節點會回應 (4)Downloading:peer to peer 交換檔案 以上述方法, 分別對 OpenNap WinMX FastTrack 三套 P2P 程式進行分析 OpenNap 偵測起始狀態及登入 Server 的封包訊息,FastTrack 跟 WinMX 連線訊息有使用加密技術, 但仍然可針對一些特徵提出警訊 說明如下 : 1 OpenNap[25] (Open Source Napster Server): 該程式即為 Napster 的修正版, 同樣有 central servers 的架構, 但是這套程式與 Napster,Inc. 無關, 所使用的技術也不同 這是一種 Open Source 平台, 適用於 Unix 及 Windows 系統, 使用者可免費架設 central server, 提供 WinMX 及支援 OpenNap 的用戶登入 使用時,clients 與 servers 之間的溝通均為明碼傳送, 因而整個連線行為及封包特徵較容易分析 SNORT 規則共分六條, 整理如下表 : 編號規則名稱檢驗字串位移比對及大小 catch the server welcome answer catch the client login message catch the name of files shared by the client VERSION offset:4;depth:12 SERVER offset:11;depth:18 WinMX offset:4;nocase a 5c offset:4;depth:9 20

30 4 Alert on query submit FILENAMECONT AINS 5 alert on download requests GET 6 Alert on upload requests SEND 表 3-3 SNORT Rules for OpenNap offset:4;depth:18 offset:0;depth:3; dsize:3 offset:0;depth:4; dsize:4 2 WinMX Peer Network[22] (WPN): WinMX 連線協定較 OpenNap 複雜許多, 它不但支援登入 OpenNap 的伺服器群組, 本身也提供一套 WinMX 對等網路傳輸協定, 而且檔案搜尋 管理的功能非常強大 WinMX 本身的網路傳輸技術採用 decentralized 以及 encyrpted messages 的方式, 此外連線類型還區分兩種讓用戶選擇 : (1)Primary connections: 適合給高頻寬使用者, 具較佳搜尋效率及穩定性, 使用該方式連線即可成為 WPN 的中繼 cache server, 還可開設聊天室 (2)Secondary connections: 適用低頻寬或者用戶, 或者用戶連線被防火牆阻擋時, 採用這方法將透過其他 primary connections 的 cache servers 來進行路由 WinMX 創辦公司 Frontcode 於 2005 年接獲美國唱片業協會 (RIAA) 要求在 WinMX 加入關鍵詞過濾功能, 令使用者無法搜尋受版權保護的收費作品 在面臨法律訴訟的壓力下,Frontcode 公司終於在 2007 年 6 月底將 WinMX 官方網址關閉, 但是目前仍有不少私人架設的論壇提供升級及討論的服務 由於 WinMX Peer Network 採 TCP 加密技術傳輸, 因而增加辨識的困難 作者提出兩條 SNORT 規則, 第一條偵測 primary connection 中的某固定大小為 145 bytes 的 UDP 封包, 第二條僅偵測 secondary connection 是否建立, 如下表說明 : 編號規則名稱規則內容 1 2 alert on supernodes that answer to joining peer alert on secondary connection contacting WPN cache servers msg : WPN Primary connection detected ;dsixe:145;classtype: policy-violation msg : Probably WPN Secondary connection detected ; flow : 21

31 established;flags:pa;tag:host,1, packets,src 表 3-4 SNORT Rules for WinMX 3 FastTrack[23] FastTrack 亦採用 decentralized 以及 encrypted messages 來連線, 並且使用 supernode 的方式提供一般使用者作為 indexing server 除此之外, FastTrack 連線具有突破傳統防火牆封鎖的修正技術, 透過 supernode 的仲介, 讓防火牆背後的 storing peer 能提供檔案讓外面的 requesting peer 下載 至於下載請求則採用與 HTTP 非常類似的語法, 再加上下載檔案前的溝通都採加密連線, 增加不少判斷的困難 採用 FastTrack 協定的軟體中, 作者以最著名的 KaZaA[24] 為例 列舉出兩條規則 : 第一條規則判斷 supernode 回應使用者的 UDP flooding; 第二條判斷下載檔案時未加密的 HTTP/1.1 的字串, 並加入搜尋 KazaaClient 的字串降低誤判率 如下表說明 : 編號規則名稱檢驗字串位移比對及大小 1 alert on supernodes that answer to joining peer 28 offset:0;depth:1 4b 61 5a offset:11;depth:17 2 Alert on sending a positive response to a request for a shared file f 2f 31 2e f 4b offset:0;depth:15 KazaaClient session:printable 表 3-5 SNORT Rules for WinMX [2] 並未針對文章中提出的規則在真實網路中進行判斷準確率的檢驗, 但作者運用了規則編寫容易, 且擴充性佳的 SNORT 作為 P2P 連線偵測系統 網管人員可依照該方法自行定義規則, 用來辨識其他 P2P 連線 22

32 3.2 連線行為辨識法之研究 (Behavior-Based) 應用層封包辨識的效果是 P2P 連線辨識法中最準確的, 但是這種方法最大的問題在於 (1) 應用層防火牆處理效能較低 (2) 需隨時更新辨識資料庫 因此本節的研究以 P2P 常出現的連線行為來進行辨識, 盡量能在不減低防火牆負擔的狀況下有效的辨識 P2P 連線 傳輸層 (Transport Layer) 的辨識 第一代 P2P 軟體通常使用固定 port 進行連線, 但隨著技術進步, 現今 P2P 連線已經很難單純地透過固定連接埠來辨別 3.1 節介紹 Payload Analysis 的 P2P 辨識方法, 這種方式優點為辨識率準確, 但仍有一些限制 : (1)Throughput:Layer7 防火牆因為需大量封包比對, 與僅進行 IP 及 Port 比對的 Layer3 防火牆相比, 負擔相對提高 (2)HTTP Request: 許多 P2P 協定使用 HTTP 協定傳檔, 使我們不容易分辨 P2P 或 WEB 連線, 通常 Payload Analysis 只分析連線最前面 8~16bytes 的封包, 容易發生漏判 (False Negative) 的狀況, 如 HTTP/ Partial Content 的字串都可能在 HTTP 或 P2P 連線中產生 (3)Encryted:message 加密或先透過 SSL 的連線都將使 Payload Analysis 失效 (4)Others P2P protocols:p2p 應用廣泛, 封包辨識法無法保證能成功辨識新的協定, 必須隨時更新定義檔 為改善這些缺點,[3] 藉由觀察 P2P 常見的行為樣式 (connection pattern), 提出一套 PTP 演算法 (P2P Traffic Profiling Algorithm), 利用傳輸層的辨別, 可以不需檢查任何封包的內容, 快速地檢驗出 P2P flow PTP 演算法包含兩個原則, 分別是 TCP/UDP IP pairs 及 {IP,Port} pairs, 分述如下 : 1 TCP/UDP IP pairs: 大部分的 P2P 軟體都會同時使用 TCP 及 UDP 傳輸協定, 通常利用 UDP 來進行 traffic control queries 或 query-replies,tcp 則用來下載或上傳資料 除了 P2P 連線之外, 其他會同時用到 TCP/UDP 來進行傳輸的軟體很少, 表 3-6 列了此類軟體的 TCP/UDP port, 提供我們進行辨別時, 將這些例外 port 摒除, 避免造成誤判 23

33 表 3-6 同時使用 TCP/UDP 的非 P2P 應用程式 資料來源 :Thomas Karagiannis,et al. [3] 2 {IP,Port} pairs: 近來 P2P 網路朝向分散式 (distributed network) 或混合式 (hybird network) 網路模式發展 無論哪種模式, 當一個新節點要加入網路時, 通常會跟一些 cache servers 進行連線, 這些節點稱為 superpeers/ supernodes, 能夠把自己暫存的網路節點列表, 傳送給新節點, 以加快連線速度 當新節點與 superpeers 建立連線後,superpeers 同時也會將新節點的連線資訊傳送出去, 也就是將 IP 及連接埠 ({IP, port} pair) 廣播至整個網路中, 以便讓網路其他的節點可以與其通訊 整個連線過程如下圖所示 : 圖 3-1 {IP,port}pairs of Host A N 個不同 IPs 與 A 連線, 同時也會有 N 個不同的 foreign used ports 用來與 A 連線 資料來源 :Thomas Karagiannis,et al. [3] 利用上述的兩種原則,PTP 演算法提出的 P2P 判斷步驟如下 : (1) 辨識 source-destination IP pairs 同時使用 TCP/UDP 傳輸協定 (2) 摒除表 3-6 少數同時使用 TCP/UDP 的程式, 如 DNS NETBIOS IRC gaming streaming 等, 假設發現某連線同時使用 TCP/UDP pairs, 而且 s-d ports 沒在表中, 我們可以合理懷疑該連線為 P2P flow 24

34 (3) 接著檢驗其 {IP,Port} pairs, 如果超過 20 個連線, 且持續 5 分鐘以上, 即可斷定為 P2P 連線 最後將 PTP 演算法與封包比對法相比, 證明這種 non-payload 驗證方法相當有效, 其實驗結果如下 : 圖 3-2 PTP 演算法與封包分析法的準確率比較資料來源 :Thomas Karagiannis,et al. [3] 上線為封包比對法, 下線為 PTP 演算法, 在三種不同連線速度的網路環境檢驗, PTP 演算法準確率都極高, 即使速度高達 220Mbps( 最右圖 ), 兩者相較之下仍有超過 95% 的準確率 圖 3-3 PTP 演算法的誤判率資料來源 :Thomas Karagiannis,et al. [3] 上線為正確 P2P flows, 下線為誤判率 (False positives),ptp 演算法誤判率僅 8%~12% 該演算法乃依照 P2P 軟體在網路中連線的行為模式來判定, 其優勢有 (1) 不 25

35 用檢驗任何 payload, 提升防火牆效率 (2) 可辨識未知的 P2P 協定 (3) 辨識準確率高且誤判率低 (4) 連線加密亦能判斷 但是網路中某些連線行為模式與 {IP,Port} pairs 相同, 卻不是 P2P 的應用 例如 web server mail server 的連線行為就是 server 的連線資訊可能同時和多個相異的 {IP,Port} pairs 有關連 未來可以將這類連線透過 well-known port 排除掉, 以減低誤判率 封包重送的辨識法 (Based on the Content Redistribution) P2P 網路中, 每個節點同時扮演著 server 及 client 的角色, 因此當節點下載到某段資料之後, 通常會立刻上傳給有此檔案需求的其他節點 [4] 根據這個特性, 提出一套封包偵測方式, 可以不需要比對封包內容, 即可判斷出已知或未知的 P2P 協定 下圖以 BitTorrent 為例,Tracker 即是 supernode, 連線分享步驟概分為 (1) 當 peer1 有 file1 欲分享時, 它會把訊息傳送給 Tracker(2)Tracker 接著把這訊息通知想要下載 file1 的節點 peer2(3) 當 peer2 下載完一小片段後, 接著 peer 也 3 透過 Tracker 的仲介, 向 peer2 取得剛完成下載的片段檔案 圖 3-4 BitTorrent 下載與上傳的模擬圖資料來源 :Xing Lu,et al. [4] 在 P2P 網路中, 每個參與連線的節點至少都有一個 listening TCP port, 提供其他節點來溝通或下載資料, 雖然這個 port 是動態的, 而且每個參與連線的節點的 port number 可能都不同, 但是當節點開啟 P2P 應用程式加入連線後, 這個 port 就會維持固定, 直到本次連線結束為止 [4] 找出不同節點各自的監聽埠, 透過以圖 3-5 及圖 3-6, 來辨別 P2P flow: (1)peer_table: 我們找出所有節點的 listening port 並記錄成 peer_table, 表內容包含 <ip,port> 當 TCP 封包到達該 peer, 該封包的 <sip,sport> 或 <dip,dport> 可在 peer_table 找到, 我們記錄該封包所屬的 flow 為 P2P flow 26

36 (2)content_hash_table: 為了更新 peer_table, 當收到 TCP 封包時, 將封包最前面 k-bytes 字串的 payload 映射至 content_hash_table 當有相同的 content 被同一個節點接收後又送出, 該 content 及 flow 我們都判定為 P2P flow, 同時將該 content 的 <sip sport>s 記錄至 peer_table 中 圖 3-5 Content_hash_table 的表格內容 圖 3-6 演算法虛擬碼資料來源 :Xing Lu,et al. [4] 最後以北京清華大學學生宿舍網路為實驗環境, 進行兩次實驗, 把 content redistribution 與 signature-based 的方式互相比較, 證明該方法對 BitTorrent 及 PPLive 有極準確判斷率, 對於 Maze 及 Xuelei 準確率較低, 但總誤判率 (False Postive Rate) 均低至 1.5% 左右 如表 3-7 實驗結果所示 : 27

37 表 3-7 封包重送辨識法的準確率及誤判率 資料來源 :Xing Lu,et al. [4] Maze( 天網 ) 及 Xuelei( 迅雷 ) 均為中國大陸境內相當流行的 P2P 下載程式, 其判斷效率不佳的原因在於,Maze 是 CERNET(China Education and Research Network)[27] 常用的分享軟體, 它提供 peers 透過區網 ( 同一個 class C 或 class B) 分享檔案的功能, 類似微軟的網路芳鄰, 由於 LAN(Local Area Network) 分享的速度及效率均遠高於 WAN(Wide Area Network), 因此 peer 會在短時間內完成檔案下載工作, 不像其他 P2P 軟體, 必須得透過 WAN 端數個不同 peers 分成片段上下載 Xuelei 這套程式可提供 peer 下載 web server 的檔案, 類似像 archie 搜尋 ftp 檔案, 也因為檔案來源幾乎都是集中式的 web server, 並非 P2P 常見的分散式傳輸架構, 也因為 Maze 及 Xuelei 並沒有具備一般 P2P 網路 highly soughtafter rosources 的特性, 因此以封包重送辨識法的準確率就顯得不足 該演算法優勢為不需要透過封包比對, 即可有效辨識已知或未知的 P2P 連線, 但缺點在於端看連線過程是否加密 假設連線過程只有 message stream 加密, 而檔案傳輸過程不加密, 如 WinMX FastTrack 等, 此方法仍可有效判別 但若連線全程加密, 因為各連線之間金鑰不同, 本演算法將會完全失效 28

38 3.3 應用層防火牆之效能改善 封包進出防火牆必須進行規則比對, 傳統以 Rule-based 的 Layer3 或 Layer4 的防火牆, 當規則越來越多時, 效能會慢慢降低, 如果加上 Layer7 防火牆, 須耗費更多的記憶體及 CPU 來處理, 效能會變得更加低落 L7-filter 雖然只比對連線前 10 封包, 但是後續每個封包仍需要經過所有規則比對, 才能決定封包命運 因此 Signature-based 方式辨識 P2P 連線雖然準確率高, 但是效能問題卻變成相對衍生的困擾,[5] 提出一套改善方法, 修改 Netfilter 的 pre-routing hook, 把已經辨認過的連線標記放進一個表中, 讓後續進來的封包先查詢該表是否已經有經過比對, 如果有就直接從表中讀出比對的結果, 反之才會去比對系統的防火牆規則 圖 3-7 具狀態檢測的 Netfilter 資料來源 :Bing-Heng Peng,et al. [5] 圖 3-7 中, 當第一次比對出結果後, 隨即將該封包的連線狀態旗標儲存在 state table 中, 隨後的封包可以先查詢該表有無自己連線的比對結果 此外並設定一個比對門檻值 8, 當某連線前 8 個封包比對所有規則後仍然沒有結果, 就可以把預設決策設定為 ACCEPT 或是 DROP, 寫入對應的 Conntrack Entry 中, 避免該連線後續封包仍繼續進行比對 除了 ACCEPT 與允許 DROP 之外, 另外還增加 STATE 目標函數 ; 當封包比對出結果後, 再運用相關參數, 將結果存入 Conntrack 中, 相關參數如下表說明 : 29

39 Parameter --accept --drop --mark X Description 允許封包通過, 並在對應之 Conntrack 狀態欄標記為 accept" 不允許封包通過, 並在對應之 Conntrack 狀態欄標記為 drop" 允許封包通過, 並在對應之 Conntrack 狀態欄標記 mark 值 X", 提供如 QoS 額外之用 表 3-8 STATE 目標函數之參數資料來源 :Bing-Heng Peng,et al. [5] 測試環境為 Linux kernel L7-filter 1.4, 硬體為 SmartBits 6000C, 將防火牆規則分成 與 200 條, 並確保封包要比對到最後一條規則 另外也增加無規則的測試當作對照組 分別測試了封包大小為 與 1518 bytes 之下, 防火牆最大處理效能, 實驗結果如下表所示 : Packet Size:128 Bytes Packet Size:512 Bytes Packet Size:1518 Bytes Throughput Throughput Throughput Rules Original L7-filter (Mbps) Improvement Rules Original L7-filter (Mbps) Improvement Rules Original L7-filter (Mbps) Improvement 表 3-9 三種不同大小封包的測試數據資料來源 :Bing-Heng Peng,et al. [5] 由實驗結果可以看出, 當過濾規則變多時, 文中提出的改善機制能夠有效改善過濾效能, 不會因為過濾速度過慢, 嚴重拖垮網路效能 30

40 第四章實驗設計 本實驗設計採 仿真 的方式進行, 針對中小學學生最常使用的 P2P 軟體進行實體連線的封包錄製及重播 中小學經費較不足, 因此本實驗全部採用免費軟體進行, 而且為了讓實驗變因更容易掌握, 本章節提出一套封閉環境的架構方法, 讓雜訊干擾的減至最低, 以利實驗進行順利 4.1 模擬 (simulation) 或仿真 (emulation) 一般網路實驗可分為模擬 (simulation) 或仿真 (emulation) 兩類, 差別在於 模擬 選取整個系統環境的某些行為特徵, 用另一系統來表示它們的過程 ; 而 仿真 則為較高階段的模擬技術, 讓被模仿的系統更貼近真實的環境 著名模擬軟體如 NS2[39] 或交通大學開發的 NCTU-ns[40], 它們共同特色在於能夠使用單一電腦的 CPU 來模擬多台網路上不同的節點, 並透過軟體本身專屬的語法及支援的網路協定, 讓模擬出來的節點們互相溝通, 此方式可大幅節省真實環境硬體的開發成本 而本實驗設計採用 仿真 方式進行, 原因在於 P2P 軟體種類相當多元, 不同軟體連線時所採用的協定也是百家爭鳴, 所以到目前為止沒有任何的模擬軟體可以正確地產生 P2P 流量以供壓力測試 [6] 除此之外, 網路上亦也有些免費的 packet builder/generator 的流量製造工具程式, 提供使用者定義封包內容之後發送, 但是此類方式仍然無法貼切地表示出完整連線的互動過程 因而本實驗選擇將整個連線過程的封包錄製下來, 再透過播放軟體重送至網路環境中, 讓防火牆彷彿置身於真實網路環境中, 來達到仿真以及效能測試的目的 31

41 4.2 封包錄製 本實驗欲比較 T4-terminator L7-filter IPP2P 三種不同方式下, 對於 P2P 連線主動防禦的效能 為了控制每次實驗時,P2P 的連線情形均需相同, 因此預 先將真實環境的 P2P 流量錄製下來, 實驗時再進行重播的動作來模擬相同的連線 P2P 連線軟體的選擇 P2P 軟體相當多, 本實驗選擇中小學學生最常用的五項軟體進行研究, 分別是 FOXY BitTorrent emule MSN Messenger Yahoo 即時通 FOXY 採用 Gnutella 協定, 它目前是國內最多用戶的檔案分享軟體, 操作介面極為簡單, 所以大部分學生都在無師自通下學會了安裝 FOXY, 及抓取違法版權的資料 FOXY 由於用戶多, 所以造成的資訊洪流最嚴重, 不但大量地阻塞上傳頻寬, 而且使得電腦效能大幅下降, 更重要的是上面假檔充斥, 病毒 色情資訊多到氾濫的地步 BT 與 emule 因為操作方式較為複雜, 使用的學生人數比較少, 但這兩套軟體也是盜版電影與盜版音樂的大溫床, 亦列為禁止的目標 MSN Messenger 及 Yahoo 即時通是佔有率極高的 IM 軟體, 通常老師上資訊課時, 許多學生都會偷偷安裝該類軟體來聊天, 無法專心聽講, 學習成效大打折扣 ; 而這類軟體很容易使用 TCP 80 port 來逃避防火牆監督, 因此必須透過應用層辨識方式加以攔截 錄製工具 封包錄製或者監看的工具程式不少, 依使用者不同需求而發展出不同的功能 功能最基本的, 在 UNIX 上面常見的為 Tcpdump, 而 Windows 版本則為 Windump, 兩者皆為文字操作介面, 需要下達指令才能操作 Wireshark[29] 則是另一套跨平台的封包錄製工具, 它前身即為大名鼎鼎的 Ethereal, 它不但免費且功能相當強大, 支援十多種其他錄製工具的檔案格式 除上述軟體外, 在 Windows 上面還有兩套免費錄製工具,Packetyzer 以及本實驗採用的 Microsoft Network Monitor[30] 免費的錄製程式著重在解碼封包內容, 在視窗中顯示出封包各欄位的詳細內容, 以供使用者分析 而商用的工具著重在 監控 與 統計, 能夠在線監控網路狀況, 並即時提供大量的統計分析圖, 支援的網路協定也相對地比免費軟體來得多, 著名的商業軟體如 Sniffer Pro Capsa 等 32

42 本實驗採用 Microsoft Network Monitor Ver3.2 為封包錄製工具, 它是微軟提供的免費封包錄製軟體 大部分錄製軟體都依照封包進出網卡的先後順序排列, 所以同一時間在視窗畫面上會參雜著許多不同程式的封包 ; 而 Network Monitor 最大的不同點, 在於它可以把封包按照本身歸屬的應用程式做出分類, 因此使用者能夠排除其他封包干擾, 錄製該程式對外互動的完整過程 圖 4-1 Microsoft Network Monitor 執行畫面 由上圖執行畫面可看出, 各連線的封包都被區隔分類, 不但更容易觀察連線行為, 而且可以選擇單獨儲存某連線的封包 ; 而右下角的小窗格可看出 Foxy 傳輸採用 Guntella 協定 錄製方式 通常來說,P2P 連線的 Payload Signature 會出現在連線起始階段的前幾個封包, 連線建立之後的封包大部分都是資料的傳遞, 所以擷取請求建立連線階段的封包比較具有代表意義 本實驗欲錄製五種 P2P 連線的起始封包, 必須先啟用 L7-filter 或 IPP2P 進行連線阻擋, 才能順利擷取其請求連線的起始封包 由於 IPP2P 不支援 IM 通訊協定, 所 33

43 以選擇支援較多協定的 L7-filter 為過濾工具, 將防火牆規則設定如下表 : 01# iptables -N BAN 02# iptables -A FORWARD -m layer7 --l7proto gnutella -j BAN 03# iptables -A FORWARD -m layer7 --l7proto bittorrent -j BAN 04# iptables -A FORWARD -m layer7 --l7proto edonkey -j BAN 05# iptables -A FORWARD -m layer7 --l7proto yahoo -j BAN 06# iptables -A FORWARD -m layer7 --l7proto msnmessenger -j BAN 07# iptables -A BAN -j ULOG 08# iptables -A BAN -j DROP 表 4-1 IPTables L7-filter Rules of packet capturing IPTables 指令若不指定 table 的話, 預設值為 filter table, 在第二章有提過 filter table 共有三個 chain, 分別是 INPUT chain FORWARD chain OUTPUT chain 而 Rule#01 先在 filter table 自行定義一個名為 BAN 的 chain, 為了要方便觀察紀錄被 DROP 的封包 Rule#02 到 Rule#06 表示在 FORWARD chain 上面使用 L7 extension match module, 分別對五種不同連線協定進行應用層封包辨認, 條件符合者將它移至 BAN chain,rule#07 將 BAN 的資料再搬到 ULOG 這個記錄檔, 最後 Rules#08 將 BAN chain 的封包全部丟棄 34

44 圖 4-2 Flowchart of packet capturing 1 2 上圖是整個指令的處理流程, 雖然 Netfilter 能以內建計數器及 LOG 模組, 透 過系統核心的 syslogd 來記錄封包資訊, 但也因為透過 syslogd, 所以會跟系統其他 log 資訊混雜在 /var/log/messages 裡面, 雖然可利用某些方式分離, 但是閱讀上仍然很吃力 1 2 使用 iptables L n v 指令觀看 Netfilter 的統計數字使用 -j LOG 與其附加參數 (-j LOG --log-level 等 ) 紀錄封包資訊 35

45 ULOG 是 ulogd[31] 安裝編譯後在 IPTables 模組產生的 target function, 目的也在記錄辨識到的封包資訊, 它與 LOG 不同之處在於 ULOG 將 log 交由 UserSpace Program 處理, 再把資訊完整寫入 MySQL 或 Postgresql 等資料庫中, 最後透過 PHP 編寫的分析工具 Nulog[32], 以網頁介面呈現, 讓使用者在錄製封包時, 能夠同步觀察被 DROP 封包的各種屬性 圖 4-3 Nulog 的執行畫面 36

46 實際錄製時, 如下圖所示, 將五種軟體安裝在五台 PC 執行, 每種軟體個別錄製 15 分鐘, 最後封包統計結果如表 4-2, 因為每種軟體特性不同, 產出的封包數量差異性也不同, 很明顯看出最容易產生資訊洪流的 FOXY BT 無論產生之封包總數 總量 封包平均大小都是最大 圖 4-4 封包錄製配置圖 Application Packets Number Total Size Average Size FOXY MB 0.37 KB BitTorrent MB 0.36 KB emule KB 0.25 KB MSN Messenger KB 0.32 KB Yahoo Messenger KB 0.22 KB 表 4-2 錄製 15 分鐘後的封包總量 37

47 4.3 封包重播 封包播放工具比擷取工具來得少, 較常使用在 UNIX 上有 Tcpreplay Tomahawk 兩者均為 Open Source 的自由軟體, 兩者均需透過指令操作, 並沒有 GUI 介面 ; Tcpreplay 雖有 Win32 版本, 但仍須使用 C 語言編譯後才能執行 而具有 GUI 操作介面的有 Packet Player[33] Traffic IQ Pro, 兩者都是 Windows 的應用程式,Traffic IQ Pro 是商用軟體, 它提供封包改寫以及封包發送時同步報告的功能, 但是試用版僅支援罕見的 kar 封包紀錄格式 本實驗使用自由軟體 Packet Player, 操作相當方便, 支援播放的檔案格式也相當多, 操作畫面如下圖 圖 4-5 Packet Player 操作畫面 38

48 Packet Player 重播時是依照錄製的時間戳記將封包依序送出, 最大特色在 Burst Mode 及 Loop Sending Burst Mode 顧名思義為暴衝模式, 該方式能夠將封包傳遞之間的間隔時間修正到趨近於零, 等於一瞬間就可以把原本排程數分鐘甚至數小時的封包量全部送出, 製造待測物的壓力 ; Loop Sending 可由 one loop 設定至 infinite loop, 讓同樣的播放動作反覆不斷地進行, 配合 Burst Mode 可讓網卡在短時間內衝出極高的流量, 以供防火牆壓力測試 4.4 效能測試 提到網路設備效能測試硬體, 最常被使用的就是知名大廠 SPRIRENT 公司的 SmartBits 與 IxChariot 公司的 IXIA 兩大系列的產品都可以借由機身擴充槽插上介面卡, 再接上待測物進行仿真壓力測試, 但是這類設備要價不斐, 並非一般中小學經費能夠負荷 所以本研究利用 IxChariot 公司提供的 Qcheck[34] 及 Endpoint[35] 這兩套免費軟體作為效能測試工具 圖 4-6 Qcheck 執行畫面 39

49 Qcheck 與 Endpoint 支援四種協定 (TCP UDP SPX IPX) 及提供四種測試功能 (Response Time Throughput Streaming Traceroute) Qcheck 是前端使用者 console 軟體, 目前僅提供 Win 作業系統版本, 它必須配合後端待測物背景執行的 Endpoint 程式, 才能測出各項數據 Endpoint 支援多達 17 種的作業系統, 並提供測試時 localhost to remote 及 remote to remote 兩種方式, 使用上具有相當大的彈性 圖 4-7 Localhost to Remote 效能測試圖 圖 4-8 Remote to Remote 效能測試圖 40

50 第五章系統實作與效能評估 本章節說明實作過程, 將實驗分為兩大組, 分別是實驗組的 T4-terminator L7-filter IPP2P 及對照組的 Pure NAT; 實驗組均設定 8 條防火牆規則, 對照組則單純進行 NAT 工作, 觀察在大量流量壓力下, 防火牆各項效能數據, 並加以分析評估 5.1 實驗環境 圖 5-1 為實驗環境的配置, 與第四章封包擷取配置相較, 多了一台 WEB Server 及效能測試電腦 圖 5-1 實驗環境配置圖 41

51 實驗環境中 Clients 與 Servers 之硬體規格及作業系統 : P2P Clients Qcheck Console CPU Intel Celeron 2.8 G CPU Intel Core2 Duo1.83 G RAM 512 MB RAM 1 GB OS WinXP Pro SP3 OS WinXP Pro SP3 LAN SiS900 10/100 LAN Marvell Yukon 100/1000 P2P IPS Web Server CPU Intel Pentium4 3.2 G CPU Intel Xeon 3.2 G RAM 1 GB RAM 1 GB OS CentOS 5.1 OS FreeBSD 6.2-RC2 Kernel IPTables WAN V V1.3.8 Broadcom NetXtreme 100/1000 LAN Realtek /100 Web Server WAN Apache Intel PRO/1000 GT 表 5-1 硬體設備與作業系統規格表 42

52 5.2 實驗方法與步驟 五個 P2P Clients 端將預錄好的封包檔案, 以 Burst Mode 及 Infinite Loop 的方式重播, 並設定每個 Loop 之間沒有任何延遲, 讓網卡打出不間斷的連續流量來加壓 P2P IPS 另外許多 P2P 程式運用大量的 HTTP-like 的協定來傳輸檔案 [6], 如 FastTrack(KaZaA) Gnutella(Foxy) Xuelei 等, 因此本實驗另建置一台 Web Server, 網頁上放置如表 5-2 所示五個 ISO 檔案, 每個 client 端均對五個 ISO 檔開啟 HTTP 下載連線, 模擬 P2P 連線時, 大型封包傳輸的情況, 增加 IPS 判斷封包內容的工作 File name KNOPPIX DVD-EN.iso CentOS-5.2-i386-bin-DVD.iso Fedora-9-i396-DVD.iso FreeBSD-7.1-Release-i386-DVD.iso FreeBSD-6.4-Release-i386-DVD.iso Size 4.14 GB 3.74 GB 3.33 GB 1.77 GB 1.70 GB 表 5-2 Web Server 五個 ISO 檔案 在前一章節以 L7-filter 進行封包擷取, 同時以 Nulog+ULOG+MySQL 觀察記錄被擋下封包的資訊, 但在實作效能測試時, 直接將條件比對符合的封包予以丟棄, 以節省系統資源 在防火牆規則數方面, 因 L7-filter 支援多達 109 種, 而 IPP2P 支援的協定僅有 9 種, 而且 IPP2P 所支援的 9 種協定中,WinMX 協定在 L7-filter 卻又不支援, 為了控制實驗變因, 於是本實驗取兩軟體最大交集共 8 種協定進行測試 另外在 T4-terminator 部分,IPTables 規則數亦同樣設定為 8 條, 除了開放 WEB SMTP POP3 連線外, 其餘 TCP 封包只要 5 分鐘內連線超過 30 次, 均視為 P2P 封包加以阻擋 L7-filter 及 IPP2P 相互交集的 8 種協定中,Gnutella(Foxy) emule /edonkey BitTorrent 是國內學生較常用的 P2P 軟體, 其他如 FastTrack (KaZaA) Direct Connect AppleJuice SoulSeek Ares 則是其他國家流行的連線軟體 這 8 種協定並不包含所有的 Instant Messenger, 但進行實驗時仍會把先前預錄的 MSN YAHOO 即時通封包打出, 因為這些封包仍會在所有的 IPTables 43

53 規則中逐一進行比對, 對效能測試仍具有意義 實驗進行時共分成兩大組, 先進行對照組的 Pure NAT, 再進行實驗組的 T4-terminator L7-filter IPP2P 每一組再分別進行 3 種效能測試 (Benchmark): 1 Throughput: 分別以 5 種不同 Data Size(50kB 100kB 250kB 500kB 1000kB 測試 IPS 的最大處理能力 (Throughput), 每 10 秒鐘測一次值, 每個 Data Size 各測量 20 次後取其平均 2 Response Time: 反應時間 (Response Time) 與延遲時間 (Latency) 最大差異在於 Latency 指的是單一事件的延遲, 而 Response Time 是指會造成延遲的所有因素的總和 (overall processing delay,made up of individual latencies) Qcheck 軟體設計的目的在測量遠端網路狀況, 通常測量封包會跨過數個網域, 所以才會定義為 Response Time 本實驗環境封閉, 且 Console 端與待測物 IPS 僅相隔一個 switch, 所以測出之 Response Time 幾乎等同於 Latency, 但本測試名稱仍採用軟體命名的 Response Time 實驗時分別以 5 種不同 Data Size(2kB 4kB 8kB 16kB 32kB) 測試 IPS 的延遲時間, 重複次數 (Iterations) 設成 5, 每 10 秒鐘測一次, 每個 Data Size 各測量 20 次後取其平均 3 CPU Utilization: 為比較 Burst Mode 對 IPS 加壓的效果, 本實驗再分成兩組, 第一組按照封包錄製時的時間軸循序播放, 第二組才以 Burst Mode 加壓播放 兩組均使用 sar(system Activity Repoter) 指令 連續記錄 500 秒後, 取其之最大值 最小值 平均值 1 記錄每秒鐘 CPU 使用率, 1 # sar > /root/filename, 1 指記錄的間隔秒數, 500 指連續記錄之時間, 並將結果 輸出成檔案 44

54 5.2.1 實驗一 :T4-terminator 在 [3] 中作者提出一套 PTP 運算方法, 使用傳輸層 (Transport Layer) 來辨識 P2P 連線, 藉著檢驗 {IP,Port} pairs 的連線數量, 如果連線數超過 20 條, 而且持續時間超過 5 分鐘, 即判定為 P2P 連線 而在第二章 ( 圖 2-6 圖 2-7) 也清楚呈現, 無論分散式或者混合式的 P2P 架構, 一個新加入的節點, 很快地就會跟鄰近節點產生連線 因此本實驗依照 P2P 連線的特性及 [3] 的方式加以簡化, 提出一套 Layer4 的 P2P 限制方式, 本研究將其命名為 T4-terminator(T4 for Transport Layer4), 設計之防禦規則如下表所示 00# modprobe ipt_recent ip_list_tot=1000 ipt_pkt_list_tot=50 01# iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPT 02# iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 80 -j ACCEPT 03# iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -j ACCEPT 04# iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 25 -j ACCEPT 05# iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 110 -j ACCEPT 06# iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 110 -j ACCEPT 07# iptables -A FORWARD -p tcp -m state --state NEW,ESTABLISHED, \ RELATED -m recent --name P2P_db --update --second hitcount 30 \ -j DROP 08# iptables -A FORWARD -p tcp -m recent --set --name P2P_db 表 5-3 T4-terminator Rules 因為第 7 8 條規則會動用到 recent 模組, 但 recent 資料庫預設最多僅記錄 100 個 IP, 而且每個 IP 預設僅能記錄 20 個封包資訊 ; 當資料庫滿載時, 新資訊會取代舊資訊, 這對於 NAT 主機要服務整個 Class C 的區網, 及對外上百甚至上千個連線來說, 顯然是不夠用的, 所以第 0 條規則以手動方式載入 recent 模組, 並指定其參數, 讓記錄的 IP 數量擴充到 1000 個, 每 IP 追蹤的封包擴充到 50 個 第 8 條規則運用 recent 模組的 set 參數, 把符合該規則的 TCP 封包記錄到自行定義之 P2P_db 資料庫 ; 第 7 條規則用到參數 update, 它會不斷比對更新 P2P_db 資料庫的資訊, 若資訊不存在, 則交給第 8 條規則把該資訊寫進資料庫 第 7 條規則 second 300 及 hitcount 30 的意思為 300 秒內重複次數 30 次, 亦即只要 5 分鐘內超過 30 次 TCP 連線, 無論狀態是 NEW ESTABLISHED RELATED 的連線, 隨後的封包均採 DROP 方式處理 45

55 第 1~6 條規則目的在當開放 WEB SMTP POP3 連線, 因為 IPTables 採 first match 的關係, 所以這三種連線的 TCP 封包不會被後續的規則 DROP 掉, 讓 Client 端嘗試 P2P 連線被禁止時, 至少還能維持網頁 郵件收發的正常連線 整個執行流程如圖 5-2 所示, 本方式最大的優勢在於不檢驗 Payload Signature, 有效提高 IPS 的過濾速度 另外對於採加密連線, 或模糊演算技術, 甚至未知特徵的 P2P 連線亦能進行阻擋, 尤其對於中小學學生熱愛的 P2P 線上對戰遊戲阻擋效果甚佳 此方式最大缺點在於會漏判部分採 80 port 連線的 P2P flow, 或者誤判其他非 P2P 的 TCP 連線, 但漏判 誤判的問題在本研究中並未加以探討 圖 5-2 T4-terminator flowchart 46

56 5.2.2 實驗二 :L7-filter classifier L7-filter classifier 提供 Kernelspace 及 Userspace 版, 實驗使用 Kernelspace v2.20 版本,Protocol definitions 為 v 實驗定義 IPS 規則如下表, 因為 IPTables 規則比對是採 first match 逐一比對, 必須比對到符合條件的規則, 才會決定封包的命運, 所以將封包數量最多 (4586 個 ) 的 FOXY 放最後, 封包數較少 (2710 個 ) 的 emule 放第六條 01# iptables -A FORWARD -m layer7 --l7proto directconnect -j DROP 02# iptables -A FORWARD -m layer7 --l7proto soulseek -j DROP 03# iptables -A FORWARD -m layer7 --l7proto applejuice -j DROP 04# iptables -A FORWARD -m layer7 --l7proto ares -j DROP 05# iptables -A FORWARD -m layer7 --l7proto fasttrack -j DROP 06# iptables -A FORWARD -m layer7 --l7proto edonkey -j DROP 07# iptables -A FORWARD -m layer7 --l7proto bittorrent -j DROP 08# iptables -A FORWARD -m layer7 --l7proto gnutella -j DROP 表 5-4 L7-filter Rules 圖 5-3 L7-filter Rules flowchart 47

57 5.2.3 實驗三 :IPP2P classifier 本實驗使用 IPP2P v0.8.2, 不同 L7-filter 採呼叫外部 Protocol definitions,ipp2p 的 String-match 是以 16 進位碼直接隨程式碼編譯到模組中 實驗定義 IPS 規則如下表, 所有規則順序都跟 L7-filter 相同 01# iptables -A FORWARD -m ipp2p --dc -j DROP 02# iptables -A FORWARD -m ipp2p --soul -j DROP 03# iptables -A FORWARD -m ipp2p --apple -j DROP 04# iptables -A FORWARD -m ipp2p --ares -j DROP 05# iptables -A FORWARD -m ipp2p --kazaa -j DROP 06# iptables -A FORWARD -m ipp2p --edk -j DROP 07# iptables -A FORWARD -m ipp2p --bit -j DROP 08# iptables -A FORWARD -m ipp2p --gnu -j DROP 表 5-5 IPP2P Rules 圖 5-4 IPP2P Rules flowchart 48

58 5.3 實驗結果與效能評估 Throughput 以 5 種不同 Packet Size 測試後, 實驗結果均呈現最大處理能力由高至低為 : T4-terminator > PureNAT > IPP2P > L7-filter, 各項實驗數據如以下圖表 : 50 kbytes Throughput (Mbps) 100 kbytes 250 kbytes 500 kbytes 1000 kbytes PureNAT T4-terminator L7-filter IPP2P 表 5-6 Throughput of different Packet Size PureNAT T4-terminator L7-filter IPP2P Throughput (Mbps) Packet Size (kbytes) 圖 5-5 Throughput of different Packet Size 49

59 5.3.2 Response Time 以 5 種不同 Packet Size 測試後, 實驗結果呈現兩種排序 : 1 Packet Size 為 2kB 4kB 32kB, 反應時間由快至慢為 : PureNAT T4-terminator IPP2P L7-filter 2 Packet Size 為 8kB 16kB 時, 反應時間由快至慢為 : T4-terminator PureNAT IPP2P L7-filter 這部分 PureNAT 與 T4-terminator 互有領先, 各項實驗數據如以下圖表 : Response Time (msec) 2 kbytes 4 kbytes 8 kbytes 16 kbytes 32 kbytes PureNAT T4-terminator L7-filter IPP2P 表 5-7 Response Time of different Packet Size PureNAT T4-terminator L7-filter IPP2P Response Time (msec) Packet Size (kbytes) 圖 5-6 Response Time of different Packet Size 50

60 5.3.3 CPU Utilization 為瞭解僅記錄 500 秒的 CPU 使用率是否具有代表性, 因此本實驗進行前, 先 將預錄封包進行 500 秒的 Burst Mode Replay, 記錄 500 秒之後各軟體重播次數如 下表 : Application Replay times Foxy 9298 emule BitTorrent 8761 MSN Messenger YAHOO! Messenger 表 5-8 統計 500 秒 Burst Mode 封包重播之次數 由表 5-8 得知, 原先各軟體錄製十五分鐘的封包, 使用 Burst Mode Replay 在短短 500 秒內, 重播次數由八千多次至三萬三千多次不等, 可證明本實驗記錄 500 秒的 CPU Utilization 已具有足夠的代表性 另外, 為比較有無使用 Burst Mode 對 IPS 加壓的效果, 本實驗再分成兩組, 第一組按照封包錄製時的時間軸循序播放, 第二組才以 Burst Mode 播放, 其實驗結果如後詳述 51

61 首先第一組進行封包依錄製時間軸播放的方式, 以 sar 指令連續記錄 CPU 使用率 500 秒鐘後, 由實驗圖表可看出雖然 L7-filter 及 IPP2P 的 CPU 使用率高於 T4-terminator, 但是之間差異極微 主要原因來自依時間軸重播的封包, 其固定單位時間內送出的封包數量甚少, 尚不足以對 CPU 的運算能力構成壓力 CPU Utilization(%) Minimum Maximum Average PureNAT T4-terminator L7-filter IPP2P 表 5-9 CPU Utilization without Burst Mode PureNAT T4-terminator L7-filter IPP2P CPU Utilization (%) Min Max Avg 圖 5-7 CPU Utilization without Burst Mode 52

62 第二組以 Burst Mode Replay 再次實驗後, 可看出 CPU 使用率均明顯提高, 尤其以 L7-filter 最為顯著, 高出同樣採用 Layer7 延伸比對的 IPP2P 不少 實驗數據顯示, 無論最大值 最小值 平均值, 其使用率由少至多排序均呈現 :PureNAT < T4-terminator < IPP2P < L7-filter CPU Utilization (%) Minimum Maximum Average PureNAT T4-terminator L7-filter IPP2P 表 5-10 CPU Utilization with Burst Mode 100 PureNAT T4-terminator L7-filter IPP2P CPU Utilization (%) Min Max Avg 圖 5-8 CPU Utilization with Burst Mode 53

63 5.4 分析與比較 從各項實驗數據顯示, 本研究提出的 T4-terminator 阻擋方式, 縱使 IPS 規則同為 8 條, 但是各項效能表現幾乎不亞於 PureNAT, 其中最大處理能力甚至優於 PureNAT, 原因在於 PureNAT 要對所有穿透封包進行目的端 DNAT(Destination NAT) 及來源端 SNAT(Source NAT) 封包偽裝轉換, 核心必須記錄每個封包的正確的歸屬 IP; 而相對本研究的 T4-terminator 規則, 第 8 條規則雖然必須消耗資源, 將新的 TCP 封包資訊記錄到 P2P_db 這個檔案, 但是當資料記錄符合 5 分鐘內超過 30 條 TCP 連線 的條件後, 後續封包就直接被核心丟棄, 這些大量被丟棄的封包, 可節省系統資源, 不必再進行 DNAT SNAT 動作 另外 T4-terminator 前 6 條規則的比對是採用 Layer3 的 Port Number 比對方式, 對系統資源的消耗並不多, 因此在這消長互現的狀況下, 呈現出 T4-terminator IPS 極佳的處理效能 而在 L7-filter 與 IPP2P 方面, 兩者雖然都使用 Kernelspace 版, 並採 Layer7 的 Payload Signature 檢驗, 但各項測試數據均顯示 IPP2P 效能優於 L7-filter, 尤其 CPU Utilization 的表現與 T4-terminator 可說是不相上下 下表將研究成果配合其運作原理做一整理 : L7-filter IPP2P T4-terminator CPU Utilization 最高很低很低 Response Time 較長中等最短 Throughput 較低中等最佳 Kernelspace version Userspace version 運作方式支援 Kernel 版本數量 是 是 是 是 否 - Netfilter/IPTables Netfilter/IPTables Extension match Extension match Netfilter/IPTables 多 少 - 54

64 支援 IPTables 版本數量 多少 - 封包比對層級 Layer7 Layer7 Layer3/Layer4 Payload Signature 演算法比對方式 Regular Expression 每條連線前 10 個封包或前 2048 Bytes 16 進位具體代碼 - 每個封包均比對 每個封包均比對 封包處理速度慢快極快 辨識通訊協定數量特徵定義檔位置自行定義協定的方便性 Quality of Service/ Traffic Control 對已連線且傳輸中的 P2P flow 能否禁止辨別加密連線或模糊演算 109( 包含其他協定 ) 9( 全是 P2P 協定 ) - Extension pattern - Write in Code file 僅需修改 pattern 需修改 source file, 具彈性且方便 code, 再重新編譯 - 已結合 conntrack, 不具 conntrack, 較 只能全禁止或全放 方便於 Qos 不方便進行 QoS 行 效果不佳 效果不佳 立即生效 否 否 可 辨別未知協定否否可 表 5-11 三種 P2P 主動防禦方式之比較 55

65 總結上表可看出 3 種防禦方式各有其優缺點 :L7-filter 更新快 支援新版系統核心 辨識範圍廣 擴充性高 容易進行頻寬控管, 雖然執行效能稍低, 但是使用上彈性很大, 因此不少商用 IPS 都以 L7-filter 來作為產品的開發核心 IPP2P 雖然執行效率極佳, 但最大缺點在官網接近三年未發佈新版本, 以致新版的 Netfilter/IPTables 均無法支援, 自行擴充協定也不方便 T4-terminator 的方式最大優勢在防火牆效能幾乎不受影響下, 卻能夠有效封鎖 P2P 連線, 但缺點在於 誤判 其他非 P2P 之連線, 或者 漏判 少數採 80 port 傳輸的 P2P flow 此外 L7-filter 及 IPP2P 兩種 Layer7 特徵防禦方式, 在實作時發現, 對於已進行傳輸中的 P2P flow, 阻擋效果都不佳 亦即 client 端已經開啟 P2P 程式分享檔案後, 無論再執行 L7-filter 或 IPP2P 規則, 都無法有效中途抑止傳輸行為 原因在於兩者定義的封包特徵, 絕大多數都在連線建立之初已溝通完畢, 一旦連線建立後, 交換的封包多為大型檔案資料, 導致阻擋效果不佳, 因此 client 端通常還是可以順利地把進行檔案交換 另外碰到加密 模糊演算 未知協定等 P2P 連線, 兩種 Layer7 的辨識方法都無法加以防禦 ; 但是上述問題, 採用本研究提出的 T4-terminator 防禦方式, 都可以迅速迎刃而解 但若網管人員不想全面禁止 P2P flow, 而是採用頻寬管理的方式, 本研究的 T4-terminator 就無法順利達成 56

66 第六章結論與未來方向 近來 P2P 網路蓬勃的發展, 隨之而來的頻寬問題 資通安全危機層出不窮 ; 另外智慧財產權的法律訴訟亦在世界各國陸續點燃 各家 ISP 業者通常以 QoS 的管理方式以減低 P2P 對頻寬的衝擊, 而我國教育部則是明文禁止各級學校禁用 P2P 軟體來下載非法檔案 隨著 P2P 技術進步, 傳統防火牆已經很難加以抵擋, 必須透過 Layer7 的辨識系統進行防禦, 然而此類的商用 IPS 要價不斐, 對於經費拮据的國中小學來說, 是一筆很大的負擔 本研究採用自由軟體實作一套 IPS 系統, 以極低的成本達到 P2P 連線的主動防禦效果 6.1 研究成果 1 仿真 免費的測試環境: 通常商用網路設備的測試儀器, 如 SmartBits 或 IXIA 動輒百萬, 絕非中小學或一般企業可以負荷 本研究分析比較許多免費測試軟體之後, 整合出一套適合於效能評估, 且操作方便的仿真環境 本實驗環境不僅限於 P2P 的測試, 同時也適用其他網路設備的效能測試 2 迅速 有效的 T4 主動防禦 : 因為 Layer7 的比對需花費較多的系統資源, 一旦區網電腦增加, 或者流量變大, 將使 IPS 必須維護更多的連線, 以導致網路速度變慢 ; 另者 Layer7 缺點在於對於封包加密 連線採用模糊演算技術, 甚至未知特徵的 P2P 連線均無法正確判斷 本研究運用 IPTables 內建的 connection tracking 功能及 recent 模組參數, 提出 T4-terminator 的防禦方式, 對於加密 已連線並傳輸中 未知協定的 P2P 連線都可以有效阻擋 而且 T4 的方式不需要進行封包內容比對, 可以大幅提升 IPS 效能 3 精準 彈性的 Layer7 比對模組 : 無論 L7-filter 或者 IPP2P 都具有 Open Source 的特性, 可讓使用者自行定義封包特徵, 外掛在 Netfilter/IPTables 上面進行延伸比對, 有效地阻擋 P2P 連線 57

67 6.2 未來方向 本論文提出的方案可以有效阻擋目前常見的 P2P 連線, 但尚有未臻完美之處, 未來本研究可朝三個方向進行 : 1 整合 T4 及 Layer7, 提升 IPS 效能及防禦準確率 : 本研究提出的 T4 防禦規則採用 寧可錯殺一百 也不可放過一個 嚴格規範, 雖然 P2P 防禦效果極佳, 但相對也會導致其他正常連線封包遭到丟棄, 誤判率的問題有待探討 而放行 WEB 80 port 的方式亦可能讓少數 P2P 連線順利穿越 IPS, 因此網管者可視學校需要, 修正防火牆內容, 讓 T4-terminator 及 Layer7 的規則互相搭配, 達到有效防禦的目的 2 整合 IDS 及編寫 CGI 介面, 提高安全性及便利操作 :IPTables 規則語法需要一段時間的學習才能上手, 較不利網管人員交接, 未來可利用 PHP 或 Perl 等語言撰寫操作介面, 讓不熟悉語法的網管更方便操作 ; 還可以整合其他 IDS(Intrusion Detecion System) 如 SNORT 的辨識規則, 抵擋 WAN 端的各類攻擊, 以及判斷 LAN 端的網路病毒的行為, 搭配 IPTables 加以封鎖, 提高資訊環境安全性 3 運用負載平衡開發分散式 IPS 系統, 維持網路品質 : 當 LAN 端電腦越來越多, 或者網路環境採 GigaNet 高速傳輸時, 單一台 IPS 的運算能力會拖垮整體效能, 未來系統可以運用負載平衡演算法, 將封包導向分散式系統進行平行處理, 維持網路連線品質 58

68 參考文獻 [1] Sen, S., O. Spatscheck, and D. Wang. Accurate, scalable in-network identification of p2p traffic using application signatures. 2004: ACM New York, NY, USA. [2] Spognardi, A., A. Lucarelli, and R. Di Pietro. A methodology for P2P file-sharing traffic detection. in Hot Topics in Peer-to-Peer Systems, HOT-P2P Second International Workshop on [3] Thomas, K., et al., Transport layer identification of P2P traffic, in Proceedings of the 4th ACM SIGCOMM conference on Internet measurement. 2004, ACM: Taormina, Sicily, Italy. [4] Xing, L., D. Haixin, and L. Xing. Identification of P2P traffic based on the content redistribution characteristic. in Communications and Information Technologies, ISCIT '07. International Symposium on [5] Bing-Heng Peng, H.-J.L., Huan-Yun Wei, Performance Enhancement over Linux Content Filtering. Journal of Information Technology and Applications, : p [6] Ying-Dar LIN, M., Po-Ching LIN, Meng-Fu TSAI, Tsao-Jiang CHANG,and Yua n-cheng LAI, kp2padm: An In-Kernel Architecture of P2P Management Gateway. IEICE TRANS. INF. & SYST, VOL.E91 D. [7] Constantinou, F. and P. Mavrommatis. Identifying Known and Unknown Peer-to-Peer Traffic. in Network Computing and Applications, NCA Fifth IEEE International Symposium on [8] Dedinski, I., et al. Cross-Layer Peer-to-Peer Traffic Identification and Optimization Based on Active Networking [9] Haoyi, W. and N. Ishikawa. Design and implementation of a simulator for peer-to-peer networks: optimal-sim. in Communications, Computers and signal Processing, PACRIM IEEE Pacific Rim Conference on [10] Schollmeier, R. and G. Schollmeier. Why peer-to-peer (P2P) does scale: an analysis of P2P traffic patterns. in Peer-to-Peer Computing, (P2P 2002). Proceedings. Second International Conference on [11] 陳勇勳, Linux 網路安全技術與實現. 1 ed. 2008, Taipei: 悅知文化. [12] L7-filter Classifier. Available from: 59