Which protocol is used by the ping command to test the connectivity between the devices?

3.4.3 Ping, traceroute and ICMP

Internet Control Message Protocol (ICMP) is used by the network layer to relay information about its status. If an IP packet doesn’t arrive, then ICMP can be used to return the IP packet to its source with an error message. ICMP was one of the possible protocols that could be indicated within the IP header, see the previous section. However, ICMP is commonly sent by a router, and thus it is considered to be at network level as hosts need not be involved. ICMP is unreliable as it provides no reliability.

The ICMP packet format is shown in Figure 3.30. The important fields are the type field and the code field. Together these give information about the status of the network. Type 3 corresponds to Destination Unreachable, and there can be several reasons given by the code. Some examples are:

Codes 0 and 1 might be returned when a route can’t be found, and code 7 when a route leads to a network where the host isn’t known. Code 4 is useful in a few contexts: it indicates that the Do Not Fragment field was set in an IP packet, but the packet can’t be forwarded without fragmenting: the source host can try to adapt to this by sending smaller IP packets.

Some other important types and codes are:

0/0: Echo Reply

8/0: Echo Request

11/0: TTL expired in transit

The Echo Reply and Echo Request packets are used to determine if a host is reachable. A common tool that uses these is the “ping” tool which is available on most operating systems. The following command issued from a machine at UCL computer science:

ping wikipedia.org

generates the response:

PING wikipedia.org (208.80.152.2) 56(84) bytes of data.

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=0 ttl=47 time=116 ms

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=1 ttl=47 time=115 ms

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=2 ttl=47 time=115 ms

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=3 ttl=47 time=114 ms

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=4 ttl=47 time=115 ms

64 bytes from rr.pmtpa.wikimedia.org (208.80.152.2): icmp_seq=5 ttl=47 time=114 ms

--- wikipedia.org ping statistics ---

6 packets transmitted, 6 received, 0% packet loss, time 5042ms

rtt min/avg/max/mdev=114.615/115.197/116.824/0.863 ms, pipe 2

The ping tool sends an ICMP packet with Echo Reply, and calculates the RTT for an Echo Reply to be received. We pressed Control-C to stop the ping after six packets were sent. We can see that the RTT is ∼115 ms on average.

An associated tool is “traceroute” (on Unix) or “tracert” (on Windows). The two tools don’t work exactly the same way, but the basic idea is to send IP packets with increasing TTL values. As we noted in the previous section, routers decrement the TTL on an IP packet when they forward the packet. Packets are sent with an initial TTL, and if this reaches zero, an ICMP packet is returned with the 11/0 type and code. By systematically increasing the TTL we can discover the routers on the path between the source and the destination as each router will be expected to return ICMP packets. In practice, traceroute or tracert may not find the complete route: some routers don’t return ICMP packets, partly in response to certain types of network attacks, such as Denial of Service (DoS). Thus from the same machine, the command

traceroute wikipedia.org

generates the following response (from which we have removed some lines for space reasons):

traceroute to wikipedia.org (208.80.152.2), 30 hops max, 38 byte packets

1 cisco (128.16.6.150) 3.544 ms 0.817 ms 0.649 ms

2 128.40.255.29 (128.40.255.29) 0.323 ms 0.245 ms 0.229 ms

3 128.40.20.1 (128.40.20.1) 0.381 ms 0.283 ms 0.254 ms

4 128.40.20.62 (128.40.20.62) 0.311 ms 0.285 ms 0.276 ms

5 ic-gsr.lmn.net.uk (194.83.102.81) 0.351 ms 0.257 ms 0.256 ms

6 so-1-0-0.lond-sbr1.ja.net (146.97.42.61) 0.529 ms 0.511 ms 0.527 ms

7 so-6-0-0.lond-sbr4.ja.net (146.97.33.154) 0.796 ms 0.812 ms 0.815 ms

8 if-15-0-0.mcore3.LDN-London.as6453.net (195.219.195.85) 0.922 ms 0.848 ms 0.800 ms

9 if-5-0-0.mcore3.L78-London.as6453.net (195.219.195.10) 1.125 ms 1.137 ms 1.118 ms

MPLS Label=513 CoS=0 TTL=1 S=1

10 if-12-0-0-983.core2.NTO-NewYork.as6453.net (216.6.97.37) 88.627 ms 88.717 ms 88.999 ms

MPLS Label=673 CoS=0 TTL=1 S=1

...

