中 華 大 學

中 華 大 學 碩 士 論 文

題目：校園網路中用戶身份認證過濾系統 之實作

系 所 別： 資 訊 工 程 學 系 碩 士 班 學號姓名： M09502051 楊 有 信 指導教授： 劉 懷 仁 博 士

中華民國 九十七 年 八 月

摘要

在開放式的網路環境，如校園網路，使用者可以利用網際網路所帶來的便利 性達成資訊的交換及取得。然而，在這樣開放的環境，也同樣提供了濫用網路資 源的使用者一個無設限的網路平台，進而成為資訊犯罪的溫床。

一般而言，網路管理者根據事先指定好的網路位址，建構出網路位址跟使用 者的對應關係。然而，網路位址可以被假造或誤用。因此，對於一位惡意使用網 路資源的用戶，可以利用他人的網路位址來避免網路管理員的追查。

為了避免固定 IP 位址與使用者對應關係被誤認，本篇論文提出一個藉由身分 認證伺服器跟應用層閘道器(Application Gateway)的結合，精確的辨識出每一條 網路連線的使用者。此外，我們的方法亦可以實現在動態取得 IP 位址的環境，

如 DHCP。從實驗分析結果，我們的方法跟原本 Linux 防火牆(iptables) 相比並 沒有額外增加太多系統效能的負擔。

關鍵字： 防火牆、身分認證、辨識、iptables、DHCP。

致謝

首先我要感謝劉懷仁博士，讓我了解做研究的態度及嚴謹的精神。在他的指 導下，除了提供學術領域相關知識外，也讓我在做研究的過程中，學會對事物該 有之嚴謹的態度，讓我可以用更正面的思考面對未來的生活。

感謝實驗室的學長、同學、學弟們，不論在論文研究或是課業上遇到問題，

都能適時的討論及幫忙，給予我許多新的觀念及想法，並應用在論文中。另外，

感謝利基網路股份有限公司的總經理魏煥雲博士，除了提供 SmartBit 硬體的環 境測試平台，並給予技術上及數據分析上的建議，讓論文更貼近實際上之應用。

最後感謝我的好友及家人的支持，給予我關心及鼓舞，讓我在無慮的環境下 完成我的研究。最後，也對曾經幫助過我的人，至上最高謝意！

目錄

摘要 ……….I 致謝 ………...II 目錄 ………..III 圖目錄………..IV 表目錄………...V

第一章 簡介 ………1

第二章 背景知識及相關研究………4

2.1 Linux Netfilter 架構………..…..5

2.2 連線追蹤系統 (Connection Tracking System)………...………...9

2.3 Iptables 架構…….………12

第三章 系統架構 ………...18

3.1 建置環境……….………..20

3.2 用戶資訊更新 (Binding Update)…...………...21

3.3 系統元件………...23

3.3.1 用戶資訊表 (Kernel Hash Tables) ………..…………...24

3.3.2 連線辨認元件 (Connection Identifier) ..………..27

3.3.3 連線過濾元件 (Filter Component)……….………..………....28

3.3.4 用戶資訊載入元件 (Information Loader) ………..………….28

3.3.5 過濾規則產生元件 (Rule Generator).………..………29

3.4 系統連線紀錄 (Syslog)………..……….30

第四章 數值分析 ………..31

4.1 符號定義………...32

4.2 辨認數值分析………...32

4.3 數值分析討論………...34

第五章 效能評測 ………..36

5.1 效能評測環境 ………..36

5.2 效能評測分析 (Performance Analysis)...………..……...37

5.3 負載分析 (Overload Analysis).………..………..39

第六章 結論與未來工作………..44

參考文獻 ………..46

圖目錄

圖 一、Netfilter 架構………6

圖 二、Connection Tracking Hash Table………12

圖 三、檢查點、Conntrack 系統與 mangle table、filter table、nat table 關係…..15

圖 四、Co-operations between system components………...19

圖 五、A Campus Environment………..20

圖 六、Binding updates ………..21

圖 七、Active Directory 群組查詢範例………22

圖 八、System Architecture………23

圖 九、User Table 範例………..25

圖 十、Group Table 範例………..26

圖 十一、IP-User Table 範例………26

圖 十二、測試環境………36

圖 十三、Forwarding Rate……….38

圖 十四、Maximum Latency………..38

圖 十五、Forwarding Rate with 250 Rules………40

圖 十六、Forwarding Rate with 500 Rules………40

圖 十七、Forwarding Rate with 750 Rules………41

圖 十八、Forwarding Rate with 1000 Rules ………..41

圖 十九、Latency with 250 Rules ………..42

圖 二十、Latency with 500 Rules ………..42

圖 二十一、Latency with 750 Rules………...43

圖 二十二、Latency with 1000 Rules………43

表目錄

表 一、Table 與 Chain 列表 ...14

表 二、Binding update 範例 ...25

表 三、系統紀錄參數表...30

表 四、系統紀錄範例...30

第一章 簡介

隨著網際網路的興起及普及，透過網際網路取得資訊及分享資訊已變成是人 們日常生活中的一部分。不僅僅加快取得知識、資訊的速度，也藉由網際網路的 特性，縮小了人跟人之間溝通的限制。然而，網際網路所帶來的便利性，卻也是 有心人士從事資訊犯罪的最好工具。因此，如何過濾使用者的網路行為，也成為 現今防火牆的主要需求。

在開放性的校園網路環境裡，學生可以利用學校的網路資源快速查詢所需的 資訊、知識，以達到快速學習的效果。然而網路資源容易遭到誤用，如非法 FTP 站分享未授權的軟體，都可能讓學生及學校面臨違反智慧財產權等法律問題。近 年來越來越興盛的 P2P 軟體，如 Bit Torrent 或 eMule，更讓非法分享、下載軟體、

影片、音樂等問題更加的嚴重。雖然網路管理者可以透過購買防火牆來阻斷這些 網路行為，但卻無法有效得知是哪位使用者做了這些濫用網路的行為。

在企業或校園網路裡，一般而言使用者的網路位址通常是事先指定好的，一 位使用者可以有一個到多個網路位址。藉由事先定義好的使用者跟網路位址的對 應關係，網路管理者可以透過分析防火牆紀錄裡的網路位址來找出是哪位使用者 誤用網路資源。然而對於一位誤用網路資源的使用者，如使用 Peer-to-peer 軟體 非法分享未授權軟體 [1] 等，可以使用他人網路位址或是利用 IP gray space [2]

來避免被網路管理者稽核。在這樣的情況下，如果還是利用事先定義好的使用者 與網路位址對應關係去追查誤用網路資源的使用者，很容易造成誤判讓沒有濫用 網路資源的使用者變成受害者。

在動態取得網路位址的環境下，如 DHCP [3]，由於取得到的網路位址完全

是動態決定，無法確定使用者跟網路位址的對應關係，更加難以利用防火牆紀錄 中的網路位址來追查誤用網路資源的使用者。即使防火牆可以辨認並阻斷該使用 者濫用的網路行為，但卻無有利的證據顯示該連線是由哪位使用者所產生的。

