number of bytes exchanged can come in handy in assessing the severity of what might have transpired. You might not be able to see the actual data bytes or payload, but numbers can be telling. Lengthy individual exchanges and the number of exchanges in aggregate can readily indicate potential damage by an intruder.

●Who began and/or ended the connection? By determining which host initiated and terminated the connection, you get an idea of who is in control. Typically, the client requests the connection and the server responds (as you have already seen). Either host can end the conversation, so observe which one initiates the termination with a RESET or FIN.

Damage Assessment

Using TCPdump as a detective tool to analyze an attempted computer break-in is like investigating a burglary attempt or actual burglary. The first step in damage assessment is determining whether the perpetrator actually got into the computer system (or in the case of a burglary, into the house). Repeated SYN attempts to a system without a reply might be the equivalent of jimmying a door without successful entry. The completion of the three-way handshake is the equivalent of entry; it might just be through the garage door, which also requires a key to get into the house, but it is indicative of some kind of entry. The three-way handshake is the evidence equivalent of finding a previous locked door now unlocked or finding strange fingerprints inside the locked door.

The server port number can indicate the intruder's interest. The use of a conventional port, such as telnet, means that perhaps the burglar might be doing a serious raid of goods (password files, trusted host relationships, and so on), the equivalent of a thief's interest in jewelry and appliances. What about the unconventional port numbers that don't support a known service? Is that the sign of some kind of a joyride through your system just to prove it can be done—kind of like coming home to find that someone drank all the milk in the refrigerator, threw the empty carton on the floor, and did or took nothing else?

Whereas the house burglary damage might be assessed by determining what is blatantly gone (the big-screen TV, for example), what about a burglar who broke into a big, fully stocked warehouse that didn't keep good inventory records? How would you make an assessment of stolen goods? Perhaps a neighbor saw a strange vehicle in the driveway. Was it a moving van or was it a motorcycle? When you examine the number of bytes exchanged in the TCPdump output, you are in effect determining what kind of haul the burglar made off with. You are making best-guess efforts based on the little evidence that you have.

TCP Gone Awry

In subsequent chapters, you will read many examples of the malicious attacks that employ TCP. Appendix A, "Exploits and Scans to Apply Exploits," and Appendix C, "Detection of Intelligence Gathering," discuss scanning methods that use different and sometimes unexpected combinations of TCP flags to perform reconnaissance on networks and circumvent detection or bypass filtering attempts. The following sections introduce some other anomalous TCP activity, such as an ACK scan, a telnet scan, and TCP session hijacking.

An ACK Scan

Scans of ports are done for a variety of reasons, but they usually are used to discover whether a host or hosts are offering a particular service. If a host is found to be offering a service that might be exploitable, the hacker might try to break in using some vulnerability. Often, scans are blatant; the hacker makes no attempt to hide his reconnaissance of your network, except that the computer from which the scans originate might be compromised. The hacker assumes that either no one is monitoring the scanning activity or that by using the compromised host, no one can identify the hacker with the scan. Most likely there will be no attribution because no one can associate the hacker with the scan.

At times, however, the scanner attempts to be more furtive about the reconnaissance efforts in an attempt to evade notice. Examine the following activity, which is TCPdump output of many related connections. The prober can identify live hosts by those responding to the ACK

scan. The deletion of time stamps makes it more readable: ack.com.23 > 192.168.2.112.23: . ack 778483003 win 1028

ack.com.23 > 192.168.31.4.23: . ack 778483003 win 1028 ack.com.143 > 192.168.2.112.143: . ack 778483003 win 1028 ack.com.143 > 192.168.31.4.143: . ack 778483003 win 1028 ack.com.110 > 192.168.2.112.110: . ack 778483003 win 1028 ack.com.110 > 192.168.31.4.110: . ack 778483003 win 1028 ack.com.23 > 192.168.14.19.23: . ack 778483003 win 1028 ack.com.143 > 192.168.14.19.143: . ack 778483003 win 1028 ack.com.110 > 192.168.14.19.110: . ack 778483003 win 1028 ack.com.23 > 192.168.33.53.23: . ack 778483003 win 1028 ack.com.23 > 192.168.37.3.23: . ack 914633252 win 1028 ack.com.23 > 192.168.14.49.23: . ack 3631132968 win 1028

