SecurActive Performance Vision's blog

ICMP, network administration & security monitoring

What is ICMP?

ICMP stands for Internet Control Message Protocol and is also a common IP transport protocol. It seems pretty explicit, although most people reduce ICMP to ping reply commands, a good way to test whether a host can be reached through a network and how much it takes for a packet to make a round trip through the network…
Obviously ping and trace-route-like tools are very useful for network administrators… but there is much more to say about ICMP and the help it can provide for network administration & diagnosis.
In total, ICMP can be used to send more than twenty types of control messages. Some are just messages, some others are a way for IP devices or routers to indicate the occurrence of an error. You can get a full list of existing ICMP messages on http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

How does ICMP work?

Ping

Ping is the simplest command using ICMP messages (echo request); it sends towards a network address an echo request packet (or DNS name, which will be resolved into an IP address). The destination can then send back an echo reply packet. The request sender will then be able to know whether the destination is reachable through ICMP or not and get an evaluation of the time required for the ICMP message to make the round trip to the destination. Ping is frequently used to test the availability of a host and to evaluate the network response time. The time-to-live indicated corresponds to the original TTL of the sender minus the number of hops that was necessary to reach the destination. For instance, hereunder the original TTL is 64 (see sniffer screenshot), which means that the ICMP message went through 10 routers (64-54) to reach www.google.com.

xxx@xxx:~$ ping www.google.com PING www.l.google.com (209.85.227.103) 56(84) bytes of data.
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=1 ttl=54 time=12.9 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=2 ttl=54 time=12.5 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=3 ttl=54 time=11.9 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=4 ttl=54 time=12.4 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=5 ttl=54 time=12.4 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=6 ttl=54 time=13.1 ms
64 bytes from wy-in-f103.google.com (209.85.227.103): icmp_seq=7 ttl=54 time=12.4 ms

Traceroute

A traceroute is a command (it can traceroute or tracert according to the system which is used) that sends a sequence of ICMP packets with a TTL value which is incremented by one each time. This means that the first packet (TTL = 1) will reach the first router, which will send back an ICMP packet, and the second one (TTL = 2) will reach the second router, which …. and so on. The result will be the list of routers or hops to reach the destination with a response time for each:

traceroute to www.google.fr (209.85.227.99), 30 hops max, 40 byte packets
1 fw1.prod.securactive.lan (192.168.xxx.xxx) 0.234 ms 0.430 ms 0.421 ms
2 82.227.168.254 (82.227.168.254) 6.147 ms 7.136 ms 8.125 ms
3 * * *
4 bzn-crs16-1-be1010.intf.routers.proxad.net (212.27.50.170) 11.576 ms 12.066 ms 13.054 ms
5 cbv-6k-1-po20.intf.routers.proxad.net (212.27.50.190) 14.044 ms * *
6 74.125.50.117 (74.125.50.117) 16.506 ms 15.625 ms 16.514 ms
7 209.85.250.142 (209.85.250.142) 56.473 ms 50.894 ms 50.417 ms
8 209.85.243.111 (209.85.243.111) 21.928 ms 216.239.43.233 (216.239.43.233) 14.945 ms 209.85.243.111 (209.85.243.111) 19.445 ms
9 216.239.49.45 (216.239.49.45) 15.953 ms 14.959 ms 209.85.252.83 (209.85.252.83) 12.945 ms
10 209.85.243.93 (209.85.243.93) 25.932 ms 209.85.243.97 (209.85.243.97) 13.450 ms 209.85.243.89 (209.85.243.89) 16.446 ms
11 wy-in-f99.google.com (209.85.227.99) 14.940 ms 13.429 ms 15.455 ms

Traceroute can help you understand what the route to a certain destination is and eventually where the response time or packet loss can take place.

Error messages

Let’s describe the most typical ICMP error messages you can find on networks.

ICMP Network Unreachable

Context

Let’s take the simplest example: one machine sitting on a LAN (192.168.0.7), has one default gateway (192.168.0.254), which is the router. It is trying to reach a server, which does not sit on the LAN (10.1.0.250) and which cannot be reached, because 192.168.0.254 does not know how to route this traffic.

