International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 3, May June 2013 ISSN 2278-6856

PREVENTION OF SYN FLOOD DOS ATTACK

1

Sanjyoti Tarai, 2Khaleel Ahmad, 3Jayant Sekhar

1,2&3

Deptt of CSE/IT, SITE, SVSU, India

Abstract: The main aim of this paper was to analyze current

Distributed Denial of Service botnets, malware and taxonomies to determine the best prototype to design and develop that could detect and mitigate an attack on a server. A human verification prototype was developed and implemented that would require user input to validate the visitor to a site was a real person. This system would only trigger if the visitor sent too many requests for the site per minute. If the visitor failed to validate, the system firewalls their IP address. This thesis and prototype, although slightly inefficient at high load levels, could potentially help to mitigate a medium-scale DDoS attack on a website. The prototype does indeed detect a user that exceeds the threshold set, and it does then forward them on for verification. The prototype also then creates entries that simulate the IP address of that user being blocked at a firewall level. However, the prototype fails to appreciate any false positives that may occur. If a user was to exceed the threshold and then fail validation, their IP address would be firewalled on the server permanently (or until an Administrator flushed the firewall).

designed to destroy or corrupt data to technologically advanced robot networks with intelligent coding that allows them to intercommunicate with each other, and send back captured private data like bank account numbers and credit card details to the owner of the malware (Hoeflin, D. etal. 2007). This paper is divided into four Sections. In the Section-I the description of the synflood is mentioned, Section-II contains the design part of the prototype, Section-III describes the consideration of the design, Section-IV concludes the paper and the future work is suggested.

Index Terms Prevention.

DoS,

DDoS,

Network

Security,

