免费ARP

此内容为转载内容，因原文链接不明所以类型才为原创

引言

我们很多系统都是使用双机热备份系统（即一个主用，另一个备用，如果主用没有问题，备用一直处于空闲状态；如果主用出现问题，备用立刻接管）。假设主用服务器的MAC地址为：1111-1111-1111，备用服务器的MAC地址为：2222-2222-2222，通过某种软件，两台服务器共同对外共同使用一个IP，例如10.10.10.1，这样客户机在需要同服务器进行通信的时候（第一次通信的例子，在这时候ARP的缓存是空的，或至少没有10.10.10.1的MAC地址），先向局域网发送广播ARP请求报文请求10.10.10.1这个IP地址的MAC地址，得到主用服务器响应后，将10.10.10.1和对应的MAC地址放入自己的ARP缓存中，然后向这个IP发送请求就可以进行通信了。如果在通信的过程中，主用服务器突然发生故障，down机了，这时备用服务器立刻接管10.10.10.1这个IP进行服务，可是刚才那台客户机的ARP缓存表中10.10.10.1这个IP对应的MAC地址是1111-1111-1111，再往这个MAC地址发送数据包肯定是石沉大海的，怎样才能让备用接管了服务之后立刻能起作用呢？
我们能想到的方法有两种，一种就是在使用双机热备份系统，接管那个IP的时候，生成一个不依赖于任何一个主机的虚拟MAC地址，接管IP的同时也接管那个虚拟的MAC地址，这样客户机不需要做任何更改动作，ARP缓存表不变。另外一种就是在接管的同时，接管的服务器对外广播一个ARP报文给所有主机，例如在刚才的例子中，ARP广播报文的数据字段中源IP地址是10.10.10.1，源MAC地址是2222-2222-2222，目的IP地址也是10.10.10.1，目的MAC地址也是2222-2222-2222，IP报文的目的地址是：FFFF-FFFF-FFFF，这样让所有的广播网络上的主机接收该报文，并更新自己的ARP缓存表，已告知10.10.10.1这个IP的对应MAC地址已经变为2222-2222-2222，这样，刚才的那个客户机就能正确地同服务器进行通信了。
第一种方法在大多数系统中已经被采用，例如Cisco的HSRP技术中，虚拟出来的MAC地址是以0000.0c07.ac＋HSRP的group ID组成，并且限制局域网上不会存在不同应用的相同Group ID，以确保局域网上不会重复MAC地址生成。在VRRP中也是如此，原理和HSRP同。这样无论主备用如何切换，客户机不需要做任何动作。
第二种方法就是免费ARP技术（gratuitous ARP），目前应用也很广泛。

免费ARP的作用

免费ARP目前的作用有两种：

• 第一种就是刚才上面所说的宣告广播的作用，以告诉整个广播域，目前这个IP所对应的MAC地址是什么。
• 第二种是看看广播域内有没有别的主机使用自己的IP，如果使用了，则在界面上弹出“IP冲突”字样。普通ARP请求报文广播发送出去，广播域内所有主机都接收到，计算机系统判断ARP请求报文中的目的IP地址字段，如果发现和本机的IP地址相同，则将自己的MAC地址填写到该报文的目的MAC地址字段，并将该报文发回给源主机。所以只要发送ARP请求的主机接收到报文，则证明广播域内有别的主机使用和自己相同的IP地址（这里不考虑路由器的ARP代理问题）。免费ARP的报文发出去是不希望收到回应的，只希望是起宣告作用；如果收到回应，则证明对方也使用自己目前使用的IP地址。
  在所有网络设备（包括计算机网卡）up的时候，都会发送这样的免费ARP广播，以宣告并确认有没有冲突。

免费ARP带来的漏洞

根据上面第一种所起的作用能发现免费ARP带来的一个漏洞，因为目前的局域网上都没有安全的认证系统，所以任何主机都可以发送这样的免费ARP广播，这样就会出现MAC地址欺骗。假如某银行系统局域网内有服务器A，客户机B，客户机C，客户机B正在向服务器提交当天的信用卡消费和账号信息（通过某种安全通信机制进行通信，确保客户机C是无法接收到两者之间传输的数据包的），这时客户机C（攻击者）向局域网内发送了一个免费ARP广播，其源IP地址为服务器A的地址，源MAC地址为客户机C自己的MAC地址。客户机B收到这样的报文后，会将自己ARP缓存中服务器A的MAC地址改为客户机C的MAC地址，这就形成了MAC地址欺骗，这样客户机B会将所有该发给服务器A的信息都发送给客户机C，C在通过抓包分析就知道了很多不该知道的信息。通常为了确保A不再发送信息给B以改变B的ARP缓存里A的IP对应的MAC地址，C可以通过其他手段先将A工具瘫痪。这样就放心大胆地进行欺骗了。这是前几年至今都很流行的攻击手段之一。
目前针对该攻击没都有很好的防范手段，当前使用的方法有

1. 设置MAC地址和IP地址绑定。
2. 将交换机上某些端口设置为信任端口，来自这些端口的请求认为是可靠的，予以转发，其他的不转发。
   但是这些方法都很死板，不灵活。