实战发起ARP攻击Word文件下载.docx

实战发起ARP攻击Word文件下载.docx

《实战发起ARP攻击Word文件下载.docx》由会员分享，可在线阅读，更多相关《实战发起ARP攻击Word文件下载.docx（12页珍藏版）》请在冰豆网上搜索。

　　注意!

在“搞破坏”时不能对公司的网络产生任何影响——这点要绝对注意，任何时刻，任何人都不该通过任何方式考验我们的网络，所以小编在做测试时都是断网操作的——禁用物理PC上的物理网卡，在VMWARE中使用Host-only主机模式。

　　什么是VMWAREhost-only（主机模式）？

让我们来简单了解一下：

如果你想利用VMWare创建一个与网内其他机器相隔离的虚拟系统，进行某些特殊的网络调试工作，可以选择host-only模式。

在VMWARE的host-only模式中，所有的虚拟系统是可以相互通信的，但虚拟系统和真实的网络是被隔离开的。

　　搭建环境的步骤很简单，小编使用VMWARE安装了一个WINDOWSXP系统，然后退出VMWARE，将虚拟XP的实体文件COPY两份，这样小编就有了三份XP。

XP同胞三兄弟

其实在“克隆”XP三胞胎时小编有个顾虑，就是这三个系统的网卡MAC地址会不会相同，这样肯定是不可以的。

先不管那么多，起动这三个XP再说，天啊，那叫一个慢，小编0.99G的内存——被集成显卡挖了点“墙角”，IntelCeleronCPU1.6G，也就这速度了，下回不同时起动它们三个就是了。

起动后立刻查看这三个系统虚拟网卡的MAC地址，有点出乎编的意外，WMWARE已经为它们各自分配了不同的MAC。

小编想验证一下，对于VMWARE，MAC是被随机生成的，还是真的VMWARE比较“聪明”？

“智商”测验题目很简单，记下当前MAC，重起XP，比对一下前后的MAC，结果证明——VMWARE还是比较聪明的。

The"

3"

　　环境准备好后，安装“网络执法官”，安装完毕当选择要监控的网卡时“网络执法官”报了个错，如下图，由于小编为主机A3分配的是一个A类地址，每个A类IP网段可容纳16777216台主机，远超过了“网络执法官”所要求的65536台主机这一数量，看来“网络执法官”默认情况下无法使用在A类IP网络中。

　在这里所描述的A类IP地址为什么是1677216个而不是1677214个，小编在这里要说明一下，1677214这个数量是除去了主机位全部为0和全部为1的两个地址，例如IP地址：

10.0.0.0/8和10.255.255.255/8，这两个地址不能分配给网段中的设备使用，前者主机位全部为0，这个IP地址所表示的是当前网络的网络地址，而非是某个主机地址，而后者所表示的是10.0.0.0这个网段的广播地址。

这两个地址虽不能分配给终端设备使用，但对于网络来讲它们确实起着各自的作用，如下图，主机发送的广播包，此时的网络地址是：

10.0.0.0，子网掩码是：

255.255.255.0，或表示为10.0.0.0/24，广播地址是10.0.0.255。

此时就不难理解为什么“网络执法官”所监控的IP地址范围是65536个，而不是65534个。

65534是B类IP网段所能容纳的可供分配的IP地址个数。

10.0.0.0/24网段上的广播包

　　稍等，小编收回刚才所说的话，“网络执法官”并非不能使用在A类IP网络中。

“网络执法官”所在乎的似乎是主机数量，小编将IP10.0.0.10的子网掩码由默认的255.0.0.0改为255.255.255.0后，成功进入，此时的IP地址范围为10.0.0.1–10.0.0.254。

点击确定后“网络执法官”将检查以太网中的活动主机，并列出相关信息，如下图：

　　让我们使用Wireshark从另一个角度看一下“网络执法官”都做了些什么？

　　“网络执法官”将整个子网（10.0.0.1-10.0.0.254）都扫描了个遍，具体方法当然就是使用ARP协议了，如果某个IP地址被使用，则会被“网络执法官”登记在册，如10.0.0.10这个IP地址，它就成为了“网络执法官”的第一个收获，也就是主机A1。

随后它还发现了10.0.0.20这个IP，也就是主机A2。

制造IP地址冲突

　　使用“网络执法官”制造IP地址冲突非常简单，小编之前在《ARP攻击之制造IP地址冲突》一文中有介绍过WINDOWS系统是使用什么机制来判断以太网中是否存在冲突IP地址的，现在我们可以通过实践来加深一下理解。

　　小编右键选中主机A，选择“手工管理”，管理方式为IP冲突，频率设置为每5秒造成1次。

　　为什么设置为5秒？

设置为5秒只是为了方便在主机A1上使用Wireshark查看收到的攻击数据包。

　　如上图所示的情况，针对目标地址vmware_64:

ab:

ea，ARPReply数据包源地址一栏出现了数个不同的MAC地址，这些当然都是虚假的，这些虚假数据包真正来自何处呢？

当然是A3这台就机，也就是源地址一栏MAC地址为vmware_a2:

04:

9d的主机（它正在扫描整个子网）。

但糟糕的是在虚假的数据包中我们看到不“元凶”。

制造ARP欺骗

　　现在小编使用主机A3通过ARP欺骗破坏主机A1与外界的通讯，实施步骤很简单，在“网络执法官”中使用“手工管理”下的“禁止与所有其它主机（含关键主机）的连接”，如下图：

　　主机A3在持续不断的攻击A1，现在我们在主机A2上测试一下与主机A1之间的通讯状况。

　　在上图中不知各位同学发现没有，从A2pingA1还是ping通了一次的。

从第二个ping包开始就不通了，而且以后也别想ping通，为什么能ping通第一次呢？

因为在ping之前，小编使用arp–d命令清空了主机A2的ARP缓存表，ping在通过ARP协议解析A1的MAC地址时还是成功的，不过也就在此刻被“网络执法官”发现了，随后“网络执法官”开始向A2发送虚假的ARP数据包，更新了A2上的ARP缓存表，A1正确的MAC地址是00-0C-29-64-AB-EA，而非00-0C-29-5D-D3-88——这时A2就“迷路”了，找不到A1了。

　　让我们看一下Wireshark中的情况：

　　如上图中23行-26行所示，第一次的ping操作是成功的，但在接下来的第27、28行你就可以看到，虚假的ARP被发送到主机A1和A2上，主机A2更新的自己的ARP缓存表后，开始发出第二次ping操作——第29行中的内容，但却收不到回应，直到ping操作超时显示Requesttimeout。