网络监听技术概览

　　网络监听，在网络安全上一直是一个比较敏感的话题，作为一种发展比较成熟的技术，监听在协助网络管理员监测网络传输数据，排除网络故障等方面具有不可替代的作用，因而一直倍受网络管理员的青睐。然而，在另一方面网络监听也给以太网安全带来了极大的隐患，许多的网络入侵往往都伴随着以太网内网络监听行为，从而造成口令失窃，敏感数据被截获等等连锁性安全事件。

　　网络监听在安全领域引起人们普遍注意是在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这两个产品中有所体现。可分别参见： 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/

　　关于作者

　　宫一鸣，男，河南电信网络关键设备高级系统管理员，主任工程师，中国电信国家级跨世纪人才，中国电信网络安全小组核心成员，河南电信网络安全小组成员。