ADDIS ABABA UNIVERSITY

SCHOOL OF GRADUATE STUDIES

COLLEGE OF NATURAL SCIENCES
DEPARTMENT OF COMPUTER SCIENCE

Defending the Virtual Infrastructure of Cloud Computing

from Denial of Service Attack

Aderaw Semma
Advisor: Mulugeta Libsie (PhD) A.A.U
Co-Advisor: Metasebia Kassa, ZTE University

A THESIS SUBMITTED TO

THE SCHOOL OF GRADUATE STUDIES OF ADDIS ABABA UNIVERSITY

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS

FOR THE DEGREE OF MASTER OF SCIENCE IN COMPUTER SCIENCE

February, 2014

Addis Ababa

1
 ADDIS ABABA UNIVERSITY
SCHOOL OF GRADUATE STUDIES
COLLEGE OF NATURAL SCIENCES
DEPARTMENT OF COMPUTER SCIENCE

Defending the Virtual Infrastructure of Cloud Computing

from Denial of Service Attack

Aderaw Semma
Advisor: Mulugeta Libsie (PhD) A.A.U
Co-Advisor: Metasebia Kassa, ZTE University

APPROVED BY:

BOARD OF EXAMINERS:

1. Dr. Mulugeta Libsie, Advisor __________

2. ________________________ __________

3. ________________________ __________
2
 Acknowledgement
My first thanks are to the Almighty God!, without his blessings I wouldn't have been writing
even this acknowledgments.

I then would like to express my heartfelt thanks to my advisors, Dr. Mulugeta Libsie and Mr.
Metasebia Kassa, for their guidance, support, and encouragement during the thesis work. I am
especially indebted to Dr. Mulugeta for teaching me Distributed Systems, which have been
proven beneficial for my current thesis work and future career. Without his endless efforts,
knowledge, and patience this thesis would have never been possible. Moreover I would also like
to acknowledge all my colleagues and all my classmates of first batch computer science
extension students especially Doji Wordofa.

Last but not least, I would like to express my deepest gratitude and love to my wife w/ro
Firehiwot Mesfin and my beautiful daughters Merat and Azaheal who support me to pass all the
challenges without any complain.

i
 Table of Contents Pages

List of Figures ................................... .................................................................................... iv

List of Acronyms .............. .................................................................................................... vi

Abstract...... ......................................................................................................................... viii

Chapter One: Introduction........................................................................................................1

1.1 Background .......................................................................................................................................................... 1

1.2 Statement of the Problem ..................................................................................................................................... 4

1.3 Objectives ............................................................................................................................................................. 4

1.4 Methodology ........................................................................................................................................................ 5

1.5 Scope and Limitation............................................................................................................................................ 6

1.6 Significance of the Study...................................................................................................................................... 6

1.7 Organization of the Thesis.................................................................................................................................... 6

Chapter Two: Literature Review..............................................................................................7

2.1 Security Threats and Impacts in the Cloud........................................................................................................... 7

2.1.1 Problems as a Result of Attacks .................................................................................................................. 8

2.2 Denial of Service ................................................................................................................................................ 10

2.2.1 DoS Attack Techniques ............................................................................................................................. 10

2.2.2 Types of DoS Attacks ................................................................................................................................ 11

2.2.3 DoS Attack Targets.................................................................................................................................... 16

2.3 The Attackers’ Motivation ................................................................................................................................. 19

2.4 Tools to Launch DoS Attacks............................................................................................................................. 22

2.5 Vulnerabilities of the Cloud to DoS Attacks ...................................................................................................... 25

2.5.1 DoS Attacks on Virtual Network ............................................................................................................... 26

2.5.2 DoS Attacks on VM................................................................................................................................... 26

2.5.3 DoS Attacks on Hypervisor ....................................................................................................................... 27

ii
 2.6 Summary ............................................................................................................................................................ 28

Chapter Three: Related Work ................................................................................................29

3.1 Works on Basic DoS Attack Technique ............................................................................................................. 29

3.2 Works on DDoS Attacks .................................................................................................................................... 34

3.3 Works on DoS Attacks Related to Flood Attack Type ....................................................................................... 36

3.4 Summary ............................................................................................................................................................ 41

Chapter Four: The Proposed Solution ....................................................................................42

4.1 Introduction ........................................................................................................................................................ 42

4.2 Description of the Proposed Solution ................................................................................................................. 42

4.3 Components of the Proposed Architecture ......................................................................................................... 45

4.3.1 Data Management Unit .............................................................................................................................. 48

4.3.2 Bandwidth Analyzer .................................................................................................................................. 52

4.3.3 Packet Analyzer ......................................................................................................................................... 55

4.3.4 Timestamp Unit ......................................................................................................................................... 61

4.4 Summary ............................................................................................................................................................ 63

Chapter Five: Evaluation and Analysis ..................................................................................65

5.1 Introduction ........................................................................................................................................................ 65

5.2 Prototype Implementation .................................................................................................................................. 66

5.2.1 Network Domain ....................................................................................................................................... 66

5.2.2 Node Domain ............................................................................................................................................. 67

5.2.3 Process Domain ......................................................................................................................................... 67

5.3 Development and Simulation Tools ................................................................................................................... 68

5.3.1 Baseline Scenario of the Proposed Model ................................................................................................. 79

5.3.2 DoS Attack with no Mitigation Scenario................................................................................................... 85

5.2.3 DoS Attack with Mitigation Scenario........................................................................................................ 96

5.4 Summary .......................................................................................................................................................... 104

Chapter Six: Conclusion and Future Works ........................................................................105

iii
 6.1 Conclusion ........................................................................................................................................................ 105

6.2 Future Works .................................................................................................................................................... 106

References ............................................................................................................................107

Annex A: Process Model and Source Code for the IP Cloud Model ..................................114

Annex B: Process Model and Source Code for the DoS attack scenario ............................120

Annex C: Process Model and Source Code for DoS attack Mitigation Scenario................121

iv
 List of Figures
Figure 1.1: The relationship between a cloud customer and a cloud provider...............................1

Figure 2.1: Survey of Arbor Network in the year 2012.................................................................22

Figure 4.1: Location of the proposed solution…...........................................................................43

Figure 4.2: The Proposed Architectural Framework ...................................................................44

Figure 4.3: The Proposed Architectural Framework Flow Chart ...............................................46

Figure 4.4: Flooding DoS Attack on the Cloud.............................................................................48

Figure 4.5: Pseudo- code of the Data Management Unit..............................................................51

Figure 4.6: Pseudo- code of the Bandwidth Analyzer...................................................................54

Figure 4.7: IP header format for the Cloud Control Packet.........................................................56

Figure 4.8: Pseudo- code of the Packet Analyzer..........................................................................60

Figure 4.9: Pseudo- code of Timestamp Unit................................................................................62

Figure 5.1: The Working environment of the OPNET simulation tool..........................................68

Figure 5.2: The LAN configuration in the model of the proposed solution...................................70

Figure 5.3: The Router configuration in the model of the proposed solution...............................71

Figure 5.4: The Switch configuration in the model of the proposed solution...............................72

Figure 5.5: IP Cloud representation in OPNET...........................................................................74

Figure 5.6: The Application configuration in the model of the proposed solution.......................75

Figure 5.7: The supported services in the model of the proposed solution...................................76

Figure 5.8: The Profile configuration in the model of the proposed solution...............................77

Figure 5.9: The Applications of the proposed solution used by users..........................................78

Figure 5.10: The Baseline scenario model of the proposed solution............................................79

Figure 5.11: The Baseline scenario network components.............................................................80

Figure 5.12: The Simulation speed of baseline scenario ..............................................................81

Figure 5.13: The Simulation Message of baseline scenario .........................................................82

v
Figure 5.14: The Memory usage of the simulation in baseline scenario ......................................82

Figure 5.15: Traffic Sent and the Request load of the simulation result in baseline scenario......83

Figure 5.16: The Mail Server simulation result in baseline scenario...........................................84

Figure 5.17: The IP spoofing model in DoS attack scenario........................................................85

Figure 5.18: The Duplicate baseline scenario..............................................................................86

Figure 5.19: The DoS attack scenario model in our simulation....................................................87

Figure 5.20: The IP Ping traffic configuration.............................................................................88

Figure 5.21: The Simulation speed of DoS attack scenario .........................................................89

Figure 5.22: The Simulation message of DoS attack scenario......................................................89

Figure 5.23: The Memory usage of the simulation in DoS attack scenario..................................90

Figure 5.24: The Traffic load comparison on DoS attack scenario..............................................91

Figure 5.25: Traffic sent comparison on DoS attack scenario......................................................92

Figure 5.26: Traffic received comparison.....................................................................................93

Figure 5.27: Task processing time of the DB server in DoS attack scenario................................94

Figure 5.28: TCP Active Connection Counts................................................................................95

Figure 5.29: DoS attack mitigation network model ......................................................................97

Figure 5.30: the Traffic load comparison on the mitigation scenario..........................................98

Figure 5.31: Traffic sent comparison on mitigation scenario.......................................................99

Figure 5.32: Task processing time of the DB server in mitigation scenario...............................100

Figure 5.33: Aggregate Network Traffic load (packets/sec) ......................................................101

Figure 5.34 Traffic Sent to the DB server (packets/sec) .............................................................102

Figure 5.35: Response time (seconds) .......................................................................................103

Figure 5.36: Processing Delay in Seconds..................................................................................104

vi
 List of Acronyms
BA Bandwidth- Analyzer
BPA Basic Probability Assignment
BPDU's Bridge Protocol Data Units
CPU Central Processing Unit
CSP Cloud Service Provider
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DMU Data Management Unit
DoS Denial of Service
FTP File Transfer Protocol
HTTP Hyper Text Transfer Protocol
IaaS Infrastructure as a Service
ICMP Internet Control Message Protocol
IDSs Intrusion Detection Systems
IP Internet Protocol
IRC Internet Relay Chat
ISP Internet Service Provider
LAN Local Area Network
OPNET OPtimized Network Engineering Tools
OSPFP Open Shortest Path First Protocol
PA Packet Analyzer
PaaS Platform as a Service
pps Packets per Second .
RTO Retransmission Time-Out
RIP Routing Information Protocol
SaaS Software as a Service
SLA Service Level Agreement
SLO Service Level Objectives
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol

vii
SOE Sequence of Events
STD State Transition Diagrams
TCP Transmission Control Protocol
TFN Tribe Flood Network
ToS Types of Services
TTL Time_to_Live
TU Timestamp Unit
UDP User Datagram Protocol
VM Virtual Machine
VPN Virtual Privet Network
WAN Wide Area Network
XML eXtensible Markup Language

viii
 Abstract
Cloud Computing is a new computing model and its security aspects require special
considerations. Now a day’s Denial of Service (DoS) attacks are harmful elements of computer
networks and it is one of the most harmful security aspects to attack the cloud environment. The
rapid advances in processor, memory, and Internet technology have enabled the development of
cloud based networks. All these resources are available for attackers like any user, and they have
their own motivations to apply DoS attacks effectively by exhausting the resources of the cloud
and inhibit the normal relation between the cloud services providers and the cloud legitimate
users. This problem requires developing a novel mitigation mechanism that maintains the normal
interaction within the cloud world. Many defending mechanisms of this attack have been
proposed to mitigate the impact of the attacks.

This thesis work is done to mitigate DoS attacks on the cloud computing environment through a
packet analysis approach in the mitigation process. To complete our work, we propose a DoS
attack mitigation architectural framework on cloud computing infrastructure to mitigate DoS
attacks. In addition, we consider four basic components in our architectural framework that work
in coordinated manner to implement the mitigation process. The components of our architectural
framework are Data Management Unit, Bandwidth Analyzer, Packet Analyzer, and Timestamp
Unit.

To show our results, we used simulation based testing on the DoS attack mitigation using the
OPNET simulation tool. In order to demonstrate the mitigation process our simulation uses three
scenarios baseline, DoS attack and mitigation. In our investigation, we assess the effectiveness of
our mitigation process for SYN flooding attack on the cloud infrastructure. So, our evaluation on
the simulation demonstrates that the comparison result on the baseline, DoS attack and
mitigation scenarios helps to observe the Traffic Sent, Response Time, Processing Delay, and
Network Traffic Load on the cloud among the three scenarios. From the output of the simulation
results we conclude the DoS attack impact is higher due to the bogus traffic but the mitigation
graph is above than the baseline graph because it sends packets in filtered and optimized form
during the mitigation process.
Keywords:
Security, Denial of Service Attack, Distributed Denial of Service Attack, IaaS, Service
Availability on Cloud Computing
ix
 Chapter One: Introduction

1.1 Background
Cloud computing is the latest trend in distributed computing and has been the subject of much
publicity. Its vision covers on-demand, reliable services provided over the Internet with easy
access to virtually infinite computing, storage and networking resources. Through very simple
web interfaces and at small incremental cost, users can outsource complex tasks, such as data
storage, system administration, or application deployment, to very large data centers operated by
cloud providers [1].

Cloud computing is composed of five essential characteristics, three service models, and four
deployment models. The essential characteristics are On-demand self-service, broad network
access, resource pooling, rapid and measured service. On top of these characteristics, as in Figure
1.1 it provides services based on the following service models:

Software as a Service (SaaS) - the capability of providing applications installed on a cloud
infrastructure,

Platform as a Service (PaaS) - the capability provided to the consumer to deploy onto the cloud
infrastructure, and

Infrastructure as a Service (IaaS) - the capability provided to the consumer to provision
processing, storage, network and other fundamental computing resources [2, 3, 4].

Cloud Customer

Software-as-a-Service
Provides Uses
Platform-as-a-Service

Infrastructure-as-a-Service

Cloud Provider
Figure 1.1: The relationship between a cloud customer and a cloud provider

1
The most common deployment models of cloud computing are typically classified in the
following forms [2, 3, 4]:

Public Cloud- the cloud infrastructure is made available to the general public or a large
industry group and is owned by an organization selling cloud services,

Private Cloud- the computing infrastructure is dedicated to a particular organization and
not shared with other organizations. Private clouds are further classified as: On-premise
private clouds and externally hosted private clouds,

Hybrid Cloud- the cloud infrastructure is a composition of two or more distinct cloud
infrastructures (private, community, or public) that is more complex than the other
deployment models, since they involve a composition of two or more clouds. Each
member remains a unique entity, but is bound to the others through standardized or
proprietary technology that enables application and data portability among them.

Community Cloud- the cloud infrastructure is shared by several organizations and
supports a specific community that has shared concerns.

Cloud computing has key benefits as compared to the traditional computing systems. Some of
the advantages are its ability to scale rapidly, store large amount of data remotely, and share
services in a dynamic environment. Moreover, business users recognize the cloud’s advantages
from their point of view in speeding innovation, accelerating business processes, and reducing
time to revenue. It turns IT from a capital intensive concern to as pay per you use activity. There
are other benefits of cloud computing like: increased flexibility, rapid implementation, increased
effectiveness, and energy efficiency [2, 3, 5, 6].

Even though cloud computing has several advantages, it also faces many challenges. Some of the
challenges are security, performance and availability of cloud computing services and resources
[4]. Our concern in this thesis work is assuring the protection of cloud infrastructure and services
from different threats. The most prominent threat on availability of cloud computing service is
Denial of Service (DoS) through flooding or logical attacks. Since the aim of cloud computing is
to deliver its applications and services to users through the Internet, it is prone to various kinds of
external and internal security attacks [7, 8, 9].

2
As studies show, the number of DoS attacks on the cloud is increasing these days. The study on
50 companies that compares 2010 and 2011 shows the percentage of annualized cyber crime cost
allocated to nine attack types compiled from all benchmarked organizations. Malicious code and
DoS attack account for the highest percentage cyber crimes of 23% and 17% respectively with
average cost of $5.9 million per year together. The total cost of such companies on study shows,
with a range of $1.5 million to $36.5 million each year per company. Moreover, the DoS attack
depends on the size of the company size based on small, medium and large-sized organizations
that reveals the cost mix for specific cyber attacks. Specifically, small organizations which have
less than 5,000 nodes have experience of a higher cyber crime costs relating to malicious code
and malware. In addition, large organizations which have greater than 15,000 nodes have
experience of a higher cyber crime costs relating to DoS attack [11].

For example, "On 18 October 2012, HSBC servers came under a DoS attack which affected a
number of Hong Kong and Shanghai Banking Corporation (HSBC) websites around the world”.
Additional news posted on November 8, 2012 by Enurrendy Leaders at four security technology
companies shows the DoS attacks that have hit 10 US banks in the weeks before highlight the
need for new approaches to preventing and responding to online outages [12].

Despite the increasing sophistication and severity of cyber attacks, a survey of more than 700
senior IT professionals reveals that organizations are surprisingly unarmed to deal with today’s
threat landscape, while 65 percent of organizations experiencing an average of three DoS attacks
in the previous 12 months of 2012. Unlike the previous few years, where many organizations
focused on confidentiality and integrity-based attacks, respondents noted a major shift in their
security objectives, ranking DoS and DDoS as two of the top three threats their organizations
face today [12].

Most of the researchers try to solve these attacks and provide specific solutions to DoS attacks in
the cloud. But, the problem still exists in more sophisticated manner in different cloud areas. So,
it needs a constructive solution to mitigate this problem. Thus, in this thesis we will go through a
survey on the problem, identify and analyze the DoS attack mechanism, analyze the past
researchers contributions and finally we will come up with solutions for potential DoS attacks on
IaaS of the cloud based on the new understanding of the problem domain. The motivation to

3
carry out this thesis on IaaS is because all other services provided through the cloud computing
environment rely on it. The DoS attacks main target in the cloud is IaaS to degrade performance
or completely block out all other services of the cloud. So, this thesis contributes to fill the gap in
the cloud computing domain.

1.2 Statement of the Problem

Studies have been conducted in the past few years to propose solutions to the problems of cloud
computing services security issues. Among the different threats, DoS attack is becoming the
most critical. It denies cloud services users from using their access right on virtual infrastructure.
Its impact is not as such simple; the degree can range from mild service degradation to complete
loss of service [10].

To address this problem we raise the following research questions:

How DoS attacks on virtual infrastructure of the Cloud are identified and mitigated?

Which types of DoS attacks are the most common in the virtual infrastructure of the
Cloud Computing?

How to develop our proposed solution for the problem by reviewing others work on the
domain area?

How we evaluate the solution using testing and implementation?

1.3 Objectives

General Objective

The general objective of this thesis is to develop a DoS attack mitigation architectural framework
on the cloud infrastructure (IaaS).

Specific Objectives

To achieve the general objective of the thesis, the following specific objectives are identified.

Thorough understanding and investigation of the current cloud computing security issues,
focusing on DoS attacks;

4

Identifying the appropriate tools to develop the architectural framework;

Designing the architectural framework which prevents virtual infrastructure of cloud
computing from flood attacks,

Developing a prototype and simulating the result, and

Identifying the major implementation issues for the newly designed architectural
framework.

1.4 Methodology

In order to achieve the general and specific objectives mentioned above, we use the following
methods.

 Literature review: related literature from different sources (books, Internet, journals, etc.)
will be reviewed to understand DoS attack problems on cloud computing environment. The
major activities are

The most current researches in the area of cloud computing on DoS attacks problems
will be reviewed.

Identifying the strength and weakness of solutions proposed by previous researchers.
 Simulation

We use OPNET simulation tool for implementation with the following components
 Project Editor: To develop network models. Network models are made up of
subnets and node models. This editor also includes basic simulation and analysis
capabilities.
 Node Editor: To develop node models. Node models are objects in a network
model. Node models are made up of modules with process models. Modules may
also include parameter models.
 Process Editor: To develop process models. Process models control module
behavior and may reference parameter models.
 Link Model Editor: To create, edit, and view link models.
 Packet Format Editor: To develop packet formats models. Packet formats
dictate the structure and order of information stored in a packet.

5

Developing a Prototype using OPNET’s expresses process models in a language
called Proto-C, which is specifically designed to support development of protocols
and algorithms. Proto-C is based on a combination of state transition diagrams
(STDs), a library of high-level commands known as Kernel Procedures, and the
general facilities of the C or C++ programming language.

1.5 Scope and Limitation

The thesis mainly focuses on developing an architectural framework for DoS attack mitigation
on cloud computing. It particularly focuses on the IaaS of the cloud computing environment. So,
some results of the thesis may not be applicable for non-cloud computing systems and the other
cloud service models.

1.6 Significance of the Study

The result of this research will contribute to the ongoing researches in this domain area.
Moreover, it provides its own contribution to the beneficiaries by allowing sustainable provision
and acceptance of cloud computing services by the services providers and subscribers.

1.7 Organization of the Thesis

The rest of the thesis is organized as follows. Chapter two explains major technologies and issues
used in DoS attacks of the cloud. Chapter three is a review of related works on DoS attacks and
mitigation techniques in the cloud environment. The Chapter also discusses researches that have
been conducted on DoS attacks from different researchers that consider attacking and mitigation
techniques as well as identifying the strengths and weakness of their work. Chapter four presents
a DoS attack mitigation architectural framework designed for the identification and mitigation
mechanism of an attack. The Chapter discusses the proposed mitigation architectural framework
of DoS attacks on the cloud computing infrastructure based on its components separately.
Chapter five presents the experimental environment and the tools that are used to perform all the
activities of the thesis work and also presents the simulation results. Finally Chapter six
concludes the thesis work and provides the contribution and possible future works not covered
by this thesis work.
6
 Chapter Two: Literature Review

This Chapter gives a brief description of the major issues of Denial of Service (DoS) attack
related to cloud computing services. DoS attack is one of the security challenges on the cloud
computing environment that results in minimizing the performance of the cloud services or
blocking its availability from legitimate users [19]. The details of DoS attacks in the cloud,
including the motivations of the attackers and the tools they use for attacking, are also addressed.
In addition to the primary motives of the attacker, the attacking techniques as well as their targets
and the main problems due to these attacks are reviewed.

2.1 Security Threats and Impacts in the Cloud

