SYN Flooding Attacks and Countermeasures: A Survey

Download PDF
41 downloads 0 Views 439KB Size Report
Comment
Sep 10, 2003 - how the attack works. It will also discuss methods of de- fense against the TCP SYN Flooding attack and how do these methods work to prevent ...
SYN Flooding Attacks and Countermeasures: A Survey Raed M. Bani-Hani

Zaid Al-Ali

Jordan University od Science and Technology Dept. of Network Engineering and Security Irbid, Jordan

Jordan University od Science and Technology Dept. of Network Engineering and Security Irbid, Jordan

[email protected]

[email protected]

ABSTRACT This paper discusses the SYN Flooding attack, which is a specific type of Denial of Service attacks (DoS). This attack had always been a very important subject to be studied in the Information Security field. It exploits characteristics of the Transmission Control Protocol (TCP). It can be launched against machines that bind to and listen on a TCP socket. Thus, it can make the machine incapable of providing services to legitimate clients. In addition, the paper will describe the types of attack, variations of the attack, and how the attack works. It will also discuss methods of defense against the TCP SYN Flooding attack and how do these methods work to prevent such attack. Furthermore, the advantages and disadvantages of these methods will be provided. Figure 1: TCP three-way handshaking.

Categories and Subject Descriptors C.2.2 [Computer Communication Network]: Network Protocols—Protocol Architecture; D.4.4 [Operating Systems]: Security and Protection

General Terms Security

Keywords DDoS, SYN-flooding, Security Attacks, TCP Protocol

1. INTRODUCTION The basic vulnerability that allows SYN Flooding attack to occur depends on the design and implementation of TCP, precisely in the three-way handshaking which represents the connection setup part of TCP. This handshaking happens in three steps. First, the client sends a Synchronize (SYN) packet to the server. Second, the server allocates resources and responds with a SYN and SYN acknowledgement (SYNACK) packet. Finally, the client responds back with an ACK packet[14].

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. iCICS 2013, April 23-25, 2013, Irbid, Jordan. Copyright 2013 ACM 1-58113-000-0/00/0010...$10.00.

Based on that, the attacker utilizes the second step to make a successful attack. As shown in Figure 1, when a TCP server receives a SYN packet, it immediately allocates resources for the received SYN in the ”Transmission Control Block” (TCB) that is used to hold information about each connection. Each TCB has a memory of at least 280 bytes. When the server is in the SYN RECEIVED state, the connection is half opened and there is no verified information about the other side; if no response was received, the server is stuck in the SYN-RECEIVED state for a while. From this we can clearly see a potential DoS attack: by sending a flood of SYN packets and ignoring the corresponding server’s replies, the server will keep allocating TCBs for the incoming connections and eventually the server’s memory will be exhausted and as a result the server will crash. If, on the other hand, the server’s reply is handled, this could let the server free some of the TCBs. Many types of defenses were proposed after this attack was discovered. However, the attack also evolved and adapted to overcome these defenses. This paper clarifies types and variations of the attack, exploits and weaknesses in the host that the attacker looks for to launch his attack, and describes types of end-host based defenses against the attack. In addition, the paper will illustrate the strengths and weaknesses of each defense type. Attackers exploit certain properties of the Internet, which are: destination oriented routing, the stateless nature of the Internet and the lack of authenticity. All of these proper-

ties combined with the deterministic nature of the Internet protocols make DoS attacks absolutely achievable. This informative paper aims to be an opening to a research that could hopefully end up with a standard to prevent SYN Flooding attack. By describing this attack and explaining the available defense methods, we are planning to propose a new type of defense, or correct the flaws and weaknesses in an existing one. Furthermore, multiple types of defense (called Hybrid Approach) can be proposed based on the current defense approaches. The rest of the paper is organized as follows: section 2 explains the SYN attack. Section 3 discusses types of attacks including direct attack, spoofed based, distributed and reflectors attacks. Section 4 discusses end-host based defenses against the attack. Section 5 explains the issues to consider before designing a defense method and provides some hybrid approaches for defending against the attack. Finally, we conclude the paper in section 6.

