DDoS Detection and Mitigation in

SDN using ONOS controller

A Report Submitted
in Partial Fulfillment of the Requirements
for the Degree of
Bachelor of Technology
in
Information Technology

by
Ayush Gupta (20168024)
Shubham (20168045)
Anukul Joshi (20168056)
Ajeet Prasad (20168085)

Group: IT-04

under the supervision of

Dr. Shashank Srivastava

to the
COMPUTER SCIENCE AND ENGINEERING DEPARTMENT
MOTILAL NEHRU NATIONAL INSTITUTE OF TECHNOLOGY
ALLAHABAD, PRAYAGRAJ, UTTAR PRADESH (INDIA)
June, 2020
 UNDERTAKING

I declare that the work presented in this report titled “DDoS Detection and Mitigation
in SDN using ONOS controller”, submitted to the Computer Science and Engineering
Department, Motilal Nehru National Institute of Technology Allahabad, Prayagraj,
Uttar Pradesh (India) for the award of the Bachelor of Technology degree in
Information Technology , is my original work. I have not plagiarized or submitted
the same work for the award of any other degree. In case this undertaking is found
incorrect, I accept that my degree may be unconditionally withdrawn.

June, 2020
Prayagraj
U.P. (India)

(Ayush Gupta)

(Shubham)

(Anukul Joshi)

(Ajeet Prasad)
‘

ii
iii
Preface

We hereby present the project on DDoS Detection and Mitigation in SDN (Software
Defined Networking)using ONOS controller. The controller that we used is ONOS.
ONOS is based on the principle of SDN. In SDN we have various controllers which
help us in network monitoring, defining rules for the network management, identifi-
cation of anomalies etc. in an efficient manner. In this project we have performed
DDoS attacks (SYN flood and ICMP flood attacks) on a targeted single host with
ONOS controller managing the network components. Then network traffic details
and statistics are collected using ONOS APIs and openflow protocol which helps us
in creating the dataset. Various machine learning techniques are then applied on the
dataset to analyse and gain useful insights from the data. We have also performed
live detection and mitigation of the attacks. Detection is performed by testing the
incoming traffic against the machine learning model that we have already trained
and once the attack is detected, mitigation is performed with the ONOS application
running at the controller which installs new flow rules in the flow tables at switches
to stop the attack.
We declare that we have taken help from the internet whose references have been
stated. We have also taken immense help and guidance from our mentor Dr.
Shashank Srivastava. We hope this thesis proves helpful to its readers.

iv
Acknowledgements

We are very grateful to our mentor Dr. Shashank Srivastava Sir for giving us an
opportunity to learn something new. We take this opportunity to thank him for
the encouragement, sound advice and lots of good ideas and suggestions during the
project.
We would also like to thank Dr. Shashwati Banerjea for formation of groups for
projects which enabled us to work on this project.
We are also thankful to Mr. Naveen Kumar for his constant guidance throughout
the project.
Further, we thank all the teaching and non-teaching staff of the Department of
Computer Science and Engineering for their constant assistance and co-operation.
We would also like to thank the Linux Foundation for hosting the ONOS project as
an open source project.

v
Contents

Preface iv

Acknowledgements v

1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 4

3 Proposed Work 6
3.1 Attacks Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 SYN Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 ICMP Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 ONOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 Bazel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5 hping3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.6 Mausezahn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.7 sFlow-rt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Creation of Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Generating Normal Traffic . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Generating DDoS Attacks Traffic . . . . . . . . . . . . . . . . 12
3.3.3 Collecting Statistics using ONOS APIs . . . . . . . . . . . . . 12
3.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

vi
 3.4.1 Multi Layer Perceptron(MLP) . . . . . . . . . . . . . . . . . . 14
3.4.2 K Nearest Neighbours (kNN) . . . . . . . . . . . . . . . . . . 15
3.4.3 Support Vector Machine(SVM) . . . . . . . . . . . . . . . . . 16
3.4.4 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . 17
3.5 Live Detection and Mitigation . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Worflow using Openflow for collecting Data . . . . . . . . . . 20
3.5.2 Workflow using sflow-RT and its limitations . . . . . . . . . . 22

4 Experimental Setup and Results Analysis 24

4.1 Installing the required tools . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 ONOS set up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Starting Mininet and creating Topology . . . . . . . . . . . . . . . . . 25
4.4 Attacking with Hping3/Mausezahn . . . . . . . . . . . . . . . . . . . 27
4.5 Topology Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.6 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Live Detection and Mitigation . . . . . . . . . . . . . . . . . . . . . . 42

5 Conclusion and Future Work 46

5.1 Conclusion and Limitations . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

References 48

vii
Chapter 1

Introduction

A world without internet cannot be imagined. And internet service is not possible
without the underlying networking infrastructure. Traditional networking princi-
ples have now become old and new paradigm for network management called SDN
(Software Defined Networking) has emerged. In a Software Defined Network, a net-
work engineer or administrator can shape traffic from a centralized control console
without having to touch individual switches in the network. The centralized SDN
controller directs the switches to deliver network services wherever they’re needed,
regardless of the specific connections between a server and devices. The basis of
SDN is virtualisation, which in its most simplistic form allows software to run sep-
arately from the underlying hardware.

Four pillars of SDN

1. The control and data planes are decoupled. Control functionality is removed
from network devices that will become simple (packet) forwarding elements.

2. Forwarding decisions are flow based, instead of destination based.

3. Control logic is moved to an external entity, the so-called SDN controller.