The cloud environment offers several utilities to users including bandwidth and storage capacity
to run applications smoothly. Some providers even allow other benefits like free limited trial
periods and provide additional services for a limited period of time. The users of the cloud
frequently come under security threats and malicious attacks. The areas where these attacks
could have the biggest impact on the cloud include decoding and cracking of passwords,
launching potential attack points, and executing malicious commands [20, 32].

Insider threats and attacks are done due to lack of transparency by the cloud providers’ delivery
mechanism and procedure. Any external command over the level or predefined privilege of
cloud access could lead to various challenges like corporate hacking and organized business
threats in the working environment [21, 24].

DoS attacks are initiated almost every day. Even the most prominent Websites like Twitter,
Facebook, Google, etc. couldn’t escape from being attacked. The most amusing case was the
DoS incident that targeted the White House, Federal Trade Commission of US, and the
Department of the Treasury in 2013. A botnet comprised of 30,000 – 60,000 infected computers
were used. The attack traffic consumed 20-40 gigabits of bandwidth per second; it caused target
outage for 4-5 days which was the longest outage duration ever [16].

Typical victims for DoS attacks are online businesses, carriers and service providers of the cloud.
DoS attacks target revenue-generating organizations by overtaxing link capacity. This costs them

7
both direct and indirect damages. Direct damages include revenue loss or increased network
costs. Indirect damages are related to business reputation and increased operational
expenses. DoS attacks can result in significant loss of service, money and status of organizations.
Typically, the loss of service is the inability of a particular network service or the temporary loss
of all network connectivity and services. For example, HTTP DoS attacks have forced Web sites
or cloud services accessed by millions of people to cease operation temporarily for unknown
time span.

2.1.1 Problems as a Result of Attacks

The first DoS attack occurred against Panix, the New York City area's oldest and largest Internet
Service Provider (ISP), on September 6, 1996, at about 5:30 p.m. [48]. The attack was against
different computers on the provider's network, including mail, news, and Web servers, user
"login" machines, and name servers. The Panix attack was a SYN Flood attack deriving from
random IP addresses and directed towards the server’s Simple Mail Transfer Protocol (SMTP)
ports. More specifically, Panix's computers were flooded by, on average, 150 SYN packets per
second (50 per host), so Panix could not respond to legitimate requests.

The impact of DoS attacks has increased steadily in recent years and, as more computers connect
to the Internet, an ever-increasing supply of zombies and target machines become available to
the attacker wishing to launch a DoS attack. A recent survey estimated that nearly 4000 DoS
attacks per week are active on the Internet at any given time [49]. Part of the reason for the
increased threat due to the DoS and DDoS attack is that attack tools have advanced significantly
in recent years, showing evidence of increased sophistication in automation, amplification, and
stealth. Attacking tools are sufficiently easy to use, even would-be hackers with limited coding
experience can launch worms and scripts that cause damage almost similar with the expert
attackers. The most common problems due to DoS attacks in the cloud services are the following
[23, 28, 31,78]:

8

Network Bandwidth

A typical network bandwidth attack involves the echo and chargen (character generator)
services. Echo replies with the input it was given, and chargen sends an endless stream of
characters to any client. However, an attacker might spoof a packet originating from the chargen
port of the system with a particular service running, and send it to the echo service from the
broadcast address. The occurrence of a DoS attack increases bandwidth consumption besides
causing congestion, making certain parts of the cloud inaccessible to the users [18].

Server Memory

A memory starvation attack is designed to force a Web site to consume excess memory. This
type of attack usually occurs if there is a coding on the site, when there is an overlook to check
whether an allocation or new memory request succeeded, and assumptions that memory would
always be plentiful. For example, an attacker can continuously add line items to users using a
script that adds millions of line items. In a commerce server site, shopping carts are loaded into
memory as dictionary objects, so an attacker will eventually exhaust the available memory of the
server, resulting in a DoS attack.

CPU usage

From the attacker's point of view, the objective of a CPU starvation attack is to create normal
applications to get stuck in a tight loop doing expensive calculations. For example, an attacker
might issue multiple checkout requests to the Web site, exceeding system capacity. At that rate,
the server will run out of CPU capacity in a very short time.

Hard Disk Space

A resource starvation attack, also known as a disk space attack, is one in which an attacker is
able to consume a particular resource until it is exhausted. For example, an attacker might
continuously issue requests to the Web site to create illegal users. If this occurs, the system will
run out of disk capacity.

9

Database Connection Pool

Depending on the connection pooling settings of the application and the time it takes for an
attack query to execute, an attacker might be able to consume all connections in the connection
pool, which will cause database queries to fail for legitimate users.

2.2 Denial of Service

Denial of Service is an attack which makes the cloud services unavailable to its intended users.
There are various methods and strategies to carry out this attack. The primary aspect would be to
block a victim’s network and thus make it inaccessible by other clients. The other aspect could
be attacks at various points of the cloud which makes the cloud unstable to provide its normal
services to the intended users [17]. There are two general forms of DoS attacks: those that crash
services and those that flood services. These forms of attacks can be carried out in different ways
or techniques.

2.2.1 DoS Attack Techniques

Attackers use different mechanisms to deny normal services and the most common techniques
are discussed in this section [22, 29, 34]:

Basic Attack Technique

This is an attacking technique that relies on network resources. It commonly uses consumption
of computational resources, such as bandwidth, disk space, or processor time, problems created
by the interruption of configuration information, such as routing information, disruption of state
information, such as unsolicited resetting of TCP sessions, disturbance of physical network
components and blocking the communication media between the intended users and the victim
so that they can no longer communicate effectively.

Attack Source Technique

This category of DoS attacks can be either single source or distributed source attacks. Attackers
may launch attacks from a single host or from multiple hosts. If the attacks originate from

10
multiple hosts that are distributed in the network, it is called a Distributed Denial of Service
(DDoS) attack. In contrast, if the attacks are generated from a single host, it is called a single
source denial of service attack. Most commonly the term DoS is used to refer only to the single
source denial of service. However, to avoid confusions we use DoS to refer to both distributed
and single source attacks.

Attack Enhancing Techniques

In this category, spoofing, reflection and amplification DoS attacking techniques are used by
attackers. In this case the victim will not know who originated the attack. Such a technique can
cause DoS attacks that may be more difficult to defend by bouncing their attack traffic off from
other hosts in a network, or by amplifying the amount of attack traffic received by the attack
target. The use of spoofing, reflection and amplification make it difficult to impersonate a
legitimate host and to combine the attack traffic with legitimate traffic for the purposes of
avoiding detection.

2.2.2 Types of DoS Attacks

To implement the above techniques, attackers use different types of DoS attacks. The well
known types of DoS attacks are discussed below:

Low-Rate TCP Targeted Denial of Service

The Low-Rate DoS attack exploits TCP’s slow-time-scale dynamics of Retransmission Time-
Out (RTO) mechanisms to reduce TCP throughput. It does not employ numerous packets to
flood the network but it exploits the working mechanism of TCP timers thus bringing the
throughput of a system to almost zero [51]. These low-rate attacks are crafted to generate packets
only periodically in very minimal quantity. Through this process, TCP waits for the RTO to
expire after which the data is sent again. When the congestion is more, the RTO timer is doubled
after which the packets are retransmitted. So an attacker is able to calculate this RTO time and
send attacking packets to create packet collision and loss to push the TCP into waiting state.
This type of attack can effortlessly escape the traffic monitors due to its low traffic rate. Hence,
there is no need for flooding the network with packets, but only send packets when the timer is

11
about to expire and push it again into the RTO waiting time. Basically, an attacker can cause a
TCP flow to repeatedly enter an RTO state by sending high-rate, but short-duration bursts, and
repeating periodically at slower RTO time-scales [36, 52].

Smurf Attack

A Smurf attack is one particular variant of a flooding DoS attack and it works on the mechanism
of flooding the victim's bandwidth. It relies on misconfigured network devices that allow packets
to be sent to all computer hosts on a particular network via the broadcast address of the network
by a number of Internet Control Message Protocol (ICMP) echo requests to a broadcast address.
The network then serves as a Smurf amplifier and the attacker will send large numbers of IP
packets with the source address faked to appear to be the address of the victim. The network's
bandwidth is quickly used up, preventing legitimate packets from getting through to their
destination [25, 28, 30].

Reflective Denial of Service

Reflective attacks are those which employ intermediate hosts for their attacks. The
main difference between Direct and Reflective attacks is that in the direct attack, the attacking
system sends out packets directly to the victim but hides its original IP address and it adopts the
IP address of some other host. But in a reflective attack, the attacker floods a large number of
reflectors with its source address spoofed with the victim's address. A classic example for
reflective attack would be a Smurf attack that sends ICMP ping packets towards the
victim. ICMP is similar with Smurf Attack that can be considered as a form of reflected attack,
as the flooding host(s) sends Echo Requests to the broadcast addresses of misconfigured
networks, thereby tempting many hosts to send Echo Reply packets to the victim [52, 53, 54].

Amplification Denial of Service

In attack amplification, attackers exploit services that generate one large message or multiple
messages for each message they receive to amplify the amount of attack traffic directed towards
the targeted victim. For example, in a Smurf DoS attack, attackers exploit the IP network
broadcasting service and send ICMP echo request packets to the IP multicast address of an
intermediary network to amplify the attack traffic. If the intermediary network does not filter

12
ICMP traffic directed to IP multicast addresses, many of the machines on the network will
receive this ICMP echo request packet and send an ICMP echo reply packet back. To direct the
ICMP echo reply packets towards the victim, attackers use the victim’s IP address as the source
address in the ICMP echo request. In this attack, each ICMP request sent by the attacker
generates N reply messages from the intermediary network, where N is the number of hosts in
the intermediary network. Such an attack achieves an N : 1 amplification [53, 54, 55].

TCP/ SYN Flood

A TCP/SYN flood occurs when a host sends a flood of TCP/SYN packets, often with a forged
sender address. The TCP/SYN flooding attack aims at exploiting server CPU and memory.
Whenever a host attempts to connect to a server, a three way handshake protocol is established
before any actual data transfer occurs. Firstly, the host sends a SYN packet to initiate the
handshake. The server then replies with an Acknowledgement packet. At last the host again
needs to send a SYN ACK packet to establish a successful connection. But attackers leave the
handshake half open by not sending the last SYN ACK. Such a half opened handshake is stored
in the server memory and the server keeps waiting for the host to send the final packet. When
thousands of such half open connections are initiated, the server runs out of memory and
crashes. However, because the sender address is forged, the response never comes. These half-
open connections saturate the number of available connections the server is able to make,
blocking it from responding to legitimate requests until after the attack ends [20, 52, 54,].

Ping Flood and Ping of Death

Ping flood is similar to Smurf wherein the victim is attacked continuously with thousands of ping
packets. The attack is based on sending the victim a large number of ping packets, usually using
the "ping" command from Unix-like hosts and the -t flag on Windows systems to make the target
less capable of doing its normal operation. It is very simple to launch if the attacker gets an
access of greater bandwidth than the victim. Ping of death is based on sending the victim a
malformed ping packet, which might lead to a system crash [25, 52, 56].

13

UDP Flood

UDP flooding is similar to ping flood but instead of ping packets, UDP packets are continuously
sent to the server [20]. UDP could be a lot more effective than ICMP in smaller networks as the
size of the UDP packets are enormous. The packet size could be set up to 65000 bytes which
could easily flood a given Ethernet network when multiple zombies are set up [52, 53, 56].

Teardrop Attacks

A Teardrop attack involves sending damaged IP fragments with overlapped and over-sized
payloads to the target server. This can crash various operating systems because of a bug in their
TCP/IP fragmentation re-assembly code [25, 46].

Around September 2009, a vulnerability in Windows Vista was referred to as a "teardrop attack",
but the attack targeted SMB2 which is a higher layer than the TCP packets that teardrop used
[47].

Application Level Flood Attacks

On different applications, these types of flooding attacks affect server running software to get
them confused, fill the disk space, and consume all available memory or CPU time.

Other kinds of DoS attacks rely primarily on brute force, flooding the target with devastating
insecure packets, over-saturating its bandwidth connection or depleting the target's system
resources. Bandwidth saturating floods rely on the attacker having higher bandwidth available
than the victim; a common way of achieving this today is via DDoS, employing a botnet. Other
floods may use specific packet types or connection requests to saturate finite resources by
occupying the maximum number of open connections or filling the victim's disk space with logs.

An attacker with shell-level access to a victim's computer may slow it until it is unusable or crash
it by using a fork bomb. A kind of application-level DoS attack is XDoS or XML DoS, which
uses XML messages that are intentionally sent to flood and destroy the communication channel
of the cloud service provider [42, 57, 58].

14

Distributed Denial of Service Attacks

Distributed Denial of Service has the cohesive strength of many compromised systems working
towards a single cause. The first stage of this attack is to build its platform with many host
systems that can work under remote commands. The attacker would first scan networks to hunt
for vulnerable systems that are weak in security features. Once the scanning procedure is
completed, attackers would bring these hosts into control using software exploitations [24]. After
having sufficient hosts under control, attackers also create backdoors that allow special access
that is used for future entry.

A DDoS attack occurs when multiple systems flood the bandwidth or resources of a targeted
system, usually one or more web servers. This is the result of multiple compromised systems
flooding the targeted system(s) with traffic. Attackers can also break into systems using
automated tools that exploit faults in programs that listen for connections from remote hosts. It
utilizes a layered structure where the attacker uses a client program to connect to handlers, which
are compromised systems that issue commands to the zombie agents, which in turn facilitate the
DDoS attack. Agents are compromised via the handlers by the attacker, using automated routines
to exploit vulnerabilities in programs that accept remote connections running on the targeted
remote hosts. Each handler can control up to a thousand agents [54, 55, 56, 57].

The major advantages to an attacker of using a DDoS attack are: multiple machines can generate
more attack traffic than one machine, multiple attack machines are harder to turn off than one
attack machine, and that the behavior of each attack machine can be harder to track and shut
down. In some cases a machine may become part of a DDoS attack with the owner's consent. An
example of this is the 2010 DDoS attack against major credit card companies by supporters of
WikiLeaks [50].

The most common attacks that advance the performance of DDoS are the following [19, 24, 42,
43]:

15
Application Layer DDoS Attacks

These attack types include Slowloris, Zero-day DDoS attacks, DDoS attacks that target Apache,
Windows or OpenBSD vulnerabilities. Application layer DDoS attacks are classified into the
following types: (1) session flooding attack in which session connection request rate is higher
than the requests from legitimate users; (2) request flooding attack in which sessions containing
more number of requests than usual are sent; and (3) asymmetric attack in which sessions
containing high-workload requests are sent.

Protocol DDoS Attacks

This type of attack consumes actual server resources, or intermediate communication equipment,
and it is measured in packets per second.

Volume-Based DDoS attacks

The volume-based attack’s goal is to saturate the bandwidth of the attacked site, and magnitude
is measured in bits per second.

2.2.3 DoS Attack Targets

The targeted victim of a DoS attack can be an end system that implements all layers of the
TCP/IP reference model, a router, an ongoing communication, a link or an entire network, an
infrastructure, or any of these combinations. In the case of a system, the targeted victim can be
an application, or an operating system. The most common DoS attacked targets are discussed
below:

DoS Attacks on Applications

On these particular targets, an attacker attempts to prevent the application from performing its
intended tasks by causing the application to exhaust the finite supply of resources. For example,
in an eXtensible Markup Language (XML) DoS attack, also known as Billion Laughs attack, an
attacker passes to an XML parser a small XML document that is both well formed and valid, but
expands to a very large file. When the parser attempts to parse the XML document, it ends up

16
consuming all memory available to the parser application. Usually, the resources for applications
are constrained by configuration, such as the maximum number of processes and the maximum
number of simultaneous connections that an application can create, to limit the impact of an
application DoS attack on the entire operating system. However, if such limits are not chosen
carefully, based on the role of a machine, important applications may become the easy targets of
a DoS attack [35, 41, 42, 57, 58].

DoS Attacks on Operating Systems

These types are very similar to application DoS attacks. However, in application DoS attacks, the
operating system may be able to protect other applications from being affected. Whereas the
problem can be more catastrophic in the case of operating system DoS attacks. A very well-
known DoS attack on an operating system is the TCP SYN flooding, in which an attacker sends a
flood of TCP SYN packets to the victim without completing the TCP handshake, and exhausting
the victim’s connection state memory. Such an attack affects all applications that rely on TCP for
their communication [20, 35, 52].

DoS Attacks on Routers

Many of the DoS attacks against an end system can also be launched against an IP router. The
simplest attack on a router is to overload the routing table with sufficiently large number of
routes so that the router runs out of memory, or the router has insufficient CPU power to process
the routes. More serious DoS attacks on routers that use false route updates can cause
blackholing of an entire network address block [29, 35, 39, 40].

DoS Attacks on Network Links

The simplest form of DoS attack on network links is to send enough non congestion controlled
traffic, e.g., UDP traffic, such that a link becomes excessively congested, and legitimate traffic
suffers unacceptably high packet loss. Congesting a link might also cause a routing protocol to
drop an adjacency if sufficient routing packets are lost, potentially amplifying the effects of the
attack. Moreover, it may be possible for an attacker to deny access to a link by causing the router
to generate sufficient monitoring or report traffic such that the link is filled. Simple Network

17
Management Protocol (SNMP) traps are one possible vector for such an attack, as they are not
normally congestion controlled [35, 39, 40].

DoS Attacks on Infrastructure

Most of the network systems depend on some underlying infrastructure for their normal
operations. The effects of infrastructure attacks on the users of that infrastructure can be very
large. For example, denying access to a DNS server effectively denies access to all services, such
as Web, email, public keys and certificates that are being served by that DNS server. The larger
the zone a DNS server is responsible for, the bigger the impact of a DoS attack. All root DNS
servers were subjected to a very large scale DoS attack. As a result, some root name servers were
unreachable from many parts of the global Internet.

Some DoS attacks target a common infrastructure that is connected with all hosts in a local
network. For example, an attack with access to a subnet may be able to prevent other local hosts
from accessing the network by simply exhausting the address pool allocated by a Dynamic Host
Configuration Protocol (DHCP) server. Although such attacks require the ability to spoof MAC
address of an Ethernet or wireless card, it is quite feasible with certain hardware and operating
systems [39, 40].

DoS Attacks on Firewalls and IDSs

Firewalls are intended to defend the systems behind them against outside threats by restricting
data communication traffic to and from the protected systems. Firewalls may also be used in
defending against denial of service attacks. Meanwhile, firewalls themselves may become the
targets of DoS attacks. There are two types of firewalls, stateful and stateless, and both can be
attacked by sending traffic that causes the firewall to hold excessive state. In the case of
excessive state, the firewall may run out of memory, and can no longer instantiate the state
required to pass legitimate flows. For most firewalls, this will cause denial of service to the
systems behind the firewall. Intrusion detection systems (IDSs) suffer from similar problems to
that of firewalls [39, 40].

18
2.3 The Attackers’ Motivation

There are many reasons to launch DoS attacks on different organizations by an attacker. DoS
attacks began to occur when a critical mass of organizations and individuals became Internet
connected, which give attackers real incentive to strike. DoS attack criminal motivations are
driven by current time situations. The driving forces of DoS attackers motivation could be [20]:
principle driven attacks, business driven attacks, socially driven attacks, prominent to attack and
bring down the web services from their internal motives, credibility with other hackers for
compromising a high-profile site, revenge for real, perceived injustices, criminal extortion or
competitive tactics, political activism or cyber terrorism and finally desire for entertainment, or
experimenting with new attack techniques. Motivations of attackers can be categorized into the
following:

Monetary Gain

There are a number of ways that attackers can increase their wealth through DoS, most
remarkably via extortion, whereby an initial attack is quickly followed by demands of payment
and threats of additional attacks. A number of incidents have demonstrated that DoS is being
used as a tool for disrupting competitor operations, thereby creating dissatisfaction on customers.
Some of the activities in the monetary gain are discussed below [25, 29, 38].

Criminal Extortion

Attackers threaten to continue disrupting a service until payment is received. The most lucrative
use of the DoS attack is for blackmail. In these attacks, the attackers threaten online businesses
with an attack unless the companies pay them. One can naturally and rightly assume that victim
organizations do not reveal most extortion attacks they experience; however, the few attacks
revealed to the public do illuminate the extent of the problem

19
Inter-Personal Rivalries

DoS attacks were launched against online markets especially around the Christmas shopping
season. These could be either extortion or inter-company rivalry to create financial losses that are
attacked by DoS to prevent from doing business online. The result is often a loss in sales revenue
or advertising revenue.

Unwanted Competition

The most common motive of DoS attacks against online businesses is competition. Attackers use
competing businesses web sites to build a stronger market share. As a result, they have used DoS
attacks to impact the profits and even shut down competing businesses.

Cyber Criminal Showing off Capabilities

Initially, attackers did not conduct DoS attacks for monetary gain. But as time passed, malicious
attackers realized the money making potential of these attacks; thus, the goal of DoS attackers
has evolved from bragging rights to monetary gain.

Revenge Attack

DoS can be carried out as a revenge tactic for an injustice perceived by an attacker. This is also
generally the domain of low skilled attackers. Some of the activities in the revenge attack are
discussed below [25, 38].

Social Network Attacks

We can call this type of attacks socially driven attacks. If a social networking site is under the
target of attackers, every user of the site is automatically facing the problem directly or
indirectly. This helps the attacker to show a revenge tactic for an injustice for the public.

Vandalism

Sometimes attackers are motivated to involve in a deliberate distraction of public or private

organizations using DoS attack without tangible reason. This shows the attacker domain is from
low skilled attackers.

20

Information Warfare

This refers to attacks that are carried out for political reasons, including terrorism and online
protests or hactivism which are typically directed at government and other critical infrastructure
organizations [60].

In the past, DoS attacks were thought to be tools used by hackers as a form of protest. However,
recent attacks have shown that DoS attacks can also be a way for cyber crimes and for other
purposes mentioned above [21]. For instance, attacker motivations considered common or very
common in the activities are shown in Figure 2.1 based on the survey of Arbor Network in the
year 2012 [20, 44]. Some of them are the following:

Political

