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