问题找到了，下面的工作就好办了，通过修改服务器端的软件配置，使它不再进行113端口的认证，看看这个问题解决了么？不用问client用户，再抓包如下：

    server# tcpdump host client
    tcpdump: listening on hme0
    19:06:45.775516 client.1066 ＞ server.smtp: S 1119047365:1119047365（0） win 64240 ＜mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]＞ （DF）
    19:06:45.775546 server.smtp ＞ client.1066: S 116566929:116566929（0） ack 1119047366 win 10136 ＜nop,nop,timestamp 20482353 0,nop,[|tcp]＞ （DF）
    19:06:45.775776 client.1066 ＞ server.smtp: . ack 1 win 64240 ＜nop,nop,timestamp 169013 20482353＞ （DF）
    19:06:45.789316 server.smtp ＞ client.1066: P 1:109（108） ack 1 win 10136 ＜nop,nop,timestamp 20482354 169013＞ （DF）
    19:06:45.796767 client.1066 ＞ server.smtp: P 1:11（10） ack 109 win 64132 ＜nop,nop,timestamp 169013 20482354＞ （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这两个产品中有所体现。可分别参见：
　　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
    nbsp; Interface: 192.168.1.37
    Internet Address Physical Address Type
    192.168.1.33 00-90-6d-f2-24-00 dynamic