1. Introduction

With the rapid growth of e-commerce, the networking Denial of Service attack has become one of the most serious threats to the network security field as evidenced by recent attacks deployed in Feb 2000, on several commercial servers such as Yahoo, CNN, Amazon, eBay, E*Trade, ZDNet, and Buy.com. The attacks shut down these sites for several hours and cost millions of dollars in lost revenue.

Analysis of the actual data packets and investigating the traffic pattern is the first step of the research for defending against a DoS attack. In this mini project, we analyzed the traffic trace data of a recent Denial of Service attack against a CoC server to find out what happened during the attack, to identify the victim, and to show the traffic pattern of the attack.
 

2. Project progress

We, Markus and Minho, did this project individually and approached the problem from a different angle. We combined our results and generated this report together with the authorization of professor Jun Xu in order to generate a more complete report on what happened during the attack. Markus approached this problem by analyzing the source address distribution and traffic flow which is described at section 4, and Minho analyzed the symptoms of the DoS attack which are shown at section 5.
 

3. TCP Syn flooding attack

  As we will show in next section, the DoS attack against CoC was TCP SYN flood attack. To help the reader understand our project, we will briefly describe this type of attack.

There are two types of common DoS attacks. The first type attempts to consume all of the victim's bandwidth. This is conduced by sending a tremendous amount of garbage packets from one or many source hosts. The second type is a system resource starvation attack which attempts to use up all the CPU power, memory, or disk space on the victim. By using up all network bandwidth or system resources, the victim cannot provide normal network or system service to users.

A TCP SYN flooding attack is in the second category, resource starvation. Recently, this has become one of the most popular type of DoS attacks. What causes the denial of service is an artifact of the way the TCP protocol uses 3-way handshaking to make a connection.

Figure 1. The 3-way TCP handshake process.

After receiving first SYN packet, the server must save the client information to maintain the half-connection information. When the server receives huge numbers of SYN packets, the queue to record the half-connection becomes full, and the server cannot provide further TCP service.
 

