Free ARP

This content is reprinted content, because the original link is unknown, so the type is original

Introduction

Many of our systems use a dual-system hot backup system (that is, one primary and the other standby. If the primary is no problem, the backup is always in an idle state; if the primary fails, the backup will take over immediately).Suppose the MAC address of the primary server is: 1111-1111-1111, and the MAC address of the backup server is: 2222-2222-2222. Through some software, the two servers share an IP, such as 10.10.10.1, so that the clientWhen the machine needs to communicate with the server (in the example of the first communication, the ARP cache is empty at this time, or at least there is no MAC address of 10.10.10.1), it first sends a broadcast ARP request message to the LAN to request 10.10.10.1 The MAC address of this IP address, after getting the response from the main server, put 10.10.10.1 and the corresponding MAC address into its own ARP cache, and then send a request to this IP to communicate.If in the process of communication, the main server suddenly fails and goes down, then the standby server immediately takes over the IP 10.10.10.1 for service, but the ARP cache table of the client just now corresponds to the IP 10.10.10.1The MAC address is 1111-1111-1111, and sending data packets to this MAC address must be in vain. How can I make the backup work immediately after taking over the service?
There are two methods we can think of. One is to use a dual-system hot backup system to generate a virtual MAC address that does not depend on any host when taking over the IP. Taking over the IP also takes over the virtual MAC address.The MAC address of the client does not need to be changed, and the ARP cache table remains unchanged.The other is to broadcast an ARP packet to all hosts while taking over. For example, in the previous example, the source IP address in the data field of the ARP broadcast packet is 10.10.10.1, and the source MAC address is 2222.-2222-2222, the destination IP address is also 10.10.10.1, the destination MAC address is also 2222-2222-2222, and the destination address of the IP packet is: FFFF-FFFF-FFFF, so that all hosts on the broadcast network can receive the packet, and update its ARP cache table, it has been informed that the corresponding MAC address of the IP 10.10.10.1 has changed to 2222-2222-2222, so that the client just now can communicate with the server correctly.
The first method has been adopted in most systems. For example, in Cisco's HSRP technology, the virtual MAC address is composed of the group ID of 0000.0c07.ac+HSRP, and it is restricted that there will be no identical applications in different applications on the local area network.Group ID to ensure no duplicate MAC address generation on the LAN.The same is true in VRRP, and the principle is the same as that of HSRP.In this way, the client does not need to take any action no matter how the primary and secondary switches are switched.
The second method is gratuitous ARP technology (gratuitous ARP), which is also widely used at present.

The role of gratuitous ARP

There are currently two roles for gratuitous ARP:

• The first is the function of the announcement broadcast just mentioned above, to tell the entire broadcast domain what the MAC address currently corresponds to this IP is.
• The second is to see if there are other hosts in the broadcast domain that use their own IP. If so, the word "IP conflict" will pop up on the interface.The ordinary ARP request message is broadcast and sent out, and all hosts in the broadcast domain receive it. The computer system judges the destination IP address field in the ARP request message. If it finds that it is the same as the local IP address, it fills in its own MAC address into this field.The destination MAC address field of the packet, and the packet is sent back to the source host.Therefore, as long as the host sending the ARP request receives the message, it proves that there are other hosts in the broadcast domain that use the same IP address as itself (the ARP proxy problem of the router is not considered here).The gratuitous ARP message sent out does not want to receive a response, but only wants to be used as an announcement; if a response is received, it proves that the other party also uses the IP address it is currently using.
  When all network devices (including computer network cards) are up, such gratuitous ARP broadcasts will be sent to announce and confirm whether there is a conflict.

Vulnerabilities from gratuitous ARP

According to the first function above, a loophole caused by gratuitous ARP can be found. Because there is no secure authentication system on the current local area network, any host can send such a gratuitous ARP broadcast, which will appearMAC address spoofing.Suppose there are server A, client B, client C in the LAN of a banking system, and client B is submitting the credit card consumption and account information of the day to the server (communication through a certain secure communication mechanism to ensure that client C cannot receiveAt this time, client C (the attacker) sends a free ARP broadcast to the LAN, its source IP address is the address of server A, and the source MAC address is client C's own MAC address.address.After client B receives such a message, it will change the MAC address of server A in its own ARP cache to the MAC address of client C, which forms MAC address spoofing, so that client B will send all the messages to the server.A's information is sent to client C, and C knows a lot of information that should not be known through packet capture and analysis.Usually, in order to ensure that A no longer sends information to B to change the MAC address corresponding to A's IP in B's ARP cache, C can first disable A's tool through other means.This makes it easy to cheat with confidence.This is one of the most popular methods of attack in the past few years.
At present, there is no good defense against this attack. The currently used methods include

1. Set MAC address and IP address binding.
2. Set some ports on the switch as trusted ports. Requests from these ports are considered reliable and forwarded. Others are not forwarded.
   But these methods are rigid and inflexible.