RESPONSIVE SYSTEM FOR DDoS ATTACK

AGAINST APACHE WEB SERVER

Thesis

Submitted in partial fulfillment of the requirements for the degree of

MASTER OF TECHNOLOGY in

COMPUTER SCIENCE & ENGINEERING – INFORMATION

SECURITY

by

PRASHANT KULKARNI

(08IS10F)

DEPARTMENT OF COMPUTER ENGINEERING

NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA

SURATHKAL, MANGALORE-575025

June, 2010

D E C L A R A T I O N

I hereby declare that the Report of the P.G. Project Work entitled “RESPONSIVE

SYSTEM FOR DDoS ATTACK AGAINST APACHE WEB SERVER” 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 and Signature of 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 “RESPONSIVE SYSTEM

FOR DDoS ATTACK AGAINST APACHE WEB SERVER” submitted by PRASHANT

KULKARNI (Register Number: 08IS10F) 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 degree of Master of Technology in Computer Science and

Engineering – Information Security in the Department of Computer Engineering, National

Institute of Technology Karnataka, Surathkal.

Mr. Radhesh Mohandas

Adjunct Faculty

Department of Computer Engineering

NITK Surathkal

Mr. Alwyn R Pais

Assistant Professor

Department of Computer Engineering

NITK Surathkal

Chairman- DPGC

Dedicated to

My Guruji, teachers

And

family

ACKNOWLEDGEMENT

I take this opportunity to express my deepest gratitude and appreciation to all

those who have helped me directly or indirectly towards the successful completion of this

project.

Foremost, I would like to express my sincere gratitude to my guides Mr.

Radhesh Mohandas, Adjunct Faculty and Mr. Alwyn R Pais, Assistant Professor,

Department of Computer Engineering, NITK Surathkal. Their advice, constant support,

encouragement and valuable suggestions throughout the course of my project work

helped me successfully complete the project. This project drew upon the knowledge and

experience of my guides. Without their continuous support and interest, this thesis would

not have been the same as presented here.

I am thankful to Dr. Santhi Thilagam, Head, Department of Computer

Engineering for her co-operation and for providing necessary facilities throughout the

M.Tech. program.

Besides my guides, I would like to thank entire teaching and non-teaching staff in

the Department of Computer Engineering, NITK for all their help during my tenure at

NITK. Kudos to all my friends at NITK for thought provoking discussion and making

stay very pleasant.

Last but not least, I am thankful to my parents to whom I am greatly indebted for

their support and encouragement to pursue my interests.

Prashant Kulkarni

ABSTRACT

The application level Distributed Denial of Service attack (DDoS) is one of the major

threats that exhausts web server resources. Attackers often target Apache Web Server

as it is most widely used server on which majority of the business critical applications

are hosted and run 24x7. In this project we propose a solution for the detection and

prevention of DDoS attack at the web server level. Proposed scheme is based on the

concept of source throttling where the client pays a resource stamp fee which is

negligible when the client is making a limited number of requests but becomes a

limiting restriction when a large number of requests are sent. This prevents an attacker

from consuming a large portion of the server resources. We prevent an attacker from

sending large number of requests by engaging it to solve either Integer Factorization

or Discrete Logarithm Problem. Many of the available solutions are effective but

require attention of programmer to make application use the solution to thwart DDoS

attack. Hence, server is not completely shielded from the attack if solution has been

implemented for only subset of applications hosted on the same server. We

implemented aforementioned algorithms in the form of Apache modules which make

presence of our mechanism totally transparent to Web Application developer as well

as an end user and our solution introduces negligible overhead on the web server.

Keywords: DDoS, Apache Module, Integer Factorization, Discrete Logarithm

Problem, Web Server

i

TABLE OF CONTENTS

Page No.

Title Declaration Certificate Dedication Acknowledgement Abstract Table of contents i

List of figures iii

List of tables iv

Chapter I INTRODUCTION 1

1.1 Service Availability 1

1.2 Overview of DDoS Attacks 2

1.3 Background 3

1.4 Problem Statement 5

1.4 Thesis Organization 5

Chapter II TECHNICAL BACKGROUND 7

2.1 A Brief History Of DoS And DDoS Attacks 7

2.2 Introduction To DDoS 9

2.3 Underlying Causes Of DoS/DDoS Attacks 14

2.4 Classification Of DoS/DDoS Attacks 15

2.5 Representative DDoS Attacks 18

2.6 Apache Web Server 23

ii

2.7 Prime Number 26

2.8 Integer Factorization 26

2.9 Discrete Logarithm Problem 27

Chapter III RELATED WORK 28

3.1 Proposed Countermeasures 31

Chapter IV PROPOSED SOLUTION 33

4.1 CPU Threshold 33

4.2 Solution Description 33

Chapter V IMPLEMENTATION DETAILS 38

Chapter VI SECURITY CONSIDERATIONS 43

Chapter VII EXPERIMENTAL RESULTS 45

8.1 Integer Factorization Module 45

8.2 Discrete Log Problem Module 48

Chapter VIII CONCLUSION AND FUTURE WORK 50

REFERENCES 51

RESUME (Bio-Data)

iii

LIST OF FIGURES

Fig

No.

Description Page No

2.1 Three-layer Control for a DDoS Attack 10

2.2 Reflection DDoS Attack 13

2.3 Purpose DDoS Attack 17

2.4 IP Spoofing Attack 19

2.5 TCP’s Three-way Handshake 20

2.6 TCP SYN Flooding Attack 21

2.7 Smurf Attack 22

2.8 Apache Web Server Architecture 24

2.9 Apache Filters 25

2.10 Apache Buckets 25

2.11 Apache Brigades 25

3.1 Ingress Filtering 29

4.1 Communication between Client and Server 34

4.2 Communication between Client and Server 36

5.1 Schematic of modules 38

5.2 Standard response of IF 39

5.3 Standard response of DLP 39

5.4 Apache Buckets modification 41

5.5 Response generated by server when mod_ddos_IF is in use 41

iv

5.6 Response generated by server when mod_ddos_DLP is in use 41

6.1 Server load reduction 46

6.2 Number of Requests sent by the attacker 46

6.3 Response time of legitimate User 47

6.4 Server load reduction when N is fixed 47

6.5 Server load reduction 48

6.6 Number of Request sent by Attacker 48

6.7 Response time of legitimate User 48

6.8 Server load reduction when P is fixed 49

v

LIST OF TABLES

Table No.

Description Page No

1.1 General Security Goals and Threats 1

5.1 DDoS Module Parameters 42

vi

NOMENCLATURE/ACRONYMS

Notation Description DDoS Distributed Denial of Service DoS Denial of Service IF Integer Factorization DLP Discrete Log Problem

Integer Factorization N Composite Number, used to throttle the client P Prime Number, One of the factor of Composite Number N Q Prime Number, One of the factor of Composite Number N Ndigits Size of the Composite Number N (Number of Digits in N) Pdigit Size of the Prime Number P (Number of Digits in P) Qdigit Size of the Prime Number Q (Number of Digits in Q) Nold Old value of composite number N Pold Old prime P value Qold Old prime Q value Discrete Logarithm Problem P Prime number, used to throttle the client α A generator of Zp

* β An integer in finite field other than zero and one i.e., { β Zp| β

0 or 1} x Power Pdigits Number of digits in Prime P Zp A finite field

Zp

* The set of integers which are relatively prime to p i.e., Zp*= {1,

… ,P-1}

1

CHAPTER 1

INTRODUCTION

1.1 SERVICE AVAILABILITY

Internet has successfully fulfilled the expectation of empowering a single computer to

service remote requests from millions of geographically dispersed clients. With this

significant power, the Internet has been widely applied in our society, and has

increasingly become a prevalent part of human lives. People enjoy and benefit greatly

from a number of fresh nouns that belong to a new information era: eBusiness,

eCommerce, eEducation, eGovernment, eHealth and so on. These entities of public

interest are made available by means of Web Server. In consequence, the issue of how

to supply these network services reliably and securely to legitimate clients is a

growing concern among computer engineers and researchers.

Generally, authentication, integrity and confidentiality are the most important

principles of network security. However, recent reports about a number of prominent

Internet service providers that broke down because of malicious attacks urge people to

realize that all security principles must be based on service availability. It is clear that

no one can evaluate the quality of an online service that is not available.

“Availability” in this context refers to a service that can be accessed within a

reasonable amount of waiting time after a legitimate client sends a request. Table 1.1

illustrates these general security goals and the corresponding threats.

Goal Security Threat

Information Confidentiality Exposure of Information

Information Integrity Modifying/Injecting Information

Information Authentication Forged Information

Service Availability Denial of Service Table 1.1: General Security Goals and Threats

2

The service availability of a network server can be destructed in a variety of

ways, such as internal bugs within a system, hardware limits, or malicious attacks

from outside. Distributed Denial of Service (DDoS) is the term we use to refer to the

results of any intentional or accidental actions that can successfully make a legitimate

service unavailable for legitimate users.

Since other DDoS threats are relatively easy to deal with, this thesis will focus

only on the study of malicious DDoS attacks launched via the Internet at application

level. By analyzing existing countermeasures against DDoS attacks and their inherent

problems, we will propose a new defense scheme which is expected to be efficient

and effective in both practice and theory.

1.2 OVERVIEW OF DDOS ATTACKS

D. Howard (John D 1997) presented a comprehensive definition of DDoS:

If computer hardware, software, and data are not kept available, productivity can be

degraded, even if nothing has been damaged. Denial of Service can be conceived to

include both intentional and unintentional assaults on a system’s availability. The

most comprehensive perspective would be that regardless of the cause, if a service is

supposed to be available and it is not, then service has been denied.

A Cyber world DDoS attack is designed to flood server with numerous

spurious requests, crushing its infrastructure, depleting its bandwidth, computational