4. The network is programmable through software applications running on top

of the controller that interacts with the underlying data plane devices.[24]

DDoS has remained a nightmare for industries and academia since last decade.

1
SDN came with a hope of solving the critical problem of DDoS detection and mit-
igation. But due to design issues of OpenFlow and centralized point of control,
it has been found vulnerable to DDoS Attack. DDoS attacks are dangerous and
can potentially bring down networks. In SDN environment, an OpenFlow switch
matches the flow input by checking the packet header. In case of no match, packet
is forwarded to the controller which writes a flow rule for such packets and forwards
it to switch flow tables. At the time of a DDoS attack, large number of packets
(with the spoofed IP addresses) are sent to the controller. And hence the controller
becomes overwhelmed with these packets and is unable to process the legal packets.
Also since a lot of new flow rules are forwarded to the switches, the flow tables with
limited capacity become full and thus legal traffic transmission halts. Hence both
the controller and switches can be attacked. Therefore, this paper provides mech-
anisms to tackle the DDoS attacks in SDN, and found Open Network Operating
System (ONOS) as an ideal as well as an unexplored controller to perform the task.
We aim to explore the different types of DDoS attacks that may be performed on
an SDN controller and lists out the prominent features that reflect unusual traffic.
Further, machine learning algorithms are used to classify the legitimate traffic and
the attack traffic. The model generated from the application of these algorithms
would help to detect DDoS attacks in real time and also mitigate them.

Distributed Denial of Service Attack

Distributed Denial of Service (DDoS) attacks are a critical threat to the Internet.
A DDoS attack is a malicious attempt to disrupt normal traffic of a targeted server,
service or network by overwhelming the target or its surrounding infrastructure with
a flood of Internet traffic. DDoS attacks operate by utilizing multiple compromised
computer systems as sources of attack traffic. The compromised systems can be
computers and other networked resources such as IoT devices[23]. Recently, there
have been an increase in number of DDoS attacks against online services and Web
applications. Some of the biggest DDoS attacks till now include 2018 GitHub attack
and 2016 Dyn attack.

2
1.1 Motivation
The separation of the control plane from the data plane of a switch enables abstrac-
tion of a network through a logically centralized controller. The controller functions
as the “brain” of a software-defined network. However, centralized control draws
attackers to exploit different network devices by hijacking the controller. Security
was initially not a key characteristic of SDN architecture, which left it vulnerable
to various attackers. The investigation of such attacks in the newly emerging SDN
architecture is a challenging task. Therefore, a comprehensive forensic mechanism
is required to investigate different forms of attacks by determining their root cause.

DDoS attacks are dangerous and can potentially bring down network causing
immense loss to the victim. Since the number of such attacks are increasing at a
very high pace day by day, hence we wanted to find mechanisms to tackle the DDoS
attacks in SDN and we found ONOS as an ideal controller to perform our task.
By making use of machine learning techniques to first train the model and then
applying it to test the incoming unknown traffic, we try to detect any such attempt
made by attackers before they victimize the entire network.

3
Chapter 2

Related Work

There has been some research and development in the field of DDoS attacks in SDN
environment in the previous years. Dayal et al. [1] analysed the various DDoS at-
tacks in SDN architecture and compares and contrasts these attacks on how they
affect the system.
Mohan et al. [2] discussed the solution to various attacks possible in SDN including
denial of service to network and to the controller. Generally, the DDoS attack de-
tection module in SDN is based on statistical analysis or static policy which helps
in detecting volumetric attacks. For the detection of the different class of DDoS
attack including volumetric, reflection and protocol exploitation, traffic analysis is
cumbersome and its analysis through machine learning paves a way of efficient DDoS
detection.
For the SDN paradigm, Braga et al. in [3] first and foremost suggested the use
of Self-organizing map (SOM) to classify network flows. They proposed a feature
set for the detection of DDoS attack in SDN based infrastructure. Exploiting the
proposed feature set, the SOM-based classifier classifies the flow as malicious or le-
gitimate.
Kokila et al. [4] proposed and implemented SVM based model in SDN controller
for identifying DDoS attack and obtained less false positive results as compared to
other classifiers like Random Forest, J48, Radial Basis Function (RBF) and Naı̈ve
Bayes.
Gabriel et al. [5] and Cui et. al. [6] used Neural Network in their proposed DDoS

4
detection model for analyzing network flows to identify malicious behavior. Tree
based method XGBoost is used by [7].
Bawany et al. [8] proposed a detection and mitigation mchanism of DDoS attacks
in a large-scale network, but the same is not suitable for small-scale network.
Latah and Toker [9] used two staged approach to detect the DDoS attacks. First
they would measure the rate of the arriving packets in the network based on statis-
tics collected by controller. When packet rate passed the pre-determined threshold,
an inspection unit that used SVM was activated to detect DDoS flooding attacks.
Ye et al. [10] collected the data traffic by means of the controller. Six features re-
lated to DDoS attacks were extracted and SVM was employed to detect the attack.
For UDP and TCP attacks, high accuracy was reported. But for the ICMP attack,
low accuracy rate was reported due to the fact that they considered no. of source
port per unit time as one of the features and ICMP flow has no source or destination
port.
This report discusses the various attacks performed in SDN environment and pro-
poses a solution to detect such attacks by developing a machine learning based
trained model. The features are selected in such a way so that they can used to
detect various types of attacks with a high accuracy and avoid the limitations of
previously discussed approaches.

5
Chapter 3

Proposed Work

