然而，對入侵者呢？與管理員感興趣的是對資料報進行分析不同，入侵者，感興趣的是資料報的內容，尤其是賬號，口令等敏感內容。
我們模仿入侵者在主機上跑乙個上面提到的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等軟體的出現，交換機的安全性已經面臨著嚴峻的考驗！我們將在後面對這種技術進行介紹。
檢測網路監聽的手段
對發生在區域網的其他主機上的監聽，一直以來，都缺乏很好的檢測方法。這是由於產生網路監聽行為的主機在工作時總是不做聲的收集資料報，幾乎不會主動發出任何資訊。但目前網上已經有了一些解決這個問題的思路和產品：
1：反應時間
向懷疑有網路監聽行為的網路傳送大量垃圾資料報，根據各個主機回應的情況進行判斷，正常的系統回應的時間應該沒有太明顯的變化，而處於混雜模式的系統由於對大量的垃圾資訊照單全收，所以很有可能回應時間會發生較大的變化。
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產品中有很好的體現。可參見：
4：利用arp資料報進行監測
除了使用ping進行監測外，目前比較成熟的有利用arp方式進行監測的。這種模式是上述ping方式的一種變體，它使用arp資料報替代了上述的icmp資料報。向區域網內的主機傳送非廣播方式的arp包，如果區域網內的某個主機響應了這個arp請求，那 麼我們就可以判斷它很可能就是處於網路監聽模式了，這是目前相對而言比較好的監測模式。
這種方式，在neped和promiscan這兩個產品中有所體現。可分別參見：
值得注意的是，現在網際網路上流傳著一些基於上面這兩種技術的指令碼和程式，它們宣稱自己能準確捕捉到區域網內所有進行網路監聽的主機，目前來講，這種說法基本上是不可靠的，因為上述技術在實現中，除了要考慮網絡卡的硬體過濾外，還需要考慮到不同作業系統可能產生的軟體過濾。因為雖然理論上網絡卡處於混雜模式的系統應該接收所有的資料報，但實際上不同的作業系統甚至相同的作業系統的不同版本在tcp/ip的實現上都有自己的一些特點，有可能不會接收這些理論上應該接收的資料報。
除了上述幾種方式外，還有一些其他的方式，如：檢測hub燈，但相比侷限性就更大了，只能作為上述模式的補充。
安全的交換機？
文章到這裡結束了嗎？沒有，我們還漏掉了乙個很重要的監聽手段-交換環境下面的網路聽，這是個很有必要談及的話題，筆者作為網路管理員參加了許多的工程決策，吃驚的發現許多的公司都還停留在交換機是區域網安全的徹底解決之道的概念上。
應該認識到這個概念是個傳說，是的，在以前，的確是這樣的，但隨著上面介紹的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的主機，這樣即使系統連線在交換機上，也不會影響對資料報的攫取，由此就輕鬆的通過交換機實現了網路監聽。
oracle RAC 監聽原理簡介
rac1 rac2 都需需要配置監聽，各自監聽自己的 例項 客戶端使用server的虛擬ip配置2個監聽位址 為什麼使用虛擬位址?監聽位址使用 vip 如果沒有vip，連線失敗節點的process會有乙個比較長的tcp超時等待，才能返回錯誤，有了vip後，節點失效後，由於vip漂移到其它節點，連線該...
網路監聽 Sniffer
sniffer 嗅探器 就是利用計算機的網路介面截獲目的地為其他計算機的資料報文的一種技術。該技術被廣泛應用於網路維護和管理方面，它工作的時候就像一部被動聲納，默默的接收著來自網路的各種資訊，通過對這些資料的分析，網路管理員可以深入了解網路當前的執行狀況，以便找出所關心的網路中潛在的問題。sniff...
監聽網路狀態
using system using system.threading using system.runtime.interopservices namespace network static networkhelper public static networkhelper getnetwork...