Distributed Netflow Analysis for Limiting User Data Rates
林鳳銘 吳守豪 李蔡彥
國立政治大學電算中心
l96in@nccu.edu.tw, swu@nccu.edu.tw, li@nccu.edu.tw
摘要
隨著網際網路的發展，網路資源的有效管理與 運用，一直都是十分重要的課題。網路流量收集與 分析的工具已日趨成熟，但大部分此類工具的系統 架構，多將收集與分析的工作集中在同一台主機 上。當病毒肆虐或在網路流量較高的主幹上，此類 系統架構常有擴充性不足的情形發生，使得正常的 收集與分析工作無法順利進行。因此在本論文中， 我們提出了一個分散式計算的架構，重新實作流量 分析程式，以依照需要將某一網段或某些特定封包 的流量資訊，即時傳送給其他專屬的資料分析伺服 器。此方式可將流量收集與分析的負載，分散至多 個伺服器，以有效提高流量分析品質。另外，我們 嘗試將此分析所得的資料，做初步的流量管制應 用。換言之，我們將分析出具有異常流量的主機資 訊，回饋給路由器，以自動進行限速的設定，並主 動通知主機使用者改善。我們以此實做出的系統進 行實驗，證明這個自動調整流量的方式，能有效改 進網路管理品質。 關鍵詞：分散式流量分析，Netflow，流量限制，降 速。1. 簡介
由於網際網路不斷發展，連結上網際網路的機 器數量以驚人的速度成長，而一般的區域網路中連 接的主機也在不斷的增加。隨著主機數量的增加， 網路的流量亦自然隨之提高，而如何分析網路的使 用情形，以善用網路資源，便成了十分重要的課 題。通常為了計算網路上的流量，許多網路中心都 會架設流量伺服器，以收集網路上流量的資訊[2]； 之後再根據此流量資訊進行詳細的分析，以找出網 路上發生的一些異常狀況[1][3][9][10]。根據不同的 異常狀況，管理者可以再設計不同的處理方式以因 應之。這些網路流量統計可以用來做為網路計價的 依據[12][13]，也可以用來分析網路的特性[8]。例 如，[4]就以流量研究出網路的一些不正常的使用狀 況，而 [7] 則提出了利用網路流量來進行被動式的 資訊流行為偵測。 目前這些網路流量分析的工作，多藉由收集流 量資訊的主機來執行。對於流量不大或是網路規模 較小的單位而言，單一主機的架構或許足以應付； 但是當網路流量成長到一定的程度時，要在同一部 機器上同時收集並計算網路流量，就會顯得有些吃 力。例如，網路上發生病毒、 spam、或是想要即 時將流量資訊存入資料庫以便稍後分析時，大量的 運算將會拖慢這台伺服器，甚至發生來不及運算的 情況。 為了解決上述的狀況，在本論文中，我們提出 了一個分散式流量分析系統架構，以將某一網段或 某些特定封包的流量資訊，即時傳送給其他專屬的 伺服器上。在文獻上，已有許多流量資訊收集與分 析的系統被提出來，其中多數是以單一主機收集 Netflow 功能所提供的流量資訊；其中在[6]可以找 到以 C 語言實做的這一類流量收集程式。為了達到 分散式流量處理的目的，我們必須將單一主機收集 到的流量資訊傳送到一個以上的流量分析主機。為 此，我們重新實做了收集 Netflow 流量的程式。如 此一來，我們不但能有效降低接收路由器封包的伺 服器之負載，同時也可以即時針對一些異常的網路 行為或主機執行更詳盡的流量分析。 過去在網路管理（特別是學校宿網的管理） 上，對於即時流量過大的主機，所採取的制裁手段 通常是「鎖卡」（禁止該主機連上 Internet）。這個 處理的方式最有效也最直接，可以即時阻止網路頻 寬 被 該 主 機大 量 佔 用 。雖 然 管 理 者可 以 事 先 以 E-mail 通知該主機的使用者，不過由於鎖卡後剝奪 了該主機的上網能力，因此一旦該主機的使用者沒 有在事前收到 E-mail 就被停止連上 Internet 的能 力時，該主機的使用者可能認為網路出了問題，以 致無法連通 Internet，因此也無法透過網路瞭解該 主機無法上網的原因。為了解決這個問題，本論文 提出了一個比較折衷的處理方式。我們根據分散式 流量分析，對於流量過大的主機採取降速（降低該 主機使用網路頻寬的速度）的措施，並將降速的資 訊即時於網上公布。此時由於只是上網的速度變慢 了而不是再也無法連接網路，因此該主機的使用者 可以很快的察覺到異狀，並且透過網路查知該主機是否已被限速，而採取必要的補救措施。如此一 來，將可以同時保障該主機與同一網段底下網路使 用者的權益。以下謹就分散式流量資訊收集及即時 限速的方式進一步提出我們的作法。
2. 分散式網路流量資訊的收集
2.1 系統架構 路由器是網路封包的交換中心，因為網路上的 訊息需靠路由器的傳送以達到目的地。因此，在適 當的路由器上，我們可以有效的收集到網路上的流 量資訊。一般而言，常見的流量資訊收集架構如圖 一所示[1]。此流量收集架構，屬於集中式架構。圖 中的 Netflow 伺服器負責收集路由器送出的封包 資訊，同時該伺服器也負責路由器封包的分析運 算。這個架構適用於規模較小而且網路負載較輕的 網路，用來做統計計價或偵測網路異常使用現象。 然而，對於區域網路中心而言，除了需要分析自己 的流量資訊外，也必須一併分析底下所連接網路的 流量，因此所需處理的資料量極大。這些流量資訊 的大小，可以大到每十分鐘數百萬位元組之多。為 了避免佔用過多的磁碟空間，我們常會以即時壓縮 的方式處理接收到的流量資訊。如果我們同時想在 這部 Netflow 伺服器上即時進行流量資訊分析，則 必須將此壓縮的流量資訊作解壓縮後方能進行。即 時運算與分析這麼大的流量資訊將會使得該伺服 器的負載提高，甚至發生漏接路由器所送出流量封 包的情況。如果同時又遭受病毒的攻擊（例如不斷 以小封包偵測可攻擊的 web 伺服器），流量的資訊 就更可觀了。為了解決這種情況，同時使用資料庫 來儲存經過計算後的即時流量資訊，我們提出了圖 二所示的分散式流量分析架構。 根據圖二的分散式的流量分析架構，我們可以 發現這個架構與[1] 所使用的流量收集方式最大的 差別在於 Netflow 伺服器上只執行了一個 Netflow Dispatch Daemon，這個 Daemon 負責即時收集路由 器送傳送出來的流量資訊，同時它可以根據使用者 需求將一些特定流量資訊透過網路傳送給遠端的 Netflow Data Collector 上。由於這些 Netflow Data Collector 所收到的流量資訊屬於篩選過的特定流量 資訊（如下一小節說明），因此流量資訊較小，有助 於稍後的分析與計算。 2.2 流量資訊的格式 Netflow 是由 Cisco 所提出的專屬技術規格 [5]，因而所傳送出來封包的內容也受到該規格的規 範。我們所重寫的分散式流量分析程式，僅擷取了 Netflow 規格中的部分必要欄位，所抓取出來的資訊 欄位如圖三所示。 我們所收集的流量資訊與[1]不同之處在於分散 式流量資訊少了資訊流發送端路由器介面編號與資 訊流接收端路由器介面編號。對於流量分析而言， 我們並不在意所分析的流量流經路由器那一個介面 編號(interface number)。 我們已實做完成此一分散式流量資訊收集與分 析系統，並完成了初步的實驗測試。為了縮短系統 開發所需要的時間，此系統雛形係以 Perl 語言[11] 撰寫，以簡化程式開發時間，換取執行上的效率。 NetFlow Server Router interface 1 interface n interface z Daemon 圖一、集中式流量資訊的收集 NetFlow Dispatch Daemon Router interface Packet Export Interface interfaceNetflow Packet Export
NetFlow Data Collector Packet DataBase NetFlow Data Collector Packet DataBase 圖二、分散式流量資訊的收集 Destination IP Address
Protocol Packets Octets
Source IP Address：資訊流的來源端 IP 位址。 Destination IP Address：資訊流的接收端 IP 位址。 Protocol：資訊流所使用的通訊協定。 Source Port：資訊流發送端程式所使用的埠號。 Destination Port：資訊流接收端程式所使用的埠號。 Packets：資訊流等於多少個封包。 Ocets：資訊流的大小。 Source IP Address Source Port Destination Port 圖三、所收集的特定流量資訊格式
3. 使用者上網速度的限制
網路是一個開放式頻寬共享的環境，任一位連 上網路的使用者，都期望能盡可能地使用網路的頻 寬。由於網路的頻寬是固定的，因此在同一時間內， 如果大家同時競相使用網路頻寬，則必有排擠效 應。使用到較少網路頻寬的使用者甚至會以為網路 變慢或故障了。網路管理者最不希望發生的事，便 是在同一網段上有人架設非法的各式網站。由於架 站的伺服器是以背景的方式來執行，因此只要頻寬 許可，這個架站的伺服器最有希望使用較多的網路 頻寬。倘若發生了這種情況，同一網段內的使用者 將會發現網路變慢了。如果這個網段又是以集線器 (hub)來串接，則碰撞(collision)的效應，將使網路變 慢情形更加嚴重。 為了找出使用過量網路頻寬的使用者，我們可 以藉由分散式流量統計來完成。我們將特定網段的 流量資訊匯出到某一部 Netflow Data Collector 上， 同時在這部伺服器上詳細分析流量資訊，以找出過 量頻寬的使用者。當我們找到了使用過多頻寬的機 器時，為了避免同一網段上的使用者受到影響，我 們通常會採取的手段是「鎖卡」，以切斷該部機器上 網的管道，使其與網際網路隔絕。這個方式可以解 決了同一網段上其他使用者上網速度慢的問題，但 卻不見得可以透過網路通知到使用者進行改善。因 此，在這裡我們提出的另一個以「降速」為主的解 決方式。由於我們不斷即時計算網路流量，一旦發 現有機器開始佔用大量的網路頻寬時，我們的流量 統計伺服器就可以開始即時監控該主機接下來的動 作。如果此主機一直都使用過量的頻寬，我們就會 主動地限制該主機可以使用的網路頻寬大小。 3.1 系統架構 為了達成即時自動降低使用者佔用大量網路 頻寬的動作，我們所採用的網路架構，如圖四所示。圖中的多個 Netflow Data Collector 持續接收 Netflow Dispatch Daemon 所 傳 送 出 來 的 流 量 資 訊，並即時計算流量資訊。一旦發現有使用者過量 使用網路頻寬時，立即將流量過大的使用者 IP 記 錄下來，然後再依據路由器所需要的設定方式加以 封裝，透過網路傳送到路由器上。而路由器除了為 底 下 串 接 的使 用 者 傳 送一 般 封 包 外， 還 會 根 據 Netflow Data Collector 所送過來的指令，對需要降 速的主機，進行限制頻寬的降速動作。降速是透過 路由器的設定達到的。由於資料流速檢查需要路由 器上的 CPU 執行額外的計算，因而加重路由器的 負載，因此限速的主機數量需有所限制。以實驗中 的 Cisco 6509 路由器而言，由實際的經驗得知當需 要被降速的 IP 在不超過 100 個的情況下，路由器 的 CPU 負載仍可低於 10 %，因此額外的計算負 載仍在可接受的範圍內。 雖然上述的降速設定是針對主機 IP 而做的，但 比較嚴謹的說法應是根據 MAC 位址來降速。只是 目前實驗的環境是宿舍網路，而我們宿舍上網的先 決條件是必須由住宿生上網登記 IP 與 MAC 位址的 對照關係。在這種情形下，由於 IP 位址與 MAC 位 址是一對一的關係，所以在這裡執行的降速動作對 IP 與 MAC 位址而言是相同的。 3.2 降速演算法 就目前而言，一般的區域網路都屬 Ethernet 的 網路環境，串接的方式多為以集線器(hub)串連。因 此以下我們將以 Ethernet 為例說明。對一個網路上 的主機而言，需要被降速的原因包含以下兩點：第 一、當使用者所使用的流量超過 Ethernet 頻寬的一 定比例(例如 30 %，則初始流量上限為 10Mbps * 30%= 3 Mbps)；第二、當該主機或許由於受到病毒 感染，而不斷地在網路上傳送攻擊性的小封包，導
Netflow data collector Real Time Netflow Data Calculation Reducing Bandwidth ? NO Yes Formatted reduce bandwidth string
User Machine User Machine
Export Nertflow data Router Receiving Reduce Bandwidth string ? Reducing Bandwidth Yes NO Normal Operation Netflow Dispatch Daemon Nertflow data 圖四、限制使用者網路頻寬之架構圖 Overuse bandwidth ? Real Time Netflow Data Process
Overuse Counter + 1 Overuse Counter > 2 ? No Reducing User Data Rate Yes User already
has limited data rate ?
No
Yes No
Get User Data Rate and Bandwidth Limit
Yes Overuse Counter - 1
致網路上到處充斥著一些沒有機器回應的封包資 訊。兩個原因只要其中之一成立，便構成了降速的 起始條件。 本研究所用的降速演算法，如圖五所示。假設 某一主機 i 的即時流量經過計算後為 fi。我們首先 檢查該主機 IP 是否存在於被降速表格中。如果是， 則系統就會一併計算該主機被降速後的頻寬上限 hi；否則將 hi設定為該主機之初始流量上限 hmax。 如果該系統超量使用頻寬(fi>hi)，則我們會把該系統 的超量計數器(ci)增加，以得到連續超量的次數。如 果 ci未超過連續超量次數上限 cmax，則系統目前毋 須改變設定；但是如果 ci大於或等於 cmax, (ci >= cmax)，則表示這個 IP 連續超量使用網路頻寬。此 時系統會將頻寬上限再度打折(hi=max(hmin, hi*r), 0<r<1, r 是速度調降的比例)，並將此降速資訊格式 化成路由器可以接受的格式，再傳給路由器以即時 執行降速的動作。 假設目前即時收集的主機流量顯示該 IP 未超 量使用頻寬上限，則超量計數器(ci)可以歸零，並且 系統會針對該 IP 是否已經被降速而採取必要升速 措施。換言之，hi=min(hmax, hi/r), 0<r<1。如果 hi = hmax，則代表該主機已升速至起始速度，此時我們 可以將此 IP 從限速表中剔除。 3.3 實際範例 我們架設了一台測試用的主機來驗證我們所提 出架構的可行性。我們在這部主機上架設了一個 FTP 伺服器，然後透過網路中的其他台主機不斷地 從這台 FTP 伺服器上抓取資訊，以造成這部測試 主機過量使用網路頻寬的條件。經過 Netflow Data Collector 計算後發現該主機的行為異常，因此需降 速以限制頻寬。我們將降速的條件格式化後，傳送 給相對應的管理路由器上，再由路由器根據降速條 件執行相對應的降速動作。 圖六是我們實驗結果的圖形輸出。圖六中的 Y 軸表示每十分鐘該主機的流入與流出量(藍色代表 流出量而綠色表示流入量)，X 軸則為時間。圖六 中的主機(IP:140.119.xx.xx) ，在 15:00 與 16:00 一 小時內不斷地流出資訊，平均每十分鐘的流量都大 於 400 MB( 等 於 400 * 8 * 10^6/600 = 5.33 Mbps)，當我們所設計的系統發現這個狀況時，在 16:00 通知相對應的管理路由器進行降速的動作。 從圖六看出該測試主機從 16:00 之後每十分鐘的 資料傳出量已經小於 25 MB ( 25 * 8 * 10^6/600 = 0.33 Mbps)，這部主機的資料傳輸量已明顯地降低。
4. 結論
分散式流量統計的優點在於可以將接收到的 流量資訊計算分散到一個以上的主機，而不必侷限 於 Netflow 伺服 器的運算能 力，同時能 夠降低 Netflow 伺服器的系統負載。除了減低系統負荷 外，也能較輕易做到異質性的資料分析工作；例 如，可以為特定網段或某一部主機，採取不同方式 的流量計算方式。這種分散式流量統計，對於流量 極大的區域網路中心而言，十分重要。它可以將所 串接的連線單位事先分類，然後分別將流量資訊傳 送到不同的 Netflow Data Collector 上作個別計 算，以避免因資訊量過大而發生無法即時運算的問 題。 網 管 人 員 在 面 對 使 用 者 過 量 使 用 網 路 頻 寬 時，除了將該超量主機隔離外，還可以根據需要即 時地降低該主機可以使用的頻寬。本論文便提出了 這樣一個即時降低流量上限的方法。網路存取的速 度在降速後會變慢，如果該主機的使用者此時也在 線上操作這部主機，他將可以明顯地感覺到差異 性。這個作法的優點是讓該使用者在仍可上網的情 況下，透過網路瞭解自已經過量使用網路資源，並 且尋找解決之道。 本文中所建立的分散式流量分析機制，是根據 來源端與目的地端的 IP 位址來分析流量，降速的 動作則交由路由器來執行。這樣的作法多少會加重 路由器的負載。由於需要被降速的 IP 是以存取表 單的方式交由路由器來循序執行，因此當表單越大 時，路由器的負載也會增加。所以如何決定一個適 合的表單大小，以不嚴重影響路由器效能，將是一 個有待後續實驗的重要問題。參考文獻
[1] 林鳳銘、吳守豪、李蔡彥, “Intrusion Detection: a Network View”, in Proceeding s of TANet 2001Conference, pp. 34-48, 2001.
[2] 范修維, “網路流量分析系統之建置及應用,” in
Proceedings of TANet 2001 Conference, pp.
419-424, 2001.
[3] 黃文穗、林守仁, “利用 Netflow 建置 Code Red Worm 偵測系統,” in Proceedings of TANet 2001
Conference, pp. 471-474, 2001.
[4] P. Barford and D. Plonka. “Characteristics of Net-work Traffic Flow Anomalies”, in Proceedings of
ACM SIGCOMM Internet Measurement Workshop,
Nov. 2001.
[5] Cisco’s IOS NetFlow Feature,
http://www.cisco.com/warp/public/732/netflow/ [6] ftp://ftp.eng.oar.net/pub/flow-tools
[7] C. Fraleigh, C. Diot, B. Lyles, S. M., P. Owezarski, D. Papagiannaki, and F. Tobagi. “Design and De-ployment of a Passive Monitoring Infrastructure,” in Proceedings of PAM 2001 Workshop, April 2001.
[8] A. C. Gilbert, Y. Kotidis, S. Muthukrishnan, M. Strauss, “QuickSAND: Quick Summary and Analysis of Network Data,” DIMACS Technical
Report 2001-43, 2001.
[9] D. Moore, G. Voelker, and S. Savage, “Inferring Internet Denial-of-Service Activity,” in
Proceed-ings of 2001 USENIX Security Symposium,
Wash-ington, DC, August 2001.
[10] B. Nickless, J.-P. Navarro, and L. Winkler, “Combining Cisco NetFlow Exports with Rela-tional Database Technology for Usage Statistics, Intrusion Detection, and Network Forensics”,
Usenix, LISA, 2000.
[11] Perl, http://www.perl.com.
[12] S. Shenker, D. Clark, D. Estrin, S. Herzog, “Pricing in Computer Networks: Reshaping the Research Agenda,” Telecommunications Policy, vol. 20, No. 3, April 96.
[13] F. Travostino, “Towards an Active IP Account-ing Infrastructure,” in the ProceedAccount-ings of the