18 w006.z207088246.xo.cnc.net (207.88.246.6) 115.472 ms 117.700 ms 114.693 ms

19 * * *

20 * *

Traceroute sends three packets with each TTL, and prints on each line: the hop count, the name of the router or host and its IP address, and then the RTT. After 18 hops, our traceroute stops returning responses. However, we can note some interesting aspects: our local gateway (128.16.6.15) is the first hop, and we configured this in our Internet settings. We can also see how UCL (128.40.*.*) is connected to the London Metropolitan Network (*.lmn.net), to the U.K. academic backbone SuperJANET (*.ja.net), then through a peering service (as6453.net) at hop count 9 to New York at hop count 10. We can also note that the RTT goes up from about 1 ms to 88 ms! By the time we reach hop count 18, the RTT is ∼116 ms on average.

Despite us not being able to traceroute from this host to wikipedia.org, the practical use of traceroute is usually to find misconfigured routes or problematic firewalls. There are many web pages that provide traceroute and ping services so that the reachability can be tested from a variety of sources on the Internet.

14.2.2.2 Validation

1.

Using ping to validate connectivity.

Since ping creates ICMP packets that belong to the nonvideo slice, it can be determined how all hosts are reachable.

Using iperf to validate bandwidth.

From h2 to h3 we generate a video service that is a 10 Mbits/s UDP traffic with destination port 9999. This service should use the video slice.

Log into h2 and h3 in a new terminal:

Start listening to UDP packets at port 9999 on the h3 as reveiver:

Start sending UPD packets with destination port 9999 on the sender h2 to h3:

The results in Figs. 14.5 and 14.6 show that h2 keeps sending video traffic and h3 is able to receive the video traffic with 8.97 Mbits/s bandwidth, which means that the video traffic uses the video slice we created.

Using dump-flows to check flow entry.

On switch s1, a UDP packet comes in the port s1_eth3, and its destination address is 00:00:00:00:00:03 with destination port 9999. This means that this packet should be in the video slice. s1 looks up its flow table, and the corresponding actions are output as s1_eth2. This output port maps the packet to the flow with 10 Mbits/s bandwidth.

In practical scenarios, service slicing is used in a demonstrator of industrial conditional monitoring [274,275].

Pings and Ping Sweeps

A ping is a special type of network packet called an Internet Control Message Protocol (ICMP) packet. Pings work by sending a particular type of network traffic, called an ICMP echo request packet, to a specific interface on a computer or network device. If the device (and the attached network card) that received the ping packet is turned on and not restricted from responding, the receiving machine will respond back to the originating machine with an echo reply packet. Aside from telling us that a host is alive and accepting traffic, pings provide other valuable information including the total time it took for the packet to travel to the target and return. Pings also report traffic loss that can be used to gauge the reliability of a network connection. To run ping from your Linux machine, open a terminal and issue the command:

  ping target_ip

You will need to replace the “target_ip” portion of the command with the actual IP address or hostname of the machine you are trying to ping.

The first line in Figure 3.1 shows the ping command being issued. All modern versions of Linux and Windows include the ping command. The major difference between the Linux and Windows version is that by default, the Windows ping command will send four echo request packets and automatically terminate, whereas the Linux ping command will continue to send echo request commands until you force it to stop. On a Linux system, you can force a ping command to stop sending packets by using the Ctrl + C combination.

Let us focus our attention on the third line that starts with “64 bytes from”. This line is telling us that our ICMP echo request packet successfully reached the target host and that the host successfully sent a reply packet back to our machine. The “64 bytes” indicates the size of the response packet. The “from ord08s05-in-f6.1e100.net (74.125.225.6):” specifies which hostname (and IP address) responded to our google.com ping. The “icmp_seq=” designates the packet order. The “ttl = 128” is the time to live value; this is used to determine the maximum number of hops the packet will take before automatically expiring. “Time = 29.2 ms” is telling you how long the entire trip took for the packets to travel to and from the target. After stopping the ping command, you will be provided with an output of statistics including the number of packets transmitted, packet loss, and a series of time-based stats. If the target host is down (offline) or blocking ICMP packets, you will see 100% packet loss or a “Destination Host Unreachable” message depending on which operating system you are using. Sometimes, in sporadic network connections, you may see multiple request time out and a few with a response. This is typically because of a poor connection to an environment or the receiving system is experience network issues.