Robert Beck [4] 設計了一個能夠管理使用者的防火牆系統。該系統結合了身 分認證的功能以避免未經過身分認證的使用者來誤用他們實驗室的網路資源。在 系統初始化階段，設定攔截送往任何網路位址的封包。每位使用者都必須做完身 份認證的動作獲得該實驗室的網路使用權。身份認證動作是藉由 Telnet 登入到 一個以 OpenBSD 實做的身分認證閘道器(Authenticating Gateway)完成。一旦使 用者經過身分認證閘道器的認證，該身分認證閘道器就會產生一條過濾規則 (Policy Rules)讓使用者之認證之網路位址封包通過，進而獲取網路資源的使用 權。然而該系統過濾規則僅能利用使用者帳號來做設定，而無法利用群組的觀念 來設定。現在的身分認證伺服器，如微軟(Microsoft)開發的 Active Directory [5] 就 有支援使用者群組化等功能。另一個嚴重影響系統效能的關鍵問題是每當使用者 成功地從身分伺服器完成身分認證程序，該應用閘道器就會產生一條對應到該使 用者的過濾規則讓該使用者產生的封包都能通過應用閘道器。如果有n位使用者 通過認證程序，那麼系統上就至少會有n條過濾規則。也就是說，過濾規則會隨 著使用者人數上升而上升。同時，在 [4] 的方法中，系統上的過濾規則會因為 使用者的上線、下線或與網路住址的異動而動態地新增、移除過濾規則，造成系 統上過濾規則的不穩定，且過於頻繁的更新規則也會浪費系統資源，嚴重影響系 統效能。此外，在原方法中該系統係 Packet-Based 的作法，是故過濾規則的多寡 會直接影響系統效能。

我們延伸了 [4] 的方法，加以支援群組管理觀念及減少系統上的過濾規 則。此外，我們也藉由減少新增、移除過濾規則的動作來提高我們的系統效能。

為了達成這樣的目的，在我們的系統架構可分為五個元件 Binding Manager，

Information Loader，Rule Generator，Filtering Module，Connection Identifier。前 三個元件是實作為應用程式 (Userspace Program)，分別執行在我們的應用層閘道 器(Application Gateway)與身分認證伺服器(Authentication Server)上；而後兩個元 件則是實作為 Linux 核心模組(Kernel Modules)，加到 Linux 核心。藉由身分認證 伺服器跟以 Linux 為基礎的應用層閘道器(Application Gateway)結合，精確的辨識 出每一條網路連線的使用者，避免傳統使用者與網路位址對應關係所造成的誤判 的問題。同時我們的方法也可以實現在動態取得網路位址的環境裡，解決傳統辨 識使用者方法的不足。

本篇論文在第二章主要說明 Linux Netfilter 架構、Connection Tracking (conntrack)模組及應用層之 iptables 功能的相關簡介。在第三章我們描述我們提 出來的系統架構，及如何應用到使用者辨認的網路環境中。在第四章則是實驗的 結果及說明。最後在第五章提供整篇論文的結論及未來發展。

第二章 背景知識及相關研究

隨者網際網路的快速發展，網際網路相關應用成為人們日常生活中的一大部 分。然而，如何管理使用者之網路行為及面對駭客的入侵造成資料外流等，也是 管理者最迫切面對的問題。因此佈建防火牆系統除了能管理使用者之網路行為，

同時也確保內部網路的資料安全。

近年來，網際網路的應用及通訊協定的不斷更新，如動態更換通訊阜之 P2P 應用軟體，導致早期以網路位址及通訊阜為主的防火牆系統已不敷使用，進而演 變到以封包特徵值 (Signature/Pattern)辨識為主的防火牆系統。而秉持著開放性原 始碼的精神， Linux 系統已成為最被廣泛實做成防火牆系統之作業系統。伴隨 著網際網路的興起，Linux 作業系統在設計時就已經將網際網路的功能考慮進 來，因此，對於網際網路之功能支援已相當成熟。而 Linux 防火牆架構從早期的 ipchains (Kernel Version 2.2)到現在的 Netfilter [6] (Kernel Version 2.4~2.6)架構，

除了提供封包過濾的功能，也顯示 Linux 在防火牆這一塊領域也具有相當成熟的 功能支援性。因此我們考慮在 Linux 作業系統上實做我們提出之動態辨識使用者 之功能。

論文實做則是基於 Linux 核心[7]中的 Netfilter 架構之上的 Connection Tracking 機制基礎上實作的。在 User-space 實做的 Rule Generator 元件是依靠 iptables 應用程式來下達過濾規則，通知 Linux 核心來辨識使用者及其連線。因 此這個章節，我們簡短介紹 Linux 核心中之 Netfilter 架構以及 Connection Tracking 子系統與 Userspace 上的 iptables 之相關運作流程。

2.1 Linux Netfilter 架構

Netfilter 為改良上一版之防火牆系統-ipchains，由於 ipchains 有許多潛在的 致命缺點及開發之限制特性，因此 Linux 核心進入到 2.4 版後，在網路封包過濾 處理架構方面，提出了新的架構取代舊有的 ipchains 達到 Per-Packet-Filtering、

NAT [8]等功能，該架構為 Netfilter 組織提出的 Netfilter 架構。該架構主要的功能 是讓封包在核心裡面藉由通過不同的狀態下的檢查點(Hook Points)及檢查點上 所註冊的不同的過濾函式達到封包過濾的動作。搭配 Userspace 的 iptables 應用 程式，則可以在核心中不同檢查點上新增過濾函式，達到不同狀態下擁有不同的 封包過濾方式的彈性。在其架構中，封包的過濾動作可分為兩大步驟：

(1) 在 Linux 核心中註冊的檢查點中抓取封包。

(2) 將封包送往該註冊檢查點上的過濾函式做過濾的動作，並回傳封包的處 理回應動作。

利用在核心中註冊的五個不同的封包檢查點，允許封包在經過系統的不同狀 態下做不同的過濾動作，增加了封包過濾的彈性。當封包經過核心內相關檢查點 時，則會進入註冊在該檢查點上的過濾函式，直到通過該檢查點上的所有相關過 濾函式，封包才會繼續交給核心中的網路處理函式，來完成封包在核心中的處理 流程。

核心中相關檢查點及封包在 Netfilter 架構中處理的流程為圖一所示。從圖一 中 ， 核 心 中 註 冊 了 NF_IP_PRE_ROUTING 、 NF_IP_LOCAL_IN 、 NF_IP_FORWARD、NF_IP_LOCAL_OUT 及 NF_IP_POST_ROUTING 等五個封 包檢查點 [9]。依據封包在系統上的不同流程，經過的檢查點也會不同。例如封 包經過系統再轉送到他地，經過的檢查點則分別為 NF_IP_PRE_ROUTING、

NF_IP_FORWARD 及 NF_IP_POST_ROUTING。若封包是要給該系統上的程序，

則會經過 NF_IP_PRE_ROUTING 及 NF_IP_LOCAL_IN。反之，若封包是由該系 統 上 之 程 序 所 產 生 並 送 往 他 地 ， 則 會 經 過 NF_IP_LOCAL_OUT 及 NF_IP_POST_ROUTING 等檢查點。

圖 一、Netfilter 架構

架構中之五個不同檢查點代表核心中網路封包之不同狀態，底下則詳細提供 不同檢查點之敘述。

‹ NF_IP_PRE_ROUTING: 當封包進入系統時，經由 Device Driver 幫忙 將 bit stream 轉換成核心網路之資料結構(Socket Buffer)，開始封包在系 統中之處理流程。當封包在 Data Link Layer 做完檢查碼(Checksum)的核 對確認封包之完整性之後，則會交給上層 IP Layer 做路由(Routing)的動 作。而在進入路由之前就會經過此檢查點。其目的為事先過濾一些不需 要經過系統之封包，如 DoS 之類的封包；或是做 DNAT (Destination Network Address Translation)的功能，將目的端網路位址做必要的轉換。

‹ NF_IP_LOCAL_IN: 封包若經由路由函式判斷該封包是給系統上之程 序的話，就會先進入此檢查點。一旦通過該檢查點之檢查，封包才能傳 給上層之程序處理。例如，可以在此檢查點設定那些網路位址群組才能 使用系統上之服務，減少不必要的系統負載。

‹ NF_IP_FORWARD: 封包若經由路由函式決定該封包是送往他地，則 會經過此檢查點。換句話說，若封包透過網路卡間的路由繞送，或是 NAT 轉址後的封包轉送，都會經過此檢查點。

