【文章內(nèi)容簡介】 來很可能會提出來的要求，這樣做的目的是在設計過程中 對系統(tǒng)將來可能的擴充和修改預做準備，以便一旦需要時能比較容易地進行一些擴充和修改。 本軟件雖然能夠捕獲到本網(wǎng)段的數(shù)據(jù)，并可以對捕獲的數(shù)據(jù)進行簡單的分析，還可以進行指定對象的監(jiān)聽和將結果顯示出來等功能，但在實際的運用中，用戶肯定會遇到更多的問題，以下是對本軟件的擴充性能的一些初步預計： （ 1）自動獲取本機和網(wǎng)關的 IP 和 MAC地址； （ 2）監(jiān)視所有主機的收發(fā)郵件記錄收發(fā)郵件的 Email 地址、日期、主題等； （ 3）對捕獲到的數(shù)據(jù)進一步分析，得到非法數(shù)據(jù)； （ 4）可以對局域網(wǎng)內(nèi)的計算機進行一些簡單的操作。 3 理論 基礎與相關工具介紹 網(wǎng)絡監(jiān)聽原理介紹 Ether協(xié)議 （以太網(wǎng)協(xié)議） 的工作方式是將要發(fā)送的數(shù)據(jù)包發(fā)往連接在一起的所有主機。在包頭中包括有應該接收數(shù)據(jù)包的主機的正確地址，因為只有與數(shù)據(jù)包中目標地址一致的那臺主機才能接收到 數(shù)據(jù) 包，但是當主機工作在監(jiān)聽模式下 ， 不管數(shù)據(jù)包中的目標物理地址是什么，主機都將可以接收到。 數(shù)據(jù)包并不能在協(xié)議棧的高層直接發(fā)送出去，要發(fā)送的數(shù)據(jù)包必須從TCP/IP協(xié)議的 IP 層交給網(wǎng)絡接口，也就是所說的數(shù)據(jù)鏈路層。網(wǎng)絡接口不會識別 IP 地址的。 因此， 在網(wǎng)絡接口由 IP 層 傳輸過 來的帶有 IP 地址的數(shù)據(jù)包 將 增加了一部分以太幀的幀頭的信息。在幀頭中，有兩個域分別為只有網(wǎng)絡接口才能 識別的源主機和目的主機的物理地址 ， 這是一個 48位的地址，這個 48位的地址是與 IP 地址相對應的，換句話說就是一個 IP 地址也會對應一個物理地址。 傳輸數(shù)據(jù)時，包含物理地址的幀從網(wǎng)絡接口（網(wǎng)卡）發(fā)送到物理的線路上，如果局域網(wǎng)是由一條粗纜或細纜連接而成，則數(shù)字信號在電纜上傳輸，能夠到達線路上的每一臺主機。當使用集線器時，由集線器再發(fā)向連接在集線器上的每一條線路，數(shù)字信號也能到達連接在集線器上的每一臺主機。當數(shù)字信號到達一臺主機的 網(wǎng)絡接口時，正常情況下，網(wǎng)絡接口讀入數(shù)據(jù)幀，進行檢查，如果數(shù)據(jù)幀中攜帶的物理地址是自己的或者是廣播地址，則將數(shù)據(jù)幀交給上層協(xié)議軟件，也就是 IP 層軟件，否則就將這個幀丟棄。對于每一個到達網(wǎng)絡接口的數(shù)據(jù)幀，都要進行這個過程。 當連接在同一條電纜或集線器上的主機被邏輯地分為幾個子網(wǎng)的時候，那么要是有一臺主機處于監(jiān)聽模式，它還將可以接收到發(fā)向與自己不在同一個子網(wǎng)（使用了不同的掩碼、 IP 地址和網(wǎng)關）的主機的數(shù)據(jù)包，在同一個物理信道上傳輸?shù)乃行畔⒍伎梢员唤邮盏健? 以太網(wǎng)上的數(shù)據(jù)幀主要涉及 TCP/IP 協(xié)議，針對以 下幾個協(xié)議的分析： IP，ARP， RARP， IPX，其中重點在于 IP 和 ARP 協(xié)議，這兩個協(xié)議是多數(shù)網(wǎng)絡協(xié)議的基礎 。 在本軟件的監(jiān)聽過程中，將監(jiān)聽到的數(shù)據(jù)包利用工具和所編寫的方法進行逐層分析，并解析出每一層、每一協(xié)議、每一字段的數(shù)據(jù)，從中得到自己想要的信息，最后將其顯示出來，并進行動態(tài)的更新。 TCP/IP 的層次結構 OSI 與 TCP/IP體系結構的比較 OSI（ Open System Interconnect）是 開放式 系統(tǒng) 互聯(lián) ， 為了解決不同體系結構的網(wǎng)絡的互聯(lián)問題，國際標準化組織 ISO于 1981年制定了開放系統(tǒng)互連參考模型（ Open System Interconnection Reference Model， OSI/RM）。 OSI把 網(wǎng)絡 通信的工作分為 7層，它們由低到高分別是物理層（ Physical Layer)，數(shù)據(jù)鏈路層（ Data Link Layer)，網(wǎng)絡層 (Network Layer)，傳輸層（ Transport Layer)，會話層（ Session Layer），表示層（ Presen tation Layer)和應用層（ Application Layer)。每層完成一定的功能，每層都直接為其上層提供服務，并且所有層次都互相支持 。 TCP/IP 協(xié)議 (Transmission Control Protocol/Inter Protocol)是 傳輸控制 /網(wǎng)際協(xié)議，這個協(xié)議是 Inter國際互聯(lián)網(wǎng)絡的基礎 。 TCP/IP通訊協(xié)議采用了 4層的層級結構，每一層都呼叫它的下一層所提供的網(wǎng)絡來完成自己的需求。這 4層分別為： （ 1） 應用層：應用程序間溝通的層，如簡單電子郵件傳輸（ SMTP）、文件 傳輸協(xié)議（ FTP）、網(wǎng)絡遠程訪問協(xié)議（ Tel）等 ； （ 2） 傳輸層：在此層中 ，它提供了節(jié)點間的數(shù)據(jù)傳送服務，如傳輸控制協(xié)議（ TCP）、用戶數(shù)據(jù)報協(xié)議（ UDP）等， TCP和 UDP 給數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)较乱粚又?，這一層負責傳送數(shù)據(jù)，并且確定數(shù)據(jù)已被送達并接收 ； （ 3） 互連網(wǎng)絡層：負責提供基本的數(shù)據(jù)封包傳送功能，讓每一塊數(shù)據(jù)包都能夠到達目的主機（但不檢查是否被正確接收），如網(wǎng)際協(xié)議（ IP） ； （ 4） 網(wǎng)絡接口層：對實際的網(wǎng)絡媒體的管理，定義如何使用實際網(wǎng)絡（如Ether、 Serial Line 等）來傳送數(shù)據(jù)。 TCP/IP各層的描述如表 1所示。 表 1 TCP/IP 各層描述 TCP/IP 的描述 主要協(xié)議 主要功能 應用層 Http、 Tel、 FTP和 等 負責把數(shù)據(jù)傳輸?shù)絺鬏攲踊蚪邮諒膫鬏攲臃祷氐臄?shù)據(jù) 傳輸層 TCP 和 UDP 主要為兩臺主機上的應用程序提供端到端的通信， TCP 為兩臺主機提供高可靠性的數(shù)據(jù)通信。它所做的工作包括把應用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡層，確認接收到的分組，設置發(fā)送最后確認分組的超時時鐘等。 UDP 則為應用層提供一種簡單的服務。它只是把稱作數(shù)據(jù)報的分組從一臺主機發(fā)送到另一臺主機，但并不保證該數(shù)據(jù)能到達另一端。 網(wǎng)絡層 ICMP、 IP 和 IGMP 有時稱作互聯(lián)網(wǎng)層，主要為數(shù)據(jù)包選擇路由，其中 IP 是 TCP/IP協(xié)議族中最核心的協(xié)議。所有的 TCP、 UDP、 ICMP 及 IGMP數(shù)據(jù)都以 IP 數(shù)據(jù)報格式傳輸 鏈路層 ARP、 RARP 和設備驅動程序及接口卡 發(fā)送時將 IP 包作為 幀 發(fā)送；接收時把接收到的位組裝成 幀 ；提供鏈路管理；錯誤檢測等 OSI模型與 TCP/IP協(xié)議 的 區(qū)別 如下： （ 1） TCP/IP 一開始就考慮到多種異構網(wǎng)的互聯(lián)問題，并將網(wǎng)際協(xié)議 IP 作為 TCP/IP的重要組成部分。但 ISO和 CCITT最初只考慮到全世界都使用一種統(tǒng)一的標準公用 數(shù)據(jù)網(wǎng)將各種不同的系統(tǒng)互連在一起。后來， ISO認識到了網(wǎng)際協(xié)議 IP 的重要性，然而已經(jīng)來不及了，只好在網(wǎng)絡層中劃分出一個子層來完成類似 TCP/IP中的 IP 的作用； （ 2） TCP/IP一開始就對面向連接服務和無連接服務并重，而 OSI在開始只強調(diào)面向連接這一種服務。一直到很晚 OSI 才開始制定另一種無連接服務的有關標準； （ 3） TCP/IP較早就有較好的網(wǎng)絡管理功能，而 OSI到后來才開始考慮這個問題。 OSI 與 TCP/IP體系結構的比較如圖 2所示。 圖 2 OSI 與 TCP/IP 體系結構的對比 TCP/IP 四層協(xié)議的表示方法舉例 圖 3 TCP/IP 四層協(xié)議的表示方法舉例 在許多文獻中，也常見到 TCP/IP 的四層協(xié)議的表示方法。例如，在討論兩個主機通過兩個網(wǎng)絡用路由器連在一起時，可以使用如圖 3所示的層次關系。圖3中的邏輯鏈路控制和物理層都簡化為網(wǎng)絡接口層。實際上，現(xiàn)在插在主機中的網(wǎng)絡接口板上的硬件和軟件就是實現(xiàn)了數(shù)據(jù)鏈路層和物理層這兩層的功能。應當注意的是，在網(wǎng)絡互連中起重要作用的路由器則沒有應用層和運輸層，其數(shù)據(jù)鏈路層和物理層也是在網(wǎng)絡接口板上實現(xiàn)的。 使用 TCP/IP進行通信的示意圖 在 TCP/IP的應用層協(xié)議使用的是客戶－服務器方式?？蛻簦?Client）和服務器（ Server）都是指通信中所涉及的兩個應用進程?？蛻簦掌鞣绞剿枋龅氖沁M程之間服務和被服務的關系。當 A 進程需要 B 進程的服務時就主動呼叫 B進程，在這種情況下， A 是客戶而 B 是服務器。這里最重要的特征就是：客戶是服務請求方，服務器是服務提供方。 客戶與服務器的通信關系一旦建立，通信就可是雙向的，客戶和服務器都可 以發(fā)送和接收信息，如圖 4所示。 圖 4 客戶進程和服務器進程使用 TCP/IP 協(xié)議進行通信 Winpcap 簡介 Winpcap（ windows packet capture） 是 Windows 平臺下一個免費，公共的網(wǎng)絡訪問系統(tǒng)。開發(fā) Winpcap這個項目的目的在于為 win32應用程序提供訪問網(wǎng)絡底層的能力。它提供了以下的各項功能： （ 1） 捕獲原始數(shù)據(jù)報，包括在共享網(wǎng)絡上各主機發(fā)送 /接收的以及相互之間交換的數(shù)據(jù)報 ； （ 2） 在數(shù)據(jù)報發(fā)往應用程序之前，按照自定義的規(guī)則將某些特殊的數(shù)據(jù)報過濾掉； （ 3） 在網(wǎng)絡上發(fā)送原始的數(shù)據(jù)報； （ 4） 收集網(wǎng)絡通信過程中的統(tǒng)計信息。 Winpcap 的主要功能在于獨立于主機 協(xié)議（如 TCP/IP)而發(fā)送和接收原始數(shù)據(jù)報。也就是說， Winpcap不能阻塞 、 過濾或控制其他應用程序數(shù)據(jù)報的發(fā)收，它僅僅只是監(jiān)聽共享網(wǎng)絡上傳送的數(shù)據(jù)報。因此，它不能用于 服務質量 QoS 調(diào)度程序或個人防火墻。目前， Winpcap開發(fā)的主要對象是 Windows NT/2020/XP，這主要是因為在使用 Winpcap 的用戶中只有一小部分使用 Windows 95/98/Me，并 且微軟 也已經(jīng)放棄了對 win9x的開發(fā)。其實 Winpcap中的面向 9x系統(tǒng)的概念和 NT 系統(tǒng)的非常相似，只是在某些實現(xiàn)上有點差異，比如說 9x 只支 持 ANSI編碼，而 NT系統(tǒng)則提倡使用 Unicode編碼。 Winpcap 提供給用戶兩個不同級別的編程接口：一個基于 libpcap 的，另一個是 較底層的 。對于一般的要與 UNIX 平臺上 libpcap兼容的開發(fā)來說，使用 是當 然的選擇。下面幾個庫是與 lipcap相關的：—— 數(shù)據(jù)包的發(fā)送構造過程 ； libnids— — 實現(xiàn)了 ids的一些框架 ； libicmp—— icmp數(shù)據(jù)包處理 。 操作系統(tǒng)攔截數(shù)據(jù)包的技術有很多，現(xiàn)在很多文章都是介紹 編寫 IM DRIVER阿 在 NDIS中間層對 MINIPORT（網(wǎng)卡驅動程序）和協(xié)議驅動程序之間 的數(shù)據(jù)包進行攔截。這是微軟提供的一種技術但編寫該過濾程序攔截程序非常 地復雜，安裝也很麻煩。 現(xiàn)在 簡單的介紹基于 NDIS 包攔截技術。 NDIS 協(xié)議驅動程序是通過填寫一張 NDIS_PROTOCOL_CHARACTERISTICS 的表，并調(diào)用 NDIS API 函數(shù)NdisRegisterProtocol 進行注冊?，F(xiàn)在來關注一下NDIS_PROTOCOL_CHARACTERISTICS這張表，這張表中存有所有協(xié)議驅動程序與底層的派發(fā)函數(shù)的入口 。如 BindAdapterHandler， SendHandler， ReceiveHandler等，當網(wǎng)卡有數(shù)據(jù)包進入時，會通過表中 ReceiveHandle 或 ReceivePacketHandler通知協(xié)議驅動程序有一個該協(xié)議的數(shù)據(jù)包進入，反之協(xié)議驅動程序是通過 Send Handler 或 SendPacketsHandler 函數(shù)向網(wǎng)卡驅動發(fā)送數(shù)據(jù)包到網(wǎng)絡上去的 。雖然在 程序中是調(diào)用 NdisSend或 NdisSendPackets 函數(shù)發(fā)送 ， 但是 通過查看 的頭文件里對這兩個函數(shù)的定義就知道了， 它 們都是一 個宏定義，實際還是通過這表中 Send Handler 或 SendPacketsHandler 發(fā)送的。 現(xiàn)在要做的事情應該很清 楚 了 ， 只 要 能 夠 將 每 一 個 協(xié) 議 程 序 所 填 寫 的NDIS_PROTOCOL_CHARACTERISTICS 表里的派發(fā)函數(shù)指向自己的函數(shù)，就能成功的對數(shù)據(jù)包進行攔截。 Winpcap 也是用 NDIS（ Windows 的通信協(xié)議程序 (比如 TCP/IP)和網(wǎng)絡設備驅動器之間通信的規(guī)范 ）的 ，將自己注冊為一個協(xié)議處理驅動。 Winpcap的使用非常方便，但是它 有一個致命的缺陷就是只適用于共享式以太網(wǎng)絡，對于交換式網(wǎng)絡下的數(shù)據(jù)則無能為力 。經(jīng)過 測試，在使用交換機連接的局域網(wǎng)下， Winpcap只能監(jiān)聽到本網(wǎng)段內(nèi)的數(shù)據(jù)，而對于來自其他網(wǎng)段的數(shù)據(jù)則無法監(jiān)聽，除非你把probe接到交換機之前或者接到交換機的 console 口上，不過那樣的弊端是顯而易見的 ， 所以， Winpcap的應用 還是 有局限性的 。 Jpcap 簡介 由于核心 Java API不能直接訪問網(wǎng)絡底層，因此需要借助一種工具來為 Java和網(wǎng)絡底層提供一個橋梁。 Jpcap就 是一種提供在 Windows 或 UNIX系統(tǒng)上進行網(wǎng)絡底層 訪問的 Java API。 Jpcap不是一種 純粹的 Java解決方案 ， 它依賴本地庫的使用。在 Windows 或 UNIX上， 用戶 必須有必要的第三方庫，分別是 WinPcap或 libpcap。 Jpcap 的工作原理是 使 用 一個事件模型 讓你對數(shù)據(jù)包進行 處理。首先必須創(chuàng)建一個執(zhí)行接口 的類 ： public class JpcapTip implements JpcapHandler