Now that you have a basic understanding of how the ping command works, let us see how we leverage this tool as a hacker. Because we know that pings can be useful in determining if a host is alive, we can use the ping tool as a host discovery service. Unfortunately, manually pinging every potential machine on even a small network would be highly inefficient. Fortunately for us, there are several tools that allow us to conduct ping sweeps. A ping sweep is a series of pings that are automatically sent to a range of IP addresses, rather than individually entering each target’s address.

The simplest way to run a ping sweep is with a tool called FPing. FPing is built into Kali and is run from the terminal. The tool can also be downloaded for Windows. The easiest way to run FPing is to open terminal window and type the following command:

  fping –a –g 172.16.45.1 172.16.45.254>hosts.txt

The “–a” switch is used to show only the live hosts in our output. This makes our final report much cleaner and easier to read. The “–g” is used to specify the range of IP addresses we want to sweep. You need to enter both the beginning and the ending IP addresses. In this example, we scanned all the IPs from 172.16.45.1 to 172.16.45.254. The “>” character is used to pipe the output to a file, and the “hosts.txt” is used to specify the name of the file our results will be saved to. To view the hosts.txt file, you can either open it with a text editor or use the “cat” command, which is built into the Linux terminal. The cat command will display the contents of a file in the current terminal window. To view the contents of the hosts.txt, enter the following command into your terminal:

  cat hosts.txt

There are many other switches that can be used to change the functionality of the FPing command. You can view them all by utilizing the man page as shown below:

  man fping

Once you have run the command above, you can open the hosts.txt file that was created to find a list of target machines that responded to our pings. These IP addresses should be added to your target list for later investigation. It is important to remember that not every host will respond to ping requests; some hosts may be firewalled or otherwise blocking ping packets.

ICMP

The most common tool associated with ICMP is called ping. ping utilizes ICMP packets to verify that a given destination network device is reachable from the source device. It does this by sending a message from the source to the destination using the ICMP protocol that includes specific flags to designate the type of ICMP message being sent. If the destination device responds, then it is considered available and the ping utility will typically show how long it took for the destination device to respond and other useful information. A simple example of how this is used is shown in Figure 2.9.

ping is often used when troubleshooting to confirm connectivity to the destination device at the Internet layer, however, there are some valid cases where a ping test will fail but connectivity between the devices is still functional. Based on the original Request for Comments (RFC) that defined ICMP, it was intended that ICMP support be required on all network devices and that the device should respond to all ICMP requests. Due to security concerns however, ICMP is frequently disabled or blocked which prevents ping from being used to check for connectivity to a network device. If ICMP is enabled and nothing is blocking the transmission of ICMP packets, the test should be successful.

ICMP Rate Limiting

ICMP flood is a common flood attack and is often combined with other kinds of flood attacks.

ICMP flood is the most straightforward of the flood protections. A threshold value of total ICMP packets per second to a destination (from all IP addresses) is set, and if that threshold (a default of 1000 p/s) is exceeded in a particular second, the remainder of the ICMP packets for that second, as well as all of the ICMP packets for the next second, are dropped. Furthermore, sessions are not made for dropped packets.

ICMP Flood Protection This controls how many ICMP packets per second per single IP destination are permitted before the firewall begins dropping ICMP packets to that destination. Packets are dropped for the remainder of the second, and all of the next second. No sessions are set up for dropped packets.

A good starting number for ICMP flood protection is 100 packets per second. If you find your routers returning high numbers of ICMP messages, resulting from normal PING health checks, and normal network discovery (ICMP host unreachable, ICMP path MTU discovery), you can adjust your trust security zone with a higher threshold.

Capturing and Saving Data With TCPDump

The following examples show you how to capture and save traffic with TCPDump using various options and filters; the output can then be opened and analyzed with Ethereal.

This example captures all packets in their entirety by using the snaplen=0 option and logs the output to a file called capture_all.

This example captures all Internet Control Message Protocol (ICMP) packets in their entirety and logs the output to a file called icmp_capture. Notice that the icmp parameter has to be escaped with either the “\” or the “\\” because it is also considered a reserved keyword. In the capture filter language, if you use icmp as a value for “proto”, it must be escaped with a slash. If you are typing such a filter on the UNIX command line, the backslash is special for UNIX shells, so the backslash must be escaped with another backslash.