The proposed DDoS detection system consists of data collection, analysing the data
collected, applying machine learning techniques to detect whether an attack attempt
has been made and then mitigating the attack. To create SDN network topology,
mininet network emulator is used. Mininet creates a network of virtual switches
supported openflow for flexible and customized routing, host and links. There are
variety of open source SDN controllers like RYU, Floodlight, OpenDay Light, POX
etc. We chose ONOS as a controller for managing the network topology created by
mininet. The flowchart below describes the different steps that were involved.

Figure 1: Different Steps in DDoS Detection

6
3.1 Attacks Performed
3.1.1 SYN Flood
A SYN flood (half-open attack) is a type of denial-of-service (DDoS) attack which
aims to make a server unavailable to legitimate traffic by consuming all available
server resources. Here’s how it works:

1. The attacker sends a high volume of SYN packets to the targeted server, often
with spoofed IP addresses

2. The server then responds to each one of the connection requests and leaves an
open port ready to receive the response.

3. While the server waits for the final ACK packet, which never arrives, the
attacker continues to send more SYN packets. The arrival of each new SYN
packet causes the server to temporarily maintain a new open port connection
for a certain length of time, and once all the available ports have been utilized
the server is unable to function normally [21].

Figure 2: SYN Flood attack in action

7
3.1.2 ICMP Flood
An icmp flood is a denial-of-service attack in which the attacker attempts to over-
whelm a targeted device with ICMP echo-request packets, causing the target to
become inaccessible to normal traffic. ICMP flood can be broken down into 2 re-
peating steps:

1. The attacker sends many ICMP echo request packets to the targeted server
using multiple devices.

2. The targeted server then sends an ICMP echo reply packet to each requesting
device’s IP address as a response [22].

Figure 3: ICMP Flood attack in action

8
3.2 Tools Used
The important setup tools that have been used are ONOS, Mininet and maven which
are describes as follows.

3.2.1 ONOS
ONOS stands for Open Network Operating System. ONOS provides the control
plane for a software-defined network (SDN), managing network components, such
as switches and links, and running software programs or modules to provide com-
munication services to end hosts and neighboring networks.
OpenFlow is the communications protocol that gives access to the forwarding
plane of a network switch or router over the network [11].

3.2.2 Mininet
Mininet is a network emulator which creates a network of virtual hosts, switches,
controllers, and links. Mininet hosts run standard Linux network software, and its
switches support OpenFlow for highly flexible custom routing and SDN [12].

3.2.3 Maven
Maven is a build automation tool used primarily for Java projects. Maven can
also be used to build and manage projects written in C, Ruby, Scala, and other
languages. The Maven project is hosted by the Apache Software Foundation.
Since the ONOS apps are written using Java language, maven was used to build
the app and create an oar file which was then installed using ONOS cli.

3.2.4 Bazel
Bazel is a tool that automates software builds and tests. Supported build tasks
include running compilers and linkers to produce executable programs and libraries,
and assembling deployable packages for Android, iOS and other target environments.

9
Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven.
Features of bazel are:

• Multi-language support: Bazel supports many languages, and can be extended

to support arbitrary programming languages.

• High-level build language: Projects are described in the BUILD language, a

concise text format that describes a project as sets of small interconnected
libraries, binaries and tests. In contrast, with tools like Make, you have to
describe individual files and compiler invocations.

• Multi-platform support: The same tool and the same BUILD files can be used
to build software for different architectures, and even different platforms [13].

Bazel has been used to first build the ONOS project and then to run it locally.

3.2.5 hping3
hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface
is inspired to the ping(8) unix command, but hping isn’t only able to send ICMP echo
requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute
mode, the ability to send files between a covered channel, and many other features
[14]. hping is a widely used tool for performing DDoS attacks. It provides a lot of
options to adjust the traffic according to the requirements.

3.2.6 Mausezahn
Mausezahn is a free fast traffic generator written in C which allows you to send nearly
every possible and impossible packet. It is mainly used to test VoIP or multicast
networks but also for security audits to check whether your systems are hardened
enough for specific attacks [15]. Mausezahn can be used for generating traffic gen-
erator (e. g. to stress multicast networks), for penetration testing of firewalls, for
DDoS attacks on networks (for testing purposes) etc.

10
 Mausezahn is basically a versatile packet creation tool on the command line with
a simple syntax. Currently Mausezahn is only available for Linux platforms. It is
also a widely used tool for performing DDoS attacks.

3.2.7 sFlow-rt
sFlow-rt provides real-time analytics for actionable intelligence to support Devel-
opers and SDN applications. sFlow-RT receives a continuous stream of telemetry
from standard sFlow agents embedded in network devices, hosts and applications
and converts them into actionable metrics, accessible through a REST API [16].

11
3.3 Creation of Data Set
3.3.1 Generating Normal Traffic
60% percent of our dataset contains the normal traffic that would be generated
when normal usage of the network is going on. The normal traffic has been gen-
erated using mausezahn/hping3 commands by sending the data between multiple
source/destination pairs. Different types of traffic including TCP, UDP, ICMP and
DNS packets etc. were sent during the normal traffic.

3.3.2 Generating DDoS Attacks Traffic

The rest of the dataset contains the traffic when the DDoS attack takes place. The
attacks have been performed using the mausezahn/hping3 tool. A single destination
with IP 10.0.0.1 was chosen as the victim. Attack was performed using spoofed IP
addresses.

3.3.3 Collecting Statistics using ONOS APIs

