No matter how strong your security measures are, there is an attacker working to get through them. Treating this as inevitable is key to keeping your data safe and secure. In our two-part packet delivery process blogs here and here we learned a switch is involved in ARP routing. This is one of the devices attackers target. It is also a great line of defense to keeping attackers out of your confidential server data. In this article, we give you the various ways to help keep your information safe and your ARP protected.
When a device needs to send a packet, it uses the IP address of the destination host. However, knowing only the IP address is not enough. When the device encapsulates the packet into a frame, the frame also contains the MAC address of the destination host.
Whether pinging a device, printing a document, or uploading a file on a server, the same principle always applies. As a result, without knowing the destination MAC address, the encapsulation process cannot finish, and the packet will not be sent.
The easiest way for a device to learn the MAC address of the destination host is by using the Address Resolution Protocol (ARP). ARP messages are exchanged between the source and destination host so that the source host learns the MAC address of the destination.
Though, since normal network operations heavily depend on ARP, appropriate protection must also be implemented to protect against potential ARP spoofing attacks that can severely affect a network.
In this article, we will discover:
Before we continue, ask yourself a couple of questions:
Do I have the time to handle configurations to protect against spoofing attacks?
Do I have the bandwidth to configure my devices and set up firewalls?
If you answered "No" to these questions, consider hiring an engineer to take on these configurations.
PivIT's EXTEND professional services can handle safety configurations on your network with our trusted industry-best SmartHands offering.
Let’s assume that you want to upload a file to a File Transfer Protocol (FTP) server. For your computer to start sending data, besides knowing the IP address of the FTP server, it must know the MAC address as well. So, how can the device learn the MAC address of the server?
Well, there are two options, either manually or automatically. The manual configuration is a straightforward process, but not scalable when you have many devices in your network. This is because you will have to create a mapping for each device’s MAC and IP address manually.
The ARP protocol is a much better, and scalable, option. It does the mapping automatically for you so network communications can operate flawlessly without any need for an on-demand mapping configuration.
ARP is a very simple Layer 2 protocol. Its main purpose is to learn the MAC address for a specific IP address used by the destination host and to store the mapping of these two addresses in its local ARP table. If this information is available in the ARP table, the device can send data to the same destination host using those IP and MAC addresses.
So, what happens when ARP is doing its job? Let’s look at the example in the above image. PC1 wants to upload a file to the FTP server, but it does not know its MAC address. This is when ARP comes into play. It is a protocol that uses two different types of ARP messages, namely, an ARP request message and an ARP reply message.
First, PC1 sends an ARP request message to the server. Since this is a Layer 2 protocol, the source MAC address is the MAC address of PC1, while the destination MAC is a broadcast. The reason for using a broadcast MAC as a destination is that every device receives that message in the local network but only the server replies.
But how does the server know that it should reply? Inside the ARP request, there is a message containing the IP addresses of the server and the IP address of PC1. So, when the server recognizes its IP address of 192.168.1.100 in the message it replies to the IP address of PC1 with an ARP reply message containing a mapping of its own MAC and IP address.
When PC1 receives the message, it writes that mapping inside its local ARP table and keeps it there for some time, depending on the operating system. If PC1 has that information, it can communicate with the server. However, after some period of inactivity, this mapping will get discarded for the device to spare local resources.
The same process of learning the MAC address of the server will be repeated when PC1 needs to print something, and the MAC address is not available in the ARP table.
Long lead times making deadlines impossible to meet?
Gear at your doorstep in days--not months--and within your budget.
Knowing the MAC address of the destination device is essential for you to send data toward that device in the local network. However, if your device uses a different destination MAC address, the frame will be sent to a different device in the network, instead of the intended one.
You might be wondering, how is it even possible to use a wrong MAC address when ARP is doing the mapping automatically? Well, it is very possible, and it is called an ARP spoofing attack.
Implementing this attack is quite easy and all you have to do is use the right tool. As you already know, for each ARP request message there is an ARP reply, but the ARP spoofing attack uses something else called a gratuitous ARP reply.
Basically, this is a normal ARP reply message sent by a device without any ARP request message previously received. Although these messages look like any other ARP reply messages, they contain incorrect mappings. By spoofing an ARP reply message from a legitimate device with a gratuitous ARP reply, the message contains an IP address of a legitimate device and the MAC address of the host that initiated the attack.
This results in a remapping of the ARP cache in the ARP table of the target device and uses the attacker device as a destination when sending data to the real IP address of the spoofed device or the real destination device.
So, how does this work in practice? As you can see from the image above, PC1 learns the MAC address of the FTP server after the exchange of ARP messages. The attacker sends a gratuitous ARP reply that contains a mapping of the IP address of the server and the MAC address of the attacker’s computer.
Logically, PC1 rewrites the old data in the ARP table with the new one that has just been learned, so next time PC1 needs to upload something to the FTP server, the traffic will go through the attacker. And just like that, we have a man-in-the-middle attack.
You can implement a firewall to ensure your network is protected from even the most harmful attacks. View some of our selection guides below:
The solution to the ARP spoofing attack comes in the form of a feature called Dynamic ARP Inspection (DAI). The DAI feature has the responsibility of inspecting the ARP messages to ensure that only valid ARP requests and responses are exchanged on the switch ports where the danger might come from.
As a result, each intercepted ARP reply message is verified for a valid MAC-to-IP mapping before the message is forwarded. If the message is valid, everything continues normally, otherwise, the ARP reply message is dropped.
For DAI to determine the validity of the ARP reply messages in a network where a DHCP server is deployed, it uses the DHCP snooping database. This database, besides containing MAC-to-IP mappings, also stores other information and is built from another security feature called DHCP snooping.
For more information on DHCP snooping, view our article entitled A Guide to Configuring and Troubleshooting DHCP Snooping.
The validation is not performed on every single port on the switch on which the DAI feature is enabled. When you start DAI, you must define the ports as trusted and untrusted.
The inspection happens only on untrusted ports, and these ports are the ports that connect to end devices. The rest of the ports should be configured as trusted so that all ARP messages are permitted without any inspections performed.
As you can see from the image above, only interfaces FastEthernet0/1 and FastEthernet0/2 are configured as untrusted, while FastEthernet0/3 is configured as trusted since it is an uplink to another switch.
When an attacker, connected on FastEthernet0/2, sends a gratuitous ARP reply, the switch checks the parameters included in the message and compares them against the mappings in the DHCP snooping database. If they are legitimate, the ARP message is forwarded, otherwise, the switch drops the frame.
The configuration of the DAI feature is very simple. All you must do is enable the DHCP snooping and DAI feature. For both, you must define the VLANs for which you want to inspect traffic, and then define the ports as trusted or untrusted. Keep in mind that if ports are not configured as trusted, by default they are enabled as untrusted.
Although you can manually map the MAC addresses to IP addresses for each device to which you want to send data, this approach can very quickly become unmanageable because of the potentially high number of devices in your network.
It can also lead to misconfiguration, so using the ARP protocol is the best option to accomplish the same goal. However, you should secure this protocol by using the DAI feature just to be on the safe side and protect your network from unwanted man-in-the-middle attacks.
If you are having trouble with the ARP protocol or any configuration, send PivIT a request or connect with our Team in real-time using our chat feature. Know how to configure everything already but you're in need of new hardware? Click below to view your options!