Attackers use DoS attack as a tool for implementing political ideology via online technologies to
be preferred by some political groups to attack any organization. Large Internet organizations
believe ideological and political motivations have become the single commonest motivation
behind the DDoS attacks, as a survey of major Internet firms by Arbor Networks in 2012
confirmed [20, 44].

Online Gaming

Online gaming is the biggest security threat on performance and availability which are critical to
the success of online gaming businesses. As a result, the business can suffer huge losses in a
short period of time. A prolonged outage or very slow response can be catastrophic, both in cash
and business reputation, which means people will take their money elsewhere without use.

21
 Figure 2.1: Survey of Arbor Network in the year 2012

2.4 Tools to Launch DoS Attacks

Attackers use numerous scripts that are us

used
ed for scanning, compromising, and infecting
vulnerable machines. Then they use powerful DoS attack tools to carry out the actual
attacks. The most well known and freely available tools on the Internet to launch DoS attacks in
cloud computing environment byy the attackers are the following:

Trinoo

This tool uses a handler and agent architecture wherein an attacker sends commands to the
handler via TCP, and handlers and agents communicate via UDP. Both handlers and agents are
password protected to prevent the
them
m from being taken over by another attacker. Trinoo generates
UDP packets of a given size to random ports on one or multiple target addresses during a
specified attack time interval [25, 39, 59].

22

Tribe Flood Network (TFN)

This tool uses a different type of handler and agent architecture. Commands are sent from the
handler to all of the agents, from the command line. The attackers do not “log in” to the handler
as with Trinoo. This tool can perform a UDP flood, a TCP SYN flood, and Smurf attacks at
specified or random victim ports. The attackers run commands from the handler using any of a
number of connection methods, e.g., a remote shell bound to a TCP port, and UDP-based
client/server remote shells. All commands sent from the handler to agents through ICMP packets
are encoded, which hinders detection [25, 39, 59].

Stacheldraht

This tool combines the features of the tools Trinoo and TFN. The interesting aspect of
Stacheldraht is that the attacking agents use a "Telnet-like" program that uses encryption to
communicate with the controllers [25, 59, 60].

Trinity

This is the first DDoS tool that is controlled via Internet Relay Chat (IRC). Upon compromise
and infection by Trinity, each zombie joins a specified IRC channel and waits for commands.
The use of a legitimate IRC service for communication between attacker and zombie replaces the
classic independent handler, and elevates the level of the threat. It is also capable of launching
several types of flooding attacks on a victim site, including UDP, an IP fragment, TCP SYN,
TCP RST, TCP ACK, and other floods [25, 39].

DDoS 2.0

Network firewalls today can detect the majority of flood and network DoS attacks. Many ICMP
and UDP flood attacks can also be identified using intelligent packet filtering as well as source
and destination access control lists. Hence, attackers today focus on application layer DDoS
attacks, because these usually bypass most traditional network security devices. DDoS 2.0 is
considered to be a highly amplified class of DDoS attacks. Recently, a new type of DDoS attack
has been uncovered that uses Web servers as payload-carrying bots. Using a basic software
program equipped with a dashboard and control panel, attackers could configure the IP, port, and

23
duration of the attack. Hackers simply need to type the Website URL they wish to attack, and
they can instantly disable targeted sites [59, 61].

Slowloris

Slowloris is a DoS attack tool based on the concept of keeping the server busy with very few
resources. Instead of flooding the server with requests, it holds the connections open for a very
long time. To do so, a Slowloris client sends partial HTTP requests, and continues to send
subsequent headers at regular intervals to keep the sockets from closing. Without requiring that
much bandwidth, an attacker can open numerous connections, and overwhelm the targeted Web
server. Eventually, the server’s connection pool will be entirely busy processing Slowloris
requests, and it will start denying new connection attempts from legitimate clients [37, 61, 62].

Slow HTTP POST

This tool is very similar to Slowloris. Here, the requests are HTTP POST requests, in which all
the headers are sent correctly, including the content length. After the headers are sent and
received, the POST message body is sent at a very low rate, thus keeping the connection open for
an extended time. The server has to wait until all content arrives according to the declared
Content-length. Unlike Slowloris, Slow HTTP POST can’t be mitigated by load balancers [44].

Slow Read

Instead of pushing data slowly to the server, the client forces the server to send a large amount of
data, which it accepts at a very slow rate. Upon establishing the connection, the attacking client
declares a very small receive-window-size. This makes the server split the response to many
small pieces that would fit the buffer size, resulting in very slow ongoing responses [44].

Dirt Jumper

Its availability led to the development of many similar tools with minor modifications that go by
other names, like RussKill, September, Simple Di Botnet and Pandora DDoS. The different
versions vary in the DoS methods they implement and in their stealthiness. Most versions
implement at least three DoS methods, including HTTP flood, SYN flood, and POST flood [44,
63].
24
2.5 Vulnerabilities of the Cloud to DoS Attacks

Vulnerability is the probability that a system will be unable to resist the actions of a threat agent.
Vulnerability is an attribute of a given system. For example, in the cloud computing environment
IaaS, PaaS, and SaaS have different threats, vulnerabilities, and risks due to the virtual network,
the virtual machine or the hypervisor. The biggest weaknesses of the cloud are weak
authentication protocols, an open management port, or the need to manage cloud resources
remotely, all of which are reasons of the cloud vulnerabilities. Hackers are recognizing all of
these open ports, and starting to use them. Most security professionals have argued that the cloud
is more vulnerable to DoS attacks, because it is shared by many users, which makes DoS attacks
much more damaging. When the Cloud Computing operating system notices the high workload
on the flooded service, it will start to provide more computational power, more virtual machines
or more service instances to cope with the additional workload. Thus, the server hardware
boundaries for maximum workload to process do no longer hold. In that sense, the Cloud system
is trying to work against the attacker by providing more computational power. Thus, the attacker
does not have to flood all servers that provide a certain service in target, but just can flood a
single, cloud based address in order to perform a full loss of availability on the intended service
[20].

A hypervisor is a thin layer of software or firmware that provides access to hardware resources
and provides virtual partitioning capabilities. It gives a single physical system, or host server, the
ability to distribute resources to one or more VMs at a single time. The hypervisor is directly
responsible for hosting and managing VMs running on the host. It provides a virtual hardware
that consists of a configuration file, some virtual disk files, and various other files on disks [33].
But, improper configuration of the hypervisor could potentially lead to unintended resource
exhaustion like boot storms, which occurs when many co-resident VMs try to boot at the same
time like DDoS. Based on these opened vulnerabilities, attackers set different services of the
cloud in attacking the targets some of which are described below [28, 44, 46]:

25
2.5.1 DoS Attacks on Virtual Network

A virtual network interconnects a virtual machine that shares a virtual switch with other virtual
machines and is one of the biggest security challenges in the design of a cloud computing
platform. Like in physical networks, virtual network security controls must be deployed over the
virtual network. DoS attacks can happen on every multi-process system that is run either in
virtual or physical networks. The ways of attacks are usually the same in both network types,
which limit the resources available for use by predefined users. In this case, the resources
allocated for each user help to determine the occurrence of DoS attacks [45].

DoS attacks can flood the cloud either on physical or virtual network attacks and it is the biggest
problems for IaaS. This attack consists of overloading the server hosting IaaS services with an
enormous number of requests for data processing [21]. In cloud computing, due to the large
number of cloud users who share the cloud infrastructure, the problem of DDoS attacks become
much higher. The problem is further magnified when the cloud has no sufficient resources to
provide services to customers [22]. The cloud system works against the attacker by providing
more computational power. The attacker sends large amount of messages to the targeted IaaS
host server in order to exhaust its memory and CPU resources resulting in the loss of availability
of the server to the end users.

2.5.2 DoS Attacks on VM

A virtual machine (VM) is a virtualized representation of a physical machine operated and

maintained by the virtualization software. Each VM is a self-contained operation environment
that behaves as a separate computer with processor, memory, network adapter, removable drives,
and peripheral devices [26, 33, 46].

Denial of service is a particular type of cross-VM attack in the cloud. An attacker can easily
exhaust the resources from a physical host in order to deny services to other VMs in the machine
and get more advantage than trying to leak some information from co-resident VMs. The risk of
DoS attacks in the cloud is as prominent as it is in physical multiprocessing systems. However,
because the host machine resources (CPU, network, memory, ...) are shared between all the VMs
and the host machine, the impact of a DoS attack is potentially more damaging. So, DoS attack is

26
a critical problem for VMs, and via the hypervisor software, it allows a single VM to consume
all the system resources, starving the remaining VMs and degrading their function [26].

Moreover, DoS attacks on the cloud infrastructure are risks to the availability of IaaS by limiting
access to a VM, and by abusing the customers’ operating system, applications and potential data.

The attacker may also use a compromised VM, that can be used to affect the host servers and
other VMs in the same virtual or physical network. DoS attacks could be launched against these
VMs or it could be performed in the host server. In the case of cloud environments, the
vulnerability to attack increases since the attacker just needs only to pay for a cloud service as a
consumer. So, an attacker will try to exhaust the resources of the cloud using vulnerable systems
and apply DoS attack on the VM. This attack could be considered as a VM-to-VM attack which
means an attacker may use a VM to communicate and compromise other VMs on the same
physical host and it breaks the isolated characteristic of VMs.

Attackers can also utilize the available shared resources deliberately in order to compromise an
entire host system. The exhaustion of resources can take many forms, from consuming all the
CPU cycles of the VM, write continuously on the assigned memory of the VM, or performing
recursively I/O operations on the VM’s virtual disk. These methods executed by a single
malicious VM are not very effective. However, if the attacker manages to instance several VMs
on the host machine, the DoS attack becomes more practicable. As a result the co-resident VMs
performance is heavily affected and termination of VMs, minimization or complete termination
of communications between the host machine and the VMs can also happen [26, 27].

2.5.3 DoS Attacks on Hypervisor

Attackers can also make use of vulnerabilities in the hypervisor in order to perform a DoS attack.
Vulnerabilities have been found in some of the most famous hypervisors that allow DoS. For
example in Microsoft’s Hyper-V “a malformed sequence of machine instructions run by an
authenticated user in one of the guest virtual machines hosted by the Hyper-V server” could
cause a DoS [28].

27
Hypervisors sometimes provide functionalities that are not necessary (e.g., shared clipboard),
which increase the attack surface. Hypervisors have less code than traditional OSs, and their
interactions with the real world are very limited but it can introduce an attack vector. For
example, in 2010, the Xen hypervisor 3.x had 17 known vulnerabilities. The VMware ESX 3.x
bare-metal hypervisor went from 165 known vulnerabilities to 409 in just one year [64]. Finally,
after having instanced the VM and obtained the pertinent information, an attack is performed.
The different resources are shared between the attacked resources that can give the location to
perform such attacks. Any shared resource or communication channel can be potentially
exploited unless proper measures are taken. Even though the whole virtual network is properly
secured, the threat of DoS on the VMs via the hypervisor is always present.

2.6 Summary

This Chapter explained DoS attack and its security challenges in the cloud computing
environment. DoS attack types and attacking mechanisms provide a clear image on how an
attacker can simply attack different organizations using attacking tools. As a result, the possible
risks that occur due to DoS attack in the cloud computing environment are very critical for both
the cloud users and cloud service providers. For instance, network bandwidth, server memory,
application exception handling mechanism, CPU usage, hard disk space, database space and
database connection pool are some of the services at risk due to the attack. The attackers’
motivations that engage in the attack of cloud infrastructure, vulnerabilities of the systems, DoS
attacks tools and problems due to attacks are the main issues to be known. Thus, this thesis is
concerned on the DoS attacks on IaaS, the vulnerabilities of virtual network, VMs and
hypervisor and to come up with possible solutions to get a clear idea on the impact of DoS
attacks on the cloud computing environment.

28
 Chapter Three: Related Work

This Chapter reviews some of the works that have been done on securing cloud infrastructure
from possible attacks and assuring reliability of cloud services. Even though cloud computing is
in its infant stage, some researches have been done in the field of security, particularly on DoS
attacks in the cloud. Those researches work on the identification of DoS attacks in the cloud
environment using Intrusion Detection Systems (IDSs). In addition, some researchers work on
analyzing and mitigating activities after the identification of DoS attacks in the cloud computing
environment.

In this Chapter, we will review previous works on DoS attacks in the cloud. We will try to
analyze mitigation as well as detection mechanisms of DoS attacks and identify gaps that exist in
previous works. Finally, we summarize the works reviewed.

3.1 Works on Basic DoS Attack Technique

Bedi and Shiva [13] made an experimental based research to address a specific type of DoS
attack on the Virtual Machines (VMs). These VMs hold IaaS, PaaS, and SaaS to provide cloud
computing services. So the researchers use tools like nmap, hping and wget to estimate the
placement of virtual machines in a cloud infrastructure with a high likelihood. They worked on a
specific kind of DoS attack, where an attacker congests a bottleneck network channel shared
among VMs co-resident on the same physical node in the cloud infrastructure. Their model is
designed to evaluate the behavior of this shared network channel using Click modular router on
DETER testbed. Moreover, their model illustrates the game theoretic concepts, which represent
this attack as a two-player game called the guard to defend against such attacks which comes
from the attacker. They also recommended strategies for defending against such attacks on
different companies’ services. Their approach holds new ways of detecting DoS attack on the
VMs using different tools and provide solution for user to use their resource properly. But, they
addressed only the problem of attack from shared VMs co-resident on the same physical node.

Thomas and Janardhanan [14] focused on protecting and defending the cloud infrastructure
against malicious attacks by designing ‘intrusion tolerance’. They showed the renewal and

29
confidentiality property of sensitive data by utilizing secret sharing and adding a proxy server.
As they mentioned, the proxy server acts as an intermediate server between the client system and
cloud servers; and it blocks the attackers by sending a dummy dataset and by analyzing their
behaviors in the networks. To reduce the impact of DoS attack, they proposed a framework of
cooperative intrusion detection system (IDS) but the attacks may never be completely prevented.
So, they implemented CloudSim Toolkit to monitor the cloud process and store the data. Their
implementation is authenticated by the proxy and the original data is encrypted. Their conclusion
depends on the authentication process. It is successful means the real data will be viewed clearly
and identified from the attackers’ data. Using this, it ensures the intrusion attack is detected and
separated during the process and provides solutions for utilization of the cloud infrastructure
without interruptions.

The work on the availability challenge of cloud computing by Aboosaleh et al. [9] showed the
effect of DoS attack on the cloud. The researchers designed a model for DoS attack, and then
they simulated a cloud system on the experimental environment. Their experiments show that the
cloud system is vulnerable to this attack and leads to failures. In order to confront this attack,
several solutions are proposed in this paper. They suggested load balancing and honeypots
filtering besides the intrusion detection systems (IDS) to defend from the attack. The paper’s
strength is the experiment that shows the cloud system is vulnerable to this attack and leads to
failures but they didn’t test their defending mechanism. They simply suggested the mechanism of
how to defend from attack.

A distributed cloud intrusion detection model is designed by Gul and Hussain [15]. They tried to
show high intrusion prospects and suspect of security on cloud environment due to its distributed
nature. Their initiation to the work is data, application and services non-availability can happen
through DoS attacks and both cloud service providers and users become unable to provide or
receive cloud services. For such type of attacks, they propose IDS as a strong defensive
mechanism. Moreover, due to non-availability of cloud computing services, they suggested
deliberate and comprehensive Service Level Agreement (SLA) to be written among user and
provider covering all the relevant legal and service provisioning issues and details. As a strength,
they proposed an efficient multi-threaded cloud IDS, administered and monitored by a third party
ID monitoring service, that can provide alert reports to cloud users and expert advice for the

30
cloud service provider. But, if the 3rd party fails to administer and monitor, both cloud users and
service providers will be in danger when an attack occurs.

Panja et al. [68] proposed an approach to avoid DOS attacks by an entity integrated into a cloud
server that can be used to monitor what ratio of available bandwidth is being used. To find the
maximum available bandwidth of the server and to monitor the amount of bandwidth used by
each router, the entity Denial-of-Service-Bandwidth-Allowance-Device (DOSBAD) will
periodically send a series of packets to each possible path within the cloud. They use two large
packets and two small packets that are sent to the switch between the routers respectively. The
former packets are used to create a queue and the later to measure the time gap between being
sent and being received. To identify malicious activities, the proposed system measures the
number of incoming packets along with the amount of acknowledgement packets. When the
number of incoming packets starts to outweigh the number of acknowledgement packets sent,
that can indicate that the bandwidth limit may be close to being reached. This indicates that
there is an abnormal activity coming into the network, i.e., a flash crowd. At this point,
DOSBAD may look for common return addresses on incoming packets at the overwhelmed
router(s) and then send out a ping to those addresses. If DOSBAD does not receive a response
from an address, that may indicate a DOS attack being attempted. To investigate a possible DOS
attack, DOSBAD pings the suspicious address and identifies the address of the most incoming
packets by storing the signature of each incoming packet. Finally they conclude that, if a high
ratio of bandwidth is being used, one or more routers are overwhelmed by incoming packets, and
if high number of packets are coming in at a router from the same IP address that address is
suspicious to the system.

As a weakness to find the maximum available bandwidth of the server, DOSBAD periodically
sends a series of packets down each possible path within the cloud and this reduces the
performance of the network. Since DOSBAD is integrated into a cloud server to monitor what
ratio of available bandwidth is being used, it can create false positive results due to different
factors of the devices.

31
Mazzariello et al. [71] proposed that IDS service increases a cloud’s security level by applying
two methods of intrusion detection. The behavior-based method dictates how to compare recent
user actions to the usual behavior. The knowledge-based method detects known trails left by
attacks or certain sequences of actions from a user who might represent an attack. The audited
data is sent to the IDS service core, which analyzes the behavior using artificial intelligence to
detect deviations. The analyzer uses a profile history database to determine the distance between
a typical user behavior and the suspect behavior and communicates this to the IDS service. The
rules analyzer receives audit packages and determines whether a rule in the database is being
broken. It returns the result to the IDS service core. With these responses, the IDS calculates the
probability that the action represents an attack and alerts the other nodes if the probability is
sufficiently high. The analyzed data source IDS can be classified as network and host based.
Network based IDS analyzes traffic flowing through a network segment, by capturing packets in
real time, and analyzing and checking them against some “classification” criteria.

They suggested that an IDS can be further characterized with respect to the type of detection
mechanism implemented. Namely, an IDS can explicitly model attacks, anomalies and unwanted
behavior, thus implementing the misuse based detection paradigm, or conversely model normal
and expected events, consequently detecting as anomalous what doesn’t conform to such
“normality” model.

Treating anomalies as events that disturb the distribution of traffic features differs from previous
methods. Lakhina et al. [72] largely focused on traffic volume as a principal metric. In
comparison, feature-based analysis has two key benefits. First, it enables detection of anomalies
that are difficult to isolate in traffic volume. Some anomalies such as scans or small DOS attacks
may have a minor effect on the traffic volume of a backbone link, and are perhaps better detected
systematically for distributional changes instead of volume changes. Second, unusual
distributions reveal valuable information about the structure of anomalies information which is
not present in traffic volume measures. The distributional structure of an anomaly can aid in
automatic classification of anomalies into meaningful categories. This is a significant advance
over heuristic rule-based categorizations, as it can accommodate new, unknown anomalies and at
the same time expose their unusual features.

32
As a weakness the intrusion detection system administrator assigns a threshold value for packets.
In this case, a larger value means that a packet is received from a legal user and setting a
threshold value is not an easy task. The threshold value mainly depends on false positive rate and
it will miss the valuable packets. In addition to signature based, IDSs monitor the packets in the
network and identify threats by matching with database entries but it will fail to detect those
attacks that are not included in the database. Signature based IDS will perform poorly in
capturing large volume of anomalies.

Thomas and Janardhanan in [74] ascertain that protecting and defending the cloud infrastructure
against malicious attacks can be solved by designing intrusion tolerance. Intrusion tolerance in
cloud computing is a system security approach to safeguard a cloud infrastructure against
malicious attacks from unauthorized servers and hackers. The researchers proposed a framework
of cooperative intrusion detection system that incorporates intrusion tolerance to mitigate DoS
attacks. Intrusion Tolerance has to be achieved with the help of cryptographic methods and
proxy server. Proxy servers can analyze the behaviors of the client request and also the behaviors
of the intruders. If intruders are found in the proxy servers, their request will not be transferred to
the main servers. The proxy server blocks the intruders, i.e., the proxy server will analyze the
user as well as the data. Moreover, they use CloudSim toolkit that is used to launch a cloud
platform. It monitors the cloud process and stores the data periodically. They try to achieve
efficiency by authenticating the proxy and by encrypting the original data using data encryption
methods. Proper authentication will only allow the real data to be viewable reducing the risk of
intrusion. These methods enable the process to be reliable and secure, fulfill the client
expectation and serve them in better manner.

They also address the renewal and confidential property of sensitive data by utilizing secret key
sharing and adding a proxy server. The proxy server acts as an intermediate server between the
client system and cloud servers, blocks the intruders by sending a dummy dataset and by
analyzing their behaviors in the networks. Thus, the aim of the IDS is to alert or notify the
system that some malicious activities have taken place and ensuring suitable preventive measures
to eliminate it and preserving the integrity of the cloud platform.

33
As a weakness according to the recent development trends and advancement of intrusion
detection, detecting all kinds of intrusions across the platform effectively requires a holistic view
of the monitored network. So the system administrator or the system itself may take appropriate
and timely actions to prevent the incoming attacks. The attacks may never be completely
prevented, and some attacks may not be detected accurately and on time.

3.2 Works on DDoS Attacks

Lonea et al. in [65] work on detecting DDoS attacks in cloud computing environment using the
Dempster-Shafer theory (DST) operations. In their work, they combine the evidences obtained
from IDSs deployed in the VMs of the cloud systems with a data fusion methodology in the
front-end. They also use MySQL database placed within the Cloud Fusion Unit (CFU) of the
front-end server to store the VM-based IDS alerts during the attack. To meet their final goal, they
propose a quantitative solution for analyzing alerts generated by the IDSs, using the DST
operations in 3-valued logic and the Fault-Tree Analysis (FTA). The 3-valued logic applied in
their work are True, False and (True, False) to determine the basic probabilities assignment
(BPA’s) calculation in DST. Finally, their proposed solution uses the Dempsters combination
rule to the attacks assessment to maximize the true positive rates of DDoS. Their work shows the
implementation of all the stages of training, detecting, and preventing the attack in a clear
manner. As a limitation, the summarization of all packets in a matrix form, the conversion of
this matrix into covariance matrix, and storing a result matrix for further analysis is very difficult
when the number of packets increases.