xxxxx:~$ ifconfig eth0
Link encap:Ethernet  HWaddr 00:21:70:ba:52:ab inet adr:192.168.0.7
Bcast:192.168.0.255  Masque:255.255.255.0 adr inet6: fe80::221:70ff:feba:52ab/64 Scope:Lien
…
traceroute to www.google.com (209.85.229.106), 30 hops max, 60 byte packets
1  192.168.0.254 (192.168.0.254)  1.435 ms  1.717 ms  2.031 ms
2  88.189.126.254 (88.189.126.254)  28.478 ms  39.345 ms  39.342 ms
3  * * *
…..
11  ww-in-f106.google.com (209.85.229.106)  79.061 ms  68.128 ms  79.744 ms

PING 10.1.0.250 (10.1.0.250) 56(84) bytes of data. —
10.1.0.250 ping statistics —
47 packets transmitted, 0 received, 100% packet loss, time 46327ms

Step 1:

Step 1: Network unreachable

Step 2:

Step 2: Network unreachable

Step 3:

ICMP step 3 Network unreachable

ICMP Host Unreachable

Context

Let’s take the simplest example: one machine sitting on a LAN (10.1.2.23), has one default gateway (10.1.2.254/24), which is the router. It is trying to reach a server, which does not sit on the LAN (192.168.1.15). The traffic flows and reaches the last router before the server (192.168.1.254/24; this router cannot reach 192.168.1.15 (because it is unplugged, down or it does not exist).

Step 1:

Step 1: Host unreachable

Step 2:

Step 2: Host unreachable

Step 3:

Step 3: Host unreachable

ICMP Port Unreachable

Let’s take a second example: one machine sitting on a LAN (192.168.0.7). It is trying to reach a server 192.168.0.254, which sits on the LAN on port UDP 4000, on which the server does not respond.

Step 1:

Step 1: ICMP Port unreachable

Step 2:

Step 2: Port unreachable

All the information you can find in an ICMP error message!

ICMP Network capture

Provided you are used to analying traffic with a sniffer, this looks quite explicit: in the ICMP part of the payload of an ICMP error packet, you can find all the information required to understand which flow triggered the error. Of course, you can read the type and code of the ICMP error, but you can also find the IP source and destination of the error, as well as protocol, source & destination ports.

Where is the challenge with ICMP?

You may be tempted to say: if it is that simple, why do we need on top of any sniffer? All the information sits in the payload…
But in every network, you will find some ICMP errors… they may be due to a user trying to connect to a bad destination, or trying to reach a server on the wrong port… The key is in having a global view of how many errors you have normally and currently and from where to where. The key to leveraging ICMP information is in having a relevant view of it and understanding what it means.

How can ICMP help on network diagnostic and security monitoring?

From the explanation here above, we can keep in mind that by analysing ICMP errors we can be identify machines that try to connect networks or machines, that are routable from the LAN’s machine or ones that try to connect on actual servers but for services whose ports are not open.
Here are some examples of phenomena that can be identified that way:

Misconfigured workstation

A workstation repeats a large volume of missed attempts to connect to a limited number of servers: it may be that this machine does not belong to the company’s workstations (external consultant on the network, whose laptop is trying to reach common resources on his home network -DNS, printers,…), or it may be the machine of someone coming from a remote site with its own configuration or a machine that has been simply wrongly configured.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers to this machine or this group of machines. The ICMP information contained in the payload of each of these errors would probably show they are trying to reach a certain number of hosts for some services or applications.

Migration legacy

A certain number of machines keep requesting DNS resolution to a DNS server which has been migrated (this could be true for any application available on the network). Their users certainly feel worse performance when trying to use these services.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers to a group of machines. The ICMP information contained in the payload of each of these errors would probably show they are all trying to reach the previous IP address of a given server.

Network device misconfiguration

A router does not have a route configured; some machines are trying to reach some resources, unsuccessfully.

How would we see it?

A large number of ICMP Network Unreachable errors coming from one router to many machines. The ICMP information contained in the payload of each of these errors would probably show they are all trying to reach the same network through the same router.

Port scanning

A machine is trying to complete a network discovery. It is trying to connect to all servers around to see on which ports they are open.

How would we see it?

A large number of ICMP Port Unreachable errors coming from one or several routers corresponding to a single machine (the one which is scanning).

Spyware / Worms

An infected machine is trying to propagate its spyware, virus or worm throughout the network; obviously it has no previous knowledge of the network architecture.

How would we see it?

A large number of ICMP Host Unreachable errors coming from one or several routers corresponding to a limited number of hosts, trying to reach a large volume of non existing machines on a limited set of ports.

How you could see that in SecurActive NSS in less than 30 seconds!