capacity or system stack memory, and eventually crashing it. In consequence,

legitimate clients have to experience a service downtime, and victim servers may lose

millions of dollars.

One of the most popular DoS attacks called TCP SYN flooding attacks had

been reported by several major newspapers in 1996. These attacks succeeded in

crippling Panix, a major New York Internet service provider in early September 1996

and created similar problems for the website of the New York Times just a few days

later. As a rule, a SYN flooding attacker exploits spoofed IP addresses to mount a

large number of initial and unresolved connection requests to a victim server,

depleting its resources and rendering it incapable of responding to legitimate clients.

According to an advisory issued by CERT on September 19th, 1996, several

3

underground magazines pushed the spread of DoS attacks ahead by publishing source

codes and automated tools for launching TCP SYN flooding attacks.

Distributed Denial of Service (DDoS) was rapidly brought to the public’s

attention after eBay, Amazon, Yahoo and several other prominent commercial

websites fell victim to this new form of DoS attacks on February 9th, 2000. Relying

on the fast spread of Internet worms (Wu Chang 2003), a DDoS attacker is able to

easily manipulate thousands of vulnerable computers in the Internet to launch a large-

scale DoS attack to a target. Compared with traditional ones, the strength of DDoS

attacks can be multiplied by 10, 100, or even 1000, and the effect on the Internet is

therefore immeasurable. In a worst case scenario, as the above incidents have

demonstrated, even if an Internet server possesses very large bandwidth and

resources, and is protected by a reliable firewall system, it is still vulnerable to a range

of Distributed Denial of Service attacks.

1.3 BACKGROUND

A countermeasure against counterfeit clients is to perform authentication before any

communication and resource allocation. However, conventional authentication

schemes based on public-key infrastructure (for example, RSA and DSS) will no

longer meet the demand for DDoS defense. This is because most of them require a

server to conduct expensive computations, such as modular exponentiation, and store

a large amount of session information for each client which actually opens up new

opportunities for DDoS attacks. Therefore, a more effective and inexpensive approach

to defend against DoS attacks is desirable.

So far, several approaches have been proposed in the literature (F. Kargl 2001,

T. J. Ott 1999), among which Client Puzzle is one of the most notable and influential.

Earlier work (B. Bencsth 2003, T. Aura 2001, T. J. Ott 1999) showed that the client

puzzle mechanism is capable of alleviating or confining DDoS attacks to a harmless

level in theory. The aim of client puzzles is to destroy DDoS attacks by forcing every

suspected adversary to consume a number of computational resources (Client side)

before it is granted access to the resources of a server. In contrast to traditional

authentications, client puzzles seem weak, yet are inexpensive and efficient in

4

determining whether a connection request is sent by network worms (A. Wagner

1999, Wu Chang 2003).

The idea of client puzzles was first introduced as an access control mechanism

by Dwork and Naor in 1992 (C. Dwork 1992). They proposed a system for junk mail

defense in which every successful delivery of a message requires the sender to solve a

small cryptographic puzzle. By doing so, they successfully impose a large amount of

computational costs on sending mass mails, while for legitimate clients; the costs to

compute single puzzles are negligible. The concept of Source Throttling is

synonymous with client puzzle.

Combining the idea of a stateless protocol (C. Dwork 1992) and Client Puzzle,

Juels and Brainard (Juels 1999) proposed a Client Puzzle Protocol to protect network

servers against SYN flooding attacks. This protocol emphasizes that no memory

should be allocated before client authentication, and that the client is the one who

pays for the authentication. Generally speaking, when there is no DDoS attack alarm,

a defending server accepts and responds to connection requests as normal. However,

if the server is suspected of being under attack, it will send a small cryptographic

puzzle to each client applying for a service before allocating any system resources to

them. Only the request belonging to the client who returns the correct answer is

allowed to proceed. The cost of computing a single puzzle is trivial for legitimate

clients, yet unbearably expensive for a DDoS attacker who attempts to consume

considerable resources from the server. Moreover, the complexity of cryptographic

puzzles can be adjusted by an administrator, according to the strength of the attack

received. In their paper, Juels and Brainard also presented a simple puzzle

construction to implement their protocol, although this seemed unsatisfactory and

caused a lot of arguments in network forums.

Following this, a few researchers attempted to improve puzzle construction

within the framework of the Client Puzzle Protocol. Aura and Nikander (T. Aura

1997) proposed a hash function based puzzle scheme in which a client needs a brute-

force search for the correct answer, and a server performs a hash function to verify the

solution. Waters and Juels (J. A. Halderman 2004) suggested a new technique that

permits the outsourcing of puzzles. However, even puzzles can be used by different

5

servers, and the solution of a puzzle still requires one modular exponentiation for

every defending server.

In general, these proposed puzzle schemes are less capable of meeting the

requirements of client puzzles. Improper usage of these unqualified puzzles, on the

other hand, will lead to DDoS attacks.

1.4 PROBLEM STATEMENT

Most of the organization leverages on Apache Web Server for hosting their web

applications. There are no major solutions for the DDoS attack implemented in the

Apache web server module. The mod_evasive module is used to secure Apache Web

Server from DDoS. It is an implementation of web application firewall. It prevents

DDoS by discarding requests for a particular IP for which number of requests has

exceeded the threshold. This naïve approach does not take into account spoofed IP

and hence genuine user can also be victimized.

Since the most of the web applications are hosted on the Apache Web Server,

it is very important to have a mitigation mechanism built inside it for the DDoS

Attacks. The existing approaches rely on IP based filtering which do not mitigate the

DDoS attack efficiently because of IP spoofing.

Hence, it becomes essential to design a new mechanism for DDoS attack for

the Apache Web Server instead of conventional IP based mechanism. We intend to

use source throttling mechanism to mitigate the DDoS attack. Overall, we intend to

solve the problem of DDoS attack on Apache Web Server using Integer Factorization

and Discrete Log problem to throttle the client.

1.5 THESIS ORGANIZATION

The rest of the thesis is organized as follows. Chapter 2 introduces DoS attacks, and

analyzes potential reasons for their existence. We will give a broad overview of DoS

attacks and their attack modes by depicting a number of prevalent examples, such as

SYN flooding and Smurf. Existing proposed countermeasures will be described in

Chapter 3, along with an analysis of their advantages and disadvantages. Chapter 4

presents proposed solution using integer factorization and discrete log problem.

6

Chapter 5 discusses implementation details of integer factorization and discrete log

problem in the form of Apache modules. In Chapter 6 we will discuss security

measurements. Effectiveness of proposed solution using Integer Factorization and

Discrete Log Problem are discussed in Chapter 7. Finally Chapter 8 concludes the

thesis along with the future work.

7

CHAPTER 2

TECHNICAL BACKGROUND

Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks have been

around for years, but it seems that people still cannot find a proper way to deal with

them. This chapter intends to provide an overview of DoS/DDoS attacks and related

tools/methodologies used to materialize this kind of attacks.

This chapter begins with a brief history of DoS attacks, which leads to a

review of their evolution. We then highlight factors that contribute to significant surge

in DDoS attacks. DDoS attacks will be classified according to their characteristics,

and several notorious DDoS attack approaches will also be described in this chapter.

2.1 A BRIEF HISTORY OF DOS AND DDOS ATTACKS

Most people were not aware of the urgency of DDoS attacks, until a number of

famous Internet service providers were brought down in February 1996. However,

earlier than this, in 1988, an incident happened which was ignored, maybe because the

Internet was relatively unknown at that time. The Morris worm, a self-replicating

program created by Robert T. Morris Jr., successfully disrupted the Internet for nearly

48 hours in the city of California (Morris Internet Worm). That was the first taste of

DoS attacks.

After ten years of development, DDoS attacks appear more sophisticated and

difficult to solve. Before 1999, DoS attackers might have exploited IP spoofing and

flaws in existing network protocols to mount attacks from a single source to a single

target. A series of advisories issued by CERT between 1996 and 1998 reported these

attacks, such as SYN flooding, Smurf, ping of death, etc.

In 1999, several Distributed Denial-of-Service tools (Trinoo, TFN and

“stacheldraht”) were reported by CERT for the first time. The fear about larger-scale

attacks proved to be true by the events that happened in February, 2000, when

eminent websites like Yahoo, CNN.com and Amazon, which were protected by

powerful firewall systems and possessed huge bandwidth and system resources, were

still brought down by DDoS attacks.

8

The most common process for launching DDoS attacks consists of three steps:

1. Scan vulnerable computers across a wide range of the Internet.

2. Intrude these victims and install malicious scripts for mounting an attack.

According to different types of scripts, these infected computers are categorized as

“Masters” or “Zombies”.

3. An attacker communicates with “Masters” only, instructing them to transfer

an attack order to “Zombies”, which will finally mount the real attack.

Before 2000, most DDoS attacks were required to scan vulnerable victims

manually, and list them for later intrusion. The attacks took the form of multiple

sources to a single target at this stage.

From 1996 to 2000, several countermeasures against DoS/DDoS were

proposed, such as SYN cookies (Bert Slagter 2009), Filtering mechanisms (B.

Bencsth 2003), Congestion Control (J. Ott 1999, R. Stone 2000), etc. However, none

of them seemed good enough to tackle and stop the violence of DoS attacks.

Since 2001, the quick evolution of DDoS attacks is even more terrifying.

Attackers who deploy self-propagating network worms like the notorious Code Red

and advanced scanning strategies (A. Wagner 1999) can easily compromise more than

ten thousand unwitting “accomplices” in a few hours. Stefan Savage, a network

researcher from CAIDA (Supercomputer Center’s Cooperative Association for

Internet Data Analysis) pointed out that, “With that kind of firepower, they could

have taken down anything” (F. Kargl 2001). Scientists admit that with a little

improvement, Code Red could render an arbitrary network incapable of

