实现网络监听的工具： 
上面我们看到，一切的关键就在于网卡被设置为混杂模式的状态，这种工作复杂吗？不幸的是，这种工作并不复杂，目前有太多的工具可以做到这一点。

自网络监听这一技术诞生以来，产生了大量的可工作在各种平台上相关软硬件工具，其中有商用的，也有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 &gt; server.smtp: S 1087965815:1087965815(0) win 64240 <mss> (DF)
19:04:30.040613 server.smtp &gt; client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 <nop> (DF)
19:04:30.040960 client.1065 &gt; server.smtp: . ack 1 win 64240 (DF)

client连接服务器的25端口，三次握手正常，没有问题，我们再往下看 
19:04:30.048862 server.33152 &gt; client.113: S 99370916:99370916(0) win 8760 <mss> (DF)
19:04:33.411006 server.33152 &gt; client.113: S 99370916:99370916(0) win 8760 <mss> (DF)
19:04:40.161052 server.33152 &gt; client.113: S 99370916:99370916(0) win 8760 <mss> (DF)
19:04:56.061130 server.33152 &gt; client.113: R 99370917:99370917(0) win 8760 (DF)
19:04:56.070108 server.smtp &gt; client.1065: P 1:109(108) ack 1 win 10136 <nop> (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 &gt; server.smtp: S 1119047365:1119047365(0) win 64240 <mss> (DF)
19:06:45.775546 server.smtp &gt; client.1066: S 116566929:116566929(0) ack 1119047366 win 10136 <nop> (DF)
19:06:45.775776 client.1066 &gt; server.smtp: . ack 1 win 64240 <nop> (DF)
19:06:45.789316 server.smtp &gt; client.1066: P 1:109(108) ack 1 win 10136 <nop> (DF)
19:06:45.796767 client.1066 &gt; server.smtp: P 1:11(10) ack 109 win 64132 <nop> (DF)

我们看到，server不再进行113端口的认证尝试，直接push数据，问题应该解决，到client试验，果然延迟现象消失！

由这个试验，我们可以看到，网络监听手段，对网络的系统管理员是非常有价值的。

本文转自游来游去岛博客51CTO博客，原文链接http://blog.51cto.com/ylyqd/1881如需转载请自行联系原作者

wingking84