‹ NF_IP_LOCAL_OUT: 在系統上的程序所產生出來的封包，經由上層 通訊協定之處理完成封包之後(新增每一層表頭)與路由決策之前，則會 經過該檢查點。經過檢查點的檢查之後，才會經過路由函式，將封包送 出系統。

‹ NF_IP_POST_ROUTING: 當封包經由路由函式決定封包送往目的端 的網路卡後，就會進入該檢查點。通常這個檢查點也賦予來源端網路位 址轉換(SNAT)及相關網路封包統計等功能。

如之前所敘，封包經過檢查點會進入該檢查點之過濾函式。每個過濾函式在 完成該動作之後，則會回傳該封包過濾後的回傳值，藉由該回傳值來判斷是否讓 封包繼續通過至下個過濾函式，或是阻擋掉該封包避免繼續後續的網路處理動 作。而過濾函式之回傳值定義如下：

‹ NF_DROP: 該封包符合系統上的過濾條件，停止該封包送往下一個 過濾函式，並將封包丟棄，釋放該封包所佔有的相關系統記憶體空間。

‹ NF_ACCEPT: 讓封包通過此過濾函式並且送往下一個過濾函式。若無 後續之過濾函式，則讓封包通過該檢查點，恢復正常網路處理流程。

‹ NF_STOLEN: 封包暫時交由目前之過濾函式處理，不傳給下一個過濾 函式。與 NF_DROP 不同之處在於 NF_DROP 會丟棄該封包並釋放相關 記憶體空間，而 NF_STOLEN 則是等某個條件滿足後再進行過濾的動 作。例如封包有經過分割(Fragmentation)的動作，則會等封包重組織後 再進行過濾函式的比對動作。

‹ NF_QUEUE: 對於特殊應用而言，例如由 Userspace 的應用層式來對 核心中的封包做處理的動作，則藉由 NF_QUEUE 將封包 Queue 在核心 的佇列(Queue)[10]中提供上層的應用程式使用。等到上層應用程式處理 完之後，則會通知核心讓封包通過或是過濾掉該封包。

‹ NF_REPEAT: 再一次呼叫該過濾函式來過濾該封包。此回傳值應當小 心使用，避免封包在此過濾函式造成處理上的循環而無法完成系統上網 路封包處理之流程。目前在核心的應用為 TCP 狀態間轉換的檢查。

從上述所敘的檢查點及過濾函式之回傳值，則可以清楚的了解 Netfilter 架構 如何在核心中達到封包控制、過濾等動作。經由模組化的過程，我們也可以更容 易的新增、延伸 netfilter 的系統架構來滿足我們所需的功能。

Netfilter 架構之功能強大不僅僅於封包控制、過濾等動作，而是伴隨的其架 構所衍生出來的 Connection Tracking 系統。藉由 Connection Tracking 系統，則可 以將 Packet-based 封包過濾改善為 Connection-based 封包過濾，如下一節所敘。

2.2 連線追蹤系統 (Connection Tracking System)

Connection Tracking (conntrack) [11] 是獨立建構在 Netfilter 架構上的子系 統。分別註冊在 NF_IP_PRE_ROUTING 及 NF_IP_LOCAL_OUT 兩個檢查點。對 應到圖一所示的 Netfiler 架構，可以發現，這兩個檢查點分別是封包剛進入系統 或是系統上的程序產生出來的封包所經過的檢查點。其目的是在檢查系統上經過 的封包是否有新的 Connection 產生，如果有則產生新的 Connection Entry；否則 則將封包對應到已存在之 Connection Entry。而在檢查點優先進入 Connection Tracking 系統是因為註冊在檢查點上的優先權以 Connection Tracking 系統為優 先，因此，在結束 Connection Tracking 系統之作用後，封包才會進入該檢查點的 過濾函式。

Connection Tracking 主要任務是利用第三、四層之相關資訊(來源端位址、

目的端位址、來源端阜號、目的端阜號、通訊協定)作為 Hash key，將屬於同一 連線之封包在核心中 Hash 成同一 Connection Entry。對於每一個 Connection Entry 來 說 ， 除 了 基 本 的 第 三 、 四 層 相 關 資 訊 ， 還 會 紀 錄 該 連 線 的 狀 態 (NEW, ESTABLISHED, RELATED, INVALID)、用來估算 Connection Entry 生命週期的計 時器、管理過濾函式優先順序的優先權與後述之 Expect 與 Helper 功能。藉由這

些資訊，讓 Netfilter 架構具有 Stateful Packet Inspection 之功能。除了能完整的核 對封包間的先後順序，甚至是 Connection 間的主從關係(例如 FTP Command Connection 及 Data Connection)，讓防火牆不再是以單一封包做過濾，而是以同 一條連線到目前為止的通過狀態來檢測到目前為止的封包，過濾掉系統未授權之 封包。

Connection Tracking 系統的架構如圖二所示。每一個 Connection Entry 在經 過 Hash 之後，會被安排在 Connection Hash Table。每一個 Connection Entry 都有 兩個 Hash Tulpes，紀錄前後 Hash 值相同之 Connection Entry，形成一 Doubly Linked-List [10]。

圖 二、Connection Tracking Hash Table

從圖二，可以發現 Connection Tracking 的資料是由 Hash Table 組成並利用 Doubly Linked-List [10]來避免 Hash Collision [10]。其目的是加快搜尋的速度，避 免在過多連線的環境中因為搜尋 Connection Entry 而拖垮系統效能。

另外，像 FTP 之類的應用程式，除了控制用的連線，還會產生傳輸資料用 的相關連線。為了能夠精準的判斷出連線的依附關係，Connection Tracking 系統 提出了 Helper 及 Expect 等機制。Helper 機制則是協助系統辨識該連線是否跟已 存在的連線有相關。而 Expect 則是在一段週期裡面預期會有 Connection 發生。

例如，FTP 利用 Command Port 向伺服器作連線的動作並且下相關的指令，在準 備傳輸資料之前，Connection Tracking 系統會預測在一段週期裡面會有資料傳輸 的連線建立起來，再利用 Helper 機制將新的資料連線跟已存在的 FTP 連線做關 聯的動作。

如前述，封包進入 Connection Tracking 系統後，會先檢查 Hash Table 中是否 有該連線的 Connection Entry，如果沒有，則會產生新的 Connection Entry 並且初 使化該 Entry，並等待系統確認。而確認的函式為 nf_conntrack_confirm()註冊在 NF_IP_LOCAL_IN 及 NF_IP_POST_ROUTING 等兩個檢查點上。從圖一來看，

這兩個檢查點都是在路徑上的最後一個檢查點，等待封包成功的脫離 Netfilter 架 構才會完成確認的動作。而確認的動作也就是將新建立出來的 Connection Entry 插入系統的 Connection Tracking Hash Table 中。

2.3 Iptables 架構

Iptables 為應用層之應用程式，其主要功能則是提供一個使用者介面讓使用 者可以設定過濾規則，並將這些規則通知核心在 Netfilter 架構中提供的檢查點上 註冊過濾函式，並經由已註冊的過濾函式來過濾流經系統上的封包。由於 Netfilter 架構提供檢查點的觀念，因此，iptables 除了傳統過濾功能之外，亦結合了檢查 點的觀念，能夠精確的在封包流過系統的每個階段來做封包過濾的動作。因此，

提供了更完整的封包過濾功能，也讓 Linux-based 的防火牆更有彈性、更為完善。

除了提供傳統的過濾規則，亦提供下列之功能。

(1) 提供 NAT 轉址的功能，提供來源端及目的端網路位址、通訊阜號(Port) 之修改功能。

(2) QUEUE 核心封包到核心的佇列，利用 iptables 下達規則通知核心將封 包 Queue 到核心佇列，讓應用程式取得核心佇列中的封包做過濾動作。例如，檔 案傳輸之掃毒程式等。