Latanicki et al. in [69] proposed an extension to federated cloud architecture to use scalability
and migration of virtual machines to build scalable cloud defenses against cloud DDoS attacks.
The architecture is demonstrated by showing how three DDoS attack scenarios are handled by
the DDoS countermeasures. The paper considers a federated IaaS cloud architecture, analyzes
the new threats, analyzes DDoS attacks and proposes possible solutions. In order to take
decisions about the IaaS security architecture, information security, policy creation and
enforcement, an analysis of the various kinds of threats facing the IaaS architecture, its
applications, data and information systems is used. Focusing on threat analysis, they provided an
early classification in “External” and “Internal” threats. Based on the context of federated IaaS,

34
the researchers identified three sub-types of DDoS attacks and three attack scenarios introduced
to describe how they are carried out in the cloud entities. These attack scenarios are discussed in
each case as follows:

An external botnet attacking a set of virtual machines running in a Cloud (External to

Internal)

An internal botnet attacking a set of virtual machines running on the same Cloud or a
federation of clouds (Internal to Internal).

An Internal botnet attacking a target running somewhere on the Internet (Internal to
External).

In their work, they proposed a scalable solution for mitigating DDoS attacks by leveraging the
cloud capabilities. The idea is to use the scalability of federated cloud infrastructures to build
scalable cloud DDoS defenses that can deal more efficiently with DDoS attacks and restore
availability of the cloud infrastructure more quickly. For example, when an abnormal activity is
detected, IaaS defenses could scale up, e.g., increased monitoring of interfaces, or speed up
correlation analysis.

As a weakness the architecture that builds on the ability of federated IaaS to scale and migrate
Virtual Execution Environment (VEE) within the federation has a countermeasure that aims to
delay the attack sufficiently, to migrate all attacked VEEs toward machines outside the attacked
zone, to guarantee availability. But, the proposed solution did not show validating the
architecture by integrating the countermeasure in a federated IaaS architecture. Moreover there is
no any experimentation that will verify whether the scalability of the DDProbeM and
DDCorrelationM delay the attack sufficiently to migrate attacked VEEs. Therefore, performance
analysis is required to determine under which conditions the architecture can manage cloud
DDoS attacks.

Navaz et al. in [70] proposed a system by combining concepts which are available with new
intrusion detection techniques and merge Entropy based System with anomaly detection system
to mitigate multilevel Distributed Denial of Service (DDoS). This is done in two steps. First,
users are allowed to pass through a router inside the network that incorporates Detection
Algorithm and detects legitimate users. Second, it passes through a router placed inside the cloud

35
site that incorporates confirmation Algorithm and checks for threshold value. If it is beyond the
threshold value, it is considered as legitimate user, else it is an intruder. The system is
represented and maintained by a third party. When an attack occurs, it sends a notification
message for the client and an advisory report for the Cloud Service Provider (CSP). They call it
an Intrusion Detection for Grid and Cloud computing. In the system, each node identifies local
events that could represent security violations and alerts the other nodes. Moreover, each
individual IDS cooperatively participates in intrusion detection and provides sharing of
information between the IDS service and the other elements participating in the architecture: the
node, service, event auditor, and storage service.

3.3 Works on DoS Attacks Related to Flood Attack Type

Ismail et al. in [66] proposed a new framework to detect and prevent DoS attack in the cloud
computing environment. Their motivation was that cloud computing end users participate in
computing resources (co_tenancy), and by which infrastructure computing can be shared by a
number of users. As a result of this feature, some security challenges have been identified and
one of the most serious security threats is flooding attack, which prevents users from using cloud
infrastructure services. To overcome the problem, they use covariance matrix statistical method
at the attack detection stage, TTL (Time_to_Live) value counting method to determine attack
source, and Honeypot method for attack prevention. Their proposed framework depends on a
covariance matrix mathematical modeling with three stages: training, detecting, and prevention
stages. The strength of their proposed solution is the reduction of false negative rates, increase in
detection rate, resolve the conflicts generated by the combination of information provided by
multiple sensors, and improve the work for cloud administrators. As a weakness, when the
number of attacks increases, the Boolean tree becomes longer and longer, so the conversion of
alerts into Basic Probability Assignment (BPAs) will be very difficult.

Sanjay in [67] proposed a method to build a mutual and reliable computing environment for
cloud computing system by integrating the trusted computing platform into cloud computing
system. The paper tries to summarize basic characteristics, mutual and reliable security of cloud
computing which will help the development and adoption of rapid evolving technology. The
IDSs mutually exchange alerts to reduce the impact of the DoS attack and use the distributed

36
based intrusion detection system implemented into three modules called block, mutual, and
communication modules.

Each module has its own functions in the system, for example, a mutual agent is used to receive
alert messages from other intrusion detection systems. The idea of mutual defense by intrusion
detection systems in the cloud computing environments uses the techniques of DoS within the
system, therefore IDSs is deployed in each cloud computing region. Any IDS will send out the
alert to other IDSs while they are suffering from a DoS attack defined in the block table. Each
IDS exchanges alerts and has a judgment category to evaluate the reliability of these alerts.

In the proposed system the IDS component is used to gather network packets and analyse these
packets to check whether they are normal packets or not. If the packet corresponds with one of
the block table, then the system drops this packet immediately. If the packet is an odd packet
defined in the signature comparison rules, then the IDS component forwards it to the next
component for signature comparison. Otherwise the system accepts this packet.

As a weakness defined DoS attacks in the block table must be available for IDSs to exchange
information with each other about the attack or unusual activities. As a result, if a new attack
occurs that is not available in the block table, then the model fails to defend the attack. Since the
proposed system has multi process components like the block table and signature comparison, it
has its own impact on the performance of the system.

Shrivastava et al. in [73] introduced the benefit of using Internet Protocol Version 6 (IPv6) in
order to overcome the limitation of current detection and defense mechanisms against DoS and
DDoS attacks. DDoS attacks are most imminent security issues of a network due to the limitation
of current network components, multiplicity of attack methods, and invisibility of the operator to
host sites. The authors ascertain that different forms of DoS attacks can be defeated by tight
security policies and active measures like firewalls and vendor-specialized patches, but there is
no completely effective mechanism to defend these attacks. Moreover, the nature of DoS and
DDoS attacks like Smurf, TCP SYN flood, and UDP flood are also reviewed from the current
defense and detection mechanisms point of view. But, they mainly focused on academic
research. The reason is that most of the business approaches are not open to the public. They

37
used different techniques to mitigate the DoS attack, such as Ingress or Egress Filtering, IP
Traceback, Traffic Shaping, Traffic Analysis, and Host or Network Auditing.

They proposed secure node intercommunication to allow only trusted systems to communicate
with the node in the cloud network. They use source authentication to ensure the identity of a
node. They mentioned that, the inferring mechanisms, such as Ingress/Egress filtering, IP
Traceback and others, cannot be secure enough to prevent the DoS attacks because of the natural
characteristics of the current Internet Protocol with IPv4. So, they used the new IPv6 that has
IPv6 Header and an optional specific field, named Authentication Header (AH), that provides
message authentication and integrity. With regards to DoS attacks, there is no new mechanism
shown under their work. They tried to hinder attacks directly in ICMPv6 but they used IPv6
header as the only possible defense mechanism.

Their proposed solution has a situation that an attacking machine broadcasts a packet containing
too much data. The amount of data is intended to be greater than that of all nodes maximum
outgoing packet size and the source address is spoofed to represent a victim machine. Due to the
error checking nature of ICMPv6, the packet will not travel far and the available neighboring
nodes will send error messages of Packet Too Big to the victim machine. Each individual node
has mechanisms to prevent a flood of error messages. Yet, each node does not collaborate with
all neighboring nodes to ensure that the expected resulting effect is achieved. Once again, all
neighboring nodes should catch the spoofed message and prevent it from traveling any further.
As a result, the error messages will converge upon the victim node and a packet must simply be
coordinated to produce an error in some aspect of the message with a consistent source victim
node.

Their proposed solution secures node intercommunication to allow only trusted systems to
communicate with the node. Source authentication must be provided to ensure the identity of a
node. While these measures cannot prevent a malicious user from taking control of a privileged
system, an attacker is prevented from using the network as a traffic generator from an
unprivileged machine.

As a weakness in the shared cloud environment, clients want to ensure that all tenant domains
are properly isolated and that no possibility exists for data or transactions to leak from one tenant

38
domain into the next. To help achieve this, clients need the ability to configure trusted virtual
domains or policy based security zones. As data moves further from the client’s control, they
expect capabilities like Intrusion Detection and Prevention systems to be built into the
environment. The concern is not only intrusions into a client’s trusted virtual domain, but also
the potential for data leakages unknowingly and data extrusions knowingly, that is the misuse of
a client’s domain to mount attacks on third parties. Moving data to external service providers
raises additional concerns about internal and Internet based DoS or DDoS attacks. So, all the
above technical activities are very difficult to address by the client itself and it creates a non-
trusted environment.

Mann and Kumar in [75] presented an analytical approach which will employ Reactive Defense
Mechanism to mitigate the DDoS attack and further improve network performance in terms of
less computation time. Their work shows how to find out the number of packets being malicious
in the legitimate requests and then mitigate them using their proposed mechanism. In their work,
they incorporated analytical approach based on a mathematical equation which will be used to
find out the number of packets that are malicious under legitimate data packets. In addition to the
above approach, they used an algorithm which is a refined method of traditional hop count
inspection mechanism to mitigate the malicious packets which are coming along with the
legitimate data from the attacker side. The mathematical equation they used sets the value of a
Joint Probability to 1 to control the attacker utilization of bandwidth that exceeds the total
channel bandwidth capacity by sending too much malicious packets. So, by the help of this
analytical approach based on mathematical equations, they get the number of packets that are
malicious in legitimate data and then these packets can be mitigated on the basis of a hop count
value stored in their TTL (Time to Live) field. The proposed analytical approach is named Hop
Count Inspection with Malicious Probability Rate (HCI-MPR) based on Hop count Inspection to
mitigate these malicious packets.

As a result of their observation and conclusion from the simulation results, the proposed
analytical approach that addresses the problem of DDoS attacks saves potential computation time
and provides remarkable detection rate.

39
As a weakness they proposed additional mechanisms to work at large data rates by providing
some potential inputs in the future but there is no clear mechanism that is clearly shown in their
work.

Sowmya et al. in [76] proposed a generic security management framework that permits suppliers
of cloud knowledge management systems to outline and enforce complicated security policies.
This security framework is meant to detect and stop an oversized array of attacks outlined
through an expressive policy description language and to be simply interfaced with numerous
knowledge management systems.

They argued that their new proposed framework efficiently defends a storage system by
evaluating the security framework on the advanced data management platform. The main target
of their analysis is the detection of malicious purchasers that will be performing DoS attacks and
that can't be prevented by typical security mechanisms. Through the analysis process, if a mutual
authentication is performed it means that there is a possible threat in the system. This shows
those purchasers might behave in a very malicious way by making an attempt to break the
system, consume bandwidth or decrease its overall performance.

Their proposed work called a generic security management framework, which is targeted at
cloud knowledge storage systems, permits suppliers of cloud knowledge management systems to
outline and enforce complicated security policies. The genericity of their approach comes from
its flexibility and it supports custom security possible events and may be applied to completely
different cloud storage systems. Their work shows the cloud suppliers may benefit from generic
security management systems, by creating an interface with any of the cloud systems that exhibit
this kind of security vulnerabilities and by helping to handle and detect not solely predefined
attacks. They incorporated the following main components in the system:

Cloud Controller: to enforce the security policy towards all the active online clients in the
cloud network.

Clients: the set of different customers who are assumed to be utilizing the services
offered by the cloud service providers.

Virtual machine: It is a completely isolated guest operating system installation within a
normal host operating system.

40

Cloud infrastructure: the set of dispersed data centers which are networked with their
respective web servers and MySQL server.
In the proposed solution, there is a model integrated into the generic security management
framework which will manage the security policy set by a cloud controller. As a weakness of the
proposed framework, in the case of more complex policies, it is difficult to handle the detection
process accurately. Moreover, from the probability of using more complex policies during the
detection process, there may be high false positive or false negative results. In addition, it needs
further development to the trust management component of the security management framework
and their study did not show the impact that it has on the policy enforcement decisions for
complex scenarios.

3.4 Summary

From the review, clouds are vulnerable to many attacks and malicious behaviors that threaten
both data and physical and virtual computing resources of the cloud. Basically, any set of actions
that threaten the cloud security requirements (e.g., integrity, confidentiality, availability) are
considered to be attacks. Attack detection and prevention components should be installed within
the cloud security system to protect cloud resources from various anomalies. From these
anomalies, DoS attacks are the main ones that are addressed through different researches. All the
reviewed works show how these attacks should create a minimum problem or no problem at all
to guarantee the maximum availability of the services. This can be achieved by deploying
different detection and prevention methods and techniques that provide high availability such as
dynamic server load balancing and active clustering. Clouds should also be provided by the next
generation of intrusion detection systems and firewalls in order to protect resources from
intruders.

Like viruses, new DoS attacks are constantly being developed by attackers. Therefore continuous
researches and providing solutions for current problems are needed to beat the attackers’ idea in
advance. The gaps to be filled in this work are also expected to provide its own contribution. So,
our contribution will focus by identifying the attacking mechanisms of an attacker on the virtual
machines and providing solutions to detect and mitigate DoS attacks on users services specially
on IaaS.

41
 Chapter Four: The Proposed Solution

4.1 Introduction

As we discussed in Chapters 2 and 3, there are two general forms of DoS attacks: those that
crash or damage services and those that degrade or completely deny legitimate users from using
different online services. Therefore, different researches are currently trying to detect and
mitigate this attack. In this thesis, we proposed an architectural framework to mitigate the DoS
attack on IaaS of cloud system from flooding attacks like TCP, UDP, and ICMP. To achieve the
goals of this DoS attack mitigation our proposed framework identifies the attackers’ behavior
based on their activities, if their actions are out of the predefined cloud policies. This action
provides an input to identify whether there is a DoS attack in the cloud or not.

So, in the following sections we will describe the details about the mitigation techniques and the
components of the architectural framework in the proposed solution. In Section 4.2, we describe
and present the proposed architectural framework for DoS attack mitigation on IaaS on the cloud
service. Section 4.3 summarizes the requirements and assumptions of the proposed solution
based on the given architectural framework, and Section 4.4 summarizes the Chapter based on
our proposed architectural framework of DoS attack mitigation.

4.2 Description of the Proposed Solution

In this section, we describe and present the proposed solution for DoS attack mitigation on the
IaaS for the case of cloud computing environment as illustrated in Figure 4.1. The architecture
shows the cloud users which contain N number of users based on the Internet model to access the
cloud computing environment. The DoS attacker shares the same infrastructure with legal users
that creates flooding attack and utilizes the bandwidth of legitimate users to prevent them from
their normal activities. Different cloud policies like Service Level Agreement (SLA),
Certificates, and Service Level Objectives (SLO) are considered to manage and analyze the
users’ behavior for further DoS attack identification by the proposed system.

42
 Proposed
Model on the
Cloud Front
End Server

CFE_
Legitimate Users Internet Server

IaaS

Legitimate Users’ Packets

Attackers’ Packets

DoS Attackers
Figure 4.1: Location of the proposed solution

Generally, to design the DoS attack mitigation architectural framework in the cloud computing
environment, four basic parties must be clearly identified: legitimate users, DoS attacker,
proposed architectural framework, and the cloud services provider. As a general architectural
framework <U, DA, MM, CSP> could be designed, where U stands for legitimate users, DA
stands for DoS Attacker, MM stands for Mitigation Model, and CSP stands for Cloud Services
Provider.

Our aim is to make our design architecture effective against DoS attacks. More specifically,
when a DoS attack is suspected from an incoming request, our proposed system will enable to
overcome the traffic through its mitigation process. This reduces the chance that the attack traffic
causes any damage and prevents the attack traffic from wasting network resources. When DoS
attackers conspire into sender-receiver pairs to flood the system such that no legitimate entities
can distinguish attack traffic from legitimate traffic, our proposed architecture gives a guarantee
to the legitimate user its fair share of network resources. That is, for the limited link capacity

43
shared by specific number of users, each user should get sufficient traffic demand to be
guaranteed by allotting at least a minimum bandwidth share from that link. So, to provide this
minimum bandwidth share our proposed solution will control the bandwidth consumption
through packet size transfer per second based on the given threshold value.

The most common flooding attacks that occur on the cloud computing environment are the flood
of a lot of packets within a given time interval to consume resources allocated for the legitimate
users. So, TCP, UDP, and ICMP packets are selected by the attackers for flooding the cloud
computing environment. It depends on what the attackers are trying to deny access to, and how
they are trying to do it.

The ICMP and UDP attacks are likely to be trying to flood any networked systems with packets,
which will slow down or even stop legitimate users’ packets from flowing. When a link starts to
get overloaded, legitimate users’ packets and connections are slowed down, which obviously
affects normal traffic.

Figure 4.2: The Proposed Architectural Framework

44
Figure 4.2 shows our proposed architectural framework of DoS attack mitigation of the cloud
computing environment. So, to prevent such attacks our design of DoS attack mitigation
architectural framework consists of the following components: Data Management Unit (DMU),
Bandwidth Analyzer (BA), Packet Analyzer (PA), and Timestamp Unit (TU). Next we present
each component of the architecture and describe the interaction among them.

4.3 Components of the Proposed Architecture

The components of the proposed solution mitigate the DoS attack via coordination. The initial
inputs or the flow of unfiltered data packets to the proposed solution is coming through the Data
Management Unit (DMU) and the filtered output pass through the cloud interface of the cloud
environment. In between other components like Bandwidth Analyzer (BA), Packet Analyzer
(PA), and Timestamp Unit (TU) are parts of the DoS attack mitigation process. Figure 4.3 shows
the proposed architecture flow chart, which holds all the components of the architecture with
their functions.

45
 Start

Incoming Request

Initiate the DMU

Initialize Bandwidth Is request from

Analyzer legitimate
Yes user? No

Is a packet
size under the Initiate Packet Analyzer
threshold? No

Yes

Is privileged
Pass the request to Timestamp Unit
Yes packet?

No
Packet timestamp & Pass to Cloud
Register the request in to the Suspicious
IP list

Allow access to cloud services as

Deny access or block communication
per the agreement & usage policy

Cloud sends response to DMU

Cloud sends response to the respective user

Stop

Figure 4.3: The Proposed Architecture Flow Chart

46
Other Components

These components are other components in the implementation of DoS attack mitigation in
addition to our proposed architectural framework components and they are important
components as a participant in the mitigation process as shown in Figure 4.4.

Cloud Users: are a set of different customers who are assumed to be utilizing the services
offered by the cloud service providers. The clients will be entitled for uploading, modifying,
deleting, and accessing their own data as per their privilege. All the clients are under strict
awareness of cloud service provider.

Virtual Machine: A virtual machine (VM) is a software implementation of a machine (i.e., a
computer) that executes programs like a physical machine. All the services provided by the
cloud services provider are implemented through VMs.

Cloud Infrastructure: is set of dispersed data which are networked with their respective
web servers, database server, etc. The cloud service provider uses it as a base for all service
provided to clients based on the written agreement on the SLA or SLO.

Malicious Process: the following are the three types of malicious processes of a DoS attack

o Flooding: multiple duplication of requests during files upload/modification/file

accessibility using TCP, UDP and or ICMP packets flooding.

o Bandwidth Degradation: while using these packets, the attacker tries to lead the
Cloud to bandwidth depletion attack due to packets of different size.

o Spoofed IP: a false address used for an attack.

47
 Figure 4.4: Flooding DoS Attack on the Cloud

4.3.1 Data Management Unit

The attacker can use several VM instances which can then be instantiated as required to be part
of the attack. Depending on the attack motivation, the attacker can run query instances repeatedly
in the target zone of the cloud. After the target is successfully addressed with its attacking, it
will use more malicious VMs, and sends malicious packets per VM over the shared network
channel to cause a DoS attack on the cloud infrastructure as shown in Figure 4.4. The process of
this attacking mechanism makes the attack difficult to identify by the Cloud Service Provider
(CSP). Thus to meet its objective the attacker sets different actions, for instance: identify the
number of VMs to be used to conduct the DoS attack, deciding the bit rate of the traffic to be
sent from each VM, and the attack type it uses in that particular DoS attack. So, attack
prevention is a mechanism which stops the attacks before they actually cause damage. One
effective mechanism of attack prevention is packet filtering, which filters incoming traffic
according to specified rules.

48
If the attacker uses a DoS attack tool like Shaft which is a derivative of the Trinoo tool, it will
create attacks that can be run individually, or in combined form with UDP/TCP/ICMP flooding
to make one attack. So, to mitigate such a difficult flooding attack, the Data Management Unit
(DMU) uses the packet IP address information to identify the incoming requests. Such processes
can be used to identify normal traffic, detect abnormal traffic and determine the type as well as
source of traffic. The identification of legitimate user’s incoming requests as well as the
attacker’s behavior by extracting required information of the packet will be applied for further
process. So, DMU filters the packets as malicious and/or normal and makes decisions of either
transfer to the Bandwidth Analyzer or Packet Analyzer for further processing.

This unit has a filtering scheme that filters incoming packets according to a specific rule to make
sure that incoming packets are from the network they claim to be from. In DMU, a packet
coming into the network is identified as suspicious packet, if the network sending it should not
use the given source IP address from the CSP. Packets from cloud users to CSPs, all the IP
addresses which do not belong to the CSP's network will be filtered. For example IP addresses
other than XXX.XXX.*.* will be filtered. IP addresses identification of cloud users during their
communication with the CSPs is effective for defending against IP source address spoofing,
which is a fundamental weakness of the Internet.