2. SYN FLOODING ATTACK ”TCP implementation as described in RFC 4987 lets the host to enter the LISTEN state for all, some or none of the IP addresses pair, port number pair specified in application” [8]. If the server host does not know the IP address neither the port number of the client host, the server host must listen to any address and to any port. Thus, it can not specify any information about the client host. If the server host enters such listening state, we call it ”unbound” LISTEN state [8]. Unbound Listen state is the target of the SYN-flooding attack in which the attacker depends on the deterministic nature of TCP. The attacker expects the server host to accept requests and also to allocate resources for these requests. As result, the attack will consume the server’s resources. Web applications, which use TCP, depend on unbound listen for their functionality, so many of them are under the threat of such attack. DoS Attacks on the Internet defer depending on what type of resources the attacker consumes to make the victim incapable of serving legitimate clients. For example, some may consume link bandwidth, memory or CPU cycles. Allocating resources for the received SYN segments is the main goal of SYN Flooding attack, so the attack aims to exhaust the memory space of the victim for the longest possible time by sending a flood of fake SYN packets. Two important issues to be considered in making a successful SYN-flood attack are Barrage Size and Barrage Frequency[8]. Barrage size means how many SYN packets to be sent to the victim. Usually the size or number of SYNs to send is measured according to the backlog queue (the memory space allocated for the incoming connections). Thus, the number of SYN packets must be larger or equal to the backlog queue size to consume all reserved memory for incoming connections. Barrage frequency means how long to wait between floods of request. SYN-flood attack aims to consume the end host resources but not to burn the bandwidth, so there must be some time measurement to determine when to resend SYN packets. This depends on the lifetime of the half-opened connections since the victim would reclaim the

Figure 2: Direct Attack. resources after this amount of time. For instance, a timer is set for 75 seconds after sending the SYN-ACK packet; here the frequency barrage should be every 75 seconds to keep the victim busy and all resources are consumed for longer time. An important thing to note is that ”the attack is directed at a particular listening application not the end host itself. In fact, it attempts to prevent only new incoming connections but not the outgoing or the already established ones [8].

3. TYPES OF ATTACKS 3.1 Direct Attack If the attacker uses his/her own IP for the attack without spoofing or using other compromised machines this is called ”Direct Attack”. It is a very simple attack in which the attacker can simply do the attack by calling the connect( ) system call [15] many times as illustrated in Figure2. In Figure2, the attacker must ignore the victim’s replies for the attack to be successful. If, on the other hand, the attacker machine handles the replies, this would allow the victim to free the reserved resources. In order to ignore the victim’s replies, the attacker might use firewall to filter incoming packets by blocking SYN-ACK packets whose source IP matches that of the victim. This type of attack is trivial and practically not used by attackers because there are many disadvantages from the attacker perspective. One important objective of an attack is to conceal the identity of the attacker. In Direct Attack, there is no IP spoofing. Therefore, it is very easy to trace back the flood of packets and find out who initiated them. Another weakness in the Direct Attack is that if the victim detects the attack, it can simply block the attackers IP to prevent this attack

3.2

Spoofed-Based Attack

This type of attack is more convenient for attackers because it uses IP spoofing. Thus, the attacker’s identity is concealed. IP spoofing can be done by changing the headers of the packets and injecting new ones with spoofed IP(s). This process is much easier now a days because there are many ready tools to help in injection desired information in packet headers. Furthermore, advanced attackers can spoof IP addresses by misusing programming languages and Application Programming Interfaces (API’s). For example, a

Figure 4: DDoS Attack Figure 3: Spoofed-Based Attack.

