51Testing软件测试论坛

标题: 嘛是侦听？ [打印本页]

作者: zhuyuancan 时间: 2007-10-9 17:24
标题: 嘛是侦听？
哪位高人能否解释一下侦听是嘛啊？在安全行测试中如何实现侦听

作者: jackei 时间: 2007-10-10 18:25
google 一下吧，比较基础的东西了。

作者: rickyzhu 时间: 2007-10-10 22:39
google不行，用百度也可以。

监听程序罢了。

作者: wangfeng25 时间: 2007-10-11 11:00
概念网络上太多了，不多说了~
当局域网内的主机都通过HUB等方式连接时，一般都称为共享式的连接，这种共享式的连接有一个很明显的特点：就是HUB会将接收到的所有数据向HUB上的每个端口转发，也就是说当主机根据mac地址进行数据包发送时，尽管发送端主机告知了目标主机的地址，但这并不意味着在一个网络内的其他主机听不到发送端和接收端之间的通讯，只是在正常状况下其他主机会忽略这些通讯报文而已！如果这些主机不愿意忽略这些报文，网卡被设置为promiscuous状态的话，那么，对于这台主机的网络接口而言，任何在这个局域网内传输的信息都是可以被听到的。

作者: wangfeng25 时间: 2007-10-11 11:03
类似sniffer 的工具~楼主可以找找看。
还有Windump Iris WINDOWS平台的
tcpdump Dsniff UNIX的等等~~~

作者: wangfeng25 时间: 2007-10-11 11:04
网上找的例子
我们不妨举一个例子来看看：我们现在有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步就会发生变化，这台主机将会默不作声的听到以太网内传输的所有信息，也就是说：窃听也就因此实现了！这会给局域网安全带来极大的安全问题，一台系统一旦被入侵并进入网络监听状态，那么无论是本机还是局域网内的各种传输数据都会面临被窃听的巨大可能性。

作者: wangfeng25 时间: 2007-10-11 11:04
网络监听的防范方法：

上面我们介绍了可以用来进行网络监听的软件，那么对这种不受欢迎的行为，有没有一些防范手段呢？

上面我们知道，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来实现可信的网络通讯连接。

作者: wangfeng25 时间: 2007-10-11 11:06
在系统管理员看来，网络监听的主要用途是进行数据包分析，通过网络监听软件，管理员可以观测分析实时经由的数据包，从而快速的进行网络故障定位。

我们可以举个例子： 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 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0)
ack 1087965816 win 10136 <nop,nop,timestamp 20468779 0,nop,[|tcp]> (DF)
19:04:30.040960 client.1065 > server.smtp: .
ack 1 win 64240 <nop,nop,timestamp 167656 20468779> (DF)

client连接服务器的25端口，三次握手正常，没有问题，我们再往下看

19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (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 <nop,nop,timestamp 20471382 167656> (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 <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等文件，很简单。

作者: wangfeng25 时间: 2007-10-11 11:06
检测网络监听的手段

对发生在局域网的其他主机上的监听，一直以来，都缺乏很好的检测方法。这是由于产生网络监听行为的主机在工作时总是不做声的收集数据包，几乎不会主动发出任何信息。但目前网上已经有了一些解决这个问题的思路和产品：

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

[ 本帖最后由 wangfeng25 于 2007-10-11 11:08 编辑 ]

作者: ruanyongjie 时间: 2007-10-16 12:10
真够专业的

作者: zhuyuancan 时间: 2007-10-16 14:38
怎么说是版主呢！！够敬业，够专业，够有实力

作者: hgl 时间: 2007-11-24 13:44
版主很牛啊，我顶~~~

作者: 软件测试论坛 时间: 2008-1-28 11:46

获益匪浅啊

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)