target.my.com > tracer.net: icmp: echo reply (DF) tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF)

tracert sends the first ICMP echo request in an IP datagram with a time-to-live (TTL) value of 1. The TTL is a value set by a sending host and decremented by each network device through which the packet traverses. TTL provides a means of discarding packets that have overstayed their welcome on the Internet and might be bouncing aimlessly. If a router decrements the TTL and the value becomes 0, the packet must be discarded and an ICMP "time exceeded intransit" error message is returned.

In the previous output, after a TTL with a value of 1 is observed, the router router.my.com sends an ICMP "time-exceeded in-transit" message. This is because it decremented the TTL and discovered a value of 0. It must then discard the packet and inform the sending host.

When used for tracert, however, the original source host receiving this ICMP error message records the router from which it came. If necessary, tracert then sends another ICMP echo request in an IP datagram, but increments the TTL value by 1. This process repeats until the ICMP echo request finally makes its way to the destination host and receives an ICMP echo reply.

By default, three different ICMP requests are sent to each new hop for redundancy in case a packet is dropped. Notice that tracer.net sends an ICMP echo request to target.my.com. Immediately, you see the reply from router.my.com complaining via the ICMP "time exceeded in-transit" message that the TTL value has been decremented to 0. This is seen for all three different ICMP echo requests. The host tracer.net then increments the TTL to 2, which is enough to allow it to get to the actual destination host, target.my.com. The reason that you do not see TCPdump display the TTL value of 2 is because the default behavior of TCPdump is to print the TTL only when it has a value of 1 to warn of an impending problem. target.my.com responds to all the ICMP echo requests with echo replies. If you want to examine the TTL regardless of value using TCPdump, use the command line option –vv.

Protocol Benders

Between the expected and abnormal falls a netherland of applications that exhibit normal, yet unconventional, behavior. These applications deviate from the expected behavior because they were designed differently. These patterns are presented so that if you encounter them, you will understand that this is normal traffic.

Specifically, FTP and UNIX Traceroute will be discussed. FTP is considered to be a protocol bender because it defies the convention of using one ephemeral and one server port for the duration of the FTP connection. The UNIX Traceroute is an unusual application because it combines ICMP and UDP to navigate from source to destination and record all routers on the way.

FTP

The expected behavior of TCP that you have witnessed so far is to establish the two ports used by the client and server during the three-way handshake. The client usually selects an ephemeral port greater than 1023, and the server listens on a well-known port. Throughout

the remainder of the established TCP session, the client and server talk only on these established ports. FTP differs from most other TCP services, because it communicates using two different server ports. The first port is port 21, which is known as the standard FTP command port. The second port is used for data passed between the client and the server. The actual port used is different for active and passive FTP, as you will soon see.

Active FTP

Active FTP is so named because the FTP server opens up the data connection to the client. Both active and passive FTP use port 21 to issue FTP commands, such as those to retrieve or store a file. But, in active FTP, the second is port 20 for FTP data passed between the client and the server. The FTP data port is used to exchange a file between the two hosts or to send a listing of file directories from the server to the client.

Look at the following TCPdump output for an active FTP session to see an unusual, but normal, change of TCP ports:

Session negotiation:

ftp.client.com.35955 > ftp.server.com. 21: S 1884312222:1884312222(0) ftp.server.com.21 > ftp.client.com.35955: S 3113925437:3113925437(0) ack 1884312223

ftp.client.com.35955 > ftp.server.com.21: . ack 1 ftp.server.com.21 > ftp.client.com.35955: P 1:24(23) ack 1 ftp.client.com.35955 > ftp.server.com.21: . ack 24

dir command issued by the user:

ftp.server.com.20 > ftp.client.com.35956: S 3558632705:3558632705(0) ftp.client.com.35956 > ftp.server.com.20: S 1901007864:1901007864(0) ack 3558632706

ftp.server.com.20 > ftp.client.com.35956: . ack 1

In the preceding example, the FTP connection is established between ftp.client.com using ephemeral port 35955 and server port 21. The three-way handshake is completed and some data (usually a welcoming message) is passed between the two. This is similar to what you have witnessed with other TCP protocols.

Next, the user issues the FTP dir command from the client requesting a listing of the directories on the server. A new connection is established from source port 20 of the server to the ephemeral port 35956 on the client. Although you do not see it in the output, the client informed the server that it would be listening on ephemeral port 35956 via the FTP port command. After this new three-way handshake is completed, ftp.server.com can send the directories to ftp.client.com on this established connection. Additional exchanges of data cause the establishment of new connections and the selection of new ephemeral ports. This is called active FTP because the FTP server initiates the data connection to the client. As you might guess, this presents some problems for packet-filtering devices that would have to indiscriminately allow traffic into the network coming from source port 20. Passive FTP avoids these problems by having the internal FTP client make the data connection.

Passive FTP

Passive FTP differs from active FTP in the manner in which the data connection is established. It uses the identical method of connecting to FTP port 21 to establish the command port. But, as you observed with active FTP, the problem arises when a packet-filtering device must allow initial SYNs in from source port 20 to a high-numbered port inside the packet-filtering device. What is to keep a hacker from using this hole as a way into the network? After all, the packetfiltering device might not be examining the content of the packet using this hole and cannot be sure it is indeed FTP traffic.