An ONOS app was created for the purposes of collecting the data. The app utilises
some APIs provided by ONOS to collect the require data. The features selected are
listed as follows :

• Average bytes per flow(bps in and bps out): Bytes(bytes-in and bytes-
out) per flow will be high during an attack phase, making it an important
feature in the identification of DDoS attack.

• Number of frames per second: In a volumetric DDoS approach, the frames

in each flow will be increased drastically to consume the network bandwidth.
On the other hand, in protocol exploitation frames will increase, but not as
high as in the case of volumetric attack.

• Entropy of destination IP addresses per second: During a DDoS attack

all the attack packets are destined either to a single host or a small pool of
host, making the randomness of destination IP address quite small.

12
• Entropy of source IP address per second: As DDoS attack is distributed
in nature, i.e. the attack sources are either distributed in the network via a
bot or attacker is using spoofed IP addresses to attack the victim. Hence, the
randomness of source IP addresses in the attack flows will be quite high.

• Entropy of IP protocol per second: The protocol utilized to perform a

DDoS attack would be same in most of the cases, more the number of attack
flows, less will be the randomness of the IP protocol being used to perform the
attack. Hence, the entropy of the IP protocol per second will be lower during
attack phase than during regular traffic.

13
3.4 Testing
3.4.1 Multi Layer Perceptron(MLP)
A multilayer perceptron (MLP) is a feedforward artificial neural network that gen-
erates a set of outputs from a set of inputs. An MLP is characterized by several
layers of input nodes connected as a directed graph between the input and output
layers. MLP uses backpropagation for training the network.
• Activation Function
The activation function combines the input to the neuron with the weights
and then adds a bias to produce the output. In other words, the activation
function maps the weighted inputs to the output of the neuron. One of such
activation functions is the sigmoid function which is used to determine the
output of the neuron. Another types of activation function that can be used
are the Rectified Linear Unit (ReLU) or the tanh function.
There are 3 types of layers. They are Input, Hidden and Output layers respectively.

• Input or Visible Layers - The bottom layer that takes input from your
dataset is called the visible layer, because it is the exposed part of the network.
Often a neural network is drawn with a visible layer with one neuron per input
value or column in your dataset.

• Hidden Layers - Layers after the input layer are called hidden layers because
that are not directly exposed to the input. The simplest network structure is
to have a single neuron in the hidden layer that directly outputs the value.
Given increases in computing power and efficient libraries, very deep neural
networks can be constructed. Deep learning can refer to having many hidden
layers in your neural network.

• Output Layer - The final hidden layer is called the output layer and it is
responsible for outputting a value or vector of values that correspond to the
format required for the problem.
The choice of activation function in he output layer is strongly constrained by
the type of problem that you are modeling.

14
Figure 4: Figure depicting working of Multi Layer Perceptron with input, hidden
and output layers [18]

• Learning - via Back propagation

The training process of the MLP occurs by continuous adjustment of the
weights of the connections after each processing. This adjustment is based
on the error in output(which is the different between the expected result and
the output). This continuous adjustment of the weights is a supervised learn-
ing process called ‘backpropagation’. The backpropagation algorithm consists
of two parts:

– Forward pass - Here, the expected output corresponding to the given

inputs are evaluated backward pass.
– Backward pass - Partial derivatives of the cost function with respects
to the different parameters are propagated back through the network.

The process continues until the error is at the lowest value.

3.4.2 K Nearest Neighbours (kNN)

The k-nearest neighbors algorithm (kNN) is a non-parametric method used for clas-
sification. The training examples are vectors in a multidimensional feature space,

15
each with a class label. The training phase of the algorithm consists only of stor-
ing the feature vectors and class labels of the training samples. In the classification
phase, k is a user-defined constant, and an unlabeled vector (a query or test point) is
classified by assigning the label which is most frequent among the k training samples
nearest to that query point. Here we used Euclidean distance as distance metric.
p
Euclidean distance between two points is given by (x1 − x2 )2 + (y1 − y2 )2

Figure 5: Figure depicting the working of K Nearest Neighbours [19]

3.4.3 Support Vector Machine(SVM)

Support Vector Machine (SVM) is a supervised machine learning algorithm which
can be used for both classification or regression challenges. In this algorithm, we plot
each data item as a point in n-dimensional space (where n is a number of features
you have) with the value of each feature being the value of a particular coordinate.
Then, we perform classification by finding the hyper plane that differentiates the
two classes.
In figure 4, we have three hyper planes (A, B and C) and all are segregating the
classes well. Here, maximizing the distances between nearest data point (either
class) and hyper-plane will help us to decide the right hyper-plane. This distance
is called as Margin. As in figures, you can see that the margin for hyper-plane C is
high as compared to both A and B. Hence, we name the right hyperplane as C.

16
Figure 6: Figure depicting three hyper planes differentiating two classes and their
distances from the two classes (maximum is the best)[20]

3.4.4 Performance Evaluation

k-fold cross validation technique was used to evaluate the machine learning models
where the original sample is randomly partitioned into k equal size sub-samples.
The model is trained using k-1 sub-samples and tested using the remaining sub-
sample. This is then repeated k times. The k results from these samples can then
be averaged to produce a single output. The model used in our study employed
10-fold cross validation.

The accuracy for each fold is determined by -