communicating with the outside world. This is a new phase of DoS attacks which can

be launched from multiple sources to multiple targets.

Furthermore, communication between “Zombies” and “Masters” can be

encrypted by DoS tools such as “stacheldraht”, and be transferred via IRC channels

(Kevin J 2001) which offer anonymous service for their users. All of these factors

make it more difficult to detect and trace a DDoS attack.

9

2.2 INTRODUCTION TO DDOS

Distributed Denial of Service (DDoS) is a new form of DoS attack, first reported in

early 2000. In contrast to traditional DoS attacks, DDoS attackers, in particular, are

armed with self-propagation worms which can be installed on a discretionary number

of vulnerable computers on the Internet. An attacker is able to harness these

compromised machines in order to mount a coordinated DoS attack. These infected

machines are typically divided into two groups: “Masters” and “Zombies”, which play

different roles in a DDoS attack. “Masters” are more like an intermediary, while

“Zombies” serve as attack platforms. Communication between an attacker and the

“Zombies” is not direct, but depends on the “Masters”. One “Master” may control and

deliver the attacker’s command to a number of “Zombies”. By mounting such a

coordinated DoS attack, the effectiveness of a DDoS can be multiplied by 10, 100, or

even 10,000 times (John Elliott 2000).

A typical DDoS attack process can be described as follows. An attacker first

scans a large range of networks to find vulnerable hosts that have weak defenses

against a malicious intrusion. The number of these hosts is determined by the strength

of the attack that an attacker intends to launch. Second, the attacker installs “Master”

or “Agent” programs on these vulnerable hosts. A machine with an “Agent” program

is called a “Zombie”, which carries out the actual attack. A machine installed with a

“Master” program is able to communicate with a number of “Zombies” and serves as

a control-handler of the attacker. An attacker can command several “Masters”

directly, and “Zombies” are activated by these “Masters” at the designated time for an

attack. Figure 2.1 shows this three-layer control. The reason for using such

architecture is to keep the attacker safe and difficult to trace. Now, all the preparation

has been accomplished. The attacker only needs to cross his fingers and wait for an

appropriate time to launch his DDoS attack. When a defending server suspects that it

is under a DoS attack, it can only find numerous legitimate connection requests

received from a large number of legitimate IP addresses, consuming all the resources

of the server. However, the real owners of these “Zombies” are unwitting accomplices

(F. Kargl 2001), and do not know what has actually happened on their machines.

10

The improvements in DDoS attacks can be summarized as having two main

features.

Figure 2.1: Three-layer Control for a DDoS Attack

One is that DDoS attacks may effectively bypass IP spoofing defense

mechanisms. Before 2000, researchers exploited ingress/egress filtering edge routers

to stop most packets with spoofed IP addresses. This forced the attacker to perform IP

spoofing by using only the addresses from his own network. A simple and powerful

solution against these attacks is to filter all packets from one suspected network in

order to ensure service for legitimate clients from the rest of the Internet.

Unfortunately, DDoS attacks can pass around this filter by launching attacks from

different networks. It would be pointless for a network service provider to block all

request packets from so many networks. The other characteristic is that a DDoS

attacker can amplify attack traffic immensely by using self-propagation worms to

compromise sufficient computers on the Internet. He can manually or automatically

scan the Internet to find each vulnerable machine on N networks as his “Zombie”.

One “Zombie” issues 1/N traffic load to a target server. If N is big enough, it may

bring down any target and cause an incredible amount of damage.

11

2.2.1 DDoS Tools and Technologies

Usually, attackers utilize professional tools to launch attacks. Sub7, TFN,

Trin00 and “Stacheldraht” are older DDoS tools while Kaiten, GTbot, sdbot appear to

be more recent (F. Kargl 2001). Nearly all DDoS tools, however, need some core

techniques to accomplish attacks, such as scanning, propagation, and communication.

These techniques are usually exploited before real attacks start, but serve as vital

points in DDoS attacks. In the following section, we will describe these methods.

(a) Scanning

Scanning is the first step in launching DDoS attacks. What attackers scan for are

vulnerable machines/systems existing within the entire Internet. “Vulnerable”, in this

context, means that these machines/systems are subject to intrusion attacks, since

most of them have weak or even no defense systems, such as firewall or antivirus

software. Some of them may have a number of system bugs and have not been fixed

in time. All of them offer the opportunity for attacks to intrude these

machines/systems and leave unnoticeable codes for malicious intentions. In early

DDoS attacks, an attacker had to personally scan and identify all the potential targets

he/she required, storing their addresses into a list. This list was used to direct

compromised machines to recruit more “Masters” and “Zombies”. More recently, this

situation has been changed by network worms like Code Red, which can fulfill the

process of scanning-detection-infection-propagation automatically, without any

direction from attackers (A. Wagner 1999). A scanning strategy is a method for

selecting the next machine to be probed. A primitive type is random scanning

strategy, in which compromised machines probe random IP address for potential

targets. Sometimes this technique can lead to network congestion, since many

machines may detect, and try to intrude, the same IP address simultaneously. Hitlist

scanning can avoid this problem by recording all the machines that have been

detected and compromised. This technique is utilized to speed up the initial slow

phase of worm propagation. More details and other scanning strategies can be found

in (P. R. J. Mirkovic 2002).

12

(b) Propagation

Today automated propagation has been developed into three general models (Kevin J

2001): the central source propagation, the back-chaining model and the autonomous

model. In central source propagation, the attack code is stored in a central server or

set of servers. Propagation is fulfilled by an intrusion transferring a copy of the attack

code from the central source to a newly compromised system. During back-chaining

propagation, a system which is intended to compromise other potential targets, serves

as a central source from which the attack code can be delivered to others. The newly

infected machines then become the source for the next propagation (P. R. J. Mirkovic

2002). In contrast with the central source propagation, this model ensures a smooth

delivery for the attack code. Autonomous propagation can directly inject a vulnerable

machine with the attack code, without downloading or copying it from the external

source, saving the file retrieval phase.

(c) Communication

Communication mechanisms are another important issue not only for DDoS attackers,

but also for security engineers. If communication packets from an attacker to

“Masters”, or from “Masters” to “Zombies”, can be detected ahead of real attacks,

according to the destinations of these packets, the compromised machines can be

identified and removed easily. However, as time goes by, communication channels for

DDoS attacks are becoming more difficult to detect. Early DDoS tools used

TCP/UDP packets for communication, which are relatively easy to identify using

network monitoring tools, such as Intrusion Detection Systems (IDS). Then attackers

found the Internet Relay Chat (IRC) provides a sufficiently anonymous environment

for communicating with “Zombies” directly, which makes it more difficult to identify

DDoS networks (Kevin J 2001).

2.2.2 Attack Network Topologies

There are two major topologies in DDoS attacks: direct attacks and reflection attacks.

The architecture of direct attacks has been demonstrated in figure 2.1. An attacker

controls several “Masters” that are responsible for transmitting the attack command to

a number of “Zombies”. At a designated time, all the “Zombies” launch a direct

13

DDoS attack by flooding a victim with numerous bogus requests. The attack

command flows along the following path:

Attacker → Masters → Zombies → Victim

The architecture of a reflection DDoS attack is illustrated in figure 2.2. Denote

network (a), which consists of all the “Masters” and “Zombies”, as the attack

network. Network (b) represents a large number of well-meaning and innocent

servers, which unfortunately act as reflectors in a reflection DDoS attack. Many of

these reflectors possess broadband or good connectivity, such as Internet server

providers. In this kind of attack, by manipulating attack network (a), an attacker can

mount many initial requests carrying a target’s IP address to innocent systems in

network (b). These systems will unwittingly reply and return corresponding messages

to the victim, which can easily exhaust the victim’s bandwidth and lead to severe

network congestion. In reflection DDoS attacks, it is more difficult to detect malicious

packets on the Internet, and much harder to find clues to the attack network or the

attackers’ real IP addresses.

Figure 2.2: Reflection DDoS Attack

14

2.3 UNDERLYING CAUSES OF DOS ATTACKS

2.3.1 Social Factors

Everything exists for a reason. If the first appearance of the Morris worm was due to

intellectual curiosity (Morris Internet Worm), the prevalence of DDoS attacks

nowadays has a much more realistic basis in this for-profit society.

First of all, business or commerce being performed via the Internet means high

profit and time sensitiveness (X. Geng 2002). A successful DDoS attack may lead to a

victim losing thousands of dollars per minute. Hence, a DDoS attack may aim to

commit a commercial crime or take personal revenge. In addition, the purpose of

bringing down popular Web servers can also be to gain a reputation among hackers’

community.

More evidence indicates that the tools to automatically launch DDoS attacks

that disperse within the Internet have become another serious problem. Even a

network illiterate can mount a considerable DDoS attack by using these tools. This

situation is not acceptable in today’s Internet, where numerous monetary transactions

are handled. What we need is not only a good solution to defend against these DDoS

attack tools, but also a complete policy to rule the activity of information providers in

the Internet. Unfortunately, this idea seems far from actual practice and difficult to

achieve.

2.3.2 Architectural Factors

The Internet was created for functionality, not for security. It can supply worldwide

clients with quick, easy and inexpensive communication channels, and can be

gradually reinforced by diverse levels of network protocols that ensure the reliability

and timely delivery of communication. However, the booming growth of the Internet

also leaves a lot of concealed damage and other serious issues for security researchers.

One problem of the Internet is that network resource is limited and

consumable (Kevin J 2001). Bandwidth, processing power or memory of a network

device all have their maximum capabilities. When a network computer provides

service to a mass of remote clients, it simultaneously creates the possibility of making

a single computer fight against a large number of network resources. If the goal of an

15

attack is to deplete the victim’s resources, this can always be achieved in theory, as

long as it carries with a sufficient amount of resources, such as a large number of