Passive FTP avoids this problem altogether by having the client initiate the connection to the server. Remember that active FTP required that the server initiate the connection to the client. Look at the following output of a passive FTP session establishment:

Session negotiation:

ftp.client.com.44890 > ftp.server2.com.21: S 4276284026:4276284026(0) win 8760 <mss 1380> (DF)

ftp.server2.com.21 > ftp.client.com.44890: S 1669630260:1669630260(0) ack 4276284027 win 8280 <mss 1460> (DF)

ftp.client.com.44890 > ftp.server2.com.21: . ack 1 win 9660 (DF) dir command issued by the user:

ftp.client.com.44891 > ftp.server2.com.3967: S 4282611109:4282611109(0) win 8760 <mss 1380> (DF)

ftp.server2.com.3967 > ftp.client.com.44891: S 1669768808:1669768808(0) ack 4282611110 win 8280 <mss 1460> (DF)

ftp.client.com.44891 > ftp.server2.com.3967: . ack 1 win 9660 (DF)

When ftp.client.com issues the dir command on the current command connection, it causes a data connection to be established. You don't see this in the TCPdump output, but ftp.server2.com informs the client via the FTP port command that it will be listening on port 3967. The client issues the SYN connection to that port and the server responds with a SYN/ACK. The directory listing is done via this connection. Because the client is making an outbound connection to the server, the subsequent responses from the server can be allowed back in the packet-filtering device with relatively strong confidence that this is a "safe" connection. This involves less risk than allowing active FTP connections by permitting all inbound source port 20 through the packet-filtering device.

UNIX Traceroute

The UNIX Traceroute program discussed next shows a combination of UDP and ICMP to discover the path that a datagram takes from source to destination. This traceroute program is similar in function to the Windows Tracert; instead of using ICMP to discover the routers and destination host, however, it uses UDP.

The intermediate routers that are discovered respond as you saw in the Windows Tracert with ICMP "time-exceeded in-transit" messages when an IP datagram has a TTL value decremented to 0. Again, this process is repeated until the UDP datagram makes its way to the destination host by incrementing the starting TTL value by 1 for each new hop to be forged beyond the previous one. The UDP destination port chosen is one typically in the 33000–33999 range—one that almost surely does not listen. The intention is to elicit an ICMP "UDP port unreachable"

message that signals to traceroute that the destination host has been found. Like tracert, the default behavior for traceroute is to send three different connections to each router or host. This example alters the behavior to send only one for simplicity:

tracer.com.62615 > target.com.33456: udp 12 (DF) [ttl 1] router.com > tracer.com: icmp: time exceeded in-transit [tos 0xc0]

tracer.com.62615 > target.com.33457: udp 12 (DF)

target.com > tracer.com: icmp: target.com udp port 33457 unreachable (DF)

In the preceding output, you see tracer.com send a UDP datagram to destination port 33456 of target.com. The initial TTL value is set to 1. As soon as this packet hits router.com, it decrements the TTL value to 0 and returns an ICMP "time exceeded in transit" message to tracer.com. When tracer.com receives this, it sends another UDP datagram to target.com. This is different from the first one because it increments the destination port to 33457 and, while you cannot tell from the standard TCPdump output, it increments the initial TTL to 2. This allows the datagram to traverse the first router, router.com, and take one more hop. That additional hop takes it to the destination host target.com that does not listen on port 33457 and returns an ICMP "port unreachable" message.

You should be aware that both the UNIX traceroute and the Windows tracert only work if specific ICMP messages are allowed into the network of the host executing the commands. Both versions require that ICMP "time exceeded in-transit" messages be allowed into the network. The UNIX traceroute requires that ICMP "port unreachable" messages be allowed, and Windows tracert requires that ICMP echo requests be allowed.

You are probably asking whether these types of ICMP messages should be permitted inbound to your network. This really depends on the security posture you adopt. At the most protected and restricted sites, this is not necessarily recommended. The risks might far outweigh the benefits because it is possible to use these ICMP messages for purposes other than the ones for which they were designed, as was witnessed with the discussion of Loki in Chapter 4.

However, if your site is a more open one and you are willing to accept the risks, allowing these ICMP messages can provide some obvious benefits of route discovery along with informative feedback to internal hosts in your network.

Summary of Expected Behavior and Protocol Benders

Here is a brief synopsis of what has been covered so far in this chapter. The RFCs are the standards documents upon which TCP/IP and the Internet were built. They describe how things are supposed to work when everyone conforms to the same rules. Unfortunately, hackers have discovered that different implementations of TCP/IP react differently to deliberate violations of the RFC standards. That's one of the foundations of hacking: deliberately exploiting exceptional conditions that the implementers of the TCP/IP code believed would never happen. Hackers often attempt to identify operating systems by sending strange stimuli and observing the host's responses. The final part of this chapter looks at some of the reactions of systems to these deliberate deviations.

As previously discussed, there are unique responses for the same stimulus depending on the circumstances and availability of the requested service. Responses also depend on a host or router's capability to respond to a particular connection. Each of the different protocols has