TP + TN
Accuracy =
TP + TN + FP + FN
where True Positives (TP) is the total number of attack traffic instances correctly
classified as attack traffic; True Negatives (TN) is the total number of normal traffic
instances correctly classified as normal traffic; False Positives (FP) is the total num-
ber of normal traffic instances falsely classified as attack traffic and False Negatives
(FN) is total number of attack traffic instances falsely classified as normal traffic.
The accuracy of the whole folds is used to compute the final accuracy. Also along
with the accuracy, to further evaluate the performance and unbiased nature of the
model we have calculated precision, recall and f1 score as well.

Precision tells how precise the model is, out of those predicted positive, how many

17
of them are actual positive. It is calculated as -
TP
P recision =
TP + FP

When there is high cost associated with false negatives, recall is used. Recall tells out
of total actual positives, how many are detected by our model as positive. Formula
for recall is -
TP
Recall =
TP + FN

F1-score is a function of Precision and Recall and is relevant to determine the balance
between precision and recall. F1-score can be calculated as -
P recision ∗ Recall
F 1 − score = 2 ∗
P recision + Recall

18
3.5 Live Detection and Mitigation
• Live Detection - The models which we have trained already with the data
collected are used for detecting whether an attack has been launched or not.
The new incoming traffic is tested against the trained model and information
is sent to the ONOS app running at controller.

• Mitigation - For the purpose of mitigation we are employing tracebacking

technique to first trace the attacker and once the attacker has been traced,
we install new flow rules at the switch to which attacker is connected. The
switch will drop those packets that were sent by the attacker and destined to
the victim. We resolve two big issues in this way. First, the victim will not
be attacked further. Second, since those enormous amount of packets would
be dropped at the first switch only and won’t be forwarded further, so the
overall network would not be overwhelmed by that traffic and the unnecessary
wastage of bandwidth would be avoided.

Steps for the tracebacking algorithm used:

1) Start from the victim and find the switch to which the victim is connected.
2) Let it be s.
3) Find the port on s that received the largest amount of bytes. Let it be p.
4) Find the device connected to port p.
5) If that device is a host, then it means we have got the attacker. The con-
troller then installs the flow rule in the flow table of switch s and the algorithm
terminates.
6) If that device is a switch, then move to that switch and go to step 2.

This entire work at the controller end would be done through the app that we built
for ONOS.

19
 Figure 7: Tools used for detection

We performed the entire analysis and process using two methods -

• sFlow-RT - The data statistics were collected using sflow-RT which installs an
agent on every switch in the network.

• OpenFlow - The data statistics were collected using openflow protocol and
ONOS APIs inside ONOS app.

The detailed live detection and mitigation process using Openflow protocol is ex-
plained as follows -

3.5.1 Worflow using Openflow for collecting Data

1. We first stored the trained ML models into a file using python. For SYN attack
we stored SVM and kNN for SYN attack and ICMP attack respectively since
they had the best accuracy.

2. Then we created an app in ONOS that would do the work of mitigating the
attack when it happens by defining the flow rules for switches.

3. The code of the app is written in Java and build was done using maven.

20
4. Then we start the local ONOS instance, mininet to create the topology using
the commands mentioned in the next section.

Figure 8: Flow of DDoS detection & Mitigation module (Using Openflow)

5. After this a python server is started. App running at ONOS controller connects
as client to the python server. The incoming data statistics collected using
ONOS APIs in the app are sent to the server. The server analyses the incoming
traffic to find whether there is an attack or not. Prediction is done using the
stored trained models. If any of the model detects that an attack has been
launched, the result is sent as ”Attack Detected” to the app running at ONOS
controller.

6. App receives the information. Now, there are two possibilities, the result
obtained is -

(a) Attack - In this case, the controller traces back the attacker using the
tracebacking technique already mentioned above and defines a flow rule
to drop the packets sent by the attacker and destined to the victim. In
this way, we make sure that the victim host doesn’t get overwhelmed
by the huge amount of packets coming from attacker since they will be
dropped at the switch itself.

21
 (b) No Attack - In this case, the normal flow in the traffic continues. Con-
troller need not take any specific action.

3.5.2 Workflow using sflow-RT and its limitations

Figure 9: Flow of detection and mitigation module (Using sflow)

Here two major differences are visible from the approach used earlier.

1. Data collection - The data statistics are collected using sflow-RT tool in the
python server script. Earlier the data was being collected inside the ONOS
app itself and it was sent to the python server by the app.
Limitations -
sflow-rt is an external app which installs an agent at every switch in the net-
work. These agents are then used to collect the data statistics. This creates
an extra overhead on the switches which are already handling such a large
volume of data and this also increases the external dependencies in the app.

2. Mitigation - Mitigation of the attacks was done by creating flow rules on the
switch to which the victim was connected. Whereas in the earlier approach, the

22
flow rules are being created on the switch to which the attacker is connected.
Limitations -
Creating flow rules on the switch to which victim is connected stops the victim
from receiving the data but the attack data still travels from the attacker to the
entire network and then reaches the victim. Hence the attack data exploits
the network bandwidth and creates unnecessary load and congestion in the
network.

23
Chapter 4

Experimental Setup and Results

Analysis

4.1 Installing the required tools

First of all, all the tools mentioned in section 3.2 are required to be installed.

#ONOS source code

ONOS is build from its souce code downloaded from github
using command :
git clone https://gerrit.onosproject.org/ONOS

#Mininet
sudo apt-get install mininet

#Maven
sudo apt-get install maven

#Bazel
sudo apt-get install bazel

#sFlow-RT
sFlow-RT folder can be downloaded from here:
https://sflow-rt.com/download.php

#Hping3
sudo apt-get install hping3

# Mausezahn

24
sudo apt-get install netsniff -ng

