2.2 破解方案
下图是破解试验的结构示意图。其内部服务器和外部服务器都提供Web服务,防火墙中实现了MAC地址和IP地址的绑定。报文中的源MAC地址与1P地址对如果无法与防火墙中设置的MAC地址与1P地址对匹配,将无法通过防火墙。主机2和内部服务器都是内部网络中的合法机器;主机1是为了做实验而新加入的机器。安装的操作系统是W2000企业版,网卡是3Com的。
试验需要修改主机1中网卡的MAC和IP地址为被盗用设备的MAC和IP地址。首先,在控制面板中选择“网络和拨号连接”,选中对应的网卡并点击鼠标右键,选择属性,在属性页的“常规”页中点击“配置”按钮。在配置属性页中选择“高级”,再在“属性”栏中选择“Network Address”,在“值”栏中选中输人框,然后在输人框中输人被盗用设备的MAC地址,MAC地址就修改成功了。
然后再将IP地址配置成被盗用设备的IP地址。盗用内部客户机IP地址:将主机1的MAC地址和IP地址分别修改为主机2的MAC地址和IP地址。主机1可以访问外部服务器,能够顺利地通过防火墙,访问权限与主机2没有分别。而且,与此同时主机2也可以正常地访问外部服务器,完全不受主机1的影响。无论是主机2还是防火墙都察觉不到主机1的存在。主机1
如果访问内部服务器,根本无需通过防火墙,更是畅通无阻了。
盗用内部服务器IP地址:将主机1的MAC地址和U地址修改为内部服务器的MAC地址和IP地址。主机1也提供Web服务。为了使效果更明显,主机1上提供的Web服务内容与内部服务器提供的内容不同。
因为在实际的实验中主机1与主机2连在同一个HUB上,主机2的访问请求总是先被主机1响应,主机2期望访问的是内部服务器,得到的却总是主机1提供的内容。更一般地,主机2如果试图访问内部服务器,获得的到底是主机1提供的内容还是内部服务器提供的内容具有随机性,要看它的访问请求首先被谁响应,在后面的分析中我们将进一步对此进行阐述。
盗用服务器的MAC和IP危害可能更大,如果主机1提供的Web内容和内部服务器中的内容一样,那么主机2将无法识别它访问的到底是哪个机器;如果Web内容中要求输人账号、密码等信息,那么这些信息对于主机1来说则是一览无遗了。
3 破解成功的原因
上面的实验验证了绑定MAC地址与IP地址的确存在很大的缺陷,无法有效地防止内部IP地址被盗用。接下来,将从理论上对该缺陷进行详细的分析。
缺陷存在的前提是网卡的混杂接收模式,所谓混杂接收模式是指网卡可以接收网络上传输的所有报文,无论其目的MAC地址是否为该网卡的MAC地址。正是由于网卡支持混杂模式,才使网卡驱动程序支持MAC地址的修改成为可能;否则,就算修改了MAC地址,但是网卡根本无法接收相应地址的报文,该网卡就变得只能发送,无法接收,通信也就无法正常进行了。
MAC地址可以被盗用的直接原因是网卡驱动程序发送Ethernet报文的实现机制。Ethernet报文中的源MAC地址是驱动程序负责填写的,但驱动程序并不从网卡的EEPROM中读取MAC,而是在内存中建立一个MAC地址缓存区。网卡初始化的时候将EEPROM中的内容读入到该缓存区。如果将该缓存区中的内容修改为用户设置的MAC地址,以后发出去的Ethernet报文的源地址就是修改后的MAC地址了。
如果仅仅是修改MAC地址,地址盗用并不见得能够得逞。Ethernet是基于广播的,Ethernet网卡都能监听到局域网中传输的所有报文,但是网卡只接收那些目的地址与自己的MAC地址相匹配的Ethernet报文。如果有两台具有相同MAC地址的主机分别发出访问请求,而这两个访问请求的响应报文对于这两台主机都是匹配的,那么这两台主机就不只接收到自己需要的内容,而且还会接收到目的为另外一台同MAC主机的内容。
按理说,两台主机因为接收了多余的报文后,都应该无法正常工作,盗用马上就会被察觉,盗用也就无法继续了;但是,在实验中地址被盗用之后,各台实验设备都可以互不干扰的正常工作。这又是什么原因呢?答案应该归结于上层使用的协议。
目前,网络中最常用的协议是TCP/IP协议,网络应用程序一般都是运行在TCP或者UDP之上。例如,实验中Web服务器采用的HTTP协议就是基于TCP的。在TCP或者UDP中,标志通信双方的不仅仅是IP地址,还包括端口号。在一般的应用中,用户端的端口号并不是预先设置的,而是协议根据一定的规则生成的,具有随机性。像上面利用IE来访问Web服务器就是这样。UDP或者TCP的端口号为16位二进制数,两个16位的随机数字相等的几率非常小,恰好相等又谈何容易?两台主机虽然MAC地址和IP地址相同,但是应用端口号不同,接收到的多余数据由于在TCP/UDP层找不到匹配的端口号,被当成无用的数据简单地丢弃了,而TCP/UDP层的处理对于用户层来说是透明的;所以用户可以“正确无误”地正常使用相应的服务,而不受地址盗用的干扰。
当然,某些应用程序的用户端口号可能是用户或者应用程序自己设置的,而不是交给协议来随机的生成。那么,结果又会如何呢?例如,在两台MAC地址和IP地址都相同的主机上,启动了两个端口相同的应用程序,这两个应用是不是就无法正常工作了呢?其实不尽然。
如果下层使用的是UDP协议,两个应用将互相干扰无法正常工作。如果使用的是TCP协议,结果就不一样了。因为TCP是面向连接的,为了实现重发机制,保证数据的正确传输,TCP引入了报文序列号和接收窗口的概念。在上述的端口号匹配的报文中,只有那些序列号的偏差属于接收窗口之内的报文才会被接收,否则,会被认为是过期报文而丢弃。TCP协议中的报文的序列号有32位,每个应用程序发送的第一个报文的序列号是严格按照随机的原则产生的,以后每个报文的序列号依次加1。
窗口的大小有16位,也就是说窗口最大可以是216,而序列号的范围是232,主机期望接收的TCP数据的序列号正好也处于对方的接收范围之内的概率为1/216,可谓小之又小。 TCP的序列号本来是为了实现报文的正确传输,现在却成了地址盗用的帮凶。
4 解决MAC与IP地址绑定被破解的方法
解决MAC与IP地址绑定被破解的方法很多,,主要以下几种。
交换机端口、MAC地址和IP地址三者绑定的方法;代理服务与防火墙相结合的方法;用PPPoE协议进行用户认证的方法;基于目录服务策略的方法;统一身份认证与计费软件相结合的方法等。在这里笔者尤其推荐最后一种方法,这种方法是将校园网办公自动化系统和网络计费软件结合在一起而实现的,这在校园网信息化建设的今天具有很强的实践性。
文章转载地址:http://www.365master.com/kt_article_show.php?article_id=15190&categ_code=10041003