skilled attacker can bypass the process of IP header generating (which is done by the kernel), and build his/her own header using ”RAW” sockets. For more details about RAW sockets see Steven’s book [15]. Since the attacker spoofs the IP address, then the victim’s replies will be sent back to the spoofed IP address as shown in Figure 3. Thus, the attacker has to choose the spoofed IP wisely. That is, the attacker must choose a spoofed IP that does not exist on the network, or at least to guarantee that the spoofed IP will not respond to the victim’s replies because if that happened, and there were responses from the spoofed IP’s, then the victim will receive error messages and free it’s resources. The attacker can do the attack either by choosing one appropriate spoofed IP to inject it in all the outgoing packets, or take a list of IP addresses and recycle through the list injecting each packet with a different IP. If the attacker chooses one IP for all packets, the victim could simply block the spoofed IP and stop the attack. However, in this case the attacker managed to hide the real source IP, thus the identity is protected. If the attacker spoofed the packets with different IP addresses, the attack is more complex and it makes the defense more difficult, since the victim can’t deicide from which source the flood is coming. Spoofed-based SYN Flooding attack hides the original IP address of the attacker and thus the identity is protected. However, since all the packets are coming from one physical source [despite using different spoofed source IP addresses] and going to same destination [victim], such activity on the network can lead to the detection of the attack since the attacker launches the attack from only one machine which means that a large amount of traffic leaves that machine, and by monitoring the network’s traffic eventually the attacker’s machine can be traced back and get caught.

3.3 Distributed Attack To make a powerful attack, the attacker may use more resources than one machine. Using a large number of compromised machine to do the attack makes the attack more powerful, more secure (from attacker’s perspective), and more

difficult for the victim to defend against. This attack is known as the Distributed Denial of Service attack (DDoS). It is clear that the attacker uses a number of machines to launch the attack. DDoS must pass two major phases: The recruitment phase and the actual DoS attack phase. Recruitment is gathering the largest number of machines to launch the attack. The attacker first makes an intensive scanning for vulnerable machine and security flaws which can be in the same Local Area Network (LAN) or in the Wide Area Network (WAN). Then, the attacker breaks into these vulnerable machines and gets access to them. Finally, the attacker injects the attack tool in the vulnerable machines. As a result, these machines will be ready to participate in the attack and might be used to compromise other machines. These machines are sometimes called ”zombies or slaves” and some calls them ”botnets” because they just do whatever the attacker orders them to do. In fact, machines owners don’t even know that their machines are compromised. After the recruitment phase, the attacker can choose master botnets or Handlers [12]that can communicate and send orders to other botnets. By choosing master botnets, the compromised machines become hierarchal and more manageable (see Figure 4).Then, the attacker can communicate with the slaves (compromised machines) directly by Internet Relay Chat ”IRC” or by master botnets (Handlers). Recruitment phase is probably the hardest part of DDoS. In order to do it, there are many techniques used such as, Sophisticated Scanning, Random Scanning, and Divide and Conquer Scanning [12, 5]. However, the recruitment phase is not a problem anymore for attackers because nowadays botnets are rented, and there is an underground market for renting and buying botnets. ”Based on an experiment conducted by researchers from VeriSign’s iDefense Intelligence Operations Team, involving 25 different ”rent a botnet/DDoS for hire” underground marketplace propositions, they were able to conclude that the average price for renting a botnet is $67 for 24 hours” [7]. DDoS is the attacker’s golden ticket for a successful attack. The identity of the attacker is almost perfectly concealed and it is practically impossible to trace back the attacker since the attack starts from zombies and the order of attack is given by master botnets. It is very difficult to tell who

queue, the queue starts to handle incoming SYN packets and store information about new connections. Many kernels divide this queue into two queues. The first queue is for the SYN-RECEIVED state connections which have not finished the three-way handshaking and the server is still waiting for the acknowledgment from the client. The second queue is for the completed connections. Entries in the completed connections queue are waiting for the kernel to deliver the completed connection to the application [15].

the real attacker is.

As a defense against the SYN-Flooding attack, some applications just increase the backlog queue size to handle as much as possible incoming connections. This is not efficient since the attacker can simply increase the number of SYN segments ”barrage size”. In addition, there is an upper limit for the size of the backlog queue to be allocated for each application.

DDoS has evolved and became much more complex and more effective. Actually, DDoS is evolving faster than the defense itself, and it is very hard to detect such attack since it is distributed. Many advanced DDoS attacks had appeared lately and many ready tools to conduct the attack are widespread on the Internet [1].

A more efficient way to increase the backlog queue is to dynamically increase its size. When an application experiences a flood of SYN segments ”possibility of an attack”, it can increase the backlog queue dynamically until it handles this flood. Many applications like Apache and Microsoft Internet Information Services (IIS) use such mechanism [3].

