不是教你学坏 实战发起ARP攻击

首先， 准备测试环境。 小编打算这样做：使用三个虚拟WINDWOS XP系统， 分别为A1、A2、A3， 使用A3破坏A1与A2之间的正常通讯。

各主机详细信息

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

　　什么是VMWARE host-only (主机模式)？让我们来简单了解一下：如果你想利用VMWare创建一个与网内其他机器相隔离的虚拟系统， 进行某些特殊的网络调试工作， 可以选择host-only模式。 在VMWARE 的 host-only模式中， 所有的虚拟系统是可以相互通信的， 但虚拟系统和真实的网络是被隔离开的。

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

XP同胞三兄弟其实在“克隆”XP三胞胎时小编有个顾虑， 就是这三个系统的网卡MAC地址会不会相同， 这样肯定是不可以的。 先不管那么多， 起动这三个XP再说， 天啊， 那叫一个慢， 小编0.99G的内存——被集成显卡挖了点“墙角”， Intel Celeron CPU 1.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网络中。 “网络执法官”所在乎的似乎是主机数量， 小编将IP 10.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 ， ARP Reply数据包源地址一栏出现了数个不同的MAC地址， 这些当然都是虚假的， 这些虚假数据包真正来自何处呢？当然是A3这台就机， 也就是源地址一栏MAC地址为vmware_a2:04:9d的主机（它正在扫描整个子网）。 但糟糕的是在虚假的数据包中我们看到不“元凶”。 制造ARP欺骗

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

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

　　在上图中不知各位同学发现没有， 从A2 ping A1还是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操作超时显示 Request time out 。