THROTTLING DDoS ATTACKS USING INTEGER FACTORIZATION AND ITS SUBSTANTIATION USING ENHANCED WEB STRESS TOOL

Transcription

1 THROTTLING DDoS ATTACKS USING INTEGER FACTORIZATION AND ITS SUBSTANTIATION USING ENHANCED WEB STRESS TOOL Thesis Submitted in partial fulfillment of the requirements for the degree of MASTER OF TECHNOLOGY in COMPUTER SCIENCE & ENGINEERING - INFORMATION SECURITY by SYED TAQI ALI (07IS10F) DEPARTMENT OF COMPUTER ENGINEERING NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA SURATHKAL, MANGALORE JULY, 2009

2 Dedicated To My Mother

3 D E C L A R A T I O N I hereby declare that the Report of the P.G Project Work entitled "THROTTLING DDoS ATTACKS USING INTEGER FACTORIZATION AND ITS SUBSTANTIATION USING ENHANCED WEB STRESS TOOL" which is being submitted to the National Institute of Technology Karnataka Surathkal, in partial fulfillment of the requirements for the award of the Degree of Master of Technology in COMPUTER SCIENCE AND ENGINEERING INFORMATION SECURITY in the Department of Computer Engineering, is a bonafide report of the work carried out by me. The material contained in this report has not been submitted to any University or Institution for the award of any degree.. (Register Number, Name & Signature of the Student) Department of Computer Engineering. Place: NITK, SURATHKAL Date:...

4 C E R T I F I C A T E This is to certify that the P.G Project Work Report entitled "THROTTLING DDoS ATTACKS USING INTEGER FACTORIZATION AND ITS SUBSTANTIATION USING ENHANCED WEB STRESS TOOL" submitted by SYED TAQI ALI (Register Number: 07IS10F), as the record of the work carried out by him, is accepted as the P.G. Project Work Report submission in partial fulfillment of the requirements for the award of the Degree of Master of Technology in COMPUTER SCIENCE AND ENGINEERING INFORMATION SECURITY in the Department of Computer Engineering. External Guide (Name and Signature with date and seal). Internal Guide (Name and Signature with date and seal).. Chairman DPGC (Signature with Date and Seal)

5 ACKNOWLEDGEMENTS I take this opportunity to express my deepest gratitude and appreciation to all those people who made this project work easier with words of encouragement, motivation, discipline, and faith by offering different places to look to expand my ideas and helped me towards the successful completion of this project work. First and foremost, I would like to express my sincere gratitude to my guide Mr. Radesh Mohandas, Adjunct faculty, and Mr. Alwyn Roshan Pais, Sr. Lecturer, Department of Computer Engineering, National Institute of Technology Karnataka, Surathkal for their insightful advice, motivating suggestions, invaluable guidance, help and support in successful completion of this project and also for his constant encouragement and advice throughout my M.Tech programme. I express my deep gratitude to Mr. K. Vinay Kumar, Asst. Professor and Head, Department of Computer Engineering, National Institute of Technology Karnataka, Surathkal for their constant co-operation, support and for providing necessary facilities throughout the M.Tech programme. I would like to thank the Department of Information Technology, Govt. of INDIA for offering Information Security as M.Tech specialization under ISEA project. I would like to take this opportunity to express my thanks to the teaching and non teaching staff in Department of Computer Engineering, NITK for their invaluable help and support in these two years of my study. I am also grateful to all my classmates specially Mr. Sandip patil, for their help, encouragement and invaluable suggestions. Finally, I would like to thank all whose direct and indirect support helped me completing my thesis in time. Date: S. TAQI ALI i

6 ABSTRACT Distributed Denial of Service (DDoS) Attack is a threat to the Internet today. In these attacks, an attacker runs a malicious process in compromised systems under his control and generates enormous number of requests, which in turn can easily exhaust the computing resources of a victim web server within a short period of time. Many mechanisms have been proposed till date to combat this attack. In this thesis we propose a new solution to reduce the impact of a DDoS attack on a web server by throttling the client s CPU. The concept of source throttling is used to make the client pay a resource stamp fee, which is negligible when the client is making a limited number of requests but becomes a limiting restriction when he is making a large number of requests. The proposed solution makes use of the integer factorization problem to generate the CPU stamps. We have packaged our solution as an API so that existing web applications can easily deploy our solution. DDoS attacks have become a major threat to web servers. Hence there is a need to test a website for various vulnerabilities that can lead to various exploitations before deployment. Application specific solutions need to be built. To test such solutions and various research concepts, good commercial tools are not available to the research community. Existing open source tools do not scale well to simulate the required loads nor have traffic shaping features. Free tools are not scriptable to tune to the application. I have developed a high performance web stress tool which is extensible in response to the needs of a research community. Keywords: Source throttling, Distributed denial of service, Integer factorization, CPU stamps, request stamping, HTTPattack Tool, Webserver, Web Stress Tool, Open Source Tool. ii

7 CONTENTS ABSTRACT.ii List of Figures...vi List of Tables..viii Nomenclature...ix 1. INTRODUCTION DoS and DDoS Attacks...1 What is DDoS Attack?...2 Symptoms of DoS Attack Prime Number Integer Factorization Web Server Benchmarking And Threshold Value Web Stress Tools LITERATURE SURVEY Types of DoS and DDoS Attacks Bandwidth Depletion Attacks Resource Depletion Attacks DoS Countermeasures...17 Reducing IP Spoofed Packets...17 SYN Cookies...18 SYN Cache...19 Prevention of Ad hoc flooding attack DDoS Countermeasures Taxonomy of DDoS Countermeasures...21 iii

8 2.3.2 Detecting a DDoS attack by analyzing client response pattern Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks A novel approach to detecting DDoS attacks at an early stage Methods Of Integer Factorization...29 Trial Division Method...29 Pollard p-1 Factorization Method...30 Euler s Factorization Method...30 Shor's algorithm Web Stress Tools...30 Shareware/Proprietary Tools Webserver Stress Tool HP LoadRunner software NeoLoad Load Testing Tool WebLoad Load Generation Engine...35 Freeware Tools Microsoft WAS Tool...37 Open Source Tools Apache JMeter FWPTT - Fast Web Performance Test Tool JCrawler Stress Testing Tool Curl-loader PROBLEM DESCRIPTION Need Of DDoS Countermeasure Need Of Web Stress Tool PROPOSED SOLUTION...45 iv

9 4.1 Throttling DDoS Attacks Using Integer Factorization...45 Description...45 Countermeasures Against The Throttling...46 Methodology...47 Application...49 Implementation Results HTTPattack: An Open Source Web Stress Tool...55 Tool Description...55 Features...56 Implementation Results CONCLUSION Conclusion Scope of Future Work...64 BIBLOGRAPHY...65 BIO-DATA..68 v

10 List of Figures Figure 1.1: DoS Attack... 1 Figure 1.2: DDoS Attack... 2 Figure 2.1: Amplification attack... 7 Figure 2.2: Ad hoc flooding attack... 9 Figure 2.3: Resource Starvation after clicking html file Figure 2.4: IP Fragmentation Figure 2.5: IP Fragments overlapping Figure 2.7: Leaving connections half open by sending multiple SYN requests without replying to SYN, ACK Figure 2.6: TCP SYN Attack Figure 2.8: TCP Connection establishment with SYN Cookies Figure 2.9: Ad Hoc Neighbour nodes isolate attack Figure 2.10: DDoS Countermeasure Taxonomy Figure 2.11: DDoS Agent-Handler Model Figure 2.12: The simple algorithm Figure 2.13: Client Puzzle Protocol when server is under attack Figure 2.14: Result of a ramp test with 400 users using Webserver Stress Tool Figure 2.15: Tests using the URL script feature in Webserver Stress Tool Figure 2.16: HP LoadRunner Virtual User Generator Figure 2.17: NeoLoad Infrastructure vi

11 Figure 2.18: NeoLoad Tool Screenshot Figure 2.19: WebLoad Tool Screenshot Figure 2.20: WAS Tool Screenshot Figure 2.21: WAS Tool Cookies Screenshot Figure 2.22: Apache JMeter with 10 HTTP URLs Figure 2.23: FWPTT Screenshot Figure 2.24: JCrawler Configuration Screenshot Figure 2.25: Curl-loader Configuration File Screenshot Figure 4.1: Graph Overhead on requests/sec with fixed N Figure 4.2: Graph Server load relief Figure 4.3: Graph Max client requests/sec Vs Number of digits in N Figure 4.4: Graph Overhead at server when p is generated dynamically Figure 4.5: Graph Overhead at server when p and q are dynamic Figure 4.6: Graph Overhead on number of rps with p and q generated dynamically.. 54 Figure 4.7: Tests on dynamic web pages with HTTPattack Tool Figure 4.8: Screenshot Testing Throttling DDoS Solution with HTTPattack Tool Figure 4.9: HTTPattack Tool with all feature enabled Figure 4.10: HTTPattack Tool with zoomed graph vii

12 List of Tables Table 4.1: Number of primes in each digit Table 4.2: Latency in milliseconds of browsers to calculate factors Table 4.3: Tool Comparision Table viii

13 Nomenclature Notation DoS DDoS IP UDP USCERT ICMP RREQ RREP ADOV MTU Description Denial of Service Distributed Denial of Service Internet Protocol User Datagram Protocol United States Computer Emergency Readiness Team Internet Control Message Protocol Route Request Route Reply Ad hoc On-Demand Distance Vector Maximum Transfer Unit TCP Transmission Control Protocol TCB Transmission Control Block SYN Synchronize MIB Management Information Base rps Request per second URL Uniform Resource Locator CCB Custom Command Line Browser built using C# N An integer and a product of two primes p, q Prime factors of N Ndigits pdigits qdigits MSDN Number of digits in n Number of digits in p Number of digits in q Microsoft Developer Network ix