#Python 3.6
Python 3.6 and its packages:
sudo apt-get install python3.6
sudo apt-get install python3-pip
sudo pip3 install numpy

4.2 ONOS set up

After the installation, we start the ONOS local instance. That is done using bazel
tool. The controller is running on localhost ip - 127.0.0.1
#Run ONOS
$ bazel run onos-local

#Login into ONOS CLI

$ tools/test/bin/onos localhost

#activate apps using ONOS CLI

app activate org.onosproject.openflow
app activate org.onosproject.fwd
app activate org.ddosmodule.app // app created by us
cfg set org.onosproject.fwd.ReactiveForwarding matchIpv4Address true
// for matching IPv4 Addresses also while matching a flow rule

4.3 Starting Mininet and creating Topology

After setting up ONOS controller, we need to add nodes to data plane. We attach
Mininet to the controller by following command.

#starting Mininet

For tree topology with depth 2

$ sudo mn --topo=tree,depth=2,fanout=5
--controller=remote,ip=127.0.0.1

For creating custom topology using file "filename.py"

25
$ sudo mn --custom=filename.py
--topo topology --controller=remote,ip=127.0.0.1

To view the created topology

Go to
http://127.0.0.1:8181/onos/ui/index.html
* username : onos
* password : rocks

#Run python server for sending attack information to ONOS

controller
$ python3 live_detection.py

26
4.4 Attacking with Hping3/Mausezahn
Next we open xterm windows from various nodes and target a node to bring it
down. We perform two of the most devastating DDoS attacks SYN flood and ICMP
flood. We chose host 10.0.0.1 as the victim and the attacks were performed from
host 10.0.0.10. The following commands are used :
#SYN flood
hping3 -S -p 80 --flood 10.0.0.1 --rand-source
mz eth0 -c 0 -t tcp dp=80,flag=syn -A rand -B 10.0.0.1

#ICMP flood
hping3 --icmp --rand-source --flood 10.0.0.1
mz eth0 -c 0 -t icmp "ping" -A rand -B 10.0.0.1

4.5 Topology Used

Figure 10: Topology that we have used

27
4.6 Data Analysis
The data was collected for normal traffic and attack traffic separately. Dataset of
total 15000 (9000 for normal traffic + 6000 for attack) tuples was created for each
attack. K-fold cross validation technique was used to evaluate the machine learning
models. Our feature vector consists of six features. Our target vector consists of
two classes to identify a flow as the attack (1) or normal traffic (0).
We have done the analysis of each attack separately. We plotted the heatmap to
find the correlation between the features, boxplots to observe how the feature values
varied during attack and no attack.
And then after applying machine learning algorithms on the dataset, we also com-
puted accuracy, precision, recall etc.

28
SYN ATTACK ANALYSIS
• Description of Dataset

Figure 11: Dataset Description

• Correlation matrix

Figure 12: Correlation matrix

The correlation matrix shows that the attack status depends heavily on source

29
 entropy. This is because we have used random source ip addresses during at-
tack. It also highly depends on destination entropy since during the attack,
enormous amount of packets are destined towards the same destination (vic-
tim) and hence the entropy is quite low.

• Relation between source entropy and attack vectors

Figure 13: Boxplot between source entropy and attack vectors

Source entropy is very high during attack since we have spoofed the source ip
address during the attack to use random address during every frame transfer.

• Relation between destination entropy and attack vectors

Figure 14: Boxplot between destination entropy and attack vectors

30
 Range of destination entropy is low during an attack as one node is targeted
and comparatively high during normal packet flow.

• Relation between bps in and attack vectors

Figure 15: Boxplot between bps in and attack vectors

The boxplot in Figure shows there is not much variation in the bps in param-
eter during a syn attack since it isn’t a volumetric attack.

• Relation between bps out and attack vectors

Figure 16: Boxplot between bps out and attack vectors

The boxplot in Figure 15 above shows there is not much variation in the bps
out parameter during a syn attack.

31
• Relation between frames and attack vectors

Figure 17: Boxplot between frames and attack vectors

The boxplot in Figure above shows there is some variation in the frames pa-
rameter during a syn attack as compared to no attack.

• Relation between protocol entropy and attack vectors

Figure 18: Boxplot between protocol entropy and attack vectors

The boxplot in Figure shows that protocol entropy is low during attack since
large number of packets of same type are sent.

32
ICMP ATTACK ANALYSIS
• Description of Dataset

Figure 19: Dataset Decription

• Correlation matrix

Figure 20: Correlation matrix

Correlation between attack and source entropy, destination entropy, bps in,
bps out is very high. Also, mean value of bps in and bps out in case of ICMP

33
 attack is quite high as compared to SYN attack since this is a volumetric
attack.

• Relation between source entropy and attack vectors

Figure 21: Boxplot between source entropy and attack vectors

Source entropy is high since source ip has been spoofed during the attack.

• Relation between bps in and attack vectors

Figure 22: Boxplot between bps in and attack vectors

Since icmp flood is a volumetric based attack, bps in are high in this case also.

34
• Relation between bps out and attack vectors

Figure 23: Boxplot between bps out and attack vectors

Bps out is high since attack being volumetric in nature.

• Relation between destination entropy and attack vectors

Figure 24: Boxplot between destination entropy and attack vectors

Destination entropy is low during attack as one node is targeted with large
number of packets and comparatively high during normal packet flow.

35
• Relation between frames and attack vectors

Figure 25: Boxplot between frames and attack vectors

