網(wǎng)絡監(jiān)聽，在網(wǎng)絡安全上一直是一個比較敏感的話題，作為一種發(fā)展比較成熟的技術(shù)，監(jiān)聽在協(xié)助網(wǎng)絡管理員監(jiān)測網(wǎng)絡傳輸數(shù)據(jù)，排除網(wǎng)絡故障等方面具有不可替代的作用，因而一直倍受網(wǎng)絡管理員的青睞。然而，在另一方面網(wǎng)絡監(jiān)聽也給以太網(wǎng)安全帶來了極大的隱患，許多的網(wǎng)絡入侵往往都伴隨著以太網(wǎng)內(nèi)網(wǎng)絡監(jiān)聽行為，從而造成口令失竊，敏感數(shù)據(jù)被截獲等等連鎖性安全事件。
網(wǎng)絡監(jiān)聽在安全領(lǐng)域引起人們普遍注意是在94年開始的，在那一年2月間，相繼發(fā)生了幾次大的安全事件，一個不知名的人在眾多的主機和骨干網(wǎng)絡設備上安裝了網(wǎng)絡監(jiān)聽軟件，利用它對美國骨干互聯(lián)網(wǎng)和軍方網(wǎng)竊取了超過100，000個有效的用戶名和口令。上述事件可能是互聯(lián)網(wǎng)上最早期的大規(guī)模的網(wǎng)絡監(jiān)聽事件了，它使早期網(wǎng)絡監(jiān)聽從"地下"走向了公開，并迅速的在大眾中普及開來。
關(guān)于網(wǎng)絡監(jiān)聽常常會有一些有意思的問題，如："我現(xiàn)在有連在網(wǎng)上的計算機了，我也有了竊聽的軟件了，那么我能不能竊聽到微軟(或者美國國防部，新浪網(wǎng)等等)的密碼？
又如：我是公司的局域網(wǎng)管理員，我知道hub很不安全，使用hub這種網(wǎng)絡結(jié)構(gòu)將公司的計算計互連起來，會使網(wǎng)絡監(jiān)聽變得非常容易，那么我們就換掉hub，使用交換機，不就能解決口令失竊這種安全問題了么？
這是兩個很有意思的問題，我們在這里先不做回答，相信讀者看完全文后會有自己正確的答案。
一些基本概念：
首先，我們知道，一臺接在以太網(wǎng)內(nèi)的計算機為了和其他主機進行通訊，在硬件上是需要網(wǎng)卡，在軟件上是需要網(wǎng)卡驅(qū)動程序的。而每塊網(wǎng)卡在出廠時都有
一個唯一的不與世界上任何一塊網(wǎng)卡重復的硬件地址，稱為mac地址。同時，當網(wǎng)絡中兩臺主機在實現(xiàn)tcp/ip通訊時，網(wǎng)卡還必須綁定一個唯一的ip地址。下面用一個常見的unix命令ifconfig來看一看作者本人的一臺正常工作的機器的網(wǎng)卡：
[yiming@server/root]# ifconfig -a
hme0: flags=863 mtu 1500
inet 192.168.1.35 netmask ffffffe0
ether 8:0:20:c8:fe:15
從這個命令的輸出中我們可以看到上面講到的這些概念，如第二行的192.168.1.35是ip 地址，第三行的8:0:20:c8:fe:15是mac地址。請注意第一行的BROADCAST，MULTICAST，這是什么意思？一般而言，網(wǎng)卡有幾種接收數(shù)據(jù)幀的狀態(tài)，如unicast，broadcast，multicast，promiscuous等，unicast是指網(wǎng)卡在工作時接收目的地址是本機硬件地址的數(shù)據(jù)幀。Broadcast是指接收所有類型為廣播報文的數(shù)據(jù)幀。Multicast是指接收特定的組播報文。Promiscuous則是通常說的混雜模式，是指對報文中的目的硬件地址不加任何檢查，全部接收的工作模式。對照這幾個概念，看看上面的命令輸出，我們可以看到，正常的網(wǎng)卡應該只是接收發(fā)往自身的數(shù)據(jù)報文，廣播和組播報文，請大家記住這個概念。
對網(wǎng)絡使用者來說，瀏覽網(wǎng)頁，收發(fā)郵件等都是很平常，很簡便的工作，其實在后臺這些工作是依靠tcp/ip協(xié)議族實現(xiàn)的，大家知道有兩個主要的網(wǎng)絡體系：OSI參考模型和TCP/IP參考模型，OSI模型即為通常說的7層協(xié)議，它由下向上分別為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層、應用層，而tcp/ip模型中去掉了會話層和表示層后，由剩下的5層構(gòu)成了互聯(lián)網(wǎng)的基礎(chǔ)，在網(wǎng)絡的后臺默默的工作著。
下面我們不妨從tcp/ip模型的角度來看數(shù)據(jù)包在局域網(wǎng)內(nèi)發(fā)送的過程：當數(shù)據(jù)由應用層自上而下的傳遞時，在網(wǎng)絡層形成ip數(shù)據(jù)報，再向下到達數(shù)據(jù)鏈路層，由數(shù)據(jù)鏈路層將ip數(shù)據(jù)報分割為數(shù)據(jù)幀，增加以太網(wǎng)包頭，再向下一層發(fā)送。需要注意的是，以太網(wǎng)的包頭中包含著本機和目標設備的mac地址，也即，鏈路層的數(shù)據(jù)幀發(fā)送時，是依靠48bits的以太網(wǎng)地址而非ip地址來確認的，以太網(wǎng)的網(wǎng)卡設備驅(qū)動程序不會關(guān)心ip數(shù)據(jù)報中的目的ip地址，它所需要的僅僅是mac地址。目標ip的mac地址又是如何獲得的呢？發(fā)端主機會向以太網(wǎng)上的每個主機發(fā)送一份包含目的地的ip地址的以太網(wǎng)數(shù)據(jù)幀(稱為arp數(shù)據(jù)包)，并期望目的主機回復，從而得到目的主機對應的mac地址，并將這個mac地址存入自己的一個arp緩存內(nèi)。
當局域網(wǎng)內(nèi)的主機都通過HUB等方式連接時，一般都稱為共享式的連接，這種共享式的連接有一個很明顯的特點：就是HUB會將接收到的所有數(shù)據(jù)向HUB上的每個端口轉(zhuǎn)發(fā)，也就是說當主機根據(jù)mac地址進行數(shù)據(jù)包發(fā)送時，盡管發(fā)送端主機告知了目標主機的地址，但這并不意味著在一個網(wǎng)絡內(nèi)的其他主機聽不到發(fā)送端和接收端之間的通訊，只是在正常狀況下其他主機會忽略這些通訊報文而已！如果這些主機不愿意忽略這些報文，網(wǎng)卡被設置為promiscuous狀態(tài)的話，那么，對于這臺主機的網(wǎng)絡接口而言，任何在這個局域網(wǎng)內(nèi)傳輸?shù)男畔⒍际强梢员宦牭降摹?/p>
例子：
我們不妨舉一個例子來看看：我們現(xiàn)在有A,B兩臺主機，通過hub相連在一個以太網(wǎng)內(nèi)，現(xiàn)在A機上的一個用戶想要訪問B機提供的WWW服務，那么當A機上的用戶在瀏覽器中鍵入B的ip地址，得到B機提供的web服務時，從7層結(jié)構(gòu)的角度上來看都發(fā)生了什么呢？
1：首先，當A上的用戶在瀏覽器中鍵入B機的地址，發(fā)出瀏覽請求后，A機的應用層得到請求，要求訪問IP地址為B的主機，
2：應用層于是將請求發(fā)送到7層結(jié)構(gòu)中的下一層傳輸層，由傳輸層實現(xiàn)利用tcp對ip建立連接。
3：傳輸層將數(shù)據(jù)報交到下一層網(wǎng)絡層，由網(wǎng)絡層來選路
4：由于A，B兩機在一個共享網(wǎng)絡中，IP路由選擇很簡單：IP數(shù)據(jù)報直接由源主機發(fā)送到目的主機。
5：由于A，B兩機在一個共享網(wǎng)絡中，所以A機必須將32bit的IP地址轉(zhuǎn)換為48bit的以太網(wǎng)地址，請注意這一工作是由arp來完成的。
6：鏈路層的arp通過工作在物理層的hub向以太網(wǎng)上的每個主機發(fā)送一份包含目的地的ip地址的以太網(wǎng)數(shù)據(jù)幀，在這份請求報文中申明：誰是B機IP地址的擁有者，請將你的硬件地址告訴我。
7：在同一個以太網(wǎng)中的每臺機器都會"接收"(請注意這一點！)到這個報文，但正常狀態(tài)下除了B機外其他主機應該會忽略這個報文，而B機網(wǎng)卡驅(qū)動程序識別出是在尋找自己的ip地址，于是回送一個arp應答，告知自己的ip地址和mac地址。
8：A機的網(wǎng)卡驅(qū)動程序接收到了B機的數(shù)據(jù)幀，知道了B機的mac地址，于是以后的數(shù)據(jù)利用這個已知的MAC地址作為目的地址進行發(fā)送。同在一個局域網(wǎng)內(nèi)的主機雖然也能"看"到這個數(shù)據(jù)幀，但是都保持靜默，不會接收這個不屬于它的數(shù)據(jù)幀。
上面是一種正常的情況，如果網(wǎng)卡被設置為為混雜模式(promiscuous)，那么第8步就會發(fā)生變化，這臺主機將會默不作聲的聽到以太網(wǎng)內(nèi)傳輸?shù)乃行畔ⅲ簿褪钦f：竊聽也就因此實現(xiàn)了！這會給局域網(wǎng)安全帶來極大的安全問題，一臺系統(tǒng)一旦被入侵并進入網(wǎng)絡監(jiān)聽狀態(tài)，那么無論是本機還是局域網(wǎng)內(nèi)的各種傳輸數(shù)據(jù)都會面臨被竊聽的巨大可能性。實現(xiàn)網(wǎng)絡監(jiān)聽的工具：
上面我們看到，一切的關(guān)鍵就在于網(wǎng)卡被設置為混雜模式的狀態(tài)，這種工作復雜嗎？不幸的是，這種工作并不復雜，目前有太多的工具可以做到這一點。
自網(wǎng)絡監(jiān)聽這一技術(shù)誕生以來，產(chǎn)生了大量的可工作在各種平臺上相關(guān)軟硬件工具，其中有商用的，也有free的。在google上用sniffer tools作為關(guān)鍵字，可以找到非常多。
作者在這里列舉一些作者喜歡的軟件，供有興趣的讀者參考使用。
Windows平臺下的：
Windump
Windump是最經(jīng)典的unix平臺上的tcpdump的window移植版，和tcpdump幾乎完全兼容，采用命令行方式運行，對用慣tcpdump的人來講會非常順手。目前版本是3.5.2，可運行在Windows 95/98/ME/Windows NT/2000/XP平臺上
Iris
Eeye公司的一款付費軟件，有試用期，完全圖形化界面，可以很方便的定制各種截獲控制語句，對截獲數(shù)據(jù)包進行分析，還原等。對管理員來講很容易上手，入門級和高級管理員都可以從這個工具上得到自己想要得東西。運行在Windows 95/98/ME/Windows NT/2000/XP平臺上
unix平臺下的：
tcpdump
不多說，最經(jīng)典的工具，被大量的*nix系統(tǒng)采用，無需多言。
ngrep
和tcpdump類似，但與tcpdump最大的不同之處在于，借助于這個工具，管理員可以很方便的把截獲目標定制在用戶名，口令等感興趣的關(guān)鍵字上。
snort
目前很紅火的免費的ids系統(tǒng)，除了用作ids以外，被用來sniffer也非常不錯，可以借助工具或是依靠自身能力完全還原被截獲的數(shù)據(jù)。
Dsniff
作者設計的出發(fā)點是用這個東西進行網(wǎng)絡滲透測試，包括一套小巧好用的小工具，主要目標放在口令，用戶訪問資源等敏感資料上，非常有特色，工具包中的arpspoof，macof等工具可以令人滿意的捕獲交換機環(huán)境下的主機敏感數(shù)據(jù)。
Ettercap
和dsniff在某些方面有相似之處，也可以很方便的工作在交換機環(huán)境下提示：國內(nèi)用戶訪問這個站點需要使用代理服務器。
Sniffit
被廣泛使用的網(wǎng)絡監(jiān)聽軟件，截獲重點在用戶的輸出。 網(wǎng)絡監(jiān)聽的具體實現(xiàn)：
在系統(tǒng)管理員看來，網(wǎng)絡監(jiān)聽的主要用途是進行數(shù)據(jù)包分析，通過網(wǎng)絡監(jiān)聽軟件，管理員可以觀測分析實時經(jīng)由的數(shù)據(jù)包，從而快速的進行網(wǎng)絡故障定位。
我們可以舉個例子： server是郵件服務器，下面帶了很多的client用戶，郵件服務器收發(fā)郵件工作正常，但下面的client用戶總是抱怨發(fā)郵件時連接到郵件服務器后要等待很久的時間才能開始發(fā)送工作，問題出在哪里呢？
在server上使用tcpdump對來自其中的一個client的數(shù)據(jù)包進行捕獲分析，看看結(jié)果如何？
server#tcpdump host client
tcpdump: listening on hme0
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0)
win 64240 (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0)
ack 1087965816 win 10136 (DF)
19:04:30.040960 client.1065 > server.smtp: .
ack 1 win 64240 (DF)
client連接服務器的25端口，三次握手正常，沒有問題，我們再往下看
19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF)
19:04:56.070108 server.smtp > client.1065:
P 1:109(108) ack 1 win 10136 (DF)
這里有問題了，我們看到server端試圖連接client的113認證端口，然而client端并不會去回應它，server端從19點04分30秒到19點04分56秒嘗試3次，費時26秒后，才放棄認證嘗試，主動reset了client端的113端口，開始push后面的數(shù)據(jù)，而正是在這個過程中所花費的時間，使用戶發(fā)送郵件時產(chǎn)生了漫長的等待。?
???問題找到了，下面的工作就好辦了，通過修改服務器端的軟件配置，使它不再進行113端口的認證，看看這個問題解決了么？不用問client用戶，再抓包如下：
server# tcpdump host client
tcpdump: listening on hme0
19:06:45.775516 client.1066 > server.smtp:
S 1119047365:1119047365(0) win 64240 (DF)
19:06:45.775546 server.smtp > client.1066:
S 116566929:116566929(0) ack 1119047366 win 10136 (DF)
19:06:45.775776 client.1066 > server.smtp:
. ack 1 win 64240 (DF)
19:06:45.789316 server.smtp > client.1066:
P 1:109(108) ack 1 win 10136 (DF)
19:06:45.796767 client.1066 > server.smtp:
P 1:11(10) ack 109 win 64132 (DF)
我們看到，server不再進行113端口的認證嘗試，直接push數(shù)據(jù)，問題應該解決，到client試驗，果然延遲現(xiàn)象消失！
由這個試驗，我們可以看到，網(wǎng)絡監(jiān)聽手段，對網(wǎng)絡的系統(tǒng)管理員是非常有價值的。
然而，對入侵者呢？與管理員感興趣的是對數(shù)據(jù)包進行分析不同，入侵者，感興趣的是數(shù)據(jù)包的內(nèi)容，尤其是賬號，口令等敏感內(nèi)容。
我們模仿入侵者在主機上跑一個上面提到的sniffit軟件，監(jiān)聽本機發(fā)出去的所有telnet數(shù)據(jù)，如下：
server#./sniffit -A . -p 23 -s server
同時，我們模仿一個用戶yiming登錄一臺client機器，
server@yiming#telnet client
Trying 192.168.1.1...
Connected to 192.168.1.1
Escape character is '^]'.
login: yiming
Password:
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
$ ls
bak lost+found project wangguan
libcap nms snmp wglist
$ pwd
/yiming
$
我們看到這個用戶telnet到client機器，輸入賬號口令，執(zhí)行了ls，pwd命令，
此時看看sniffit的記錄文件記錄了什么，
server# more server.32780-client.23
........... ..!.."..'.......h.7....#..$....VT100....'.........yiming..Power^man!..ls ..pwd..
我們看到了賬號yiming，密碼Power^man!，還有登錄后操作的命令。請注意一點，yiming這個用戶盡管設置了非常復雜的密碼，但對網(wǎng)絡監(jiān)聽而言，是沒有絲毫意義的。
其實除了截獲telnet密碼這樣的功能外，專用的網(wǎng)絡監(jiān)聽軟件從密碼到郵件，瀏覽的網(wǎng)頁等內(nèi)容，無所不包，但由于本文不是介紹網(wǎng)絡監(jiān)聽軟件用途的，因此這里不詳細敘述各種監(jiān)聽軟件的使用方法，有興趣的讀者可以參照各個軟件的readme等文件，很簡單。
網(wǎng)絡監(jiān)聽的防范方法：
上面我們介紹了可以用來進行網(wǎng)絡監(jiān)聽的軟件，那么對這種不受歡迎的行為，有沒有一些防范手段呢？
上面我們知道，sniffer是發(fā)生在以太網(wǎng)內(nèi)的，那么，很明顯，首先就要確保以太網(wǎng)的整體安全性，因為sniffer行為要想發(fā)生，一個最重要的前提條件就是以太網(wǎng)內(nèi)部的一臺有漏洞的主機被攻破，只有利用被攻破的主機，才能進行sniffer，去收集以太網(wǎng)內(nèi)敏感的數(shù)據(jù)信息。
其次，采用加密手段也是一個很好的辦法，因為如果sniffer抓取到的數(shù)據(jù)都是以密文傳輸?shù)模菍θ肭终呒词棺ト〉搅藗鬏數(shù)臄?shù)據(jù)信息，意義也是不大的-比如作為telnet，ftp等安全替代產(chǎn)品目前采用ssh2還是安全的。這是目前相對而言使用較多的手段之一，在實際應用中往往是指替換掉不安全的采用明文傳輸數(shù)據(jù)的服務，如在server端用ssh,openssh等替換unix系統(tǒng)自帶的telnet,ftp,rsh，在client端使用securecrt,sshtransfer替代telnet,ftp等。
除了加密外，使用交換機目前也是一個應用比較多的方式，不同于工作在第一層的hub,交換機是工作在二層，也就是說數(shù)據(jù)鏈路層的，以CISCO的交換機為例，交換機在工作時維護著一張ARP的數(shù)據(jù)庫，在這個庫中記錄著交換機每個端口綁定的MAC地址，當有數(shù)據(jù)報發(fā)送到交換機上時，交換機會將數(shù)據(jù)報的目的MAC地址與自己維護的數(shù)據(jù)庫內(nèi)的端口對照，然后將數(shù)據(jù)報發(fā)送到"相應的"端口上，注意，不同于HUB的報文廣播方式，交換機轉(zhuǎn)發(fā)的報文是一一對應的。對二層設備而言，僅有兩種情況會發(fā)送廣播報文，一是數(shù)據(jù)報的目的MAC地址不在交換機維護的數(shù)據(jù)庫中，此時報文向所有端口轉(zhuǎn)發(fā)，二是報文本身就是廣播報文。由此，我們可以看到，這在很大程度上解決了網(wǎng)絡監(jiān)聽的困擾。但是有一點要注意，隨著dsniff，ettercap等軟件的出現(xiàn)，交換機的安全性已經(jīng)面臨著嚴峻的考驗！我們將在后面對這種技術(shù)進行介紹。
此外，對安全性要求比較高的公司可以考慮kerberos，kerberos是一種為網(wǎng)絡通信提供可信第三方服務的面向開放系統(tǒng)的認證機制，它提供了一種強加密機制使client端和server即使在非安全的網(wǎng)絡連接環(huán)境中也能確認彼此的身份，而且在雙方通過身份認證后，后續(xù)的所有通訊也是被加密的。在實現(xiàn)中也即建立可信的第三方服務器保留與之通訊的系統(tǒng)的密鑰數(shù)據(jù)庫，僅kerberos和與之通訊的系統(tǒng)本身擁有私鑰(private key)，然后通過private key以及認證時創(chuàng)建的session key來實現(xiàn)可信的網(wǎng)絡通訊連接。
檢測網(wǎng)絡監(jiān)聽的手段
對發(fā)生在局域網(wǎng)的其他主機上的監(jiān)聽，一直以來，都缺乏很好的檢測方法。這是由于產(chǎn)生網(wǎng)絡監(jiān)聽行為的主機在工作時總是不做聲的收集數(shù)據(jù)包，幾乎不會主動發(fā)出任何信息。但目前網(wǎng)上已經(jīng)有了一些解決這個問題的思路和產(chǎn)品：
1：反應時間
向懷疑有網(wǎng)絡監(jiān)聽行為的網(wǎng)絡發(fā)送大量垃圾數(shù)據(jù)包，根據(jù)各個主機回應的情況進行判斷，正常的系統(tǒng)回應的時間應該沒有太明顯的變化，而處于混雜模式的系統(tǒng)由于對大量的垃圾信息照單全收，所以很有可能回應時間會發(fā)生較大的變化。
2：觀測dns
許多的網(wǎng)絡監(jiān)聽軟件都會嘗試進行地址反向解析，在懷疑有網(wǎng)絡監(jiān)聽發(fā)生時可以在dns系統(tǒng)上觀測有沒有明顯增多的解析請求。
3：利用ping模式進行監(jiān)測
上面我們說過：當一臺主機進入混雜模式時，以太網(wǎng)的網(wǎng)卡會將所有不屬于他的數(shù)據(jù)照單全收。按照這個思路，我們就可以這樣來操作：假設我們懷疑的主機的硬件地址是00:30:6E:00:9B:B9,它的ip地址是192.168.1.1,那么我們現(xiàn)在偽造出這樣的一種icmp數(shù)據(jù)包：硬件地址是不與局域網(wǎng)內(nèi)任何一臺主機相同的00:30:6E:00:9B:9B,目的地址是192.168.1.1不變，我們可以設想一下這種數(shù)據(jù)包在局域網(wǎng)內(nèi)傳輸會發(fā)生什么現(xiàn)象：任何正常的主機會檢查這個數(shù)據(jù)包，比較數(shù)據(jù)包的硬件地址，和自己的不同，于是不會理會這個數(shù)據(jù)包，而處于網(wǎng)絡監(jiān)聽模式的主機呢？由于它的網(wǎng)卡現(xiàn)在是在混雜模式的，所以它不會去對比這個數(shù)據(jù)包的硬件地址，而是將這個數(shù)據(jù)包直接傳到上層，上層檢查數(shù)據(jù)包的ip地址，符合自己的ip，于是會對對這個ping的包做出回應。這樣，一臺處于網(wǎng)絡監(jiān)聽模式的主機就被發(fā)現(xiàn)了。
這種方法，在10pht這個黑客組織的antisniff產(chǎn)品中有很好的體現(xiàn)。可參見： http://www.securitysoftwaretech.com/antisniff/download.html
4：利用arp數(shù)據(jù)包進行監(jiān)測
除了使用ping進行監(jiān)測外，目前比較成熟的有利用arp方式進行監(jiān)測的。這種模式是上述ping方式的一種變體，它使用arp數(shù)據(jù)包替代了上述的icmp數(shù)據(jù)包。向局域網(wǎng)內(nèi)的主機發(fā)送非廣播方式的arp包，如果局域網(wǎng)內(nèi)的某個主機響應了這個arp請求，那 么我們就可以判斷它很可能就是處于網(wǎng)絡監(jiān)聽模式了，這是目前相對而言比較好的監(jiān)測模式。
這種方式，在neped和PromiScan這兩個產(chǎn)品中有所體現(xiàn)。可分別參見： http://www.apostols.org/、http://www.securityfriday.com/ToolDownload/PromiScan/promiscan_doc.html
值得注意的是，現(xiàn)在互聯(lián)網(wǎng)上流傳著一些基于上面這兩種技術(shù)的腳本和程序，它們宣稱自己能準確捕捉到局域網(wǎng)內(nèi)所有進行網(wǎng)絡監(jiān)聽的主機，目前來講，這種說法基本上是不可靠的，因為上述技術(shù)在實現(xiàn)中，除了要考慮網(wǎng)卡的硬件過濾外，還需要考慮到不同操作系統(tǒng)可能產(chǎn)生的軟件過濾。因為雖然理論上網(wǎng)卡處于混雜模式的系統(tǒng)應該接收所有的數(shù)據(jù)包，但實際上不同的操作系統(tǒng)甚至相同的操作系統(tǒng)的不同版本在tcp/ip的實現(xiàn)上都有自己的一些特點，有可能不會接收這些理論上應該接收的數(shù)據(jù)包。
除了上述幾種方式外，還有一些其他的方式，如：檢測hub燈，但相比局限性就更大了，只能作為上述模式的補充。
相對而言，對發(fā)生在本機的網(wǎng)絡監(jiān)聽，是可以利用一些工具軟件來發(fā)現(xiàn)的，比較簡單，這里我們不介紹，有興趣的讀者可以參考cert等網(wǎng)站。
安全的交換機？
文章到這里結(jié)束了嗎？沒有，我們還漏掉了一個很重要的監(jiān)聽手段-交換環(huán)境下面的網(wǎng)絡聽，這是個很有必要談及的話題，筆者作為網(wǎng)絡管理員參加了許多的工程決策，吃驚的發(fā)現(xiàn)許多的公司都還停留在交換機是局域網(wǎng)安全的徹底解決之道的概念上。
應該認識到這個概念是個傳說，是的，在以前，的確是這樣的，但隨著上面介紹的dsniff等軟件的誕生，所謂交換機的安全已經(jīng)成為一個傳說了。
本文前面的部分介紹了交換機工作的原理，不同于HUB的共享式報文方式，交換機轉(zhuǎn)發(fā)的報文是一一對應的，由此看來，交換環(huán)境下再采用傳統(tǒng)的共享式局域網(wǎng)下網(wǎng)絡監(jiān)聽是不可行了，由于報文是一一對應轉(zhuǎn)發(fā)的，普通的網(wǎng)絡監(jiān)聽軟件此時無法監(jiān)聽到交換環(huán)境下其它主機任何有價值的數(shù)據(jù)。
交換機是安全的？
不，還有一些別的方法，比如利用arp，本文一開始就提到了局域網(wǎng)內(nèi)主機數(shù)據(jù)包的傳送完成不是依靠ip地址，而是依靠arp找出ip地址對應的mac地址實現(xiàn)的。而我們知道arp協(xié)議是不可靠和無連接的，通常即使主機沒有發(fā)出arp請求，也會接受發(fā)給它的arp回應，并將回應的mac和ip對應關(guān)系放入自己的arp緩存中。
那么如果能利用這個特性，在這個環(huán)節(jié)中做些文章，還是可以截獲數(shù)據(jù)包的。
Arp理論的實踐
作者這里推薦一個不錯的上述理論產(chǎn)物，dsniff，這個軟件包中包括了filesnarf、 mailsnarf、msgsnarf、urlsnarf、dnsspoof、macof 等諸多很有特色的組件，可以捕獲網(wǎng)絡中的各種敏感數(shù)據(jù)，但這些不是今天感興趣的主題，我們只看其中一個組件，arpspoof，這個組件就是上述arp理論的一個實踐，它的工作原理是這樣的：發(fā)起arpspoof的主機向目標主機發(fā)送偽造的arp應答包，騙取目標系統(tǒng)更新arp表，將目標系統(tǒng)的網(wǎng)關(guān)的mac地址修改為發(fā)起arpspoof的主機mac地址，使數(shù)據(jù)包都經(jīng)由發(fā)起arpspoof的主機，這樣即使系統(tǒng)連接在交換機上，也不會影響對數(shù)據(jù)包的攫取，由此就輕松的通過交換機實現(xiàn)了網(wǎng)絡監(jiān)聽。
舉例如下：
主機a和b連接在交換機的同一個vlan上，
A機的ip地址：192.168.1.37
B機的ip地址：192.168.1.35，mac地址為：08-00-20-c8-fe-15
網(wǎng)關(guān)的ip地址：192.168.1.33，mac地址為：00-90-6d-f2-24-00
首先在a機上看看a機的arp表
C:\ >arp -a
Interface: 192.168.1.37
Internet Address Physical Address Type
192.168.1.33 00-90-6d-f2-24-00 dynamic
我們看到a機中保留著網(wǎng)關(guān)的ip地址192.168.1.33和對應的mac地址00-90-6d-f2-24-00
我們在B機上執(zhí)行arpspoof，將目標指向a機，宣稱自己為網(wǎng)關(guān)，如下：
HOSTB# arpspoof -t 192.168.1.37 192.168.1.33
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15
可以看到b機持續(xù)向a發(fā)送arp回應包，宣稱網(wǎng)關(guān)192.168.1.33的mac地址是自己！此時，我們在a機上看看arp表的內(nèi)容，
C:\>arp -a
Interface: 192.168.1.37
Internet Address Physical Address Type
192.168.1.33 08-00-20-c8-fe-15 dynamic
哈！a機的arp表已經(jīng)改變了，網(wǎng)關(guān)的mac地址被更新為了 b機的mac地址，這樣，當有數(shù)據(jù)包發(fā)送時，a機理所當然的會發(fā)到它arp表中網(wǎng)關(guān)對應的mac地址08-00-20-c8-fe-15，然而這個地方的b機正在等待著，悄然無聲的冒充網(wǎng)關(guān)收發(fā)著a機的數(shù)據(jù)包。
有一點要說明的是，為了讓a機能正常使用網(wǎng)絡，b機還必須打開數(shù)據(jù)轉(zhuǎn)發(fā).
linux中可以使用
sysctl -w net.ipv4.ip_forward = 1
bsd系統(tǒng)可以使用
sysctl -w net.inet.ip.forwarding =1
solaris系統(tǒng)可以使用
ndd -set /dev/ip ip_forwarding 1
除了這樣打開內(nèi)核的支持外，也可以選用外部的fragrouter等轉(zhuǎn)發(fā)軟件，如此，就能確保a機正常工作了。
此外，ettercap的作者指出，內(nèi)核為2.4.x的linux系統(tǒng)在arp實現(xiàn)中，考慮到了arp欺騙，不會接受未經(jīng)請求的arp回應，因此直接向這種系統(tǒng)發(fā)送arp reply也是無效的，不過，有意思的是雖然它不會接受未經(jīng)請求的arp reply，但是只要接收到arp的request，它就會更新自己的arp緩存，；)，如此就好辦了，發(fā)送一個偽造的arp request即可！不過，作者在自己實驗時沒有發(fā)現(xiàn)這個問題，作者內(nèi)核為2.4.7的系統(tǒng)接受了直接的arp reply，并更新了自己的arp表。
如果一切配置正常的話，被重定向的a機是不會有什么明顯的感覺的，網(wǎng)絡照常是通暢的，只是在后臺數(shù)據(jù)都繞了一個小圈子，不是直接到網(wǎng)關(guān),而是先經(jīng)由b機，再由b機轉(zhuǎn)發(fā)到網(wǎng)關(guān)，因為數(shù)據(jù)包都經(jīng)過了b機，那么在b機上起一個網(wǎng)絡監(jiān)聽軟件，a機的所有數(shù)據(jù)必然會被監(jiān)聽到。交換環(huán)境下的監(jiān)聽由此實現(xiàn)！
除此之外，dsniff還提供了macof等淹沒交換機arp表等進行監(jiān)聽的模式，這里就不介紹了，有興趣的讀者可以自己查閱相關(guān)資料。
Arp方式監(jiān)聽的防范
對付采用arp方式的監(jiān)聽也是個比較棘手的問題，有幾個不是非常理想的對策。
首先還是上面提到的加密，盡可能的讓局域網(wǎng)內(nèi)的傳輸?shù)臄?shù)據(jù)都是秘文的，這個可能相對最理想的防范方法，但實施起來可能有一點困難。有一點要注意，ssh1是不安全的，我們提到的dsniff和ettercap都可以對ssh1實施中間人的監(jiān)聽。
另外，還可以考慮指定靜態(tài)arp，如大多數(shù)unix系統(tǒng)支持arp讀取指定的ip和mac地址對應文件，首先編輯內(nèi)容為ip和mac地址對照的文件，然后使用命令：arp -f /path/to/ipandmacmapfile讀取文件，這樣就指定了靜態(tài)的arp地址，即使接收到arp reply，也不會更新自己的arp緩存，從而使arpspoof喪失作用。windows系統(tǒng)沒有-f這個參數(shù)，但有-s參數(shù)，用命令行指定ip和mac地址對照關(guān)系，如arp -s 192.168.1.33 00-90-6d-f2-24-00，可惜除了xp外，其它的版本的window平臺即使這樣做，當接收到偽造的arp reply后，依然會更新自己的arp緩存，用新的mac地址替換掉老的mac地址，所以無法對抗arpspoof。而且采用靜態(tài)arp有一個缺憾，就是如果網(wǎng)絡很大的話，工作量會非常的大。
Arp方式監(jiān)聽的檢測
首先是借助檢測ip地址和mac地址對應的工具，如arpwatch，安裝了arpwatch的系統(tǒng)在發(fā)生mac地址變化時會在系統(tǒng)的日志文件中看到如下提示
Apr 21 23:05:00 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15)
Apr 21 23:05:02 192.168.1.35 arpwatch: flip flop 192.168.1.33 8:0:20:c8:fe:15 (0:90:6d:f2:24:0)
Apr 21 23:05:03 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15)
從提示中可以看出arpwatch檢測到了網(wǎng)關(guān)mac地址發(fā)生了改變。
其次借助于一些入侵檢測系統(tǒng)，如snort，亦可以起到的一定的檢測作用。在snort的配置文件中打開arpspoof的preprocessor開關(guān)并進行配置即可。
作者本人試驗發(fā)現(xiàn)，如果采用本地解析時，觀測局域網(wǎng)本地的dns服務器的反解是一個好的辦法，因為發(fā)起arpspoof的主機會不間斷的嘗試正反解析冒充的網(wǎng)關(guān)ip，發(fā)送數(shù)量非常多的重復解析數(shù)據(jù)包，當懷疑有arpspoof時很容易被發(fā)現(xiàn)，如下：
nameserver# tcpdump -n -s 0 port 53
tcpdump: listening on hme0
23:19:22.489417 192.168.1.35.41797 > 192.168.1.68.53:
32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF)
23:19:22.490467 192.168.1.35.41798 > 192.168.1.68.53:
32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF)
結(jié)束語：
上面我們介紹了網(wǎng)絡監(jiān)聽技術(shù)的幾個主要方面，包括網(wǎng)絡監(jiān)聽的主要技術(shù)細節(jié)，具體實現(xiàn)，檢測方法等。此外還介紹了一種非傳統(tǒng)的監(jiān)聽方式，通過本文，希望讀者能對網(wǎng)絡監(jiān)聽產(chǎn)生一些認識。
參考資料
Richard stevens: 《TCP/IP Illustrated, Volume 1: The Protocols》
Dsniff網(wǎng)站： http://www.monkey.org/~dugsong/dsniff/
Attacks Against SSH 1 And SSL的討論： http://slashdot.org/articles/00/12/18/0759236.shtml
ettercap網(wǎng)站： http://ettercap.sourceforge.net/