3.4 Reflection Attack

Dynamically increasing the backlog queue size is more efficient. However, it is not capable of stopping SYN-flood attack. It is not advisable to use such defense mechanism, or at least not use it alone. In fact, hosts can use this type of defense alongside with other types of defenses as a ”Hybrid Approach”.

Figure 5: Reflection Attack

Reflection attack is another type of distributed attack. It is an indirect attack that uses the intermediate nodes between the attacker and the victim to do the attack. The intermediate nodes are called ”reflectors”. This type of attack depends on messages that require replies such as ”Reset” (RST) and ”Internet Control Messaging Protocol” (ICMP) messages [4]. The attacker sends a flood of messages to the reflectors with spoofed IP address of the victim, and then the reflectors will respond back to the victim and flood it with replies. In reflection attack, the attacker uses the same army of compromised machine of DDoS mentioned in the previous section to send reflectors the messages. Hence, that reflectors are not compromised machines; they are normal machines connected to the Internet. In order for these machines to generate replies and flood the victim with them, these machines should run TCP and IP protocols in order to understand the messages they receive. As shown in figure 5 5, this type of attack could make a huge amount of traffic burning the bandwidth of the victim, which will eventually causes a DoS attack. Reflection Attack floods the victim with reply messages, since SYN segments cannot be produced as replies; it is not possible to launch a SYN Flooding attack using such method. However, Reflection attack can be used against hosts that enable some types of SYN Flooding defenses (discussed later in section 4).

4. TYPES OF DEFENSE 4.1 Increasing Backlog Queue Backlog queue is a large data structure that keeps record of incoming connections until the three-way handshaking complete, and then the kernel allocates memory known as a ”buffer” for every complete connection. When a TCP application allocates memory for a backlog

4.2

Reducing SYN-RECEIVED Timer

SYN-RECEIVED timer is set whenever a SYN segment is received, defining how long to wait before removing the allocated TCB for each unfinished connection that is not progressing ”not finishing the three-way handshaking for some reasons” [8]. By reducing the time which the server would wait for a client to complete the connection, the server won’t keep the TCB’s for long time, and then the server will free the allocated memory in less time. Since SYN Flooding attack aims to consume the memory of the victim for the longest possible time, this type of defense seems to be suitable. This solution might be simple and easy to implement. However, it is absolutely not efficient since it has many disadvantages. When an attack is in progress, the SYN Flooding packets can cause congestion on the victim’s path. Thus legitimate clients’ packets will be delayed due to this congestion, and as a consequence of reducing the SYN-RECEIVED timer their TCB’s will be removed. As a result, this mechanism will fail to serve a legitimate client which is the goal of the defense in the first place.

4.3

SYN Cache

Allocating TCB’s for incoming connections after receiving SYN segments is the main problem that made SYN-flood attack possible. TCB’s store full information about the incoming connections such as IP addresses and port numbers. In addition, TCB also stores information about flow control, congestion control and socket number variables.

exhausting the memory of the hash table. Another problem in SYN Cash resides in delaying full information storing. SYN segments are not only used to establish the connection, they also can carry some options such as, maximum segment size (MMS), selective acknowledgments (SACK), time stamp and other options, and these options are not retransmitted in the ACK segment. As a result, SYN Cache will lose these pieces information and this could affect the performance of the connection.

Figure 6: SYN Cache

