普通网管变网络高手 网络监听全解

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

　　网络监听在安全领域引起人们普遍注意是在 94 年开始的，在那一年 2 月间，相继发生了几次大的安全事件，一个不知名的人在众多的主机和骨干网络设备上安装了网络监听软件，利用它对美国骨干互联网和军方网窃取了超过 100000 个有效的用户名和口令。上述事件可能是互联网上最早期的大规模的网络监听事件了，它使早期网络监听从 " 地下 " 走向了公开，并迅速的在大众中普及开来。

　　关于网络监听常常会有一些有意思的问题，如： " 我现在有连在网上的计算机了，我也有了窃听的软件了，那么我能不能窃听到微软 ( 或者美国国防部，新浪网等等 ) 的密码 ?

　　又如：我是公司的局域网管理员，我知道 hub 很不安全，使用 hub 这种网络结构将公司的计算计互连起来，会使网络监听变得非常容易，那么我们就换掉 hub ，使用交换机，不就能解决口令失窃这种安全问题了么 ?

　　这是两个很有意思的问题，我们在这里先不做回答，相信读者看完全文后会有自己正确的答案。

　　 基本概念：认清 mac 地址和 ip 地址

　　首先，我们知道，一台接在以太网内的计算机为了和其他主机进行通讯，在硬件上是需要网卡，在软件上是需要网卡驱动程序的。而每块网卡在出厂时都有一个唯一的不与世界上任何一块网卡重复的硬件地址，称为 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 产品中有很好的体现。可参见： [url]http://www.securitysoftwaretech.com/antisniff/download.html[/url]

　　 4 ：利用 arp 数据包进行监测

　　除了使用 ping 进行监测外，目前比较成熟的有利用 arp 方式进行监测的。这种模式是上述 ping 方式的一种变体，它使用 arp 数据包替代了上述的 icmp 数据包。向局域网内的主机发送非广播方式的 arp 包，如果局域网内的某个主机响应了这个 arp 请求，那 么我们就可以判断它很可能就是处于网络监听模式了，这是目前相对而言比较好的监测模式。

　　这种方式，在 neped 和 PromiScan 这两个产品中有所体现。可分别参见：

　　 [url]http://www.apostols.org/[/url] 、

　　 [url]http://www.securityfriday.com/ToolDownload/PromiScan/promiscan_doc.html[/url]

　　值得注意的是，现在互联网上流传着一些基于上面这两种技术的脚本和程序，它们宣称自己能准确捕捉到局域网内所有进行网络监听的主机，目前来讲，这种说法基本上是不可靠的，因为上述技术在实现中，除了要考虑网卡的硬件过滤外，还需要考虑到不同操作系统可能产生的软件过滤。因为虽然理论上网卡处于混杂模式的系统应该接收所有的数据包，但实际上不同的操作系统甚至相同的操作系统的不同版本在 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-f 2-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-f 2-24-00  dynamic

　　我们看到 a 机中保留着网关的 ip 地址 192.168.1.33 和对应的 mac 地址 00-90-6d-f 2-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-f 2-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)

　　 结束语

　　上面我们介绍了网络监听技术的几个主要方面，包括网络监听的主要技术细节，具体实现，检测方法等。此外还介绍了一种非传统的监听方式，通过本文，希望读者能对网络监听产生一些认识。

本文出自 51CTO.COM技术博客