throttling ddos attacks using integer ...isea.nitk.ac.in/publications/taqi.pdf1.1 dos and ddos...
TRANSCRIPT
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-575025
JULY, 2009
Dedicated
To
My Mother
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: ............................
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 Internal Guide
(Name and Signature (Name and Signature
with date and seal) with date and seal)
……………………………..
Chairman – DPGC
(Signature with Date and Seal)
i
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
ii
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.
iii
CONTENTS
ABSTRACT………………………………………………………………………….ii
List of Figures………………………………………………………………………...vi
List of Tables……………………………………………………………….……….viii
Nomenclature ………………………………………………………………………...ix
1. INTRODUCTION ..................................................................................................1
1.1 DoS and DDoS Attacks ...................................................................................1
What is DDoS Attack? ....................................................................................2
Symptoms of DoS Attack ...............................................................................3
1.2 Prime Number .................................................................................................3
1.3 Integer Factorization .......................................................................................3
1.4 Web Server Benchmarking And Threshold Value ..........................................4
1.5 Web Stress Tools .............................................................................................4
2. LITERATURE SURVEY .......................................................................................5
2.1 Types of DoS and DDoS Attacks ....................................................................5
2.1.1 Bandwidth Depletion Attacks ...........................................................5
2.1.2 Resource Depletion Attacks .............................................................9
2.2 DoS Countermeasures ...................................................................................17
Reducing IP Spoofed Packets .......................................................................17
SYN Cookies ................................................................................................18
SYN Cache....................................................................................................19
Prevention of Ad hoc flooding attack ...........................................................19
2.3 DDoS Countermeasures ................................................................................21
2.3.1 Taxonomy of DDoS Countermeasures ...........................................21
iv
2.3.2 Detecting a DDoS attack by analyzing client response pattern ......26
2.3.3 Client Puzzles: A Cryptographic Countermeasure Against
Connection Depletion Attacks ..............................................................................28
2.3.4 A novel approach to detecting DDoS attacks at an early stage ......29
2.4 Methods Of Integer Factorization .................................................................29
Trial Division Method...................................................................................29
Pollard p-1 Factorization Method .................................................................30
Euler’s Factorization Method .......................................................................30
Shor's algorithm ............................................................................................30
2.5 Web Stress Tools ...........................................................................................30
Shareware/Proprietary Tools ........................................................................31
2.5.1 Webserver Stress Tool ....................................................................31
2.5.2 HP LoadRunner software ...............................................................33
2.5.3 NeoLoad – Load Testing Tool........................................................34
2.5.4 WebLoad – Load Generation Engine .............................................35
Freeware Tools..............................................................................................37
2.5.5 Microsoft WAS Tool ......................................................................37
Open Source Tools ........................................................................................39
2.5.6 Apache JMeter ................................................................................39
2.5.7 FWPTT - Fast Web Performance Test Tool ...................................40
2.5.8 JCrawler – Stress Testing Tool .......................................................41
2.5.9 Curl-loader ......................................................................................42
3. PROBLEM DESCRIPTION ................................................................................43
3.1 Need Of DDoS Countermeasure ...................................................................43
3.2 Need Of Web Stress Tool..............................................................................44
4. PROPOSED SOLUTION .....................................................................................45
v
4.1 Throttling DDoS Attacks Using Integer Factorization .................................45
Description ....................................................................................................45
Countermeasures Against The Throttling .....................................................46
Methodology .................................................................................................47
Application ....................................................................................................49
Implementation Results ................................................................................50
4.2 HTTPattack: An Open Source Web Stress Tool ...........................................55
Tool Description ...........................................................................................55
Features ........................................................................................................56
Implementation Results ................................................................................57
5. CONCLUSION ....................................................................................................64
5.1 Conclusion .....................................................................................................64
5.2 Scope of Future Work ...................................................................................64
BIBLOGRAPHY .........................................................................................................65
BIO-DATA…………………………………………………………………………..68
vi
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 .............................................. 10
Figure 2.4: IP Fragmentation ....................................................................................... 12
Figure 2.5: IP Fragments overlapping ......................................................................... 13
Figure 2.7: Leaving connections half open by sending multiple SYN requests without
replying to SYN, ACK ................................................................................................. 15
Figure 2.6: TCP SYN Attack ....................................................................................... 15
Figure 2.8: TCP Connection establishment with SYN Cookies .................................. 19
Figure 2.9: Ad Hoc Neighbour nodes isolate attack .................................................... 20
Figure 2.10: DDoS Countermeasure Taxonomy ......................................................... 21
Figure 2.11: DDoS Agent-Handler Model................................................................... 22
Figure 2.12: The simple algorithm .............................................................................. 27
Figure 2.13: Client Puzzle Protocol when server is under attack ............................... 28
Figure 2.14: Result of a ramp test with 400 users using Webserver Stress Tool ........ 32
Figure 2.15: Tests using the URL script feature in Webserver Stress Tool ................ 32
Figure 2.16: HP LoadRunner Virtual User Generator ................................................. 33
Figure 2.17: NeoLoad Infrastructure ........................................................................... 34
vii
Figure 2.18: NeoLoad Tool Screenshot ....................................................................... 35
Figure 2.19: WebLoad Tool Screenshot ...................................................................... 36
Figure 2.20: WAS Tool Screenshot ............................................................................. 38
Figure 2.21: WAS Tool Cookies Screenshot ............................................................... 38
Figure 2.22: Apache JMeter with 10 HTTP URLs ...................................................... 39
Figure 2.23: FWPTT Screenshot ................................................................................. 40
Figure 2.24: JCrawler Configuration Screenshot......................................................... 41
Figure 2.25: Curl-loader Configuration File Screenshot ............................................. 42
Figure 4.1: Graph Overhead on requests/sec with fixed N .......................................... 52
Figure 4.2: Graph Server load relief ............................................................................ 53
Figure 4.3: Graph Max client requests/sec Vs Number of digits in N…..…………...53
Figure 4.4: Graph Overhead at server when p is generated dynamically .................... 54
Figure 4.5: Graph Overhead at server when p and q are dynamic ............................... 54
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 ................................ 62
Figure 4.8: Screenshot Testing Throttling DDoS Solution with HTTPattack Tool .... 62
Figure 4.9: HTTPattack Tool with all feature enabled ................................................ 63
Figure 4.10: HTTPattack Tool with zoomed graph ..................................................... 63
viii
List of Tables
Table 4.1: Number of primes in each digit .................................................................. 48
Table 4.2: Latency in milliseconds of browsers to calculate factors ........................... 51
Table 4.3: Tool Comparision Table ............................................................................. 61
ix
Nomenclature
Notation Description
DoS Denial of Service
DDoS Distributed Denial of Service
IP Internet Protocol
UDP User Datagram Protocol
USCERT United States Computer Emergency Readiness Team
ICMP Internet Control Message Protocol
RREQ Route Request
RREP Route Reply
ADOV Ad hoc On-Demand Distance Vector
MTU 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
Number of digits in n
Number of digits in p
Number of digits in q
MSDN Microsoft Developer Network
1
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.
2
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.
3
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 emails 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
4
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(b3) 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.
5
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.
2.1.1 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
6
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.
7
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
8
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, Energy-
constrained 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.
9
Figure 2.2 Ad hoc flooding attack
2.1.2 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
10
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 e-mail 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
11
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.
12
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
- 1480 bytes in the data field of the IP datagram.
- identification = 777
- offset = 0 (meaning the data should be inserted beginning at byte 0)
- flag = 1 (meaning there is more)
2nd fragment
- 1480 byte information field
- identification = 777
- offset = 1,480 (meaning the data should be inserted beginning at btye 1,480
- flag = 1 (meaning there is more)
3rd fragment
- 1020 byte (=3980-1480-1480) information field
- identification = 777
13
- 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.
14
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
15
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.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
Figure 2.6 TCP SYN Attack
16
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.
17
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.
18
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.
19
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.
20
Figure 2.9 Ad Hoc Neighbour nodes isolate attack
21
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.
2.3.1 Taxonomy of DDoS Countermeasures
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.
Figure 8: DDoS
Countermeasures
Mitigate /Stop Attacks
DDoS Countermeasures
Detect /Prevent Potential Attacks
Deflect Attacks
Detect/Prevent
Secondary Victims
Dynamic Pricing
Install Software Patches
Post - Attack Forensics
Network Service
Providers
Individual Users
MIB Statistics
Egr ess Filtering
Drop Requests
Throttling Load Balancing
Honeypots
Study Attack Shadow Real Network
Resources
Traffic Pattern
Analysis
Event Logs
Packet Traceback
Detect and Neutralize Handlers
Built - in Defenses
Figure 2.10 DDoS Countermeasure Taxonomy
22
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.
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
Figure 2 : DDoS Agent
Agent - Handler Attack Model
H
Attacker
Handler
H
Client
Victim
A A
Attacker …
…
H
A A …
H
A A …
……
Agent
s
Figure 2.11 DDoS Agent-Handler Model
23
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.
24
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
25
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.
26
Post-Attack Forensics
Traffic Pattern Analysis
If traffic pattern data is stored during a DDoS attack, this data can be analyzed post-
attack 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.
2.3.2 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
27
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.
28
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]
29
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;
30
Pollard p-1 Factorization Method
Let n be a composite integer with prime factor p. By Fermat's little theorem, we
know that ak(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 = a2 + 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.
31
Shareware/Proprietary Tools
2.5.1 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 $249.95. 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.
32
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
33
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
34
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
35
Figure 2.18 NeoLoad Tool Screenshot
2.5.4 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.
36
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 2.19.
Figure 2.19 WebLoad Tool Screenshot
37
Freeware Tools
2.5.5 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 2000. 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.
38
Figure 2.20 WAS Tool Screenshot
Figure 2.21 WAS Tool Cookies Screenshot
39
Open Source Tools
2.5.6 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.
40
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
41
2.5.8 JCrawler – Stress Testing Tool
JCrawler [23] is an open-source Stress-Testing Tool written in Java for web-
applications. 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
42
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.
2.5.9 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
43
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 http://www.stockmarket.com 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,
44
http://www.stockmarket.com 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.
45
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.
46
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
47
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).
48
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 4 5 6 7 8
NP 1061 8363 68906 586081 5096871
Algorithm 1: Generate q
GenerateQ(qdigits,NP,primes,cip)
{
cip = ”A.B.C.D”
ipMapValue = 224
*A+216
*B+28*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.
49
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 http://www.stockmarket.com 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
50
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.
51
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<1000000); 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
5 0 0.2 0 0.2 0
6 0 0.2 0 0.2 0
7 0 0.2 0 0.4 0
52
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.
8 0 1.8 0 2.2 0.01
9 6 1.8 3 2.2 0.05
10 34 16 22 18 0.05
11 44 23 28 25 0.07
12 265 134 147 147 0.43
13 318 163 169 173 5.60
14 2512 1269 1347 1398 6.62
15 4975 2475 2659 2866 44.6
16 49820 25069 19859 28173 67.5
0
20
40
60
80
100
120
100
200
300
500
750
1000
1500
2000
2500
3000
3500
4000
4500
5000
7500
1000
0
Serv
er L
oad
Requests per second
Overhead with fixed N
with solution with out solution
Figure 28 Graph Overhead on requests/sec with fixed N
53
From the graph in Figure 28 we can see that the overhead of our solution is not
significant when „N‟ is fixed.
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.
0
500
1000
1500
2000
2500
3000
8 9 10 11 12 13 14 15 16
Nu
mb
er o
f rp
s
Number of digits in N
Max Client Req/sec Vs Ndigit
0
10
20
30
40
50
60
1 2 3 4 5
Server load
Time (minutes)
Server load relief
Mixed traffic (1000 good traffic
+ 2000 bad traffic)
Good traffic (1000 req/sec)
Figure 4.2 Graph Server load relief
Figure 4.3 Graph Max client requests/sec Vs Number of digits in N
54
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.
0
20
40
60
80
100
120
8 9 10 11 12
Over
hea
d (
req
/sec
)
Number of digits in N
Overhead with dynamic p (timestamp)
0
20
40
60
80
100
120
140
8 9 10 11 12
Over
hea
d (
req
/sec
)
Number of digits in N
Overhead with dynamic p and q
85
90
95
100
105
110
115
8 9 10 11 12
Ove
rhea
d (r
eq/se
c)
Number of digits in N
Number of request/sec with 30 sec flush
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
55
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
56
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.
57
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.
58
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;
59
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
60
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 172263 requests in 10 seconds i.e. it is capable
to send 17226 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 4.10.
61
Table 4.3 Tool Comparision Table
Tool Name Scriptable
(support
dynamic
request)
Tunable Maximum
rps
(approx.)
Available as
HTTPattack Yes Yes 17000 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
62
Figure 4.7 Tests on dynamic web pages with HTTPattack Tool
Figure 4.8 Screenshot Testing Throttling DDoS Solution with HTTPattack Tool
63
Figure 4.9 HTTPattack Tool with all feature enabled
Figure 4.10 HTTPattack Tool with zoomed graph
64
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.
65
BIBLIOGRAPHY
[1] Peter Alfeld, "Notes and Literature on Prime Numbers",
http://www.math.utah.edu/~pa/math/prime.html (Nov 11, 1996).
[2] Stephen Specht,"Taxonomies of Distributed Denial of Service Attacks,
Tools, and Countermeasures", www.princeton.edu/~rblee/DDoS%20
Survey%20Paper_v7final.doc (Last visited on 5th
March 2009).
[3] Hossein Bidgoli, Handbook of Information Security, Pages: 207-219.
John Wiley & Sons, Hoboken, New Jersey (2006).
[4] RFC 4987, W. Eddy, The IETF Trust (2007),"TCP SYN Flooding
Attacks and Common Mitigations", http://tools.ietf.org/html/rfc4987.
[5] R. Praveen Sam, Dr. B. Stephen Charles, Dr. P. Chandrasekhar
Reddy, "Denial of Service attack through compromised nodes in Mobile
Ad-Hoc Networks", www.acadjournal.com volume 21, 2007.
[6] RFC 793, “Transmission Control Protocol DARPA Internet Program
Protocol Specification”. Arlington, Virginia. September 1981.
[7] RFC 3561, C. Perkins, “Ad hoc On-Demand Distance Vector (AODV)
Routing”, Nokia Research Center, July 2003.
[8] CERT/CC team, Copyright 1997, 1998 Carnegie Mellon University,
"CERT® Advisory CA-1997-28 IP Denial-of-Service Attacks",
http://www.cert.org/advisories/CA-1997-28.html, (Last visited on 5th
March 2009).
[9] CERT/CC team, Copyright 1995-2009 Carnegie Mellon University,
"CERT® Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing
Attacks", http://www.cert.org/advisories/CA-1996-21.html, (Last visited
on 5th
March 2009).
[10] Wesley M. Eddy, Verizon Federal Network Systems,1992-2009
Cisco Systems, "Defenses Against TCP SYN Flooding Attacks", The
66
Internet Protocol Journal - Volume 9, Number 4,
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-
4/syn_flooding_attacks.html.
[11] Yuji Soejima et al, "Detecting DDoS Attacks by Analyzing Client
Response Patterns", Proc., Int. Symp. on Applications and the Internet
Workshops, Pages: 98 - 101, year of Publication 2005.
[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 2006.
[13] Alfred J.Menezes, Paul C. van Oorschot and Scott A. Vanstone,
Handbook of Applied Cryptography, Pages: 87 - 93. CRC Press, Boca
Raton (2000).
[14] Wikipedia, "Euler's factorization method", http://en.wikipedia.org/
wiki_/Euler's_factorization_method (Last visited on 20th May 2009).
[15] Wikipedia, "Shor's algorithm", http://en.wikipedia.org/wiki_
/Shor's_algorithm (Last visited on 20th May 2009).
[16] Paessler the network monitoring company, "Webserver Stress Tool",
http://www.paessler.com/webstress, (Last visited on 14th
June 2009).
[17] Hewlett-Packard Development Company, "HP LoadRunner
software", https://h10078.www1.hp.com/cda/hpms/display/main/hpms_
content.jsp?zn=bto&cp=1-11-126-17^8_4000_100__, (Last visited on 24th
June 2009).
[18] Neotys Web Load Testing Solutions, "NeoLoad Evaluation - Load
Testing", http://www.neotys.com/evaluation/overviewEval.html, (Last
visited on 24th
June 2009).
[19] RaidView Software Ltd, "Web Load Open Source Load Testing",
http://www.webload.org/, (Last visited on 25th
June 2009).
67
[20] Microsoft Corporation, "Web Application Stress Tool",
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-
062a-439e-a67d-75a89aa36495&displaylang=en, (Last visited on 20th
May 2009).
[21] Apache Jakarta Project, "Apache JMeter",
http://jakarta.apache.org/jmeter/, (Last visited on 25th
June 2009).
[22] Bogdan Damian, "fwptt", http://fwptt.sourceforge.net/, (Last visited
on 25th
June 2009).
[23] Idumali, Under the CPL, "JCrawler", http://jcrawler.sourceforge.net/,
(Last visited on 26th
June 2009).
[24] Robert Iakobashvili et al., under the licensed GPLv2, "curl-loader",
http://curl-loader.sourceforge.net/, (Last visited on 1st July 2009).
[25] Syed Taqi Ali, "HTTPattack Tool", http://isea.nitk.ac.in/HTTPattack
/home.php (Last visited on 9th July 2009).
[26] Microsoft, "Naming Guidelines", http://msdn.microsoft.com/en-
us/library/xzf533w0(VS.71).aspx, (Last visited on 20th
May 2009).
[27] W3school.com, Copyright 1999-2009 by Refsnes Data, "JavaScript
Timing Events", http://www.w3schools.com/js/js_timing.asp, (Last visited
on 15th
April 2009).
[28] Microsoft, "IAsyncResult Interface", http://msdn.microsoft.com/en-
us/library/system.iasyncresult.aspx, (Last visited on 28th
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 1999.
68
BIO-DATA
ContactAddress :
H.no. : 22-8-473, Hussain e Zehra Bldg,
Purani Haveli, Hyderabad – 2,
Andhra Pradesh.
e - Mail: [email protected]
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).