SYN Cache idea is based on postponing the processes of full information storing until the three-way handshaking completes. When a SYN Cache enabled host receives a SYN segment, it only stores a small amount of information about the incoming connection including IP addresses pairs and port number pairs. SYN Cache uses a global hash table with limited amount of space to store the basic information about the incoming connections. Each entry in the table has a unique index, as shown in Figure 6.The index is calculated using IP address pairs, port number pairs and a selected secret bits from the received SYN segment, all combined together as an input to hash function producing the new entry index as an output. When a connection completes the three-way handshaking, the hash value is calculated using the information inside received ACK, then the host searches the hash table for matching. If a match was found, the connection is moved to TCB. Otherwise, the packet is dropped. The hash table is divided into subsets called ”buckets”, and the entries are stored in each bucket as a linked list. This increases the efficiency of searching the hash table. The selected secret bits are used to prevent the attacker from targeting a specific bucket [13]. The bucket acts as a queue such that if there is no enough memory in the bucket it removes the oldest entry and adds the new entry to the beginning of the queue ”first come first serve”. Since the hash table is divided into limited space buckets, it bounds the CPU time (searching time), and bounds the memory space allocated [8]. Thus the attacker can’t exhaust the memory space or the CPU cycles of the SYN Cache enabled host. Therefore, these bounds protect the machine from being exhausted and crashed. Based on Lemon’s study [11], a SYN Cash entry is 160 bytes while a full TCB entry exceeds 730 bytes. Furthermore, 15359 entries in the hash table are supported. Also the study shows that connection latency only increased by 15% when a host is under attack. In addition, SYN Cache decreases the connection latency when the host is not under attack. SYN Cache enhanced the performance of the host when it is under attack, but still allocates memory for incoming connections. However, conducting the attack is still possible by

Note that at the end of the three-way handshaking, the host has to do heavy processing procedure; calculating the hash value and searching for matching. This processing procedure is triggered whenever a host receives an ACK segment, and if the attacker floods the victim with ACK segments, the host will be busy processing these segments and cannot serve other connections. The attacker then managed to consume the victims CPU cycles causing a DoS attack As discussed in section 3.4, Reflection attack floods the victim with reply messages, since ACK segment is a reply message, flooding the SYN Cash enabled host with ACK segments is possible using this type of attack.

4.4

SYN Cookies

Another type of defense against the SYN Flooding is SYN Cookies. The name ”Cookies” came from the web cookies which is a small piece of data used to keep state about the ongoing session [6]. SYN Cookies are used for the same reason: to keep some information about incoming connections. SYN Cookies are based on the same concept of the SYN Cache: postponing the information storing until the three-way handshaking completes. As discussed in section 4.3, SYN Cache stores a small amount of information about the incoming connections. However, SYN Cookies; stores zero state about all incoming connection [9], and delay the TCB creation and storing until the three-way handshaking completes. As shown in Figure 7,when a SYN Cookies enabled host receives a SYN segment, it calculates a cookie value based on the information of the received SYN segment (to be discussed later in this section), then it sends back a SYN-ACK segment containing the cookie value to the client. Finally, the host will receive an ACK segment containing the cookie value at which time the host recalculates the cookie value based on the information of the received ACK segment, and compares it with the cookie value contained in the same ACK segment. If there is a match, the connection is moved to TCB. Otherwise, the segment is discarded. Since the SYN-ACK segment is the second step of the threeway handshaking, it cannot carry data; hence, the connection establishment is not complete yet. Sending the cookie value in the SYN-ACK segment is the tricky part. One of the important things in the three-way handshaking is synchronizing the Initial Sequence Numbers (ISN) between the hosts [14]. Sequence numbers are chosen randomly by hosts, and since the host can choose any value as a sequence number, SYN Cookies technique uses the sequence number field in the segments to inject the cookie value which will be sent to the peer. As a result, the cookie will be a 32-bit number similar to the length of the sequence number.

Figure 7: SYN Cookies