14 CHAPTER 1 INTRODUCTION A website is a collection of related web pages, images, videos or other digital assets that are hosted on one web server, usually accessible via the Internet. Most websites are publicly available. A single web server may contain one or more websites. Normally user will access these websites through browser (either IE or Mozilla or Chrome or Netscape navigator, etc). 1.1 DoS and DDoS Attacks A Denial of Service (DoS) attack is an attack with the purpose of preventing legitimate users from using a victim computing system or network resource. In DoS attack, attacker will send enormous number of requests to the victim machine. Figure 1.1 DoS Attack In this Figure 1.1 system A is a legitimate user and X is an attacker who is sending enormous number of request to bring down the server B, so that legitimate user A is unable to utilize the services of the server. 1

15 What is DDoS Attack? There are several threats to websites. One of them is Distributed Denial of Service (DDoS) attack. DDoS attack is an attack where multiple compromised systems are used to target a single system causing a DoS attack. Victims of DDoS attack consists of not only targeted system but also all compromised systems maliciously used and controlled by the hacker in the attack. The end targeted system is called a primary victim and the compromised systems are called secondary victims. The use of secondary victims in DDOS attack provides the attackers with the ability to introduce a much larger and more disruptive attack. Figure 1.2 DDoS Attack In this Figure 1.2 Attacker/s has compromised the several systems by installing his malicious program in the systems. When the attacker sends command to these systems, they will start sending enormous number of requests to the victim machine which brings victim machine down and it is no more available for a legitimate user. In modern web application, when the web client makes a request it takes a little effort to compose it, but causes the server to process a lots of data and compose the response. This variation in computation efforts between the server and the client makes the DDoS attack successful. 2

16 Symptoms of DoS Attack The USCERT defines symptoms of DoS attacks: Unusually slow network performance (opening files or accessing web sites) Unavailability of a particular web site Inability to access any web site Dramatic increase in the number of spam s received. The services that result from malicious activity are also denial-of-service attacks. DoS attacks can also lead to problems in the network branches around the actual computer being attacked. For example, the bandwidth of a router between the Internet and a LAN may be consumed by DoS, compromising not only the intended computer, but also the entire network. 1.2 Prime Number There are two types of natural numbers: primes and composites [1]. Prime numbers are integers greater than or equal to 2 that are only divisible by 1 and the number itself. Thus the first few prime numbers are 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, etc. Two is the only even prime number, since any bigger even number is divisible by 2. Therefore, the term odd prime refers to any prime number greater than 2. To know whether the given number is prime or not, we need to perform one of the primality tests on it. 1.3 Integer Factorization Factoring is the act of splitting an integer into a set of smaller integers (factors) which, when multiplied together, form the original integer. For example, the factors of 403 are 13 and 31; the factoring problem is to find 13 and 31 when given 403. Prime factorization requires splitting an integer into factors that are prime numbers; every integer has a unique prime factorization. Multiplying two prime integers together is easy, but factoring the product is much difficult. No good algorithms exist to solve this problem in polynomial time and the best algorithm which solves this problem 3

17 with least complexity is general number field sieve in O(exp((64/9b) 1/3.(log b) 2/3 )) for a b-bit integer. For a quantum computer it takes O(b 3 ) by using Shor s algorithm. 1.4 Web Server Benchmarking and Threshold Value Web server benchmarking is the process of estimating a web server performance in order to find whether the server can serve sufficiently high workload or not. The performance is usually measured in terms of: Number of requests that can be served per second (depending on the type of request, etc.); Latency response time in milliseconds for each new connection or request; Throughput in bytes per second (depending on file size, cached or not cached content, available network bandwidth, etc.). The measurements must be performed under a varying load of clients and requests per client. The threshold value is the number of requests that a server can handle without straining its resources. It is defined as a predetermined percentage of the maximum number of requests that a server can handle. 1.5 Web Stress Tools Web Stress Tools are the tools which are used to measure the performance of Web Server. These tools simulate the number of clients accessing the website simultaneously in a given instant of time. With this we can estimate the web server threshold that is, how many requests that the server can handle per second. Web Stress Tool ensures that critical issues in the website are resolved before they bring down the web resources. 4

18 CHAPTER 2 LITERATURE SURVEY 2.1 Types of DoS and DDoS Attacks There are basically two types of DoS and DDoS attacks namely Bandwidth depletion attacks and Resource depletion attacks. These are discussed in this section Bandwidth Depletion Attacks Bandwidth depletion attack [2] is designed to flood the victim network with unwanted traffic that prevents legitimate traffic from reaching primary victim system. There are two main types of bandwidth depletion attacks. First one is flood attack which involves the secondary victim systems for sending large volumes of traffic to a victim system, to congest the victim system s bandwidth. Second one is amplification attack which involves either the attacker s or the secondary victim system s sending messages to a broadcast IP address, using this to cause all systems in the subnet reached by the broadcast address to send a message to the victim system. This method amplifies malicious traffic that reduces the victim system s bandwidth. Flood Attacks In a DDoS flood attack the secondary victim systems flood the primary victim system with IP traffic. The large volume of packets sent by the secondary victim systems to the victim system slows it down, crashes the system or saturates the network bandwidth. This prevents legitimate users from accessing the primary victim system. There are various types of flood attacks namely UDP Flood attack and ICMP Flood attack, which are discussed below. UDP Flood Attacks User Datagram Protocol (UDP) is a connectionless protocol. When data packets are sent via UDP, handshaking is not required between sender and receiver, and the receiving system will just receive packets it must process. A large number of UDP 5

19 packets sent to a victim system can saturate the network by depleting the bandwidth available for legitimate service requests to the victim system. A DDoS UDP Flood attack occurs when the UDP packets are sent to either random or specified ports on the victim system. Typically, UDP flood attacks are designed to attack random victim ports. This helps the victim system to process the incoming data and to determine which applications have requested data. If the victim system is not running any applications on the targeted port, then the victim system will send out an ICMP packet to the sending system indicating a destination port unreachable message. ICMP Flood Attacks Internet Control Message Protocol (ICMP) packets are designed for network management features such as locating network equipment and determining the number of hops or round-trip-time to get from the source location to the destination. For instance, ICMP_ECHO_REPLY packets ( ping ) allow the user to send a request to a destination system and receive a response with the roundtrip time. A DDoS ICMP flood attack occurs when the zombies (secondary victim) send large volumes of ICMP_ECHO_REPLY packets to the victim system. These packets signal the victim system to reply and the combination of traffic saturates the bandwidth of the victim s network connection. Amplification Attacks A DDoS amplification attack [2] is aimed at using the broadcast IP address feature found on most routers to amplify and reflect the attack. Amplification attack is shown in Figure 2.1. This feature allows a sending system to specify a broadcast IP address as the destination address rather than a specific address and source address as spoofed target IP. This instructs the routers servicing the packets within the network to send them to all the IP addresses within the broadcast address range. There are three types of amplification attacks such as smurf attack, fraggle attack and Ad-Hoc Flooding attack. 6

20 Figure 2.1 Amplification attack Smurf Attack Smurf attack is a DDoS attack in which the attacker sends packets to a network amplifier, with the return address spoofed to the victim s IP address. The attacking packets are typically ICMP ECHO REQUESTs, which are packets ( ping ) that request the receiver to generate an ICMP ECHO REPLY packet. The amplifier sends the ICMP ECHO REQUEST packets to all of the systems within the broadcast address range, and each of these systems will return an ICMP ECHO REPLY to the target victim s IP address. The smurf attack amplifies the original packet tens or hundreds of times so that the attack can be done very easily. Fraggle Attack A DDoS Fraggle attack is similar to a Smurf attack but Fraggle uses UDP ECHO packets instead of ICMP ECHO packets. The UDP ECHO packets are sent to the port that supports character generation, with the return address spoofed to the victim s echo service creating an infinite loop. The UDP Fraggle packet will target the character generator in the systems reached by the broadcast address. These systems each generate a character to send to the echo service in the victim system, which will resend an echo packet back to the character generator, and the process repeats. This 7

21 attack generates even more bad traffic and can create even more damaging effects than the Smurf attack. Ad-Hoc Flooding Attack Mobile Ad-Hoc Network is an autonomous system of mobile nodes connected by wireless links. Each node operates not only as an end-system, but also as a router to forward packets. The mobile Ad-Hoc networks have several salient characteristics such as Dynamic topologies, Bandwidth-constrained, variable capacity links, Energyconstrained operation, Limited physical security. When a source node needs to send packets to a destination node to which it has no available route, then it broadcasts a RREQ (Route Request) packet to its neighbours. AODV protocol [7] adopts some methods to reduce the congestion in a network. A node cannot originate more than RREQ_RATELIMIT RREQ messages per second. After broadcasting a RREQ, a node waits for a RREP (Route Reply). If a route is not received within round-trip milliseconds, the node may try again to discover a route by broadcasting another RREQ. In the Ad-Hoc Flooding Attack [5], the attack node violates the above rules to exhaust the network resource. Firstly, the attacker selects many IP addresses, which are not in the networks if he knows the scope of IP address in the networks. Because no node can answer RREP packets for these RREQ, the reverse route in the route table of node will be protected for longer. The attacker tries to send excessive RREQ without considering RREQ_RATELIMIT per second. In the following Figure 2.2, Node H is attacker and it floods mass RREQ packets all over the networks so that the other nodes cannot build paths with each other. 8

22 Figure 2.2 Ad hoc flooding attack Resource Depletion Attacks In DDoS resource depletion attacks [2] the attacker sends a malformed packet that ties up the network resources or exhausts the system resources, so that no resources are left for legitimate users. There are several types of resource depletion attacks, they are system resource starvation attacks, buffer overflow attacks, teardrop attack, land attack and protocol exploit attacks. System resource starvation attacks Consider the effect of running the following routine [3] on a UNIX or LINUX system. While true Do mkdir foo chdir foo Done In many UNIX and LINUX systems, this will generate so many i-nodes (file system objects that hold file parameters such as ownerships and permissions, times of access and modification, and the size of each file) that the system may run out of resources and crash. Another type of resource starvation attack is a snork attack [3]. In this kind of attack, a attacker sends a specially crafted UDP packet to a particular 9