bogus connection requests. Actually, this is why DDoS attacks are successful.

Another problem is that “Internet security is highly interdependent” (Kevin J

2001). For example, DDoS attacks generally launched from systems or networks that

are undermined through security-related compromises. That means, no matter how

perfectly the target system might be protected, its susceptibility to DDoS attacks

depends on the security status of the rest of the global Internet.

The last but not the least issue is the hasty deployment of network protocols.

Most of them are designed to meet the demands of industry, and are hastily applied to

widespread network servers and routers. SYN Flooding and IP spoofing attacks

exploit TCP/IP. A server based on SSL protocol (Eran Gabber 1996) is subject to

DDoS attacks, because the protocol requires the server to perform a computationally

expensive verification operation to initiate a SSL connection. An attacker may easily

overwhelm the server by flooding it with invalid connection requests.

2.4 CLASSIFICATION OF DOS ATTACKS

Before discussing details of specific examples of DoS attacks, it is useful to classify

DoS attacks according to their characteristics. Some researchers have undertaken this

work in distinct ways. Readers can refer to (P. R. J. Mirkovic 2002, F. Kargl 2001, Y.

Xiang 2004) for more information. Here, we provide two kinds of classification.

1. One possible classification of DDoS attacks according to the aims of attacks could

be:

• System destruction: The target of this type of attack is the hardware of

network devices, such as electricity power, network lines, and so on. These attacks are

easy to detect, and can be solved quickly by switching on the backup power system,

or recovering the communication lines. Besides these physical attacks, the limitations

of hardware, such as a Network card or CPU with too small capability is also an

attack point in this category.

16

• Implementation bugs: Sometimes attackers may search for specific bugs in

network systems, or scan improper configurations of firewalls or routers to launch

their attacks. These system and application faults may be caused by the ignorance of

administrators, or software bugs. The general solution is to install patches timely, and

examine important input and output data for network devices regularly and patiently.

• Resource consumption: A service provided by a server can be viewed as a

shared resource in the Internet. A DDoS attacker who aims at resource consumption

can exploit bogus requests to deceive the victim server into repeatedly granting the

resources to him, until it is exhausted or unavailable for other legitimate clients. This

type of attack is more difficult to tackle, because most of them make use of the

weaknesses of existing network protocols. In fact, their malicious requests appear no

different from legitimate ones and ordinary defense systems are incapable of detecting

them. Our solution tries to thwart attacks that exhaust server’s resources and hence it

falls in to this category of attacks.

According to the definition of resource, forms of attack can be further divided

into distinct parts as follows:

– System resource: This includes CPU processing capability, storage

capability, buffer space, etc. Attackers cripple a victim by forcing it to process more

than it can handle. Notice that this result is not due to the low capability of the

hardware. In fact, attackers take advantage of the flaws of several protocols to

unlimitedly amplify the effect of DoS attacks. As we discuss later, TCP SYN flooding

attacks belong just to this category.

– Bandwidth: When installing a network device, such as a server, a router or a

firewall, the administrator will configure the maximum bandwidth or maximum

connectivity. The aim of these attackers is to force a server to deplete its connectivity

or obstruct the network by flooding large amounts of traffic packets. A Smurf attack

forces routers to stop forwarding packets due to network congestion.

17

2. The other classification relies on the evolution of DoS attacks, and three attack

modes can be identified:

• Single-to-Single: Early DoS attacks, such as IP Spoofing attacks and TCP

SYN flooding attacks, belong to this category. They exploit spoofed IP addresses to

cheat a victim server to drain down resources. But actually, they only use their own

system resources to perform these attacks. As a result, the power and impact of these

attacks are relatively impotent. Furthermore, they are less available to launch attacks

that aim at bandwidth consumption.

• Multiple-to-Single: Early Distributed DoS attacks take advantage of

network worms to compromise vulnerable machines on the Internet. These raw

recruits are used to launch a cooperative DoS attack. In combination with the attack

methods used in Single-to-Single, many systems with less resource can attack a much

larger system.

• Multiple-to-Multiple: Nowadays, more sophisticated DDoS attacks can

easily overwhelm a target network that may include several network servers.

Although several countermeasures and DoS Detect systems have been applied to

mitigate the force of large-scale DDoS attacks, the data on DoS attacks each week

indicate that they are still far from being prevented. the following figure 2.3

summarizes the above classifications:

Figure 2.3: Classification of DDoS Attack

18

2.5 REPRESENTATIVE DDOS ATTACKS

2.5.1 IP Spoofing

IP spoofing means to cheat others by using false IP addresses instead of one’s own as

shown in figure 2.4. Strictly speaking, IP Spoofing alone is not a DDoS attack, but an

important step in those attacks. Nearly all successful DDoS attacks need to cooperate

with this technique in order to conceal attackers’ real IP addresses and avoid IP

tracing.

At the beginning, IP spoofing was used by attackers to gain unauthorized

access to remote systems. In 1995, one year before the appearance of SYN flooding

attacks, CERT reported several IP spoofing attacks, in which attackers could obtain

root access to victim systems by making use of applications that used authentication

based on IP addresses.

When a client wants to establish a TCP connection, a program can be used to

generate a socket, automatically filling the header field of an IP packet with the

source address. However, there exists APIs to create raw sockets whereby attacker

can manually set the source IP address which would be different than its own. Due to

the fact that the routing strategy only considers IP destination addresses, the

correctness of IP source addresses is unfortunately ignored (Thomer M. 2001).

In some cases, an attacker can use IP spoofing to launch a small-scale DoS

attack, as in the following scenario, albeit that the strength of this attack is limited. An

attacker A forges B’s IP source address and sends a lot of packets to different

destinations. As a rule, all the returning IP packets flow to B which may lead to

network congestion.

19

Figure 2.4: IP Spoofing Attack

2.5.2 TCP SYN Flooding

Taking advantage of the imperfections of the TCP connection establishment protocol

( A. Juels 1999) , attackers launch TCP SYN flooding attacks by bombarding a target

server with many “half-open” connections which leads to the victim’s connection

capability being depleted, so that it becomes unavailable for other legitimate clients.

Normally, establishment of a TCP connection requires that both sides

exchange an orderly sequence of messages. This process is commonly called TCP’s

three-way handshake. The client begins this protocol by sending a SYN message to

the server which is listening to connection requests from the network. Acknowledging

the SYN message, the server returns a SYN-ACK message to the client and

meanwhile prepares for this connection by distributing a piece of buffer space to store

session information. The client completes the protocol by replying to an ACK

message. Now, the connection is established, and the service-specific data can be

transferred between the client and the server. Figure 2.5 illustrates this three-way

handshake connection.

20

Figure 2.5: TCP’s Three-way Handshake

There are at least two shortcomings in this TCP connection establishment

protocol. One is that the authentication is based on source IP addresses, whereby an

attacker may perform IP spoofing. Before receiving the final ACK message, the

server has already allocated buffer space for this connection, and must keep it until a

timeout. Taking advantage of this point, an attacker can exhaust the buffer space of

the target server by sending a sufficient number of “half-open” connections. TCP

SYN flooding attack shown in figure 2.6

In this attack, the attacker uses IP spoofing to forge large amounts of initial

connection requests (SYN messages), and mount them to a target server. These

requests appear to be legitimate and are not filtered by firewall or other defense

systems. The server responds with SYN-ACK messages, and allocates buffer space

for each connection. Although the time for keeping these reserved buffer space is

short, the space can eventually be exhausted, and the server then fails to respond to

other legitimate clients, as long as the attacker floods numerous connection requests

repeatedly. This attack effectively prohibits normal clients from visiting the target

server. That is the reason for its prevalence in the hackers’ community.

21

Figure 2.6: TCP SYN Flooding Attack

According to the advisory of CERT, any system connected to the Internet and

providing a TCP-based network service (such as Web Server, FTP server, or mail

server) is potentially vulnerable to this kind of attack.

2.5.3 Smurf

Smurf attacks make use of forged ICMP echo request packets and IP broadcast

addresses to overwhelm a victim system with large amounts of ICMP echo reply

packets that are sent from an intermediary site. The Internet Control Message Protocol

(ICMP) is used to inspect errors and send control messages. It is also used to check

whether a network device is responding. Hence, if a machine receives an ICMP echo

request packet, it will respond with an ICMP echo reply packet. Figure 2.7 illustrates

this smurf attack.

On the Internet, a packet can be transferred to an individual IP address or

broadcast to an entire subnet, depending on whether the destination address is an IP

broadcast address. Via an IP broadcast address, a packet can be delivered to all

machines on that subnet. In a typical Smurf attack, three parties play different roles:

22

an attacker, an intermediary and a victim. Using IP spoofing, the attacker forges an

ICMP echo request packet with the victim’s source address, and sends it to an IP

broadcast address. When all the machines in the intermediary’s network receive this

packet, they send ICMP echo reply packets directly to the spoofed IP address, which

actually belongs to the victim. This may cause severe network congestion in the

victim’s local network. The targets of this attack may include not only the victim host,

but also routers and communication lines connected to the victim’s local network. The

function of the intermediary site is to amplify the amount of traffic that flows to the

victim’s address. In consequence, some researchers refer to this site as an amplifier

site (F. Kargl 2001).

Tools for launching this type of DDoS attack have been developed, which can

spread these attacks to multiple intermediaries simultaneously, and lead to much

larger attacks. In other cases, the target of Smurf attacks can be the intermediary

directly. If all the machines on that network respond to one or several ICMP echo

requests, it will certainly cause severe network congestion and outage. In particular, if

an attacker can force routers to stop forwarding packets, then all the hosts behind

those routers are effectively disconnected.

Figure 2.7: Smurf Attack

23

2.6 APACHE WEB SERVER

The Apache is the powerful web server that has played a major role in both the

growth and continuous development of a web. As a free open-source solution, it backs