A SYN Cookies enabled host must have a 32-bit local counter that increments with approximately 60 seconds, and it must have an eight predefined MSS values [2]. The eight MSS values are encoded to three bits, and the three bits will be part of the sequence number (cookie value). When a host receives a SYN segment with a MMS in it, the host chooses an approximated value for the MSS from one of the eight values.(the local counter will be discussed later). As discussed previously in section 4.3, the SYN Cache technique uses a hash function to calculate the index value. The same cryptographic method is used in SYN Cookies to calculate part of the cookie value. A SYN Cookies enabled host needs the following parameters to calculate the cookie value: IP addresses pairs, Port numbers pairs, 3-bit encoded MMS, least significant 5 bits of the counter value and a secret value [2]. First when a host receives a SYN segment, it begins the cookie calculation by getting IP addresses pairs, port number pairs and secret value, all concatenated together as an input to a hash function, then a hash value will be produced. ”MD5” hash algorithm is used to calculate the hash value [10]. MD5 produces a 128-bit hash as an output; only 3 bytes of the hash value are used in the cookie value. As shown in Figure 8, the least significant 5 bits of the local counter are inserted as the most significant bits of the ISN, followed by the 3-bit encoded MSS, and finally the 24 bits truncated from the hash value, resulting in a 32-bit ISN that represents the cookie value. When a host receives an ACK segment, this AKC segment contains an acknowledgment number that acknowledges the previous SYN-ACK segment. The ACK number means the number of the next expected byte, and since the SYN-ACK segment consumes one sequence number (considering the SYN-ACK segment as 1-byte data) [14], then the ACK segment will contain ACK number that equals the calculated ISN+1. Thus the cookie value of the received ACK segment is (ACK-number -1). If an ACK segment is received, a SYN Cookies enabled host first gets the ACK number and decrements it by one, then the host proceeds to calculate the cookie value using the same procedure explained above but this time the IP ad-

Figure 8: Cookie Calculation

dresses pairs and port number pairs are obtained from the ACK segment. If the calculated cookie value equals the (ACK number -1), then the connection is moved to TCB, Otherwise, the packet is discarded. Note that the server records the time of the last produced cookie using the local counter. If the returned cookie has been out for a while, the packet is rejected. This time is obtained by checking the most significant 5 bits of the cookie and the least significant bits of the counter. ”This expiry time is used to invalidate any out-of-date cookies may have a same value as another cookie at that moment. Also, due to the fact that the first 2 part of the handshaking (SYN and SYN-ACK) are not remembered, it is not possible for the server to resend lost SYN-ACK packets to the client” [10]. The secret value used in the hash prevents the attacker from obtaining the hash value, making the 24 bits of the cookie value secure since the attacker has to make 2ˆ 24 try to make the right guess. While SYN-Cache had a problem with MSS, SYN Cookies enhanced the connection by approximating the advertised MSS. Another advantage in SYN Cookies is consuming the memory resource is almost impossible since SYN Cookies store zero state for incoming connection. As discussed in Section 3.4, a reflection attack can cause DoS by consuming the CPU cycles. Suppose the attacker want to flood the victim with ACK segments using Reflection attack, thus consuming the victims CPU cycles by calculating hash values for the incoming ACKs. However, the attacker has to do extra work. He/She first must obtain the timer value and the MSS value. This is possible because the server returns these values explicitly in the cookie. Also the attacker has a timing problem because the flood of ACK segments must be done before the counter increments, or else all the segments will be discarded. The problems with SYN Cookies are mostly in the incompatibility with TCP options because SYN Cookies do not store any state for incoming connections which includes options of the incoming SYN segments. As a result, this affects the performance of the connection. Recent versions of SYN Cookies implementations partially solved the options problem (16). Recent versions of SYN Cookies uses ”Time Stamp” option to store some options information. Since the time stamp is echoed back, SYN Cookies can use the time stamp field bits to encode some option including window

size and SACK permitted options. By sending the encoded options in the time stamp field in the SYN-ACK segment, these values will be echoed back in the ACK segment, and by doing so, the host managed to keep these pieces of information. Using time stamp is a smart idea because SYN Cookies managed to store more information and still maintaining zero state during the three-way handshaking, and that is a very good enhancement to the connection [8, 9].

5. DISCUSSION Implementing the backlog queue method helped to bound the memory space allocated by any TCP dependent application. Thus, SYN Flooding attack only affects a running application that listens on a specific port number, which minimizes the scope of the problem, hence that machine crashing due to memory depletion is almost not considered any more when trying to deploy a defense mechanism. On the other hand, DDoS attack method made the problem much worse since DDoS attack method depends on distributing the attack flood, making the process of tracing back the attack nearly impossible to achieve. Furthermore, DDoS can create a huge amount of traffic since the attacker can recruit millions of compromised machines. Considering DDoS attack threats, many other issues should be considered before designing a defense method. For example, DDoS attack create a huge amount of traffic, thus the probability of congestion increases. Therefore, the designer must consider that legitimate clients connections could be delayed. That explains why reducing SYN-RECEIVED timer is no advisable. By considering the traffic caused by DDoS, it is also possible to detect the attack earlier since routers on the victim’s path can notice a sudden change on the amount of traffic choosing the same route, which is the victim’s route. Another way to take advantage of routers is by using them as proxies that can negotiate connections and filter them before forwarding them to the ultimate destination. Hybrid Approaches can also be used. For example, by using a large backlog queue with SYN Cookies, the host can operate normally without SYN Cookies defects, and SYN Cookies approach is enabled only when an attack appears. In another example, a SYN Cache can be used with SYN Cookies in which SYN Cache can operate normally benefiting from its high performance, and when there is no space in the cache table, instead of removing entries from the cache table, SYN Cookies can take the lead. For more details about SYN Cash and SYN Cookies as a hybrid approach see Lemon’s study [11].

