host is unreachable, for example, the destination host can obviously not respond. In this instance, the router might reply instead.
Although a router might try to be helpful by informing the sending host of a problem, it also is providing information that could be used for reconnaissance purposes. The sender then could glean some knowledge about the type of activity that the router reports. A good security practice is to silence a router by preventing it from issuing ICMP unreachable messages to preclude the dissemination of unnecessary information. This will be discussed in more detail in
the section, "Host Unreachable."
Summary of ICMP Theory
Let's quickly summarize what you've learned in this short section on ICMP theory. You have learned that ICMP is a means of delivering error messages between hosts. It is encapsulated in an IP header, but is considered part of the IP or Internet layer.
ICMP is a unique protocol because it doesn't use ports to communicate like the transport protocols do. ICMP messages can get lost and not be delivered. In addition, ICMP can be broadcast to many hosts because there is no sense of an exclusive connection.
Finally, hosts and routers are the senders of ICMP messages. Hosts listen for ICMP, and most will respond unless they deliberately have been altered for silence.
Mapping Techniques
Mapping a target network is a very strategic part of most intelligently planned attacks. This initial step in reconnaissance attempts to discover the live hosts in a target network. An attacker then can direct a more focused scan or exploit toward live hosts only.
If mapping is not done and a malicious user or program attacks a network, the attack can become very noisy by generating a lot of traffic on the target network and not be very productive. The latter quarter of 1999 saw an example of this kind of bull-in-a-china shop reckless scan. A Trojan named RingZero that infected Windows hosts appeared to scan foreign hosts for open Web proxy ports. One of the shortcomings of the RingZero scanning activity was that it appeared to scan random hosts on many networks. In doing so, many IP addresses that were not active were scanned along with the active ones. This was a noisy scan for intrusion-detection systems that saw it. Also, a lot of work had to be done to receive any valuable feedback about hosts that supported open Web proxy ports. This would have been a more directed and perhaps more informative scan if the IP numbers that were scanned had been live hosts.
The Ubiquitous RingZero Trojan
The observed RingZero attack in a monitored network involved many different source IPs scanning mostly inactive TCP ports: 3128 (squid proxy server), 80 (normal HTTP port), and 8080 (an alternative HTTP port). About half a dozen of these scans were detected on a Class B subnet every hour. Many other sites all over the world that were capable of detecting this activity reported seeing it, too.
An initial theory was that all this activity was coming from spoofed source IPs with an unknown intent. However, Ron Marcum, a system administrator at Vanderbilt University, discovered a Windows host in his network that was doing this kind of scanning and captured the software called RingZero. At the System Administration, Networking, and Security (SANS) conference in October 1999, the RingZero software was dissected.
When activated in a test network, the host on which it was installed began to scan random hosts for the Web proxy ports. If open Web proxy server ports were discovered, they were sent back to an ftp site that aggregated this information for the collector. It is assumed that the collector then planned to use this knowledge for some future plundering. To date, we still see RingZero scanning activity and it is still unknown what the infection method is and how an infected host selects the IP numbers to scan for proxy ports.
One of the most common methods of mapping is to issue ICMP echo requests. A host (or hosts) responds to an ICMP echo request with an ICMP echo reply to signal it is a live host. This is what the ping command does; it issues an ICMP echo request and waits for an ICMP echo reply. Many security and network administrators have responded to this invasive ICMP scrutiny with the knee-jerk reaction of blocking ICMP echo requests. This is a good and necessary reaction, but this is only a partial solution because it is only a minor impediment to the insistent pursuer. Blocking ICMP echo requests has motivated hackers to invent other scanning methods using other protocols.
In Chapter 2, the section, "An ACK Scan," showed how TCP scans can use the ACK flag to attempt to identify live hosts. This can be used as an alternative network scanning method that blocks ICMP echo requests. The next sections look at some of the conventional and esoteric mapping techniques used.
Tireless Mapper
The following scan shows the classic mapping technique of sending individual ICMP echo requests to all hosts in a given subnet. In this case, the 192.168.117 Class C subnet is
scanned for all live hosts. As you can see, this is a very noisy scan:
00:05:58.560000 scanner.net > 192.168.117.233: icmp: echo request 00:06:01.880000 scanner.net > 192.168.117.139: icmp: echo request 00:12:45.830000 scanner.net > 192.168.117.63: icmp: echo request 00:15:36.210000 scanner.net > 192.168.117.242: icmp: echo request 00:15:58.600000 scanner.net > 192.168.117.129: icmp: echo request 00:18:51.650000 scanner.net > 192.168.117.98: icmp: echo request
00:20:42.750000 scanner.net > 192.168.117.177: icmp: echo request 00:26:36.680000 scanner.net > 192.168.117.218: icmp: echo request 00:27:30.620000 scanner.net > 192.168.117.168: icmp: echo request
If a site doesn't specifically look for ICMP activity, however, this might go unnoticed. So, the age-old philosophical question becomes, if a hacker maps your entire network and no one is listening, does it make any noise? Alarming on individual ICMP echo requests likely would generate a lot of alerts from an IDS, so IDSs usually do not issue alerts for individual ICMP echo requests. Yet, an IDS that examines more generic scan activity that exhibits a one-to- many source-to-destination IP relationship would correctly trigger on such a scan. In other words, if the IDS looks for one source IP connecting to many different destination IPs in a given time period—for instance, seven connections per hour—it would discover the preceding scan.
Efficient Mapper
Most likely, the preceding scan was automated so that it wasn't a labor-intensive effort for the not-so-wily scanner. But why bother with all the volume if ICMP is a protocol that can be sent to a broadcast address and can ping many hosts with a couple of commands? That is what the following scanner attempts:
13:51:16.210000 scanner.net > 192.168.65.255: icmp: echo request 13:51:17.300000 scanner.net > 192.168.65.0: icmp: echo request 13:51:18.200000 scanner.net > 192.168.66.255: icmp: echo request 13:51:18.310000 scanner.net > 192.168.66.0: icmp: echo request 13:51:19.210000 scanner.net > 192.168.67.255: icmp: echo request 13:53:09.110000 scanner.net > 192.168.67.0: icmp: echo request 13:53:09.940000 scanner.net > 192.168.68.255: icmp: echo request 13:53:10.110000 scanner.net > 192.168.68.0: icmp: echo request 13:53:10.960000 scanner.net > 192.168.69.255: icmp: echo request 13:53:10.980000 scanner.net > 192.168.69.0: icmp: echo request
It appears that the scanner is attempting to map the 192.168 subnet. The third octet in the IP number changes from 65 to 69 in this excerpt from a larger scan. You can see the final octet fluctuate between 0 and 255. The 255 in the final octet is the classic broadcast address. The 0 in the final octet is a broadcast address for hosts that have a TCP/IP stack based on the UNIX Berkeley Software Distribution (BSD) operating system. Using both these broadcast addresses, all live hosts in an accessible network should respond.
This should convince you to deny into your network any activity destined for these broadcast addresses. I don't know of any legitimate activity for traffic destined for broadcast addresses except for diagnostic activity. The section, "Smurf Attack," shows that disallowing this activity prevents Smurf amplification by your network.
Clever Mapper
In examining the next scan, you can see a new variation on an old mapping scheme:
06:34:31.150000 scanner.net > 192.168.21.0: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.63: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.64: icmp: echo request
06:34:31.150000 scanner.net > 192.168.21.127: icmp: echo request 06:34:31.160000 scanner.net > 192.168.21.128: icmp: echo request 06:34:31.160000 scanner.net > 192.168.21.191: icmp: echo request 06:34:31.160000 scanner.net > 192.168.21.192: icmp: echo request 06:34:31.160000 scanner.net > 192.168.21.255: icmp: echo request
Look at the scanning pattern. You can see that ICMP echo requests are being sent to the Class C subnet of 192.168.21. Now look at the final octet of the IP address. You can see that the first request is sent to the 0 broadcast address, and the last one is sent to the 255 broadcast address. This isn't new; you saw this in the preceding scan.
Notice in the final octet of the other IP numbers, however, that they seem to span 64 IP numbers. For instance, the first IP number has a final octet of 0, and the following one has a final octet of 63. That is 64 total IP addresses. What is the significance of 64? Well, a typical Class C subnet has 256 addresses between the 0 and 255 range.
It is possible to subdivide a Class C network so that you have multiple smaller networks by assigning an appropriate subnet mask. One way to do this is to have four individually addressable subnets with 64 hosts each. In this scheme, the network and broadcast addresses change accordingly. The network and broadcast addresses for those four subnets are the IP numbers that you see in the scan. So, it turns out that the scanner believes that this scanned network might have a different addressing scheme than the Class C "natural" division. If this were truly the addressing scheme for the 192.168.21 subnet, all live hosts might respond. Even if the subnet is a standard Class C and the activity is not blocked, this will still ping all hosts on the network because it uses the .0 and .255 broadcast addresses. If you need a refresher about address classes, reference the "Logical Addresses, IP Addresses" section in Chapter 1.
Cerebral Mapper
One final scan shows a different mapping technique using another ICMP request type. The ICMP address mask request queries a host for the subnet mask of the network on which it resides. Remember all the trouble that the preceding scanner went through to try to determine the addressing scheme? That could have been avoided entirely by using the following ICMP address mask request:
20:39:38.120000 scanner.edu > router.com: icmp: address mask request (DF) 20:39:38:170000 router.com > scanner.edu: icmp: address mask is 0xffffff00 (DF)
20:39:39.090000 scanner.edu > router2.com: icmp: address mask request (DF) 20:39:39:230000 router2.com > scanner.edu: icmp: address mask is 0xffffff00 (DF)
20:39:40.090000 scanner.edu > routerx.com: icmp: address mask request (DF) 20:39:40:510000 routerx.com > scanner.edu: icmp: address mask is 0xffffff00 (DF)
This is not a classic mapping technique per se, but it can provide some initial reconnaissance. The quest here is to examine the subnet mask of different routers. Typically, only routers respond to address mask requests so the scanner might discover additional reconnaissance of the repliers. As discussed in Chapter 1, the subnet mask assigned to a computer system tells it how many bits in its IP address designate the network and how many designate the host.