【文章內(nèi)容簡介】 ，同樣再給B發(fā)送一個偽造的ARP應答包，告訴B它就是A。這樣A和B都會誤認為監(jiān)控主機C的MAC地址是對方的MAC地址。這樣，監(jiān)控主機C就能同A和B建立活動連接，從而監(jiān)聽A和B傳遞的信息，而A和B卻認為雙方是在直接通信。只要監(jiān)聽主機在被監(jiān)聽的機器重新發(fā)送ARP查詢包前及時偽造虛假ARP應答包就能維持著這個通訊鏈路，從而獲得持續(xù)的數(shù)據(jù)記錄，同時也不會造成被監(jiān)聽者的通訊異常。Internet并不采用MAC尋址，如果一個局域網(wǎng)內(nèi)通過網(wǎng)關上網(wǎng)，那么連接外部的計算機上的ARP緩存中就存在網(wǎng)關IPMAC對應記錄。ARP協(xié)議的作用是將IP地址映射到MAC地址,監(jiān)聽設備通過向目標主機發(fā)送偽造的ARP應答包,使目標系統(tǒng)更新自身的ARP緩存表,將目標系統(tǒng)的網(wǎng)關的MAC地址修改為監(jiān)聽設備的主機MAC地址,使數(shù)據(jù)包都經(jīng)由監(jiān)聽設備的主機,同時監(jiān)聽設備向網(wǎng)關發(fā)送偽造的ARP應答包,欺騙網(wǎng)關更新自己的ARP緩存表,網(wǎng)關發(fā)給目標主機的數(shù)據(jù)也都流經(jīng)監(jiān)聽的主機,這樣就實現(xiàn)了交換環(huán)境下的網(wǎng)絡監(jiān)聽。在這兩種監(jiān)聽方式中，由于監(jiān)控的雙方都直接將數(shù)據(jù)發(fā)送到起中轉(zhuǎn)作用的監(jiān)控主機上，因此可以直接使用網(wǎng)卡的缺省工作方式，不必將其設為混雜模式。 167。 數(shù)據(jù)包捕獲機制通常網(wǎng)卡在接收到網(wǎng)絡上傳來的數(shù)據(jù)包后，經(jīng)過MAC匹配后，產(chǎn)生中斷信號，通知操作系統(tǒng)調(diào)用網(wǎng)卡驅(qū)動程序進行接收，然后把這些數(shù)據(jù)交給上層的協(xié)議棧進行處理。在這個過程中，根據(jù)系統(tǒng)設置的過濾條件，通常會丟棄一些不符合條件的數(shù)據(jù)包。對于監(jiān)控系統(tǒng)來說，由于監(jiān)控環(huán)境的復雜性，特別是在高速網(wǎng)絡中，如果處理速度跟不上，將嚴重影響監(jiān)控系統(tǒng)的性能。因此，為了提高效率，必須盡可能早的在底層截獲數(shù)據(jù)包，設定過濾條件，丟棄監(jiān)控系統(tǒng)不需要的數(shù)據(jù)包。捕獲到的數(shù)據(jù)包先在操作系統(tǒng)的內(nèi)核空間，然后再由內(nèi)核空間拷貝到用戶空間。因此監(jiān)控系統(tǒng)的程序架構大體分為兩部分：捕獲和過濾網(wǎng)絡數(shù)據(jù)包的內(nèi)核空間部分，進行協(xié)議分析、設計用戶界面的用戶空間部分，在用戶空間也可以設置過濾條件，在協(xié)議分析之前對數(shù)據(jù)包進行過濾。[2]： 簡單監(jiān)聽系統(tǒng)框架底層包的捕獲機制與操作系統(tǒng)有關，但其實現(xiàn)方式大同小異。數(shù)據(jù)包有網(wǎng)卡接收，經(jīng)操作系統(tǒng)調(diào)用網(wǎng)卡驅(qū)動程序處理，然后到達數(shù)據(jù)鏈路層，經(jīng)操作系統(tǒng)的協(xié)議棧進行處理，最后交給應用程序。包捕獲機制是在鏈路層對數(shù)據(jù)包進行旁路處理，過濾和緩沖發(fā)送和接收到的數(shù)據(jù)包，然后拷貝到應用程序。操作系統(tǒng)對數(shù)據(jù)包仍然進行網(wǎng)絡協(xié)議堆棧處理，并不受包捕獲機制的影響。包捕獲機制的設計在最底層需要考慮操作系統(tǒng)的特征，包過濾機制則處于設計的中間部分，而在上層給用戶程序提供了一個統(tǒng)一的接口，方便用戶使用。包捕獲機制中底層與操作系統(tǒng)有關的部分，用戶并不可見，用戶程序只考慮調(diào)用接口函數(shù)，這樣使得用戶程序移植性很好?？偠灾?，包捕獲機制與操作系統(tǒng)有關，操作系統(tǒng)不同，提供的包過濾器也不同。[3]。包捕獲機制系統(tǒng)平臺備注BPFBSD系列Berkeley Packet FilterDLPISolaris，HPUX,SCO OpenserverData Link ProviderInterfaceNITSunOS3Network Interface TapSNOOPIRIXSNITSunOS4Streams Network Interface TapSOCK_PACKETLinux基本類似BPFLSF=Linux Socket FilterDrainIRIX用于竊聽系統(tǒng)丟棄的包Unix上最常用的三種數(shù)據(jù)鏈路層訪問方法為:BSD的BPF(分組過濾器)、Linux的SOCK_PACKET接口和SVR4的DLPI(數(shù)據(jù)鏈路提供者接口)。SOCK_PACKET類型的協(xié)議套接字工作在用戶層，Linux用它可以實現(xiàn)對鏈路層的訪問的部分功能，而通常要通過編寫內(nèi)核驅(qū)動程序，在Linux下才可對鏈路層進行訪問。使用SOCK_PACKET建立的套接字，內(nèi)核直接將網(wǎng)絡數(shù)據(jù)交給用戶而不進行處理，用戶可以直接從網(wǎng)卡的協(xié)議棧得到數(shù)據(jù)。使用如下方式來建立SOCK_PACKET類型的套接字：socket (AF_INET,SOCK_PACKET, htons(0x0003))；表示建立的因特網(wǎng)協(xié)議族類型的套接字，該套接字在物理層截取數(shù)據(jù)幀，數(shù)據(jù)不需要網(wǎng)絡協(xié)議棧處理，而且截取幀的類型為不確定，所有的數(shù)據(jù)包都需處理。在使用此套接字進行監(jiān)聽的時候，要將監(jiān)聽主機的網(wǎng)卡模式設置為“混雜”模式，才能監(jiān)聽到其它主機的數(shù)據(jù)。網(wǎng)卡的模式設置可以通過設備管理函數(shù)ioctl（）來實現(xiàn)。： 基于SOCK_PACKET的捕包機制Linux的SOCK_PACKET方法主要存在兩個方面的不足：1）沒有內(nèi)核緩沖功能，在內(nèi)核也不能進行過濾，它的套接口接收緩沖區(qū)一次只能接收一幀數(shù)據(jù)，每接收到一幀數(shù)據(jù)就需要調(diào)用操作系統(tǒng)將其從內(nèi)核拷貝，傳遞給應用進程。這樣一來它的數(shù)據(jù)包接收過程需要頻繁的進行系統(tǒng)調(diào)用，使得系統(tǒng)開銷很大。2）不能對設備過濾。套接口要接收來自以太網(wǎng)、PPP鏈路、SLIP鏈路等設備的數(shù)據(jù)，而不能只接收某一設備的數(shù)據(jù)，比如以太網(wǎng)設備。這就需要在應用進程中進行過濾，丟掉不需要關注設備的數(shù)據(jù)，這就對高速網(wǎng)絡的監(jiān)視造成了影響。（BSD Packet Filter, 簡稱BPF）[4]。BPF是包括Libpcap庫在內(nèi)的眾多數(shù)據(jù)包截獲系統(tǒng)的工作基礎。目前,許多版本Unix和Linux平臺上多數(shù)嗅探器都是基于BPF開發(fā)的。BPF工作機制如圖2—8所示： 使用BPF捕獲分組使用BPF進行監(jiān)聽的每一個應用進程可以裝載自己的過濾器，這個過濾器是通過基于寄存器的過濾器機器作用于每一個數(shù)據(jù)包。過濾器程序可以通過這個偽機器的機器語言編寫，但有一種更簡單的編寫方式，就是使用pcap_pile函數(shù)接口，將應用進程設定的ASCII過濾字符串編譯成BPF偽機器的機器語言。使用BPF在網(wǎng)絡接口對數(shù)據(jù)鏈路層進行網(wǎng)絡監(jiān)聽時，對于到達的數(shù)據(jù)包，網(wǎng)絡接口設備的驅(qū)動器先不將它傳遞給上層的協(xié)議棧進行處理，而是先調(diào)用BPF進行數(shù)據(jù)包傳遞，由每個監(jiān)控進程的過濾器對數(shù)據(jù)包進行過濾處理。如果這個數(shù)據(jù)包被過濾器接收，它就會傳到與過濾器相連的緩存中，最后由應用進程處理時再將其從緩沖區(qū)拷貝到用戶進程空間中。在數(shù)據(jù)包傳到緩存后，控制權就交給鏈路層設備驅(qū)動程序，由上層的協(xié)議棧處理被提交上來的數(shù)據(jù)包。網(wǎng)絡中的數(shù)據(jù)除了按內(nèi)核協(xié)議棧流程傳遞處理，Linux內(nèi)核還提供了一種靈活修改網(wǎng)絡數(shù)據(jù)的機制，在網(wǎng)絡數(shù)據(jù)流轉(zhuǎn)經(jīng)過多個地點設立檢查點，用戶可以在這些檢查點設立處理方法，數(shù)據(jù)流轉(zhuǎn)這些地方的時候就會按照這些方法進行處理，然后再正常流轉(zhuǎn)。Linux內(nèi)核中的netfilter就是基于這種機制實現(xiàn)的。在Linux內(nèi)核中，用NetFilter模塊實現(xiàn)BPF，在用戶空間用iptables實現(xiàn)過濾。對于IPVIPV6等網(wǎng)絡協(xié)議棧，netfilter在Linux內(nèi)核中都有相應的實現(xiàn)。IPV4在數(shù)據(jù)包的傳遞過程中設立了五個檢查點，分別是NF_IP_PRE_ROUTINE、NF_IP_FOWARD、NF_IP_POST_FOUTINE、NF_IP_LOCAL_IN和NF_IP_LOCAL_OUT。這五個點又稱作五個鉤子函數(shù)。內(nèi)核通過這五個鉤子函數(shù)完成包過濾過程[5]。BPF使用以下3個技術來降低開銷[4]： （1） BPF過濾在內(nèi)核進行，以此把從BPF到應用進程的數(shù)據(jù)拷貝量減到最小。（2） 由BPF傳遞到應用進程的只是每個分組的一段定長部分。這個長度稱為捕獲長度。大多數(shù)應用進程只需要分組頭部而不需要分組數(shù)據(jù)。這個技術減少了由BPF拷貝到應用進程的數(shù)量。也可以根據(jù)應用的需要設置這個長度值。（3） BPF為每個應用進程分別拷貝數(shù)據(jù)，只有當緩沖區(qū)已滿或讀超時期滿時該緩沖區(qū)中的數(shù)據(jù)才拷貝到應用進程。如此緩沖，雖然還是相同數(shù)量的分組從BPF拷貝到應用進程，但系統(tǒng)調(diào)用的次數(shù)大量減少，提高了數(shù)據(jù)包處理效率。每個應用進程使用兩個緩沖區(qū)，由BPF維護，當應用進程從一個緩沖區(qū)拷貝數(shù)據(jù)時，接收的數(shù)據(jù)可以緩沖到另一個緩沖區(qū)。167。 數(shù)據(jù)包捕獲函數(shù)庫監(jiān)控程序雖然在實際的監(jiān)控應用中對監(jiān)控的內(nèi)容可能不同，但卻常常需要檢查、處理和控制網(wǎng)絡通訊的細節(jié)，比如查看通訊雙方的地址，使用什么端口，服務類型是什么，有什么樣的傳輸控制機制等。通常在網(wǎng)絡安全監(jiān)控程序中必須實現(xiàn)以下功能：截獲數(shù)據(jù)包，分析數(shù)據(jù)報頭，重寫數(shù)據(jù)包甚至將通訊連接截斷。對于這些常用功能和繁復的過程，一個好方法是可以寫一些函數(shù)將它們封裝起來，這樣安全監(jiān)控程序的編寫可以大大簡化，其性能和健壯性也可以提高。這些封裝的函數(shù)以應用程序編程接口函數(shù)庫的形式供開發(fā)人員使用。這樣的API library有很多，像libpcap、libnet、libnids等都是類Unix系統(tǒng)平臺上比較流行的網(wǎng)絡開發(fā)工具，它們各有不同的特點。Libpcap是平臺獨立的分組捕獲函數(shù)庫，主要支持讀入分組；而libnet則支持構造任意協(xié)議的分組和數(shù)據(jù)鏈路分組的寫出；libnids[7]的開發(fā)是基于libpcap和libnet的，除了能夠捕獲網(wǎng)絡數(shù)據(jù)包，還能重組ip碎片，重組TCP數(shù)據(jù)流，監(jiān)測端口掃描攻擊等。使用這些函數(shù)庫，可以屏蔽網(wǎng)絡底層編程在不同操作系統(tǒng)的差別，可以使開發(fā)人員集中解決開發(fā)應用中的主要問題上[6]。本文所論述的系統(tǒng)是監(jiān)控系統(tǒng)，故下面將詳細討論libpcap. Libpcap函數(shù)庫1．Libpcap概述 Libpcap[8]的英文意思是Packet Capture Library，是一個開源的數(shù)據(jù)庫，向網(wǎng)絡抓包系統(tǒng)提供一個高層接口。它由McCanne,Leres和Jacobson在1994年設計，是一個獨立于系統(tǒng)的用戶層包捕獲的API接口。雖然幾乎每一個操作系統(tǒng)都有自己的抓包機制，但是應用程序使用libpcap就可以消除依賴于系統(tǒng)的包捕獲模塊，這樣就為底層網(wǎng)絡監(jiān)控編程提供了一個易于移植的應用框架。libpcap API可以在C和C++語言里使用，然而它有許多包裝方法，使得它也可以在Perl、Java、Python等語言里使用。幾乎所有的類Unix操作系統(tǒng)都可以運行l(wèi)ibpcap，當然也包括Linux.[9]使用libpcap進行網(wǎng)絡監(jiān)聽，首先需要知道監(jiān)聽的網(wǎng)絡接口。我們可以在程序里指明或者使用libpcap進行查找。查找網(wǎng)絡接口的函數(shù)是char* pcap_lookupdev(char *errbuf),這個函數(shù)返回一個字符串指針，這個指針所指的字符串含有適合包捕獲的第一個網(wǎng)絡設備。如果終端用戶未指明任何網(wǎng)絡接口，就需要調(diào)用這個函數(shù)。指明網(wǎng)絡接口，在Linux中我們可以這樣說明，比如eth0，一個錯誤的做法是使用硬編碼的接口名字，這是因為它們不是跨平臺可移植的。這個函數(shù)的errbuf參數(shù)所使用的緩沖空間由用戶提供，在錯誤發(fā)生時，庫函數(shù)用這個緩沖空間存儲錯誤消息。Libpcap的許多函數(shù)需要這個參數(shù)，我們必須小心分配這個緩沖空間，因為這個緩沖空間必須至少能容納PCAP_ERRBUF_SIZE個字節(jié)，目前定義為256.一旦知道了網(wǎng)絡設備的名稱，我們需要打開它。函數(shù)pcap_t *pcap_open_live（const char *device， int snaplen， int promisc， int to_ms， char *errbuf）用來打開網(wǎng)絡設備。這個函數(shù)返回pcap_t類型的接口句柄，當調(diào)用libpcap的其它函數(shù)時，就需要使用這個句柄。這個函數(shù)的第一個參數(shù)是一個字符串，它含有想要打開的網(wǎng)絡設備的名稱。第二個參數(shù)是要捕捉的最大字節(jié)數(shù)。當我們僅需要捕獲數(shù)據(jù)包頭或者對內(nèi)存有重要限制的嵌入式系統(tǒng)進行編程時，將這個參數(shù)設定一個較低的值比較好。通常，以太幀最大長度為1518個字節(jié)，但是其它的鏈路類型可能有更大的長度。但是65535這個值能夠容納任何網(wǎng)絡上的任何一個數(shù)據(jù)包。參數(shù)to_ms規(guī)定了將捕捉的信息從內(nèi)核空間拷貝到用戶空間時，內(nèi)核應該等待多長時間（單位是毫秒）。上下文的改變的代價是比較大的。如果我們在高速網(wǎng)絡上捕捉數(shù)據(jù)，最好讓內(nèi)核讓內(nèi)核先把一些包緩沖在一起，然后再一起從內(nèi)核空間拷貝到用戶空間。如果將to_ms設為0，在沒有足量的數(shù)據(jù)包到達網(wǎng)絡設備之前，讀取操作會一直等待。Libpcap的文檔并沒有對這個數(shù)值提供任何建議。但是我們可以參考一些嗅探器設定的值，比如tcpdump使用的值為1000，它的數(shù)值決定了網(wǎng)絡設備是否用promiscuous模式，設為0，則網(wǎng)絡設備是非promiscuous模式，非0數(shù)值則設定網(wǎng)絡設備為promiscuous模式。注意，如果我們讓libpcap以nonpromiscuous模式監(jiān)聽，但接口的工作方式之前已經(jīng)是promiscuous模式，接口可能仍然保持該模式。我們不能想當然的認為，此時網(wǎng)卡不會接收目的地址是其它主機的數(shù)據(jù)包。對于這種情況最好使用libpcap提供的過濾功能。一旦我們打開網(wǎng)絡設備進行數(shù)據(jù)包的捕捉，我們實際上告訴pcap開始獲得數(shù)據(jù)包。要獲得數(shù)據(jù)包，我們有幾個選擇：1） 函數(shù) const u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h),這個函數(shù)需要一個由pcap_open_live返回的pcap_t句柄，和一個pcap_pkthdr類型的結構指針，該函數(shù)返回到達網(wǎng)絡設備的第一個數(shù)據(jù)包。2） 函數(shù)int pcap_loop（pcap_t *p，int t， pcap_handler_callback, u_char* user）用來采集數(shù)據(jù)包并進行處理。這個函數(shù)在沒有捕捉到t個數(shù)據(jù)包之前，不會返回。如果將t的值設為負值，這個函數(shù)會一直運行下去，只有錯誤發(fā)生的情況下才會返回。函數(shù)pcap_loop（）返回的是一個整數(shù)值，并沒有返回捕捉到的數(shù)據(jù)包，而是每當有一個數(shù)據(jù)包準備讀取時，就調(diào)用一個用戶定義的函數(shù)進行處理。這樣我們就可以使用一個獨立的函數(shù)去處理數(shù)據(jù)包。如果使用pcap_next（）函數(shù)，就必須進行循環(huán)調(diào)用，但對包的處理過程也得放在循環(huán)里。使用pcap_loop()調(diào)用用戶定義的函數(shù)時，有一個問題是如何向用戶定義的函數(shù)傳遞參數(shù)。使用全局變量并不是一個好方法。Libpcap的解決方法是使用用戶參數(shù)。每次調(diào)用