For example, assume that a CSP provides services to a legitimate cloud user in the network and
assigns the user a fixed set of IP addresses within a give range of IP addresses. To limit IP source
address spoofing, the DMU places a filter on the input link of the cloud, which carries packets
from the user network into the CSP network and onto the Internet. The filter is set to forward
along all packets with source addresses that belong to the known set of IP addresses assigned to
the user network by the CSP, but the filter discards (and optionally logs as suspicious) all packets
that contain source IP addresses that do not match the valid range of the customer’s known IP
addresses. Hence, packets with source addresses that could not have legitimately originated from
within the user network will be dropped after analyzed by the Packet Analyzer of our proposed
architectural framework. But, if the attacker uses the legitimate cloud user IP addresses by
spoofing the DMU uses the IPsec authentication using control field value of the packet, when
the our proposed architectural framework detects an attack, the key exchange establishes IPsec
security between the target host and the legitimate cloud user in the administrative domain. This

49
prevents the proposed architectural framework as well as the cloud infrastructure from being
attacked by spoofed packets flood.

The other task of this unit is to protect the proposed architecture from flood attack by
determining the aggregate flow packets through limited rate. For instance, the following
components of the packet can be extracted: Source IP, Control field value, Source Port,
Destination IP, Destination Port, and Protocol types, to be used in the mitigation process. The
information we get from the extraction of the packets helps as an input for the Bandwidth
Analyzer, and for the Packet Analyzer for further mitigation processing. As we see from Figure
4.2, the data store holds suspicious IP addresses as well as legitimate IP addresses lists for future
references. To show the function DMU clearly we use the algorithm that recognizes three cases
for each captured packet in the operation.

Case1. If the source IP addresses do not belong to the CSP's network, then the request will be
forward to the Packet Analyzer for further processing.

Case2. If the source IP addresses belong to the CSP's network but the requests apply more than
the given limit, then use the IPsec authentication using control field value of the packet and
create key exchange between the legitimate user and CSP to check IP spoofing. Finally, if the IP
spoofing happens then the request will be forward to the packet Analyzer for further processing.

Case3. If the source IP addresses belong to the CSP's network, then the request will be forward
to the Bandwidth Analyzer for further processing.

To apply these three cases we assume the following: if the particular IP address has been signed
on for the first time, it makes the status as legitimate user. This action is true for a maximum of 3
trials. For the fourth time it makes the particular IP address status as malicious user. In the time
calculations we are only considering 4 times. DMU acts by inspecting the "packets" that transfer
between cloud user and the CSP. The other packet rule considers the predefined IP address range
set be the CSP, if the particular IP address has been signed within the given range of predefined
IP address DMU makes the status as legitimate user. If a packet matches the packet set of rules,
the DMU will set decision on the packet on either of the cases.

50
So, DMU will take the advantage to check the given IP address whether it is from the suspicious
IP address or from the privileged cloud user IP address based on the predefined source IP address
from the CSP to provide a reliable decision on the mitigation process. So, Data Management
Unit is responsible to receive incoming request based on the predetermined aggregate flow of
packets through limited rate and send respective response to other components of the proposed
architectural framework. It identifies each incoming request whether it is from a legitimate user
or not. If the request is not valid then the request will be sent to the Packet Analyzer for further
processing. If the request is from legitimate user then it will be forwarded to the Bandwidth
Analyzer as shown in Figure 4.5.

Data_Managment_Unit() //Input: Rq Request from user //Output: Rq Request to BA or PA

H=Maintain the IP address range; U=Time user enter into the cloud; I=Each user IP address;

If (I∈H) // check for I is an element of legal IP address range

{
Accept the request from the client and Send the request to the BA.
}
else // check for number of trials and IPsec authentication

{
If (U<4)
{

Accept the request from the client and Send the request to the BA.
}

else
{
Check for key authentication;
Accept the request from the client and Send the request to the PA;
}
}//else

BA: Bandwidth Analyzer PA: Packet Analyzer

51
 Figure 4.5: Pseudo- code of the Data Management Unit

4.3.2 Bandwidth Analyzer

It accepts necessary inputs from the Data Management Unit to process malicious user for the
bandwidth depletion attack. The two main strategies of infrastructure attacks are exhausting
bandwidth via a flood of packets and DoS attack by exhausting processing power, memory, or
OS exploitation in the implementation of a system. In comparison, the bandwidth flooding is a
common problem that is relevant to almost all parts of the Internet and needs a common solution.
It is known that bandwidth depletion attack floods a victim network and thereby prevents
authorized traffic from reaching and getting the service of the targeted victim. This can be done
through different flooding types, for instance:

In a UDP Flood attack, numerous amounts of UDP packets are sent to either random or
specified ports on the victim system to create bandwidth depletion.

ICMP flood or ping flood is a simple attack where the attacker overwhelms the victim
with ICMP Echo Request (ping) packets with different sizes to consume the outgoing
bandwidth as well as incoming server bandwidth.

In addition to the above two flooding attack types, it is possible to experience a TCP
flooding attack that is not taking advantage of the TCP three-way handshake. It is also
possible to commit a TCP flooding attack taking advantage of other TCP’s finite state or
TCP’s flags to use a lot of bandwidth and degrade the service availability of legitimate
users.

From the cloud policy point of view we can observe the rate limiting data flow from VMs in case
of bandwidth depletion. If the Cloud Service Provider serves N VMs, the traffic from each of
these N VMs is rate limited to 1/N with equal share bandwidth usage among VMs. In other
words, the bandwidth is evenly shared between the VMs; but this approach cannot prevent DoS
attacks since the attacker can use an arbitrary number of VMs to send traffic. To be more
effective in mitigating DoS attacks we can limit the number of byte transfer per VM, but still will
suffer from the DoS attack problem that the attacker can use more source VMs than the
legitimate traffic. So, the allocation of byte transfer rate for different applications of VMs can be

52
based on the Types of Services (ToS) parameters with a predefined limited rate profile
accordingly to consider as a mitigation criterion in the process.

Let us consider n as the total number of packets to be processed from each VM with constant
packet size of C bytes and t is the average time for each packet during process. From the above
assumption the maximum rate of an application from a single VM to be processed is (n*C)/t.
Thus, let Rmax = C/t in Byte per second, and if the maximum rate utilized a VM as per packet
flow is greater than the maximum allocated usage by each VM for a single packet which is
1/N*n of the total available capacity, then bandwidth analysis control must be implemented. To
do this the Bandwidth Analyzer (BA) is responsible to detect whether the packet flow rate is
under the specified threshold or not. If it is under the threshold the request will be forwarded to
the Timestamp Unit for further processing. Otherwise, the user request will be forwarded to the
Packet Analyzer. So, the Bandwidth Analyzer adjusts itself to check the bandwidth depletion
attack by taking packet flow rate and makes a decision based on the algorithm shown in Figure
4.6. Finally, if the suspected user is free from the bandwidth depletion attack the output will
transfer to the Timestamp Unit otherwise to the Packet Analyzer for further analysis. Steps to
determine the decision based on the given threshold in the bandwidth analyzing process:

1. Decide the total number of packets to be processed from each VM of a cloud legitimate user,
say n.
2. Determine the packet size which is forwarded from cloud legitimate user with constant value,
say C bytes.
3. Determine the average time of process for each packet which forwards from cloud legitimate
user, say t second.
4. Calculate the rate utilized by each legitimate cloud user, say Rmax = C/t
5. Determine the total number of legitimate cloud users and total capacity, say N and Q
respectively
6. Find the maximum allocated usage by each cloud legitimate user by a single packet, say
Rnor= Q/N*n
7. Compare the utilized amount by each legitimate cloud user and the maximum allocated usage
8. If the utilized amount is above the allocated usage make a decision to send to the Packet
Analyzer else to the Timestamp Unit.

53
Bandwidth_Analyzer () //Input: Rq Request from DMU //Output: Rq Request to TU or PA

n= total number of packets;

C = packet size in byte;

t = average time in second;

N=total number of legitimate cloud users;

Q= total capacity;

Rmax = C/t; // rate utilized by each legitimate cloud user

Rnor= Q/N*n; // maximum allocated usage by each legitimate cloud user

If (Rmax > Rnor)

Send_Request_DMU(Rq); //Accept the request from the DMU as input and Send the request to the
PA.

else

Send_Request_TU(Rq);//Accept the request from the DMU and Send the request to the TU.

}//else

DMU: Data Management Unit PA: Packet Analyzer TU: Timestamp Unit

Figure 4.6: Pseudo- code of the Bandwidth Analyzer

54
4.3.3 Packet Analyzer

It receives input from the Data Management Unit or from the Bandwidth Analyzer to check the
priority and privilege of packets of the request. The goal of a flooding attack is generally to
overload the network capacity on some link to a server. Types of packets that are commonly
used for this flooding attack have different packet size, and the most effective packets attacks are
ICMP (ping), UDP packets, and TCP SYN packets (opens a connection). To apply DoS attacks
the attacker uses packets with spoofed source addresses, the reason is to get responses from
server, which might flood from the attacker, or to make it harder to identify the attacker. So, all
TCP, UDP, and ICMP packets have their source or destination addresses depending on the value
translated to identify whether the packets are privileged or not.

The Cloud Service Provider (CSP) sets control field to create communication in the cloud
computing environment on the source and destination VMs from their hypervisors between the
cloud users and the service provider. The control field is an 8 bits value where the initial bit
value is 1. The packet contains the header of the first data packet of that flow from each VM,
which is used to check its policy by the CSP. The packet control field specifies the action to be
applied in the flow to block packets which come from malicious users. Control packets are
distinguished from the rest of the data packets by using a control field value in the IP header with
8 bits values set for specified group of cloud users. The control field value applied for this
purpose has a value from 128 to 255 which determine the first bit of the control field value as 1
means the bits value between 10000000 to 11111111. Moreover, data packets in the cloud
contain a 31-bit sequence number, 29-bit message number, and a 32-bit time stamp. Conversely,
the control packet header holds the first 8 bits, called control bits, from 0-7, the next 8 bits called
Types of Service (ToS) or information from 8-15 and bits from 16 -31 can be used for user-
defined types. The detailed control information depends on the packet type on ToS. Figure 4.7
shows the IP header format for the cloud control packet to exchange information between the
cloud user and the CSP.

55
 Figure 4.7: IP header format for the Cloud Control Packet

Our proposed architecture uses a database (DB) to hold predefined list of IP addresses of
legitimate users, suspicious IP list, and control field value set by the CSP. When a packet reaches
its destination its control field value is extracted; this value is known as source control field. In
this section of our proposed architecture, we use these source control field value for filtering
mechanism, and provide a clear idea of implementation to mitigate DoS attacks in cloud
environment. The algorithm requires continuous monitoring of packets travelling over the
network in the cloud, by using the extracted value of source control field value, source IP, and
flag information from packets. The algorithm recognizes four cases for each captured packet in
the whole operation.

Case1. If flag is set and source IP address exists (flag=1 and SrcIP=1) then get source control
field value of the packet. Now check if the source control bit value matches with the stored
control field value from the DB, if not and the first bit of source control bit value=1 , then update
source control field value for that source IP address in the DB and allow the packet to pass to the
Timestamp Unit.

56
Case2. If flag is set and source IP address does not exist (flag=1 and SrcIP=0) then get source
control field value of the packet. Now check if the source control field value matches with the
stored control field value from the DB. If they match then add a new entry for the source IP
address with the corresponding control bit value in the DB and allow the packet to pass to the
Timestamp Unit.

Case3. If flag is not set and source IP address exists (flag=0 and SrcIP=1) then get source control
field value of the packet. Now check if the source control field value matches with the stored
control field value from the DB, if this source control field value does not match the stored
control field value entry in the DB for the corresponding source IP address, then packet is
spoofed, else the packet is legitimate and allow the packet to pass to the Timestamp Unit.

Case4. If flag is not set and source IP address does not exist (flag=0 and SrcIP=0) then it means
that the packet is spoofed, because every legitimate IP address having a valid TCP connection
will have its entry in the DB.

Thus, the packet analyzer takes a decision based on the above four cases to identify a malicious
user and blocks it from communicating the cloud. On the other side, data that comes from
legitimate users get consent to communicate with the Timestamp Unit for further processing. So,
if the user truly exists in the system as legitimate, the analyzer, instead of dropping the data, will
grant the time update by the Timestamp Unit and accept its request for communication. Else, the
data will be dropped and the suspicious user information is stored in the black list DB for future
investigation. Figure 4.8 shows the pseudo code of the Packet Analyzer of our proposed
architecture in the DoS attack mitigation process.

Packet_Analyzer()

//Input: Rq Request result from DMU or BA

//Output: Rq to TU, Update DB, Drop request, Allow request

Case1:

If(flag is set)

57
If(ScrIP exists in the DB)

Get(ScrIP,StcF,flag);

Stc_Field=StoreControlFieldV(StcF);//get stored control field value

Soc_Field=SourceControlFieldV(SocF);//get source control field value

If(SocF = StcF)

UpdateDB(ScrIP, SocF);

‘Allow the packet’;//the packet is legitimate

else

UpdateDB(ScrIP, SocF=0);

‘Drop the packet’;//the packet is spoofed

}//get

}//If

Case2:

else//source IP address doesn’t exist

Get(ScrIP,StcF,flag);

58
 Stc_Field=StoreControlFieldV(StcF);//get stored control field value

Soc_Field=SourceControlFieldV(SocF);//get source control field value

If(SocF = StcF)

UpdateDB(ScrIP, SocF);

‘Allow the packet’;//the packet is legitimate

else

UpdateDB(ScrIP, SocF=0);

‘Drop the packet’;//the packet is spoofed

}//get

}//else

}//If

Case3:

else//flag is not set

If(ScrIP exists in the DB)

Get(ScrIP,StcF,flag);

Stc_Field=StoreControlFieldV(StcF);//get stored control field value

59
 Soc_Field=SourceControlFieldV(SocF);//get source control field value

If(SocF != StcF)

UpdateDB(ScrIP, SocF=0);

‘Drop the packet’;//the packet is spoofed

else

UpdateDB(ScrIP, SocF);

‘Allow the packet’;//the packet is legitimate

}//get

}//If

Case4:

else//SrcIP doesn’t exist in the DB

UpdateDB(ScrIP, SocF=0);

‘Drop the packet’;//the packet is spoofed

}//Case3 else

BA: Bandwidth Analyzer DMU: Data Management Unit TU: Timestamp Unit

Figure 4.8: Pseudo- code of the Packet Analyzer

60
4.3.4 Timestamp Unit

The main purpose of this unit is to renew the timestamp of the legitimate user’s packets to create
better communication with the cloud services. Timestamps are typically used for classification of
events in a sequence of events (SOE), in which case each event is marked with a timestamp.

The prevalence of dynamic network addresses on the Internet makes timing important in all
types of investigations of events that occurred on the Internet. In these investigations, attribution
relies on the identification of which computer was using an IP-address at a particular time. If the
IP-address is dynamically assigned, the originating computer can only be identified if a log of the
usage of the address exists, and the time of the event can be established with sufficient certainty
and accuracy. When we come to cloud computing, cloud users can independently prove the
integrity of their data when they use trusted timestamps between the user and CSP in a cloud
computing environment and cloud services can use “data integrity protection” and “guarantee” as
a key competitive differentiator. The importance of this trusted timestamps between the user and
CSP in the process of providing cloud services based on their SLA is as follows. A cloud user
requests the creation of a new instance of a cloud service (1). The IT resource is instantiated and
the pay-per-use monitor receives a "start” event notification from the resource software (2). The
pay-per-use monitor stores the value timestamp in the log database (3). The cloud user later
requests that the cloud service instance be stopped (4). The pay-per-use monitor receives a "stop”
event notification from the resource software (5) and stores the value timestamp in the log
database (6).

So, whenever a user logs into the cloud the time is registered at a start event and the total time
constraints are analyzed by timestamp in which the amount of time which is required for
executing that particular service will be calculated. Here total timing required is calculated by
creation timing and receipt timing. Cloud providers need to ensure that a universal time source is
used across its infrastructure to eliminate potential discrepancies in timestamps.

This will require the creation of provisions to ensure that provider and application logs, along
with any other relevant data, are handled appropriately. It is also reasonable for organizations to
mandate an accurate synchronization of timestamps to aid in the investigation of a security
incident. If timestamps cannot be relied upon, then in many cases, it cannot be possible to trace

61
the use of an IP-address, since identification of the time of the event is necessary to find the
correct originator in the cloud computing environment. Therefore, the exact timing information
is necessary for compliance to laws and policies based on the SLA.

Our proposed architectural framework adjusts the time stamp value using the Timestamp Unit
(TU) to maintain smooth communication between the user and CSP based on the SLA. To do
this, we take the initial or starting event time (to) and the final process time during the mitigation
process (tf).

∆t=tf-to and if ∆t > the maximum allotted time (tmax) to create normal communication time

between the cloud user and CSP then the time stamp value must be adjusted to to = to + ∆t to
prevent the user request from timout.

So, the Timestamp Unit (TU) renews the time stamp of valid requests forwarded from the
Bandwidth Analyzer or Packet Analyzer and finally forwards the renewed request into the cloud
interface as shown in Figure 4.9.
Timestamp_Unit(Rq:Request) //Input: Rq Request result from PA or BA //Output:
Request with timestamp
to= starting event time;

tf = final processing time during the mitigation process;

tmax = maximum allotted time on SLA;

∆t=tf-to;

If(∆t > tmax)