up most popular operating systems including Microsoft Windows, Linux, UNIX,

FreeBSD, Mac OS X and Solaris. The Apache web server is entirely modular in

structure. All the features and functions are available as modules. One of the biggest

advantages of Apache over other web servers is its scalable architecture that enables

plugging custom modules to complement/enhance the functionality of apache. We

used Apache Web Server version 2.2.13 for Linux. We decided to incorporate DDoS

prevention functionality in the Apache Web Server due to its widespread use and

popularity. Apache's modular software design allows third party modules to be easily

incorporated into the server. The system administrator can choose modules to suit

their business and security requirements.

2.6.1 Apache Module

Modules are pieces of code which can be used to provide or extend functionality of

the Apache HTTP Server. Modules can either be statically or dynamically included

with the core. For static inclusion, the module's source code has to be added to the

server's source distribution and to compile the whole server. Dynamically included

modules add functionality to the server by being loading as shared libraries during

start-up or restart of the server. In this case the module mod_so provides the

functionality to load modules dynamically. In a current distribution of either Apache

2.0 or Apache 1.3, all but very basic server functionality has been moved to modules.

The general architecture of Apache web server is shown in figure 2.8.

The core data structure in a module is the 'module' structure (Nick Kew 2007).

When building a module, the application developer defines this structure and fills it

with the appropriate functions calls which should be run in order to invoke the

operations for the module. The module structure for mod_log_config.c, is as follows:

module config_log_module = { STANDARD_MODULE_STUFF, init_config_log, /* initializer */ NULL, /* create per-dir config */ NULL, /* merge per-dir config */

24

make_config_log_state, /* server config */ NULL, /* merge server config */ config_log_cmds, /* command table */ NULL, /* handlers */ NULL, /* filename translation */ NULL, /* check_user_id */ NULL, /* check auth */ NULL, /* check access */ NULL, /* type_checker */ NULL, /* fixups */ config_log_transaction /* logger */ }; The NULL entries in this table refer to portions of the server API which the

config_log_module does not use.

Figure 2.8: Apache Web Server Architecture

25

2.6.2 Apache Filters

Apache 2 Filters are handlers for processing data of the request and the response

(Nick Kew 2007). They have a common interface and are interchangeable.

Figure 2.9: Apache Filters

In figure 2.9 you see two examples filter chains: The input filter chain to process the

data of the request and the output filter chain to process the data of the response

(provided by the content handler). The agent “Request processing” triggers the input

filter chain while reading the request. An important use of the input filter chain is the

SSL module providing secure HTTP (HTTPS) communication.

The output filter chain is triggered by the content handler. In our example, the

Deflate output filter compresses the resource depending on its type.

Figure 2.10: Apache Buckets

Figure 2.11: Apache Brigades

26

To improve performance, filters work independently by splitting the data into

buckets and brigades shown figure 2.10 (Nick Kew 2007) and just handing over

references to the buckets instead of writing all data to the next filter's input shown in

figure 2.11 (Nick Kew 2007). Each request or response is split up into several

brigades. Each brigade consists of a number of buckets. One filter handles one bucket

at a time and when finished hands the bucket on to the next filter. Still the order in

which the filters hand on the data is kept intact.

2.7 PRIME NUMBER

There are two types of natural numbers: primes and composites. 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 primality tests on it.

2.8 INTEGER FACTORIZATION

In number theory, the integer factorization (Arjen K 2004) problem is the problem of

finding a non-trivial divisor of a composite number. When the numbers are very large,

no efficient algorithm is known. The difficulty of this problem is at the heart of

certain algorithms in cryptography such as RSA. The prime factorization requires

splitting an integer into factors that are prime numbers; by the fundamental theorem

of arithmetic, every integer has unique prime factors. Multiplying two prime integers

together is easy as compared to factoring the composite number into two primes. No

good algorithm exists to solve this problem in polynomial time and the best algorithm

that solves this problem with a least complexity is the general number field sieve in

O (exp ((64/9b) 1/3 (log b) 2/3)) for a b-bit integer.

27

2.9 DISCRETE LOGARITHM PROBLEM

The discrete logarithm problem (Chris Studholme 2002) is defined as: Let P be an

odd prime, Zp = {0, 1, … ,P-1} is a finite field, Zp* a set of integers which are relative

prime to P i.e Zp* ={ a Zp | gcd (a, P)=1} Zp* ={1,…, P-1}.α is a generator in

Zp such that β αx mod P. Given α, β and P, the problem of finding x such that

previously mentioned equality holds is known as discrete logarithm problem (DLP). It

is the basis of several cryptographic systems, including the Diffie-Hellman key

agreement used in the IKE (Internet Key Exchange) protocol. The useful property is

that exponentiation is relatively easy but the inverse operation, finding the logarithm

is hard. The cryptosystems are designed so that the user does only easy operations

(exponentiation in the field) but an attacker must solve the hard problem (discrete log)

to crack the system.

28

CHAPTER 3

RELATED WORK

The earlier chapters gave sufficient background and understanding of DDoS attacks.

This chapter elucidates methodologies, algorithms proposed/implemented by

community working towards thwarting this kind of attacks.

3.1 PROPOSED COUNTERMEASURES

To prevent DDoS attacks, many defense mechanisms have been proposed. Various

firewalls and router configurations have been suggested by network administrators

and commercial vendors. Protocol designers are also trying to improve existing

protocols to make them resistant to DDoS attacks. However, most of them inevitably

have potential disadvantages, and are not capable of successfully defending against

DoS/DDoS attacks.

After that, a number of current countermeasures against DDoS attacks will be

introduced, such as Packet Marking, Filtering techniques, SYN cookies, and so on.

These countermeasures’ objectives, working theories, merits and limitations will also

be analyzed.

Before introducing several proposed countermeasures, we look briefly at the

differences between the Internet and the traditional phone network, which does not

often suffer from malicious denial of service attacks. There are three reasons for this.

First, every connection request (call) binds tightly with its real address (phone

number). It is fairly easy to identify an attacker. Second, it seems impossible in the

phone network where an attacker exploits worms/viruses to compromise other

telephones for a cooperated DoS attack. The last reason is that a DoS attack launched

via the traditional phone network requires a lot of resources, including human

resources, money and time.

According to these reasons, scientists and researchers strive to find similar

ways to resolve DoS problems. Ingress/Egress filtering and packet marking can be

used to obtain a relatively reliable IP address. Client puzzles are deployed to increase

the cost of launching DoS attacks. A number of anti-virus softwares and intrusion

29

detection systems have been developed to detect and stop the spread of network

worms. In this section, we provide a brief introduction to current defense methods.

More information can be obtained from the following literature: Trackback IP ( K.

Park 2001), Ingress /egress filtering ( P. Ferguson 1998), SYN cookies ( Bert Slagter

2009), Client Puzzle ( T. Aura 2001, J. A. Halderman 2004, Wu Chang 2003, T. J. Ott

1999).

3.1.1 Ingress/Egress Filtering

The aim of filtering is to stop packets with spoofed IP addresses from reaching a

target server. To date, two primary methods have been studied: ingress filtering and

egress filtering (Y. Xiang 2004). Ingress filtering is applied on the external interface

of a network (e.g. firewall/routers) and drops all suspected incoming packets. For

example, if the source address of an incoming packet belongs to its internal network,

this packet will be dropped immediately. This scenario is illustrated in figure 3.1,

where three packets from distinct IP addresses try to pass into a subnet, and the

firewall filters unwanted packets according to the ingress filtering rule.

Figure 3.1: Ingress Filtering

30

In contrast, egress filtering is exploited on the internal interface of a network

to inspect packets going out. It will filter the packets that do not have the local

network addresses.

• Advantage: The packets filtering mechanism is an efficient way to prevent

most spoofed packets from travelling on the Internet. Although an attacker can still

perform IP spoofing by using his/her local network addresses, it is relatively easy for

victim servers to trace back and identify the deployed network, then tackle it with

corresponding security measures.

• Disadvantage: As mentioned in Section 2.5.1, IP spoofing may help

attackers hide their real identities, which, as a result, becomes an important step in

launching a DoS/DDoS attack. However, DDoS attacks, in particular, are often

launched from real IP addresses (“Zombies” and “Master”). Ingress/Egress filtering

does not work well in these DDoS attack scenarios. Moreover, to efficiently prevent

spoofed packets, filtering mechanisms must be applied widely on network routers and

firewalls within the whole Internet, which would be not easy to reach in today’s

Internet, where fills in numerous different network devices based on various network

protocols and industry standards.

3.1.2 Packet Marking

Packet marking is also used to prevent IP spoofing. In this method, a packet can be

traced back to its source address by inserting trace back data into the packet when it

passes through distinct routers to the destination (K. Park 2001). If a victim is

attacked, it can deduce the path of malicious packets in order to identify the attacker’s

source address.

• Advantage: This may be combined with filtering mechanisms to destroy IP

spoofing completely. Packet marking is capable of meeting the demands of DDoS

defense.

• Disadvantage: Requiring each router to insert unique information as a packet

passes will increase traffic load and create much information redundancy. Moreover,

since the trace back data needs to be encoded, packet marking encounters

computational difficulties when it has to deal with a large number of attack packets

(Y. Xiang 2004).

31

3.1.3 Time-out

In the time-out approach, a server deploys a short period of time to wait for the final

ACK message, which should be returned from a client to complete TCP connection

protocol. After this time, which we call “time-out”, the connection request will be

rejected. Meanwhile, the distributed buffer space for this connection will also be

cleared (T. J. Ott 1999).

• Advantage: This approach may help the server to prevent too many half-

open SYN packets from being crammed into the buffer space. It is easy to implement

in existing servers, without any need to increase software/hardware, or modify

network protocols.

• Disadvantage: This approach can be overwhelmed by a SYN flooding attack

