The recent attacks on popular web sites like Yahoo, eBay and E*Trade, and their consequent disruption of services have ex- posed the vulnerability of the Internet to Distributed Denial of Service (DDoS) attacks [ 121. It has been shown that more than 90% of the DOS attacks use TCP [ 191. The TCP SYN flooding is the most commonly-used attack. It consists of a stream of spoofed TCP SYN packets directed to a listening TCP port of the victim. Not only the Web servers but also any system con- nected to the Internet providing TCP-based network services, such as FTP servers or Mail servers, are susceptible to the TCP SYN flooding attacks. The SYN flooding attacks exploit the TCP’s three-way hand- shake mechanism and its limitation in maintaining half-open connections. When a server receives a SYN request, it returns a SYN/ACK packet to the client. Until the SYN/ACK packet is acknowledged by the client, the connection remains in half- open state for a period of up to the TCP connection timeout, which is typically set to 7.5 seconds. The server has built in its system memory a backlog queue to maintain all half-open connections. Since this backlog queue is of finite size, once the backlog queue limit is reached, all connection requests will be dropped.
If a SYN request is spoofed, the victim server will never re- ceive the final ACK packet to complete the three-way hand- shake. Flooding spoofed SYN requests can easily exhaust the victim server’s backlog queue, causing all the incoming SYN requests to be dropped. The stateless and destination-based nature of Internet routing infrastructure cannot differentiate a legitimate SYN from a spoofed one, and TCP does not offer strong authentication on SYN packets. Therefore, under SYN flooding attacks, the victim server cannot single out, and re- spond only to, legitimate connection requests while ignoring the spoofed. To counter SYN flooding attacks, several defense mecha- nisms have been proposed, such as Syn cache [ 171, Syn cook- ies 131, SynDefender 161, Syn proxying 1201, and Synkill 1261. All of these defense mechanisms are installed at the firewall of the victim server or inside the victim server, thereby providing no hints about the sources of the SYN flooding. They have to rely on the expensive IP traceback 121, 1211, 12.51, 1281, 1291, [ 341 to locate the flooding sources. Because the defense line is at, or close to, the victim, the network resources are also wasted by transmitting the flooding packets. Moreover, these defense mechanisms are stateful, i.e., states are maintained for each TCP connection or state computation is required. Such a solution makes the defense mechanism itself vulnerable to SYN flooding attacks. Recent experiments have shown that a specialized firewall, which is designed to resist SYN floods, became futile under a flood of 14,000 packets per second [ 8 1. The stateful defense mechanisms also degrade the end-to-end TCP performance, e.g., incurring longer delays in setting up connections. In the absence of SYN flooding attacks, all the overheads introduced by the defense mechanism become superfluous. We, therefore, need a simple stateless mechanism to detect SYN flooding attacks, which is immune to the SYN flooding attacks. Also, it is preferred to detect an attack early near its source, so that one can easily trace the flooding source without resorting to expensive IP traceback. In this paper, we propose a simple and robust mechanism to detect SYN flooding attacks, which is complementary to the de- fense systems mentioned above. The simplicity of this flooding detection system (FDS) lies in its statelessness’ and low com- putation overhead. The FDS is, in some sense, a by-product of the router infrastructure that differentiates TCP control packets from data packets [ 33 1. Instead of monitoring the ongoing traf- fic at the front end (like firewall or proxy) or the victim server itself, we detect SYN flooding attacks at leaf routers that con- nect end hosts to the Internet. The FDS can be deployed at the first-mile or last-mile leaf routers. The benefit of deploying the FDS at the first-mile leaf routers is their proximity to the flooding sources. If a SYN flooding attack is detected at the first-mile leaf router, information about the location of flooding sources is also captured. The flooding sources must be inside the subnet to which the leaf router is connected, hence saving most of the work required by IP traceback. We will discuss the placement of FDS in Section II-B. The key feature of FDS is to utilize the inherent TCP SYN- FIN pairs’ behavior for SYN flooding detection. The SYN/FIN packets delimit the beginning (SYN) and end (FIN) of each TCP connection. As shown in Figure 1 that is borrowed from [ 3 11, under the normal condition, one appearance of a SYN packet results in the eventual return of a FIN packet. Al- though we can distinguish SYNs from SYN/ACK packets, we have no means to discriminate active FINS from passive FINS since each end host behind a leaf router may be either a client or a server. Therefore, the SYN-FIN pairs refer to the pairs of (SYN, FIN) and (SYN/ACK, FIN). In this paper, the “SYN” packets are generalized to include the pure SYN and SYN/ACK packets. While the RST packet violates the SYN-FIN pair, for any RST that is generated to abort a TCP connection2, we can still get a SYN-RST pair. The impact of RST upon SYN flood- ing detection is discussed further in Section II-C.
We rely on packet classification to differentiate the TCP SYN, FIN and RST packets at leaf routers. This packet clas- sification was originally motivated by the desire of providing service differentiation to IP flows. Large-scale packet classifi- cation mechanisms [ 141, [ 161, 1301 have been proposed, mak- ing it possible to distinguish TCP control packets at routers at a very high speed. At leaf routers, no state or state computa- tion is involved in our FDS. Only three new variables are intro- duced to measure the number of received SYN, FIN and RST packets at the inbound and outbound interface, respectively. We refer to the traffic flowing from the Internet to the Intranet as in- hound, and the traffic in the other direction as outbound. Based on this SYN-FIN (RST) pairs’ behavior, the dynamics of the difference between the number of SYN and FIN (RST) pack- ets can be modeled as a stationary, ergodic random process, and our FDS is an instance of the Sequential Change Point Detection [ 11. To make the FDS independent of sites and ac- cess patterns, the difference between the number of SYNs and FINS (RSTs) is normalized by an estimated average number of FINS (RSTs). The non-parametric Cumulative Sum (CUSUM) method 141 is applied, making the FDS much more generally applicable and its deployment much easier. The efficacy of our detection mechanism is validated by trace-driven simulations. The evaluation results show that our FDS has short detection time and high detection accuracy. Moreover, due to its close proximity to the flooding sources, our detection mechanism not only alarms on the ongoing SYN flooding attacks but also reveals the location of the flooding sources. The remainder of the paper is organized as follows. Section 2 discusses the issues related to our detection system. Section 3 describes the proposed detection algorithm based on the TCP SYN-FIN (RST) pair’s behavior. Section 4 validates and evalu- ates the performance of the FDS using trace-driven simulations. Section 5 discusses the related work. Finally, conclusions are drawn in Section 6.
We propose a simple and robust mechanism for de- tecting SYN flooding attacks. Instead of monitoring the ongoing traffic at the front end (like firewall or proxy) or a victim server itself, we detect the SYN flooding attacks at leaf routers that con- nect end hosts to the Internet. The simplicity of our detection mechanism lies in its statelessness and low computation overhead, which make the detection mechanism itself immune to flooding at- tacks. Our detection mechanism is based on the protocol behavior of TCP SYN-FIN (RST) pairs, and is an instance of the Seqnen- tial Change Point Detection [l]. To make the detection mecba- nism insensitive to site and access pattern, a non-parametric Cn- mnlative Sum (CUSUM) method  is applied, thus making the detection mechanism much more generally applicable and its de- ployment much easier. The efficacy of this detection mechanism is validated by trace-driven simulations. The evaluation results show that the detection mechanism has short detection latency and high detection accuracy. Moreover, due to its proximity to the flood- ing sources, our mechanism not only sets alarms upon detection of ongoing SYN flooding attacks, but also reveals the location of the flooding sources without resorting to expensive IP traceback.
This paper presented a simple and robust SYN flooding de- tection mechanism to be installed at leaf routers. The detection utilizes the SYN-FIN pairs’ behavior that is invariant under the various arrival models and independent of sites and time-of- day. The distinguishing features of FDS include: (1) it is state- less and requires low computation overhead, making itself im- mune to SYN flooding attacks; (2) the non-parametric CUSUM method is employed, making the detection robust; (3) it is in- sensitive to site and access pattern; and (4) it does not under- mine the end-to-end TCP performance. The efficacy of FDS is evaluated and validated by trace-driven simulation. The simula- tion results show that the FDS achieves high detection accuracy and short detection time. Moreover, once the first-mile FDS detects the ongoing flooding traffic, information about the loca- tion of flooding sources is also revealed, thus saving most of IP traceback efforts.