{
to = to + ∆t; //Generate new timestamp

Rq_newtimestamp=Update_TimeStamp(Rq,t0);

//Update the Request or packet with new timestamp;

SendnewRequest(Rq_newtimestamp);

//Send new request to cloud;

BA: Bandwidth Analyzer PA: Packet Analyzer

Figure 4.9: Pseudo- code of Timestamp Unit
62
Finally the Cloud uses its interface component to create communication between the proposed
architecture and the Cloud infrastructure. Based on the input which comes from the Timestamp
Unit the cloud establishes smooth communication for legitimate users and provides information
to the cloud service provider to grant access to cloud services for legitimate users as per the
agreement on SLA or SLO.

Service quality management capabilities enable the service providers to proactively evaluate
their capacity and resource availability and address the communication issues in a timely
manner. The cloud has this service quality management functions to enable communication
service providers to evaluate and adhere to committed service-level agreements (SLAs) for
particular communication services to the Cloud user. Constant monitoring of network and
service capacity and availability are vital to delivering these SLA agreements.

Finally, the Cloud sends a response to the Data Management Unit to show the successful
communication between the client and the cloud service. So, Cloud receives requests from the
Timestamp Unit and checks the timestamp value, and then allows access to the cloud service as
per the agreement and usage policies. The cloud sends the response to the DMU for the specific
user request for the legitimate users of the cloud.

4.4 Summary
In this Chapter, we described the main components of our proposed architecture to mitigate DoS
attack on the IaaS of the cloud computing environment. The architecture has four main
components: Data Management Unit, Bandwidth Analyzer, Packet Analyzer, and Timestamp
Unit. All the components in the proposed architecture are direct participants in the mitigation
process, i.e., the output of one component will be the input of the next component.

The proposed architecture follows a step by step decision making process based on the given
input as per the requirement of each component. The decision making process is mainly
concerned on the privilege of legitimate user’s activity. If the activity looks as if it is malicious
activity, the investigation process on that user activity will be initiated and either of the decisions
allow or deny are applied on that particular user.

63
The mitigation process applies on the flooding attack that consumes basic resources of the
legitimate users like UDP, ICMP, and TCP flooding types. Our proposed architecture relies on
three steps to mitigate this type of attack. The first step is request identification based on the
incoming requests to determine whether from legitimate users or not. The second step is
bandwidth depletion on the given infrastructure based on the flood packet size under the
specified threshold. The third step is about priority and privilege checking on the flow of packet
requests using packet analysis. In the next Chapter we will describe the prototype detail of the
proposed architecture to mitigate the DoS attack on the IaaS of the cloud computing
environment.

64
 Chapter Five: Evaluation and Analysis

5.1 Introduction

Our work is designed based on the cloud computing infrastructure security to mitigate DoS
attack using OPtimized Network Engineering Tools (OPNET), and was created by OPNET
Technologies, Inc., which was founded in 1986 as open source network simulation tool. So this
design work shows three different scenarios called baseline, DoS attack with no mitigation, and
DoS attack with mitigation scenarios. The reason to use these scenarios is to see the clear impact
of DoS attack on the cloud users and how our mitigation architectural framework mitigates the
attack to provide reasonable services assurance for legitimate users.

The first is called baseline scenario and it is an IPcloud deployed over WAN (Wide Area
Network) as this cloud is the representation of cloud features to show security issues regarding to
different cloud types. There is a network of four servers: database server, Web_server, FTP
server and Mail server that work as cloud. This cloud gives services of database, web
applications, ftp and mail to three different LANs as cloud legitimate users in which one of them
is connected internally to a cloud router and two of them are externally connected to the WAN
through a router and are directed towards the cloud. These LANs get all the four services from
the cloud and there is a smooth flow of traffic because no attacker is attacking the cloud.

The second is called DoS attack with no mitigation scenario is attacking the cloud by generating
ping traffic after every 0.1sec. This ping traffic is DoS attack. Due to this the cloud becomes
busy and servers do not receive the requests from legitimate users like the first scenario and users
face delay of authenticated services and links choke due to the suspicious traffic.

The third is called DoS attack with mitigation scenario, where our proposed mitigation is placed
between the CSP_router and IP cloud (Internet) to block the unnecessary ping traffic DoS attack
coming from the attacker. This DoS attack is to be mitigated by setting the proposed network
model in OPNET. As a result, authenticated services are sent or received at both the source and
destination sides because our proposed architectural framework allows legitimate user requests
to pass through it.

65
To accomplish the above tasks, we implement the following OPNET components: Project Editor,
Node Editor, Process Model Editor, Link Model Editor, Path Editor, Packet Format Editor, Probe
Editor, Simulation Sequence Editor, and Analysis Tool. The implementation detail of these
components is presented in various sections of this Chapter. Section 5.2 gives an overview of
prototype description. Section 5.3 describes the development environment employed to
implement the proposed architectural framework and presents the implementation description of
the different scenarios with their respective simulation experiment and evaluation result. Finally,
we summarize the Chapter in Section 5.4.

5.2 Prototype Implementation

The development environment, programming language and simulation tool that were used for
implementation and evaluation of the proposed solution is described in this Section. So, the
capabilities and programming issues of the OPNET modeler, the simulation platform on which
the “DoS attack mitigation of our proposed architectural framework” is implemented to show the
DoS attack mitigation process of our proposed architectural framework. OPNET provides a
comprehensive development environment supporting the modeling of communication networks
and distributed systems. Both behavior and performance of modeled systems can be analyzed by
performing discrete event simulations. The OPNET environment incorporates tools for all phases
of a study, including network model design, simulation, and result evaluation

We have used the following common OPNET Modeling Domains to show our work:

5.2.1 Network Domain

The Network Domain’s role is to define the topology of a communication network. The
communicating entities are called nodes and the specific capabilities of each node are defined by
designating their model. Within a single network model, there may be many nodes that are based
on the same node model; the term node instance is used to refer to an individual node, in order to
distinguish it from the class of nodes sharing the same model. However, in general, when the
term node is used by itself, in the context of the network domain, it can be assumed that a node
instance is being referred to, rather than a node model.

66
5.2.2 Node Domain

The Node Domain provides for the modeling of communication devices that can be deployed
and interconnected at the network level. In OPNET terms, these devices are called nodes, and in
the real world they may correspond to various types of computing and communicating
equipment such as routers, bridges, workstations, terminals, mainframe computers, file servers,
and so on.

Node models are expressed in terms of smaller building blocks called modules. Some modules
offer capability that is substantially predefined and can only be configured through a set of built-
in parameters. These include various transmitters and receivers allowing a node to be attached to
communication links in the network domain.

5.2.3 Process Domain

The processor modules are user-programmable elements that are key elements of communication
nodes. The tasks that these modules execute are called processes. A process can in many ways be
thought of as similar to an executing software program, since it includes a set of instructions and
maintains state memory.

Processes in OPNET are based on process models. The relationship between process model and
process is similar to the relationship between a program and a particular session of that program
running as a task (in fact, the term “process” is used in many operating systems as well).

OPNET expresses process models in a language called Proto-C, which is specifically designed
to support development of protocols and algorithms. Proto-C is based on a combination of state
transition diagrams (STDs), a library of high-level commands known as Kernel Procedures, and
the general facilities of the C or C++ programming language. A process model’s STD defines a
set of primary modes or states that the process can enter and, for each state, the conditions that
would cause the process to move to another state. The condition needed for a particular change
in state to occur and the associated destination states are called a transition.

67
5.3 Development and Simulation Tools

In the previous section, the necessary tools are identified for designing and implementing our
proposed DoS attack mitigation architectural framework. This section describes the
implementation detail of the different components of the proposed architectural framework.
Section 5.3.1 describes the implementation of the baseline scenario of the smooth network
communication model between the service provider and the legitimate users. Section 5.3.2
discusses the implementation of the DoS attack without mitigation scenario, to show the traffic
impact of an attack on the legitimate users. Section 5.3.3 describes the implementation detail of
our DoS attack mitigation scenario, to show the simulation results over the mitigation process.

Figure 5.1, represents the working area of the OPNET simulation to create different network
models and we use this simulation tool environment to show our proposed architectural
framework of the DoS attack mitigation process.

Figure 5.1: The Working environment of the OPNET simulation tool

68
To show the mitigation process in OPNET simulation tool we use different network nodes and
network components to represent the baseline, the DoS attack with no mitigation, and the DoS
attack with mitigation scenarios. The common network components we use in our mitigation
process are discussed below:

Client LANs

The general node functions of the client LANs use 10BaseT_LAN object to represent an
Ethernet LAN in a switched topology. The object contains any number of clients as well as one
server. Client traffic can be directed to the internal server in the LAN as well as external servers
via Internet to the cloud. Supported applications in the client LAN include: FTP, Email,
Database, Custom, Rlogin, Video, HTTP, etc. These applications run over TCP or UDP. For
each application, we can specify traffic for group of clients, allowing to quickly characterizing
the entire LAN.

We set the following attributes:

It has a switching with a speed of 500,000pkts/sec set as a default value during configuration and
we set 100 workstations for three different client LAN users to use four services from the cloud.
These clients are categorized into four groups as per the services they want, the first group is
DB_users they use 75 workstations to get database services, the second group is Web_users they
use 75 workstations to get web services, the third group is Mail_users they use 75 workstations
to get mail services, and the fourth group is FTP_users they use 75 workstations to get ftp
services. All workstations we use as a client in this model has an Auto Assigned class C IP
address to differentiate as a legitimate user of the cloud. In addition the LAN server is Auto
Assigned by default to simplify our simulation work. Figure 5.2 shows the LAN configuration
attributes in all the scenarios of the network model based on the services used by legitimate users
of the cloud.

69
 Figure 5.2: The LAN configuration in the model of the proposed architectural framework

Routers

Two routers are used across the simulation process among those where one of the routers acts as
a firewall. These routers have a type of ethernet4_slip8_gtwy node model that represents an IP-
based gateway supporting four Ethernet hub interfaces and eight serial line interfaces. It
determines the IP packets arriving on any interface are routed to the appropriate output interface
based on their destination IP address. It uses the Routing Information Protocol (RIP) or the Open
Shortest Path First (OSPF) protocol to create the routing tables dynamically and automatically
70
and to select routes in an adaptive manner. For our purpose we use RIP, and Auto Assigned class
C IP address during configuration as shown in Figure 5.3.

Figure 5.3: The Router configuration in the model of the proposed architectural framework

The Switch

The node represented by ethernet128_ switch_adv node model for a switch supporting up to 128
ethernet interfaces. The switch implements the Spanning Tree algorithm in order to ensure a loop
free network topology. Switches communicate with each other by sending Bridge Protocol Data
Units (BPDU's). Packets are received and processed by the switch based on the redirection
information and the current configuration of the spanning tree. It supports 128 Ethernet
connections at the specified data rate (10, 100, 1000 Mbps) and Spanning Tree Bridge Protocol
(IEEE 802.1D) as well as Ethernet (IEEE 802.3) protocols. We use the switch to create the CPS
infrastructure by configuring the VPN with VLAN as shown in Figure 5.4.

71
 Figure 5.4: The Switch configuration in the model of the proposed architectural framework

Server

We use four servers to provide different services to users, the general functions of these nodes
are to represent a server node with server applications running over TCP/IP and UDP/IP. This
node supports one underlying Serial IP (SLIP) connection. The operational speed is determined
by the data rate of the connected link. It can support one of the following protocols: RIP, UDP,
IP, TCP, OSPF. In our case we use RIP, and Auto Assigned class C IP address for the
Web_server, Database_server, Mail_server, and FTP_server to provide four services as per the
legitimate users requirement and need.

Every server in the architectural framework is designed based on the following attributes:

Server Configuration Table: This attribute allows for the specification of application servers
running on the node.

Transport Address: This attribute allows for the specification of the address of the node.

IP Forwarding Rate: specifies the rate (in packets/second) at which the node can perform a
routing decision for an arriving packet and transfer it to the appropriate output interface.

IP Gateway Function: specifies whether the local IP node is acting as a gateway.

Workstations should not act as gateways, as they only have one network interface.

72
 RIP Process Mode: specifies whether the RIP process is silent or active. Silent RIP processes
do not send any routing updates but simply receive updates. All RIP processes in a workstation
should be silent RIP processes.

TCP Connection Information: specifies whether diagnostic information about TCP

connections from this node will be displayed at the end of the simulation.

TCP Maximum Segment Size: determines the size of segments sent by TCP. This value
should be set to largest segment size that the underlying network can carry unfragmented.

TCP Receive Buffer Capacity: specifies the size of the buffer used to hold received data
before it is forwarded to the application.

IPCloud

An IP based cloud is used as the required cloud and this cloud acts as the Internet cloud and
connects two or more subnets. So, the ip32_cloud node model as shown in Figure 5.5 it
represents an IP cloud supporting up to 32 serial line interfaces at a selectable data rate through
which IP traffic can be modeled. The IP packets arriving on any cloud interface are routed to the
appropriate output interface based on their destination IP address.

It uses the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) protocol
to create automatically and dynamically the cloud's routing tables and to select routes in an
adaptive manner.

This cloud requires a fixed amount of time to route each packet, as determined by the "Packet
Latency" attribute of the node. Packets are routed on a first-come-first-served basis and may
encounter queuing depending on the transmission rates of the corresponding output interfaces.

The available protocols to support this cloud model are: RIP, UDP, IP, OSPF, BGP, IGRP, and
TCP.

During the design we determine the following attributes:

Packet Latency: specifies the delay (in seconds) after which the incoming IP datagrams get
transfered through the cloud.
73
 Packet Discard Ratio: Determines the number of packets to be dropped out of the total
packets transferred.

Figure 5.5: IP Cloud interface representation in OPNET

Application Config :

Four different applications are created to use in our proposed architectural framework: the
database application, FTP, Mail application and the web application as shown in Figure 5.6. The
required application traffic is created by configuring the applications at the application
configuration and profile configuration level. A heavy database access application is used in this
simulation such that it imposes more database queries over the database server. A heavy

74
browsing access application is used for the web application in this simulation such that it
imposes more web request over the web server. We also use the same configuration for both
Mail and FTP applications to handle more requests from users of the cloud.

Figure 5.6: The Application configuration in the model of the proposed architectural framework

In Figure 5.7, required configurations are done at the application and the profile config level and
the available of the supported cloud services in terms of database, web, Mail, and FTP
applications are studied.

Generally the "Application Config" node is designed based on the following specifications:
1. "ACE Tier Information": Specifies the different tier names used in the network model. This
attribute will be automatically set when the model is created using the "Network->Import

75
Topology->Create from ACE..." option. The tier name and the corresponding ports at which the
tier listens to incoming traffic is cross-referenced by different nodes in the network.
2. "Application Specification": It specifies applications using available application types. We can
specify a name and the corresponding description in the process of creating new applications.
For example, "Web Browsing (Heavy HTTP 1.1)" indicates a web application performing heavy
browsing using HTTP 1.1. The specified application name will be used while creating user
profiles on the "Profile Config" object.
3. "Voice Encoder Schemes": Specifies encoder Parameters for each of the encoder schemes
used for generating voice traffic in the network.

Figure 5.7: The supported services in the model of the proposed architectural framework

Profile Config

The general description of the "Profile Config" node is used to create user profiles in the
specified type of network as shown in Figure 5.8. These user profiles can then be specified on
different nodes in the network to generate application layer traffic and the application defined in
the “Application Config” objects is used to configure profiles. Therefore, we create applications
using the "Application Config" object before using this object and we can specify the traffic
patterns followed by the applications as well as the configured profiles on the “Profile Config".

76
Figure 5.8: The Profile configuration in the model of the proposed architectural framework

77
 Figure 5.9: the Applications of the proposed solution used by users

Figure 5.9 shows how the cloud applications are assigned to the legitimate users of the cloud,
and the available services that support the specific number of users. From each client group 25
of them get database service, 25 of them get web service, 25 of them get mail service, and 25 of
them get FTP service in our simulation model based on their profile configuration.

78
5.3.1 Baseline Scenario of the Proposed Architectural Framework

This section shows a well behaved model of the cloud based network which runs with no attacks
and no active mitigation technology. As shown in Figure 5.10 cloud based network is designed
in OPNET network modeler with different network components to use in the base line scenario.
The detail of these network components and their tasks were discuss previously before this
section.

Figure 5.10: The Baseline scenario model of the proposed architectural framework

79
 Figure 5.11: the Baseline scenario network components

Figure 5.11 shows the network components to see the normal scenario with normal traffic load
and normal communication among different components. In addition, the application, the VPN
and the profile configuration are assigned to create smooth communication between the
legitimate users of the cloud, and the available services supported by the providers. As we
discussed previously every components of this scenario uses RIP, and Auto Assigned class C IP
address as a legitimate component in the network model. The application, the profile and the
VPN nodes help to assign the task for each component in the network model.

80

Simulation Results of the Baseline Scenario

Figure 5.12: the Simulation speed of the baseline scenario

Figure 5.12 shows the simulation speed of the first scenario with two available categories,
current simulation speed and average simulation speed based on events per second. From the
simulation graph, we can see above 200,000 events run in a single second within the range of
900 seconds. These events are packet events from nodes and behavioral events from users and
systems within a limited simulation time. As we see from the simulation speed graph on the
simulation speed tab when the simulation completes, it record average speed and current or
actual speed in events per second to observe the performance of the model during the dynamic
simulation time. Our simulation time set about 15 minutes within this time the total events to be
simulated in the base line scenario is about 2708945 as shown in Figure 5.12.

81
 Figure 5.13: The Simulation message of the baseline scenario

The Figure 5.13 shows the simulation statistics message of the first scenario. It displays the
result of total number of events and average speed of the simulation. This message is generated
by the simulation dynamically after the end of allocated simulation time.

Figure 5.14: The Memory usage of the simulation in the baseline scenario

Figure 5.14 shows the simulation memory usage of the first scenario. It displays the total usage
of memory within the given time range. This time is allocated as a simulation time for the
network model and the memory consumption shows the consumed memory by the current or
actual simulation of the network model.

82
 Figure 5.15: The Traffic Sent and the Request load of the simulation result in the baseline
scenario

Figure 5.15 shows the simulation result of the traffic sent in packets per second and the traffic
load in request per second respectively of the baseline scenario. It displays the total traffic and
requests of the baseline scenario within the given time range. As we see on the source tree the
client traffic sent and the server request load are selected in the top to down direction. On the
graph preview panel the respective graphs are displayed in the top and down respectively. The
displayed statistical values on the graph are available to show the graph on the selected
simulation runs from the source tree of the result window. From the simulation graph we can
observe a smooth relationship between the client and the server, in both cases the output value
range is from 0.0 to 1.4 approximately. This means traffic sent from the client is the same as the
request accepted by the server.

83
 Figure 5.16: The Mail Server simulation result in the baseline scenario

Figure 5.16 shows the simulation result of download response time in second, the traffic sent in
packets per second and the traffic sent in bytes per second seen from top to down on the graph. It
displays the total traffic and download response time of the mail server in baseline scenario
within the given time range. As we see on the source tree the download response time, the traffic
sent in packets per second and the traffic sent in bytes per second of mail users are selected from
top to down direction. On the graph preview panel the respective graphs are displayed from the
top to down in the selection order of statistical values from the source tree. The displayed
statistical values on the graph are available to show the graph on the selected simulation runs
from the source tree of the result window based on the given simulation time.

84
5.3.2 DoS Attack with no Mitigation Scenario

The design of the cloud computing environment makes vulnerable to DoS attack and hence the
problems of this network falls at the two ends with one being the CSP and the other being the
cloud client. So, the misbehavior at one end could easily affect the other end as the intermediate
entities would do almost nothing to protect them from further damage. Different methods apply
to protect the victim but still it has a problem to identify the requests that are being sent from
various units including both legitimate as well as attacker. So, due to these difficulties DoS
attackers make their impact on the cloud.

To show this scenario in the simulation model the initial attack is a single attacker sending TCP
SYN packets from spoofed IP addresses at a rate of 1000 packets per second (pps). But,
simulating IP spoofing is difficult in OPNET since all of the IP addresses will be registered in a
global IP address table for the reference of the routing protocols and any false IP address, which
can’t be found out in this IP address table and will cause a fatal error when we run the
simulation. Due to this problem in our simulation, we use an alternative approach to imitate the
effect which can be achieved by IP spoofing, as shown in Figure 5.17.

Figure 5.17: The IP spoofing model in DoS attack scenario

85
When one of the attackers wants to attack the target service, it will send a SYN packet to the
target service, whose source IP address is set with IP address of another host, instead of its own
IP address. When the target service receives the SYN packet, it will respond it with a SYNACK
packet again and again. Since the source IP address of SYN packet is falsely set the half-opening
connection in the target service will keep waiting for the ACK message until timeout expires.
Then in this way the target service will suffer from the same problem as it does from the IP
spoofing approach.
In general OPNET provides an option to create scenarios and in this simulation three scenarios
are created. The main objective of this scenario is to impose DoS attack conditions across the
cloud infrastructure. To simplify our works we duplicate the baseline scenario using duplicate
scenario from the scenario menu of the tool. This helps us to use other network components
without changing, as shown in Figure 5.18.

Figure 5.18: The Duplicate baseline scenario

86
After we duplicate the baseline scenario, we incorporate two groups of attackers from different
directions by applying IP Ping traffic to create huge traffic on the services provided by the CSP,
as shown in Figure 5.19. The IP Ping traffic creates one-way delay that each packet experiences
while traversing the network and this traffic load hinders the legitimate users activities in the
cloud. To apply this in this scenario first, we configure IP ping traffic from the DoS attack nodes
to the four cloud services across the WAN. So, the normal traffic of the legitimate users is
dominated by this traffic due to the bogus traffic generating by the attacker.
See Annex B for the DoS attack source code using proto_ C for the DoS attack scenario and
other configurations in the process model.

Figure 5.19: The DoS attack scenario model in our simulation

87
To create the IP Ping huge traffic from the attacker to the cloud services, we must configuration
it before start attacking on the services provided by the CSP. As shown in Figure 5.20 the IP ping
traffic configuration between the attacker and the FTP_Server with an exponential traffic
repetition time is displayed. Similar configuration also applies to the database, Web, and mail
servers to create IP Ping traffic from the attacker node to the cloud services.

Figure 5.20: The IP Ping traffic configuration

Figure 5.21 shows the simulation speed of the DoS attack scenario and it is slower than the
baseline scenario due to the attack traffic load in the target service. If we compare the two
available categories, current simulation speed and average simulation speed based on events per
second from Figure 5.12, we can see the differences between 200,000 and 150000 events run in a
single second within the same range of time, 900 seconds. As we see from the simulation speed
graph on the simulation speed tab when the simulation completes, it record average speed and
current speed in events per second to observe the simulation performance of the model during
the given time. Our simulation time sets about 15 minutes within this time the total events to be
simulated are 5484066, which are too much as compared to the base line scenario as shown in
Figure 5.12. So, the impact of large number of events per simulation leads to reduce the
simulation speed of a given scenario.

88

Simulation Results of the DoS Attack Scenario

Figure 5.21: The Simulation speed of DoS attack scenario

Figure 5.22 shows the simulation statistics message of DoS attack scenario. It displays the result
of total number of events and average speed of the simulation speed of the DoS attack scenario,
which is larger than the baseline scenario in Figure 5.13. The average speed of this scenario is
171484 events per second, which is less than that of the base line scenario.

Figure 5.22: The Simulation message of DoS attack scenario

89
Figure 5.23 shows the simulation memory usage of the DoS attack scenario, it needs much
memory as compared to the baseline scenario due to the attack traffic load. It displays the total
usage of memory within the same given time range like the baseline scenario. To compare this
simulation memory usage with that of the base line scenario the maximum limit as shown in
Figure 15.14 is 18MB of memory usage but here the maximum limit is 30 MB of memory usage.

Figure 5.23: the Memory usage of the simulation in DoS attack scenario

Figure 5.24 shows the comparison of database query load within the given time interval based on
requests per second between the first two scenarios. As we see on the source tree the traffic load
request on database server in request per second of the attacker and the client are selected from
top to down direction. On the graph preview panel the respective graphs are displayed from the
top to down in the selection order of statistical values from the source tree. The displayed
statistical values on the graph are available to show the graph on the selected simulation runs
from the source tree of the result window based on the given simulation time.

90

Comparison on the Simulation Results of the DoS Attack and Baseline Scenarios

Figure 5.24: the Traffic load comparison on DoS attack scenario

As it is observed from the graph the load request on DB server is not very high when legitimate
users communicate under baseline scenario. On the other hand, when DoS attack strikes under
attack scenario, we observe a shoot in DB server load with increased connection requests. It is
found from the obtained relationship that increased traffic load makes greater impact on server
load. The reason behind the fact is that the attacker is sending more traffic to initiate connection
requests for which the server responds and hence the load is increased. The ultimate target of the
attacker in this perspective is to degrade the server’s connection capacity for legitimate requests.
From the comparison the traffic load request of the attack at pick time is around 50000 requests
per second but the traffic load request of the client node is around 25000 requests per second.

91
This clearly shows double traffic load are created in the DoS attack scenario than in the base line
scenario.

Figure 5.25: Traffic sent comparison on DoS attack scenario

Figure 5.25 shows the comparison of database traffic sent in packets per second within the given
time interval for the two scenarios. As we see on the source tree the traffic sent to the database
server from the attacker and the client are selected from top to down direction. On the graph
preview panel the respective graphs are displayed from the top to down in the selection order of
statistical values from the source tree. The displayed statistical values on the graph are available
to show the graph on the selected simulation runs from the source tree of the result window
based on the given simulation time.

As it is seen on the graph preview the traffic of the baseline scenario has minimum packets per
second traffic as compared to the attack scenario. The impact of the high traffic sent from the
attacker leads to high traffic load on the target services. The comparison shows around 25000

92
packets per second traffic sent from the attacker and 12500 packets per second from the client at
peak time. So, around double packets per second transfer in the DoS attack scenario than base
line scenario is seen.

Figure 5.26: Traffic received comparison

Figure 5.26 shows the comparison of database traffic received in bytes per second within the
given time interval for the two scenarios. As we see on the source tree the traffic received by the
web server from the attacker and the client are selected from top to down direction. On the graph
preview panel the respective graphs are displayed from the top to down in the selection order of
statistical values from the source tree.

The traffic of the baseline scenario has minimum bytes per second traffic as compared to the
attack scenario. The impact of the high traffic sent from the attacker leads to high traffic load on
the target services. The comparison shows around 625000 bytes per second traffic received from
the attacker and 37500 bytes per second from the client at peak time. So, the bytes per second
transfer from the DoS attack scenario are greater than the base line scenario.

93
 Figure 5.27: Task processing time of the DB server in DoS attack scenario

In Figure 5.27, task processing time of DB server is observed. We find that task processing time
greatly increases under attack scenario as compared to baseline scenario. It depicts that the server
is made exhausted by sending huge amount of attack traffic for which it has to perform requested
tasks. As a result, average processing time (in seconds) per task is increased, degrading services
for legitimate requests.

Approximately a double fold increase is observed in average task processing time of the server
when it is under DoS attack as compared to the base line scenario. Moreover, the increased
magnitude of attack induces more delay factor in average processing time per task of the server.

94
 Figure 5.28: TCP Active Connection Counts

In Figure 5.28, we observe that active connection counts under attack scenario greatly increase as
compared to the baseline scenario. It shows how much the server is getting exhausted in
connection management processing of attack based traffic so that legitimate users will find a
denial in connection establishment with the server. The peak value in our analysis has 325 active
connection counts under DoS attack as compared to average value of around 125 counts under
baseline scenario. Moreover, increasing the attack size exhibits more connection count load on
the server.

95
5.2.3 DoS Attack with Mitigation Scenario

In this scenario we consider flows of traffic that are the same as the first and the second scenarios
by duplicating the DoS attack scenario as we did for DoS attack scenario but we add some
packet treatment differentiation. To implement the mitigation process in addition to the network
components of the DoS attack scenario we add load balancer to deploy the task of DMU in our
proposed architectural framework, Packet analyzer node to deploy the task of BA and PA in our
proposed architectural framework, and Packet Manager to deploy the task of Timestamp Unit in
our proposed architectural framework.

Using the load balancer, the aggregated flows from legitimate and suspicious sources are
loadbalanced and a First IN, First Out (FIFO) queuing is configured in which every legitimate
flow is processed into a low latency queue. Then we apply weights to indicate the allocated
bandwidth for the queues of the routers. Moreover the load balancer models a device which
intercepts Internet application traffic and sends it to a list of preconfigured applications based on
the given criteria. So, this protects our proposed architectural framework from high flood attack.

Other network components in our mitigation architectural framework like Packet Analyzer and
Packet Manager use to control the traffic profile that we are simply going to apply it to our
proposed network model. Sandhyarani and Hanrasekhar in [77] in OPNET simulation a network
analyzer also called a "packet analyzer," "traffic analyzer" and "protocol analyzer," with the
following functionalities: i) provide detailed statistics for current and recent activity on the
network; ii) detect unusual levels of network traffic; iii) detect unusual packet characteristics; iv)
identify packet sources or destinations; v) configure alarms for defined threats; and vi) monitor
bandwidth utilization.