with a high-speed rate, which means the buffer space may be filled with malicious

connection requests before each time-out occurs. Furthermore, a short time-out can

possibly influence the service availability of clients whose network connection has a

long time delay.

3.1.4 Random Dropping

In the random dropping approach, a server selects a certain percentage for its buffer

capacity, which should never be 100 percent. When the amount of consumed buffer

space reaches this designated value, a number of half-open connection requests in the

waiting queue will be rejected at random.

• Advantage: Using this approach, a server is able to avoid a complete denial

of service, since the server buffer will never be consumed completely. The server only

needs a random dropping algorithm to perform this approach.

• Disadvantage: No identification for random dropping may result in a

substantially degraded service for legitimate clients. It is undesirable consequence,

especially when most requests waiting in queue belong to a DDoS attacker.

3.1.5 SYN Cookies

Since TCP SYN flooding attacks exploit the inherent shortcomings of the protocol, it

appears reasonable to improve the protocol to resist attacks. SYN cookies belong to

this category. In the SYN cookies approach, a server verifies the authentication of

32

connection requests by using so-called “cookies”, which are computed by hashing a

series of connection parameters. These parameters include a client’s IP address, port

number, and a secret number known only by the server. When receiving a client

request i, the server generate a secret number, and hashes connection parameters to

obtain a “cookie” Hi. The server then returns a SYN-ACK message containing Hi to

the client. Until the server receives the final ACK message with the correct Hi, the

resource will not be allocated for this formal connection (T. J. Ott 1999).

• Advantage: SYN cookies are believed to be one of the most successful

defenses against TCP SYN flooding. Instead of allocating resources without any

verification, SYN cookies introduce a small authentication mechanism to help the

server distinguish between spoofed IP addresses and legitimate ones. Resources are

only granted to the client who can successfully pass the authentication.

• Disadvantage: The major limitation of this approach is that SYN cookies

assume that IP spoofing attackers are incapable of eavesdropping on the SYN-ACK

messages sent to the spoofed IP address, and consequently, attackers cannot provide

the server with the correct cookies. This assumption may not be always correct. For

example, if spoofed IP addresses are located within the same subnet, it is relatively

easy for an attacker to intercept all the packets transferred on the network. On the

other hand, the cryptographic hashing used in SYN cookies is quite expensive. Some

engineers argue therefore, that servers expecting a lot of incoming connections should

not use this solution.

Saraiah (Saraiah et al., 2009) and Avinash (Avinash et al., 2010) have

proposed a solution to reduce the impact of the DDoS attacks on the web server by

throttling the client CPU using Integer Factorization (IF) and Discrete Log Problem

(DLP). Their proposed solution is made available in the form of APIs which are to be

integrated within a web application by the programmer. Hence, their solution is not

transparent to the developer and client. Here, we re-consider the drawback of their

approach and decided to implement the same solution in the form of Apache modules

which makes presence of the solution transparent to the web application developer as

well as end user.

33

CHAPTER 4

PROPOSED SOLUTION

This work focuses on application-level DDoS attacks since they have become a major

threat to web-based services. Our proposed solution leverages upon Integer

Factorization and Discrete Log Problem to throttle the client making a request. Before

dwelling into details, we outline the basic terminologies pertaining to our design and

implementation details.

4.1 CPU THRESHOLD

The Web Server Benchmarking (Threshold Value) 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 server CPU usage.

The threshold value depicts the maximum CPU usage within which HTTP requests

can easily be served without straining its resources. This value is configurable by the

server administrator depending upon his requirement.

4.2 SOLUTION DESCRIPTION

We consider an Internet-scale distributed system of clients and servers. Attacker is a

malicious entity whose aim is to prevent legitimate clients from receiving service of

the server. A server operates normally when it is not under an attack. The server

assumes that it is under DDoS attack when the CPU utilization exceeds the threshold.

The server enters panic mode by sending puzzle to the client who is expected solve it

in order to be eligible for the service. If the client responds with incorrect response to

the challenge thrown by the server then server does not provide requested service. The

goals of the proposed solution are as follows:

Prevent distributed denial of service attacks on web server.

34

The computation cost employed by the server in generating and verifying the

puzzle must be significantly lesser than the computational cost enforced on the

client in solving the puzzle.

The puzzle difficulty which depends on the server’s resources availability

should be adjustable.

Having solved previous puzzle does not aid in solving new given puzzle.

Solution should be totally transparent to clients as well as web application

developer.

4.2.1 Integer Factorization in Action

Let us consider the detailed operation at server as well as client side with respect to

figure 4.1. Thin line indicates actual request/ response connection between client and

server. Dashed lines represent communication between client and the server that

happen transparently without end user’s intervention.

Figure 4.1: Communication between Client and Server

Operation at the server side:

During an attack, when the client sends a request to the server for the first

time, server responds by sending the ‘Ndigits’ number ‘N’ to be factored into

two primes by the client. The granularity of ‘Ndigits’ can be decided using an

algorithm named ‘GenerationOfN’ (Saraiah 2009).

35

When a client sends a request to the server with value ‘N’ (previously sent by

the server) along with calculated prime factors ‘P’ and ‘Q’, the server verifies

the equality N =P * Q.

If N ≠ P * Q then the server will not respond to that request, otherwise server

will send the requested resource by injecting a new ‘N’ value to be used as a

challenge by the client while making subsequent request in the future. This

process continues as long as the server load is above threshold value.

Operation at a client side:

When the client receives an ‘N’ value from the server in response to the

request sent, the client factorizes ‘N’ using Integer Factorization algorithm to

determine two prime factors ‘P’ and ‘Q’ followed by which client re-issues the

request for the same resource but this time request includes a triplet <N, P,

Q>.

The client receives service once equality is verified by the server as mentioned

before.

An attacker using a custom non-standard client to bombard server would be

incapable of extracting value ‘N’ from the response and calculate prime factors for the

same. Hence, requests made from these kinds of clients shall not be entertained by the

server. However, if an attacker modifies his client to read ‘N’ from the request and

compute ‘P’ & ‘Q’ to be sent back then the number of requests that can be made from

such a client would come down drastically as the client machine would remain busy

calculating factors before it can make the next request. Hence, the bombard rate

would also decrease and server is relieved from DDoS attack to a great extent. If the

distributed attack sustains or increases, we can increase the number of digits of ‘N’

and this would help throttle the malicious clients without introducing any additional

load on the server.

36

4.2.2 DLP in Action

Let us consider the detailed operation at server as well as client side with respect to

figure 4.2. Thin line indicates actual request/ response connection between client and

server. Dashed lines represent communication between client and the server that

happen transparently without end user’s intervention.

Figure 4.2: Communication between Client and Server

Operation at the server side:

During an attack, when the client sends a request to the server for the first

time, server responds by sending the ‘Pdigit’ Prime number ‘P’ along with

generator α and remainder β to client. Client need to be calculate ‘x’ such that

β = αx mod P. The granularity of ‘Pdigit’ can be decided using an algorithm

named ‘GenerationOfP’(Avinash 2010).

When a client sends a request to the server with values <P, α, β> (previously

sent by the server) along with calculated power ‘x’, the server verifies the

equality β = αx mod P.

If β ≠ αx mod P then the server will not respond to that request, otherwise

server will send the requested resource by injecting a new <P, α, β> values to

be used as a challenge by the client while making subsequent request in the

37

future. This process continues as long as the server load is above threshold

value.

Operation at a client side:

When the client receives an <P, α, β> values from the server in response to

the request sent, the client calculate ‘x’ such that β = αx mod P. followed by

which client re-issues the request for the same resource but this time request

includes P, α, β and x.

The client receives service once equality is verified by the server as mentioned

before.

An attacker using a custom non-standard client to bombard server would be

incapable of extracting values <P, α, β> from the response and calculate ‘x’ for the

same. Hence, requests made from these kinds of clients shall not be entertained by the

server. However, if an attacker modifies his client to read <P, α, β> from the request

and compute ‘x’ to be sent back then the number of requests that can be made from

such a client would come down drastically as the client machine would remain busy

calculating factors before it can make the next request. Hence, the bombard rate

would also decrease and server is relieved from DDoS attack to a great extent. If the

distributed attack sustains or increases, we can increase the number of digits of ‘P’

and this would help throttle the malicious clients without introducing any additional

load on the server.

38

CHAPTER 5

IMPLEMENTATION DETAILS

The solution discussed in the previous chapter has been implemented in the form of

lightweight Apache modules called mod_ddos_IF and mod_ddos_DLP. The

schematic of these modules is shown in figure 5.1. The shaded boxes represent the

modules we have developed

Figure 5.1: Schematic of modules

These modules can either be embedded statically while compiling Apache

source code or can be used as a dynamic shared object (DSO) with the Apache web

server. Apache Portable Runtime (APR) library that ships with Apache source code

written in C language is used to develop these modules. In Apache, the core job of

returning the response to the client is done by the content generator. In the basic form,

it simply returns the requested file from the file system of the server. For different file

types (jsp, php etc), a separate content generator is registered which does the job of

executing server script and renders an appropriate response. An actual request sent by

the client can be modified before it is actually seen by the content generator. This can

be achieved by means of hooking in to the request processing pipeline of the apache

web server. If a module is registered to hook in to the pipeline before request reaches

content generator then it is called as an input filter. In the same way, the response

39

produced by the content generator can also be modified before it’s actually sent back

to the client. This functionality is achieved by the output filter.

In our case, we leverage upon input filter to check for the presence of cookie

containing a triplet <N, P, Q> for IF and the presence <P, α, β, x> for DLP. Whenever

a request comes to the apache web server during attack, our verification i.e. input

filter will be activated and will be hooked as content filter. Verification filter will pull

a chunk of data from request and it will look for the cookie in request_rec data

structure. If no such triplet is found in this request, then the verification filter does not