23 port, causing the victim system to use 100% of its CPU for an extended period of time. Consider the html file, <script lang="javascript"> while(1){ alert("denial of Service Demo."); } </script> After executing it appears as shown in Figure 2.3. Figure 2.3 Resource Starvation after clicking html file Buffer overflow attacks In a buffer overflow attack [3], a program writes too much data into a buffer compared with the amount of memory allocated. Examples of buffer overflow attacks include sending a message with an excessively long subject line or using FTP (the file transfer protocol) to request a file with an excessively long name or to change directories, again with an excessive number of characters in the argument that follows the cd command or Sending to a user of the Pine program a message with a "From" address larger than 256 characters. The excess input may be written into memory, overwriting data that control the execution path for the program that is running, seizing control of the execution of the program, and running rogue commands or programs (often with super user-level privileges). Each program runs by sequentially executing CPU instructions. The sequence order of these instructions is kept in the extended instruction counter (also known as 10

24 the EIP register) that controls program execution, specifying the address of each subsequent instruction that is to be executed. The extended instruction counter is modified whenever there is a jump instruction or a function is called. When a function has been run, the extended instruction counter needs to know where to go when the function complete its run. It does this by putting the return address for the function call into the stack, a special area of memory is used to hold arguments for functions, register values, and other variables that enable it to go to the instruction immediately after the one that has called the function that has just been run. Attacker can send specially constructed input that spills over into memory, overwriting the return address within the stack. Once the called function is through running the special input is loaded into the EIP register in an attempt to make overflow code (i.e., code that is inserted after the data designed to exceed the allocated buffer size) to be run in lieu of the normal process code. Any rogue commands or program in a buffer overflow attack can be used for a variety of malicious purposes, including causing DoS on the victim or other hosts. The attacker may miscalculate the allocated buffer size, spilling garbage data as well as specially crafted input designed to overwrite the stack s return address into memory. The result may be that the application that is running (and possibly also the system itself) may crash. Teardrop attack This type of denial of service attack exploits the way that the Internet Protocol (IP) requires a large packet to be fragmented to handle by the next router. The maximum amount of data that a link-layer packet can carry is called the MTU (maximum transfer unit). Because each IP datagram is encapsulated within the link-layer packet for transport from one router to the next router, the MTU of the link-layer protocol places a strict limit on the length of an IP datagram. 11

