杭靜文,羅洪斌,劉 穎
(北京交通大學(xué)電子信息工程學(xué)院,北京100044)
近年來(lái),隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展和企業(yè)大量業(yè)務(wù)的需要,構(gòu)建在網(wǎng)絡(luò)上的應(yīng)用越來(lái)越多,其復(fù)雜程度及對(duì)網(wǎng)絡(luò)的依賴程度也日益提高,各種各樣的網(wǎng)絡(luò)問(wèn)題也隨之產(chǎn)生。然而,由于網(wǎng)絡(luò)的異構(gòu)性和復(fù)雜性,對(duì)網(wǎng)絡(luò)行為及其特征的了解仍然有限,因此采用網(wǎng)絡(luò)測(cè)量方法獲取網(wǎng)絡(luò)參數(shù)是研究網(wǎng)絡(luò)性能、進(jìn)行網(wǎng)絡(luò)管理的有效方法,同時(shí)它對(duì)解決網(wǎng)絡(luò)問(wèn)題及進(jìn)行網(wǎng)絡(luò)規(guī)劃有著重要意義。
網(wǎng)絡(luò)流量監(jiān)測(cè)方法主要有基于SNMP、基于分組嗅探、基于ROMN和基于Flow技術(shù)等幾種[1]。其中,NetFlow是一種網(wǎng)絡(luò)數(shù)據(jù)包交換技術(shù),并可同步實(shí)現(xiàn)對(duì)高速轉(zhuǎn)發(fā)的IP數(shù)據(jù)流進(jìn)行測(cè)量和統(tǒng)計(jì)。最新的NetflowV9版本已經(jīng)提交給IETF以IPFIX(IP Flow Information Export)[2]的名稱進(jìn)行標(biāo)準(zhǔn)化,在正式獲得采納前,NetFlow已經(jīng)獲得許多主流廠商的支持,被廣泛應(yīng)用于網(wǎng)絡(luò)安全管理[3]與流量監(jiān)測(cè)[4~5]。
本文首先介紹現(xiàn)有的網(wǎng)絡(luò)流量監(jiān)測(cè)方法,對(duì)各自的優(yōu)缺點(diǎn)進(jìn)行簡(jiǎn)單分析,詳細(xì)介紹了NetFlow技術(shù),并提出了一種基于NetFlow的流量監(jiān)測(cè)系統(tǒng)模型。該模型利用NetFlow技術(shù)進(jìn)行流量監(jiān)測(cè),通過(guò)提取相應(yīng)信息組成流記錄,將流記錄匯總存入數(shù)據(jù)庫(kù),為進(jìn)一步數(shù)據(jù)挖掘提供依據(jù)。該模型采用自定義模板采集流量信息,靈活性高,可擴(kuò)展性強(qiáng)。測(cè)試證明了該模型的可行性,能夠?yàn)榫W(wǎng)絡(luò)流量分析提供合理高效的數(shù)據(jù)支持,對(duì)于網(wǎng)絡(luò)管理、異常檢測(cè)以及網(wǎng)絡(luò)規(guī)劃等方面有重要意義。
網(wǎng)絡(luò)流量監(jiān)測(cè)是指捕獲網(wǎng)絡(luò)中流動(dòng)的數(shù)據(jù)包,并通過(guò)查看分組內(nèi)部數(shù)據(jù)以及進(jìn)行相關(guān)的協(xié)議、流量分析、統(tǒng)計(jì)等來(lái)發(fā)現(xiàn)網(wǎng)絡(luò)運(yùn)行中出現(xiàn)的問(wèn)題,它是網(wǎng)絡(luò)和系統(tǒng)管理人員進(jìn)行網(wǎng)絡(luò)故障和性能診斷的有效工具,下面介紹幾種常見(jiàn)的網(wǎng)絡(luò)流量監(jiān)測(cè)方法。
簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol, SNMP)[6]是專(zhuān)門(mén)設(shè)計(jì)在IP網(wǎng)絡(luò)中管理網(wǎng)絡(luò)節(jié)點(diǎn)(路由器、交換機(jī)等)的一種標(biāo)準(zhǔn)協(xié)議,它是一種應(yīng)用層協(xié)議,是TCP/IP協(xié)議族的一部分?;赟NMP的流量信息采集的核心思想是在每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)上存放一個(gè)管理信息庫(kù)(Management Information Base, MIB),并由節(jié)點(diǎn)上的代理Agent負(fù)責(zé)維護(hù),管理站中的網(wǎng)絡(luò)管理系統(tǒng)(Network Management System, NMS)通過(guò)應(yīng)用層協(xié)議對(duì)這些信息庫(kù)進(jìn)行統(tǒng)一管理。
當(dāng)網(wǎng)絡(luò)設(shè)備不支持SNMP,或者用戶需要細(xì)節(jié)網(wǎng)絡(luò)流信息,如網(wǎng)絡(luò)協(xié)議類(lèi)型、某特定IP地址的流量時(shí),經(jīng)常采用實(shí)時(shí)抓包分析的分組嗅探方法[7]。然而這種方法只能通過(guò)某個(gè)網(wǎng)絡(luò)接口進(jìn)行抓包,并且?guī)缀跛鞋F(xiàn)存的分組嗅探工具都是基于Libpcap[8]程序包運(yùn)行的,其中包括最早的TcpDump[9]、當(dāng)前流行的Wireshark[10]、Sniffer等。
遠(yuǎn)程網(wǎng)絡(luò)監(jiān)控(Remote Network Monitoring,RMON)是IETF定義的MIB[11],它是為了解決SNMP協(xié)議在日益擴(kuò)大的分布式網(wǎng)絡(luò)中的局限性所提出的。RMON MIB的主要目的是使SNMP更為有效、更為積極主動(dòng)地監(jiān)控遠(yuǎn)程設(shè)備,提高傳送管理信息的有效性、減少管理站的負(fù)擔(dān),滿足監(jiān)控網(wǎng)絡(luò)性能的目的。
目前基于流(Flow)的分析技術(shù)主要有2種:sFlow和NetFlow。sFlow采用數(shù)據(jù)流隨機(jī)采樣技術(shù),可以使用超大網(wǎng)絡(luò)流量環(huán)境下的流量分析,為用戶提供詳細(xì)實(shí)時(shí)的流量性能分析,并能分析流量趨勢(shì)以及存在的問(wèn)題,目前只有HP、Extreme Networks等少數(shù)廠商部分型號(hào)的交換機(jī)支持sFlow,它的缺陷是輸出信息都是單個(gè)數(shù)據(jù)包,沒(méi)有會(huì)話的概念,進(jìn)行數(shù)據(jù)分析時(shí)需要聚合計(jì)算。NetFlow的特點(diǎn)是其流量統(tǒng)計(jì)基于IP流,IP流包含了豐富的信息,非常適合網(wǎng)絡(luò)性能的監(jiān)測(cè)和分析。
綜上所述,基于SNMP和RMON[12]的流量監(jiān)測(cè)方法,主要檢測(cè)網(wǎng)絡(luò)設(shè)備端口整體流量,流量信息內(nèi)容過(guò)于簡(jiǎn)單,無(wú)法針對(duì)用戶與業(yè)務(wù)進(jìn)行分析;基于分組嗅探的流量監(jiān)測(cè)方法,由于其需要采集的數(shù)據(jù)量過(guò)大,因此不適合大流量的網(wǎng)絡(luò)環(huán)境,并且輸出信息不支持會(huì)話概念。以上這些方法都無(wú)法滿足高帶寬網(wǎng)絡(luò)環(huán)境的性能要求和分析需求,目前大多數(shù)流量監(jiān)測(cè)系統(tǒng)采用NetFlow作為主要的流量采集手段。
NetFlow是一種網(wǎng)絡(luò)數(shù)據(jù)包交換技術(shù),它首先被用于網(wǎng)絡(luò)設(shè)備對(duì)數(shù)據(jù)交換進(jìn)行加速,并可同步實(shí)現(xiàn)對(duì)高速轉(zhuǎn)發(fā)的IP數(shù)據(jù)流進(jìn)行測(cè)量和統(tǒng)計(jì)。
NetFlow以“流”為采集單位進(jìn)行數(shù)據(jù)統(tǒng)計(jì),能對(duì)IP網(wǎng)絡(luò)的通信流量進(jìn)行詳細(xì)的行為模式分析和計(jì)量。NetFlow中的關(guān)鍵概念是“流”(flow),它由以下7個(gè)關(guān)鍵域定義:
(1)源IP地址(Source IP address);
(2)目的IP地址(Destination IP address);
(3)源端口號(hào)(Source Port Number);
(4)目的端口號(hào)(Destination Port Number);
(5)協(xié)議類(lèi)型(Layer 3 Protocol Type);
(6)服務(wù)類(lèi)型(Type of Service);
(7)輸入邏輯接口(Input Logical Interface)。
一個(gè)NetFlow流定義為在一個(gè)源IP地址和目的IP地址間傳輸?shù)膯蜗驍?shù)據(jù)包流,且所有數(shù)據(jù)包具有共同的傳輸層源、目的端口號(hào)。不同數(shù)據(jù)包,如果以上7個(gè)關(guān)鍵域都匹配,將被視為同一股流。每股流的開(kāi)始時(shí)間、持續(xù)時(shí)間,流中報(bào)文數(shù)、字節(jié)數(shù)等信息都被記錄下來(lái)。當(dāng)該股流結(jié)束或到期后,輸出過(guò)程將這些流信息根據(jù)自定義的模板組成NetFlow報(bào)文。
在NetFlow技術(shù)的演進(jìn)過(guò)程中,開(kāi)發(fā)出了5個(gè)主要的實(shí)用版本,即NetFlow V1,V5,V7,V8和V9,NetFlow V9[13]目前被IETF組織從5個(gè)候選方案中確定為IPFIX標(biāo)準(zhǔn)。不同版本間的差異直觀的表現(xiàn)在輸出報(bào)文格式上,NetFlow V9是一種全新的靈活可擴(kuò)展的NetFlow數(shù)據(jù)輸出格式,采用了基于模板(Template)的統(tǒng)計(jì)數(shù)據(jù)輸出,可以很方便地添加需要輸出的數(shù)據(jù)域,解決了數(shù)據(jù)類(lèi)型不斷變化的需求,同時(shí)支持多種NetFlow新功能如Multicase NetFlow,BGP Next Hop V9,NetFlow for IPv6等。
流量監(jiān)測(cè)系統(tǒng)中的采集對(duì)象是指產(chǎn)生NetFlow流記錄的網(wǎng)絡(luò)設(shè)備,主要是中高端路由器和高端交換機(jī)。對(duì)于采集對(duì)象的選擇,要根據(jù)網(wǎng)絡(luò)結(jié)構(gòu)以及流量監(jiān)測(cè)系統(tǒng)的綜合情況來(lái)決定,可以是網(wǎng)絡(luò)的聚合層設(shè)備,也可以是核心層設(shè)備。流量監(jiān)測(cè)系統(tǒng)由采集器和收集器以及數(shù)據(jù)庫(kù)組成。本文所提出的流量監(jiān)測(cè)系統(tǒng)模型,如圖1所示。
圖1 流量監(jiān)測(cè)系統(tǒng)模型
采集器可以布置在任何產(chǎn)生流量的地方,當(dāng)系統(tǒng)規(guī)模較大時(shí),需要配置多個(gè)采集器。本文采用收集器和數(shù)據(jù)庫(kù)集中部署,由多個(gè)采集器共同負(fù)責(zé)采集全網(wǎng)內(nèi)路由器上產(chǎn)生的流量。
該模型的優(yōu)點(diǎn):采集器分散在各個(gè)采集域的邊緣,可以監(jiān)測(cè)到整個(gè)域內(nèi)的流量信息,收集器和數(shù)據(jù)庫(kù)集中部署,便于統(tǒng)一管理和維護(hù),提高了設(shè)備的利用率。
采集器模塊的功能:捕獲原始網(wǎng)絡(luò)流量,提取相應(yīng)信息按自定義模板封裝成NetFlow報(bào)文,以UDP包的形式不斷發(fā)送給收集器。
采集器模塊的工作原理:調(diào)用pcap類(lèi)庫(kù)從數(shù)據(jù)鏈路層進(jìn)行抓包,提取流量信息封裝成Netflow報(bào)文,然后發(fā)送到收集器。采集器處理流程簡(jiǎn)圖見(jiàn)圖2。
圖2 采集器處理流程
(1)抓包過(guò)程主要由Pcap_thread線程負(fù)責(zé)。主要功能是調(diào)用系統(tǒng)庫(kù)函數(shù)從數(shù)據(jù)鏈路層進(jìn)行抓包,然后在抓取的包中提取相關(guān)的信息并存入FLOW鏈表中。
(2)分析和封裝過(guò)程由Unpending_thread和Scan_thread來(lái)完成。
Unpending_thread線程的主要功能是不停的把FLOW鏈表里的數(shù)據(jù)通過(guò)hash計(jì)算放入到指針數(shù)組FLOWS[] 里。在放入的過(guò)程中,如果FLOWS[] 之前沒(méi)有此數(shù)據(jù),則直接復(fù)制進(jìn)來(lái);如果之前有數(shù)據(jù),則更新。Scan_thread線程的操作很簡(jiǎn)單,就是把FLOWS[] 里所關(guān)聯(lián)的數(shù)據(jù)根據(jù)不同的屬性送到不同的鏈表中,完整且滿足活動(dòng)期要求的數(shù)據(jù)存放flow_emit鏈表中,不完整且超過(guò)生存期的數(shù)據(jù)存放scan_flag_drag鏈表中,以便進(jìn)行下一步的操作。
(3)發(fā)送過(guò)程由emit_thread完成,它的主要功能就是發(fā)送NetFlow格式的數(shù)據(jù)包。
其中,自定義的NetFlow報(bào)文模板包括以下選項(xiàng):IPVersion,ProtocolIdentifier,SourceIPv-4Address,DestinationIPv4Address,SourceIP-v6Address,DestinationIPv6Address,Source-TransportPort,DestinationTransportPort,F(xiàn)low-StartSysUpTime,F(xiàn)lowEndSysUpTime,Octet-DeltaCount,PacketDeltaCount。該模板是根據(jù)用戶網(wǎng)絡(luò)行為分析的需要所定義,確定了后續(xù)發(fā)送的包含流記錄的數(shù)據(jù)包的格式和長(zhǎng)度,便于收集器對(duì)數(shù)據(jù)包的處理。模板中各字段域在文獻(xiàn)[14] 中進(jìn)行了詳細(xì)說(shuō)明。除了模板信息和流信息外,NetFlow報(bào)文中還包含了報(bào)文輸出時(shí)間、序列號(hào)和采集區(qū)域ID,收集器可以以此來(lái)區(qū)分每個(gè)NetFlow報(bào)文的到達(dá)時(shí)間和采集器。
收集器負(fù)責(zé)解析來(lái)自采集器的數(shù)據(jù)報(bào)文,依據(jù)模板進(jìn)行處理,提取出流記錄信息,然后存儲(chǔ)到數(shù)據(jù)庫(kù)中。收集器處理流程如圖3。
圖3 收集器處理流程
數(shù)據(jù)收集的過(guò)程比較簡(jiǎn)單,關(guān)鍵是收集器必須有模板,所以采集器在發(fā)送NetFlow報(bào)文前,需要先將模板發(fā)送給收集器,使收集器能夠依據(jù)模板正確處理NetFlow報(bào)文中的流信息。收集器接收來(lái)自各個(gè)采集器的NetFlow報(bào)文,按照模板提取出流信息,然后存儲(chǔ)到數(shù)據(jù)庫(kù)中,為進(jìn)一步流量分析提供數(shù)據(jù)支持。
在實(shí)驗(yàn)中,對(duì)終端A產(chǎn)生的數(shù)據(jù)流進(jìn)行監(jiān)測(cè),采集器和收集器集成在一臺(tái)服務(wù)器上。首先運(yùn)行數(shù)據(jù)捕獲程序通過(guò)集線器將網(wǎng)絡(luò)內(nèi)流量鏡像到服務(wù)器的eth0口,然后將eth0口收到的數(shù)據(jù)轉(zhuǎn)化成NetFlow流,使用NetFlow模板發(fā)送到回環(huán)地址的特定端口,收集器從這個(gè)端口提取流記錄存入數(shù)據(jù)庫(kù)。測(cè)試環(huán)境拓?fù)淙鐖D4。
圖4 測(cè)試環(huán)境拓?fù)鋱D
終端A文件下載完成之后,立即終止流量監(jiān)測(cè)系統(tǒng)的相應(yīng)進(jìn)程。查看服務(wù)器中數(shù)據(jù)庫(kù)文件,使用IPv6協(xié)議的數(shù)據(jù)流,信息存入表 receive_pkt_v6中。查詢表receive_pkt_v6中終端A有關(guān)的流記錄信息,查詢語(yǔ)句:mysql> select * from receive_pkt_v6 where src_ip='2001:da8:205:2060:20c:29ff:fe66:ca59' or dst_ip='2001:da8:205:2060:20c:29ff:fe66:ca59 '; 表中部分?jǐn)?shù)據(jù)如圖5。
圖5 表receive_pkt_v6中數(shù)據(jù)
使用IPv4協(xié)議的數(shù)據(jù)流,信息存入表 receive_pkt_v4中,查看表中終端A有關(guān)的流記錄信息, 表中部分?jǐn)?shù)據(jù)如圖6。
圖6 表receive_pkt_v4中數(shù)據(jù)
圖5與圖6中,各字段用“|”隔開(kāi),數(shù)據(jù)中各字段的含義:| 序號(hào) | 接收時(shí)間 | 源地址 | 目的地址 | 協(xié)議類(lèi)型 | 源端口 | 目的端口 | 流開(kāi)始時(shí)間| 流結(jié)束時(shí)間 | 字節(jié)數(shù) | 包數(shù)量 |。圖5和圖6中的流記錄分別表示終端A接收和發(fā)出的流量,序號(hào)為71的記錄,表示源地址2001:da8:8000:1::80,目的地址為終端A的IPv6數(shù)據(jù)流,源端口80,目的端口32767協(xié)議類(lèi)型為6(TCP),流量大小為3919173 byte,流量持續(xù)時(shí)間為5 s,該股流的數(shù)據(jù)包數(shù)量為2615;其它記錄信息與此類(lèi)似,不再表述。
從圖5、圖6中數(shù)據(jù)可以看出,已經(jīng)完整監(jiān)測(cè)到終端A產(chǎn)生的IPv4和IPv6流量,每股流量的開(kāi)始與結(jié)束時(shí)間,流量大小等信息。至此,實(shí)現(xiàn)了利用NetFlow技術(shù)進(jìn)行流量監(jiān)測(cè)的目的,且擁有較高的性能。
本文提出了一種基于NetFlow的網(wǎng)絡(luò)流量監(jiān)測(cè)系統(tǒng)模型,采用自定義的NetFlow模板來(lái)采集處理流信息,能同時(shí)處理IPv4和IPv6數(shù)據(jù)流,并對(duì)所設(shè)計(jì)的方案進(jìn)行了測(cè)試,證明了該方案的可行性和較高的性能。在今后的工作中,將繼續(xù)研究利用NetFlow進(jìn)行數(shù)據(jù)挖掘和流量分析的方法,發(fā)揮NetFlow在流量監(jiān)測(cè)分析方面的優(yōu)勢(shì)。
[1] 王志. 基于NetFlow的流量統(tǒng)計(jì)分析系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D] .北京:北京郵電大學(xué),2007.
[2] CLAISE B. Specification of the IP Flow Information Export(IPFIX) Protocol for the Exchange of IP Traffic Flow Information[S] . RFC 5101. January 2008.
[3] 劉廣義,盧泉,楊國(guó)良. 基于NetFlow流量采樣的誤差分析[J] . 電信科學(xué),2005, 21(5):68-70.
[4] 曾國(guó)鑒,魯士文. 分布式異常流量監(jiān)測(cè)系統(tǒng)的設(shè)計(jì)[J] . 計(jì)算機(jī)應(yīng)用與軟件,2008,25(11):154-156.
[5] 劉璇,張鳳荔,葉李. 基于NetFlow的用戶行為挖掘算法設(shè)計(jì)[J] . 計(jì)算機(jī)應(yīng)用研究,2009,26(2): 713-715.
[6] GALVIN J, MCCLOGHRIE K. Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)[S] . RFC 1445. April 1993.
[7] FUENTES F, KAR D C. Ethereal vs. Tcpdump: a comparative study on packet sniffing tools educational purpose[J] . Journal of Computing Sciences in Colleges. 2005, Vol. 20, No. 4. pp.169-176.
[8] Programming with Pcap[EB/OL] . [2011-10-13] . http://www.tcpdump.org/pcap. htm.
[9] TCPdump[EB/OL] .[2011-11-16] . http://www.tcpdump.org.
[10] Wireshark[EB/OL] . [2011-09-07] . http://www.wireshark.org.
[11] WALDBUSSER S. Remote Network Monitoring Management Information Base[S] . RFC 1757, May 2000.
[12] 田海燕, 王換招, 李玉鵬. 基于RMON的網(wǎng)絡(luò)流量測(cè)量系統(tǒng)設(shè)計(jì)及實(shí)現(xiàn)[J] . 計(jì)算機(jī)工程與應(yīng)用,2004,40(5):160-162.
[13] CLAISE B. Cisco Systems NetFlow Services Export Version 9[S] . RFC 3954. October 2004. http://www.ietf.org/rfc/rfc3954.txt.
[14] QUITTEK J, BRYANT S, CLAISE B, et al. Information Model for IP Flow Information Export[S] . RFC 5102. January 2008. http://www.ietf.org/rfc/rfc5102.txt.