We use two Packet Analyzers in different location to improve the mitigation process of our
proposed architectural framework in the simulation. The first Packet Analyzer node provide
services on DoS attack detection and mitigation by applying the bandwidth and packet analyzing
on the traffic which comes from different nodes. The second Packet Analyzer node provides
statistics for current and recent activity on the network in the mitigation process.

96
The other network component that is between the load balancer and CSP_router is a Packet
Manager which discards packets going through it, if it doesn’t meet the timestamp value. The
value of the timestamp of packets to be discarded is registered at the start tome of the simulation.
We have set the packet discarder to drop in a 0.5 sec period, assuming that a handover, on an
average, lasts for 0.5 sec. The programming details of our DoS attack mitigation scenario model
using proto C language in OPNET simulation is annexed in Annex C. In Figure 5.29, the DoS
attack mitigation network model displays the node components of this scenario.

Figure 5.29: DoS attack mitigation network model

97

Comparison on the Simulation Results of the DoS Attack and Mitigation Scenarios

Figure 5.30: the Traffic load comparison on the mitigation scenario

Figure 5.30 shows the comparison of database query load within the given time interval based on
requests per second of the DoS attack and the mitigation scenarios. In DoS attack scenario, the
load traffic of the attack on DB server is very small as compare to legitimate users, it is below
0.4. It is found from the obtained relationship that the mitigation process decreases the traffic
load of the DB server to provide acceptable service to legitimate users. In Figure 5.30 it is
observed that load on DB server is very high when legitimate users communicate under
mitigation scenario rather than DoS attack scenario.

98
 Figure 5.31: Traffic sent comparison on mitigation scenario

Figure 5.31 shows the comparison of DB traffic sent in packets per second within the given time
interval for the DoS attack and its mitigation scenarios. In Figure 5.31 it is seen that the traffic of
the attack scenario has a minimum packets per second traffic as compared to the mitigation
scenario. The reason behind this minimum traffic is the effect of our mitigation on the DoS
attack which provides availability of the target services. The comparison shows the service
provided to the legitimate users is around 85% of packets per second in the mitigation scenario.

99
 Figure 5.32: Task processing time of the DB server in mitigation scenario

In Figure 5.32, task processing time of DB server is observed. We find that task processing time
greatly minimized under attack as compared to the mitigation scenario. It depicts that the server
provides services exhaustively to the legitimate user by performing the requested tasks from
them. As a result, average processing time (in seconds) per task is increased, to enhance the
service provision for legitimate requests. The task processing time of the DB server for attack is
minimal and it doesn’t affect the normal activity of the server to provide the available services
for the legitimate users.

100

Comparison of the Baseline, DoS Attack and Mitigation Scenarios

1800
Network Load in Pkt/Sec (1000)

1600
1400
1200
1000
800 Baseline
600 Mitigation
400 Attack
200
0
1 2 3 4 5 6 7 8 9

SimulationTime in Seconds(100)

Figure 5.33: Aggregate Network Traffic load (packets/sec)

Figure 5.33 shows the aggregate network traffic to compare the baseline, the DoS attack and the
mitigation scenarios. The traffic load within the given time interval of 900 simulation seconds
based on packets per second from the available nodes in the scenarios. As we see from the result
in Figure 5.33, when the time goes the traffic load of the DoS attack scenario becomes higher
and higher. But when the time goes the traffic load from the base line and the mitigation
scenarios becomes constant as it is observed in the graph. This shows the mitigation scenario
has a capacity of DoS attack mitigation to provide acceptable services from the service provider
to legitimate users. To compare the DoS attack mitigation scenario and the base line scenario
with an area function from the graph, let A1 is area of base line scenario and A2 of DoS attack
mitigation scenario. Where B is base and H is height to calculate the approximate area of the
region.

A1=1/2*B*H  ½*8*750=3000

A2=1/2*B*H ½*8*800=3200

101
From the comparison of simple area formula the cutoff value between the two scenarios for the
given simulation time is 200. So, the performance comparison of the mitigation scenario in this
case is around 94% as compare to the base line scenario.

2500

2000
Number of Packets

1500

1000 Baseline
Mitigation

500 Attack

0
1 2 3 4 5 6 7 8 9

Time in Seconds(100)

Figure 5.34 Traffic Sent to the DB server (packets/sec)

In Figure 5.34 the attacker scenario has maximum traffic sent rate i.e. reached to 2400 packets
per seconds because attacker generating bogus traffic which increases the traffic sent rate.
Minimum traffic is sent by base line scenario as there is no interruption of attacker and the
mitigation scenario sends more traffic than base line because it sends the packet in filtered and in
optimized form. This shows when we use longer time the mitigation process becomes better and
better by adjusting itself to mitigate the attack in proper manner.

102
 Figure
igure 5.35: Response time (seconds)

In Figure 5.35 the attacker scenario has taken a maximum response time because attacker
generating bogus traffic which increases the traffic sent rate. Up to 3rd minute the attacker traffic
goes smooth to adopt the environment then the attack traffic rate increase relatively. The
variability of the attack traffic is created due to the responses of the legitimate users requests by
the system but when the time goes the request from the attacker dominate over the legitimate
users. The attacker traffic dominate
dominates the legitimate users due to the bogus traffic impact on the
services,, so it dominates when the time increases
increases. We take simulation time of 15 minutes to
observe the response in seconds. Minimum response time in second is observed in the base line
scenario as there is no interruption of attacker and the mitigation scenario has more response
time than base line because it doesn’t assure a 100% prevention of DoS attack . But, when we
use longer time in the mitigation process the mitigation scenario response time becomes better
and better because of self adjustment to mitigate in accurate manner
manner.

103
 0.00008

Delay in Seconds (100)

0.00007
0.00006
0.00005
0.00004
Baseline
0.00003
Mitigation
0.00002
Attack
0.00001
0
1 2 3 4 5 6 7 8 9

Simulation Time in Seconds (100)

Figure 5.36: Processing Delay in Seconds

In Figure 5.36 the attacker scenario creates a maximum delay over the cloud because attacker
generating bogus traffic which increases the traffic magnitude. The smooth processing delay is
observed in the base line scenario as there is no interruption of attacker and the mitigation
scenario has more processing delay than base line because of some traffic impact from DoS
attack on the cloud. The delay in the mitigation scenario shows a significant difference with the
baseline scenario within some range of simulation time due to the process to adjust itself in the
mitigation environment. But, when we use longer time in the mitigation process the mitigation
scenario processing delay becomes better and better because of self adjustment to mitigate in
accurate manner to provide acceptable service for legitimate users.

5.4 Summary
In this Chapter, we described the implementation details, simulation experiment, and evaluation
result of our DoS attack mitigation architectural framework. We use three scenarios called
baseline scenario, DoS attack scenario and DoS attack mitigation scenario. We implement the
mitigation process for our proposed architectural framework using OPNET simulation tool. The
given scenarios are implemented in different network models but to simplify our work we used
scenario duplication on the second and third scenarios. The simulation experiment result shows
our architectural framework provides a guaranty of an acceptable service for legitimate users via
the mitigation process.

104
 Chapter Six: Conclusion and Future Works

6.1 Conclusion

DoS attacks are quiet advanced methods of attacking a network system to make it unusable to
legitimate network users. These attacks are an annoyance at a minimum and if they are against a
critical system, they can be severely damaging. Loss of network resources costs money, delays
work and cuts off communication between network users. The negative effects of a DoS attack
make it important that solutions and security measures be developed to prevent these types of
attacks.

In this thesis, we presents the DoS attack on the IaaS of the cloud computing environment as a
problem and we propose DoS attack mitigation architecture on the IaaS of the cloud. In addition,
our proposed architectural framework effectiveness was evaluated using an OPNET simulation
tool for legitimate users and for attacker based on their behaviors observed.

We have evaluated and analyzed our DoS attack mitigation on the cloud infrastructure using
OPNET simulation tools based on three scenarios. The first scenario is the baseline scenario to
show the normal activities and behaviors of the legitimate users of the cloud. The second
scenario is a DoS attack scenario using SYN flood attack to create unwanted traffic using
spoofed packets on the cloud infrastructure. The third scenario is the DoS attack mitigation
scenario to show how the mitigation process of our proposed architectural framework is
implemented. Our results indicate that the proposed approach can offer significant mitigation on
the cloud infrastructure that is being flooded with malicious attacker traffic.

Our mitigation architectural framework follows a coordinated mitigation among its four
components. First of all the packets which come to the cloud are aggregately controlled by the
DMU to prevent our mitigation architectural framework from flooding attack. In addition, the
DMU directs the packets to appropriate components of our mitigation architectural framework
based on the predefined criteria. All the other components the Bandwidth Analyzer, the Packet
Analyzer, and the Time Stamp Units work in coordination in the mitigation process. So, our
mitigation mechanism can mitigate the attacker’s malicious activities and provide better resource
availability to legitimate users of the cloud.
105
Our proposed architectural framework can be easily implemented in a real cloud computing
environment. So, we can see how the real attacker or its agents impact clearly on the cloud
services. If so an effective solution should be found to solve DoS attack problems in the cloud
computing infrastructure.

Our contribution in this thesis work is two-fold. First, we have proposed a architectural
framework to identify the occurrence of DoS attack and it provide decision without third party
involvement using a predefined set of rules based on the SLA of the cloud computing
environment. Second, we have proposed a DoS attack mitigation architectural framework in a
coordinated manner that mitigates the DoS attacks without affecting the legitimate users of the
cloud computing environment. Finally, we test our proposed DoS attack mitigation architectural
framework using OPNET and the result provides a DoS attack mitigation to assure a reasonable
service provision for the cloud legitimate user in the cloud computing environment.

6.2 Future Works

There are still several issues regarding the DoS attacks on cloud computing environment that
warrant further research to check the credential of the sender for legitimate users packets and
mitigate an unintentional internal attack from legitimate users. Secondly we need a systematic
procedure of setting parameters according to the dynamic cloud environment for our proposed
architectural framework so that it show effective results against real spoofed DoS traffics in the
real cloud environment. Moreover identifying different parameters for cost based DoS attack
mitigation to minimize the cost of the client incurred during the attack needs a lot to do. Last but
not least, the research should also take into consideration the fact that the cloud is still being
developed and continuously changing. Thus the risks identified within this study may need to be
updated accordingly.

106
References
[1] Tamer Özsu M. and Patrick V., Principles of Distributed Database Systems, 3rd ed, Springer
Science and Business Media, LLC, USA , November 2010.

[2] Lee B., “Draft Cloud Computing Synopsis and Recommendations”, United States National
Institute of Standards and Technologies (NIST), Special Publication 800-146, USA, May
2011.

[3] Siani P., “Privacy, Security and Trust in Cloud Computing”, Springer, USA, June 2012.

[4] Priya M. and Geeta S., “Privacy Issues and Challenges in Cloud computing”, International
Journal of Advanced Engineering Sciences and Technologies (IJAEST), Vol. 5, No. 1, pp.
001 – 006, 2011.

[5] Adam H., “Cloud Computing Takes Off”, Morgan Stanley Research, Global Technology and
Telecommunications Team, May 23, 2011.

[6] Eric B. and Randee A., “Reliability and Availability of Cloud Computing”, 1st ed., IEEE,
John Wiley & Sons, 2012.

[7] Mouna J., “Towards Quantitative Measures of Information Security: A Cloud Computing
Case Study”, International Journal of Cyber-Security and Digital Forensics (IJCSDF) 1(3):
248-262, The Society of Digital Information and Wireless Communications, Nov. 2012.

[8] IBM Global Technology Services Technical White Paper, “Security and High Availability in
Cloud Computing Environments”, June 2011.

[9] Aboosaleh M., Saeed K., Mehdi A., Baharak S., and Mohammad G., “Availability Challenge
of Cloud Cystem under DDOS Attack”, Indian Journal of Science and Technology, Vol. 5,
No. 6, June 2012.

[10] Floriana G., “Implementation of Cloud Computing into VoIP”, Database Systems Journal,
Vol. III, No. 2, 2012.

[11] Ponemon Institute Research Report, “Second Annual Cost of Cyber Crime Study”,
Benchmark Study of U.S. Companies, Ponemon Institute, August 2011.

107
[12] http://www.bankinfosecurity.com/what-to-do-about-ddos-attacks-a-5271/p-3, All the latest
UK technology news, reviews and analysis and www.radware.com, according to the
Ponemon Institute and Radware on 14 November 2012.

[13] Harkeerat S. and Sajjan S., ”Securing Cloud Infrastructure Against Co-Resident DoS
Attacks Using Game Theoretic Defense Mechanisms”, ICACCI '12, August 03 - 05 2012,
Chennai, India, 2012.

[14] Geethu T. and Janardhanan P., ”Intrusion Tolerance: Enhancement of Safety in Cloud
Computing”, International Journal of Advanced Research in Computer and Communication
Engineering Vol. 1, Issue 4, June 2012.

[15] Irfan G. and Hussain M., “Distributed Cloud Intrusion Detection Model”, International
Journal of Advanced Science and Technology, Vol. 34, September, 2011.

[16] Priya M. and Geeta S., “Privacy Issues and Challenges in Cloud computing”, (IJAEST)
International Journal of Advanced Engineering Sciences and Technologies, No. 5, Issue No.
1, pp. 001 – 006, 2011.

[17] Ruiping L. and Kin C., “Mitigating DDoS Attacks with Transparent and Intelligent Fast-
Flux Swarm Network,” IEEE Network, Vol. 25, No. 4, pp. 28-33, July-August, 2011.

[18] Vieira K., Schulter A., and Westphall C., “Intrusion Detection Techniques for Grid and
Cloud Computing Environment,” IT Professional, IEEE Computer Society, Vol. 12, Issue 4,
pp. 38-43, 2010.

[19] Mohamed H., Fahd A., and Khaled S., “EDoS-Shield- A Two- Steps Mitigation Technique
against EDoS Attacks in Cloud Computing”, 4th IEEE International Conference on Utility
and Cloud Computing, 2011.

[20] Arbor Special Report, Worldwide Infrastructure Security Report, Vol. VII, 2011.

[21] Keith J. and Burkhard N., “The Future of Cloud Computing Opportunities for European
Cloud Computing Beyond 2010”, 2010.

[22] Neil R., Lorenzo V., Jonathan C., Tony S., Hans G., Sadie C., and Paul H., “The Cloud:
Understanding the Security, Privacy and Trust Challenges”, 30 November 2010.

108
[23] Chandni M. and Viral H., “Survey on Taxonomy of DDoS Attacks With Impact and
Mitigation Techniques”, International Journal of Engineering Research & Technology
(IJERT) Vol. 1, Issue 9, November 2012.

[24] Securosis L., “Defending Against Denial of Service Attacks”, Version 1.3, Released:
November 7, 2012.

[25] The iDefense Intelligence Team, “Distributed Denial of Service (DDoS) Attacks: Latest
Motivations and Methods”, July 11, 2008.

[26] International Technical Support Organization, “IBM Data Center Networking: Planning for
Virtualization and Cloud Computing”, pp 94, May 2011.

[27] Arun R. and Selvakumar S., “Identifying the Type of High Rate Flooding Attacks using a
Mixture of Expert Systems”, Computer Network and Information Security, February 2012.

[28] Ketki A., Krishan K., and Monika S., “Impact Analysis of Recent DDoS Attacks”,
International Journal on Computer Science and Engineering (IJCSE), Vol. 3, No. 2,
February 2011.

[29] Trusted Information Sharing Network, “Managing Denial of Service (DoS) Attacks”,
Summary Report for CIOs and CSOs, for Critical Infrastructure Protection, December 2009.

[30] Yuichi O., “Detection and Defense Method against Distributed SYN Flood Attacks”,
February 15, 2005.

[31] Ajith A., “Hacking Types Denial of Service (DoS) Attack, Ethical Hacking, Social Media”,
Tech, March 17, 2012.

[32] Danish J., and Hassan Z., “Security Issues in Cloud Computing and Countermeasures”,
International Journal of Engineering Science and Technology (IJEST), Vol. 3, No. 4, April
2011.

[33] Lucian P., Minlan Y., Steven Y., Sylvia R., and Ion S., “CloudPolice: Taking Access
Control out of the Network”, October 20–21, 2010.

[34] Yury G., “{AB}USE Their Clouds. Cloud Computing, Positive Technologies”, 2012.

109
[35] Mehmud A., “Internet Denial of Service Attacks and Defense Mechanisms”, University of
Pittsburgh Technical Report, No. TR-11-178, March 2011.

[36] Yu C., and Kai H., “TCP Flow Analysis for Defense against Shrew DDoS Attacks”,
University of Southern California, Los Angeles, CA 90089, USA, June 24-28, 2007.

[37] Arbor Network, “Arbor Special Report: DDoS Attack Tools and Best-Practices for
Defense”, 2012.

[38] Fortinet, Inc., “FortiDDoS, DDoS Attack Mitigation Guide”, May 1, 2012.

[39] Cli_ Nyangasi M., “A Study On TCPSYN Attacks and Their Effects on a Network
Infrastructure”, June 23, 2010.

[40] Handley M., Rescorla E., and IAB, “Internet Denial-of-Service Considerations”, 2006.

[41] Sullivan D., “XML Denial of Service Attacks and Defenses”, MSDN Magazine, 2009.

[42] Renuka D., and Yogesh P., “Detection of Application Layer DDOS Attacks using
Information Theory Based Metricss”, Computer Science & Information Technology (CS &
IT) 05, College of Engg. Guindy, Anna University, Chennai. India, pp. 217–223, 2012.

[43] Grobauer, Walloschek and Stöcker, “Understanding Cloud Computing Vulnerabilities”,

Aug 15, 2011.

[44] Imperva White Paper, “Denial of Service Attacks: A Comprehensive Guide to Trends,
Techniques, and Technologies”, ADC Monthly Web Attacks Analysis, Hacker Intelligence
Initiative, Monthly Trend Report No 12, September 2012.

[45] Paul S., “Identifying Cloud Computing Security Risks”, Wooley Network Analyst, Tyco
Electronics, February 2011.

[46] Marshall D., Beaver S., and McCarty J., “VMware ESX: Essentials in the Virtual Data
Center”, CRC press, 2009.

[47] "Microsoft Security Advisory (975497): Vulnerabilities in SMB Could Allow Remote Code
Execution". Microsoft.com. Retrieved 2011-12-02.

110
[48] Charalampos T., ”Distributed Denial of Service Attacks”, The Internet Patrikakis, Michalis
Masikos, and Olga Zouraraki Protocol Journal, National Technical University of Athens,
Vol. 7, No. 4, December 2009.

[49] Daljeet K., and Monika S., “Study of Recent DDoS Attacks and Defense Evaluation
Approaches,” International Journal of Emerging Technology and Advanced Engineering,
Vol. 3, Issue 1, January 2013.

[50] Or K., “Technical Brief Protecting Against Application DDoS Attacks with BIG-IP ASM: A
Three-Step Solution”, December 2010.

[51] Aleksandar K., and Edward W., “Low-Rate TCP-Targeted Denial of Service Attacks”,
Karlsruhe, Germany, August 25–29, 2003.

[52] Subramani R., and Sridhar R., “Denial of Service Attacks and Mitigation Techniques: Real
Time Implementation with Detailed Analysis”, The SANS Institute 2011.

[53] Arbor Networks, “Worldwide Infrastructure Security Report 2012”, Vol. VIII, 2012.

[54] Michael G., “A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques
in a Service Provider Environment”, SANS Institute, August 21, 2003.