1.1 INTRODUCTION
A Denial of Service (DoS) attack is an attack which attempts `to prevent the victim from being able to use all or part of their network connection. A denial of service attack may target a user, to prevent them from making outgoing connections on the network[1]. Denial of service attacks are much easier to accomplish than remotely gaining administrative access to a target system. Because of this, denial of service attacks have become very common on the Internet. IT Administrators are constantly faced with threats as a result of the Internet (West,M.2008). They can be responsible for a plethora of different services and resources on a network at any one time and the challenges involved in ensuring service availability are vast (Franklin, J. et al. 2007). As a result, these Administrators rely on specialized hardware and software to combat attacks from external sources. There is a huge range of solutions on the market today to assist and defend against such attacks, but they are either costly or complicated to set up and configure properly. One of the major problems is that the Internet protocol is designed to be as lightweight as possible, meaning security considerations are usually an afterthought, and usually too late[1][2]. The assaults circulating on the Internet at this very moment range from malicious viruses Volume 2, Issue 3 May June 2013

Fig1: General view of DoS Attack 1.1 SYN Flood Attack A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system[13]. Several connections set by the attacker are half-open without proper acknowledgments, the server queue gets full and another client can not connect. In computer security, a denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended users. SYN (synchronize) is a type of packet used by the Transmission Control Protocol (TCP) when initiating a new connection to synchronize the sequence numbers on two connecting computers[9].When a client attempts to start a TCP connection to a server, the client and server exchange a series of messages which normally runs like this: The Transmission Control Protocol (TCP) is a virtual circuit protocol that is one of the core protocols of the Internet protocol suite, often simply referred to as TCP/IP. Using Page 377

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 3, May June 2013 ISSN 2278-6856
TCP, applications on networked hosts can create connections to one another, over which they can exchange streams of data[7]. 1.2. Transmission Control Protocol (TCP) The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite[14]. TCP is one of the two original components of the suite (the other being Internet Protocol, or IP), so the entire suite is commonly referred to as TCP/IP [1]. IP performs actual delivery of data via internet, whereas TCP concerns only the data packets. TCP connection between the two end computers is established by three-way handshake mechanism. The three-way handshake mechanism is below[8]. Figure 2 TCP Three-way Handshake Step1. Client A sends a SYN packet to Client B Step2.Client B sends a SYN/ACK packet to Client A Step3. Client A sends a ACK packet to Client B 1.3. TCP SYN Flood Attack TCP SYN Flood attack uses the three-way handshake mechanism. At the first of the attack client A, an attacker, sends a SYN packet to client B. Then client B sends a SYN/ACK packet to client A. As a normal three-way handshake mechanism client A should send an ACK packet to client B, however, client A does not send an ACK packet to client B. In this case client B is waiting for an ACK packet from client A[12]. This status of client B is called half open. This kind of incomplete connection is stored in Backlog Queue. After 75 seconds the incomplete connection is removed from Backlog Queue and it is disconnected[14]. However, if client A sends lots of SYN packets before client B removes incomplete connections from Backlog Queue, then Backlog Queue in client B is overflowed. In this case client B cannot accept TCP connection at all. This is called Denial-of-Service, and this type of attack is TCP SYN Flood Attack[12]. 1.4 Basic Vulnerability this handshake, the third packet verifies the initiator's ability to receive packets at the IP address it used as the source in its initial request, or its return reachability. Figure 1 shows the sequence of packets exchanged at the beginning of a normal TCP connection[8].

Figure 2: Normal TCP 3-Way Handshake The Transmission Control Block (TCB) is a transport protocol data structure (actually a set of structures in many operations systems) that holds all the information about a connection. The memory footprint of a single TCB depends on what TCP options and other features an implementation provides and has enabled for a connection. Usually, each TCB exceeds at least 280 bytes, and in some operating systems currently takes more than 1300 bytes. The TCP SYN-RECEIVED state is used to indicate that the connection is only half open, and that the legitimacy of the request is still in question. The important aspect to note is that the TCB is allocated based on reception of the SYN packet before the connection is fully established or the initiator's return reachability has been verified[14]. This situation leads to a clear potential DoS attack where incoming SYNs cause the allocation of so many TCBs that a host's kernel memory is exhausted[7]. In order to avoid this memory exhaustion, operating systems generally associate a "backlog" parameter with a listening socket that sets a cap on the number of TCBs simultaneously in the SYN-RECEIVED state. Although this action protects a host's available memory resource from attack, the backlog itself represents another (smaller) resource vulnerable to attack. With no room left in the backlog, it is impossible to service new connection requests until some TCBs can be reaped or otherwise removed from the SYN-RECEIVED state. Depleting the backlog is the goal of the TCP SYN flooding attack, which attempts to send enough SYN segments to fill the entire backlog. The attacker uses source IP addresses in the SYNs that are not likely to trigger any response that would free the TCBs from the SYN-RECEIVED state. Because TCP attempts to be reliable, the target host keeps its TCBs stuck in SYN-RECEIVED for a relatively long time before
Page 378

The SYN flooding attack became well-known in 1996, when the magazines 2600 and Phrack published descriptions of the attack along with source code to perform it[11] . This information was quickly used in attacks on an Internet service provider's (ISP's) mail and Telnet servers, causing outages that were widely publicized in The Washington Post and The Wall Street Journal (among other venues). CERT quickly released an advisory on the attack technique[10]. The basis of the SYN flooding attack lies in the design of the 3-way handshake that begins a TCP connection[3]. In Volume 2, Issue 3 May June 2013

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 3, May June 2013 ISSN 2278-6856
giving up on the half connection and reaping them. In the meantime, service is denied to the application process on the listener for legitimate new TCP connection initiation requests. Figure 2 presents a simplification of the sequence of events involved in a TCP SYN flooding attack[8].
Step12.Check whether this IP attempted Captcha more than X times. Step13.Then add IP address to IP Tables Deny List. Step14.Else Get Recaptcha box and requst visitor confirm they are real person. Step15.Else process request and send website content back. Step16.Instantiate Client list by 1.

2. Design
To develop a working prototype that detects and mitigates HTTP based DDoS attacks, there must be adequate design of a system before it can be implemented. The system was designed so that it could be deployed in a Distributed environment (that is, the CAPTCHA part need not be on the same physical server)[13]. The system also integrates directly with Apache making deployment of the Detection module (Mitigate.c) exceptionally easy for any novice IT administrator to set up. The problem scenario is when too many hosts (or compromised computers) request the website at the same time. The server cannot cope with the requests and service availability is affected. Figure 3.1 shows a basic overview of the network topology used in the prototype system. The system detects when an individual host has requested a website too many times and then requires that host to verify they are a human. Certain exceptions to this rule exist (for example, Search Engines are exempt from having to verify at all and are always given access to the site without hindrance).

Figure 2.2: Overview of the prototype

Fig 2.2 represents the overview of prototype in which A represents Visitor, B represents Apache Server, C represents Mitigate module, D represents Captcha Module. Algorithm 2.1 represents the whole Captcha system whether the IP address is allowed or not. 2.3 Apache Module The Apache Web Server will be used to serve web page requests for the prototype. The server allows for custom modules to be included, and a basic module for detecting a possible DDoS attack and then mitigating it will be developed. The module will detect the number of times a user has requested the web page in a given time[2]. Figure 3.4 shows a more detailed view of how the three components interact with one another. The apache web server runs with the module compiled. Whenever a user visits a website hosted on the Apache web server, the Mitigate.c (once compiled, becomes mitigate. so) module is called .The module should have the ability to define an allowed. Hosts file for known IPs we do not want to challenge with the captcha.php module. The module should also have the ability to send a user to another server to process the captcha.php module (saving resources on the primary server until the user has been confirmed as human). The module should have a variable that can be changed which defines the requests per minute that an IP address can send to the server before triggering the captcha.php module. When the limit for number of access requests per minute is exceeded, the module should forward the user to the captcha.php module for verification of the user making the request. If verified, the captcha.php module will send back a confirmation to the mitigate module, if not then the user will be presented with the CAPTCHA page again and again (until the captcha.php limit is exceeded).

Figure 2.1: Overview of the network topology 2.1 System overview All compromised machines are automated attacks, therefore using a method that checks whether a request originated from a real human being should help to deny the attack. The system will determine whether an IP address has requested a page too many times in a given limit[3]. 2.2 ALGORITHM FOR CAPTCHA SYSTEM Step 1.Visitors sends GET request to server Step2.Is IP allowed in the list? Step3.If Yes Step4. Then Process request and send website content back Step5.Else Read client List Step6.Has this IP sent GET request more than X times in the Last Y seconds? Step7.Then GET recaptcha bax and request visitor confirm they are real person. Step8.Does user get captcha input correct? Step9.Then add user to allow list and purge other lists. Step10.Process request and send website content back. Step11.Else Instantiate Captcha list for IP by 1. Volume 2, Issue 3 May June 2013

Page 379

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 3, May June 2013 ISSN 2278-6856 3.1Design Considerations
One of the drawbacks of using this system is the problems we are faced with as a result of human error, understanding, or general willingness to actually complete the CAPTCHA form correctly. It may be that as a result of a person being asked to fill in the CAPTCHA form after so many attempts that they decide to simply leave the website altogether, causing a drop in visitor numbers. If the website utilizing the CAPTCHA Solution is on an ecommerce site for example, this could have a severely negative impact on the organizations sales.Another problem that needs to be addressed is the ability of the user to actually see the text. If the user is blind and using special accessibility software to allow them to visit websites using other methods, normally a CAPTCHA could prevent them going any further. Thankfully, ReCAPTCHA offer support for people with visual disabilities in the form of audio clips. This presents the user with an audible sentence to type in and complete the verification process. One of the problems with using a human verification system is when activated a search engine spider like GoogleBot will not be able to access the website. This will have a dramatic effect on the websites search engine ranking. To resolve this problem, it would be easy to simply create a list that contains all the IP addresses that should never be subjected to a human verification check. Using Google as an example search engine, it became apparent that this method would not work. As it transpires, Google simply do not publish a list of IP addresses associated with their spiders; and for good reasons. They may wish to change their IP addresses in future, or add new IP addresses to the list. Publishing a list would require constant updating, and this is simply not a feasible option. It is imperative that a method of allowing these search engines unrestricted access to the server so as to preserve the website ranking, so an alternative method must be designed. The simple method chosen is to do a few DNS tests on the IP address. All of Googles search spiders have a DNS entry corresponding to the googlebot.com domain name, Figure 3.6 shows this. It is not enough to simply have a reverse DNS check (i.e. checking what domain the IP address points to) as is it simple for a spoofer to just create an A record for the IP address. Instead, a forward lookup (i.e. checking what IP address the domain points to) will guarantee the validity of the search engine (as only the owner of the domain can point the record to an IP address) (Anon., 2006.How to verify Googlebot).To summarize, when the request is received by the server, the server should do a check to see if the associated DNS entry is in an allowed. Hostnames file. This way, all known search engines that comply with reverse DNS, will always be allowed through the system without being stopped by the CAPTCHA system. A downside to this is that for every request a lot of system resources are used; reading the IP address, checking the DNS, reading the allowed. hostnames file, etc.

Figure 2.3: UML Diagram of Apache Module calls 2.4 PHP Module Once the request has been handed from the mitigate.c module to the PHP module, it is the PHP modules responsibility to determine whether or not the request was made by a human or an automated robot. The PHP module makes use of the ReCAPTCHA Project, a free, hosted CAPTCHA service which the owners claim process over 30 million CAPTCHA requests a day. The PHP module should create a variable which holds the number of attempts the user has taken. It should also have a variable which holds the maximum number of attempts the user is allowed. If the user exceeds the threshold of this limit, the IP address they are using will be denied using iptables. If the request is processed correctly by the user, the Captcha.php module should send back this result to the mitigate.c Apache module so that it may add the IP address to the allowed list of hosts. As a result of this inclusion the user will never be required to verify themselves again whilst using that web server (or until the list is purged by an administrator). Figure 2.4 shows the process as described previously of the Captcha.php system. It needs to be established how the DENY will be added to the IPTABLES firewall rules, as PHP normally runs under the web server user (either nobody or apache) and therefore would not normally have permission to configure the firewall in Linux. As this is a prototype, a workaround was used was to simply deny access using .htaccess file. This will deny the user access to the requested website, but will not deny them access to the server. In a real world situation, this is of no real use, but is useful as verification that the prototype is working as designed.To make designing and implementing the system speedier, the ReCAPTCHA Project have readily available libraries for us to use which lets us call the CAPTCHA and process the requests without having to code a great deal.

Figure 3.4: UML Diagram of Captcha Module Volume 2, Issue 3 May June 2013 Page 380

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 3, May June 2013 ISSN 2278-6856 4 Conclusions & future Work
This paper shows successful development of a working prototype that detects and mitigates a web-based (or HTTP-based) DDoS attack. The prototype was tested and confirmed to be working well at a low load. The aim of evaluating and testing the prototype to determine the effectiveness of it has not been achieved. The prototype shows signs of resource use at low levels (i.e. when 40 hosts are requesting a page at the same time). In a real world situation, the expected number of hosts requesting a page per minute can be in excess of 100,000. In a situation like this, the prototype would fail. It could be argued that although the prototype does not work, the evaluation does show a true likeness to what would happen should a true DDoS attack be inflicted on the prototype, and how it would perform during such an attack. The prototype does however work as an integrated system on one server. The deployment of the modules is simple and highly configurable. It should be noted that the prototype does not currently add to any Linux firewall IPTABLES, but only creates a deny in the .htaccess file. This would be a recommendation of future work with the prototype. It would be beneficial to be able to create a form of handler that could take the output from PHP and create rules on a Linux firewall (or even a gateway routerfirewall) so that actual packet dropping could occur. [9] Distributed

Denail Of Service Prevention Techniques(April 2010). [10] A Taxonomy of DDoS Attacks and DDoS Defence Mechanisms. [11] New Mitigating Technique to overcome DDoS attack(2008). [12] A study on Tcp-Syn Attacks and their effects on a Network Infrastructure(June 2010). [13] Multifaceted Defense Against Distributed Denial Of Service Attacks:Prevention,Detection,Mitigation(2012). [14] TCP connection Management Mechanisms for Improving Internet Server Performance(2005).

References:
[1] CERT. (2001, June 4). Denial of Service. Retrieved November 19, 2009 from http://www.cert.org/tech_tips/denial_of_service.html [2] Lee, R., & Speecht, S. (2004). Distributed Denial of Service: Taxonomies of Attacks, Tools and Countermeasures [3] Defenses Against Distributed Denial of Service Attacks. Retrieved 10 March, 2011 from http://www.garykessler.net/library/ddos.html [4] Leyden, J. (2004, September 23). US credit card firm fights DDoS attack. Retrieved 20 September, 2009 from http://www.theregister.co.uk/2004/09/23/authorize_d dos_attack/ [5] Labovitz, C. (2009, August 6). Where Did All the Tweets Go? Retrieved 5th April, 2011 from http://asert.arbornetworks.com/2009/08/where-didall-the-tweets-go/ [6] StackPi:Anew Defense Mehanism against IP

spoofing and DDoS Attacks(20, December 2002). [7] Network Bandwidth Denial Of Service(DoS)(2005). [8] Analyzing Interaction Between Denial Of Service(DoS)Attacks and Threats(2009).

Volume 2, Issue 3 May June 2013

Page 381