The boxplot in Figure above shows there is high variation in the frames pa-
rameter during a icmp attack as compared to syn attack.

• Relation between protocol entropy and attack vectors

Figure 26: Boxplot between protocol entropy and attack vectors

The boxplot in Figure shows that protocol entropy is low during attack since
large number of packets of same type are sent.

36
4.7 Testing
The following classification algorithms were used to classify whether the incoming
traffic was an attack or not -

• Multi Layer Perceptron(MLP) - MLP is a class of feed forward artifi-

cial neural network (ANN) which uses a supervised learning technique called
backpropagation for training.

• k Nearest Neighbours(kNN) - kNN is one of the simplest and easy to

implement supervised learning algorithm used for both classification and re-
gression problems.

• Support Vector Machine(SVM) - SVM is a learning method based on

statistical learning theory. It can get good classification results even with less
training data.

Using the above classification algorithms, confusion matrix between the predicted
label and actual label is drawn as below. Accuracy, precision, recall and f1-score are
calculated for each model as mentioned in section 3.4.4.
In both of the attacks, kNN model had the best accuracy 99.23% and 98.65% for
SYN and ICMP attacks respectively. Hence, the accuracy obtained is quite high.
Furthermore, performance in terms of precision, recall and f1-score is also great
and thus it is evident that the model is unbiased and performs really well.

37
SYN ATTACK
• k-fold Cross Validation results for MLP Classifier

Accuracy = 99.2%
Precision = 0.99
Recall = 0.99
f1 score = 0.99

• k-fold Cross Validation results for SVM classifier

Accuracy = 99.2%
Precision = 0.99
Recall = 0.99
f1 score = 0.99

• k-fold Cross Validation results for kNN classifier

Accuracy = 99.23%
Precision = 0.99
Recall = 0.99
f1 score = 0.99

38
 (a) MLP - SYN attack (b) SVM - SYN attack

(c) kNN - SYN attack

Figure 27: ROC curves for different models

A receiver operating characteristic curve, or ROC curve, is a graphical plot that

illustrates the diagnostic ability of a binary classifier system as its discrimination
threshold is varied. The area under the ROC curve (AUC) is a measure of how well
a parameter can distinguish between two diagnostic groups, which in our case, is
quite high.

39
ICMP ATTACK
• k-fold Cross Validation results for MLP Classifier

Accuracy = 97.94%
Precision = 0.98
Recall = 0.98
f1 score = 0.98

• k-fold Cross Validation results for SVM classifier

Accuracy = 96.99%
Precision = 0.97
Recall = 0.97
f1 score = 0.97

• k-fold Cross Validation results for kNN classifier

Accuracy = 98.65%
Precision = 0.99
Recall = 0.99
f1 score = 0.99

40
 (a) MLP - ICMP attack (b) SVM - ICMP attack

(c) kNN - ICMP attack

Figure 28: ROC curves for different models

The area under ROC curve (AUC) in the case of ICMP attack is somewhat
smaller than the AUC obtained in the case of SYN attack, but is still quite high.

41
4.8 Live Detection and Mitigation
Command for creating a new app.
$ onos-create-app app org.ddosmodule ddos-app 1.0-SNAPSHOT
org.ddosmodule.app

The command for compiling the app through maven.

$ mvn install

After the app has been built by maven, the following commands add the app inside
our local ONOS instance.
$ cd onos
$ export ONOS_ROOT="‘pwd‘"
$ source tools/dev/bash_profile
$ onos-app localhost install <path to the oar file in target>.oar

To activate the app from ONOS cli.

app activate org.ddosmodule.app

Pseudo code for live detection in python script.

1. start python server
2. load the two models using pickle library in python
3. receive the required features for the live traffic through the
ONOS app connected as client
4. Features required are: frames, source IP entropy, destination IP
entropy, protocol entropy, bytes-per-sec in, bytes-per-sec out
5. test the received data against the two models
7. initialise the prediction as "--------"
8. if prediction made by any model is attack
then change the prediction to "Attack Detected"
9. send the prediction to the app running at controller
10. go to step 3 again

42
Pseudo code for mitigation in ONOS app.
1. start a python client and connect to the server
2. collect the required features through ONOS APIs
3. calculate the (shannon) source entropy, destination entropy using
the packet-in packets.
4. send the data to server
5. receive the prediction from server
5. if the prediction is "Attack Detected"
Perform tracebacking as described in section 3.5
6. else
do nothing

43
 Testing
This is the python server output. The difference in the output is visible clearly.
During the time of attack, ”Attack Detected” is printed and during the normal
traffic ”—–” is printed.
Here attacker is h10 (10.0.0.10/32)
and the victim is h1 (10.0.0.1/32)

Figure 29: Python server output

The controller receives the prediction from the server. Red rectangular box in
Figure 30 shows that when the prediction is received as “Attack Detected”, trace-
backing is performed and it reaches the attacker which is “10.0.0.10” in this case.
After finding the attacker, flow rule is installed at the switch to which attacker is
connected.
In this way, we detected the attack attempt and mitigated it successfully.

44
Figure 30: ONOS console output

45
Chapter 5

Conclusion and Future Work

5.1 Conclusion and Limitations

We successfully collected the data for two different most common DDoS attacks on
a network - SYN flood (protocol based) and ICMP flood (volumetric). We used that
data to train our machine learning models MLP, SVM and kNN.
Also we have used k fold cross-validation technique to further make our model
unbiased. The average results of k trials is recorded. We were able to obtain the
maximum accuracy of 99.23% and 98.65% using kNN for SYN and ICMP attacks
respectively.
We were able to detect and mitigate the DDoS attack when it occurs. We have
performed the detection using ONOS app itself using the APIs provided by ONOS
and we used tracebacking technique to trace the attacker and mitigate the attack.