This example captures all packets in their entirety for destination IP 192.168.1.1 going to and from Transmission Control Protocol (TCP) port 21 and logs the output to a file called ftp_capture. When you are using more than one parameter for comparison they need to be enclosed in single or double quotes. This is because the && and ‖ parameters also have meaning in the UNIX shell. If you just type tcpdump -s 0 -w ftp_capture dst host 192.168.1.1 && tcp port 21 the UNIX shell will interpret the && for its own purposes and run only tcpdump -s 0 -w ftp_capture dst host 192.168.1.1. Then if the tcpdump process exits with a zero return value (successful), the UNIX shell will attempt to run tcp port 21, but there is no “tcp” program, so it will fail. Using quotes keeps the UNIX shell from interpreting the && and ‖ for its own purposes.

This example specifies the capture filter via a different type of format. It is using the byte-offset method and compares the byte to a value. This example is capturing all packets in their entirety where the 9th-byte offset is equal to 6 and logging the output to a file called tcp_capture. This means it is capturing all TCP packets, because the 9th-byte offset represents the protocol and 6 is the decimal value for TCP

Now that we have our output saved to capture files, all we need to do is open it with Ethereal. Once you have opened Ethereal, select File | Open. Browse to the location of the capture file and select it, then click OK. Ethereal will open it and automatically read it! Figure 7.5 shows the Ethereal output of the TCPDump tcp_capture file. This is a port scanning attempt; notice the scanner is using a static source port of 58173.

Fingerprinting

The goal of system fingerprinting is to determine the operating system type and version. There are two common methods of performing system fingerprinting: active scanning and passive scanning. The most common active methods use the responses that a system sends to specific TCP or ICMP packets. The TCP fingerprinting process involves setting flags in the header that different operating systems and versions respond to differently. Usually several different TCP packets are sent and the responses are compared to known baselines (or fingerprints) to determine the remote OS. Typically, ICMP-based methods use fewer packets than TCP-based methods, so in an environment where you need to be stealthier and can afford a less specific fingerprint, ICMP may be the way to go. You can achieve higher degrees of accuracy by combining TCP and ICMP methods assuming that no device in between you and the target is reshaping packets and mismatching the signatures.

For the ultimate in stealthy detection, you can use passive fingerprinting. Unlike the active method, this style of fingerprinting does not send any packets but instead relies on sniffing techniques to analyze the information sent in normal network traffic. If your target is running publicly available services, passive fingerprinting may be a good way to start off your fingerprinting. Drawbacks of passive fingerprinting are that it is usually less accurate than a targeted active fingerprinting session and it relies on an existing traffic stream to which you have access. It can also take much longer depending on how high the activity level of the target system is.

Firewall tools

In our kit of network tools, we may also find it useful to include those that can map the topology of and help locate vulnerabilities in our firewalls. Hping3 is a well-known and useful tool for such efforts. It is able to construct specially crafted Internet Control Message Protocol (ICMP) packets in such a way as to evade some of the normal measures that are put in place to prevent us from seeing the devices that are behind a firewall. We can also script the activities of Hping3 in order to test the responses of firewalls and IDSes, so that we can get an idea of the rules on which they are operating.

We can also use a variety of the other tools we have discussed in this section to test the security of our firewalls. We can use port and vulnerability scanners to look at them from the outside in order to find any ports that are unexpectedly open, or any services running on our open ports that are vulnerable to known attacks. We can also use sniffers to examine the traffic that is entering and leaving firewalls, presuming that we can get such a tool in place in a network location that will enable us to see the traffic.

TCP/IP Related Protocols

TCP/IP is a collection of protocols. Some of the more common protocols:

ARP

DNS

ICMP

IP

RARP

SMTP

TCP

UDP

Server Firewalls

In addition to the network firewalls described within this chapter, the firewall on the Windows Operating System should also be enabled and configured to allow just the needed network connections. Depending on the version of the Windows Operating System that is installed the default state of the firewall will depend. On Windows Server 2003 the firewall is in a state which allows all network traffic to be passed from the server to the network and from the network to the server. On Windows Server 2008 and higher the firewall is configured by default to allow almost no data to be transferred from the computer to the network or from the network to the computer. By installing and configuring the Windows firewall to block all unexpected network connections, if any unauthorized software is installed on the server that software would not be able to be contacted. Ideally, any outbound network connections that are not expected should also be blocked so that any software installed cannot phone home. While legitimate software phoning home is not necessarily a problem, unauthorized software should not be allowed to phone home as it may be passing confidential data to the controller or the server may be part of a bot-net.

FAQ