The network tool ‘ping’ has been used by almost everyone who regularly uses a PC at one point or another. The tool is so ubiquitous that it is installed by default on every modern networkable operating system and has been for some time. It is both simple to use and can be a powerful means of exploring your network locally and the internet at large. We are going to go over some use cases and explain exactly what it is and how it works.
Ping has some limitations. One of the primary limitations is that it is, at it’s heart, an ICMP Echo based tool. What does that mean? Well, ICMP stands for Internet Control Message Protocol. This differs significantly from TCP or UDP since it is not typically used to transmit data directly. It is used for diagnostic, control or error reporting and are processed both by the sender and receiver as a special case, outside of normal IP processing. This has several reasons, performance and security. It makes these packets easier to manage and filter and harder to use to compromise the security and integrity of the systems involved in the transaction (with one notable exception covered below). As a result, ping results can be inconsistent – meaning that sometimes it works and sometimes it does not. A common security filter on internet facing systems is to ‘drop’ ICMP based requests (like ping), so it will look like the site or system is not responding at all on the other end of the request.
What Can We Do With It?
Since ping is installed almost everywhere (notwithstanding whether the firewalls between the client request and server response), you can use it a number of ways to find out various things about network end points. As an example, an easy way to use ping to determine if your local system’s IP stack is functioning correctly, execute the following at a command prompt:
Which will return the following:
PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.040 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.049 ms
— 0 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3540ms
rtt min/avg/max/mdev = 0.037/0.041/0.049/0.004 ms
This tells us that the local system (localhost defined as IP 127.0.0.1) is responding to these requests and in a very fast manner (time=0.037 ms). Let’s expand on this and try a simple ping of a known internet host that allows basic ICMP traffic:
You will see the following response (or something like it since the returned name/IP could be different depending on your location):
PING google.com (188.8.131.52) 56(84) bytes of data.
64 bytes from dfw06s27-in-f8.1e100.net (184.108.40.206): icmp_seq=1 ttl=55 time=12.7 ms
64 bytes from dfw06s27-in-f8.1e100.net (220.127.116.11): icmp_seq=2 ttl=55 time=14.2 ms
64 bytes from dfw06s27-in-f8.1e100.net (18.104.22.168): icmp_seq=3 ttl=55 time=13.6 ms
64 bytes from dfw06s27-in-f8.1e100.net (22.214.171.124): icmp_seq=4 ttl=55 time=10.8 ms
— google.com ping statistics —
5 packets transmitted, 4 received, 20% packet loss, time 4353ms
rtt min/avg/max/mdev = 10.837/12.891/14.286/1.302 ms
We can see that Google responds with a geographically defined server (meaning where you are determines which server responds to the request) at the above IP address. What else can we do here? Let’s try the following:
ping -c 5 -q google.com
To receive the following information:
PING google.com (126.96.36.199) 56(84) bytes of data.
— google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4019ms
rtt min/avg/max/mdev = 11.849/12.938/13.319/0.559 ms
Here we are using ping to reach out to ‘google.com’, sending exactly five requests (-c 5) and showing only the summary of the action (-q). This can be useful to run in a cron job and/or piped to a file and used for network performance comparisons to a known end point.
So How Do We Get In Trouble?
There is one way of using ping that is typically considered malicious in nature when abused on public networks. It is often called a DoS (Denial of Service) attack and is referred to as a ‘ping flood’. It simply means that you are sending out so many ping requests that it is possible to overload the network interface of the receiving host and make it unable to process legitimate IP traffic. An example of a simple ping flood is:
sudo ping -f localhost
Sudo is used here since the a flood is overriding the typical frequency that an ICMP request is sent out to the end point. A flood will send out as many requests as the system and interface can handle. In this case, after running for exactly two seconds, here is the summary information received back from the above command:
PING localhost (127.0.0.1) 56(84) bytes of data.
— localhost ping statistics —
318900 packets transmitted, 318900 received, 0% packet loss, time 3691ms
rtt min/avg/max/mdev = 0.003/0.004/1.343/0.008 ms, ipg/ewma 0.011/0.005 ms
As you can see, we sent out more than a quarter million requests in two seconds. I restricted this to localhost to avoid being flagged by my ISP for generating a DoS level event (so be careful you only experiment locally or on networks you control).
We have touched on just a few examples of how we can use ping and discussed some of its strengths and limitations. I encourage you to explore the tool more fully and, if you are so inclined, it is covered in depth at our sister site Linux Academy as part of the Linux Certification Exam preparation for networking. Hit me up in the comments for creative uses of ping and maybe you will make our next video!