[55] Chester W., “Massive DDoS attack against Anti-spam Provider Impacts Millions of Internet
Users”, March 28, 2013.

[56] NSFocus, “DDoS Attack and Its Defense”, Neustar Insights: DDoS Survey Q1 2012, When
Businesses Go Dark. Neustar, 2012.

[57] Ashley C., and Xinyi H., “Protecting Cloud Web Services from HX-DoS attacks using
Decision Theory”, First IEEE International Conference on Communications in China:
Advanced Internet and Cloud (AIC), 2012.

[58] Ye X., “Countering DDoS and XDoS Attacks against Web Services,” in IEEE/IFIP
International Conference on Embedded and Ubiquitous Computing. Los Alamitos, CA,
USA: IEEE Computer Society, pp. 346–352, 2008.

[59] Frank K., Jörn M., Stefan S., and Michael W., “Protecting Web Servers from Distributed
Denial of Service Attacks”, WWW10, Hong Kong, May 1-5, 2001.

111
[60] Gulshan S., Kavita S., and Swarnlata R., “The Detection & Defense of DoS & DDoS
Attack: A Technical Overview”, Proceeding of ICC, pp. 27-28, December 2010.

[61] Imperva White Paper, “Four Steps to Defeat a DDoS Attack, Imperva”, 2012.

[62] Botnet DDoS Techniques & Tools of Mitigation, Incapsula,

http://www.incapsula.com/ddos/ddos-attacks/botnet-ddos, Access date: 1/5/2013 5:32 PM.

[63] Paganinip. T, “DDoS attacks so simple so dangerous”, August 29th, 2012.

[64] Azab A., Ning P., Wang Z., Jiang X., Zhang X., and Skalsky N., “HyperSentry: Enabling
Stealthy In-context Measurement of Hypervisor Integrity”, Proceedings of the 17th ACM
Conference on Computer and Communications Security (CCS 2010), Chicago, Il, October
2010.

[65] Lonea A., Popescu D., and Tianfield H., “Detecting DDoS Attacks in Cloud Computing
Environment, International Journal of Computing and Communication, pp. 70-78, February,
2013.

[66] Mohd N., Abdulaziz A., Shahrulniza M., and Amir S., “New Framework to Detect and
Prevent Denial of Service Attack in CloudComputing Environment”, International Journal
of Computer Science and Security (IJCSS), Vol. 6, Issue 4, 2011.

[67] Sanjay R., ”Secure Cloud Computing Based on Mutual Intrusion Detection System”,
International Journal of Computer Application, Department of MCA, Adhiyamaan College
of Engineering (Autonomous), Hosur, India, Vol. 1, Issue 2, February 12, 2012.

[68] Biswajit Panja, Bharat Bhargava, Sourav Pati, Dayton Paul, Leszek T. Lilien and Priyanka
Meharia, “Monitoring and Managing Cloud Computing Security using Denial of Service
Bandwidth Allowance”, 2011.

[69] Joseph L., Philippe M., Syed N., Benny R., and Massimo V., “Scalable Cloud Defenses for
Detection, Analysis and Mitigation of DDoS Attacks Towards the Future Internet”, IOS
Press, 2010.

[70] Syed Navaz A., Sangeetha V., and Prabhadevi C., “Entropy based Anomaly Detection
System to Prevent DDoS Attacks in Cloud”, International Journal of Computer Applications
(0975 – 8887) Vol. 62, No. 15, January 2013.

112
[71] Claudio M., Roberto B., and Roberto C., “Integrating a Network IDS into an Open Source
Cloud Computing Environment”, Sixth International Conference on Information Assurance
and Security (IAS), 2010.

[72] Anukool L., Mark C., and Christophe D., ”Mining Anomalies Using Traffic Feature
Distributions”, ACM, 2005.

[73] Gulshan S., Kavita S., and Swarnlata R., “The Detection and Defense of DoS and DDoS
Attack: A Technical Overview”, Proceeding of ICC, pp. 27-28, December 2010.

[74] Geethu T., and Janardhanan P., “Intrusion Tolerance: Enhancement of Safety in Cloud
Computing”, International Journal of Advanced Research in Computer and Communication
Engineering, Vol. 1, Issue 4, June 2012.

[75] Palvinder S., and Dinesh K., “A Reactive Defense Mechanism based on an Analytical
Approach to Mitigate DDoS Attacks and Improve Network Performance”, International
Journal of Computer Applications, Vol. 12, No. 12, January 2011.

[76] Sowmya R., Sundeep Kumar K., and Jitendranath M., “An Empirical Framework to Detect
Security Attacks on the Cloud Data Storage System”, International Journal of Computer
Science Issues, Vol. 9, Issue 4, July 2012.

[77] Sandhyarani S., and Hanrasekhar G., “Network Delay: Network Analyzer and OPNET
Simulation Tool”, International Journal of Computer Science and Information Technologies,
Vol. 2 (6), 2011.

[78] Metasebia K., and Mulugata L., “A Synchronized Distributed Denial of Service Prevention
System”, MEDES’12, Addis Ababa, November 21-24, 2012.

113
Annex A: Process Model and Source Code for the IP Cloud Model

Figure A.1 Possible OPNET Representation of TCP/IP Protocol Stack

Figure A.2: DoS Attack Mitigation State Transition Diagram in the Process Editor
Type Name
int prop_key
int prop_key_update_counter
int Prop_last_key_updated
Objid self_id
Evhandle next_update_evh
OmsT_Dist_handle update_dist_ptr
int source_id
int is_source_mode
int has_one_update
List* active_update_lst
Stathandle stat_update_success
Stathandle stat_update_success_limited_los
int last_key_update_num_delivered
double stop_time
Stathandle Stat_delay
Figure A.3: State variables of source process

114
 Major Simulation Kernel Procedure Packages
Package Applications
Anim Support for custom animation development
Dist Probability distribution and random number generation
Ev Event list and event property query; event cancellation
Ici Formal interfaces between processes; association of information with interrupts
Id Identification of objects
Ima In-simulation query and modification of object attributes
Intrpt Query of interrupt properties; control of interrupt handling
Pk Creation, destruction, modification, analysis, and transmission of packets
Prg Programming support: linked lists, memory, string manipulation, debugging
Pro Creation, invocation of processes; process group shared memory
Q Queueing statistics; high-level queueing operations
Rad Dynamically changing a radio transmitter channel’s receiver group (Radio version only)
Rte Basic routing support for static routing implementations
Sar Segmentation and reassembly of packets
Sim Simulation control: customized messaging, simulation execution control
Stat Custom statistic generation; intermodule signalling via statistic wires
Strm Communication between modules via packet streams, packet delivery
Subq Low-level queueing operations: enqueueing, dequeueing, statistics, etc.
Tbl Accessing of tabular data: antenna patterns, modulations
Tim Importing traffic into an existing OPNET network model
Td Setting and getting of transmission data for custom link models
Topo Query of model topology (e.g., for automatic discovery and configuration)

Figure A.4: Kernel Procedure Packages of source process

115
1.User-Defined Fields

Index Name Type Contents Size

0 src_addr integer 5 16
1 dst_addr integer 9 16
2 timer_a double 0.84 12
3 timer_b double 1.00 8
4 ack integer 0 1

2. Predef. Fields

Name Contents
creat_mod 19
creat_time 4.005
owner 19
format transp_x
id 116

3. Packet Field Types

Type Use
integer Whole numbers: flags, counters, addresses, etc.
double Floating point numbers: timer values, statistics, etc.
packet Encapsulation of higher-layer protocol data
structure Transport of complex user-defined data types
information Modeling of field size when content is irrelevant

Figure A.5: Three Main Storage Areas of Packet Contents

Figure A.6: Our Packet Contents in Packet Format Editor

116
Source Code to create legitimate users packets using Proto-C language in OPNET

/*

* Define custom structure for legitimate users packets using Proto-C

*/

typedef struct

int int_value;

double double_value;

char string [1024];

} user_struct;

/*

* Declare temporary variables

*/

Packet *fmt_pktptr;

Packet *payload_pktptr;

user_struct *s_structptr;

/*

* Create packets

*/

// Create a formatted packet and set tota size of this packet to 1024

fmt_pktptr = op_pk_create_fmt ( "user_packet" );

op_pk_total_size_set (fmt_pktptr , 1024);

// Set integer and double value to corresponding fields

op_pk_nfd_set (fmt_pktptr , "ptr_field_int", 120);

op_pk_cntrl_field_set (fmt_pktptr , "ptr_field_double", 100);

117
op_pk_tos_set (fmt_pktptr , "ptr_field_int", 100);

op_pk_user_def_type_set (fmt_pktptr , "ptr_field_int", 120);

op_pk_flg_set (fmt_pktptr , "ptr_field_int", 50);

op_pk_ack_set (fmt_pktptr , "ptr_field_int", 150);

op_pk_tmstmp_set (fmt_pktptr , "ptr_field_int", 180);

op_pk_infn_set (fmt_pktptr , "ptr_field_char", 255);

// Dynamically allocate memory for user_struct and assign structure pointer to a field

s_structptr =(user_struct *) op_prg_mem_alloc (sizeof (user_struct ));

op_pk_nfd_set (fmt_pktptr , "user_field_struct",&s_structptr , op_prg_mem_copy_create ,

op_prg_mem_free , sizeof(user_struct ));

// Set the formatted packet pointer to corresponding field of the formatted packet

op_pk_nfd_set (fmt_pktptr , "user_field_packet",payload_pktptr );

op_pk_cntrl_fld_set (fmt_pktptr , "ptr_field_double", control_field_pktptr);

op_pk_tos_set (fmt_pktptr , "ptr_field_int", tos_pktptr);

op_pk_user_def_type_set (fmt_pktptr , "ptr_field_int", user_type_pktptr);

op_pk_flg_set (fmt_pktptr , "ptr_field_int", flag_pktptr);

op_pk_ack_set (fmt_pktptr , "ptr_field_int", ack_No_pktptr);

op_pk_tmstmp_set (fmt_pktptr , "ptr_field_int", timestamp_pktptr);

op_pk_infn_set (fmt_pktptr , "ptr_field_char", infor_pktptr);

// Send the formatted packet to the output port indexed \

op_pk_send(fmt_pktptr , idex_id);

// Declare segment buffer and reassembly buffer as state variables

Sbhandle seg_buf;

Sbhandle rsm_buf;

// Create segment buffer and reassembly buffer

seg_buf = op_sar_buf_create(OPC_SAR_BUF_TYPE_SEGMENT ,OPC_SAR_BUF_OPT_DEFAULT );

rsm_buf = op_sar_buf_create(OPC_SAR_BUF_TYPE_REASSEMBLY , OPC_SAR_BUF_OPT_DEFAULT );

// Add packets into segment buffer to form a stream

118
for(i = 0; i < 1000; ++i)

op_sar_segbuf_pk_insert(seg_buf , op_pk_create (1024) , i);

// Empty stream by sending all segments from segment buffer

for(i = 0; i < 1000*1024/ SEGMENT_SIZE; ++i)

op_pk_send(op_sar_srcbuf_seg_remove(seg_buf , SEGMENT_SIZE), 0);

// Insert received segment info reassembly buffer

op_sar_rsmbuf_seg_insert (rsm_buf , op_pk_get (0));

// Get the total number of original packets within reassembly buffer

pkt_num = op_sar_rsmbuf_pk_count (rsm_buf );

// Remove and destroy all original packets from reassembly buffer

for(int i = 0; i < pkt_num; ++i)

pktptr = op_sar_rsmbuf_pk_remove (rsm_buf );

op_pk_destroy(pktptr );

119
Annex B: Process Model and Source Code for the DoS attack scenario

Figure B.1: State Transition Diagram of synflood in the Process Editor

Source Code to create DoS attacker packets using Proto-C language in OPNET

/*

* Declare and initialize variables

* Declared in temporary variable block

*/

double pksize = 0;

Packet *pkptr = OPC_NIL;

int i = 0;

/*

* Generate and send 10000 unformatted packets with packet

* sizes following the loaded exponential distribution.

* Invoked in states of process model

*/

120
for(i = 0; i < 1000; ++i)

/* Generate a random packet size following the loaded

* exponential distribution

*/

pksize = op_dist_outcome(dist_exp );

/* Create an unformatted packet with pksize length for attack use */

pkptr = op_pk_create (pksize );

/* Send this packet to output stream */

op_pk_send(pkptr , 0);

Annex C: Process Model and Source Code for DoS attack Mitigation Scenario

Figure C.1: Mathematical Filter Block Diagram

121
However, we want a packet to carry some extra information that does not exist in the real packet
and is only used to facilitate simulation control. For this purpose, we use Interface Control
Information (ICI) Package to manipulate the ICI object and associate it with a packet. ICI is a
data type in OPNET. It can be used to carry integer, double, and structure types of data. ICI can
also be associated with a packet so that the packet can carry extra control information.
/*
* Tha packet analyzer component in mitigation model using Proto-C
*/

void pa_val(void)
{
FIN (pa_val ());
prop_key_update_counter++;
timer_update();
FOUT
}
void timer_update(void)
{
double next_update_time;
FIN(timer_update());
next_update_time = oms_dist_outcome (update_dist_ptr);
if (next_update_time <0)
{
next_update_time = 0;
}
next_update_evh = op_intrpt_timer_self (op_sim_time () + next_update_time, IC_PROP_VAL_CHANGED);
FOUT;
}
void user_pkt_rx()
{
ici *iciptr;
int sourceid;
int conrolid;
int flag;
int key_update_number;
int action;

122
int discard_reason;
int tracker_index;
double generated_timestamp;
active_update_tacker *pTracker;
char msg[255];
int i;
FIN(gw_pkt_rx());
iciptr = op_intrpt_ici ();
if(iciptr == OPC_NIL)
{
op_sim_end("Null ICI", "", "", "");
}
op_ici_attr_get (iciptr, "source_id", &sourceid);
op_ici_attr_get (iciptr, "key_update_number", &key_update_number);
op_ici_attr_get (iciptr, "control_field", &controlid);
op_ici_attr_get (iciptr, "flg", &flag);
op_ici_attr_get (iciptr, "action", &action);
op_ici_attr_get (iciptr, "discard_reason", &discard_reason);
op_ici_attr_get (iciptr, "generated_timestamp", &generated_timestamp);
//Basic field checks
strm_index = op_intrpt_strm ();
pktptr = op_pk_get (strm_index );
switch(strm_index)
{
case 0:
{
// Proto -C
if(sourceid != source_id)
{
op_sim_end("Bad source id for ICI", "", "", "");
}
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Bad key_update_number for ICI", "", "", "");
}
set_action=0;
op_pk_send(pktptr , 0);

123
}
break;
else
{
if(sourceid = source_id)
{
op_sim_end("True source id for ICI", "", "", "");
}
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Good key_update_number for ICI", "", "", "");
}
set_action=1;
op_pk_send(pktptr , 0);
}
break;
//Find the tracker
pTracker = OPC_NIL;
for(tracker_index = 0; tracker_index < op_prg_list_size(active_updates_lst); tracker_index++)
{
active_update_tacker *pTrackerTemp;
pTrackerTemp = (active_update_tacker *)op_prg_list_access(active_updates_lst, tracker_index);
if(pTrackerTemp->update_counter_number == key_update_number)
{
pTracker = pTrackerTemp;
break;
}
}
case 1:

{
// Proto -C
if(controlid != control_field)
{
op_sim_end("Bad controlid for ICI", "", "", "");
}

124
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Bad key_update_number for ICI", "", "", "");
}
set_action=0;
op_pk_send(pktptr , 0);
}
break;
else
{
if(controlid = control_field)
{
op_sim_end("True controlid for ICI", "", "", "");
}
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Good key_update_number for ICI", "", "", "");
}
set_action=1;
op_pk_send(pktptr , 0);

}
break;
}
}
case 2:
if(flag != flg)
{
op_sim_end("Bad flag value for ICI", "", "", "");
}
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Bad key_update_number for ICI", "", "", "");
}
set_action=0;
op_pk_send(pktptr , 0);

125
}
break;
else
{
if(flag = flg)
{
op_sim_end("True flag value for ICI", "", "", "");
}
else if(key_update_number > prop_key_update_counter || key_update_number <= 4)
{
op_sim_end("Good key_update_number for ICI", "", "", "");
}
set_action=0;
op_pk_send(pktptr , 0);
op_sim_end("Allow packets for ICI", "", "", "");
}
break;
}
}
if(pTracker == OPC_NIL)
{
int i;
char msg1[255];
char msg2[255];
char msg3[255];
printf("Current list state\n");
for(i = 0; i < op_prg_list_size(active_updates_lst); i++)
{
active_update_tacker *pTrackerTemp;
pTrackerTemp = (active_update_tacker *)op_prg_list_access(active_updates_lst, i);
sprintf(msg1, "update_counter_number=%d\n", pTrackerTemp-> ("Allow_packets_for_ICI", "", "", "");
printf(msg1);
}
sprintf(msg1, "Tracker index=%d, List size=%d", tracker_index, op_prg_list_size(active_updates_lst));
sprintf(msg2, "key_update_number=%d, prop_key_update_counter=%d", key_update_number,
prop_key_update_counter);
op_sim_end("Drop_spoofed_ packets for ICI", "", "", "");

126
sprintf(msg3, "Action=%d", action);
op_sim_end("Could not find tracker", msg1, msg2, msg3);
}
if(action == 1)
{
//Load_Balancer received packet
if(pTracker->Load_Balancer_rx)
{
op_sim_end("Two Load_Balancer rx interrupts", "", "", "");
}
else if(pTracker->pkts_alive <= 0)
{
op_sim_end("pkts_alive problem", "", "", "");
}
pTracker->Load_Balancer_rx = 1;
op_stat_write(stat_delay, op_sim_time() - generated_timestamp);
op_stat_write(stat_update_success, 1.0);
op_stat_write(stat_update_success_limited_loss, 1.0);
if(last_key_update_num_delivered >= key_update_number)
{
op_sim_end("Problem with Load_Balancer", "", "", "");
}
last_key_update_num_delivered = key_update_number;
}
else if (action == 2)
{
//Store
if(pTracker->pkts_alive < 0)
{
op_sim_end("Thats strange...", "", "", "");
}
pTracker->pkts_alive++;
pTracker->has_one_store = 1;
}
else if (action == 3)
{
//Discard

127
pTracker->pkts_alive--;
pTracker->discard_reason = discard_reason;
}
else
{
op_sim_end("Bad action", "", "", "");
}
has_one_update = 1;
for(i = 0; i < op_prg_list_size(active_updates_lst); i++)
{
pTracker = (active_update_tacker *)op_prg_list_access(active_updates_lst, i);
if(pTracker->pkts_alive <= 0)
{
pTracker->mark_for_delete--;
}
if(pTracker->mark_for_delete <= 0)
{
active_update_tacker *pTrackerTemp;
if(pTracker->pkts_alive < 0 && pTracker->has_one_store)
{
op_sim_end("That_start_range...", "2", "", "");
}
if(pTracker->Load_Balancer_rx == 0)
{
//Nothing left - update has been lost
op_stat_write(stat_update_success, 0.0);
if(pTracker->discard_reason == 1)
{
//Update
}
else if(pTracker->discard_reason == 2)
{
if(pTracker->update_counter_number > last_key_update_num_delivered)
{
op_stat_write(stat_update_success_limited_loss, 0.0);
}
}

128
else
{
op_sim_end("Bad discard reason", "", "", "");
}
}
pTrackerTemp = (active_update_tacker *)op_prg_list_remove(active_updates_lst, i);
if(pTrackerTemp != pTracker)
{
op_sim_end("AHA,not another error!", "", "", "");
}
op_prg_mem_free(pTracker);
}
}
op_ici_destroy(iciptr);
FOUT;
}
void stat_finalize()
{
Stathandle oneup;
int i;
FIN(stat_finalize());
for(i = 0; i < op_prg_list_size(active_updates_lst); i++)
{
active_update_tacker *pTracker;
pTracker = (active_update_tacker *)op_prg_list_access(active_updates_lst, i);
if(pTracker->Load_Balancer_rx == 0)
{
//Receiving should already have been taken care of
op_stat_write(stat_update_success, 0.0);
if(pTracker->update_counter_number > last_key_update_num_delivered)
{
op_stat_write(stat_update_success_limited_drop, 0.0);
}
}
if(pTracker->update_counter_number == sourceid||conrolid||flag)
{
if(pTracker->Load_Balancer_rx == 0)

129
{
op_stat_write(stat_delay, op_sim_time() - pTracker->generated_timestamp);
}
}
}
FOUT;
}

Figure C.2: RIP information of the Routing table

130
 Figure C.3: Comparison of RIP Traffic information received globally

Figure C.3 shows the comparison of traffic received in bits per second based on the global
statistics in the three scenarios independently within the same simulation time interval. As we
see on the source tree the traffic received from the baseline scenario, the attacker scenario and
the mitigation scenario are selected from top to down direction. On the graph preview panel the
respective graphs are displayed from the top to down in the selection order of the global
statistical values from the source tree. We can observe the comparison of three scenarios DoS
attack scenario shows a big traffic received as compared to others.

131
 Figure C.4: Comparison of RIP Traffic sent information globally

Figure C.4 shows the comparison of overall traffic sent to the cloud network in bits per second
from the three scenarios independently within the given time interval. In Figure C.4 it is seen that
the traffic sent from the baseline scenario is minimum as compared to the attack scenario and the
mitigation scenario. But, the mitigation scenario has minimum bits per second transfer as
compared to the attack scenario because of our DoS attack mitigation take an action on the
attacker traffic. The comparison clearly shows bits per second traffic transfer in the DoS attack
scenario is above a double value as compared to the baseline as well as the mitigation scenarios.

132
Declaration

I, the undersigned, declare that this thesis work is my original work, has not been presented for a
degree in this or any other universities, and all sources of materials used for the thesis work have
been duly acknowledged.

Name: Aderaw Semma

Signature: ______________________
Place: Addis Ababa
Date: ___________________________
This thesis has been submitted for examination with my approval as a university advisor.
Name: Dr. Mulugeta Libsie
Signature: ______________________
Place: Addis Ababa
Date: ___________________________

133