(3) 流量頻寬控管功能，利用過濾規則對不同連線之封包設定 mark 值(此 mark 值並非修改原封包之內容，而是修改封包在核心裡面對應的 mark 值)，之 後 Linux Traffic Control 就會依照封包上面的 mark 值將封包丟入不同的 Queue Disk 之中，透過 Device driver scheduling 機制來達到頻寬之分配。

Iptables 之結構則是透過在核心之中註冊不同 table 及 chain 來規劃不同過濾 規則之歸類 [12]。Table 包含 nat、mangle、filter 等；Chain 包含 PREROUTING、

INPUT、FORWARD、OUTPUT、POSTROUTING 分別對應到核心中 netfilter 提 供 之 NF_IP_PRE_ROUTING 、 NF_IP_LOCAL_IN 、 NF_IP_FORWARD 、 NF_IP_LOCAL_OUT、NF_IP_POST_ROUTING 等五個檢查點。底下則對不同 Table 之功能做簡介。

„ nat table: 隸屬於 nat table 之規則之用途為用來將封包之網路位址做轉 換(NAT)。而進入 nat table 只有每一連線的第一個封包，經過轉換後，

會將相關資訊記錄於 conntrack 之中，因此，後續的封包將自動轉 NAT 而不會再進入 nat table。另一個常見之應用為 Masquerading。內部網路 位址利用 WAN 端之 PPPoE 連線連結到網際網路而形成多對一的網路位 址對應。

„ mangle table: 隸屬於 mangle table 之規則之用途主要是修改封包之內 容。例如修改封包之 TTL、TOS(type of service)、Header 等等。若防火 牆系統在特定情況之下需要修改封包之內容則可在 mangle table 下達規 則來修改封包內容。

„ filter table: 隸屬於 filter table 之規則之用途為過濾系統上之封包。經過 規則比對下，則可對符合規則之封包做 DROP、LOG、ACCEPT、QUEUE 等相關動作。藉由這些動作來做封包紀錄與過濾，完成一般防火牆之需 求。

Iptables 提供三個主要 table 讓使用者可以針對不同的應用在不同的 table 下 規則。然而，規則並非所有檢查點都可以註冊，而是有相當的限制。以 NAT 為 例，剛進入系統之封包要修改目的端網路位址(DNAT)，因此註冊之檢查點為 PREROUTING；封包要離開系統時要修改來源端網路位址(SNAT)，因此註冊之 檢查點為 POSTROUTING；而系統上程序產生出來的封包也要修改其來源端網 路位址，因此註冊之檢查點為 OUTPUT。詳細整理於表一。

表 一、Table 與 Chain 列表

Table Chains

nat

PREROUTING OUTPUT

POSTROUTING

mangle

PREROUTING INPUT

FORWARD OUTPUT

POSTROUTING

filter

INPUT FORWARD OUTPUT

結合前一節所敘之 Connection Tracking 系統及 iptables 在核心註冊的三個 table，都是在 netfilter 架構所提供的檢查點上註冊個別功能。因此封包通過這些 系統的先後順序全仰仗著註冊時的優先權。Conntrack 系統及 iptables 註冊的三個 table 在核心中封包通過之順序由圖三所示。

圖三完整的顯示出封包在 netfilter 註冊之檢查點(NF_IP_PRE_ROUTING、

NF_IP_LOCAL_IN 、 NF_IP_FORWARD 、 NF_IP_LOCAL_OUT 、 NF_IP_POST_ROUTING)上所經過的 conntrack 系統及 iptables 註冊的 table 之流 程。由圖三橫向來看，可以得知每個檢查點上 conntrack 系統及 table 之優先順序；

由縱向來看，可以得知 conntrack 系統及 table 分布在哪些檢查點之上。

圖 三、檢查點、Conntrack 系統與 mangle table、filter table、nat table 關係(C 代 表 conntrack 系統，M 代表 mangle table，F 代表 filter table，N 代表 nat table)

透過下達 iptables 規則可以通知核心適當地處理通過系統上的封包。一條規 則除了需要指定 table、chain 之外，還需要指定規則條件 command、match (可有 可無)及動作(target or jump 指令)。詳細格式如下：

iptables [-t table] command [match] –j [target/jump]

‹ table: 該規則所隸屬的 table 為何。例如，”iptables –t mangle …..”則代 表該規則是置放在 mangle table 之中。若該欄位不指定，則代表使用預 設值 filter table。

‹ command: 下達各種 iptables 相關指令。如對特定 chain 做新增、刪除、

列 出 、 清 除 所 有 規 則 之 動 作 ”iptables –I chain” 、 ”iptables –A chain ”、”iptables –D chain”、”iptables –L chain”、”iptables –F chain”等。

‹ match: 針對封包特性做比對之相關功能。又可分為 Implicit matches 及 Explicit matches。Implicit matches，如判斷封包是否為 TCP 連線”-p tcp”

或是 UDP 連線”-p udp”等；Explicit matches，則是利用 kernel match module 寫作之方式來針對封包做特別的比對方式。如判斷封包狀態的

“-m state”、網路位址範圍的 ”-m iprange ”及限制封包數率的 ”-m limit”

等。

‹ target: 當封包符合所有 match 條件(match 條件可以有多個)之後，可以 利用 target 來決定封包在系統內的動作。例如，讓封包繼續往下個規則 走的 ”-j ACCEPT”、丟棄封包的 ”-j DROP”或是紀錄該封包的詳細資 訊”-j ULOG”等。若針對特殊應用需將核心的封包導到應用程式作判 斷，則可以利用”-j NFQUEUE”將封包 Queue 在核心中的佇列，等候應 用程式判斷完回傳 Verdict，再根據 Verdict 將封包送往下一個規則或是 丟棄。

‹ jump: 封包符合所有 match 條件後，除了可以利用 target 決定封包之決 策外，亦可以利用”-j RETURN”來跳過該 chain 上後續規則的比對動作。

本篇論文則是擴充 iptables explicit match 之方式，寫作 kernel 對應的 match module – USEROBJ 來完成連線擁有者之辨識與過濾功能。詳細如第三章系統架 構所敘。

第三章 系統架構

從傳統網路管理觀點來看，網路管理員會將每位使用者分發的網路位址與使 用者做一份對應關係的文件。再由防火牆記錄檔中所記錄的網路行為萃取出誤用 網路行為的連線，藉由連線的網路位址查詢事先定義好的網路位址與使用者對應 關係，來達到尋找出誤用網路資源的使用者。

然而這樣的方法，卻是有著相當大的隱憂。一則是惡意誤用網路資源使用者 可以藉由假造網路位址或利用他人網路位址來避免被網管人員稽查到，促使原網 路位址擁有人變成是受害者，使得稽查的結果喪失公信力。另ㄧ方面，在動態取 得網路位址的環境下，由於網路位址分發完全是動態決定，所以不能確定網路位 址與使用者的即時對應關係，造成無法確認誤用網路資源之連線之使用者。

因此，在我們的構想裡，將原本固定式的網路位址與使用者的對應變成動態 地對應紀錄在 Linux 核心之中。藉由身分認證伺服器的協助，更新 Linux 核心中 網路位址與使用者的對應關係。每當有新的連線，則利用該連線的網路位址查詢 Linux 核心中的對應關係，查出當下該網路位址的使用者為何，並紀錄在該連線 之中。等到該連線結束，則會在系統紀錄上，一併把使用者與網路位址等關係寫 在系統紀錄上。如此一來，就可以真正地指認出當下該連線的使用者為何，避免 固定式對應關係造成的誤認結果。

接下來我們將解釋應用的網路環境、Binding Manager、系統架構、各個元件 的實作及他們的相互作用。

圖 四、Co-operations between system components