allow this request to reach content generator and hence prevents client from getting

requested resource. However, our input filter produces a standard response of the

form as shown below figure 5.2 for Integer factorization and figure 5.3 for Discrete

log Problem:

<HTML> <HEAD> <SCRIPT TYPE='text/javascript' SRC='factorize.js'></SCRIPT> <TITLE>DDoS Attack Prevention </TITLE> </HEAD> <BODY Onload=factor(<N>) > </BODY> </HTML>

Figure 5.2: Standard response of IF

<HTML> <HEAD> <SCRIPT TYPE='text/javascript' SRC=DLP.js'></SCRIPT> <TITLE>DDoS Attack Prevention </TITLE> </HEAD> <BODY Onload=DLP(<P, α, β>) > </BODY> </HTML>

Figure 5.3: Standard response of DLP

40

As shown in the above code snippets, only the value of N changes in Integer

factorization Algorithm and P, α, β in Discrete Log Problem while rest of the response

body remains the same. In case of IF, the client on receiving the above response is

forced to factorize value ‘N’ and send back factors to the server with a new request

asking for the same resource again. Client sends back triplet to the same URI by

means of redirection being done form within the JavaScript. If verification filter finds

that an incoming request contains a triplet <N, P, Q> within the cookie then

verification filter checks whether aforementioned equality holds and let this request

reach an actual content generator which does the job of producing the actual response

expected by the client. Now, we hook into the response processing pipeline of an

apache with the help of output filter called injection. The Injection filter holds two

buckets; the first bucket holds the script tag to be injected inside HTML head tag of

the requested page (highlighted in gray in figure 5.4). Second bucket holds

“Onload=factor (<N>)” as highlighted in gray in figure 5.4. The response generated

by the content generator is made available to Injection filter in the form of chained

Buckets such that each bucket holds a part of the response. Injection filter scans this

chain of buckets to locate the Head tag (<HEAD>). Having located the head tag,

injection filter splits bucket containing head tags into two buckets at the position

where head tag ends. It then inserts a new bucket (containing script tag) immediately

after a bucket in which head tag ends. Now it searches for the <BODY> tag and splits

a bucket again into two parts at a position where a part of body tag ends (<BODY ). It

now inserts a bucket containing “OnLoad=factor(<N>)” here. This modified response

is then sent back to the client. The modified response produced by our injection filter

would appear as shown in figure 5.5. As can be seen, JavaScript has been included

within actual html markup.

The process of injecting a bucket is shown in figure 5.4. In this figure outer

box with dotted line indicates the brigade and boxes drawn inside outer box represent

buckets and boxes.

41

Figure 5.4: Apache Buckets modification

<HTML>

<HEAD>

<TITLE>Online Student Register</TITLE>

<SCRIPT TYPE='text/javascript'

SRC='factorize.js'></SCRIPT>

</HEAD>

<BODY Onload=factor(1841179) >

<H1>Actual Response</H1>

<IMG Src=’……….’/>

<A href=’……/result.php’>Results</A>

<INPUT type=’button’ name=’Refresh’/>

</BODY>

</HTML>

Figure 5.5: Response generated by server when mod_ddos_IF is in use

<HTML>

<HEAD>

<TITLE>Online Student Register</TITLE>

<SCRIPT TYPE='text/javascript'

SRC='factorize.js'></SCRIPT>

</HEAD>

<BODY Onload=DLP(1361,570,614) >

<H1>Actual Response</H1>

<IMG Src=’……….’/>

42

<A href=’……/result.php’>Results</A>

<INPUT type=’button’ name=’Refresh’/>

</BODY>

</HTML>

Figure 5.6: Response generated by server when mod_ddos_DLP is in use

Our input filter is known as “Verification filter” that does the job of cookie scanning

and validation as described before. Similarly for DLP module, the modified response

produced by our injection filter would appear as shown in figure 5.6. Our solution

becomes available to any web application hosted on the Apache web server as it has

been implemented at the server level and not web application level. Hence, it is

transparent to the programmer and does not require any change in the web application

code. Follow these steps to integrate our module with the apache:

Compile mod_ddos_IF

$ ./apxs -c -i -a /home/projuser/Desktop/src/mod_ddos_IF.c

After integrating mod_ddos_IF module into apache web server, the following

changes have to be made in httpd.conf to use mod_ddos_IF module (i.e.

/etc/httpd/conf/httpd.conf): LoadModule DDoS_module modules/dos_module.so

<IfModule mod_ddos>

DDoSOutputFilter on

DDoSInputtFilter on

AddOutputFilter DDoSOutputFilter.html html

AddInputFilter DDoSInputtFilter.html html

MaxCPUage 70

PrimesCacheDuration 20

</IfModule>

The following is a description of all the module parameters:

Variable/Option Description DDoSOutputFilter on Used to activate ddos output filter DDoSInputtFilter on Used to activate ddos input filter MaxCPUsage Threshold value of CPU usage PrimesCacheDuration Refreshing rate of primes

Table 5.1: Module Parameters

43

CHAPTER 6

SECURITY CONSIDERATIONS

In this chapter we will consider how an attacker can try to conquer our solution and

attack on the Apache Web Server.

Scenario 1: Let’s assume that an attacker sends request to the Apache with

spoofed source IP as well as source TCP port. On receiving this request, the server

would send puzzle over the same TCP connection. i.e. to the spoofed IP and port.

Assume that an actual machine whose IP resembles spoofed IP is currently up. This

machine would receive a TCP packets containing puzzle from the server. However,

there was no TCP connection establishment between the server and the victim

machine. As a result of which, victim machine treats these response packets as stray

packets not being part of any of the previously established TCP session and hence

discards them. Hence, server would not get solution to the puzzle and a resource

requested by an attacker won’t be served and no CPU cycles are wasted serving the

resource.

Scenario 2: If the server sends same ‘N’ more than once to the client in case

of IF then client can compute P & Q only once and send them whenever a puzzle asks

to factorize same ‘N’. This way, client prevents itself from wasting considerable CPU

time. To shield against this kind of attack, our solution generates ‘N’ dynamically

using an algorithm named ‘GenerationOfN’(Saraiah 2009). This value is computed

dynamically based on the server time (The number of milliseconds elapsed since the

server was booted). This quantity is sufficiently random and this difference varies for

every millisecond, so the ‘N’ value generated will be unique for each request. Same is

true in case of DLP where we compute <P, α, β> dynamically using an algorithm

named ‘GenerationOfP’(Avinash 2010).

Scenario 3: Larger the N value sent by the server, longer time would be

needed for attacker’s machine to calculate P and Q in case of Integer Factorization.

44

Attacker may maintain repository of triplets of the form <Nold, Pold, Qold> used in the

past. Attacker would get new N on sending request to the server. However, attacker

may choose one of these old triplets and make request to the server instead of

factoring new N value received from the server in an anticipation that his request

would be served as Nold = Pold * Qold equality holds and hence no stamp fee is paid by

the attacker. To counter this scenario, server maintains a list of recent N value sent to

the client. While doing verification, server can make sure that the N contained in the

request is indeed the same as the one sent by the server. When sever learns that N sent

along with the request is same as N value in the list (sent to the same client), server

discards this N value form the list. Same approach is employed for DLP as well. For

DLP, a table stores <P, α, β> triplet at the server which is sent to the client.

45

CHAPTER 7

EXPERIMENTAL RESULTS

We carried out performance evaluation in two phases. In first phase, we integrated

mod_ddos_IF with the Apache Web Server version 2.2.13 on Linux platform and

tests were performed to determine load reduction on the server, reduction in no. of

requests that an attacker can send, response time for the legitimate users and finally

server load reduction when N is kept fixed for IF. Same set of tests were performed in

the second phase; however mod_ddos_DLP was used this time instead of

mod_ddos_IF. Our experimental setup had four machines. These machines were

connected via 100 Mbps Ethernet connection. The Web Server is equipped with Intel

Core2Quad T6600 Processor 2.2 GHz, 4 GB RAM, 320GB hard disk (7200r/min).

The machine from which legitimate requests were sent run on a machine equipped

with Intel Pentium4 DualCore Processor 3.2 GHz, 1 GB RAM, 80GB hard disk

(7200r/min). The other two machines used to bombard Web Server had the same

configuration as previous one. We hosted one dynamic page (PHP) on the server to

generate 100 random numbers and sort them at the server side and send back result to

the client. During attack we used legitimate user machine to check the latency.

6.1 INTEGER FACTORIZATION

Below graph shows the effectiveness of the proposed solution with the help of Integer

factorization algorithm. As shown in figure 6.1, resource utilization of Web Server

was at peak when our module was not in use. This is shown in the graph when load is

around 90% with zero number of digits in N (represents a state when Apache was run

without our module).

46

Figure 6.1: Server load reduction

Our solution starts by employing 8-digit N value. As number of digits in N is

increased, the load on the attacker machine increases significantly and at the same

time load on the Web Server comes down drastically and hence it can cater to more

number of genuine users. As shown in figure 6.2, an increase in number of digits in N

drastically brings down an ability of an attacker to bombard server and hence it can

cater to more number of genuine requests.

Figure 6.2: Number of Requests sent by the attacker

Another metric of interest is a response time for a legitimate user. We

considered three scenarios. In first scenario, Web Server was run without our solution

and under attack. In this case, response time turned out to be approximately 900 ms as

represented by green line in figure 6.3. In second scenario, Web Server was operated

normally without any attack and without our solution. The response time recorded

was around 400 ms as represented by red line in figure 6.3. Next, we ran server with

our module and server was bombarded immensely to simulate attack scenarios. In this

47

case, the response time converges linearly with an increase in number of digits in N.

When maximum digits are used, response time is same as normal operating scenario.

This is shown by blue line in figure 6.3.

To figure out overhead involved in generating N value dynamically, we