25 Figure 2.4 IP Fragmentation The Identifier, Flags, Fragmentation Offset are the key fields in the IPv4 datagram. A datagram 4,000 bytes arrives to a router and this datagram must be forwarded to a link with a MTU of 1500 bytes. This implies that the 3,980 data bytes in the original datagram must be allocated to three separate fragments (each of which is also IP datagram). Suppose that the original datagram has an identification number of 777. Then the characteristics of the three fragments are as follows: 1st fragment bytes in the data field of the IP datagram. - identification = offset = 0 (meaning the data should be inserted beginning at byte 0) - flag = 1 (meaning there is more) 2nd fragment byte information field - identification = offset = 1,480 (meaning the data should be inserted beginning at btye 1,480 - flag = 1 (meaning there is more) 3rd fragment byte (= ) information field - identification =

26 - offset = 2,960 (meaning the data should be inserted beginning at byte 2,960) - flag = 0 (meaning this is the last fragment) Figure 2.5 IP Fragments overlapping In the teardrop attack [8], the attacker's IP puts a confusing offset value in the second or later fragment (i.e. reduces the offset values). If the receiving operating system does not have a plan for this situation, it can cause the system to crash. Thus leads to denial of service attack. Land Attack Some implementations of TCP/IP are vulnerable to packets that are crafted in a particular way (a SYN packet in which the source address and port are the same as the destination--i.e., spoofed). Land [8] is a widely available attack tool that exploits this vulnerability. Any remote user that can send spoofed packets to a host can crash or "hang" that host. Protocol Exploit Attacks In this attack, the attacker will misuse the protocol features for attacking the targeted system. There are three well known protocol exploit attacks; they are TCP SYN Attack, PUSH + ACK Attack and Malformed packet attacks. 13

27 TCP SYN Attack The best known flooding attack is SYN flooding attack [3] [4] in which the attacker exploits the three-way handshake involved in establishing a TCP (transmission control protocol) connection. Normally when client tries to establish a TCP connection with server, they exchange a series of messages as follows; 1. The client requests a connection by sending a SYN enabled TCP packet with the initial sequence number to the server. 2. The Server acknowledges this request by sending SYN-ACK enabled TCP packet with its own sequence number back to the client. 3. Then the client responds with an ACK of the server sequence number, and connection is established. Client Server SYN, ISNc >> << SYN-ACK (ISNc+1), ISNs ACK (ISNs+1) >> Where ISN = initial sequence number. Client and server can now send service-specific data. In most of the applications like web servers, where any client whose details are unknown to the server can established a connection by spoofing the IP address of the legitimate user. Whenever a client sends a SYN enabled packet to server then server LISTEN state is transited to SYN-RECEIVED state where it will initializes the TCB (Transmission Control Block), a data structure which stores the information about the individual connection state such as local and remote socket numbers, send and receive sequence number information, etc., which takes typically of 1300 bytes of memory space. There is limited memory for storing TCB's, if this limit is reached, then 14

28 operating system kernel will ignored incoming SYN enabled TCP packets (i.e. no new connections are allowed), or replaced the uncompleted connections. This mechanism targeted the SYN Flooding attack. Figure 2.6 TCP SYN Attack Figure 2.7 Leaving connections half open by sending multiple SYN requests without replying to SYN, ACK In SYN Flooding attack, attacker keeps on sending many SYN enabled TCP packets to the target machine as shown in the above Figure 2.7. If target machine responds to only legitimate users then attacker has to spoof the legitimate user IP address (which is off), then it will flood the SYN segments to the target machine. Then target machine responds to that requests and many half-open-connections will be created at the target machine, where the attacker never responds to the target 15

29 machine, so the reserved TCB s memory was exhausted and it can t able to accept any new legitimate connection request, thus leads to denial of service. PUSH + ACK Attacks In the TCP protocol, packets that are sent to a destination are buffered within the TCP stack and when the stack is full, the packets are sent to the receiving system. However, the sender can request the receiving system to unload the contents of the buffer before the buffer becomes full by sending a packet with the PUSH bit set to one. PUSH is a one-bit flag within the TCP header [6]. Generally TCP stores the incoming data in large blocks before processing it and process it at their own convenience. This is to minimize the processing overhead each time when segment received. Whenever receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process. The PUSH + ACK attack is similar to a TCP SYN attack. The goal of this attack is to deplete the resources of the victim system. The attacking agents send TCP packets with the PUSH and ACK bits set to one. These packets instruct the victim system to unload all data in the TCP buffer (regardless of whether or not the buffer is full) and send an acknowledgement when complete. If this process is repeated with multiple agents, the receiving system cannot process the large volume of incoming packets and it will crash. Malformed Packet Attacks A malformed packet attack is an attack where the attacker instructs the secondary victim systems to send incorrectly formed IP packets to the victim system in order to crash the victim system. There are two types of malformed packet attacks IP address attack and IP packet options attack. 16

30 IP address attack In an IP address attack, the packet contains the same source and destination IP addresses. This can confuse the operating system of the victim system and cause the victim system to crash. IP packet options attack In an IP packet options attack, a malformed packet may randomize the optional fields within an IP packet and set all quality of service bits to one so that the victim system must use additional processing time to analyze the traffic. If this attack is multiplied using enough secondary systems, it can shut down the processing ability of the victim system. 2.2 DoS Countermeasures There are a number of proposals and partial solutions available today for mitigating the effects of a DoS attack. Many of these solutions and ideas assist in preventing certain aspects of a DoS attack. However, there is no comprehensive solution to protect against all known forms of DoS attacks. Also, many derivative DoS attacks are continually being developed by attackers to bypass each new countermeasure employed. Some of the well known countermeasures are discussed in this section. Reducing IP Spoofed Packets It is impossible to totally eliminate IP-spoofed packets [9]. But we can reduce the number of IP-spoofed packets entering and exiting the network. The best method is to install a filtering router that rejects the incoming packet if its source address belongs to the internal network. In addition, it should also filter the outgoing packets that have a source address not belonging to internal network. By these combination of filters would prevent outside attackers from sending a packet pretending to be from internal network. It would also prevent packets originating within the network from spoofing outside network address. But this will not work when any outsider is the legitimate user, and then outside attacker will spoof the IP address from the outside network. 17

31 SYN Cookies SYN cookies [4] modify the TCP protocol handling at the server side (receiver connection request) by delaying the allocation of resources until the client address has been verified. When server received the SYN segment they will not create any TCB for that connection request instead they will send the SYN-ACK with the modified initial sequence number of the server called SYN cookie. SYN cookie is constructed according to the following rules: t = A counter incremented every 64 seconds m = Maximum segment size value that the server will store in the SYN queue entry s = The result of a cryptographic secret function computed over the server IP address and port number, the client IP address and port number, and the value t. The returned value "s must be truncated to 24-bit value. The initial TCP sequence number, i.e. the SYN Cookie, is computed as follows: First 5 bits: t mod 32 Next 3 bits: an encoded value representing m Final 24 bits: s When client sends back a TCP ACK packet to the server in response to the server's SYN+ACK packet, the client must use n+1 in the Acknowledgement number, where n is the initial sequence number sent by the server. Then the server subtracts 1 from the acknowledgement number to get back the SYN cookie sent to the client. From this SYN cookie, the server will reconstruct all the required values to initialize the full TCB for this connection. Server does the following steps, 1. Checks the value t against the current time to see if the connection is expired. 2. Recompute s to determine whether this is a valid SYN Cookie. 3. Decodes the value m from the 3-bit encoding in the SYN Cookie, which it then can use to reconstruct the SYN queue entry. 18

32 There are certain drawbacks to this solution; first, the server is limited to only 8 unique MSS values, since m value encoded in 3 bit. Second, the server must reject all TCP options (such as large windows), because the server not maintaining SYN queue entry from initial step where this information will be stored. Figure 2.8 TCP Connection establishment with SYN Cookies SYN Cache SYN Cache [4] [10] is based on minimizing the amount of state that a SYN allocates to 160 bytes for FreeBSD systems, i.e., not immediately allocating a full TCB. The SYN caches have some secret bits that are selected from the incoming SYN segments. The secret bits are hashed along with the IP addresses and TCP ports of a segment, and the hash value determines the location of the incomplete TCB store in a global hash table. There is a bucket limit for each hash value, and when this limit is reached, the oldest entry is dropped. Thus from the same system too many connection request cannot be made. But it affects the performance to some small extent. Prevention of Ad hoc flooding attack The method of neighbor suppression is used to prevent RREQ Flooding Attack [5]. In this method, each neighbor calculates the rate of RREQ originated by intruder. If the rate exceeds some threshold, all neighbors will not receive and forwarded packets from intruder. 19

33 Figure 2.9 Ad Hoc Neighbour nodes isolate attack 20

34 2.3 DDoS Countermeasures There are a number of proposals and partial solutions available today for detection/prevention of DDoS attacks. However, there is no comprehensive solution to protect against all known forms of DDoS attacks. Also, many derivative DDoS attacks are continually being developed by attackers to bypass each new countermeasure employed Taxonomy of DDoS Countermeasures Figure 8: DDoS Countermeasures DDoS Countermeasures Detect and Neutralize Handlers Detect/Prevent Secondary Victims Detect /Prevent Potential Attacks Mitigate /Stop Attacks Deflect Attacks Post - Attack Forensics Individual Users Network Service Providers Egr ess Filtering MIB Statistics Honeypots Traffic Pattern Analysis Packet Traceback Event Logs Install Software Patches Built - in Defenses Dynamic Pricing Shadow Real Network Resources Study Attack Load Balancing Throttling Drop Requests Figure 2.10 DDoS Countermeasure Taxonomy There are three essential components to DDoS countermeasures [2]. The first one is preventing the DDoS attack which includes preventing secondary victims, detecting and neutralizing handlers. The other component deals with a DDoS attack while it is in progress, includes detecting or preventing the attack, mitigating or stopping the attack, and deflecting the attack. Lastly, there is the post-attack component which involves network forensics. 21

35 Detect and Neutralize Handlers One important method for stopping DDoS attacks is to detect and neutralize handlers. Since the agent-handler DDoS attack tools require the handler as an intermediary for the attacker to initiate attacks, finding and stopping the handlers is a quick method to disrupt the DDoS attack network. This can possibly be done by studying the communication protocols and traffic patterns between handlers and clients or handlers and agents in order to identify network nodes that might be infected with a handler. Also, there are usually far fewer DDoS handlers deployed than there are agents, so neutralizing a few handlers can be easy. Figure 2 : DDoS Agent - Handler Attack Model Agent Attacker Attacker Client Handler H H H H A A Agent s A A A A Victim Figure 2.11 DDoS Agent-Handler Model Prevent Secondary Victims One of the best methods to prevent DDoS attacks is for the secondary victim systems to prevent themselves from participating in the attack. This requires a high awareness of security issues and prevention techniques from all Internet users. If attackers are unable to break into and make use of secondary victim systems, then the attackers will have no DDoS attack network from which to launch their DDoS attacks. In order for secondary victims not to become infected with the DDoS agent software, users of these systems must continually monitor their own security. They 22

36 must check their systems to make sure that no agent programs have been installed on their systems and that they are not sending DDoS agent traffic into the network. Typically this would include installing anti-virus and anti-trojan software and keeping these up to date. Also, all software patches for discovered vulnerabilities must be installed. Since these tasks can be viewed as difficult for the average web-surfer, recent work has proposed built-in mechanisms in the core hardware and software of computing systems that can provide defenses against malicious code insertion, for example through exploiting buffer overflow vulnerabilities. This can significantly reduce the probability of a system being compromised as a secondary victim in setting up a DDoS attack network. Detect Potential Attacks This includes Egress filtering and MIB (Management Information Base) statistic. Egress Filtering One method for detecting potential attacks is to use egress filtering. Egress filtering refers to the practice of scanning the packet headers of IP packets leaving a network (egress packets) and checking to see if they meet certain criteria. If the packets pass the criteria, they are routed outside of the sub-network from which they originated. If the filter criteria are not met, the packets will not be sent to the intended target. Since one of the features of DDoS attack is spoofed IP addresses, there is a probability that the spoofed source address of DDoS attack packets will not represent a valid source address of the specific sub-network. If the network administrator places a firewall or packet sniffer in the sub-network that filters out any traffic without an originating IP address from this subnet, many DDoS packets with spoofed IP source addresses will be discarded, and hence neutralized. 23

37 MIB Statistics Another method currently being looked at to identify when a DDoS attack is occurring uses the Management Information Base (MIB) data from routers. The MIB data from a router includes parameters that indicate different packet and routing statistics. Current research has focused on identifying statistical patterns in different parameters during a DDoS attack. It looks hopeful for possibly mapping ICMP, UDP, and TCP packet statistical abnormalities to specific DDoS attacks. Accurate statistical models based on the MIB parameters from routers are still being studied to understand how accurately they can monitor DDoS attack traffic and predict when a DDoS attack is happening. Work in this area could provide important information and methods for identifying when a DDoS attack is starting and how to filter or adjust the network to compensate for the attacking traffic. Mitigate or Stop the Effects of DDoS Attacks In this method, its goal is to reduce the effect of DDoS attacks by applying the basic techniques such as Load Balancing, Throttling and Drop Requests. Load Balancing For network providers, there are a number of techniques used to diminish the effects of a DDoS attack. Providers can increase bandwidth on critical connections to prevent them from going down in the event of an attack. Replicating servers can help provide additional failsafe protection in the event some go down during a DDoS attack. Balancing the load to each server in a multiple-server architecture can improve both normal performance as well as reduce the effect of a DDoS attack. Throttling One proposed method to prevent servers from going down is to use Max-min Fair server-centric router throttles. This method sets up routers that access a server with logic to adjust (throttle) incoming traffic to levels that will be safe for the server to process. This will prevent flood damage to servers. Additionally, this method can be extended to throttle DDoS attacking traffic versus legitimate user traffic for better results. This method is still in the experimental stage; however similar techniques to 24

38 throttling are being implemented by network operators. The difficulty with implementing throttling is that it is still hard to decipher legitimate traffic from malicious traffic. In the process of throttling, legitimate traffic may sometimes be dropped or delayed and malicious traffic may be allowed to pass to the servers. Drop Requests Another method is to simply drop requests when the load increases. This can be done by the router or the server. Alternatively, the requester may be induced to drop the request by making the requester system solve a hard puzzle that takes a lot of computing power or memory space, before continuing with the request. This causes the users of zombie systems to detect performance degradation, and could possibly stop their participation in sending DDoS attack traffic. Deflect Attacks In this method, the DDoS attack is prevent by redirecting the attack traffic. Honey pots Another area being researched is Honey pots. Honey pots are systems that are set up with limited security to be an enticement for an attacker so that the attacker will attack the Honey pot and not the actual system. Honey pots typically have value not only in deflecting attacks from hitting the systems they are protecting, but also in serving as a means for gaining information about attackers by storing a record of their activity and learning what types of attacks and software tools the attacker is using. Current research discusses the use of honey pots that mimic all aspects of a legitimate network (such as web servers, mail servers, clients, etc.) in order to attract potential DDoS attackers.the goal of this type of honey pot is to attract a DDoS attacker and get him to install either handler or agent code within the honey pot. This prevents some legitimate systems from getting compromised and allows the honey pot owner to track the handler or agent behavior and better understand how to defend against future DDoS installation attacks. 25

39 Post-Attack Forensics Traffic Pattern Analysis If traffic pattern data is stored during a DDoS attack, this data can be analyzed postattack to look for specific characteristics within the attacking traffic. This characteristic data can be used for updating load balancing and throttling countermeasures to increase their efficiency and protection ability. Additionally, DDoS attack traffic patterns can help network administrators develop new filtering techniques for preventing DDoS attack traffic from entering or leaving their networks. Packet Traceback Another set of techniques assist in identifying the attackers using packet traces. The concept of tracing is that Internet traffic could be traced back to the true source (rather than that of a potentially spoofed source IP address). This allows back tracing the attacker s traffic and possibly identifying the attacker. Additionally, when the attacker sends vastly different types of attacking traffic, this method assists in providing the victim system with information that might help develop filters to block the attack. Event Logs Network administrators can keep logs of the DDoS attack information in order to do a forensic analysis and to assist law enforcement in the event the attacker does severe financial damage. Using both Honey pots as well as other network equipment such as firewalls, packet sniffers, and server logs, providers can store all the events that occurred during the setup and execution of the attack. This will allow the network administrators to discover what type of DDoS attack (or combination of attacks) was used Detecting a DDoS attack by analyzing client response pattern This detection technique [11] takes the advantage of the congestion control mechanism for the purpose of detecting DDoS attacks and finding malicious clients. By intentionally delaying the reply packets from the server and monitoring how each 26

40 client reacts, we can determine if the client has conformed to the congestion control requirements. Figure 2.12 The simple algorithm [11] First, the algorithm counts the number of packets in each traffic flow. We may define a flow as packets coming from the same origin or packets going towards the same destination. This is useful in identifying malicious clients when their source addresses are not spoofed, while the latter is effective in finding out which hosts are under attack. Next, after each predefined time interval, the algorithm ranks each flow according to its traffic rate and delays the reply packets from servers associated with the top ranking flows. If the clients associated with the top ranking flows are legitimate, they would decrease their sending rates in response to the delay and the flow ranking would change in the next time interval. However, if some flows still stay on the top, they treat them as suspicious flows and further examines if their sending rates have decreased at all. If their sending rates are persistent, we can conclude that an attack is taking place. If the violating flows are defined as packets coming from the same origins, we can further conclude that these are origins of the attack. 27

41 2.3.3 Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks The aim of this countermeasure [30] is to defend against connection depletion attacks. The basic idea of this countermeasure is as follows. When a server comes under attack, it distributes small cryptographic puzzles to clients making service requests. To complete its request, a client must solve its puzzle correctly. In this countermeasure they have proposed the client puzzle protocol and its proper parameterization. A client puzzle is a quickly computable cryptographic problem formulated using the time, a server secret, and additional client request information. In order to have server resources allocated to it for a connection, the client must submit to the server a correct solution to the puzzle it has been given. Figure 2.13 Client Puzzle Protocol when server is under attack [30] 28

42 2.3.4 A novel approach to detecting DDoS attacks at an early stage First detection system to be proposed based on detection on the innocent host side. Propose a novel cooperative system [12] for producing warning of a DDoS attack. The system consists of a client detector and a server detector. The client detector is placed on the innocent client side and uses a Bloom filter-based detection scheme to generate accurate detection results which consumes minimal storage and computational resources. The server detector can actively assist the warning process by sending requests to innocent hosts. Advantage of a novel detection mechanism is, it makes use of valuable information obtained at the innocent host whose IP is utilized as the spoofed IP and which receives abnormal TCP control packets during the three-way handshake. Making use of the innocent host offers two distinct advantages. First, while attackers usually try to detect and deceive defenses deployed around the victim and the attacking source, it is difficult for attackers to be aware of the existence of defensive mechanisms operating on the innocent host. Second, while a defense at the victim server requires the monitoring of numerous attacking packets, leading to congestion and even making the defense system itself vulnerable to DDoS attacks, a defensive mechanism operating at the innocent host itself faces little risk of DDoS attacks. 2.4 Methods Of Integer Factorization There are number of methods are available for integer factorization [13], few of them are explained in this section. Trial Division Method A brute-force method of finding a divisor of an integer n by simply testing one by one and examining whether they divide n till square root of n is reached. for(i=2; i<= n; i++) if(n%i==0) return i; 29

43 Pollard p-1 Factorization Method Let n be a composite integer with prime factor p. By Fermat's little theorem, we know that a k(p-1) 1 (mod p), for all K, and for all a coprime to p. If a number x is congruent to 1 modulo a factor of n, then the gcd (x-1,n) will be divisible by that factor. Euler s Factorization Method Euler's factorization method [14] is a method of factorization based upon representing a positive integer N as the sum of two squares in two different ways: N = a 2 + b 2 = c 2 + d 2 and then following the procedure. The disadvantage of Euler's factorization method is that it cannot be applied to factoring an integer with any prime factor of the form 4k+3 occurring to an odd power in its prime factorization, as such a number can never be the sum of two squares. Shor's algorithm Shor s algorithm [15] is composed of two parts. The first part of the algorithm turns the factoring problem into the problem of finding the period of a function, and may be implemented classically. The second part finds the period using the quantum Fourier transform, and is responsible for the quantum speedup. 2.5 Web Stress Tools In this section the various web stress tools are divided in three sub sections. First section consists of shareware or proprietary tools, the tools which are commercial and only trial versions are available for free. Second section includes freeware tools, the tools whose executable file is available freely but not the source code. In third section, the open source tools, the tools which are freely available along with source code, are listed. 30

44 Shareware/Proprietary Tools Webserver Stress Tool Webserver Stress Tool [16] simulates large number of users accessing a website via HTTP/HTTPS. The software can simulate up to 10,000 users that independently click their way through a set of URLs. In this tool simple URL patterns are supported, as well as complex URL patterns, via a Script file. Based on the parameters we specify, the application not only requests the HTML of a URL, but also frames, images, flash files etc., emulating the same behavior a web browser would show when accessing the website. Each user is simulated by a separate thread with his own session information (i.e. cookies for each simulated user are stored separately) and surfs the URLs independently from the other users - just like in real-world usage. URLs can be parameterized for each user and the sequence of URLs can be varied. POST and GET requests are supported as well as BASIC HTTP authentication and several other settings. New scripting functionality allows us to create highly complex URL patterns for large scale web applications. This stress and load test tool provides graphs and data in a number of different formats including: Easy to use graphs Text log summary Detailed text log User text log (one for each user) Webserver Stress Tool is a commercial tool, available in several editions and prices start at $ The first screenshot is taken from the tool website and the second screenshot is from my system with trial edition, in which it is showing that we can edit the URL script and hence it can be used for dynamic requests. 31

45 Figure 2.14 Result of a ramp test with 400 users using Webserver Stress Tool Figure 2.15 Tests using the URL script feature in Webserver Stress Tool 32

46 2.5.2 HP LoadRunner software LoadRunner [17] is a performance and load testing product by Hewlett-Packard for examining system behavior and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the imagination of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analyzed in detail, to explore the reasons for particular behavior. It is a proprietary tool, so it is not freely available for research communities. Working with LoadRunner involves usage of three different tools which are part of LoadRunner. They are Virtual User Generator (VuGen), Controller and Analysis. The Virtual User Generator (VuGen) allows a user to record and/or script the test to be performed against the application under test, and enables the performance tester to play back and make modifications to the script as needed. Once a script is prepared in VuGen, it is run via the Controller. Analysis tool takes the completed scenario result and prepares the necessary graphs for the tester to view. Figure 2.16 HP LoadRunner Virtual User Generator 33

47 2.5.3 NeoLoad Load Testing Tool NeoLoad [18] is the professional load testing software, provides all the features we need to carry out load tests and analyze the results, all from within a unique and integrated interface. It is a proprietary tool and trial version is available with 10 virtual clients for 30 days only. NeoLoad simulates hundreds of virtual users on our web site, getting performance statistics and revealing errors under stress. NeoLoad records and replays browser requests to the server, which means that NeoLoad can simulate requests made by components such as plug-ins, Java applets, ActiveX, Flash animations,... and cannot simulate local actions such as updating a graphical component using client-side JavaScript. It is a multi-platform tool available in Windows, Linux and Solaris. Figure 2.17 NeoLoad Infrastructure 34

48 Figure 2.18 NeoLoad Tool Screenshot WebLoad Load Generation Engine WebLoad [19] is a Load Generation Engine written in C language and is sponsored by RadView Software. WebLoad is the only comprehensive testing and analysis solution to combine performance, scalability and integrity as a single process for unmatched verification of Web applications. It can simulate the load up to some ten thousands of users. 35

49 WebLOAD's Integrated Development Environment (IDE) provides an integrated tool for the recording, authoring and debugging of the test scripts. The IDE includes multiple data views showing HTTP traffic in real-time during recording. This includes HTTP header views and additional views (HTML View, browser preview) that show all HTTP objects such as HTML, CSS, JavaScript and images. The returned HTML is parsed into its Document Object Model (DOM) and displayed in a special DOM View. All this data is saved and can be viewed while editing the script and during playback. It is scriptable, can be used for dynamic requests. It s a commercial tool, not available freely for research community. Its trail version is available with limited features such as support only 10 HTTP virtual clients as shown in Figure Figure 2.19 WebLoad Tool Screenshot 36

50 Freeware Tools Microsoft WAS Tool Microsoft web application stress (WAS) [20] is a simulation tool that is designed to realistically reproduce multiple browsers requesting pages from a web application. We can use this tool to gather performance and stability information about our web application. It simulates a large number of requests with a relatively small number of client machines. Their goal is to create an environment that is as close to production as possible so that we can find and eliminate problems in the web application prior to deployment. It was developed by web testers. They have made the tool as easy to use as possible by masking some of the complexities of web server testing. This makes the tool desirable for anyone interested in gathering performance data on their web site. This version covers the most needed features for stress testing three tier personalized Active Server Page web sites running on Microsoft Windows NT server 4.0 and Windows The tool software is freely available for download [20]. It is having good scalability compared to other open source and freeware tools, but it can only be of use for simple web requests, it cannot be used for dynamic requests and it is not scriptable. The Web Application Stress Tool object model can be used to start, stop, and configure a test run. However, this feature cannot be used to modify a running test in this version of the tool. The screenshot of the tool while running is shown in Figure 2.21, it is showing all the cookies it got in run. 37

51 Figure 2.20 WAS Tool Screenshot Figure 2.21 WAS Tool Cookies Screenshot 38

52 Open Source Tools Apache JMeter Figure 2.22 Apache JMeter with 10 HTTP URLs JMeter [21] is an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications. JMeter can be used as a unit test tool for JDBC database connections, FTP, LDAP, Web services, JMS, HTTP and generic TCP connections. JMeter can also be configured as a monitor. It was unable to scale well as it can only send a maximum of 2200 requests per second using single system with configuration of 2 GB RAM, Intel Core 2 Duo with 3.0 GHz processor each. Moreover, it was not able to tune the request rate (rps) and consequently its variance was more during the test. 39

53 2.5.7 FWPTT - Fast Web Performance Test Tool FWPTT (Fast web performance test tool) [22] is an open source web application testing tool written in C#.net for load testing web applications. It is scriptable and it can be use for complex requests. It can record normal requests and AJAX requests. Whatever may be the input combination to this tool, this tool was unable to send more than 500 requests per second using single system with configuration of 2 GB RAM, Intel Core 2 Duo with 3.0 GHz processor each, hence it is not scalable. Moreover, it is not having an option to tune the number of request per second not it s not having graphical viewer. Figure 2.23 FWPTT Screenshot 40

54 2.5.8 JCrawler Stress Testing Tool JCrawler [23] is an open-source Stress-Testing Tool written in Java for webapplications. It comes with the crawling/exploratory feature. User can give JCrawler a set of starting URLs and it will begin crawling from that point onwards, going through any URLs it can find on its way and generating load on the web application. It will not scale well since it is searching for the URLs to redirect in each web page. Its Configuration file screenshot is shown in Figure 2.24, Figure 2.24 JCrawler Configuration Screenshot 41

55 The tool will accept all the inputs from this configuration file, user has to enter inputs into this file. There is no way to write the dynamic request hence it cannot be of use for dynamic requests Curl-loader Curl-loader (also known as "omes-nik" and "davilka") [24] is an open-source tool written in C-language, simulating application load and application behavior of thousands and tens of thousands of HTTP/HTTPS and FTP/FTPS clients, each with its own source IP-address. It runs under Linux platform. It is not scriptable and it cannot be used for dynamic requests. A sample configuration file is shown in Figure 2.25; user has to enter all its inputs into this file. In configuration file there is no option for using dynamic requests, so this tool is limited to static requests. Figure 2.25 Curl-loader Configuration File Screenshot 42

56 CHAPTER 3 PROBLEM DESCRIPTION 3.1 Need Of DDoS Countermeasure Distributed Denial of Service attacks have been increasing in the recent times. Most of the well known sites are affected by these kinds of attacks. Stock market sites are more vulnerable during the business time as there will be many genuine user accessing it, and attacker needs only a little effort to launch DDoS attack. It is difficult to prevent such attacks from happening and the attackers may continue their damage using new and innovative approaches. But once the attack has begun, the way we react to it can make a difference. In this report we propose a way to recover slowly and restore near normal situation without any change at the user end and very little change at the server end. To clarify our idea, we will use the following hypothetical profile and work with some hypothetical numbers. Suppose is designed to handle a maximum of 2000 queries per second. A query requires the application server to talk to a database server. Serving a query request is more expensive than serving a static page. During peak day times the traffic reaches around 2000 queries per second and drops to 500 in the early hours of morning. Users usually start with the main page and then do a couple of query pages every session. The ratio of the static to dynamic pages is 1:10. So there are roughly 1500 queries and 1000 main page accesses every second. A valid query request for a nonexistent relation in the database is probably the most expensive as it misses all caches and in the worst attack, the attacker creates the query dynamically. Now a distributed attack is launched against the website and it starts receiving 40,000 queries per second. The webserver will be able to respond to only 1 out of 11 requests and the number of valid users who get a response will be lesser than 10%. Now instead of wasting valuable resources to respond to the fake requests, we propose a solution to filter out the fake requests so that after a period of time, since commence of the attack, 43

57 will be able to service at least 1500 genuine requests per second. 3.2 Need Of Web Stress Tool There are several threats to webserver. One of them is Distributed Denial of Service (DDoS) attack. As mentioned in the introduction, the disparity in computation between client and the webserver makes the DDoS attack possible. To avoid this attack, the website should be incorporated with good DDoS avoidance technique or else at least it should stop responding to the requests beyond the threshold limit (maximum number of simultaneous requests that it can handle) of the webserver to save the webserver resources from hanging. Therefore, before deploying any website in the Internet, first of all, we need to know the load capacity that it can handle. To know the webserver load limit or to test whether proposed DDoS countermeasure solution is giving expected results or not, there is a need of web stress tool which can exhibit good performance under all conditions and which should be flexible for modification as per the requirement. There are some good proprietary tools that are available for webserver load testing, but there is a need of free open source web stress tool for a research community which is modifiable as per the need. Although there are many open source tools available they do not scale well to simulate the required loads nor have traffic shaping features (unable to send fix number of request per second). Also they are not scriptable to tune to the application (that means they cannot handle dynamic requests, the request which need to be modifying depending on the response received to make it ready for sending subsequent request). For example, if any research community wants to develop their own DDoS countermeasure solution, they need a tool to test the same before publishing their work. And most of the time depending on the countermeasure technique the tool has to be modified to get the required result. There is need for such an open source tool which includes all these features and one such tool is required for our DDoS Countermeasure validation. 44

58 CHAPTER 4 PROPOSED SOLUTION 4.1 Throttling DDoS Attacks Using Integer Factorization Description This is a group proposal [29] of four members. The sequence of operations is as follows. A client sends a request to the web server for a webpage. The Server starts a session and sends N along with the JavaScript to factorize it. The Client computes p and q values and sends N, p, q values to the server. The server verifies whether the product of the factors sent by the client is equal to the N value sent by the server to the client (N=p*q). If this condition is not satisfied or the values are not sent by the client, then the server will drop the request. When the server is facing normal flow of traffic, i.e., the requests to the server is less than the threshold value, we do not interfere with the web application. When the number of requests arriving at the server crosses the threshold value, our solution is invoked and the server starts sending N to all the clients. A user using a web browser will experience a momentary delay when the JavaScript calculates the values p and q on his client machine but then his request gets through when presented to the server. An attacker who is using a malicious client will not send these p and q values and his requests get dropped. If he now modifies his client to read the JavaScript and compute p and q, the number of requests that he can send will drop down drastically. If the distributed attack sustains or deepens, we can increase the number of digits in N and this will throttle the malicious clients further without increasing any load on the server. 45

59 Countermeasures Against The Throttling The strength of our solution lies in the mathematical complexity of the integer factorization problem. Since no algorithms exist to solve this problem in polynomial time the attacker will not try to optimize this computation but will try to get around the computation by finding a hole in the protocol. In this section we discuss various scenarios where the attacker actively modifies his malicious client and tries to tweak the hosts launching the distributed attack and the countermeasures that we need to have in place to defend against such modifications. Case 1: In this case the attacker observes that the server is sending the same N for all requests. He computes the prime factors once and appends these factors to every request. This is a form of replay attack. To counter this we will dynamically generate p, the first factor of the prime from a variable that changes with time. Case 2: Now if the attacker has full control over the zombies which he is using to launch the DDoS attack, he can compute the value of q on one system and propagate it quickly to all the remaining systems and launch a replay attack in the time slot. To guard against this our solution generates q dynamically as a function of client s IP address. Fixed cost functions are used to generate these values dynamically so that there is no over head on the server. Such attacks are extremely unlikely as the communication delay to propagate the computation to all the systems will be comparable to the cost of computing it at the individual node itself. Case 3: He may try to pre compute the primes in the entire prime space. As per Table 4.1, the number of primes (NP) increases with the number of digits and becomes too huge and storage becomes a limiting factor and such attacks are difficult with zombie machines which have limited amount of resources. The communication overhead of drawing it from a central database will make such attacks infeasible. Case 4: The attacker might try to guess the value of N from its previous values, the IP address, the server time and other variables that he can find out. He may even get access to the exact code or algorithm that we use to generate p and q. So we select a random combination of primes from the set of primes and design the mapping 46

60 functions such that the selected primes are uniformly chosen across this combination. We further change this combination periodically to prevent the attacker from tabulating the combination restriction the usefulness of such tabulation further. Case 5: In this extreme case when the attacker has access to fast interconnects and resources if he successfully launches the attack in case 2 and also has access to all the mapping functions in case 4, he may find out that the value of q is reused on individual nodes. To ward off this attack we can compute q from a different source with sufficient entropy or flush the combination at a much faster rate. As a result of this flushing all existing connections will need to be reset and hence we would not suggest this to be applied unless needed. Case 6: In this case the attacker satisfies the condition N=p*q, but the factors sent by the attacker are bluffed. To counter this we generate q from the IP address using a hash function that is changed periodically. The server then verifies that the q value sent in the request is not bluffed by recalculating it from the source IP after verifying N. The drawback of this algorithm is that once the value of q is computed by the client, he can reuse the same in further requests thereby necessitating a periodic change of algorithm to compute q. In another countermeasure to this type of attack the server maintains a table in which the N values sent to every client for every request has to be stored. But this will be a memory storage load on the server and can be a problem at the server if the attacker is sending large number of request per second. We have implemented this step for the sake of completeness but this part of the algorithm is not activated unless this particular attack profile is matched. Methodology The two algorithms that are used to generate the p and q dynamically are presented in this section. The first algorithm is for selecting the q which is based on the client s IP address (say cip) and the second algorithm is for selecting the p which is based on the time duration in milliseconds from the booting of the server to the current time (say st). 47

61 The server should select the Ndigits based on the number of requests coming to the server and this should be vary between 8 to16 digits. Based on the selection of Ndigits, pdigits and qdigits should be selected based on the following criteria. pdigits = Ndigits/2, qdigits = (Ndigits+1)/2 (1) The above criterion (1) is to ensure that there are no easy factors served out, it is cryptographic rule to have hard factors. To implement the dynamic generation of p and q values we first store pre-computed primes between 4 and 8 digits in a two dimensional array called primes. The number of primes (NP) in each digit (i.e., 4, 5, 6, 7, and 8) is tabulated below in Table 4.1. Table 4.1 Number of primes in each digit Ndigits NP Algorithm 1: Generate q GenerateQ(qdigits,NP,primes,cip) { cip = A.B.C.D ipmapvalue = 2 24 *A+2 16 *B+2 8 *C+D qmapvalue=(ipmapvalue) mod NP return primes[qdigits][qmapvalue] } In the above algorithm the cip represents the clients IP address and it is in the form of A.B.C.D. The ipmapvalue is the value that is generated from the client IP address and this value is unique for each client. From the total set of primes, we choose a random combination and call it selectedprimes array. So the q value generated for each client will be unique. The NP in the above algorithm represents the number of primes in selectedprimes array. 48

62 Algorithm 2: Generate p GenerateP(pdigits,NP,primes,st) { pmap=(st) mod NP return primes[pdigits][pmap] } In the above algorithm the st represents the number of milliseconds since the server boot. As st differs for every millisecond the p value generated will be unique for each client. Application Now continuing the example that we used earlier section, we are serving 1500 dynamic plus 1000 static request per second during the normal traffic profile. In the worst case, the attacker is sending an additional 40,000 void searches. So we are receiving 41,500 query requests and 1000 static requests. We now respond to the attack by prepending a JavaScript that does the stamping computation and sets a valid stamp in the HTTP header to every request received. So out of the 41,500 query requests, we should be able to respond with a static redirect page with the JavaScript for at least 39,000 of them. Now the attacker usually would have stored the old request and will not be able to modify his request to include the stamp and all his requests will be redirected only to a static page. The genuine users will be using popular browsers and will be able to get a new page with the JavaScript within a few refreshes. Now the JavaScript does a second long computation for every request that the browser sends and the user will be able to continue working with a tolerable latency. When this new search request comes in with the stamp, we treat it with higher priority and open up the server resources to it. Eventually we will converge to a point around which we will be able to serve all the stamped query requests while using the remaining resources to serve the requests without a stamp with a new page. If we are serving 1500 queries, we can still serve 20,000 static pages. Over a period of time the genuine users cross the filter after a few retries. If the attacker is able to reconfigure his resources to calculate the stamp, then he will be able 49

63 to send only a fraction of his original requests. He will be able to send in something like 400 queries requests instead of 40,000 and the damage will be contained if not eliminated. Now, if the attacker attaches an invalid stamp, he may pass through the initial filter, but we can still verify the stamp with a fraction of the cost of serving the request and drop it pretty early in the pipeline. Once the attack stops, we can remove the JavaScript attachment and restore normalcy. We also have the flexibility of changing the JavaScript to invalidate any pre-computation efforts by the attacker. Further a simple inexpensive hardware can be installed to send this static redirect, reducing the load on the server almost completely. Implementation Results In this section we present the results obtained by implementing the proposed solution. Clients: Intel core2 Duo CPU with processor speed 3.00 GHz each, 2 GB RAM, Windows XP professional operating system. Server: Intel Xeon Quad CPU, processor speed 3.60 GHz each, 4 GB RAM, Win 2003 server. To study the effectiveness of the proposed solution, we developed a website that represents a typical portal. We developed a version incorporating the solution (WSolution) and other without it (WoSolution). The WoSolution website consists of 27 pages each having multiple database connections in it. The WSolution website consists of an extra HTML page with a JavaScript which makes the client browser to factorize N. When a request comes to the website without the proper cookies, this static page is served and the client is then redirected to the proper web page. The server retrieves the number of request per second from the Windows performance counters, and when it exceeds a threshold value the server invokes the proposed solution and starts sending out a N value using cookies in each response. The client responds with the factors and the server will verify it. If the proposed condition (N=p*q) is satisfied by the client, the server will then respond with the actual page and the N value in the session variable will be flushed out. 50

64 There was a problem in adding Java script factor() function to HTML page because no browser will allow to run Java script code for long duration i.e. more than 10,00,000 loops instead they show alert called stop running this script. The effort has made to solve this problem by using settimeout() [27] function, which takes two arguments; first argument is name of the function and second one is time in millisecond. SetTimeout() will call the function after the time dealy specified in the second argument. The large loop was broken into smaller loops each with 10 lakhs iterations, and a count variable was used to continue the last iteration i value, the code is shown below; Algorithm 3: factor() y = 0;///intial value function factor() { ///breaking this loop to avoid browser alert called "stop running this script" for(i=y; i<=x && (count< ); i++,count++) { if(n%i==0) { q=i; p=n/q; break; }///factor found } ///if factor not found if(p==0){ y=i; count=0; t=settimeout("factor()",0); } } Table 4.2 Latency in milliseconds of browsers to calculate factors Ndigits IE Mozilla Opera Chrome CCB

65 Server Load We measured the latencies of different web browsers to factor the primes and tabulated it in Table 4.2. CCB in the above table represents a custom command line browser written in C#.Net. By measuring the latencies of the JavaScript computation on most popular browsers, we observe that a 14 digit N values give about 2 seconds latencies on the browsers, which should be tolerable to an end-user Overhead with fixed N Requests per second with solution with out solution Figure 28 Graph Overhead on requests/sec with fixed N 52

66 Number of rps Server load From the graph in Figure 28 we can see that the overhead of our solution is not significant when N is fixed. 60 Server load relief Mixed traffic (1000 good traffic bad traffic) Good traffic (1000 req/sec) Time (minutes) Figure 4.2 Graph Server load relief In the Figure 4.2 we sent a steady 1000 rps through client 1 which can compute p and q. This causes a steady load of about 25% on the server. After 1 minute we sent attack traffic of about 2000 rps from client 2 which does not compute p and q. The server load increases till our threshold limit is reached. Then our solution is invoked and we start serving N. The server drops the attack traffic and treats them as static pages. We can see that the server load falls down once our solution kicks in. Max Client Req/sec Vs Ndigit Number of digits in N Figure 4.3 Graph Max client requests/sec Vs Number of digits in N 53

67 Overhead (req/sec) Overhead (req/sec) Overhead (req/sec) From the graph presented in Figure 4.3, we can clearly see the throttling effect on the malicious clients where in the total number of requests that they can send can be made to fall down by a factor of 100 by increasing the number of digits to 14. This means that an attacker who has compromised 100 zombies will be able to inflict only the damage possible by one such machine thereby loosing the effectiveness of the attack. Overhead with dynamic p (timestamp) Number of digits in N Figure 4.4 Graph Overhead at server when p is generated dynamically Overhead with dynamic p and q Number of digits in N Figure 4.5 Graph Overhead at server when p and q are dynamic Number of request/sec with 30 sec flush Number of digits in N Figure 4.6 Graph Overhead on number of rps with p and q generated dynamically 54

68 Now in Figure 4.4, Figure 4.5 and Figure 4.6 we list the overhead on the server in terms of reduced number of dynamic requests that are served at 100% CPU load. As expected this loss does not increase significantly even when we are generating p and q dynamically for every request. The overhead is bounded by 120 rps in all cases which is less than 4% for our application. 4.2 HTTPattack: An Open Source Web Stress Tool Tool Description We have developed an open source web stress tool called HTTPattack in Information Security lab, Department of computer engineering, National institute of technology Karnataka which can be downloaded from our website [25]. HTTPattack tool is used to simulate the number of clients accessing the website simultaneously in a given instant of time. Its source code is available for research communities so that they can use it and modify it according to their requirement. They can easily understand its source code as it was written in C#.Net with the naming guidelines taken from MSDN [26] and with proper comments. It can be used to simulate a heavy load on a server to test its strength or to analyze overall performance under different load types. It can also be used to test the strength of DDoS countermeasure which is incorporated in the website whether it can withstand under heavy load or not. It will accept input as a set of URLs (uniform resource locator) and then it starts sending requests to each URL in circular fashion. It does not wait for the response after sending the request rather it simply switches to send next request, but it will create one thread to receive that response, so for each request the corresponding thread is created and that is responsible to receive the response. In the similar fashion, it can send maximum number of request in less time interval (technically it is sending Asynchronous requests). We made effort to make the tool interactive that is when tool starts running after every 5 seconds, it shows the updated value and draws the graph. This will help the user to analyze whether the success rate is high or failure rate is high in a given duration of time and whether the tool is 55

69 running properly or not. For logging the requests and responses, there was an IPC (inter process communication) problem since the responses may arrive at anytime and may try to access concurrently the log file so we made an effort to solve this problem using the queue concept. Whenever the response or request arrived, which has to be logged, first it will be pushed to the queue rather than directly writing it to the log file. Later at regular intervals all the entries from the queue are written to the log file. Same method is used for trace file also. Features 1.User can add their own HTTP cookies (a name value pair) to the requests. 2.User can add HTTP header directly to the uniform resource locator (URL). 3.One can use the proxy server settings to send the request through it. For example, in many organizations or research institutes, they maintain a proxy server to monitor and to authenticate the user. 4.One can run the tool even if user s credential information is required to their proxy server in each request. User can set network credential to proxy server with this tool. 5.It provides attractive graphical view which is interactive during the run. User can easily identify in which duration the requests failed and in which duration maximum requests are successful. 6.It can track each request, i.e. when the request was sent and corresponding response was received, both of them will be stored in a text file called log file. We associated a number variable called packetid which stores the request number, to each request, which in turn helps in correlating the request with the corresponding response. It will also show whether there is any error in sending request or receiving response with corresponding protocol code, e.g. HTTP 403, 407, etc. 7.It also provides a trace file to store web page source code found in response to a request. 56

70 8.One can use the timeout option with each request, and it will abort the request when that timeout occurs before receiving a response. But it is better to use it when it is needed since it will take some extra memory to store the timeout handler for each request. 9.It is simple and ready to use. The code is easily understandable, since the code has been written by following naming guidelines from MSDN help [26] and is easy to modify as per the need, thus it is scriptable. It is user friendly and each form element is associated with tooltip help so that user can easily get how to operate it. 10. It is scalable as well as tunable. Implementation Results HTTPattack tool does not execute the JavaScript found in HTML pages but it will store it if required. In HTTPattack tool, mandatory user inputs are uniform resource locator (URL) file which contains the list of URLs, attack rate in request per second (rps), attack mode, and duration of attack. After giving all these inputs, depending on attack rate it will start sending requests to the respective URL from the file in circular fashion taking each URL at a time. This tool will operate in three attack modes namely uniform mode, jitter mode and burst mode. Uniform mode: In this mode, the tool will send requests uniformly, means if 100 requests are to be sent in every second (i.e. when attack rate = 100 rps) then it will send one request in each 10 milliseconds, that is it will uniformly divide all 100 requests in 1000 milliseconds (equals to one second). Jitter mode: In this mode, if attack rate is X rps, then in every second, it will send X number of requests continuously without any delay and once the X requests are sent, then it will check how much time it took to send these X requests. If it is less than one second, then it will wait until the completion of current second (i.e. wait for some milliseconds). If time taken is more than or equal to one second, then it will continue sending next X requests for the next second. 57

71 Burst mode: In this mode, it starts sending requests continuously till attack duration ends. Our tool will send more number of rps in this mode. Algorithm of each mode is shown below with the proper comments, to make it simple to understand, Algorithm 4: Uniform Mode ///send each request unifromly while (elapsedmsec < attackdurationmsec && packetid < maxrequest) { nowtime = SendNewRequest(URL); ///total milliseconds took from start to send these many requests. elapsedmsec =(nowtime - starttime).totalmilliseconds; sleeptime = ((1000 * packetid) / attackrate - elapsedmsec); ///i.e. packet id > rate means tool sent request earlier than the calculated time ///now it has to wait to maintain uniformity if (sleeptime > 0) Thread.Sleep(sleepTime); } Algorithm 5: Burst Mode ///Continuously send the requests till attack duration ends ///SendNewRequest() will return the time at which it complete s its execution ///i.e. after sending the current request while (SendNewRequest(URL) < endtime); Algorithm 6: Jitter Mode ///send request uniformly in per second basis for ( i = 0; i < attackdurationsec; i++) { nowtime = DateTime.Now; 58

72 for ( j = 0; j < attackrate; j++) nowtime = SendNewRequest(URL); ///total milliseconds took from start of this tool till now, ///i.e. time taken to send these many request(=packetid) till now. elapsedmsec = (nowtime - starttime).totalmilliseconds; ///1000*packetId/attackRate is the time calculated ///that it should take to send these many requests (=packetid) sleeptime =((1000 * packetid) / attackrate - elapsedmsec); if (sleeptime > 0) Thread.Sleep(sleepTime); } With this line of code shown in syntax 1, we are associating a unique packetid with each request, it helps in correlating the request with the corresponding response. Syntax 1: AttackRequest attackrequestdata = new AttackRequest(++packetId, DateTime.Now, mywebrequest); When attack rate is less than 2000 requests per second (approx.) and requests need to be sent uniformly, uniform mode is recommended for use, it also depends on systems configuration. Otherwise if the attack rate is high and uniformity in sending requests needs to be maintained, then jitter mode is preferable. Generally, many tools send requests using many threads, to simulate the parallel request i.e. once a request is sent then that particular thread will wait for the response before sending next request. But HTTPattack tool will not wait until the response comes, it continuously keeps on sending requests one after the other and the arrival of response is taken care by thread which will be created at each request sent and will be destroyed when the response comes or timeout occurs(if set). In this tool we are using interface called IAsyncResult [28] to send Asynchronous requests. It will execute 59

73 the asynchronous operation and when server response anything, it will invoke the CallBackMethod() function. The CallBackMethod() will process the response received. Syntax 2: IAsyncResult result = (IAsyncResult)myWebRequest.BeginGetResponse(new AsyncCallback(CallBackMethod), attackrequestdata); If user wants good performance then he needs to enable only the features which are necessary and the remaining features such as trace file, log file, draw graph can be disabled. One can use multiple systems with this tool to get better response since one system may not affect the server with any tool. Our system is configured with Intel core2 Duo CPU with processor speed 3.00 GHz each, 2 GB RAM, Windows XP professional operating system. With this configuration and enabling only necessary features, we have tested our tool in burst mode. Our tool is capable of sending requests in 10 seconds i.e. it is capable to send rps to dynamic website; its screenshot is shown in Figure 4.7. When compared to other tools which are unable to send more than 2200 rps this tool is almost 8 times better, thus it will reduce the hardware cost by 8 times i.e. if one needs 8 systems to test the website with other tool then with HTTPattack tool only one system is sufficient to test the same. Don t use this tool simply on any organization websites unless you are authorize to do the same. This tool has been used successfully to test our DDoS countermeasure called Throttling DDoS Attack [29], it is depicted in Figure 4.8. The snapshot of our tool is depicted in Figure 4.9 with all features enabled. As the graph seems to be congested, one can expand it by right clicking on the selected part of the graph to analyze; its snapshot is shown in Figure

74 Table 4.3 Tool Comparision Table Tool Name Scriptable Tunable Maximum Available as (support rps dynamic (approx.) request) HTTPattack Yes Yes Open Source JMeter No No 2200 Open Source FWPTT Yes No 500 Open Source JCrawler No No 200 Open Source Curl-loader No No NA Open Source WAS No No 8000 Freeware 61

75 Figure 4.7 Tests on dynamic web pages with HTTPattack Tool Figure 4.8 Screenshot Testing Throttling DDoS Solution with HTTPattack Tool 62

76 Figure 4.9 HTTPattack Tool with all feature enabled Figure 4.10 HTTPattack Tool with zoomed graph 63

77 CHAPTER 5 CONCLUSION 5.1 Conclusion In this thesis we proposed an approach to contain a DDoS attack at the application level. We came up with a solution to generate stamps on the web browsers that are easily verifiable at the server. Our algorithm is further tuneable to throttle the client CPU when the attack deepens. We came up with a strategy to distinguish between genuine traffic and malicious traffic and drop the later much earlier in the transaction during a DDoS attacks. We proposed two different algorithms for dynamic generation of primes. There is no considerable overhead on the web server because of deploying the proposed solution. As a whole we saw less than 5% overhead on the server to verify the timestamp and serve the additional JavaScript. And also come up with an open source web stress tool for the use of research community. It is scriptable, tunable and scalable and thus it is having all necessary features required for a good web stress tool. 5.2 Scope of Future Work The DDoS Countermeasure can further improve to exclude the genuine requests from the bad traffic by inventing a new intrusion detection technique. The HTTPattack tool can further be enhanced to include the grid deployment feature, so that the user can deploy the tool on network. With this feature, a heavy load of requests can be sent by all the systems in the grid simultaneously. In such case, one system will act as the master and others behave as slaves. Slave systems will wait for a command from master to run the tool with heavy load..moreover, from one system we can control the whole task of execution rather than making settings on each system manually. 64

78 BIBLIOGRAPHY [1] Peter Alfeld, "Notes and Literature on Prime Numbers", (Nov 11, 1996). [2] Stephen Specht,"Taxonomies of Distributed Denial of Service Attacks, Tools, and Countermeasures", Survey%20Paper_v7final.doc (Last visited on 5 th March 2009). [3] Hossein Bidgoli, Handbook of Information Security, Pages: John Wiley & Sons, Hoboken, New Jersey (2006). [4] RFC 4987, W. Eddy, The IETF Trust (2007),"TCP SYN Flooding Attacks and Common Mitigations", [5] R. Praveen Sam, Dr. B. Stephen Charles, Dr. P. Chandrasekhar Reddy, "Denial of Service attack through compromised nodes in Mobile Ad-Hoc Networks", volume 21, [6] RFC 793, Transmission Control Protocol DARPA Internet Program Protocol Specification. Arlington, Virginia. September [7] RFC 3561, C. Perkins, Ad hoc On-Demand Distance Vector (AODV) Routing, Nokia Research Center, July [8] CERT/CC team, Copyright 1997, 1998 Carnegie Mellon University, "CERT Advisory CA IP Denial-of-Service Attacks", (Last visited on 5 th March 2009). [9] CERT/CC team, Copyright Carnegie Mellon University, "CERT Advisory CA TCP SYN Flooding and IP Spoofing Attacks", (Last visited on 5 th March 2009). [10] Wesley M. Eddy, Verizon Federal Network Systems, Cisco Systems, "Defenses Against TCP SYN Flooding Attacks", The 65

79 Internet Protocol Journal - Volume 9, Number 4, [11] Yuji Soejima et al, "Detecting DDoS Attacks by Analyzing Client Response Patterns", Proc., Int. Symp. on Applications and the Internet Workshops, Pages: , year of Publication [12] Bin Xiao et al, "A novel approach to detecting DDoS attacks at an early stage", The Journal of Supercomputing, IEEE, Volume 36 Issue 3, Kluwer Academic Publishers, June [13] Alfred J.Menezes, Paul C. van Oorschot and Scott A. Vanstone, Handbook of Applied Cryptography, Pages: CRC Press, Boca Raton (2000). [14] Wikipedia, "Euler's factorization method", wiki_/euler's_factorization_method (Last visited on 20th May 2009). [15] Wikipedia, "Shor's algorithm", /Shor's_algorithm (Last visited on 20th May 2009). [16] Paessler the network monitoring company, "Webserver Stress Tool", (Last visited on 14 th June 2009). [17] Hewlett-Packard Development Company, "HP LoadRunner software", content.jsp?zn=bto&cp= ^8_4000_100, (Last visited on 24 th June 2009). [18] Neotys Web Load Testing Solutions, "NeoLoad Evaluation - Load Testing", (Last visited on 24 th June 2009). [19] RaidView Software Ltd, "Web Load Open Source Load Testing", (Last visited on 25 th June 2009). 66

80 [20] Microsoft Corporation, "Web Application Stress Tool", 062a-439e-a67d-75a89aa36495&displaylang=en, (Last visited on 20 th May 2009). [21] Apache Jakarta Project, "Apache JMeter", (Last visited on 25 th June 2009). [22] Bogdan Damian, "fwptt", (Last visited on 25 th June 2009). [23] Idumali, Under the CPL, "JCrawler", (Last visited on 26 th June 2009). [24] Robert Iakobashvili et al., under the licensed GPLv2, "curl-loader", (Last visited on 1 st July 2009). [25] Syed Taqi Ali, "HTTPattack Tool", /home.php (Last visited on 9th July 2009). [26] Microsoft, "Naming Guidelines", (Last visited on 20 th May 2009). [27] W3school.com, Copyright by Refsnes Data, "JavaScript Timing Events", (Last visited on 15 th April 2009). [28] Microsoft, "IAsyncResult Interface", (Last visited on 28 th May 2009). [29] Saraiah G, Taqi Ali Syed, Madhu Babu J, Avinash D, Radhesh Mohandas, Alwyn R Pais, Throttling DDoS Attack, Secrypt 7 10 July 2009, Milan,Italy. [30] Carla Rosenfeld, San Diego, California, "Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks", Network and Distributed System Security Symposium

81 BIO-DATA ContactAddress : H.no. : , Hussain e Zehra Bldg, Purani Haveli, Hyderabad 2, Andhra Pradesh. e - Mail: taqiali110@gmail.com List of Publications: [1] Saraiah G, Taqi Ali Syed, Madhu Babu J, Avinash D, Radhesh Mohandas, Alwyn R.Pais, THROTTLING DDOS ATTACKS, Proceedings of SECRYPT 2009, International Conference on Security and Cryptography, Milan, Italy(7-10 July 2009). [2] Syed Taqi Ali, Radhesh Mohandas, Alwyn R.Pais, HTTPattack: An Open Source Web Stress Tool, Proceedings of Indo-Us Conference and Workshop on Cyber Security, Cyber Crime and Cyber Forensics (ICSCF 09), Kochi, India (19 21 August 2009). 68