在圖四中，呈現了元件在辨識/過濾檢查過程之間的相互作用。在我們的假 設裡，使用者必須在做任何網路行為之前必須通過身分的驗證。等到身分驗證完 成後，身分認證伺服器會送該使用者相關訊息給 Information Loader，詳細如 3.2 節所敘。Information Loader 收到之後則會更新核心中的 Hash Tables，如 3.3.4 所 敘。完成這些動作之後，使用者已經可以開始藉由產生網路連線來完成他的網路 行為。而網路連線的第一個封包(以 TCP 而言，則是指 connection request；以 UDP 而言，則是指該連線的第一個封包)則會送往 Connection Identifier，藉由該元件 來識別該網路連線的使用者為何，然後在送往 Filtering Component 做過濾、比對 的動作。之後該網路連線的後續封包則會直接送往 Filtering Component 做過濾的 動作。詳細的 Connection Identifier 跟 Filtering Component 敘述則是在 3.3.2 跟 3.3.3 節。

3.1 建置環境

本篇論文的目的在於辨識出每條網路連線真正的使用者，並且藉由使用者的 相關特性（如群組關係）來管理使用者的網路行為。我們假設每位使用者必須通 過身分驗證的程序來取得網路資源的使用權。而要完成這樣的特性可以藉由建置 的身分認證伺服器來完成。

圖五為一個簡化的校園網路架構。其中包含有線及無線等網路設施。在我們 的假設環境裡，每一個校園網路都會有架設一台或多台認證伺服器來提供使用者 認證的環境。另外，每一個校園網路的出口端也會放置一台應用層閘道器 (Application Gateway)用來決定使用者的網路連線資料是否能通過該校園網路。

而我們的方法就實做在應用層閘道器上。

圖 五、A Campus Environment

3.2 用戶資訊更新 (Binding Update)

圖六說明了使用者網路連線及身份認證的流程關係圖。在我們的應用層閘道 器中，事先預設一條過濾規則，該規則會封鎖每條使用者網路連線的網路封包。

使用者必須通過身分驗證才得以使用網路。當身份認證順利完成時，身分認證伺 服器上的 Binding Manager 則會傳送 User-Binding-Update 訊息給應用層閘道器。

User-Binding-Update 包含使用者帳號、來源端網路位址及隸屬群組名稱(如果該 認證系統有提供群組功能)。等到應用層閘道器上的 Information Loader 收到 User-Binding-Update 訊息之後，則會動態地更新應用層閘道器內 Linux 核心中 Hash Tables 的對應關係。

圖 六、Binding updates

我們利用微軟所開發的 Active Directory 為身分認證伺服器為例，使用者必 須透過 Active Directory 登入電腦然後才能夠使用網路資源。在使用者登入電腦 時，Active Directory 伺服器上的紀錄就會新增該使用者的帳號及網路位址。利用 微軟開發的 MSDN API 可以達到存取紀錄，萃取出每一筆連線的帳號及網路位

址。

在得到帳號及網路位址之後，利用 Active Directory 伺服器內建的指令 dsget、dsquery 來得到該使用者隸屬的群組。如圖七所示。

圖 七、Active Directory 群組查詢範例

在我們測試的 Active Directory 伺服器裡面新增兩位使用者 AD_Student_1、

AD_Teacher_1 與三個群組 Students、Teacher 與 Staff。借由 dsquery 跟 dsget 我們 可以知道 AD_Student_1 這位使用者隸屬於 Students 群組；AD_Teacher_1 這位使 用者隸屬於 Staff 群組跟 Teacher 群組。

利用收集到的使用者、網路位址及隸屬群組，Binding Manager 則會把這些 資訊送往我們所設計的應用層閘道器(Application Gateway)上的 Information Loader，作為更新 Linux 核心中使用者與網路位址對應的依據。

3.3 系統元件

在我們的實作的應用層閘道器中，整個系統架構根據其功能性質不同可分為 五大元件。其中，Connection Identifier 的實作方法則是在 Linux 核心模組 conntrack 的功能基礎之上，擴充網路連線之使用者辨識的功能。而 Filtering Component 的 實作方法則是分別實做成 Linux 核心與應用層 iptables 的 match modules。其他 的元件，如 Information Loader、Rule Generator、User Interface，則是寫成 Userspace 的程式。為了動態維護使用者、群組及網路位址的對應關係，我們也在 Linux 核 心裡面新增了三個 Hash Table (User Table, Group Table, IP-User Table)來記錄對 應關係。詳細的架構圖則如圖八所示。

圖 八、System Architecture

3.3.1 用戶資訊表 (Kernel Hash Tables)

我們在 Linux 核心新增了三個 Hash Table，分別是 User、Group 跟 IP-User tables。藉由新增這三個 Hash Table 來動態地維護使用者跟網路位址的對應關係。

User Object 包含了使用者最基本的資訊如使用者 ID(UID)、使用者帳號(User name)及群組 ID(GID)。而每個 User Object 則是被安排在一個 hash 過的使用者 陣列進而形成 User Table。Group Object 跟 User Object 類似，它包含了群組 ID (GID) 跟群組名稱(Group name)來提供群組的資訊。而每個 Group Object 也會被 安排在一個 Hash 過的群組陣列進而形成 Group Table。由於同一位使用者可能隸 屬於多個群組，所以在 User Object 中，則把群組表示成 Linked-List 來達到記錄 多群組的功能。

IP-User Table 利用 hash key 表示範圍為 16-bits，形成一個 16-bit 的 IP hash 陣列，Hash key 產生的方法則是取 32-bit 的網路位址取後面 16 bits 當作 Hash key。每一個 hash key 指向一個或多個紀錄網路位址及使用者 ID 的 IP-User object。由於使用 hash 的動作，所以利用 16-bit 的 Hash key 在搜尋 IP-User object 的結構的時候是非常有效率的。而有相同的後 16-bit 的網路位址則會因為有相同 的 Hash key，所以會 Hash 到同一位置而形成 Linked-List。

表二為 Binding Manager 送出來的對應關係。在表二之中，使用者 John 在同 一時間使用多台電腦；而使用者 Joe 則是隸屬多個群組。圖九、圖十與圖十一則 是依據表二而建構出來的 User Table、Group Table 與 IP-User Table 的例子。

表 二、Binding update 範例

使用者名稱 網路位址 隸屬群組

John 10.0.0.1 Students

Mary 10.1.0.1 Students

Joe 10.0.0.100 Staffs, Teachers

John 10.0.0.2 Students

圖 九、User Table 範例

圖 十、Group Table 範例

圖 十一、IP-User Table 範例

3.3.2 連線辨認元件 (Connection Identifier)

Connection Identifier 主要是對每一條網路連線做使用者的辨識並且把辨識 對應到的來源端/目的端 User Objects 記錄到該網路連線的 Connection Entry 中。

為了加速辨識的速度，我們捨棄每個封包都檢查的 Packet-based 的檢查機制而 是採用只檢查第一個封包的 Connection-based 的檢查機制。為了達成這個目標，

我們選擇在 conntrack 模組上做擴充。conntrack 核心模組利用相同的來源端/目 的端網路位址、來源端/目的端阜號跟 Protocol 的封包 hash 成同一 Connection Entry，進而可以更有效率的管理每一條網路連線。 因此利用 conntrack 模組的 Connection-based 觀念做為基礎並在上面擴充了辨識使用者的功能。同時也降低 了使用者辨認的運算複雜度，相對的提高了系統的效率。

當提出新的連線需求，Connection Identifier 會利用 IP-User Table 等完成身分 認證的動作。之後當新的連線在 Linux 核心中建立起來時，利用封包內夾帶的來 源端網路位址與目的端網路位址分別向 IP-User Table 查詢該封包對應的來源端 及目的端 User Object，而查詢到的結果則分別存在 Connection Entry 中的 sobj 及 dobj 欄位，代表該連線已通過身分認證並提供給 Filtering Component 做使用，

如此每一條連線僅執行一次認證動作，達成 Connection-based 之過濾觀念，而 不是如傳統一般使用 Packet-based 之過濾觀念。

3.3.3 連線過濾元件 (Filter Component)