Limitations - The data for legitimate traffic could have been collected in a more
better way. This would have made it more challenging for the ML models to dif-
ferentiate between the two types of traffic. But due to the hardware and software
limitations (low RAM and old processor in our laptops) we weren’t able to create
a large topology in mininet. Due to this the source entropy in case of legitimate
traffic was quite low as compared to the attack traffic, and hence the data became
quite refined.

46
5.2 Future Work
The future work in the project would be to collect the dataset on a high performance
computer with adequate hardware specifications. If these requirements are met, a
larger topology can be created in mininet than what we used now and it would be-
come more challenging task for the machine learning model to classify the incoming
traffic as attack or legitimate. Along with this, since in ONOS we can implement
multiple controllers at the same time, so in future we are thinking of using multiple
controllers instead of just one so that they communicate with each other and more
efficiently prevent DDoS attacks.

47
References

[1] N. Dayal, S. Srivastava, ”Analyzing behavior of DDoS attacks to identify DDoS

detection features in SDN”, International Conference on Communication Sys-
tems and Networks (COMSNETS), pp. 274- 281, 2017.

[2] Mohan Dhawan, Rishabh Poddar, Kshiteej Mahajan, Viay Mann, Sphinx: De-
tecting Security Attacks in Software-Defined Networks, NDSS Symposium, 2015.

[3] Braga, R., Mota, E., & Passito, A., “Lightweight DDoS flooding attack detection
using NOX/OpenFlow”, In IEEE 35 th Conference on Local Computer Networks
(LCN),IEEE , 2010 pp. 408-415.

[4] Kokila, R. T., Selvi, S. T., & Govindarajan, K., “DDoS detection and analysis
in SDN- based environment using support vector machine classifier”, In Sixth
International Conference on Advanced Computing (ICoAC), IEEE, 2014, pp.
205-210.

[5] Mihai-Gabriel, I., & Victor-Valeriu, P., “Achieving DDoS resiliency in a software
defined network by intelligent risk assessment based on neural networks and
danger theory”, In 15th International Symposium on Computational Intelligence
and Informatics (CINTI), IEEE, 2014 (pp. 319-324).

[6] Cui, Y., Yan, L., Li, S., Xing, H., Pan, W., Zhu, J., & Zheng, X., “SDAnti-
DDoS: Fast and efficient DDoS defense in software-defined networks”, Journal
of Network and Computer Applications, 68, 2016, pp.65-79.

[7] Zhuo Chen, Fu Jiang, Yijun Cheng, Xin Gu, Weirong Liu et al., “XGBoost
Classifier for DDoS Attack Detection and Analysis in SDNbased Cloud”, IEEE
International Conference on Big Data and Smart Computing, 2018.

48
[8] N. Z. Bawany, J. A. Shamsi, and K. Salah, “DDoS attack detection and mitiga-
tion using SDN: methods, practices, and solutions,” Arabian Journal for Science
and Engineering, vol. 42, no. 2, pp. 425–441, 2017.

[9] M. Latah, L. Toker, A novel intelligent approach for detecting DoS flooding
attacks in software-defined networks. Int. J. Adv. Intell. Inform. 2018, 4, 11–20.

[10] J. Ye, X. Cheng, J. Zhu, L. Feng, L. Song, A DDoS attack detection method
based on SVM in software defined network. Secur. Commun. Netw. 2018.

[11] ONOS documentation,Available fromhttps://onosproject.org/

[12] Mininet:An Instant Virtual Network on your Laptop (or other PC), Available
from http://mininet.org/http://mininet.org/

[13] Bazel FAQs, Available from https://bazel.build/faq.htmlhttps://bazel.build/faq.html

[14] hping3 official documentation, Available from

http://www.hping.org/http://www.hping.org/

[15] Linux Man page, Available from http://man7.org/linux/man-

pages/man8/mausezahn.8.htmlhttp://man7.org/linux/man-
pages/man8/mausezahn.8.html

[16] sFlow-rt, Available from http://sflow-rt.com/

[17] Python 3.5, Available from https://www.python.org/

[18] N. Kang. Mlp. [Online]. Available: https://towardsdatascience.com/multi-

layerneural-networks-with-sigmoid-function-deep-learning-for-rookies-2-
bf464f09eb7f

[19] Knn. [Online]. Available: https://blog.usejournal.com/a-quick-introduction-to-

k-nearest-neighbors-algorithm-62214cea29c7

[20] S. Ray. Understanding support vector machine algorithm. [Online].

Available:https://www.analyticsvidhya.com/blog/2017/09/understaing-
support-vector-machine-example-code/

49
[21] Syn flood attack [Online]. Available: https://www.cloudflare.com/learning/ddos/syn-
flood-ddos-attack/

[22] Ping (ICMP) Flood DDoS Attack [Online]. Available:

https://www.cloudflare.com/learning/ddos/ping-icmp-flood-ddos-attack/

[23] What is a DDoS Attack?[Online] Available: https://www.cloudflare.com/en-

ca/learning/ddos/what-is-a-ddos-attack/

[24] Kreutz et al,”Software-Defined Networking: A Comprehensive Sur-

vey”,Proceedings of the IEEE, Vol. 103, No. 1, Jan. 2015

50