The preceding scan from ack.com sends an ACK flag to various different hosts on the internal 192.168 network. A lone ACK should be found only as the final transmission of the three-way handshake, an acknowledgement of received data, an acknowledgement of a received FIN, or data that is transmitted where the entire sending buffer has not been emptied. This is not the case in this scan because no other traffic is found from ack.com to indicate that this is a reaction to some natural catalyst.

This might be an attempt to find live hosts, somewhat akin to the function of ping. If a live host receives an ACK for either an open or closed port, it should respond with a RESET. Also, filtering routers that allow only "established" connections into the network (in other words, the ACK bit is set) will not filter this kind of scan. As sites become more security conscious and begin to block more traffic into the network, those who want to do reconnaissance have to become more clever and stealthy in the manner in which they scan, as shown in this example. Note that the source ports are the same as the destination ports. This is not the expected behavior of the client selecting an ephemeral port with a value greater than 1023. This is another signature that helps to identify this scan. With the lone ACK flag set and identical source and destination ports, we can assume that this traffic has been "crafted." Someone has written a program to execute this particular scan; it is not the result of normal TCP/IP stack traffic generation.

Reserved Private Networks

Throughout the text, you will see references of networks 192.168 and 172.16 as examples. These particular address spaces are part of what the governing body of the Internet, the Internet Address Numbers Authority (IANA), has deemed to be reserved private networks per RFC 1918. In other words, these are address spaces that should be used for internal networks and traffic should not be sent to or from these networks. These address spaces are often used so that a site will not exhaust its actual assigned addresses.

Traffic to these networks is not routable because these are private address spaces. When you see these address spaces used in examples, understand that they are being used to disguise the real address spaces that were scanned or probed. The intent is not to imply that traffic can be routed to theses networks via the Internet.

A Telnet Scan?

Look carefully at the next scan. Short of finding Waldo in the output, do you see anything

amiss?

scanner.se.45820 > 192.168.209.5.23: S 4195942931:4195942935(4) win 4096 scanner.se.45820 > 192.168.216.5.23: S 4195944723:4195944727(4) win 4096 scanner.se.52526 > 172.16.68.5.23: S 357331986:357331990(4) win 4096 scanner.se.45820 > 192.168.183.5.23: S 4196001810:4196001814(4) win 4096 scanner.se.52526 > 172.16.248.5.23: S 357312531:357312535(4) win 4096 scanner.se.45820 > 192.168.205.5.23: S 4196007442:4196007446(4) win 4096 scanner.se.52526 > 172.16.250.5.23: S 357313043:357313047(4) win 4096 scanner.se.52526 > 172.16.198.5.23: S 357365266:357365270(4) win 4096 scanner.se.52526 > 172.16.161.5.23: S 357355794:357355798(4) win 4096

To the naked eye, it is a scan from scanner.se of destination hosts on the 192.168 and 172.16 subnets—specifically to destination port 23, or telnet. You might conclude that this is an attempt to find all hosts on the destination subnets that offer telnet, and that would be mostly correct. A subtle signature might indicate potentially evasive behavior, however. A SYN request usually sends no data bytes, but this scan sends 4 bytes, as you can tell by looking at the number in the parentheses.

You might imagine that the 4 bytes of data sent before the completion of the three-way handshake would be discarded. However, this is not the case. The 4 bytes should be included in the data after the handshake has been completed as noted by RFC 793. Any payload bytes that are sent during the handshake become part of the data stream after the completion of the handshake according to the RFC. This could be a good way to circumvent detection by an intrusion-detection system (IDS) that examines data sent only after the three-way handshake. If you see 64 data bytes sent on a SYN connection to your DNS server to the DNS port 53, this might indicate a different issue altogether. Software known as 3DNS attempts to give users the quickest response time to web requests. One way that this is done is by attempting to measure the response time to your DNS server from one or more web servers that might be used to respond to the user's request. As a representative size of a typical web request, 64 bytes are used. If you see this activity, it should not be considered stealthy; perhaps you might deem it invasive or annoying, or even ineffective because many sites block inbound

activity to TCP port 53, but the intent is not malicious.

TCP Session Hijacking

Although TCP appears to be a fairly safe protocol because of all the negotiation involved in session establishment and all the protocol and precision involved in data exchange, don't get complacent. Evil sniffers can be set up on an unsuspecting host to capture TCP or other data that crosses the sniffers' path. Sniffers that are placed on networks that are not switched can snoop clear-text data such as user IDs and passwords that are not encrypted in any way. Session hijacking software, such as Hunt, uses another approach to exploit an existing TCP session. These attempt to intercept an established TCP session and hijack one end of the