當 Connection Identifier 完成辨識使用者的動作並把辨識到的 UID 找到對應的 User Object 標記在 Connection Entity 上時，則可以利用 User Object 提供的資訊 找出哪些網路連線是需要做過濾的。

Filtering Component 這個元件主要包含兩個模組。一個是在 Kernel-space 執行 的核心模組，另一個則是在 user-space 執行的模組。當使用 User-space 之指令 iptables 增加過濾規則時，會一併執行此 Userspace 之模組。User-space 模組主要 將過濾規則中 UID 與 GID 這些參數傳給 Kernel-space 的 USEROBJ 模組。核心 的 USEROBJ 模組則是負責利用 Userspace 傳進來的 UID 跟 GID 參數來找出對應 的網路連線。

每當 USEROBJ 核心模組收到封包，如果該連線已經經過比對就會直接回傳 比對結果。反之，則利用 Userspace 設定的 UID/GID 跟 Connection Entry 標記的 User Object 中的 UID/GID 做比對。為了避免之後相同 connection 的封包再做一 次 UID/GID 比對的動作，則會把比對的結果(match state)紀錄在 Connection Entry 中，加快每一條網路連線所需要的比對速度。

3.3.4 用戶資訊載入元件 (Information Loader)

Information Loader 負責的工作則是接收由 Authentication server 之 Binding Manager 發送的 User-Binding-Update 訊息，分析訊息中夾帶的使用者資料如 UID、User name、GID、Group name 跟來源端網路位址等，並且將這些資料轉成 核心中 Hash Table 所需的資訊並動態地對這些 Hash Table 做更新的動作。

3.3.5 過濾規則產生元件 (Rule Generator)

Rule Generator 跟上述的元件性質有所區別。這個元件是為了能讓網路管理 者藉由管理者圖形介面所設定的管理條件能夠自動的產生對應系統上所需要的 過濾規則格式而實作出來的。簡單的過濾規則格式如下：

iptables –t mangle –A PREROUTING –m USEROBJ [!] --sobj 0x10001 [!] --dobj 0x20003 –j DROP

如上述過濾規則所示，這條過濾規則封鎖(Drop)由 sobj 選項標示之所有來源 端使用者的編號為 1、群組編號為 1 且由 dobj 選項標示之目的端使用者的編號為 3、群組編號為 2 的網路連線。規則中的！係可有可無的選項，如果有設立則表 示相反的意思。這樣的規則格式帶來了有另三個好處:

(1) 不管使用者的網路位址怎麼變更，過濾規則都不用變動，減少不必要的 載入跟刪除規則的動作。

(2) 當同一使用者使用多台電腦上網(同一使用者有多個網路位址的情 形)，也只有一條過濾規則（同一使用者對應到相同 UID）。減少系統上 的過濾規則數。

(3) 藉由利用群組的觀念，只要對每個群組產生該群組的過濾規則，可以大 量減少以每位使用者而定的過濾規則數量。

這三個好處除了能使系統上的過濾規則趨於穩定，也減少過多過濾規則載入、移 除的次數，相對的也提高系統的效能。

3.4 系統連線紀錄 (Syslog)

當經過系統上的連線結束時，在我們實作的應用層閘道器會依據 Connection Entry 所記錄的 source/destination User Object 中的使用者、群組等資訊新增在系 統紀錄上。格式定義及實際的系統紀錄如下：

表 三、系統紀錄參數表

參數 參數敘述

Time 系統紀錄產生之系統時間

Action Connection 在系統上是否被封鎖

sUser 利用 Connection 來源端網路位址查詢到的使用者 sGrp 利用 Connection 來源端網路位址查詢到的群組 dUser 利用 Connection 目的端網路位址查詢到的使用者 dGrp 利用 Connection 目的端網路位址查詢到的群組 sIP Connection 來源端網路位址

dIP Connection 目的端網路位址 sPort Connection 來源端阜號 dPort Connection 目的端阜號

AppName Connection 經由 Port/L7-filter[]辨認的通訊協定名稱

表 四、系統紀錄範例

time=2008 03 01 09:28:14; action=BLOCK; sUser=ADUSER1; sGrp=Students; dUser=NULL;

dGrp=NULL; sIP=10.0.0.1; sPort=2061; dIP=10.100.1.1; dPort=21; AppName=ftp;

time=2008 03 01 09:28:30; action=Accept; sUser=ADUSER2; sGrp=Staff,Teacher;

dUser=NULL; dGrp=NULL; sIP=10.1.0.1; sPort=3381; dIP=10.100.1.2; dPort=80;

AppName=http;

第四章 數值分析

在這個章節裡，將對提出的方法做數值上的分析，嘗試定義提出的方法在不 同部分的效能評估，並轉換成 Asymptotic Notation [10]。藉由轉換成 Asymptotic Notation 的表示，則可知道我們提供的方法在計算機上的時間複雜度為何。

在 3.3.1 節中，介紹了三個在 Linux 核心中新增的 Hash Tables。在該節的例 子中，IP-User Table 中不是每一個 Hash position 都會指向一串以 User Object 形成 的 Linked-List。同樣的在 User Table 中也不是每一個使用者都會有一個所隸屬的 群組(根據身分認證伺服器而定)。為了簡化在計算上的複雜度，我們以N_userobj與

groups

N 這兩個符號代表取平均值後的 User Object 個數與平均每位使用者平均隸 屬的群組個數。詳細定義如 4.1 節所述。

在 4.1 節中，提供相關符號定義。在 4.2 節中，提供在 IP-User Table 中搜尋 User Object 的數值分析及 Asymptotic Notation、Connection Identification 的數值 分析及 Asymptotic Notation 與過濾規則辨認的數值分析及 Asymptotic Notation。

最後，在 4.3 節中討論在實際的環境裡面時間複雜度為何。

4.1 符號定義

‹ T_{match_ip}：比對 32-bit 網路位址所花的時間。

‹ T_hashkey：利用 32-bit 網路位址產生 Hash key 所花的時間。

‹ T_{find_userobj}：利用 32-bit 網路位址在 IP-User Table 上找到 User Object 所

花的時間。

‹ T_identify：比對新建立的連線屬於何 User Object 所花的時間。

‹ T_{match_uid}：比對 UID 所花的時間。

‹ T_{match_gid}：比對 GID 所花的時間。

‹ T_{match_userobj}：比對 User Object 所花的時間（包含比對 UID、GID 等）。

‹ T_{match_rule}：比對一條過濾規則所花的時間。

‹ T_{traverse_all_rule}：比對全部過濾規則所花的時間。

‹ N_userobj：在 IP-User Table 上，每個 Hash Position 平均擁有的 User Object

個數。

‹ N_groups：在 User Table 上，平均每個 User Object 擁有的群組個數。

‹ N_policies：系統上的過濾規則個數。

4.2 辨認數值分析

在此節我們提供本論文方法之演算法之時間複雜度，如式 4-1~式 4-5 所示。

當新的連線建立起來時，Connection Identifier 會利用 32-bit 網路位址取後 16-bit 當 hash key，並利用 hash key 在 IP-User Table 所指的 User Object Linked-List 搜尋

出 所 對 應 的 User Object 記 錄 於 Conntrack 之 中 。 由 於 搜 尋 過 程 是 搜 尋 Linked-List，因此我們定義每個 Linked-List 上的 Element (User Object)之機率分 佈為 Uniform Distribution；且T_hashkey與T_{match_ip} 之時間複雜度可視為 Constant Time。式 4-1 為此過程之時間複雜度證明。式 4-2 則是利用來源端及目的端網路 位址搜尋出來源端及目的端之 User Object。

( ) ( )

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡ + + +

+

= 1 2 ... ( )

_ _

_

_ match ip

userobj userobj ip

match userobj ip

match userobj haskey

userobj

find T

N T N

T N T N

T

∑

=

+

= ^userobj

N

i

ip match userobj