6. CONCLUSION This paper covered different types of DoS attack including Direct Attack, Spoofed-Based attack, Distributed Attack (DDOS), and reflection attack. Different end-host countermeasures have been provided. However, deploying a defense only in the end host will not be enough..It is highly recommended to consider other network equipments in a secure defense such as routers which provide a great help in stopping and predicting attacks, especially against DDoS attacks. Some countermeasures, such as SYN Cache, require hash computation and searching that consumes CPU which add

a new threat to the host. Furthermore, Reflection Attack can be used to flood a victim with replies and keep him busy (consuming its CPU cycles). When comparing SYN Cookies with other types of defenses, it is found to be the best, since it stores zero state about the connection and less computations (compared to SYN Cache) is required to complete a connection. Furthermore, it is using timestamps to encode TCP options. All these advantages make SYN Cookies incomparable with other defenses. Hybrid approaches such as increasing backlog queue and SYN Cookies can also be used. A host can use the advantages of more than one type of defense, thus making the host more immune to SYN flooding attack.

7.

REFERENCES

[1] Denial-of-service attack. Web Document, January 2013. retrieved January 2013 (http://en.wikipedia.org/wiki/Denial-of-serviceattack). [2] D. J. Bernstein. Syn cookies. Web Document. retrieved January 2013 (http://cr.yp.to/syncookies.html). [3] M. Burdach. Hardening the tcp/ip stack to syn attacks. Web Document, November 2010. Published September 10, 2003; updated 2 November 2010, retrieved January 2013 (http://www.symantec.com/connect/articles/hardeningtcpip-stack-syn-attacks). [4] R. K. C. Chang. Defending against flooding-based distributed denial-of-service attacks: a tutorial. IEEE Communications Magazine, 40(10):42–51, 2002. [5] M. M. Charalampos Patrikakis and O. Zouraraki. Distributed denial of service attacks. Internet Protocol Journal., 7(4):13–35, July 2004. [6] L. M. D. Kristol. HTTP State Management Mechanism, 1997. [7] D. Danchev. Study finds the average price for renting a botnet. Web Document, May 2010. retrieved January 2013 (http://www.zdnet.com/blog/security/studyfinds-the-average-price-for-renting-a-botnet/6528). [8] W. Eddy. TCP SYN Flooding Attacks and Common Mitigations, 2008. Updated by RFCs 1122, 3168. [9] W. M. Eddy. Defenses against tcp syn flooding attacks. Internet Protocol Journal., 9(4):2–16, December 2006. [10] S. F. LEE. Analysis on some defences against syn-flood based denial-of-service attacks. Computer Science Department, University of Auckland. [11] J. Lemon. Resisting syn flood dos attacks with a syn cache. In Proceedings of the BSD Conference 2002 on BSD Conference, BSDC’02, pages 10–10, Berkeley, CA, USA, 2002. USENIX Association. [12] S. Lin and T. cker Chiueh. A survey on solutions to distributed denial of service attacks contents. [13] C. N. Maregeli. A study on tcp syn attacks and their effects on a network infrastructure. Master’s thesis, Delft University of Technology, June 2010. [14] J. Postel. Transmission Control Protocol, Sept. 1981. Updated by RFCs 1122, 3168. [15] W. R. Stevens. UNIX Network Programming:The Socket Networking API. Pearson Education, Inc., 3rd edition, 2004.