4. Source Address Distribution and Traffic flowing (Markus's work)

For this project, a set of router flow-trace data was analyzed using two of the utilities provided in a flow analysis toolkit, flow-stat and flow-print. A flow is defined as a set of packets in a session between two hosts. The flow-print data shows that the traffic here is almost all TCP. (see figure 4b) Flow-stat provides a high level overview of a flow trace file, while flow-print gives a more detailed packet-by-packet or flow-by-flow representation of the data. Flow-print is configurable into several modes, including ones that report on all flows and more specialized ones that do more filtering of the data. The flow-trace data for this project was recorded on March 27, 2001, spanning from 13:26:25 to 17:16:49. During that time, a large traffic spike is seen from 14:53:43 to 16:19:05 directed at oscar.cc.gatech.edu. The analysis below tests the assertion that the traffic is a denial of service attack, and attempts to find other defining characteristics of the data.

The flow-stat analysis of the data during the traffic spike shows a number of characteristics indicative of a DoS attack. First, over 97% of all the flows consisted of only one or two packets. It is impossible for any useful connection to consist of only two packets, because at that point, the connection is only in the SYN_SENT state. To move the connection to the ESTABLISHED state requires a third packet, which is seen in only a fraction of the flows. Another indication that the traffic is illegitimate is the average packet size. Over 94% of the packets are between 33 and 64 bytes in length. When one subtracts 20 bytes for the IP header, that leaves at best 44 bytes for the underlying protocol's header and actual data. The flow-print data analyzed later shows that the vast majority of these packets are 40 bytes long, leaving little space for a payload. The only types of applications which make use of packets with so little payload are interactive shells such as telnet or ssh. These can be ruled out in this case by the vast amount of traffic, and the fact that the PUSH flag is not set on any of the traffic. In fact, the flags on practically all of these packets had only SYN set, which is a classic indication of a denial of service attack.

A final characteristic of the data which makes it irrefutable that this traffic is a denial of service attack is the distribution of the source IP addresses. For this analysis, flow-print output was used in a mode which only showed flows which it suspects are part of a denial of service attack. From an analysis of the output, the mode selects traffic from connections which never get past the SYN or SYN_SENT/SYN_RCVD TCP states. Normal Internet traffic will not contain traffic from all possible IP addresses. For instance, the 0 and 1 class A networks are reserved, the 10 network is non-routable, and addresses with a high order octet greater than 224 are class D networks, reserved for multicast use. In a normal traffic distribution, there will no traffic from those addresses. The graph below shows a very uniform distribution of high-order octets in the source IP address, a clear indication of a random number function being used to generate the source addresses in a DoS tool. To prevent local traffic from skewing the result, traffic originating within the local network (IE 130.207 addresses) have been discarded.

Figure 2. Distribution of source address high-order octet.

With the above demonstrated evidence, it is clear without a doubt that the data represents a record of a denial of service attack. The next analysis concentrated on studying patterns in the arrival of the data. The following graph shows the number of flows started per minute between 14:53 and 16:19, the time period of the traffic spike.

Figure 3. Flows started per minute during the attack.

It is possible that the rapid drop-off in the number of packets after the start is due to automated detection systems at remote sites which are programmed to react and stem the flow of spoofed traffic. It is unlikely that the drop is due to administrator intervention because that would imply that the systems are being actively monitored, which would probably have prevented their even being infected with a remote control client to launch a DoS attack in the first place. The slower decline after that may be due to the actions of network administrators (rather than individual system administrators) noticing increased traffic flows from their networks. The sharp drop to no traffic for less than a minute shortly after 15:00 is likely an artifact of Internet connectivity, or the actions of the attacked network's administrators. The variability of the amount of traffic in the middle of the graph is likely due to variable congestion on the Internet. Very recently, new DoS tools have emerged which cause the attacking hosts to randomly stop and start their attacks to make them harder to trace. Because this occurred back in March, it is doubtful that those tools were used. The sudden increase near the end of the attack may be due to a second person controlling a network of compromised hosts also joining in on the attack, or the original attacker simply activating a new set of attacking hosts. The rapid cessation of the attack is not likely the result of the responsible person being caught because of the difficulty in locating the source of the packets. What is more likely is that the person simply stopped the attack because he felt he had proved his point that he could render the host inoperable. The following sections will show how effective the attack was at preventing the attacked computer from responding to traffic.

  5. Symptom of the TCP Syn flooding attack (Minho's work)

  - Identifying the attack type

To identify the victim's address, we assessed the number of flows to each destination. Apparently, the victim is the host oscar.cc.gatech.edu because the amount of traffic to oscar is  32 percent of the total traffic while other traffic is roughly evenly distributed to 201755 destinations.

	Number of destinations	: 201756
	Total number of packets	: 41185656
	Number of packets to oscar	: 13109624

By investigating the composition of the traffic, we know that this attack is TCP SYN flood attack because 98.9 percent of packets to the victim are TCP SYN packets.

	Number of packets (TCP, UDP, ICMP) to the victim	: 13109624
	Number of TCP SYN packets to the victim	: 12967624

  - Symptom of the attack
  

Figure 4a: Timing graph of Number of Packets		Figure 4b: Timing graph of Number of Packets (y log scale)

Figure 4a shows the number of TCP, UDP, and ICMP packets by time scale. X-axis represents the elapsed time (minute) from 13:26:25. We can see that large traffic spike that is mostly TCP traffic. Figure 4b shows same contents, but it is drawn with a log scale Y-axis to clearly show the UDP and ICMP traffic. With the lots of TCP, which is mostly consists of SYN packets (as we will see at Figure 5a) ICMP traffic was also increased. This may be attributable to lots of "Destination Host Unreachable" messages caused by attacking packets which have spoofed nonexisting source addresses.
 
  

Figure 4a: Timing graph of TCP packets		Figure 4b: Timing graph of TCP packets (y log scale)

  Figure 5a shows the two kinds of TCP traffic, SYN packets and the other traffic. The X axis represents the elapsed time (minute) from 13:26:25. Most of TCP traffic is SYN packets that are part of the attack. Figure 5b shows the same information with a log scale on the Y axis to clearly show the traffic composition. We can see that the normal traffic for transmitting data is decreased during the attack, clearly representing the effect of the attack.

Figure 6 clearly shows the effect of the attack. This is the graph for number of new connections per minute during the attack. The new connection represents the outgoing traffic from the victim, in flows with four or more packets per flow. (The first three packets are used for initializing connection.) We notice that the number of new connections is significantly decreased as the incoming attacking packets increase.
 

6. Conclusion

In this report, we analyzed the flow trace data of a recent DoS attack against a CoC server machine, oscar.cc.gatech.edu. Even though the range of analysis is limited by the contents of dumped data, the result clearly shows the symptoms of attack. We found definite signs that the additional traffic volume during the time period of the attack consisted of SYN packets, the hallmark of a DoS attack. Also, the source addresses of these packets was statistically random, even containing non-routable of multicast addresses. The attack of this attack was unmistakable, as usable output from the server during the attack dropped measurably, sadly indicating success for the attacker.