hashkey T

T N

1 _

1

_hashkey N^userobj T_{match ip}

T _{_}

2 1⎟⎟

⎠

⎜⎜ ⎞

⎝

⎛ +

+

= (式 4-1)

=Ο(N_userobj)

(

)

userobj find identify

N T

dstIP Userobj Find

srcIP Userobj Find

T

Ο

=

=

+

=

) (

2

) ( _

) ( _

_ (式 4-2)

在 Conntrack 上記錄好 User Object 之後，則會進入 Filtering Component 做封 包過濾的動作。其中 Filtering Component 會比對 Conntrack 中記錄的 User Object 所提供的 UID、Group Object 提供的 GID 與過濾規則中指定的 UID 與 GID。由 於 User Object 中記錄之 GID 為一 Linked-List，因此，我們定義 Linked-List 之每 個 Element 之機率分佈為 Uniform Distribution。式 4-3 提供 Filtering Component 之時間複雜度證明，其中T_{match_uid}、T_{match_gid}之時間複雜度可視為 Constant Time。

式 4-4 為比對來源端 UID、GID 與目的端 UID、GID 之時間複雜度證明。式 4-5 提供在最差環境下封包需比對所有過濾規則之時間複雜度。

( ) ( )

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡ + + +

+

= 1 2 ... ( )

_ _

_ _

_ match gid

groups groups gid

match groups gid

match groups uid

match userobj

match T

N T N

T N T N

T

∑

=

+

= ^groups

N

i

gid match groups

uid

match T

T N

1 _ _

1

_{match uid} N^groups T_{match gid}

T _{_ _}

2 1⎟⎟⎠

⎜⎜ ⎞

⎝

⎛ +

+

= (式 4-3)

=Ο(N_groups)

) ,

( _

) ,

