ICMP and ARP are two of the fundamental protocols used on our networks. In this video, you’ll learn about the “ping of death,” troubleshooting problems with an unreachable default gateway, and using ARP to troubleshoot issues.
<< Previous: Troubleshooting Denial of ServiceNext: Troubleshooting Malicious User Activities >>
A very interesting ICMP vulnerability was called “the ping of death.” Normally an ICMP request is very small, 64 bytes in size. It is sent to another device which then echoes that information back to you as an ICMP response. It’s a very small amount of data and it’s a very efficient way of checking to see if another device is responding across the network.
With a ping of death, you could send a ping to another device and make the total size of that ping 65,536 bytes. And if you’d set this ping to a vulnerable operating system, it would completely crash the computer. This happened on a number of different operating systems, Windows 95, Mac OS7, Linux and Unix versions. And we were able to send simply a ping across the network and completely disrupt many different kinds of machines.
This was a bug that was in the fragmentation reassembly process during this very large ping, and many operating systems were updated very quickly so that this ping of death became something that was really a historical footnote.
When you’re on your local subnet, you should always be able to access your default gateway. And if you are not able to access the default gateway then you’re not going to be able to communicate to any devices outside of your local subnet. This device should always be available and you should always know what the IP address is of your default gateway.
One way to troubleshoot this process is to simply ping the IP address that you know to be the default gateway. If you get some response, then at least you’re communicating to other devices on the subnet. Even if there’s a problem with the routing functionality of the gateway, you at least know that you’re able to communicate outside of your own device. If you’re not getting a response from the default gateway, then you need to check and make sure you do have the correct IP information and that you’re trying to access the right device.
If you want to confirm that your default gateway is routing properly, then it’s useful to know the outside IP address of that gateway, and then you can ping the outside address as well. If you are able to ping the outside address, then everything should be working properly for that particular gateway. You’re able to communicate to the inside interface, it is routing properly to the other side, and you’re receiving a response from the outside IP address.
Even if a device is not responding to a ping, you may still be communicating to that device, I it just may be configured not to respond to your request. And in that case we can look at our ARP table and see if that device is communicating on the network. An ARP is not going to pass through routers, so you’re only going to be able to perform ARP queries of devices on your local subnet.
To look at the cache of what you have in your ARP table, you can run an arp-a, and this will list out, just as we are doing in this diagram, a listing of IP addresses, the Mac addresses associated with those IP addresses, and whether they were defined statically– perhaps on our individual device– or if you were able to identify them dynamically across the network.
Once you have this table of IP addresses and their corresponding Mac addresses, you can now start examining those and see if these two things are matching up properly. If you happen to find an IP address that has a different Mac address than what you were expecting, then there may be a man in the middle attack. You need to confirm and make sure that you know exactly where this traffic is coming from.