关于|络监听常常会有一些有意思的问题Q如Q?我现在有q在|上的计机了,我也有了H听的Y件了Q那么我能不能窃听到微Y(或者美国国防部Q新网{等)的密码?
又如Q我是公司的局域网理员,我知道hub很不安全Q用hubq种|络l构公司的计算计互qv来,会ɾ|络监听变得非常ҎQ那么我们就换掉hubQ用交换机Q不p解决口oqq种安全问题了么Q?/p>
q是两个很有意思的问题Q我们在q里先不做回{,怿读者看完全文后会有自己正确的答案?/p>
一些基本概念:
首先Q我们知道,一台接在以太网内的计算Zؓ了和其他Lq行通讯Q在g上是需要网卡,在Y件上是需要网卡驱动程序的。而每块网卡在出厂旉?/p>
一个唯一的不与世界上M一块网卡重复的g地址Q称为mac地址。同Ӟ当网l中两台L在实现tcp/ip通讯Ӟ|卡q必ȝ定一个唯一的ip地址。下面用一个常见的unix命oifconfig来看一看作者本人的一台正常工作的机器的网卡:
[yiming@server/root]# ifconfig -a
hme0: flags=863 mtu 1500
inet 192.168.1.35 netmask ffffffe0
ether 8:0:20:c8:fe:15
从这个命令的输出中我们可以看C面讲到的q些概念Q如W二行的192.168.1.35是ip 地址Q第三行?:0:20:c8:fe:15是mac地址。请注意W一行的BROADCASTQMULTICASTQ这是什么意思?一般而言Q网卡有几种接收数据帧的状态,如unicastQbroadcastQmulticastQpromiscuous{,unicast是指|卡在工作时接收目的地址是本机硬件地址的数据。Broadcast是指接收所有类型ؓq播报文的数据。Multicast是指接收特定的组播报文。Promiscuous则是通常说的h模式Q是指对报文中的目的g地址不加M查,全部接收的工作模式。对照这几个概念Q看看上面的命o输出Q我们可以看刎ͼ正常的网卡应该只是接收发往自n的数据报文,q播和组播报文,请大家记住这个概c?/p>
对网l用者来_览|页Q收发邮件等都是很^常,很简便的工作Q其实在后台q些工作是依靠tcp/ip协议族实现的Q大家知道有两个主要的网l体p:OSI参考模型和TCP/IP参考模型,OSI模型即ؓ通常说的7层协议,它由下向上分别ؓ物理层、数据链路层、网l层、传输层、会话层、表C层、应用层Q而tcp/ip模型中去掉了会话层和表示层后Q由剩下?层构成了互联|的基础Q在|络的后台默默的工作着?/p>
下面我们不妨从tcp/ip模型的角度来看数据包在局域网内发送的q程Q当数据由应用层自上而下的传递时Q在|络层Ş成ip数据报,再向下到达数据链路层Q由数据链\层将ip数据报分割ؓ数据帧,增加以太|包_再向下一层发送。需要注意的是,以太|的包头中包含着本机和目标设备的mac地址Q也卻I链\层的数据帧发送时Q是依靠48bits的以太网地址而非ip地址来确认的Q以太网的网卡设备驱动程序不会关心ip数据报中的目的ip地址Q它所需要的仅仅是mac地址。目标ip的mac地址又是如何获得的呢Q发端主Z向以太网上的每个L发送一份包含目的地的ip地址的以太网数据?UCؓarp数据?Qƈ期望目的L回复Q从而得到目的主机对应的mac地址Qƈ这个mac地址存入自己的一个arp~存内?/p>
当局域网内的L都通过HUB{方式连接时Q一般都UCؓ׃n式的q接Q这U共享式的连接有一个很明显的特点:是HUB会将接收到的所有数据向HUB上的每个端口转发Q也是说当LҎmac地址q行数据包发送时Q尽发送端L告知了目标主机的地址Q但qƈ不意味着在一个网l内的其他主机听不到发送端和接收端之间的通讯Q只是在正常状况下其他主Z忽略q些通讯报文而已Q如果这些主Z愿意忽略q些报文Q网卡被讄为promiscuous状态的话,那么Q对于这C机的|络接口而言QQ何在q个局域网内传输的信息都是可以被听到的?/p>
例子Q?br /> 我们不妨举一个例子来看看Q我们现在有A,B两台LQ通过hub相连在一个以太网内,现在AZ的一个用h要访问B机提供的WWW服务Q那么当AZ的用户在览器中键入B的ip地址Q得到B机提供的web服务Ӟ?层结构的角度上来看都发生了什么呢Q?/p>
1Q首先,当A上的用户在浏览器中键入B机的地址Q发出浏览请求后QA机的应用层得到请求,要求讉KIP地址为B的主机,
2Q应用层于是请求发送到7层结构中的下一层传输层Q由传输层实现利用tcp对ip建立q接?/p>
3Q传输层数据报交到下一层网l层Q由|络层来选\
4Q由于AQB两机在一个共享网l中QIP路由选择很简单:IP数据报直接由源主机发送到目的L?/p>
5Q由于AQB两机在一个共享网l中Q所以A机必d32bit的IP地址转换?8bit的以太网地址Q请注意q一工作是由arp来完成的?/p>
6Q链路层的arp通过工作在物理层的hub向以太网上的每个L发送一份包含目的地的ip地址的以太网数据帧,在这份请求报文中xQ谁是B机IP地址的拥有者,请将你的g地址告诉我?/p>
7Q在同一个以太网中的每台机器都会"接收"(h意这一点!)到这个报文,但正常状态下除了B机外其他L应该会忽略这个报文,而B机网卡驱动程序识别出是在L自己的ip地址Q于是回送一个arp应答Q告知自qip地址和mac地址?/p>
8QA机的|卡驱动E序接收CB机的数据帧,知道了B机的mac地址Q于是以后的数据利用q个已知的MAC地址作ؓ目的地址q行发送。同在一个局域网内的L虽然也能"?到这个数据Q但是都保持静默Q不会接收这个不属于它的数据帧?/p>
上面是一U正常的情况Q如果网卡被讄Zؓh模式(promiscuous)Q那么第8步就会发生变化,q台L会默不作声的听C太网内传输的所有信息,也就是说Q窃听也因此实CQ这会给局域网安全带来极大的安全问题,一台系l一旦被入Rq进入网l监听状态,那么无论是本是局域网内的各种传输数据都会面被窃听的巨大可能性。实现网l监听的工具Q?/p>
上面我们看到Q一切的关键在于网卡被讄为杂模式的状态,q种工作复杂吗?不幸的是Q这U工作ƈ不复杂,目前有太多的工具可以做到q一炏V?/p>
自网l监听这一技术诞生以来,产生了大量的可工作在各种q_上相兌Yg工具Q其中有商用的,也有free的。在google上用sniffer tools作ؓ关键字,可以扑ֈ非常多?/p>
作者在q里列D一些作者喜Ƣ的软gQ供有兴的读者参考用?/p>
Windowsq_下的Q?/p>
Windump
Windump是最l典的unixq_上的tcpdump的windowUL版,和tcpdump几乎完全兼容Q采用命令行方式q行Q对用惯tcpdump的h来讲会非帔R手。目前版本是3.5.2Q可q行在Windows 95/98/ME/Windows NT/2000/XPq_?
Iris
Eeye公司的一ƾ付费YӞ有试用期Q完全图形化界面Q可以很方便的定制各U截h制语句,Ҏh据包q行分析Q还原等。对理员来讲很Ҏ上手Q入门和高U管理员都可以从q个工具上得到自己想要得东西。运行在Windows 95/98/ME/Windows NT/2000/XPq_?
unixq_下的Q?/p>
tcpdump
不多_最l典的工P被大量的*nixpȝ采用Q无需多言?
ngrep
和tcpdumpcMQ但与tcpdump最大的不同之处在于Q借助于这个工P理员可以很方便的把截获目标定制在用户名Q口令等感兴的关键字上?
snort
目前很红火的免费的idspȝQ除了用作ids以外Q被用来sniffer也非怸错,可以借助工具或是依靠自n能力完全q原被截L数据?
Dsniff
作者设计的出发Ҏ用这个东西进行网l渗透测试,包括一套小巧好用的工P主要目标攑֜口oQ用戯问资源等敏感资料上,非常有特Ԍ工具包中的arpspoofQmacof{工具可以o人满意的捕获交换机环境下的主机敏感数据?
Ettercap
和dsniff在某些方面有怼之处Q也可以很方便的工作在交换机环境下提C:国内用户讉Kq个站点需要用代理服务器?
Sniffit
被广泛用的|络监听软gQ截获重点在用户的输出?|络监听的具体实玎ͼ
在系l管理员看来Q网l监听的主要用途是q行数据包分析,通过|络监听软gQ管理员可以观测分析实时l由的数据包Q从而快速的q行|络故障定位?/p>
我们可以举个例子Q?server是邮件服务器Q下面带了很多的client用户Q邮件服务器收发邮g工作正常Q但下面的client用户L抱怨发邮g时连接到邮g服务器后要等待很久的旉才能开始发送工作,问题出在哪里呢?
在server上用tcpdumpҎ自其中的一个client的数据包q行捕获分析Q看看结果如何?
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)
clientq接服务器的25端口Q三ơ握手正常,没有问题Q我们再往下看
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)
q里有问题了Q我们看到server端试图连接client?13认证端口Q然而client端ƈ不会d应它Qserver端从19?4?0U到19?4?6U尝?ơ,Ҏ26U后Q才攑ּ认证试Q主动reset了client端的113端口Q开始push后面的数据,而正是在q个q程中所p的时_使用户发送邮件时产生了O长的{待。?br /> 问题扑ֈ了,下面的工作就好办了,通过修改服务器端的Y仉|,使它不再q行113端口的认证,看看q个问题解决了么Q不用问client用户Q再抓包如下Q?/p>
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)
我们看到Qserver不再q行113端口的认证尝试,直接push数据Q问题应该解冻I到client试验Q果然gq现象消失!
p个试验,我们可以看到Q网l监听手D,对网l的pȝ理员是非常有h值的?/p>
然而,对入侵者呢Q与理员感兴趣的是Ҏ据包q行分析不同Q入侵者,感兴的是数据包的内容,其是̎P口o{敏感内宏V?/p>
我们模仿入R者在L上跑一个上面提到的sniffit软gQ监听本机发出去的所有telnet数据Q如下:
server#./sniffit -A . -p 23 -s server
同时Q我们模仿一个用户yimingd一台client机器Q?/p>
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
$
我们看到q个用户telnet到client机器Q输入̎号口令,执行了lsQpwd命oQ?/p>
此时看看sniffit的记录文件记录了什么,
server# more server.32780-client.23
........... ..!.."..'.......h.7....#..$....VT100....'.........yiming..Power^man!..ls ..pwd..
我们看到了̎号yimingQ密码Power^man!Q还有登录后操作的命令。请注意一点,yimingq个用户管讄了非常复杂的密码Q但对网l监听而言Q是没有丝毫意义的?/p>
其实除了截获telnet密码q样的功能外Q专用的|络监听软g从密码到邮gQ浏览的|页{内容,无所不包Q但׃本文不是介绍|络监听软g用途的Q因此这里不详细叙述各种监听软g的用方法,有兴的读者可以参照各个Y件的readme{文Ӟ很简单?br /> |络监听的防范方法:
上面我们介绍了可以用来进行网l监听的软gQ那么对q种不受Ƣ迎的行为,有没有一些防范手D呢Q?/p>
上面我们知道Qsniffer是发生在以太|内的,那么Q很明显Q首先就要确保以太网的整体安全性,因ؓsniffer行ؓ要想发生Q一个最重要的前提条件就是以太网内部的一台有漏洞的主ȝQ只有利用被ȝ的主机,才能q行snifferQ去攉以太|内敏感的数据信息?/p>
其次Q采用加密手D也是一个很好的办法Q因为如果sniffer抓取到的数据都是以密文传输的Q那对入侵者即使抓取到了传输的数据信息Q意义也是不大的-比如作ؓtelnetQftp{安全替代品目前采用ssh2q是安全的。这是目前相对而言使用较多的手D之一Q在实际应用中往往是指替换掉不安全的采用明文传输数据的服务Q如在server端用ssh,openssh{替换unixpȝ自带的telnet,ftp,rshQ在client端用securecrt,sshtransfer替代telnet,ftp{?/p>
除了加密外,使用交换机目前也是一个应用比较多的方式,不同于工作在W一层的hub,交换机是工作在二层,也就是说数据链\层的Q以CISCO的交换机ZQ交换机在工作时l护着一张ARP的数据库Q在q个库中记录着交换机每个端口绑定的MAC地址Q当有数据报发送到交换ZӞ交换Z数据报的目的MAC地址与自q护的数据库内的端口对照,然后数据报发送到"相应?端口上,注意Q不同于HUB的报文广播方式,交换{发的报文是一一对应的。对二层讑֤而言Q仅有两U情况会发送广播报文,一是数据报的目的MAC地址不在交换机维护的数据库中Q此时报文向所有端口{发,二是报文本n是q播报文。由此,我们可以看到Q这在很大程度上解决了网l监听的困扰。但是有一点要注意Q随着dsniffQettercap{Y件的出现Q交换机的安全性已l面临着严峻的考验Q我们将在后面对q种技术进行介l?/p>
此外Q对安全性要求比较高的公司可以考虑kerberosQkerberos是一Uؓ|络通信提供可信W三Ҏ务的面向开攄l的认证机制Q它提供了一U强加密机制使client端和server即在非安全的网l连接环境中也能认彼此的n份,而且在双斚w过w䆾认证后,后箋的所有通讯也是被加密的。在实现中也卛_立可信的W三Ҏ务器保留与之通讯的系l的密钥数据库,仅kerberos和与之通讯的系l本w拥有私?private key)Q然后通过private key以及认证时创建的session key来实现可信的|络通讯q接?/p>
网l监听的手段
对发生在局域网的其他主Z的监听,一直以来,都缺乏很好的方法。这是由于生网l监听行为的L在工作时L不做声的攉数据包,几乎不会d发出M信息。但目前|上已经有了一些解册个问题的思\和品:
1Q反应时?
向怀疑有|络监听行ؓ的网l发送大量垃圾数据包Q根据各个主机回应的情况q行判断Q正常的pȝ回应的时间应该没有太明显的变化,而处于杂模式的pȝ׃对大量的垃圾信息照单全收Q所以很有可能回应时间会发生较大的变化?
2Q观dns
许多的网l监听Y仉会尝试进行地址反向解析Q在怀疑有|络监听发生时可以在dnspȝ上观有没有明显增多的解析请求?
3Q利用ping模式q行监测
上面我们说过Q当一C入杂模式时Q以太网的网卡会所有不属于他的数据照单全收。按照这个思\Q我们就可以q样来操作:假设我们怀疑的L的硬件地址?0:30:6E:00:9B:B9,它的ip地址?92.168.1.1,那么我们现在伪造出q样的一Uicmp数据包:g地址是不与局域网内Q何一C机相同的00:30:6E:00:9B:9B,目的地址?92.168.1.1不变Q我们可以设想一下这U数据包在局域网内传输会发生什么现象:M正常的主Z查这个数据包Q比较数据包的硬件地址Q和自己的不同,于是不会理会q个数据包,而处于网l监听模式的L呢?׃它的|卡现在是在h模式的,所以它不会d比这个数据包的硬件地址Q而是这个数据包直接传到上层Q上层检查数据包的ip地址Q符合自qipQ于是会对对q个ping的包做出回应。这P一台处于网l监听模式的Lp发现了?
q种ҎQ在10phtq个黑客l织的antisniff产品中有很好的体现。可参见Q? http://www.securitysoftwaretech.com/antisniff/download.html
4Q利用arp数据包进行监?
除了使用pingq行监测外,目前比较成熟的有利用arp方式q行监测的。这U模式是上述ping方式的一U变体,它用arp数据包替代了上述的icmp数据包。向局域网内的L发送非q播方式的arp包,如果局域网内的某个L响应了这个arphQ那 么我们就可以判断它很可能是处于|络监听模式了,q是目前相对而言比较好的监测模式?