performed another test where we used fixed N value of 8 digits, then fixed N value of

10 digits and so on. It is evident from figure 6.4 that the load on the server reduced

by approximately 20%. This reduction is attributed to fixed N value since server did

not do any computation to generate N dynamically. Hence, this overhead is meager

compared to the protection it provides.

Figure 6.3: Response time of legitimate User

Figure 6.4: Server load reduction when N is fixed

48

6.2 DISCRETE LOG PROBLEM

This section highlights effectiveness of proposed solution when Discrete Log Problem

is used to generate client stamp. Here, we did same set of tests as previous one. The

results are shown in graphs below.

Figure 6.5: Server load reduction

Figure 6.6: Number of Request sent by Attacker

Figure 6.7: Response time of legitimate User

49

As shown in figure 6.8, P was kept fixed. Other two parameters α and β were

determined in accordance with fixed P value.

Figure 6.8: Server load reduction when P is fixed

50

CHAPTER 8

CONCLUSION AND FUTURE WORK

Our solution to thwart DDoS attack operates at an application layer. It safeguards

Apache Web Server by throttling the client either using Integer Factorization or

Discrete Log Problem. We implemented proposed solution in the form of Apache

modules. An advantage of our solution is that it is transparent to the

developer/programmer as web applications hosted on the server are automatically

safeguarded without any changes to them. Also, it does not require intervention of

human at the client side. Our solution introduces negligible overhead on the server. It

is apparent from the result that the use of P in DLP having lesser number of digits can

produce same effect as using N with more number of digits in IF. Hence, we can say

that use of DLP brings server to normalcy faster than IF can.

The proposed solution does not discriminate benign client from the attacker.

This work can be further expanded by incorporating algorithm that would identify

genuine requests from the bad requests and hence can adapt different strategy to

throttle a malicious client.

51

REFERENCES

Avinash and et al (2010). Throttling DDoS attacks Using Discrete Logarithm

Problem. In Proceedings of SECRYPT, International Conference on Security and

Cryptography

Arjen K. Lenstra (2004),”Integer Factoring”, Designs, Codes and Cryptography,

Springer Netherlands

T. Aura and P. Nikander (1997). Stateless connections. In Proceedings of

International Conference on Information and Communications Security ICICS’97,

volume 1334 of LNCS, pages 87–97. Springer Verlag.

T. Aura, P. Nikander, and J. Leiwo (2000), “DoS-resistant authentication with client

puzzles,” in 8th International Workshop on Security Protocols, Lecture Notes In

Computer Science; Vol. 2133, Springer-Verlag,

T. Aura, P. Nikander, and J. Leiwo (2001). Dos-resistant authentication with client

puzzles. Security Protocols, 8th International Workshop, Cambridge, UK, April

3-5, 2000; revised papers, volume 2133 of Lecture Notes in Computer

Science:170–177, Springer.

B. Bencsth, I. Vajda, and L. Buttyn (2003). “A game based analysis of the client

Puzzle approach to defend against dos attacks”. In IEEE Conference on Software,

Telecommunications and Computer Networks, Venice, 7-10.

Bert Slagter (2009), "Protection against SYN Floods",

http://techblog.procurios.nl/k/news/view/33045/14863/Protection-against-SYN-

Floods.html, (June 10, 2010)

Chris Studholme (2002), "The Discrete Logarithm Problem".

www.cs.toronto.edu/~cvs/dlog/, (June 10, 2010)

52

C. Dwork and M. Naor (1992). “Pricing via processing or combatting junk mail”. In

Advances in Cryptology, Proc. CRYPTO 92, LNCS 740, pages 139–147, Santa

Barbara, CA USA, Springer Verlag.

Eran Gabber, Phillip B Gibbons, Yossi Matias, Alain Mayer (1996), "How to Make

Personalized Web Browsing Simple, Secure, and Anonymous", The SSL Protocol,

3.0. Internet Draft,

P. Ferguson and D. Senie (1998). “Network ingress filtering: Defeating denial of

Service attacks which employ IP source address spoofing”. IETF, RFC 2267,

X. Geng, Y. H., and A. B. Whinston (2002). “Defending wireless infrastructure

against The challenge of DDoS attacks”. Mobile Networks and Applications

(MONET),7(3):213– 223.

J. A. Halderman B. Waters, A. Juels and E. W. Felten (2004). “New client puzzle

Outsourcing techniques for dos resistance”. In ACM Conference on Computer and

Communications Security, pages 246–256.

Ivan Ristic (2005), “Apache Security”, O'Reilly.

A. Juels and J. Brainard (1999), “Client puzzles: A cryptographic countermeasure

against connection depletion attacks,” the Network and Distributed System

Security Symposium (NDSS ’99).

John D. Howard (1997). An analysis of security on the internet 1989 - 1995, PhD

Thesis, Carnegie Mellon University.

John Elliott (2000), Distributed Denial of Service Attacks and the Zombie Ant Effect.

53

F. Kargl, J. Maier, and M. Weber (2001). “Protecting web servers from distributed

Denial of service attacks”. In Proceedings of the 10th International WWW

Conference, Hong Kong.

Kevin J. Houle, George M. Weaver (2001), “Trends in Denial of Service Attack

Technology”, CERT® Coordination Center.

Laurie and Laurie (2007). “Apache, The Definitive Guide”, O'Reilly, third edition.

Lincoln Stein and Doug MacEachern (1999), “Writing Apache Modules with Perl and

C”, O'Reilly, First Edition.

P. R. J. Mirkovic and J. Martin (2002). “A taxonomy of ddos attacks and ddos

defense mechanisms”. Technical Report 18, University of California, Los Angeles –

Computer Science Department.

Nick Kew (2007), “The Apache Module Book”, Prentice Hall.

T. J. Ott, T. V. Lakshman, and L. Wong. Sred (1999)” Stabilized red”. In

Proceedings Of IEEE INFOCOM, pages 1346–1355.

B. Parno, D. Wendlandt, E. Shi, A. Perrig, B. Maggs, and Y. Hu (2007), “Portcullis:

Protecting connection setup from denial of capability attacks,” in ACM

SIGCOMM ’.

K. Park and H. Lee (2001). “On the effectiveness of probabilistic packet marking for

IP traceback under denial of service attack”. IEEE INFOCOM.

R. Rivest, A. Shamir, and L. Adelman (1978) . A method for obtaining digital

Signatures and public-key cryptosystems. Communications of the ACM, 21:120–

126.

54

Saraiah and et al (2009). Throttling ddos attacks. In Proceedings of SECRYPT

2009 International Conference on Security and Cryptography

R. Stone (2000). Center track: An IP overlay network for tracking dos floods. 9th

USENIX Security Symposium, pages 199–212.

R. Thomas, B. Mark, T. Johnson, and J. Croall (2003), “Netbouncer: Client-

legitimacy- Based high- performance DDoS filtering,” in 3rd DARPA Information

Survivability Conference and Exposition.

Thomer M. Gil,Massimiliano Poletto (2001), "MULTOPS: a data-structure for

bandwidth attack detection", Proceedings of the 10th conference on USENIX Security

Symposium - Volume 10.

Vicky Laurens, Abdumotaleb EI.Saddik, and Amiya Nayak (2006),” Requirement for

Client Puzzles to Defeat the Denial of Service and the Distributed Denial of

Service Attack”, The International Arab Journal of Information technology, Vol.

3, No. 4.

X. Wang and M. K. Reiter (2003), “Defending against denial-ofservice attacks with

puzzle auctions,” in IEEE Symposium on Security and Privacy, Washington DC.

Wei Yen and Ming-Fang Lee (2005), “Defending Application DDoS with Constraint

Random Request Attacks”, Asia-Pacific Conference on Communications, Perth,

Western Australia,3 - 5.

Wu chang Feng (2003). The Case for TCP/IP Puzzles. In Proceedings of ACM

SIGCOMM Workshop on Future Directions in Network Architecture (FDNA-03),

Germany

.

55

A. Wagner, B. Plattner, and R. Hiestand (1999). “Experiences with worm propagation

Simulations”. In Proceedings of the First ACM Workshop on Rapid Malcode

(WORM03).

Yi Xie and Shun-Zheng Yu (2009), “Monitoring the Application-Layer DDoS

Attacks For Popular Websites”, IEEE/ACM Transactions on Networking, VOL. 17,

NO.

Y. Xiang, W. Zhou, and M. Chowdhury (2004). “A survey of active and passive

Defense mechanisms against DDoS attacks”. Technical Report, TR C04/02, School

of Information Technology, Deakin University, Australia.

X. Yang, D. Wetherall, and T. Anderson (2005), “A DoS-limiting network

architecture,” in ACM SIGCOMM ’05, Philadelphia.

A. Yaar, A. Perrig, and D. Song (2004), “SIFF: A stateless Internet flow filter to

mitigate DDoS flooding attacks,” in IEEE Symposium on Security and Privacy.

The Morris Internet Worm (1998) http://www.snowplow.org/tom/worm/worm.html

(June 10, 2010).

56

BIO-DATA

Contact Details:

Address: #178/2, 1st floor, Muni Reddy Complex,

Thubarahalli, Ramagondanahalli Post, Bangalore -560066.

e - Mail: prashant.r.kulk@gmail.com

Phone number: +91 974007706

LIST OF PUBLICATIONS:

[1] Prashant Kulkarni, Radhesh Mohandas, Alwyn Pais, “Prevention of DDoS Attack

against Apache Web Server”, CSI Region-5 Student Convention NITK, 2010. (Best

Paper Award)

[2] Prashant Kulkarni, Radhesh Mohandas, Alwyn Pais, “Responsive System for

DDoS Attack against Apache Web Server”. The 16th Annual International

Conference on the Theory and Application of Cryptology and Information Security,

ASIACRYPT 2010. (acceptance awaited)