(

_ Match_UserobjsrcUIDsrcGID Match UserobjdstUIDdstGID

T_{match rule}= +

=2(T_{match_ userobj}) (式 4-4) =Ο

(

)

) (

_ _

_

groups policies

rule match policies rule

all traverse

N N

T N

T

∗ Ο

=

= (式 4-5)

4.3 數值分析討論

在 4.2 節中，定義了相關的辨認時間複雜度，如式 4-1 到式 4-5 所示。其中 式 4-1 則為給定 32-bit 網路位址的條件下在 IP-User Table 尋找對應的 User Object。式 4-2 則為系統上新增的連線分別利用 32-bit 來源端與目的端網路位址 搜尋對應的來源端及目的端 User Object。式 4-3 為給定 UID 與 GID 的條件下與 User Object 中的 UID 與 GID 比對的時間複雜度。式 4-4 則為封包經過一條過濾 規則比對來源端及目的端之 UID 與 GID 之辨識的時間複雜度。式 4-5 則為封包 經過所有過濾規則的時間複雜度。

從式 4-5 可以看出封包在比對預設封鎖過濾規則前所需要比對的過濾規則的 時間複雜對為Ο(N_policies∗N_groups)。然而從傳統分群組的觀念來看，平均使用者不

會隸屬於太多的群組，在實際的應用環境裡N_groups實際上的值是很小的，所以不 會因為搜尋群組而降低比對 User Object 的效能。在 3.3.1 節提到 IP-User Table 是 利用 32-bit 網路位址的後 16-bit 來作為 Hash key。如果不同的 User Object 卻 Hash 到相同的 Hash position 形成 Linked-List 則表示這兩個 User Object 的網路位址前 16 bits 不同且後 16 bits 不同。以一個 Class B 的校園網路為例，網路位址的變化 在後面的 16 bits，因此 User Object 不會因為 Hash collision 而形成 Linked-List。

所以在 Class B 的校園網路中，N_userobj通常為 1。若以企業私有網路的觀點來看，

最大的私有網路範圍則是以 10.0.0.0 到 10.255.255.255.255。其中在相同的後 16-bit 的網路位址條件下，不同的前 16-bit 網路位址只會有 256 種。也就是說，

Linked-List 最多 Element 只會有 256 個。然而，通常企業子網路(subnet mask 255.255.0.0)的分割不會超過 10 個以上，所以N_userobj在實際應用上的值很小而不 會降低搜尋 User Object 之效能。

第五章 效能評測

在這個章節裡，我們利用在不同的過濾規則數量下測量 Forwarding Rate 跟 Maximum Latency [13][14] 來衡量我們改善方法的效率。為了量測實做的方法所 造成的負載，在我們比較原本 iptables 掛載模組情形下的 Forwarding Rat 跟 Maximum Latency 與掛載我們實做的 USEROBJ 模組情形下的 Forwarding Rat 與 Maximum Latency。從實驗數據顯示，我們的方法並沒有對原本 Linux 系統造成 重大的效能影響。

5.1 效能評測環境

測量所需的環境架構由圖十二所示。應用層閘道器的硬體平台為 Intel(R) Xeon(TM) 2.80 GHz，系統記憶體容量為 1 Gigabytes 且在硬體平台上安裝了三張 Gigabit 的網路卡。身份認證伺服器則選擇有支援群組觀念的 Active Directory。

利用身分認證伺服器提供的資訊來建構系統中的 Hash Tables。最後我們利用 SmartBit 來測量封包傳送速率跟最大延遲時間。

圖 十二、測試環境

在測量的過程中，我們藉由身分認證伺服器建立 1000 位屬於不同群組的使 用者，並且將這些資訊傳入到核心中的 Hash Tables。每位使用者至少有一個到多 個網路位址，但是網路位址不會重複。

測試的封包是由 SmartBit 所產生的。而測試的硬體平台利用兩張網路卡設定 成 Inline Mode (設定成 Bridge 模式)。SmartBit 從 Bridge 的一端灌入 UDP 的封 包且由 Bridge 上的另一端接受封包。當測試封包通過我們實作的系統，則系統 上的元件則開始對封包做使用者辨識跟比對的動作。就由這樣的測試環境來測量 整個系統的效能。

5.2 效能評測分析 (Performance Analysis)

為了測量系統的效能表現，我們所有的測試條件中的比對規則皆特殊設計 過，使每一連線皆無法滿足比對規則，如此每一條網路連線都必須經過所有的過 濾規則。此外，為達成轉送動作以量測最差情況下之最大效能，我們在所有比對 規則後，加入接受所有連線之比對規則。這個條件下所測出來的 Forwarding Rate 與 Maximum Latency Time 如圖十三跟圖十四所示。

在圖十三中，我們考慮過濾規則含 0、50、100、200 條的情況，可以發現當 系統上的過濾規則上升的時候，系統的 Throughput 卻是下降。這是因為 iptables 為 List-based 的防火牆系統 [15]，過濾規則越多，則系統效能下降 [16]。這就是 為什麼我們的系統效能也會跟著下降。

圖十四則是顯示出系統在最差的環境下所測量出來的 Maximum Latency Time。對於 Store and Forward 機器，最大延遲時間為接收端網路卡收到封包最後 一個 Bit 的時間到送出端網路卡送出封包的第一個 Bit 送出的時間差[13]。由圖十

四可以發現 Maximum Latency Time 還是隨著過濾規則而升高，同樣地在 [16] 中 也是如此。Frame Size 越小，表示在相同頻寬之下，封包數量越多。經過系統的 封包數量越多，則表示在系統內等待處理的封包就會越多；相對的，經過系統的 時間也就會越長。這也就是為什麼在圖十四的曲線會隨著 Frame Size 的增大而下 降。

0 200 400 600 800 1000

64 128 256 512 1024 1518

Frame Size (Bytes) Forwarding Rate (Mbps) No Rule

50 Rules 100 Rules 200 Rules

圖 十三、Forwarding Rate

0 2 4 6 8 10 12

64 128 256 512 1024 1518

Frame Size (Byte)

Latency (ms)

No Rule 50 Rules 100 Rules 200 Rules

圖 十四、Maximum Latency

5.3 負載分析 (Overhead Analysis)

由於在本系統增加原 Linux 之額外負載，為研究增加之負載對系統效能之影 響，是故我們比對原 Linux 系統與我們實作之系統兩者之效能。

我們測試 iptables 掛載模組跟我們實做的 iptables USEROBJ 模組在 Forwarding Rate 跟 Max Latency Time 的效能表現。為了單純測出 iptables 經過模組的效 能，我們實作了 NULL Module，該模組為一空的模組，不執行任何動作，即當 它被呼叫執行，他立即返回原呼叫程式。藉以評估 iptables 掛載模組之效能表現。

為了能夠客觀評估出所增加的負載，我們把過濾規則增多，藉以觀察我們提出 iptables USEROBJ 模組增加之額外負載的情形。

由圖十五到圖二十二分別顯示出在不同過濾規則下，iptables 掛載 NULL 模組 跟我們實作的 iptables USEROBJ 模組的 Forwarding Rate 跟 Latency Time。從中 我們可以發現，我們實做的方法並沒有造成嚴重的效能下降，也不會因為過濾規 則的數量過多而拖垮系統的效能。

Forwarding Rate with 250 Rules

0 200 400 600 800 1000

64 128 256 512 1024 1518

Frame Size (Bytes)

Forwarding Rate (Mbps)

NULL Module USEROBJ

圖 十五、Forwarding Rate with 250 Rules

Forwarding Rate with 500 Rules

0 200 400 600 800 1000

64 128 256 512 1024 1518

Frame Size (Bytes)

Forwarding Rate (Mbps)

NULL Module USEROBJ

圖 十六、Forwarding Rate with 500 Rules

Forwarding Rate with 750 Rules

0 200 400 600 800 1000

64 128 256 512 1024 1518

Frame Size (Bytes)

Forwarding Rate (Mbps)

NULL Module USEROBJ

圖 十七、Forwarding Rate with 750 Rules

Forwarding Rate with 1000 Rules

0 200 400 600 800 1000

64 128 256 512 1024 1518

Frame Size (Bytes)

Forwarding Rate (Mbps)

NULL Module USEROBJ

圖 十八、Forwarding Rate with 1000 Rules

Latency with 250 Rules

0 2 4 6 8 10 12 14

64 128 256 512 1024 1518

Frame Size (Bytes)

Latency (ms)

NULL Module USEROBJ

圖 十九、Latency with 250 Rules

Latency with 500 Rules

0 5 10 15 20 25

64 128 256 512 1024 1518

Frame Size (Bytes)

Latency (ms)

NULL Module USEROBJ

圖 二十、Latency with 500 Rules

Latency with 750 Rules

0 5 10 15 20 25 30 35

64 128 256 512 1024 1518

Frame Size (Bytes)

Latency (ms)

NULL Module USEROBJ

圖 二十一、Latency with 750 Rules

Latency with 1000 Rules

0 10 20 30 40 50

64 128 256 512 1024 1518

Frame Size (Bytes)

Latency (ms)

NULL Module USEROBJ

圖 二十二、Latency with 1000 Rules

第六章 結論與未來工作

在這篇論文中，我們提供了一個結合身分認證伺服器跟封包辨識、比對的方 法來完成以使用者為觀點的網路行為管理模式。我們的方法解決了網路位址被誤 用所造成的誤判使用者的問題，在動態取得網路位址的環境下也同樣適用。我們 的方法貢獻，(1)精確的判斷出網路連線的使用者，（2）支援群組化的管理，(3) 減少過濾規則不必要的載入、移除。從效能的分析來看，加入我們的方法也不會 額外造成系統的負擔。

在未來的計畫中，我們將把我們的方法套用在 IPv6 [17] 的環境裡面。我們 預想會遇到最嚴重的問題則是記憶體的使用量過大。因為 IPv6 所定義的網路位 址為 16 bytes，這表示在建構 IP-User Table 時得花更多的記憶體空間來做存取。

如何有效的運用有限記憶體空間來建構 IP-User Table 及在 IPv6 環境下有效降低 運算的複雜度將會是我們必須要解決的首要問題。

由於我們實做之應用層閘道器是置放於校園網路的出口，需處理校園網路之 全部流量，易成為整個校園網路的網路效能瓶頸。因此，我們將在未來計畫中結 合路由器來做聯合防禦之工作，將負載分散到各個路由器，減少網路效能之影響。

而在擁有 Mobile IP 的校園網路環境裡，用戶漫遊到他地需更換網路位址的 情形之下，也會造成我們的方法失效，因此支援 Mobile IP 也是在我們仍需解決 的項目之一。

在 IPv4 網路位址不足的環境裡，由於無法分配足夠的網路位址給校園網路 中的每一用戶，因此常利用 NAT 之技術來解決網路位址不足的問題。在這樣的環 境之下，我們的應用層閘道器需要置放於 NAT 機器與交換機中間，才能有效控管

NAT 中的用戶流量。如何設計擺放在學校出口之應用層閘道器與 NAT 內之應用層 閘道器相互溝通之通訊協定也是未來工作其中一環。

參考文獻

[1] Elizabeth Mackenzie and Kathryn Goldman, “Computer abuse, Information Technologies and Judicial Affairs,” in Proceedings of the 28th annual ACM SIGUCCS conference on User services: Building the future, Richmond, Virginia, United States , October 2000, pp. 170-176.

[2] Yu Jin, Zhi-Li Zhang, Kuai Xu, Feng Cao and Sambit Sahu, “Identifying and Tracking Suspicious Activities through IP Gray Space Analysis,” in Proceedings of the 3rd annual ACM workshop on Mining network data, San Diego, California, United States, June 2007, pp. 7-12.

[3] R. Droms, “Dynamic Host Configuration Protocol,” RFC2131, IETF, March 1997.

[4] Robert Beck, “Dealing with Public Ethernet Jacks – Switches, Gateways, and Authentication,” in Proceeding of LISA ’99: 13^th Systems Administration Conference, Seattle, Washington, USA, November 1999.

[5] Active Directory, Microsoft Corporation, URL:

http://technet2.microsoft.com/windowsserver/en/library/6f8a7c80-45fc-4916-80d 9-16e6d46241f91033.mspx?mfr=true [Accessed: March 2008].

[6] The Netfilter Core Team, URL: http://www.Netfilter.org [Accessed: March 2008].

[7] The Linux Kernel Archives, URL: http://www.kernel.org [Accessed: March 2008].

[8] K. Egevang, “The IP Network Address Translator,” RFC1631, IETF, May 1994.

[9] R. Russel and H. Welte, Linux Netfilter Hacking HOWTO, 2002. URL:

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.htm

l [Accessed: March 2008].

[10] E. Horowitz, S. Sahni and D. Mehta, Fundamentals of Data Structures in C++, Computer Science Press, 2000.

[11] Pablo Neira Ayuso, Netfilter’s connection tracking system, June 2006. URL:

http://people.netfilter.org/pablo/docs/login.pdf [Accessed: May 2008].

[12] Oskar Andreasson, Iptables Tutorial 1.2.2, 2006. URL:

http://iptables-tutorial.frozentux.net/iptables-tutorial.html [Accessed: May 2008].

[13] S. Bradner, “Benchmarking Terminology for Network Interconnection Devices”, RFC 1242, IETF, July 1991.

[14] S. Bradner, “Benchmarking Methodology for Network Interconnection Devices”, RFC 2544, IETF, March 1999.

[15] S. Acharya, J. Wang, Z. Ge, T. Znati, and A. Greenberg, “Traffic-Aware Firewall Optimization Strategies,” in Proceedings of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2006, June 2006, vol5, pp. 2225-2230.

[16] Daniel Hoffman, Durga Prabhakar, Paul Strooper, “Testing iptables,” in Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada, October 2003, pp. 80-91.

[17] S. Deering, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998.