لطفا منتظر باشید ...
Chapters 2 and 3.Van Jacobson originally documented the IP expiry technique in 1988 and used it to trace the path that IP packets traversed going to a particular destination host. The technique works by sending arbitrary Layer 4 packets to a destination host with an IP TTL of 1 and then monotonically incrementing the TTL field after each response. The IP TTL field limits the lifetime of packets transmitted across the Internet and is decremented by each forwarding device (router). If the TTL field reaches zero before the destination host is reached, the router drops the offending packet and transmits an ICMP TTL exceeded in transit error message to the original host, informing the operating system of the packet's timeout. This action enables the original host to know at which router the packet expired. By starting the TTL field at 1 and successively incrementing the value with each transmission, routers between two given hosts can be enumerated (provided that there is not any prohibitive filtering or any severe packet loss). When the packet reaches its destination host, the host should return a final packet (termed a terminal packet) to the original host, letting it know that the scan has ended. A four-router hop sample execution of the IP expiry technique appears in Figure 9.6.
Figure 9.6: IP expiry.
Initially, the first IP datagram is sent with a TTL of 1. Upon receiving the datagram, the first hop router 10.0.0.1 figures out that the packet is not destined for itself and decrements the TTL field in eager anticipation to forward the packet to the next router. Because this situation would result in a TTL of 0, however, the router cannot forward the datagram and instead drops it and sends an ICMP TTL expired in transit message to 10.0.0.20, reporting the error condition. The next datagram is sent with a TTL of 2, which again reaches the 10.0.01 router (with its TTL decremented). But this time, the packet makes it to the 10.0.1.1 router before the TTL reaches 0. The 10.0.1.1 router then drops the packet and sends the ICMP error message. This process continues until the IP datagram reaches 10.0.3.20 (with a TTL of 5—the destination host). Depending on what Layer 4 protocol was employed, the terminal packet will vary as described in the next section.
Protocol-Specific Terminal Packet Semantics
Like port scanning, the IP expiry technique requires the user to choose a Layer 4 protocol with which to scan. The choice of Layer 4 protocol affects the terminal packet and might also affect the mechanics of the scan if intermediate routers filter based on Layer 4 information (read more about this subject as follows). You should choose the Layer 4 protocol based on the general assumptions of network topology and to a lesser extent the situation of the destination host. For example, if the destination host sits behind a restrictive firewall, UDP packets to arbitrary ports might be filtered out.
UDP
The original implementation of Traceroute uses UDP packets to a presumably unused high-numbered port. Assuming that this port is unused on the destination host, the terminal packet is an ICMP port-unreachable message. If the port happens to be open, the response is undefined but generally no terminal packet is sent. This behavior is the same as we saw in the section on UDP port scanning.
ICMP
Many Windows-based implementations of Traceroute use ICMP ECHO packets as their Layer 4 protocol. The ICMP ECHO protocol is a simple one to use in this case because it has a universally defined terminal response packet when the destination host is reached: an ICMP ECHO reply. The following code excerpt shows how to perform an ICMP ECHO-based IP expiry scan.First, we declare our small army of local variables and kick things off by initializing libnet and libpcap. We will use libnet's raw socket interface, a 60-byte snapshot length, and a 500 ms timeout for libpcap:
pcap_t *p;
libnet_t *1;
time_t start;
u_char *packet;
int c, ttl, done;
char *device= "fxp0";
struct pcap_pkthdr ph;
libnet_ptag_t icmp, ip;
u_long src_ip= 0x1400000a; /* 10.0.0.20 in network byte order */
u_long dst_ip= 0xl403000a; /* 10.0.3.20 in network byte order */
struct libnet_icmpv4_hdr *icmp_h;
struct libnet_ipv4_hdr *ip_h, *oip_h;
char errbuf[LIBNET_ERRBUF_SIZE];
1= libnet_init (LIBNET_RAW4, NULL, errbuf);
if (1 == NULL)
{
/* error */
}
p= pcap_open_live(device, 60, 0, 500, errbuf);
if (p == NULL)
{
/* error */
}
Here, we initialize our scan. We will send one ICMP packet per iteration through the loop, and our condition for termination is when we have hit our destination and get a terminal packet or 30 router hops, whichever comes first:
for (done = icmp = ip = 0, ttl = 1; ttl < 31 && ! xdone; ttl++)
{
The ICMP ECHO header is built first, with our special ID number and a sequence number that increases with the IP TTL:
icmp = libnet_build_icmpv4_echo(
ICMP_ECHO, /* type */
0, /* code */
0, /* checksum */
242, /* id */
ttl, /* sequence */
NULL, /* payload */ 0,
0, /* payload size */
1, /* libnet context */
icmp); /* libnet id */
if (icmp == -1)
{
/* error */
}
Next, we build the IPv4 header. Note that the TTL value starts at one and bumps up by one every time through the loop. Also note the special IP_ID value, because we will refer back to this value later. This code causes our packets to spiral outward from the scanning host, expiring one hop at a time:
ip= libnet_build_ipv4(
LIBNET_IPV4_H + LIBNET_ICMPV4_ECHO_H, /* length */
0, /* TOS */
242, /* TF ID */
0, /* IP Frag */
ttl, /* TTL */
IPPROTO_ICMP, /* protocol */
0, /* checksum */
src_ip, /* src ip */
dst_ip, /* dst ip */
NULL, /* payload */
0, /* payload size */
1, /* libnet context */
ip); /* libnet id */
if (ip == -1)
{
/* error */
}
The completed ICMP packet is written out:
c= libnet_write(l);
if (c == -1)
{
/* error */
}
fprintf(stderr, "Hop %02d: ", ttl);
Next, we descend into our reading loop where we wait for a response. If we do not get anything interesting inside our two-second timeout, we forget about this hop and return to the top of the loop and send the next packet (unless we are at 30 hops):
/* read loop */
for (start= time(NULL); (time(NULL) - start) < 2; )
{
Peel a packet from libpcap and cast an IPv4 header past the link layer header (which we assume to be Ethernet for simplicity). This casting enables us to dereference all of the header fields with ease:
packet= (u_char *)pcap_next(p, &ph);
if (packet == NULL)
{
continue;
}
/* assume ethernet here for simplicity */
ip_h= (struct libnet_ipv4_hdr *)(packet + 14);
First things first: We only want ICMP packets. If this packet is not ICMP, we do not want it:
if (ip_h->ip_p == IPPROTO_ICMP)
{
As earlier, cast an ICMP header pointer over the ICMP portion of the packet:
icmp_h= (struct libnet_icmpv4_hdr *)(packet + 34);
Check the ICMP type and code to see whether this message is a TTL expired-in-transit message:
/* expired in transit */
if (icmp_h->icmp_type == ICMP_TIMXCEED &&
icmp_h->icmp_code == ICMP_TIMXCEED_INTRANS)
{
Cast another IP header into the ICMP packet's payload to verify whether or not this TTL that expired in transit is from our previously sent ICMP packet.We can perform this task because ICMP includes the IP header (and the first eight bytes of payload) in every error message that it sends. Armed with this knowledge, we check the IP_ID of the packet that caused the ICMP error message against our value of 242. If the IP_ID matches, we assume that it is ours. While it is possible for another application to have caused an error with the same IP_ID, it is relatively unlikely:
oip_h= (struct libnet_ipv4_hdr *) (packet + 42);
if (oip_h->ip_id == htons(242))
{
fprintf(stderr, "%s n",
libnet_addr2name4(ip_h->ip_src.s_addr, 0));
break;
}
}
Check to see whether this message is an ICMP ECHO reply message. If it is, check to see whether it is a response to our ICMP ECHO packet. If it is, this packet is our terminal packet and we are done with the scan:
/* terminal response */
if (icmp_h->icmp_type == ICMP_ECHOREPLY)
{
if (icmp_h->icmp_id == 242 && icmp_h->icmp_seq == ttl)
{
fprintf(stderr, "%s n",
libnet_addr2name4 (ip_h->ip_src.s_addr, 0));
done= 1;
break;
}
}
}
}
}
TCP
While implemented less frequently, TCP also functions as a Layer 4 IP expiry scanning protocol. The terminal packet depends on whether or not the TCP port that it was used to scan with is open or closed. If the port is open, the terminal packet will be a TCP SYN|ACK; if the port is closed, the terminal packet will be a TCP RST. This behavior is the same that we saw in the section on TCP half-open port scanning.
| Note | The most well-known implementation of the IP expiry technique is Traceroute. The original Van Jacobson version, as shown earlier in the book, uses UDP as its transport protocol and sends out three probes per TTL setting (known as a round) to a default maximum of 30 hops. |
Firewalk
Firewalking is an implementation of the IP expiry technique that enables the user to determine Layer 4 access control lists (ACLs) on Layer 3 packet-forwarding devices such as routers and firewalls (for the purpose of this discussion, we refer to these devices generically as gateways). Firewalking works by sending out a TCP or UDP packet with an IP TIL of one greater than the gateway to be scanned. If the packet is accepted by the gateway's ACL, the gateway forwards the packet to the next hop. At this point, the TIL expires and elicits an ICMP 1TL expired in transit message (destined for the original host). If the packet is disallowed by (violates) the gateway's ACL, the gateway drops the packet and no response will be returned The scan will subsequently time out.Firewalking requires the user to specify two hosts: the target gateway to be scanned and the "metric," which guides the scan. The metric does not need to be accessible to the scanning host, and it can be either a gateway or a host; it is just important for the metric to be physically located downstream from the target gateway because it is used as the destination address for the scan. The firewalking host breakdown appears in Figure 9.7.
Figure 9.7: Firewalking host breakdown.
Phase One: Hopcount Ramping
In order to "firewalk" through the target gateway, you must determine the number of hops between the source and the target gateway. Because the hop distance of the target gateway is not known a priori, phase one of the operation—referred to as the hopcount ramping phase—is required. A standard Traceroute-style IP expiry scan is initiated towards the metric host with the intent of finding how many hops away the target host is from the scanning host. Phase one of firewalking appears in Figure 9.8.
Figure 9.8: Firewalking phase one: hopcount ramping.
An IP expiry scan starts as in Figure 9.7.This time, however, when the scanning host receives an ICMP TTL expired in transit from its target gateway, 10.0.2.1, it stops and binds the scan at one hop beyond the target gateway. Only now can the rest of the firewalking process proceed.
Phase Two: Firewalking (Scanning)
Once you reach the target gateway and bind the scan, firewalk scanning can commence. A series of TCP or UDP packets (referred to as probes) are sent from the scanning host to the metric with the bound IP TIL. If a given probe is accepted through the target's ACL, the scanning host receives an ICMP TTL expired in transit from the binding host. If the scanning host receives no response after the timeout expires, we assume that the probe violated the ACL on the target and was dropped.A packet passing the target's ACL appears in Figure 9.9.
Figure 9.9: Firewalking phase two: a packet passes the ACL
A TCP probe to port 22 is sent with an IP TTL of 4 to the metric. The target accepts and forwards the probe and then expires at the binding host. The binding host returns an ICMP TTL expired in transit message to the scanning host, letting it know that the probe successfully made it through the target.Figure 9.10 shows a packet that violated the target's ACL.
Figure 9.10: Firewalking phase two: a packet violates the ACL.
Again, a TCP probe sends to the metric with an IP TTL of 4, but this time the destination port is 23. The TCP probe matches a deny filter rule on the target and is immediately and silently dropped. Because the probe never makes it to the binding host, no expiry message is returned to the scanning host. The timeout expires on the scanning host, and the port is logged as being filtered.
A Creeping Walk
Packets on an IP network can be dropped for a variety of reasons. When a packet is dropped for any reason other than it being denied by a prohibitive filter, it is extraneous loss. For firewalk scans to be accurate, this extraneous packet loss needs to be kept to an absolute minimum. In most cases, the best practice is to transmit a redundant number of probes (indeed, this action is what Traceroute does with three probes per round). Unless there is severe network congestion, some of the probes should get through. What if the firewalk probe sent is filtered or dropped by a different gateway while en route to the target gateway, however? Figure 9.11 shows the early filtering of the firewalk probe.
Figure 9.11: Early filtering of a firewalk probe.
The scanning host sends a TCP probe to port 139 with an IP TIL of 4 to the metric. On the way to the target, the packet violates an ACL on 10.0.1.1 and is silently dropped. The scanning host never receives an expiry response and erroneously assumes the port to be closed on the target, which might or might not be the case. This is not extraneous loss, so simply sending more packets will not help. To mitigate this phenomenon, the user must perform "a creeping walk." This process is akin to a normal scan; however, each hop en route to the target is scanned. A standard firewalk ramping phase is performed, and then each intermediate hop up to the target is summarily scanned. This function prevents false negatives due to intermediate packing filtering and enables the firewalk process to report more confidently.If an intermediate hop is found to filter many of the ports that need to be scanned on the target gateway, a simple solution is to physically move the scanning host to a different part of the network so that it does not route through the offending intermediate gateway in order to get to the target.
Adjacent Target and Metric
An interesting situation arises when the target gateway and metric are topologically adjacent to one another. That is, the metric is exactly one hop downstream from the target. If the scanning host sends a probe that the target drops due to an ACL violation, nothing out of the ordinary happens. If the target routes the probe to the metric, however, which is the destination of the probe, the packet will not expire but rather be processed by the operating system as per RFC 1122. Depending on the Layer 4 protocol used, the destination port, and the applications running on the metric system, the results vary according to the protocol-specific terminal packet semantics described earlier. Figure 9.12 shows an adjacent target gateway and metric situation.
Figure 9.12: Adjacent target and metric
The scanning host sends a probe to TCP port 443. The probe is passed by the target gateway and forwarded to the metric. Instead of expiring and eliciting an ICMP TTL expired in transit message, the probe has reached its final destination and is subsequently processed. Because it is a TCP SYN packet and port 443 is listening on the host, a terminal SYN|ACK packet is returned to the scanning host. It should now be apparent that it is possible to execute a port scan through the target gateway on the metric, albeit a limited one. If a port is accepted by the gateway's ACL, it then becomes possible to scan for active applications on the downstream metric that attach to the specified port. The situation becomes more complicated when UDP is used as the Layer 4 probing protocol. As we discussed earlier, if an application is running on the metric that utilizes UDP sockets, a probe will not elicit a response if a listening UDP port receives it.
Firewalk Program and Code
In Chapter 12, you can find a thorough treatment of the Firewalk 5.0 program and a code walkthrough.
