Discussion - Are machine learning based intrusion detection system always secure? An insight into tampered learning.

Similarpaperdownload_5.pdf

Home >Computer Science homework help >Discussion - Are machine learning based intrusion detection system always secure? An insight into tampered learning.

A Dissertation

entitled

Design and Implementation of a Deep Learning based Intrusion Detection System in

Software-Defined Networking Environment

Quamar Niyaz

Submitted to the Graduate Faculty as partial fulfillment of the requirements for the

Doctor of Philosophy Degree in Engineering

Dr. Weiqing Sun, Committee Chair

Dr. Ahmad Y. Javaid, Committee Co-Chair

Dr. Mansoor Alam, Committee Member

Dr. Junghwan Kim, Committee Member

Dr. Mohammed Niamat, Committee Member

Dr. Hong Wang, Committee Member

Dr. Amanda Bryant-Friedrich, Dean College of Graduate Studies

The University of Toledo

August 2017

ProQuest Number:

INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted.

In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed,

a note will indicate the deletion.

ProQuest

Published by ProQuest LLC ( ). Copyright of the Dissertation is held by the Author.

Microform Edition © ProQuest LLC.

ProQuest LLC. 789 East Eisenhower Parkway

P.O. Box 1346 Ann Arbor, MI 48106 - 1346

11011026

2018

This document is copyrighted material. Under copyright law, no parts of this document may be reproduced without the expressed permission of the author.

An Abstract of

Design and Implementation of a Deep Learning based Intrusion Detection System in Software-Defined Networking Environment

Quamar Niyaz

Submitted to the Graduate Faculty as partial fulfillment of the requirements for the Doctor of Philosophy Degree in Engineering

The University of Toledo August 2017

Network management becomes difficult when the size of the network grows. An

ill-managed network opens several ways for the adversaries to exploit the security

vulnerabilities for intrusions. Also, low-priced Internet subscriptions and publicly

available attack tools enable the attackers to launch undiscovered or zero-day attacks

in a network. Machine learning based approaches are well-suited to detect such kinds

of undiscovered attacks. However, the hand-engineering involved in machine learn-

ing approaches for the proper selection of features from the network traffic puts a

constraint on the accuracy of attack detection. The recently emerged networking

paradigm named as software-defined networks (SDN) and the reincarnation of the

neural network as deep learning (DL) promise to revolutionize the relevant indus-

tries. The SDN centralizes the network management and controls the network from a

logically single point. The DL-based approach significantly improves the selection of

features for the classification or prediction in an unsupervised manner. In our work,

we utilize the benefits offered by the SDN and DL for the design and implementation

of a network intrusion detection system (NIDS). The NIDS, implemented as an SDN

application, can monitor the entire network for intrusions from a single point. Us-

ing the DL-based approach for the implementation helps in proper feature selection

from a large traffic feature set and produces high accuracy with very low false alarms

iii

in intrusion detection. Before a real-world implementation of the NIDS, we develop

a DL-based NIDS using a benchmark intrusion dataset (NSL-KDD) to explore the

applicability of a DL-based approach for the NIDS implementation. An evaluation

of the attack impact on network services running in the SDN environment is also

performed. We analyze the response time and loss of service delivery in different

attack scenarios. Finally, we discuss the implementation of a light-weight testbed for

network security experiments developed with the tools used in an SDN infrastructure.

Dedicated to

My brother Dr. Abdul Malik Jawaid and sisters: Sofia Noor, Rukhshanda Obaid,

and Sabahat Zarrin

Acknowledgments

It would be tough to express the gratitude in words to the committee members,

family, and friends. However, I will make an attempt to acknowledge their guidance,

support, and love on this academic journey.

I express my thankfulness to my advisor Dr. Weiqing Sun for his valuable research

advice and care. I am thankful to him for providing an excellent research environ-

ment. I would like to thank my co-advisor Dr. Ahmad Y. Javaid for his insights and

participation in my research. His critical feedback for the research writings consider-

ably improved the quality. I would like to express my gratitude to Dr. Mansoor Alam

for sharing his research experience and philosophy towards life. The valuable pieces

of advice from my committee members Dr. Mohammed Niamat, Dr. Junghwan Kim,

and Dr. Hong Wang are also appreciated.

I am thankful to the EECS and ET departments for the financial assistance in

all these four years and providing me the teaching opportunities as an independent

instructor.

I would like to express my deepest gratitude to my parents; my brother Dr. Jawaid;

my sisters Sufi, Rukhsi, and Zarrin; and my sister-in-law Neda Jamil. I would not

be able to come so far without their love and support. I would like to thank my

wife Najia Islam for her love, support, and patience. Lastly, I would like to thank

my friends in India and US: Dr. Ayatullah, Rahat, Kashif, Junaid, Rehan, Tameem,

Tauseef, Dr. Arshan, Maroof, Farha, Farid, Shahrukh, Atif, Masood, Yahya, Sarim,

Mubashshir, Aasim, Hamza, Safia, Dr. Ejaz, and Tauheed.

Contents

Abstract iii

Acknowledgments vi

Contents vii

List of Tables xi

List of Figures xiii

List of Abbreviations xvi

1 Introduction 1

1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Security Issues and Challenges in the SDN . . . . . . . . . . . 5

1.2.2 Intrusion Detection Systems using Machine Learning and Deep

Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.3 DDoS Detection in the SDN Environment . . . . . . . . . . . 9

1.3 Research Objectives and Contributions . . . . . . . . . . . . . . . . . 10

1.4 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Software-Defined Network and Deep Learning 14

2.1 Software-Defined Network (SDN) . . . . . . . . . . . . . . . . . . . . 14

2.1.1 The SDN Architecture . . . . . . . . . . . . . . . . . . . . . . 15

vii

2.1.2 Flow Installation in the SDN . . . . . . . . . . . . . . . . . . 18

2.2 Deep Learning (DL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.1 Sparse Autoencoder and Stacked Autoencoder . . . . . . . . . 21

3 Attack Impact Evaluation in the SDN 24

3.1 Security Threats in the SDN . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 The SDN Management Threats . . . . . . . . . . . . . . . . . 25

3.1.2 The Control Plane Threats . . . . . . . . . . . . . . . . . . . . 26

3.1.3 The Data Plane Threats . . . . . . . . . . . . . . . . . . . . . 27

3.2 Attack Implementation and Impact Analysis . . . . . . . . . . . . . . 28

3.2.1 The Data Plane Attack . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1.1 Web hosts and adversaries reside in the same network 33

3.2.1.2 Web hosts reside in one network and adversaries reside

in the other network . . . . . . . . . . . . . . . . . . 35

3.2.1.3 Web hosts reside in one network and adversaries reside

in the network of web hosts and another network as

well . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1.4 Web hosts and adversaries are distributed in different

networks . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Control Channel Spoofing . . . . . . . . . . . . . . . . . . . . 39

3.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Deep Learning based NIDS for the NSL-KDD 43

4.1 Dataset Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 The NSL-KDD Dataset . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1 The NIDS Implementation . . . . . . . . . . . . . . . . . . . . 48

4.2.2 Accuracy Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii

4.2.3 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . 50

4.2.3.1 Evaluation based on the Training data . . . . . . . . 52

4.2.3.2 Evaluation based on the Training and Test Data . . 54

4.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Deep Learning based NIDS in the SDN 56

5.1 DDoS Attacks in a Network . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Implementation of the NIDS . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Traffic Collector and Flow Installer (TCFI) . . . . . . . . . . . 59

5.2.2 Feature Extractor (FE) and Traffic Classifier (TC) . . . . . . 62

5.3 Experimental Set-up and Results . . . . . . . . . . . . . . . . . . . . 65

5.3.1 Experimental Set-up . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Traffic Analysis and Modified TCFI (MTCFI) . . . . . . . . . . . . . 75

5.4.1 Traffic Analysis of Public Datasets . . . . . . . . . . . . . . . 75

5.4.2 The Implementation of MTCFI . . . . . . . . . . . . . . . . . 78

5.4.2.1 Performance Evaluation of the MTCFI . . . . . . . . 81

5.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Conclusion & Future Work 85

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

References 88

A A Light-weight Testbed for Network and Security Experiments 102

A.1 Tools Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

A.1.1 Linux Container (LXC) . . . . . . . . . . . . . . . . . . . . . . 104

A.1.2 Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

A.2 The Testbed Architecture, Management, and Access . . . . . . . . . . 105

A.2.1 Testbed Architecture . . . . . . . . . . . . . . . . . . . . . . . 105

A.2.2 Testbed Management . . . . . . . . . . . . . . . . . . . . . . . 107

A.2.3 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

A.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

A.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

List of Tables

2.1 A flow table in a switch with a few installed rules . . . . . . . . . . . . . 18

3.1 Link speed and delay for different links in the experiments . . . . . . . . 30

4.1 Continuous features and their types in the KDD Cup 99 and NSL-KDD

datasets [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Nominal and binary features in the KDD Cup 99 and NSL-KDD datasets

[35] along with their types and 1-to-n encoding . . . . . . . . . . . . . . 46

4.3 Attack types and different attacks in each type in the NSL-KDD dataset

[95] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Distribution of records in the NSL-KDD dataset [95]. . . . . . . . . . . . 47

5.1 Different headers extracted from the TCP, UDP, and ICMP packets . . . 61

5.2 Features extracted by the FE for the TCP flows . . . . . . . . . . . . . . 63

5.3 Features extracted by the FE for the UDP flows . . . . . . . . . . . . . . 64

5.4 Features extracted by the FE for the ICMP flows . . . . . . . . . . . . . 64

5.5 Number of records in the training and test datasets for normal and different

DDoS attack traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.6 Classification accuracy comparison among soft-max and SAE based models 73

5.7 Accuracy and false-positive rates for 8-class and 2-class SAE models . . . 73

5.8 Average computational time for the training and classification in the SAE

model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.9 Precision, recall, and f-measure comparisons for the two NIDS implemen-

tations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.10 Accuracy and false alarms comparisons for the two NIDS implementations 83

xii

List of Figures

1-1 Top network attacks observed in 2015 [51] . . . . . . . . . . . . . . . . . 2

2-1 An SDN infrastructure with its decoupled control and data planes along

with various network applications . . . . . . . . . . . . . . . . . . . . . . 16

2-2 A reactive mode flow rules installation in the SDN [58] . . . . . . . . . . 18

2-3 Various steps involved in the traditional ML and DL approaches [25] along

with our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2-4 A stacked autoencoder (SAE) based deep learning model . . . . . . . . . 23

3-1 Data plane attack implemented for the performance analysis of network

services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3-2 Average connection setup latency when all the web hosts and adversaries

reside in the same network. . . . . . . . . . . . . . . . . . . . . . . . . . 32

3-3 Average loss fraction when all the web hosts and adversaries reside in the

same network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3-4 Average connection setup latency when the web hosts reside in one network

and the adversaries reside in a different network. . . . . . . . . . . . . . . 34

3-5 Average loss fraction when the web hosts reside in one network and the

adversaries reside in a different network. . . . . . . . . . . . . . . . . . . 34

3-6 Average connection setup latency when the web hosts reside in one network

and the adversaries reside in the network of web hosts and another network

as well. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

xiii

3-7 Average loss fraction when the web hosts reside in one network and the

adversaries reside in the network of web hosts and another network as well. 36

3-8 Average connection setup latency when the web hosts and adversaries are

distributed in different networks. . . . . . . . . . . . . . . . . . . . . . . 37

3-9 Average loss fraction when the web hosts and adversaries are distributed

in different networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3-10 Control plane attack with the spoofed switch identity implemented for the

performance analysis of network services. . . . . . . . . . . . . . . . . . . 38

3-11 Average connection setup latency with varying spoofing interval of the

malicious switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3-12 Average loss fraction with varying spoofing interval of the malicious switch 41

4-1 Self-taught learning implementation . . . . . . . . . . . . . . . . . . . . . 48

4-2 Various steps involved in the NIDS implementation . . . . . . . . . . . . 49

4-3 Classification accuracy achieved for 2-class, 5-class, and 23-class on the

training data using the STL and SMR . . . . . . . . . . . . . . . . . . . 51

4-4 Precision, recall, and f-measure values achieved for 2-class on the training

data using the STL and SMR . . . . . . . . . . . . . . . . . . . . . . . . 51

4-5 Classification accuracy achieved for 2-class and 5-class on the test data

using the STL and SMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4-6 Precision, recall, and f-measure values achieved for 2-class on the test data

using the STL and SMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4-7 Precision, recall, and f-measure values achieved for 5-class on the test data

using the STL and SMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5-1 Different techniques for launching a DDoS attack . . . . . . . . . . . . . 58

5-2 An NIDS with its components implemented in the SDN to detect DDoS

attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

xiv

5-3 Home Wireless Network (HWN) for normal traffic collection . . . . . . . 65

5-4 Confusion matrix for 8-class classification in the SAE model . . . . . . . 71

5-5 Precision, recall, and f-measure values for 8-class . . . . . . . . . . . . . . 71

5-6 ROC curve for 8-class classification . . . . . . . . . . . . . . . . . . . . . 72

5-7 Confusion matrix for 2-class classification . . . . . . . . . . . . . . . . . . 74

5-8 Precision, recall, and f-measure values for 2-class classification . . . . . . 74

5-9 The cumulative distribution function (CDF) of the number of flows arrived

at the hosts in 60s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5-10 The cumulative distribution function (CDF) of the number of HTTP re-

quests made to the servers in 60s . . . . . . . . . . . . . . . . . . . . . . 76

5-11 Flow count for the tuples in the two lists before and after arrival of a

packet for an asymmetric flow . . . . . . . . . . . . . . . . . . . . . . . . 80

5-12 Average execution time of the FE module for both the TCFI implemen-

tations with the increased number of downloads . . . . . . . . . . . . . . 81

5-13 Average transfer time for a web service with the increased number of

concurrent downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A-1 The testbed with two virtual networks on an infrastructure of three phys-

ical hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A-2 The GRE tunneling between two hosts in which hosts are tunneled with

the remote IP of each other . . . . . . . . . . . . . . . . . . . . . . . . . 108

A-3 The administrator and users access the testbed from the Gateway host.

The administrator uses vnetc client application to access. . . . . . . . . 109

A-4 A testbed infrastructure implemented on a VMWare ESXi host with a

network topology used in V-NetLab [40]. . . . . . . . . . . . . . . . . . . 110

List of Abbreviations

ANIDS . . . . . . . . . . . . . . . . . . . Anomaly-based NIDS

ANN . . . . . . . . . . . . . . . . . . . . . . Artificial Neural Networks

CDF . . . . . . . . . . . . . . . . . . . . . . Cumulative Distribution Function

DDoS . . . . . . . . . . . . . . . . . . . . . Distributed Denial of Services

DL . . . . . . . . . . . . . . . . . . . . . . . . Deep Learning

DNS . . . . . . . . . . . . . . . . . . . . . . Domain Name Systems

FE . . . . . . . . . . . . . . . . . . . . . . . . Feature Extractor

HTTP . . . . . . . . . . . . . . . . . . . . Hyper Text Transfer Protocol

HTTPS . . . . . . . . . . . . . . . . . . . Hyper Text Transfer Protocol Secure

HWN . . . . . . . . . . . . . . . . . . . . . Home Wireless Network

IP . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol Address

MTCFI . . . . . . . . . . . . . . . . . . . Modified Traffic Collector and Flow installer

NIDS . . . . . . . . . . . . . . . . . . . . . Network Intrusion Detection System

NTP . . . . . . . . . . . . . . . . . . . . . . Network Time Protocol

OF . . . . . . . . . . . . . . . . . . . . . . . OpenFlow

OVS . . . . . . . . . . . . . . . . . . . . . . Open vSwitch

RBF . . . . . . . . . . . . . . . . . . . . . . Radial Basis Function

RBM . . . . . . . . . . . . . . . . . . . . . Restricted Boltzmann Machine

RF . . . . . . . . . . . . . . . . . . . . . . . . Random Forest

ROC . . . . . . . . . . . . . . . . . . . . . . Receiver Operating Characteristics

SAE . . . . . . . . . . . . . . . . . . . . . . Stacked Auto-encoder

SDN . . . . . . . . . . . . . . . . . . . . . . Software-defined Networks

SLA . . . . . . . . . . . . . . . . . . . . . . Service Level Agreement

xvi

SNIDS . . . . . . . . . . . . . . . . . . . . Signature-based NIDS

SOM . . . . . . . . . . . . . . . . . . . . . . Self-Organized Maps

TC . . . . . . . . . . . . . . . . . . . . . . . Traffic Classifier

TCFI . . . . . . . . . . . . . . . . . . . . . Traffic Collector and Flow installer

TCP . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol

VNI . . . . . . . . . . . . . . . . . . . . . . Visual Networking Index

xvii

Chapter 1

Introduction

The Internet has played a significant role for the social, economic, and political growth

of the developing and developed nations. The organizations use the Internet to pro-

vide services and make their resources available through it for the rapid dissemination.

An individual shares or stores his/her information on the websites such as social net-

working, online banking, and e-commerce. As a result, a large amount of information,

growing every year at a compound rate, is available on the Internet. Cisco Visual Net-

working Index (VNI) forecasts that the global Internet traffic will reach 2.3 zettabytes

(1018 GB) per year in 2020 [9]. The plethora of available information on the Internet

with high-dependence raises concerns on the confidentiality, integrity, and availability

(CIA) of the information.

1.1 Background and Motivation

Cyberattackers launch various network intrusions to violate the CIA triad. Figure 1-1

shows the distribution for some of the top network attacks that took place in 2015 [51].

The objectives for conducting these attacks are diverse including extortion, revenge,

misguided marketing, and online protest with target organizations such as banking,

health care, government, defense, news, and social media [11, 99, 110]. These attacks

cause reputation and financial damages to the organizations. According to the report

Figure 1-1: Top network attacks observed in 2015 [51]

of Imperva Incapsula security firm, an hour of network attack can cost up to $20,000

or above to the organizations [27].

Among the network attacks, distributed denial of service (DDoS) is the most

common and easy to launch. DDoS attacks make online services and information

unavailable by inundating the network with unwanted traffic. The easy accessibility

of the attack tools along with the low-priced Internet subscription have increased the

volume and complexity of these attacks in recent years. Cisco VNI has predicted

that in a comparison to 2015, DDoS incidents will increment three-fold and reach up

to 17 million in 2020 [9]. The nature of attacks has transformed from a single type

of flooding to multi-vector. According to a report, 64% of DDoS attacks until mid-

2016 were multi-vectors that combined TCP SYN flood and DNS/NTP amplification

together [102]. DDoS detection is a challenging task which can be attributed as

follows:

• Differentiating an attack traffic from the legitimate traffic, attackers forge packet

headers so that they may appear legitimate.

• Voluminous traffic such as flash-crowd is different from DDoS. Therefore, the

system must be able to differentiate them.

• Distinguishing a flash-crowd attack from an actual flash-crowd [65].

The network administrators deploy network intrusion detection systems (NIDSs)

to detect various intrusions that might occur inside an organizational network. An

NIDS observes and analyzes the incoming and outgoing traffic for the network hosts

and generates alarms once it detects any intrusion. An NIDS can be broadly catego-

rized into two classes based on the detection approach:

1. Signature-based NIDS (SNIDS)- In the SNIDS such as Snort [88], administra-

tors install attack signatures in the NIDS. The SNIDS monitors the traffic and

compares them against the installed signatures to detect that if the observed

traffic is an intrusion or normal. It is effective in the detection of known attacks

with high accuracy and low false alarms. On the other hand, it performs mis-

erably to detect undiscovered or novel attacks for which it does not have any

pre-installed attack signatures.

2. Anomaly-based NIDS (ANIDS)- In contrast to the SNIDS, an ANIDS classifies

network traffic as an intrusion if it observes any deviation from the normal

pattern in the traffic. Although ANIDS produces high false alarms, it is well-

suited for the detection of novel attacks. Therefore, it has wide acceptance

among the research community for being capable of identifying new attacks.

Several challenges come across in developing an efficient ANIDS for a novel attack

detection. One of the challenges is the proper selection of features from the network

traffic. With the evolving attack scenarios, features identified to detect one category

of attacks may not be suitable for the others. The other issue with the NIDS devel-

opment is the lack of labeled traffic dataset from real networks. It needs considerable

efforts to produce labeled dataset from raw network traffic traces collected over a

period or in real-time. Additionally, system administrators do not want to report any

intrusions that might have occurred in the organizations to preserve the privacy of its

users and confidentiality of the network structures [21]. Different machine learning

approaches such as support vector machines (SVM), artificial neural networks (ANN),

self-organized maps (SOM), naive-bayesian (NB), and random forests (RF) have been

applied to develop ANIDS. The NIDSs are implemented as classifiers to distinguish

the normal traffic from the anomalous ones. Some of the NIDSs select or extract

features to find a subset of relevant features from the traffic dataset to improve the

classification results. Feature selection or extraction removes the redundant features

or noises from the datasets and eliminates the possibility of improper training [100].

Recently, software-defined networking (SDN) and deep learning (DL) have found

several useful applications in their respective domains. The SDN is a lately emerged

networking paradigm that facilitates centralized network management; provides a

global view of the managed network; makes network devices flexible for different func-

tions through the programmable control plane. These features of the SDN offer better

network monitoring and enhance the security compared to the traditional networks

[74, 82]. Likewise, the DL-based approaches showed better performance compared

to the existing machine learning techniques when applied to various pattern recogni-

tion problems in computer vision, image processing, and speech recognition domains.

They improve the features extraction/reduction task from a high-dimensional dataset

in an unsupervised manner by inheriting the nonlinear characteristics of neural net-

works [75]. Researchers have also started to apply the DL techniques to implement

various intrusion detection systems and observed desirable results. They consider

that the DL-based approaches can overcome the challenges found in the effective

NIDS development [21, 73]. We can collect network traffic data without any labels

from different sources and obtain an abstract features representation from them using

the DL techniques. These features could be then applied for supervised classification

of a small but labeled traffic dataset consists of normal and anomalous traffic. The

traffic for labeled dataset can be generated in a confined, isolated and private net-

work. Motivated by these facts, in this dissertation work, we implement an NIDS

using a DL-based approach in the SDN environment and evaluate its performance

on datasets that consist of normal and attack traffic. The motivation behind using

the DL-based approach is to overcome the challenges in features selection or reduc-

tion for the NIDS development as the DL-based approaches can reduce a large set

of features into an optimal feature set by self-learning, thus enhance the detection

rate. We implement the NIDS in the SDN environment as it improves the network

visibility and management. The decentralized network management in the traditional

networks makes them susceptible for various intrusions.

1.2 Related Works

Although we implement an NIDS in the SDN environment, the SDN has certain

security challenges that need to be addressed for its wide acceptance. We started

our work with the impact evaluation of adversarial attacks in the SDN. Therefore,

we discuss the related works from three perspectives. First, we review the pieces of

literature that address security issues and challenges in the SDN. Then, we examine

various NIDSs developed using machine learning and the DL-based approaches on a

benchmark intrusion dataset (NSL-KDD). Finally, we discuss various DDoS detection

systems implemented in an SDN environment.

1.2.1 Security Issues and Challenges in the SDN

In [79], Sezer et al. discussed various challenges for the large-scale deployment of the

SDN. They considered issues such as security, performance, scalability, and interop-

erability of the SDN with the traditional networks. Kreutz et al. in [39] categorized

security threats in the SDN into seven vectors. Among them, three vectors are spe-

cific to the SDN only that include controller vulnerabilities, lack of trust between the

controller and applications along with the attack on the administrator host. In [37],

Kloti et al. presented security analysis and modeling methodologies in the SDN us-

ing the STRIDE and attack tree approach and uncovered vulnerabilities in the SDN.

Scott-Hayward et al. presented a survey on security implementation using the SDN

and security of the SDN control plane in [76].

In addition, a few works addressed some of the security issues in the SDN. In [83],

Shin et al. implemented a framework for developing various security applications over

the SDN. The framework has a provision to resolve conflicts among flow rules instal-

lation by different network applications. Thus, it restricts the bypassing of firewall

rules implemented through a security application by some non-security applications.

Hu et al. and Wang et al. proposed robust firewall applications through the flow and

firewall authorization space checking in [29] and [105], respectively. They considered

the intra-table rule dependencies inside the flow tables of the switches for rule-conflict

detection. Shin et al. in [85] proposed an extension to OpenFlow (OF) data plane to

reduce the interaction between the control plane and data plane during adversarial

attacks. It reduces the load on the controller to handle a large number of flow re-

quests from the switches. However, the extension is limited only for the TCP-based

flows. In [47], Liyanage et al. proposed a secure control channel architecture for the

mobile SDN using Host Identity Protocol (HIP). In [50], Matsumoto et al. proposed

the architecture to defend the SDN controller from a malicious administrator. Wen

et al. proposed a fine-grained permission system for the restricted access of network

applications on the controller and managed network in [108].

1.2.2 Intrusion Detection Systems using Machine Learning

and Deep Learning

In this section, we shed lights on some of the recent accomplishments in this area. We

confine our discussion only to those works that used the NSL-KDD dataset [95] for the

performance evaluation. The NSL-KDD is a benchmark network intrusion dataset to

evaluate the performance of an NIDS and eliminates some of the issues observed in the

KDD Cup-99 dataset [35]. We have used the NSL-KDD to implement a DL-based

NIDS before a real-world implementation of the NIDS in the SDN. We categorize

different works by how the authors used the training data in their evaluation: whether

they have used it for the training and test purposes or only for the training.

Naoum et al. [57] used ANN with enhanced resilient back-propagation to design an

NIDS. They used the training dataset for training (70%), validation (15%) and test-

ing (15%). The usage of unlabeled data in their evaluation resulted in performance

degradation. Chae et al. in [8] used J48 decision tree classifier with 10-fold cross-

validation for the evaluation on the training dataset. They reduced the feature set

from 41 features, found in the NSL-KDD dataset, to 22 features. Thaseen et al. [98]

evaluated many popular tree-based supervised classifiers. They observed that random

tree model showed the best performance compared to the other models with the high-

est degree of accuracy and reduced false alarms. Some of the works proposed 2-levels

classification approaches. In [68], Panda et al. used discriminative multinomial naive

Bayes as a base classifier at the first level and nominal-to-binary supervised filtering

at the second level along with 10-fold cross-validation for the evaluation. The authors

further extended their work in [69] by using ensembles of balanced nested dichotomies

and RF at the first and second level, respectively and found an enhancement in the

result with a high detection rate and low false alarms. Eid et al. in [17] used a 2-level

approach with principal component analysis for the feature set reduction at first level

and then the SVM with radial basis function (RBF) for the final classification at

the second level. The approach resulted in a high detection accuracy with the train-

ing dataset when all 41 features were used. A reduced feature set that included 23

features only resulted in better detection accuracy for some of the attacks, however,

overall performance was reduced. The authors improved the result using information

gain to rank the features and then applied behavior-based feature selection to reduce

the total number of features from 41 to 20. The authors reported improvement in the

accuracy when used the training dataset for the evaluation [18].

Kromer et al. in [41] used fuzzy classification with the genetic algorithm to design

the NIDS and evaluated the performance on the test dataset. They found the detec-

tion accuracy above 80% with a low false positive rate. In [93], Syarif et al. found

that the performance of unsupervised clustering algorithms, using only the training

data, reduced drastically when the system was evaluated using the test data. Gogoi

et al. in [24] implemented the NIDS using k-point algorithm and achieved a slightly

better detection accuracy and fewer false-alarms, using both the training and test

datasets. Pereira et al. used a less popular technique, Optimum-path forest that

uses graph partitioning for feature classification and found a high detection accuracy

within one-third of the time compared to the SVM-RBF method in [70]. Although

a significant research has been done for the implementation of NIDS using machine

learning techniques [81], we confined our discussion only to the relevant ones here.

In [73], Mostafa et al. used the restricted Boltzmann machine (RBM) based deep

belief network (DBN) for feature reduction along with the SVM as a classifier to

implement the NIDS on the NSL-KDD dataset. The approach showed an accuracy

of 92.84% when applied to the training data. We can consider our work an enhance-

ment over this approach with the usage of both the training and test dataset for the

evaluation. Ugo et al. in [21] used discriminative RBM to develop a semi-supervised

learning based NIDS. They evaluated the performance using different network traffic

for the training and test purposes. They used real-world traffic traces and the KDD

Cup-99 dataset for their implementation. Our approach is different from them in a

way that we use the NSL-KDD dataset to find the application of DL-based approach

in the NIDS implementation. Moreover, the feature selection task is unsupervised

and based on the sparse autoencoder. In [22], Gao et al. implemented an NIDS for

the KDD Cup-99 dataset using RBM-based DBN with a neural network as a clas-

sifier. Kang et al. in [33] proposed an NIDS for the security of vehicular networks

using DBN and found an improvement in the detection accuracy compared to the

previous approaches. In [49], Ma et al. implemented a system that used spectral

clustering along with the sparse autoencoder based deep neural network. To evaluate

the performance of their model, they used the KDD-Cup99, NSL-KDD, and a sensor

network dataset. A sparse autoencoder based DL approach for network traffic iden-

tification was implemented in [107]. The authors identified network applications for

TCP-based flows in their work instead of the intrusion detection. A few of the works

used time-series based approach instead of machine learning where the detection takes

place by observing changes in the traffic for consecutive time windows. However, the

approach may lead to increased false alarms as a small change or fluctuation triggers

alarms [44, 86].

1.2.3 DDoS Detection in the SDN Environment

Braga et al. in [6], proposed a light-weight DDoS detection system in the SDN using

SOM. They derived the features using the statistics collected from the flow tables of

the switches for a specific interval to make the NIDS implementation light-weight.

However, the implementation has a limitation of handling those traffic for which

flow rules are not installed inside the flow tables. In [23], Giotis et al. used OF

and sFlow [80] together to implement an anomaly detection system with a reduced

processing overhead compared to the native OF-statistics collection. The implemen-

tation was based on flow sampling. Therefore, false alarms were quite high in the

attack detection. Lim et al. in [45] proposed a DDoS blocking application using the

SDN to block DDoS attacks that appear as legitimate traffic. The implementation

works in collaboration with the targeted servers to detect the attacks. However, the

prototype was limited to detect only HTTP flooding attack. In [56], Mousavi et al.

proposed an entropy-based system to detect a DDoS attack in the controller. The

implementation used a threshold value for the entropy to detect the attacks which

they selected after performing several experiments. The approach has a limitation

of choosing a threshold value for the entropy which may vary in different scenarios.

Similar to the previous approach, Wang et al. in [106] proposed an entropy-based

light-weight DDoS detection system where they export the flow statistics collection

to the switches from the controller. Although the approach reduces the overhead of

flow statistics collection in the controller, it attempts to bring back the intelligence

in the network devices. A very recent work found in [94] that used the DL approach

for the intrusion detection in the SDN environment. However, the authors used the

NSL-KDD dataset using only six features in it for the DL-based NIDS development

and provided an insight of the integration of their model with an SDN environment,

without a real-world implementation.

1.3 Research Objectives and Contributions

The primary objective of this dissertation is to utilize the features offered by the SDN

and harness the ability of the DL-based intelligence to design and develop an efficient

NIDS. The centralized management and enhanced network visibility in the SDN help

to develop the NIDS as a network application in an SDN environment. The developed

NIDS can program the network devices in such a way that they can be simultaneously

used for traffic forwarding and monitoring along with the intrusion detection purposes.

Therefore, it avoids the installation of third-party security devices or middle-boxes

for the intrusion detection in the network. The DL-based approaches improve the

classifier performance by extracting optimal features from a dataset. Following are

the contributions made in this dissertation:

• We implement an NIDS using stacked autoencoder (SAE) based DL model that

detects multi-vector DDoS attacks. A large set of features is extracted from

the network traffic. These features are then used to find the optimal abstract

features with the help of the SAE. The model is applied to different datasets

consist of normal and anomalous traffic. The NIDS is implemented as a network

application on top of the SDN controller and detects the attacks in the SDN

control and data planes.

• We investigate the application of the DL-based approaches for the NIDS imple-

mentation before their usage in the SDN. To do so, we first develop an NIDS

for a benchmark intrusion dataset known as the NSL-KDD. We use the training

and test datasets for the NIDS evaluation contrast to many previous works. We

develop the NIDS from three perspectives:

– Explicitly identify the records for each attack using the training datasets

– Identify the records based on the attack classes using the training and test

datasets

– Identify the records as normal or anomalous using the training and test

datasets

• Although we use the SDN to develop an NIDS, the SDN is vulnerable to various

security threats. Some of these threats are specific to the SDN only. Perfor-

mance degradation can be observed in network services running in the SDN

managed networks if the attacks are launched to the SDN controller. We eval-

uate the impact on these services under the adversarial attacks in the SDN. We

consider the data plane attack and control channel spoofing for the evaluation.

• We develop a light-weight and cost-effective testbed for the cybersecurity ed-

ucation in academic institutions. The testbed uses Open vSwitch (OVS), an

open source software switch that implements the OF for the SDN, as one of the

tools.

1.4 Dissertation Outline

The dissertation chapters are organized as follows:

In Chapter 1, we discussed the motivation for our dissertation work. We reviewed

literature, presented research objectives along with the organization of different chap-

ters.

Chapter 2 provides a detailed overview of the SDN and DL. We briefly cover the

background of the SDN and DL for a better understanding.

In Chapter 3, we implement the attacks from the SDN data plane and the control

channel in different scenarios. Their impact evaluation is measured on the network

services considering the parameters- latency and loss fraction in a client-server envi-

ronment. We also discuss various security threats in the SDN from different perspec-

tives.

In Chapter 4, we implement a DL-based NIDS using the NSL-KDD dataset. We

evaluate the performance of the NIDS for both the training and test datasets using

well-known machine learning parameters. A comparison is also made with the other

machine learning techniques.

Chapter 5 discusses the design and implementation of an NIDS in the SDN based

on SAE. We discuss the implementation of each module, network traffic collection,

testbed setup, and performance evaluation of our NIDS.

Chapter 6 concludes our dissertation and provides insight to overcome the limita-

tions of our work along with the enhancements.

In Appendix A, we discuss the architecture and implementation of a light-weight

testbed that we developed for the network security experiments in an academic set-up.

Chapter 2

Software-Defined Network and

Deep Learning

Software-Defined Network (SDN) targets to mitigate the current issues of traditional

networks that suffer from poor management, security threats, and stagnant innova-

tions due to the increased numbers of users, the emergence of dynamic applications,

and heterogeneous access technologies. On the other hand, the deep learning (DL)

methods address the limitation of traditional machine learning techniques for process-

ing the raw data without extraction of hand-designed features. We profit from the

salient features offered by the SDN and DL in our NIDS implementation. Following

is the discussion of the SDN and DL.

2.1 Software-Defined Network (SDN)

The Internet that we see today grew unexpectedly since its inception. Its initial

design aim was to provide end-to-end connectivity from one network host to other

with an assumption of the presence of naive users; therefore security issues were

not taken seriously. With the passage of time, various security vulnerabilities were

discovered and abused by the adversaries to launch attacks. As security measures,

different mechanisms such as firewalls and access control lists (ACL) have been added

as middle-boxes along with the routers, switches, and bridges. The distributed con-

trol algorithms for different network functions, one of the primary design attributes

towards the Internet success, have become agonizing for the security and manage-

ment of the networks with their increased complexity [7]. Complex protocols run on

different network devices in a distributed manner. Network operators configure them

to implement the network policies. To do so, they need to access the devices using

low-level command-line interfaces (CLI) or network management tools with limited

features. Also, different devices have different management interfaces. Therefore,

network management becomes difficult and erroneous [36]. The devices share a lot of

network topology related information with each other due to the distributed nature

of the control protocols. The sharing of information helps the attackers to discover

the vulnerabilities. The other issue with the current Internet architecture is that it is

ossified. Network devices are vendor-specific with closed system interfaces. Once the

operators deploy them in the production traffic, it becomes hard to make any changes

in them. Therefore, it becomes arduous to develop innovative prototypes swiftly [63].

The SDN came into existence to address the issues mentioned above. Although the

origination came recently from academic research, the SDN became popular in the

networking industries within a few years from its inception.

2.1.1 The SDN Architecture

The main idea in the SDN is the separation of the control and data planes from

the network devices (termed as switches in the SDN), unlike their tight gluing in

the traditional architecture. The control plane is taken out from the switches and

consolidated to a logically centralized controller. The controller has the global view

of the entire managed network. The switches simply act as forwarding elements and

become programmable. They can be programmed for different purposes using the

Figure 2-1: An SDN infrastructure with its decoupled control and data planes along with various network applications

network applications implemented on top of the controller. The SDN offers several

advantages to the network management and research community compared to the

traditional one. The controller in the SDN exports the abstraction of the managed

network to the applications, thus makes the distributed decision problems such as

routing and switching become centralized. The SDN provides simple interfaces to

implement the policies for the efficient network management without the low-level

details of switches. The SDN speeds-up the innovation. A researcher can rapidly

develop a prototype and analyze its impact on a production network without affecting

the production traffic by segregating different traffic using the SDN applications.

Thus, the time span for the transition of a prototype to real-world implementation

reduces significantly. Within a couple of years, the SDN has found many use cases

in the networking world including traffic engineering, mobility, network monitoring,

and data-center networking [38].

As discussed earlier, the control plane and data plane are decoupled from the

switches in the SDN, thus making the switches packet forwarding elements. Figure 2-

1 shows the SDN infrastructure with its decoupled planes and applications. The

switches, end hosts, and their communication together make the data plane. The

controller with the consolidated control plane is either an individual server or group

of logically centralized, but distributed servers. The controller communicates with the

switches using APIs called the southbound interfaces. The OF protocol is one of the

de facto standards for the southbound interfaces [52]. In the case of multiple servers,

the controllers communicate with each other with the east-west bound interfaces.

Network applications running on top of the controller communicate with it using the

northbound interfaces. So far, there has not been any standardization made for the

northbound interfaces.

The controller and switches exchange different control and configuration messages

encapsulated in the OF protocol using either an encrypted or plain TCP communi-

cation channel. These messages are used to set-up the connection of the switches

with the controller, collect the status of the switches or flows, and manage traffic

flows in the network. The switches have multiple flow tables in which flow rules re-

side. These rules have several fields which are as follows. A match field, containing

Layer 2/3 headers, to perform a match against the headers of an incoming packet.

Counters keep track the number of bytes and packets which have arrived at the

switch corresponding to a rule. Actions include forwarding, drop, or headers modifi-

cations. Priority decides the rule precedence to resolve the conflicts among multiple

matches for an incoming packet. A flow in the SDN is defined as a network stream

that contains packets having the same values for certain header fields. The controller

installs rules for the flows based on the policies dictated by the network applications.

Table 2.1 shows an example of a flow table with a few installed rules [64].

Table 2.1: A flow table in a switch with a few installed rules

Match Field Actions Counters

Priority Packets Bytes

tcp,nw dst=10.10.1.5,tp dst=110 1 152 1248 1000

icmp,nw dst=10.10.1.10,icmp type=0 drop 1000 64000 2000

tcp,nw dst=10.10.1.10,tp dst=80 2 355 9424 1000

2.1.2 Flow Installation in the SDN

Figure 2-2: A reactive mode flow rules installation in the SDN [58]

The flow rules are installed in the flow tables of the switches in two ways: proactive

mode or reactive mode [67]. In the proactive mode, the controller installs the rules

inside the tables when a switch joins the network. In contrast, the controller installs

the rules in response to the incoming flows in the reactive mode. The installation of

rules in the later one works as follows. When a packet corresponding to a flow enters

into a switch, the switch looks for a rule that matches with the headers of the incoming

packet inside its flow tables. If a rule exists inside the tables for the flow of the packet,

the switch takes actions corresponding to the rule. If a rule is not available, i.e., a

table-miss event happens, the switch creates a PACKET IN message that encapsulates

the packet headers for the incoming flow and sends it to the controller. The controller

extracts the headers for the incoming flow from the PACKET IN message and sends

either a PACKET OUT or FLOW MOD message to the switches for the flow, based on the

policies of the network applications. The flow rules are installed when the controller

sends FLOW MOD messages. The FLOW MOD message encapsulates different fields of a rule

to be installed for the flow. The switches take actions on subsequent packets of the

flow using the installed rule instead of forwarding them to the controller. Figure 2-2

demonstrates the steps involved in the reactive mode installation of flow rules in the

SDN. The flow rules have a hard or idle timeout to get evicted from the flow tables

to manage the memory size of the tables. The rules are not installed in response to

PACKET OUT messages. The controller instructs the switches to forward the packet

from a single port or multiple ports without installing any rule for the packet.

2.2 Deep Learning (DL)

Machine learning (ML) has been successfully applied to solve the problems which were

hard to formulate mathematically. The machine learning approaches involved to ad-

dress those problems use hand-designed features derived from the raw data and train

themselves over these features. These hand-designed features are provided as inputs

for the classifications or regressions based methods. However, the feature engineering

Figure 2-3: Various steps involved in the traditional ML and DL approaches [25] along with our approach

takes a lot of efforts; needs domain expertise; affects the performance of a system [43].

Deep learning (DL), a new machine learning paradigm and reincarnation of the neural

network, overcomes the issues involved with the feature engineering. It attempts to

learn the features from raw data for their abstract representations in an unsupervised

manner and eliminates the need for the hand-designed features. There have been

different DL approaches used to solve the problems in the domain of computer vision,

image processing, and speech recognition such as SAE, RBM, convolution neural net-

work, and recurrent neural network. These approaches outperform various traditional

machine learning approaches for many of the problems. Figure 2-3 shows different

steps involved in machine learning and DL [25] along with our approach for the NIDS

implementation. We use a hybrid approach in a sense that features are not learned

from the raw traffic. Instead, we have a set of few hand-designed features derived

from the network traffic. After that, we use SAE to extract the optimal features from

those hand-designed features.

2.2.1 Sparse Autoencoder and Stacked Autoencoder

A sparse autoencoder is a neural network model that encodes the input data into an

abstract representation and then decodes the representation to reconstruct the same

input data at the output [60]. A sparse autoencoder is made of three layers having the

M nodes at the input and output layers along with the N nodes at the hidden layer.

The M input nodes represent a record with M attributes, i.e., X = {x1,x2, ...,xm}.

In the training phase, the received output X̂ at the output layer is compared with the

input X to find that whether the hidden layer has performed sufficient decoding. The

sparse autoencoder network, shown in Fig 2-4a, finds the optimal values of the weight

matrices, U ∈ <N×M and U ′ ∈ <M×N , and bias vectors, b1 ∈ <N×1 and b1′ ∈ <M×1

while trying to learn an approximation of the identity function, i.e. X̂ ≈ X during

the training. Eqn. 2.1 represents the cost function used to learn the optimal weight in

the sparse autoencoder. The cost function is minimized using the gradient descent.

Back-propagation algorithm is used to compute the partial derivatives needed for

the gradient descent. The cost function is similar to the one that used in a neural

network except for the third term. The first term in the equation represents the

average of sum-of-square of the differences of all the input values and corresponding

output values for all the r records in the dataset. The second term is a regularization

term with λ as the weight-decay parameter to overcome the over-fitting.

J = 1

r∑ i=1

‖Xi − X̂i‖2︸︷︷︸ First term

+ λ

2 ( ∑ n,m

U2 + ∑ m,n

U ′ 2

+ ∑ n

b1 2 +

∑ n

b1 ′2)

︸︷︷︸ Second term

+ β N∑ j=1

KL(ρ‖ρ̂j)︸︷︷︸ Third term

(2.1)

The final term is a sparsity penalty term used as a constraint on the hidden layer

nodes to maintain low average activation values. It is expressed using Kullback-Leibler

(KL) divergence shown in Eqn. 2.2:

KL(ρ‖ρ̂j) = ρlog ρ

ρ̂j + (1 −ρ)log

1 −ρ 1 − ρ̂j

(2.2)

where ρ ∈ {0, 1} is a sparsity constraint parameter along with β that controls

the sparsity penalty term. The KL(ρ‖ρ̂j) becomes minimum when ρ = ρ̂j, where ρ̂j

represents the average activation value of a hidden unit j over all the training inputs.

Many functions are used for the activation of nodes at different layers such as sig-

moid, hyperbolic tangent, and rectified linear unit (ReLU). We use sigmoid function,

g(z) = 1 1+e−z

, for the activation of gU,b1 shown in Eqn. 2.3:

gU,b1 (X) = g(UX + b1) = 1

1 + e−(UX+b1) (2.3)

The network becomes SAE when multiple sparse autoencoders are stacked with

each other [90]. In the SAE, the outputs of a sparse autoencoder are fed into the

inputs of the next sparse autoencoder. The optimal weight matrices and bias vectors,

for each sparse autoencoder, are achieved using greedy-wise training. For example,

the first hidden layer for the first sparse autoencoder G is trained over the raw input

X to obtain U, U ′, b1, b1 ′. Once it is trained, the layer G = {g1,g2, ...,gn} encodes

the raw input X using U and b1. Then, the encoded values are used as the inputs

for the training of the second sparse autoencoder to obtain the optimal values of the

parameters V , V ′, b2, b2 ′ shown in Figure 2-4b. This process is further carried out

until the last sparse autoencoder is trained and the network becomes the DBN. The

output of the last layer from the last sparse autoencoder, a final representation of the

input, is fed into a classifier. Finally, to improve the performance of the model, all

the layers of the SAE are treated as a single model and fine-tuning is done shown in

Figure 2-4c.

F ig

u re

2 -4

: A

st a ck

ed a u to

en co

d er

(S A

E )

b a se

d d ee

p le

a rn

in g

m o d el

Chapter 3

Attack Impact Evaluation in the

SDN

The fundamental idea of the separation of the control plane and data plane in the SDN

is promising for the convenient management of the future Internet. However, there

are several issues associated with the SDN that need to address for its acceptance as a

whole in the networking industry. Among them, security should be considered at the

earliest. The overemphasize consideration on security is evident from the fact that

in the last few years there has been a notable increase in various system threats and

vulnerabilities. As discussed in the previous chapter, the SDN provides an excellent

platform to develop security and management applications. Researchers utilized this

aspect of the SDN to develop various security frameworks over it. However, the

security of the SDN itself has never been given a detailed attention compared to

the other research work in this area. A few literature have discussed various threat

vectors along with the mitigation in a limited domain.

In contrast to the previous work, we believe that evaluating the impact on the

network services running inside the SDN managed networks under the adversarial

attacks is important. It would be helpful to assess that whether network operators

or service providers able to meet the service level agreements (SLA) for its customers

under the attack situation. Two critical components in any SLA are the availability

of a service to the customers and its responsiveness. In this work, we implement

various attacks specific to the SDN and evaluate their impact on the performance of

network services.

3.1 Security Threats in the SDN

Security challenges in the SDN managed networks are more threatening compared to

the traditional networks. In a traditional network, a few servers of a network portion

become the target of the attacks. Contrary to this, if the adversaries compromise

an SDN control plane, the entire managed network will be threatened. In [4, 39,

79], the authors have discussed various vulnerabilities and threats. For the sake of

completeness, we provide a brief discussion of vulnerabilities and threats in the SDN

from the following aspects before discussing the attack implementation.

3.1.1 The SDN Management Threats

The SDN management includes tasks such as the installation of the controllers,

switches, and network applications along with their administration and trust man-

agement. Although compromising the SDN through its management is challenging

as authentication and authorization are needed, if it is compromised then the effect

on the network would be severe. The SDN managed network can come across with

various security threats through its management. The erroneous network administra-

tion can create a risk of network outage due to the centralized control of the managed

network. An administrator can misconfigure a controller to degrade the performance

of the network [50].

The network applications that run on top of the controller may come from third-

party sources. These applications together with the controller inherit the privileges

for the network behavior manipulation and could be malicious or have security bugs.

An application with security bugs could be exploited for the network or host-based

attacks and may cause information disclosure or arbitrary code execution with the ad-

ministrator privileges [108]. A malicious SDN application can execute various system

commands and terminate the controller instance with the system exit command at

the worst case. It can exclusively use the available system resources such as CPU and

memory, thus let the other applications starve for them. A malicious administrator

can manipulate the system variables and affect the network. For example, changing

the system time may disconnect the switches from a controller if the digital certificate

for authentication is used [1, 77]. Faulty or malicious switches can deter the SDN to

perform intended tasks specified by the network policies.

3.1.2 The Control Plane Threats

The control plane includes the policies of network applications along with the sig-

naling traffic exchanges between the switches and controller for the administration of

managed network. The policy of a network application can contradict the others. The

network may behave unexpectedly due to the lack of the prioritization of the policies.

For example, the set action modifies the flow rules inside the flow tables. Although

it is useful for the applications such as honeypot, quarantine a host, and captive por-

tals, a network application can exploit this action to modify the packet headers to

bypass the firewall policies implemented by other applications. A malicious network

application with a high priority can delete the rules from the flow tables in the worst

case.

According to the OF specification, the channel between the controller and switches

can be implemented using TLS/SSL encryption or plain TCP. It has been surpris-

ingly found that many of the switch vendors and controllers adopted a plain TCP

based implementation to avoid the complexity associated with the encrypted chan-

nel [4]. It is not a concern in a secure infrastructure. However, if the signaling traffic

is carried out over an insecure network, a man-in-the-middle or eavesdrop attacks

can be launched successfully. It can happen in software-defined mobile networks,

campus Wi-Fi networks or while the signaling traffic passes through an adversarial

network. The adversaries can sniff the signaling traffic from the channel to discover

the network topology. They can intercept the control messages containing the flow

rules and modify them to let the network behave unexpectedly. Additionally, they

can overwhelm the flow tables by installing a large number of rules once get access

to the channel [1, 77].

Furthermore, a malicious switch with the spoofed identity of a genuine switch can

disconnect the later one from the network that further causes the disconnection of

all the end hosts associated with the genuine switch and can lead to the disruption

of network traffic from them [15]. A faulty malicious switch can overwhelm the

controller with too many fake PACKET IN requests and limit its availability to handle

the genuine flow requests. Also, the switch and controller exchange echo request and

reply messages to check the connection aliveness between them. A malicious switch

can also exploit these control messages to overwhelm the channel.

3.1.3 The Data Plane Threats

The end hosts, flow tables inside the switches, and traffic passing through them

together make the data plane. As mentioned in the previous chapter, if a flow table-

miss event happens for a packet, the packet is forwarded to the controller for a

rule installation in the switch or the actions that need to be taken for the packet.

Therefore, the response time for the first packet in a flow is longer, in general, than the

response time of subsequent packets of the same flow. This particular characteristic

of an SDN helps the adversaries to fingerprint the SDN from the data plane [84].

It enables the adversaries to discover the flows for which the controller does not

install rules in the flow tables; instead, it sends PACKET OUT messages to handle them

in response to the PACKET IN messages sent by the switches corresponding to the

flow. The adversaries can send these flows to overwhelm the controller and keeps the

controller busy in handling them.

The packets in the adversarial flows occupy the memory buffer of a switch as

well until they get responses from the controller, thus lead to the degradation of the

network performance. The number of packets that a switch can store in its buffer

during the PACKET IN event is limited and negotiated when a switch connects with

the controller. When a switch has enough memory to buffer the packets, it sends

a PACKET IN message with a small fraction of packet header along with the buffer

identity. In response to the PACKET IN message, the controller sends a FLOW MOD or

PACKET OUT message using the buffer identifier in the received PACKET IN message.

Once the switch receives a message from the controller, it removes the packet from

the buffer whose buffer identifier matches with the one specified in the message. In

this way, the control channel carries a less amount of traffic for the PACKET IN and its

response messages. However, when the switches run out of their memory buffer due

to a large number of fake PACKET IN requests from the adversaries, they start to send

the complete packet in the PACKET IN message and also receive the entire packet with

the response message from the controller. Therefore, the channel gets overwhelmed

with a large amount of traffic compared to the previous case [64].

3.2 Attack Implementation and Impact Analysis

For our attack analysis, we implement those attacks for which the adversaries do not

require any authentication to access the SDN system. In this context, we choose the

data plane attack and control channel spoofing. In the first case, the adversaries send

fake requests from the data plane to keep the controller and switches busy to handle

Figure 3-1: Data plane attack implemented for the performance analysis of network services.

them and cause delay and loss in flow rule set-up for the legitimate traffic. In the

second case, a malicious switch spoofs the identity of a genuine switch and discon-

nects the later one from the controller. We evaluate the impact of these attacks on

the connection set-up latency and loss of client requests to the web servers. With

the growing e-commerce, the network operators must meet the SLA to their web cus-

tomers. The availability of web services and response-time are two important metrics

in any SLA. We calculate these metrics by measuring the loss of client requests and

connection setup latency. In the following subsections, we discuss the implementation

of these attacks and their impact on web services.

3.2.1 The Data Plane Attack

We implement the data plane attack shown in Figure 3-1 using the POX controller and

an SDN emulator known as Mininet. Mininet emulates the network hosts, switches,

and links between them. It implements the virtual networks using the Linux features

including network namespace and process virtualization. It uses a bash process to

emulate a virtual host and assign the virtual network interfaces to it using network

namespaces. The virtual hosts can emulate all the network functions and run various

network services independent of other virtual hosts [42]. The OF-based switches are

implemented using Open vSwitch [66]. The switches are connected to a controller

that runs on the same host or a remote host. We can create a virtual network with

as many virtual hosts and switches as needed in a single host using Mininet. Mininet

provides command line launcher to instantiate a virtual network along with a simple

Python-based API to create virtual networks of varying sizes [54]. Although Mininet

has some performance related issues while emulating a large virtual network as it is

essentially developed for the rapid-prototyping of the SDN applications, we can get

an insight of the attack impact on the network services in different scenarios.

Table 3.1: Link speed and delay for different links in the experiments

Link Type Link Speed Latency

Controller-to-Switch 10 Mbps 1 ms Switch-to-Switch 10 Mbps 1 ms Host-to-Switch 1 Mbps 1 ms

POX is an open source Python-based controller that provides a platform for rapid

development of the SDN applications. The network applications in POX are written

as components which are Python modules. There are other components available as

well which are used for tasks such as logging, debugging, and interfaces to interact

with external processes. Each component, in general, has a launch function which

POX uses for initializing the component. POX has a “core” object which serves

as central point for the components. The components register themselves with the

“core” object. In this way, they query the “core” object for the other components if

any dependency arises and the need for hard-coded import of components is elimi-

nated [71].

We modified an available component in the POX for self-learning Ethernet switch

to carry out our attack experiments. The modified component installs the flow rules

for the web-based traffic only using FLOW MOD messages. For any other traffic, it

generates PACKET OUT event to forward the packets from specific ports of the switches

without installing rules. The idle timeout for a flow rule is set to 15s. An installed rule

will evict from the flow tables if the switch does not receive any packet that matches

the rule within this timeout period. A web client sends a request to the web server at

a regular interval as a legitimate traffic. We evaluate the attack impact in two cases.

In the first case, the interval between each request is set less than the timeout period

of the installed rule. For the second case, the interval is set longer than the timeout

period. We use curl utility to automate the client requests. Curl is an open source

command-line tool that supports various protocols used for data transfer over the

network [10]. We can set a maximum time limit, i.e. connection timeout, in it until

which it attempts to connect a server. If it does not connect in that time, it returns

as a failure. We set the connection timeout to 60s. A connection is considered as lost

after the timeout. We can get the response time for the completion of a request in

curl as well.

We carried out our experiments on virtual machines (VMs) created using a VMware

ESXi host [104]. The host runs on a Dell PowerEdge 2950 server equipped with Intel

Xeon CPU E5420 @ 2.50 GHz, 16GB RAM, and eight CPU cores. We ran the same

attack experiments on four VMs. Each VM was configured with 4GB RAM and four

core CPUs. We took the average of all runs for the final results. We ran the con-

troller with the modified component. The virtual hosts were created for web services

Figure 3-2: Average connection setup latency when all the web hosts and adversaries reside in the same network.

and adversaries. The virtual hosts were connected with two switches which in turn

were connected to the controller. The virtual hosts and switches were created using

Mininet. The link speed and delay between the controller-to-switch, switch-to-switch,

and host-to-switch are listed in Table 3.1. We connected 10 web-based client-server

pairs with the switches to get a good estimation of the attack impact. The clients

send 20 requests to their corresponding servers after a fixed interval using curl. Ping

flood was considered as an adversarial attack. The adversarial hosts were considered

as a part of the managed network and located in a distributed manner to mimic the

botnets. The attacker host sends ping packets to its peer host in the network. We

varied the frequency of ping packets during the experiments and studied the impact

on web services.

We consider four attack scenarios based on the locations of the client-server (web

hosts) and adversaries. These scenarios are as follows.

Figure 3-3: Average loss fraction when all the web hosts and adversaries reside in the same network.

3.2.1.1 Web hosts and adversaries reside in the same network

In this case, all the web hosts and adversaries reside in the same network. We observe

from Figure 3-2 that the connection set-up latency is quite high when the client

requests are sent after the timeout period of the flow rules compared to when they

are sent before the timeout period. In the first case, the connection set-up latency

went up to 22s when the attack frequency reached to 14Kps (thousands per second),

whereas in the second case it went up to 3s. The fraction of lost requests increases

with the growth of attack rates in both the cases shown in Figure 3-3. However, it

is higher in the first case compared to the second case and reached up to 98%. The

reason for the high loss rate even when the requests are generated before flow rules

expiration is due to the large number of ping flooding packets from the adversaries

that cause a running out of memory buffer in the switch for queuing the incoming

packets for the legitimate traffic.

Figure 3-4: Average connection setup latency when the web hosts reside in one network and the adversaries reside in a different network.

Figure 3-5: Average loss fraction when the web hosts reside in one network and the adversaries reside in a different network.

3.2.1.2 Web hosts reside in one network and adversaries reside in the

other network

In this experimental topology, we connected the web hosts with one switch and the

adversarial hosts with the other switch, respectively. It is evident from Figure 3-4 and

Figure 3-5 that the attack impact is very less. We observed that the connection set-up

latency is desirable low shown in Figure 3-4. The latency went up to 0.11s and 0.06s

for the requests generated after and before the flow rules expiration, respectively.

From Figure 3-5, we observe that loss remains around 5% for most of the time even

the attack frequencies increase in both the cases. The reason for less impact can be

attributed because only the communication link between the controller and switch of

the adversarial side network is affected in the attack. The flow tables and memory

buffers for queuing the incoming packets in the switch associated with the web hosts

along with the communication link from the same switch to the controller were not

overwhelmed with the unwanted PACKET IN requests of ping floods.

3.2.1.3 Web hosts reside in one network and adversaries reside in the

network of web hosts and another network as well

In this scenario, web hosts reside in one network and adversaries are distributed over

different networks. In our experimental topology, web hosts are associated with one

switch while adversaries are associated with both the switches. We observed from

Figure 3-6 and Figure 3-7 that the results for this scenario are similar to the first one,

although adversaries are distributed in this scenario.

3.2.1.4 Web hosts and adversaries are distributed in different networks

In this case, web hosts and adversaries are distributed in different networks. In our

experimental topology, The clients were associated with one switch and servers were

associated with the other switch. The adversaries were associated with both the

Figure 3-6: Average connection setup latency when the web hosts reside in one network and the adversaries reside in the network of web hosts and another network as well.

Figure 3-7: Average loss fraction when the web hosts reside in one network and the adversaries reside in the network of web hosts and an- other network as well.

Figure 3-8: Average connection setup latency when the web hosts and ad- versaries are distributed in different networks.

Figure 3-9: Average loss fraction when the web hosts and adversaries are distributed in different networks.

Figure 3-10: Control plane attack with the spoofed switch identity imple- mented for the performance analysis of network services.

switches. The attack impact in this scenario is the most severe of all. This attack

consumes the controller resources, overflows memory buffer and the flow tables of the

switches; and overwhelms all the communication links. We observe from Figure 3-8

that the connection set-up latency increased up to 52s even when the requests are

sent before the flow rules expiration which gives a notion that there is a drop in the

genuine traffic at the switches due to a large number of adversarial packets. The

connection loss fraction reached to almost 100% when the attack rate reached to

6Kps in the case when the requests are sent after the flow rules expiration shown in

Figure 3-9.

3.2.2 Control Channel Spoofing

In this attack, we exploit the vulnerability of the spoofing of a switch identity observed

in [15]. The adversaries can sniff information about a switch in the network if the

control channel between the controller and switch is implemented using the plain

TCP. They can use this information to spoof the identity of a genuine switch in the

SDN network. To implement this attack, we ran an OF-based OVS in a Linux host to

use it as a genuine switch and connected this host with the POX controller in a remote

host. We used the same modified component as we used in the data plane attack with

the timeout period of 30s. We created 20 virtual hosts using the network namespace

and connected them with the switch. These virtual hosts were used as the client-

server pairs for the web services. We performed the same connection set-up latency

and loss experiments as we did for the data plane attack. We ran another OF-based

switch to function it as a malicious switch on a different host. We assigned the same

IP address of the genuine switch to the malicious switch. When the genuine switch

is connected to the controller, we establish a connection of the malicious switch with

the controller. The established connection disconnects the genuine switch from the

controller and connects the malicious switch with the controller. The genuine switch

then attempts to connect with the controller and disconnects the malicious switch.

This process repeats alternatively, therefore the end devices that were associated

with the genuine switch suffer a connection loss in the network. We automated the

connection attempt of the malicious switch with the controller at a fixed interval

varying from 2s to 22s. The genuine switch automatically attempts to connect with

the controller once it is disconnected. The clients send requests before the flow rules

expiration in one case, while in the second case requests are sent after the expiration

of the rules. Figure 3-11 and 3-12 show the result for the connection set-up latency

and loss fraction for all the clients. We did not observe any specific pattern for the

Figure 3-11: Average connection setup latency with varying spoofing interval of the malicious switch

connection set-up latency. However, the latency is high compared to the case when

there is no spoofing. The effect on the loss fraction is significant in this attack. We

observed that the loss rate for the client connection is high when the interval for the

connection of the malicious switch is short. The loss rate went up to 98%. It is due

to the fact that connection-disconnection of a malicious switch within a short interval

restricts the genuine switch to connect the controller for most of the time. With the

increase in spoofing interval, the loss fraction decreased.

This attack would be easier to launch in comparison to the data plane attack.

However, the control channel must be plain so that the adversaries can sniff the con-

trol messages from the switch to the controller and vice-versa. In the data plane

attack, the adversaries have to find out the flows for which the controller does not

install any flow rules inside the flow tables. On the other hand, this attack needs only

the information about the IP addresses of the switches and the controller. The per-

formance of network services would be remarkably degraded by spoofing the identity

Figure 3-12: Average loss fraction with varying spoofing interval of the ma- licious switch

of a few switches.

3.3 Chapter Summary

We evaluated the impact on the performance of network services running over the

SDN under adversarial attacks and the results were published in [62]. The impact

evaluation of various attacks gives an insight of the risk analysis of them and enables

the calculation of the common vulnerability scoring system (CVSS) corresponding

to these attacks. We observed that the performance of web services, considering the

response time and availability, degrades significantly in the presence of attacks. The

adverse impact on the response time and availability poses threats to the operators

to maintain the promised SLA to their customers. Although we implemented the

attacks based on certain assumptions, many organizations fail to impose the security

policies in their networks; thus these assumptions become valid [12]. The SDN is

promising and revolutionizes the network industry and research. However, we need

to devise solutions to overcome the security threats in it for its full acceptance.

Chapter 4

Deep Learning based NIDS for the

NSL-KDD

The publicly available benchmark datasets enable the researchers to develop the sys-

tems or models and compare the performances of the models with the others to

process the data which are similar to the benchmark datasets. The NSL-KDD [95]

is one of the most popular datasets for the network security practitioners to develop

and evaluate an NIDS. It is derived from the famous KDD Cup 99 [35] dataset to

overcome a few of its significant limitations. In this work, we develop an intrusion

detection for the NSL-KDD dataset using a deep learning approach, i.e. self-taught

learning (STL) [72]. We present an overview of the KDD Cup 99 and NSL-KDD

datasets before discussing the NIDS implementation.

4.1 Dataset Overview

The KDD Cup 99 dataset was prepared by [91] using the captured network traffic

under 1998 DARPA IDS evaluation program [46] developed and managed by the MIT

Lincoln Labs. The network traffic was captured in a local area network (LAN) that

simulated a US Air Force base real network for the normal traffic. Different attacks

were simulated in the same LAN to collect the anomalous traffic ranging from well-

known to undiscovered attacks. The network traffic was collected for nine weeks using

tcpdump [96]. The first seven weeks traffic were used as the training data for an IDS

development and the following two weeks traffic were used as the test data for the

evaluation of an IDS developed using the training data. The distribution of the test

data is different from the training data. The test data comprises few attacks which

were not simulated during the traffic collection for the training data, to make the

detection task realistic. However, researchers believe that most of the novel attacks

can be derived from the signature of well-known attacks. The traffic for the training

and test data consist of 4GB and 2GB raw tcpdump data. In the KDD Cup 99, this

raw traffic was processed into five million and two million TCP/IP connection records

for the training and test purposes.

4.1.1 The NSL-KDD Dataset

The KDD Cup 99 dataset has been remarkably used as a benchmark dataset for many

years in the NIDS development and evaluation. The drawback found in this dataset

is that it has a large number of redundant records in the training and test data. It

was observed that the training and test data have almost 78% and 75% redundant

records respectively. The NIDSs developed on this dataset become bias towards the

classification of frequently found attack records and produce poor classification results

for the less frequent, but harmful records due to this redundancy. It has been found

that most of the machine learning based NIDS were successfully able to classify the

training and test data with the least accuracy of 98% and 86% respectively. In this

case, the comparison and evaluation of different NIDSs become difficult as all of them

produce an excellent result on this dataset. The NSL-KDD came into existence to

overcome the limitations of the KDD Cup 99 dataset. This dataset is derived from

the KDD Cup 99 dataset. Following approaches were taken in the NSL-KDD dataset

Table 4.1: Continuous features and their types in the KDD Cup 99 and NSL- KDD datasets [35]

Feature Type Feature Type

duration basic count traffic src bytes basic srv count traffic dst bytes basic serror rate traffic wrong fragment basic srv serror rate traffic urgent basic rerror rate traffic hot content srv rerror rate traffic num failed logins content same srv rate traffic num compromised content diff srv rate traffic root shell content srv diff host rate traffic su attempted content dst host count traffic num root content dst host srv count traffic num file creations content dst host same srv rate traffic num shells content dst host diff srv rate traffic num access files content dst host same src port rate traffic num outbound cmds content dst host srv diff host rate traffic dst host serror rate traffic dst host srv serror rate traffic dst host rerror rate traffic dst host srv rerror rate traffic

to improve the KDD Cup 99 dataset. Firstly, all the redundant records from the

training and test data in the KDD Cup 99 dataset were removed. Secondly, all the

remaining distinct records in the KDD Cup 99 dataset were partitioned into 21 sets

based on the number of learning algorithms that can classify the records correctly.

A record was kept in a set whose number was equal to the number of classifiers that

accurately classified the record. The records were sampled from each set in a fraction

that is inversely proportional to the fraction of records in that set over the total

records in all the sets. This multi-steps processing of the KDD Cup dataset made

the number of records in the NSL-KDD dataset reasonable for the training of various

machine learning techniques [95].

Each record in the NSL-KDD dataset has 41 features including three nominal,

four binary, and 34 continuous features along with a label for normal or particular

kind of attack. These features are categorized into three different types:

Table 4.2: Nominal and binary features in the KDD Cup 99 and NSL-KDD datasets [35] along with their types and 1-to-n encoding

Feature Type 1-to-n encoding

protocol type basic 3 service basic 70 flag basic 11 land basic 1 logged in content 1 hline is host login content 1 is guest login content 1

Table 4.3: Attack types and different attacks in each type in the NSL-KDD dataset [95]

Attack type Different attacks

Denial-of-Service back, land, neptune, pod, smurf, teardrop, apache2, mailbomb, processtable, udpstorm

User-to-root buffer overflow, loadmodule, perl, rootkit, ps, sqlattack, xterm

Root-to-local ftp write, guess passwd, imap, multihop, phf, spy, warezclient, warezmaster, httptunnel, named, sendmail, worm, xlock, xsnoop, snmpgetattack, snmpguess

Probe ipsweep, nmap, portsweep, satan, mscan, saint

• Basic features are derived directly from a TCP/IP connection

• Traffic features are accumulated in a time interval, e.g. two seconds, for the

same host or service

• Content features are extracted from the application layer data of a connection

Table 4.1 shows the continuous features in the dataset with their types. Nominal and

binary features are shown in Table 4.2 along with their types and number of derived

features from them after 1-to-n encoding.

There are four different kinds of attacks found in the dataset including the DDoS,

User-to-Root (U2R), Root-to-Local (R2L), and Probing. The DDoS attacks are used

to overwhelm the system resources of the hosts with unsolicited requests so that they

Table 4.4: Distribution of records in the NSL-KDD dataset [95].

Traffic Training Test

Normal 67343 9711

Attack

DoS 45927 7458 U2R 52 67 R2L 995 2887

Probe 11656 2421

cannot process the legitimate requests. In the U2R attack, a non-root user exploits

the system vulnerabilities to gain access as a root user and harm the system. The

attackers exploit the system vulnerabilities to gain access to a host from remote in

an R2L attack. Probing is used to discover the network information such as services

and topology that helps in launching an attack. Table 4.3 shows different attacks in

each category. The training data contains 23 traffic classes including 22 attacks and

one normal class. The test data has 38 traffic classes including 21 attacks similar to

what found in the training data, 16 new attacks, and one normal class. These all

attacks fall into four categories as discussed above. Table-4.4 shows the distribution

of records in the training and test data for the normal and different attacks traffic.

4.2 Results and Discussion

There are two approaches used in the NIDSs evaluation developed for the NSL-KDD

dataset. In the most common approach, the training data is utilized for both the train-

ing and evaluation. The evaluation is either performed using n-fold cross-validation

or the training data is split into training, cross-validation, and test datasets. The

NIDSs developed with this approach achieved high accuracy and low false alarms.

The second approach uses the training and test datasets separately for the training

and test purposes. Since the training and test data come from different distributions,

the accuracy achieved in this approach is not as good as in the first approach. There-

fore, we emphasize on the results of the second approach in our work for the realistic

Figure 4-1: Self-taught learning implementation

evaluation of the NIDS. However, for the sake of completeness, the results for the

first approach were presented as well. Following is the implementation of the NIDS

before discussing the results.

4.2.1 The NIDS Implementation

The NSL-KDD dataset contains different types of features with different values men-

tioned in the previous section. It is important to pre-process the dataset before using

it for the inputs in the self-taught learning shown in Figure 4-1. 1-to-n encoding is

used to transform the nominal features into discrete features. We found a feature in

the dataset whose value remains 0 for all the available records in the training and

test data. The feature was removed from the dataset as its constant value in all the

records makes it insignificant. The number of features becomes 121 after performing

the steps mentioned above. The values at the output layer during the feature learning

phase shown in Figure 4-1(a) is computed with the Sigmoid function that generates

Figure 4-2: Various steps involved in the NIDS implementation

values ranging from 0 to 1. The output layer values are made an approximation to the

input layer values in this phase. Therefore, we normalize the values of the features

at the input layer in a range of 0 to 1 using max-min normalization.

We use the transformed NSL-KDD training data without the labels for the unsu-

pervised feature learning using sparse autoencoder in the first stage of the self-taught

learning. In the second stage, we convert the training data into the new features

using the parameters obtained in the first stage. These new features are passed to

the softmax regression (SMR) for classification. In our implementation, we used the

same data source, i.e., NSL-KDD training data as the unlabeled and labeled data for

the feature learning and classifier training respectively. Figure 4-2 shows the steps

involved in our NIDS implementation.

4.2.2 Accuracy Metrics

Following metrics are used for the performance evaluation of the classifiers:

• Accuracy: It is defined as the % ratio of correctly classified records over the

total number of records in the dataset.

• Precision (P): It is defined as % ratio of accurately predicted records over all the

predicted records and calculated as the % ratio of the number of true positives

(TP) over the sum of true positives (TP) and false positives (FP) for classified

records.

P = TP

(TP + FP) × 100% (4.1)

• Recall (R): It is defined as % ratio of accurately predicted records over all the

available records for a particular class in the dataset and calculated as the %

ratio of number of true positives (TP) over the sum of true positives (TP) and

false negatives (FN) for classified records.

R = TP

(TP + FN) × 100% (4.2)

• F-measure (F): It gives a holistic evaluation of a model for precision and recall.

It is calculated as the harmonic mean of precision and recall.

F = 2 ×P ×R (P + R)

(4.3)

4.2.3 Performance Evaluation

The NIDS was developed for three different types of classification based on the cat-

egorization of attacks. In the first type, each record is classified as one of the two

classes (2-class) either normal or anomalous considering all the attacks as anomalous.

Figure 4-3: Classification accuracy achieved for 2-class, 5-class, and 23-class on the training data using the STL and SMR

Figure 4-4: Precision, recall, and f-measure values achieved for 2-class on the training data using the STL and SMR

In the second type, each record is classified as one of the five classes (5-class) includ-

ing the normal and four different types of attack by identifying the attack with its

attack type. In the final type, each record is classified as one of the 23-class includ-

ing normal or one of the 22 attacks available in the training dataset. We measured

the precision, recall, and f-measure values for the attacks in the case of 2-class and

5-class classification in the test dataset evaluation. For the 5-class classification, we

computed the weighted values of these metrics.

4.2.3.1 Evaluation based on the Training data

We evaluated the classification accuracy of self-taught learning (STL) on the training

data using 10-fold cross-validation for 2-class, 5-class, and 23-class. We compared

the performance of the STL with the softmax regression (SMR) that applied to the

dataset without any feature learning. We found that the STL achieved better perfor-

mance for 2-class classification compared to the SMR shown in Figure 4-3. However,

the performances of the STL and SMR are very similar for 5-class and 23-class clas-

sification. We noticed the figure that the STL achieved more than 98% classification

accuracy for all types of classification.

We evaluated the precision, recall, and f-measure values for 2-class classification

in the training dataset evaluation. While evaluating the NIDS using 10-fold cross-

validation, a few types of attack records would either miss in the training or evaluation

phase of 5-class and 23-class classification. Therefore, we considered these metrics for

2-class classification. We found that the STL achieved better results for all these

metrics compared to the SMR. The STL achieved a value of 98.84% for f-measure,

whereas the SMR achieved 96.79% shown in Figure 4-4. We found that the STL shows

a comparable performance with many of the best results obtained in the previous work

when evaluated using the training data.

Figure 4-5: Classification accuracy achieved for 2-class and 5-class on the test data using the STL and SMR

Figure 4-6: Precision, recall, and f-measure values achieved for 2-class on the test data using the STL and SMR

Figure 4-7: Precision, recall, and f-measure values achieved for 5-class on the test data using the STL and SMR

4.2.3.2 Evaluation based on the Training and Test Data

The performance of the STL is evaluated for 2-class and 5-class using the test dataset.

We observed that the STL performs better compared to the SMR shown in Figure 4-5.

The STL achieved a value of 88.39% for accuracy, whereas the SMR achieved 78.06%

for 2-class classification. The accuracy obtained with the STL for 2-class classification

exceeds many of the previous results. The best accuracy rate reported in [95] was

82% with NB-Tree. The STL achieved a value of 79.10% for accuracy, whereas the

SMR achieved 75.23% for 5-class classification.

Figure 4-6 and 4-7 demonstrate the precision, recall, and f-measure values for 2-

class and 5-class classification. The precision achieved in the STL is lesser compared

to the SMR for 2-class classification. The values of precision for the STL and SMR

are 85.44% and 96.56%, respectively. However, the STL achieved better values for the

recall compared to the SMR. The values of the recall for the STL and SMR are 95.95%

and 63.73%, respectively. The STL exceeded SMR for the f-measure value due to a

high value of the recall. The STL obtained a value of 90.4% for f-measure, whereas the

SMR obtained 76.8%. We observed similar patterns for 5-class classification shown

in Figure 4-7. The values of f-measure for the STL and SMR are 75.76% and 72.14%,

respectively.

4.3 Chapter Summary

We developed a deep learning based NIDS using sparse autoencoder for the feature

learning and softmax regression as a classifier. The results were published in [30]

and [31]. The NSL-KDD dataset, a benchmark network intrusion dataset, was used

for the development of the NIDS. We observed that the developed NIDS performed

well compared to many of the previously implemented NIDSs for network intrusion

detection when evaluated over the test dataset.

Chapter 5

Deep Learning based NIDS in the

SDN

Attacks in an SDN environment can take place either on the data plane or control

plane. The data plane attacks are quite similar to the attacks that happen in a

traditional network targeted to a network segment or a few hosts. In contrast, the

entire managed network traffic can be disrupted if an attack occurs on the control

plane of the SDN. One of the approaches used in the control plane attacks is to

discover the traffic flows for which the controller processes all the packets of the flows

without installing any rules inside the flow tables of the switches. Once discovered

then generate packets for those flows in the network. The system resources at the

controller and switches are heavily consumed to process those packets and buffering

them respectively. We evaluated the impact of adversarial attacks in the SDN on the

network services running in the managed network in Chapter 3. In this chapter, we

discuss the implementation of a DL-based NIDS as a network application in the SDN

to detect multi-vector DDoS attacks for both the planes.

5.1 DDoS Attacks in a Network

There are various kinds of DDoS attacks that the adversaries can launch in a network

including volumetric, protocol, and application layers [13, 109]. The victim hosts

or networks are inundated with the unwanted traffic in a volumetric attack. The

attack traffic consumes a significant amount of network bandwidth and throttles the

communication between the victim and legitimate hosts from the outside networks.

The distributed attackers or bots use UDP and ICMP ping floods to launch direct

or reflected DDoS attacks shown in Figure 5-1. In the direct DDoS attacks, the

attackers send traffic directly to the victims with the spoofed IPs. On the other

hand, the attackers send traffic in the form of queries to a large number of open

public servers by spoofing the identity of victim hosts in the reflected DDoS attacks.

The public servers overwhelm the victims with a large volume of traffic generated in

response to the requests. The attack impact becomes worse in the case of DNS and

NTP amplification in which the response messages have 100 times larger payloads

than the queries. In protocol based DDoS attacks, system resources are exhausted in

addition to the consumption of link bandwidth. For example, the attackers overwhelm

the connection queue of a TCP based server by half-open incomplete connections and

make it unable to accept new connections from the legitimate clients in a TCP SYN

flood attack. Application-based attacks target the application layer protocols such

as HTTP and HTTPS. These attacks are launched at a low rate, and they look like

normal traffic from the network and transport layer perspectives. The attack scenarios

have also changed nowadays where attacks have been launched in a combination of

two or more kinds of DDoS attacks, thus making the detection task challenging and

difficult.

Figure 5-1: Different techniques for launching a DDoS attack

5.2 Implementation of the NIDS

In our NIDS, we detect the DDoS attacks from the network and transport layer per-

spectives and the implementation is based on the assumption that attackers spoof

their IP addresses while launching attacks to escape from the traceback. The imple-

mented NIDS shown in Figure 5-2 has three components which are as follows:

• Traffic Collector and Flow installer (TCFI)

• Feature Extractor (FE)

• Traffic Classifier (TC)

In our implementation, we perform packet-based flow computation for attack de-

tection, instead of sampling the traffic flows using tools such as netflow [59] and

sFlow [80], to minimize the false alarms. Detailed descriptions of each component

are as follows:

Figure 5-2: An NIDS with its components implemented in the SDN to detect DDoS attacks

5.2.1 Traffic Collector and Flow Installer (TCFI)

The TCFI module executes in parallel with the FE and TC modules which are invoked

by a timer function. We have two different implementations of the TCFI module. In

one implementation, the controller instructs the switches to forward all the packets

they receive from the network to it. On the other hand, the second one instructs

the switches to forward a limited number of flows and packets. In this section, we

discuss the previous implementation. The next one will be discussed with a few public

datasets analysis and performance comparison with the former one in Section 5.4.

The TCFI module inspects the type and code of the OF message extracted from a

received PACKET IN packet at the controller. The message type and code describe

the reason for the arrival of a packet. A packet can arrive at the controller from

a switch due to a flow table-miss event in its flow tables or forwarding by a flow

rule to the port associated with the controller and the destined physical ports. The

TCFI extracts various network and transport layer headers from a packet to identify

the flow to which it belongs. A flow is defined as a stream of packets having same

values of protocol type, source and destination IP addresses along with the source and

destination port numbers in the TCP or UDP traffic. An ICMP flow is similar to the

TCP or UDP flow except the fact that it has ICMP message type and code instead

of port numbers. The TCFI module extracts a few more packet headers used by the

FE module to extract the features from traffic flows. All these extracted headers are

stored in a packet list for every incoming packet at the controller. Table 5.1 shows

different packet headers extracted by the TCFI for the TCP, UDP, and ICMP traffic.

Algorithm 1: Traffic classifier and Flow Installer Module (TCFI)

Data: Incoming packets at the controller Result: List of extracted headers for TCP, UDP, and ICMP begin

packets list ←− [ ] flows list ←− [ ] while timer for FE is not triggered do

receive packet from switch store headers in packets list if packet arrives due to flow table-miss then

compute flow for packet compute symmetric flow, symflow, for flow if symflow ∈ flows list then

remove symflow from flows list install flow rule for symflow in switch(es) install flow rule for flow in switch(es)

else if flow /∈ flows list then add flow in flows list

output packet to desired port

The TCFI performs the task mentioned above when a packet arrives at the con-

troller due to forwarding by a flow rule already installed in the flow tables. Following

additional tasks are performed when a packet comes due to a flow table-miss event

in a switch. First, the TCFI looks for a symmetric flow corresponding to the flow

of the arrived packet in a flow list. This flow list is populated by the TCFI with all

Table 5.1: Different headers extracted from the TCP, UDP, and ICMP pack- ets

TCP UDP ICMP

Src IP Window Src IP Src IP Dst IP SYN Dst IP Dst IP Src Port ACK Src Port ICMP Type Dst Port URG Dst Port ICMP Code Protocol FIN Protocol Protocol Data Size RST Data Size Data Size TTL PUSH TTL TTL

the unique flows reach the network during a particular time window. The TCP or

UDP based flows are defined as symmetric flows if they belong to the same protocol

along with the source IP address and port number in one flow have the same val-

ues as that of the destination IP and port number of the other flow and vice-versa.

The request and response type flows become symmetric if they occur in a particular

interval for ICMP based traffic. If a symmetric flow is found for the incoming flow,

then the TCFI module removes the symmetric one from the flow list and installs two

flow rules one for the incoming flow and the other for the symmetric flow inside the

flow tables along with forwarding of the current packet using PACKET OUT message.

The subsequent packets of those flows are forwarded to the controller and destined

physical ports by the installed rules. The installation of the flow rules only for the

symmetric flows is based on the assumption that attackers usually spoof their IP

addresses to avoid traceback and response traffic from the victims. Therefore, the

attack traffic is mostly asymmetric. The flow rules are installed for the symmetric

flows only to avoid any flow table saturation due to these asymmetric flows. If a

symmetric flow is not found for the incoming packet, the TCFI inspects the flow list

to find that whether the flow for the incoming packet exists in the flow list. If the flow

is found, the TCFI forwards the packet from the switches using PACKET OUT without

installing any rules for it. Otherwise, the flow for the packet is added to the flow

list, and then the packet is forwarded as in the previous case. Algorithm 1 shows the

implementation of the TCFI. The TCFI algorithm is different from the maximum

entropy detector algorithm found in [53] in following ways:

• All kinds of flows are evaluated instead of a few particular flags based flows.

• The controller receives a packet either due to a flow table-miss event or for-

warding by a flow rule installed in a switch by the TCFI.

• Packet headers are stored in the packet list for every packet arrives at the

controller.

5.2.2 Feature Extractor (FE) and Traffic Classifier (TC)

The FE module is invoked by the NIDS using a timer function. The FE reads the

packet headers from the packet list which was populated by the TCFI. Features are

extracted from the headers for a particular time window. The FE resets the packet

list and flow list to store the headers and flows for the next time window. The list of

68 features extracted by the FE module for the TCP, UDP, and ICMP are shown in

Table 5.2, 5.3, and 5.4. The FE extracts 34, 20, and 14 features for the TCP, UDP,

and ICMP traffic respectively. These features were derived after a detailed literature

survey and reduced to an optimal feature set by the SAE-based DL approach, for

classification. Algorithm 2 shows the brief implementation of the FE specific to the

ICMP flows. The FE extracts these features for all the hosts in the network which has

incoming traffic for the observed time window. Although our computation considers

all the packets viewed at the controller, features are extracted by grouping them in

TCP, UDP, or ICMP flows. The FE calculates median for some of the features such

as the number of packets and bytes in a flow mentioned in feature # 9-12, 43-46, and

63-67. It calculates the entropy, H(F), for features mentioned in feature # 8, 14, 16,

Table 5.2: Features extracted by the FE for the TCP flows

# Feature Description

1 # of incoming TCP flows 2 Ratio of TCP flows over total incoming flows 3 # of outgoing TCP flows 4 Ratio of TCP flows over total outgoing flows 5 Ratio of symmetric incoming TCP flows 6 Ratio of asymmetric incoming TCP flows 7 # of distinct src IP for incoming TCP flows 8 Entropy of src IP for incoming TCP flows 9 Bytes per incoming TCP flow 10 Bytes per outgoing TCP flow 11 # of packets per incoming TCP flow 12 # of packets per outgoing TCP flow 13 # of distinct window size for incoming TCP flows 14 Entropy of window size for incoming TCP flows 15 # of distinct TTL values for incoming TCP flows 16 Entropy of TTL values for incoming TCP flows 17 # of distinct src ports for incoming TCP flows 18 Entropy of src port for incoming TCP flows 19 # of distinct dst ports for incoming TCP flows 20 Entropy of dst ports for incoming TCP flows 21 Ratio of dst ports ≤ 1024 for incoming TCP flows 22 Ratio of dst port > 1024 for incoming TCP flows 23 Ratio of TCP incoming flows with SYN flag set 24 Ratio of TCP outgoing flows with SYN flag set 25 Ratio of TCP incoming flows with ACK flag set 26 Ratio of TCP outgoing flows with ACK flag set 27 Ratio of TCP incoming flows with URG flag set 28 Ratio of TCP outgoing flows with URG flag set 29 Ratio of TCP incoming flows with FIN flag set 30 Ratio of TCP outgoing flows with FIN flag set 31 Ratio of TCP incoming flows with RST flag set 32 Ratio of TCP outgoing flows with RST flag set 33 Ratio of TCP incoming flows with PUSH flag set 34 Ratio of TCP outgoing flows with PUSH flag set

Table 5.3: Features extracted by the FE for the UDP flows

# Feature Description

35 # of incoming UDP flows 36 Ratio of UDP flows over total incoming flows 37 # of outgoing UDP flows 38 Ratio of UDP flows over total outgoing flows 39 Ratio of symmetric incoming UDP flows 40 Ratio of asymmetric incoming UDP flows 41 # of distinct src IP for incoming UDP flows 42 Entropy of src IP for incoming UDP flows 43 Bytes per incoming UDP flow 44 Bytes per outgoing UDP flow 45 # of packets per incoming UDP flow 46 # of packets per outgoing UDP flow 47 # of distinct src ports for incoming UDP flows 48 Entropy of src ports for incoming UDP flows 49 # of distinct dst ports for incoming UDP flows 50 Entropy of dst ports for incoming UDP flows 51 Ratio of dst port ≤ 1024 for incoming UDP flows 52 Ratio of dst port > 1024 for incoming UDP flows 53 # of distinct TTL values for incoming UDP flows 54 Entropy of TTL values for incoming UDP flows

Table 5.4: Features extracted by the FE for the ICMP flows

# Feature Description

55 # of incoming ICMP flows 56 Ratio of ICMP flows over total incoming flows 57 # of outgoing ICMP flows 58 Ratio of ICMP flows over total outgoing flows 59 Ratio of symmetric incoming ICMP flows 60 # of asymmetric incoming ICMP flows 61 # of distinct src IP for incoming ICMP flows 62 Entropy of src IP for incoming ICMP flows 63 Bytes per incoming ICMP flow 64 Bytes per outgoing ICMP flow 65 # of packets per incoming ICMP flow 66 # of packets per outgoing ICMP flow 67 # of distinct TTL values for incoming ICMP flows 68 Entropy of TTL values for incoming ICMP flows

18, 20, 42, 48, 50, 54, 62, and 68. The entropy is defined as follows:

H(F) = − n∑

i=1

fi∑n j=1 fj

× log2 fi∑n j=1 fj

(5.1)

where set F={f1,f2, ...,fn} represents the frequency of each distinct header for the

TCP, UDP, and ICMP flows. The NIDS invokes the TC module once the FE com-

pletes the feature extraction. The TC module is implemented using the SAE and

classifies the traffic for a host in one of the eight classes including normal and seven

types of DDoS attack classes. These DDoS attacks are based on the TCP, UDP or

ICMP flows launched by the adversaries separately or in a combination of two or

three.

5.3 Experimental Set-up and Results

Figure 5-3: Home Wireless Network (HWN) for normal traffic collection

We collected traffic from real and private networks. The private network was created

exclusively for attack experimentation. A discussion of them is provided in the fol-

lowing subsection. We did not choose the KDD Cup 99 or NSL-KDD traffic datasets

Algorithm 2: Feature Extractor module for ICMP features

Data: packets list(pkt lst), protocol (icmp), destinations list (dst lst) Result: extracted features (ftrlst) of ICMP traffic begin

/* List of incoming and outgoing flows for each destination */

inflows,outflows ←−{},{} /* List of number of bytes and packets per incoming and

outgoing flow for each destination */

lbif,lpif,lbof,lpof ←−{},{},{},{} /* List of distinct source IP and TTL count for each

destination */

sourceip,ttllst ←−{},{} ftrlst ←− { } foreach pkt hdr in pkt lst do

get src, dst, and flow of packet from pkt hdr if flow is found for dst in inflows then

increment packet and byte count for flow entering into dst in lpif and lbif

increment source IP and TTL count for dst in sourcip and ttllst

if src in dst lst and flow is found for src in outflows then increment packet and byte count of flow exiting from src in lpof and lbof

foreach dst in dst lst do /* Compute incoming and outgoing flows (tif, tof ), packets

and bytes per incoming and outgoing flow (tpif, tbif,

tpof, tbof ), distinct source IP and TTL and their

entropy(dsip, sipent, dttl, ttlent ), fraction of

symmetric and asymmetric flows (fsym, fasym ); Add these

features in ftrlst for dst */

tif ←− length of inflows for dst tpif,tbif ←− median of lpif and lbif for dst dsip,dttl ←− length of sourceip and ttllst for dst if outflows is not empty for dst then

tof ←− length of outflows for dst tpof,tbof ←− median of lpof and lbof for dst

sipent,ttlent ←− find entropy of sourceip and ttllst for dst foreach flow in inflows for dst do

compute symflow if symflow in outflows for dst then sym ←− sym + 1 else asym ←− asym + 1 compute fsym and fasym from sym and asym

return ftrlst

Table 5.5: Number of records in the training and test datasets for normal and different DDoS attack traffic

Traffic class # of records

Training Test

Normal (N) 49179 21076

Attack

TCP (T) 5471 2344 UDP (U) 5273 2260 ICMP (I) 1602 686 TCP & UDP (TU) 4694 2011 TCP & ICMP (TI) 4739 2031 UDP & ICMP (UI) 4437 1902 All (A) 5615 2407

for the system evaluation as it contains several kinds of intrusions including DDoS

and our system mainly focuses on the DDoS attack. Additionally, these datasets have

a features set different from our derived set of features.

5.3.1 Experimental Set-up

A home wireless network (HWN) with the Internet connectivity was used as a real

network for normal traffic collection. The network had around 12 users connected to

the Internet with their laptops or smartphones. The network topology of the HWN

is shown in Figure 5-3. The network usage patterns were not uniform for each user

that led to a variation in the traffic distribution. The HWN traffic was saved for

three days on a Linux system using tcpdump [96] and port mirroring. The first two

days traffic were used as normal traffic flows. The third-day traffic was mixed with

the attack traffic collected separately and labeled as an attack. The motivation for

doing so was to model the situations where hosts/networks may contain attack traffic

along with the normal traffic, thus makes the attack detection challenging for the

IDS. The traffic mix was performed with the help of bit-twist [5] that modifies the

packet headers in a traffic trace file. We modified a few IP addresses in the normal

traffic and changed them to those found in the attack traffic. Finally, the modified

normal and attack traffic trace files were replayed together using tcpreplay [97]. The

collected normal traffic consisted of data from web services, streaming, messengers,

and gaming. We created a private network using VMware ESXi host in an isolated

environment to collect the attack traffic. Attack tool hping3 [28] was used to launch

the DDoS attacks with varying packet sizes and frequencies. Only one type of attack

was launched at a time for easy labeling and extracting the features. An SDN testbed

was created using the same ESXi host following the steps mentioned in [26] to replay

all the collected traffic. The testbed has three hosts: the controller, switch, and end

host. We used the POX controller running the NIDS application in the controller

system. Open vSwitch (OVS) [66] was installed in the switch host to make it an OF-

switch. The host system used tcpreplay to replay the attack and normal traffic traces

one at a time. The features extracted by the FE for each time window were saved

in dataset files in CSV format to train the TC module. The interval for triggering

the FE module was set to 60s in the timer function. We referred a few literature

to set the interval for a time window [6, 23, 32]. Braga et al. [6] used 3s in their

work; we considered it too frequent to invoke the FE. Giotis et al. [23] and Jin et

al. [32] used 30s and 20s in their work, respectively. We did not find any fixed polling

interval in the literature, therefore selected an interval of 60s to invoke the FE. The

dataset files were divided into the training and test datasets. The distributions of

records in the datasets were shown in Table 5.5. The traffic features in the datasets

were real-valued with varied ranges in the dataset. Max-min normalization shown in

Eqn. 5.2 was used to normalize them in a range of [0, 1] before passing them to the

TC.

Xnorm = xi −xmin xmax −xmin

, ∀xi ∈ X (5.2)

xmin = smallest value in X

xmax = largest value in X

5.3.2 Results

The system performance was evaluated with the datasets mentioned in Table 5.5

using well-known machine learning parameters such as accuracy, recall, precision, f-

measure, and ROC. A confusion matrix (M) was used to compute recall, precision,

and f-measure. It is an N×N square matrix where N represents the number of classes

in a dataset. A column in the matrix represents the prediction of a particular class

into all available classes including the class itself in the dataset. Similarly, each row

represents the prediction of all available classes into a particular class including that

class. The diagonal elements of the matrix are the true-positive (TP) values for each

class. The sum of the elements along a row except the diagonal element represents

the prediction as false-positive (FP) for a class corresponding to the row. The sum

of the elements along a column except the diagonal element represents the prediction

as false-negative (FN) for a class corresponding to the column. Various performance

parameters can be defined as follows:

• Accuracy (A): The percentage of accurately classified records over the total

records in a dataset

A = Accurately classified records

Total records × 100 (5.3)

• Precision (P): The percentage of correctly predicted records over all the pre-

dicted records for a class. The precision for a class j can be defined as follows

using the confusion matrix (M):

Pj = TPj

TPj + FPj × 100

= Mj,j

Mj,j + ∑N

i=1 i 6=j

Mj,i × 100 (5.4)

• Recall (R): The percentage of correctly predicted records over all the available

records for a particular class in the dataset. The recall for a class j can be

defined as follows using the confusion matrix (M):

Rj = TPj

TPj + FNj × 100

= Mj,j

Mj,j + ∑N

i=1 i 6=j

Mi,j × 100 (5.5)

• F-measure (F): It gives a holistic evaluation of a model and calculated as the

percentage harmonic mean of precision and recall. It is defined as follows for a

class j:

Fj = 2 ×Pj ×Rj Pj + Rj

× 100 (5.6)

• Receiver Operating Curve (ROC): It gives a graphical visualization of the per-

formance of a classifier in which the true-positive rate is plotted against the

false-positive rate for the classifier. The area under the ROC curve provides a

proportional estimate of the average performance of a classifier.

The SAE-based classification model for the TC module was implemented using the

Figure 5-4: Confusion matrix for 8-class classification in the SAE model

Figure 5-5: Precision, recall, and f-measure values for 8-class

Figure 5-6: ROC curve for 8-class classification

training dataset and evaluation was made using the test dataset. An 8-class traffic

classification model was developed to classify the traffic into normal and seven dif-

ferent types of DDoS attacks. An attack detection model was also developed using

softmax regression only to make a comparison with the SAE. After performing a grid

parameters search, we observed that the SAE model achieved better accuracy com-

pared to the softmax regression shown in Table 5.6. Figure 5-5 shows the computed

values of precision, recall, and f-measure for the SAE models which were derived from

the confusion matrix shown in Figure 5-4. The model has the f-measure values more

than 90% in the case of normal, TCP, UDP, and UDP along with ICMP attack traffic

as seen from the figure. It has relatively low f-measure values for the combined attacks

of TCP with ICMP and UDP due to their classification into other kinds of attacks

as seen from Figure 5-4. However, their classification into normal traffic is less than

0.2% as observed from the same figure. The ROC curve is shown in Figure 5-6 for

eight different classes. We observe from the figure that the true positive rate is more

Table 5.6: Classification accuracy comparison among soft-max and SAE based models

Method Accuracy (in %)

Soft-max 94.30 SAE 95.65

Table 5.7: Accuracy and false-positive rates for 8-class and 2-class SAE mod- els

Classification Models

Accuracy False-positive Rate

8-class 95.65% 0.5% 2-class 99.82% 0.3%

than 90% for a false-positive rate of less than 5% for all kinds of traffic, therefore the

areas under the ROC curves result close to unity.

A 2-class classification model was also developed by considering various DDoS

attacks as one attack class to compare the work with others. The unavailability of

existing literature due to the unique nature of the work that involves a DL-based

attack detection in the SDN environment, it was hard to make a comparison with the

other works. The 2-class classification performance is shown in Figure 5-8. An accu-

racy of 99.8% along with the f-measure values of 99.85% and 99.75% were achieved

respectively. These values were derived from the confusion matrix shown in Figure 5-

7. The two closely related works [6] and [56] showed a detection accuracy of 99.11%

and 96% in the data and control plane, respectively. However, the limitation with

both the works is that they did not address the attack detection in the other plane.

The accuracy and false-positive rate are shown in Table 5.7 for 2-class and 8-class

SAE models.

The computational time for the training and test of our model were measured on

a machine configured with Intel (R) Core i7 CPU @ 3.40 GHz processor and 16 GB

RAM and running Matlab 2016a on Windows 7. The computational time for the

Figure 5-7: Confusion matrix for 2-class classification

Figure 5-8: Precision, recall, and f-measure values for 2-class classification

Table 5.8: Average computational time for the training and classification in the SAE model

Training time Classification time

524s 0.0835s

training of 81,010 records and classification of 34,717 records, specified in Table 5.5,

are shown in Table 5.8.

5.4 Traffic Analysis and Modified TCFI (MTCFI)

As discussed earlier, the previous implementation of the TCFI module instructs the

switches to forward every packet received at them to the controller. This approach

can cause the performance bottleneck at the controller due to the well-behaved flow

control of TCP channel between the switches and the controller. An alternative

implementation of the TCFI could be made that forwards a limited number of packets

and flows for a particular host or network service towards the controller in a specific

time window to overcome this limitation. The FE and TC modules will perform

the feature extraction and classification using those limited flows and packets. To

implement this modified TCFI (MTCFI), we first analyze the normal traffic available

from a few public datasets discussed as follows.

5.4.1 Traffic Analysis of Public Datasets

We used the following five datasets to analyze the flow patterns of the normal traffic

for a particular time window:

• UNIBS: The dataset is made publicly available by the University of Brescia

[16]. It consists of traffic traces captured at the edge router of the university

network for three consecutive days using tcpdump. The captured trace was 27

GB in size and generated from 22 workstations. After removing the payloads

Figure 5-9: The cumulative distribution function (CDF) of the number of flows arrived at the hosts in 60s

Figure 5-10: The cumulative distribution function (CDF) of the number of HTTP requests made to the servers in 60s

from the packets and anonymizing them, reduced size of the trace became 2.7

GB.

• ISCX: The dataset was collected in a testbed environment by University of

New Brunswick [87]. A systematic approach was used in it to model the real-

world traffic. Profiles with the abstract representation of events to depict real-

world network usage behaviors were used to generate the normal and attack

traffic close to the real-world. The dataset contains traffic generated for seven

days including the normal and various types of attack traffic. For our analysis

purpose, we used the normal traffic only as we observed that the attack traffic

in this dataset is targeted to the application layer and our detection approach

is based on the network and transport layers.

• Two public Apache server logs: These two web server logs, consist of HTTP

requests for a day, are made available by Lawrence Berkeley National Labora-

tory. One of the logs consists of the HTTP requests made to the EPA web

server of Research Triangle Park, NC [19]. There were around 48,000 requests

found in the log including GET, POST, HEAD, and a few invalid requests. The

other log consists of the HTTP requests made to the SDSC WWW server of

the San Diego Supercomputer Center [78]. There were around 28,000 requests

available in this log. Although these logs are dated, they give an insight for the

HTTP requests that a server receives in a day at the organizational network.

• CSET Apache server log: This server log was provided by the CSET depart-

ment of the University of Toledo. The server hosts various course and faculty

related information of the CSET department. We analyze the HTTP requests

made in a day to this server with the provided log.

We analyzed these datasets to find the number of flows or requests that happen to a

host or server. Figure 5-9 shows the cumulative distribution function (CDF) of the

flows arrived at the UNIBS and ISCX networks during a 60s time window. We found

that 90% of the traffic in the UNIBS and ISCX have 75 and 175 flows respectively.

The number of HTTP requests is below 60 for most of the time in all the server logs

shown in Figure 5-10. We considered all the HTTP persistent connections to a server

as a single request as they are made through a single TCP flow. We used these values

to set a threshold for the number of flows that can arrive for a network service as

described in the following section.

5.4.2 The Implementation of MTCFI

In the MTCFI implementation, we use two threshold variables FLOW THRES and

PKT THRES to limit the number of flows and packets respectively. We set the value of

FLOW THRES to 200 after observing the traffic from publicly available datasets as dis-

cussed above. For the PKT THRES, we checked the size of the buffer in which a switch

queues the PACKET IN requests forwarded to the controller until it gets responses for

them from the controller. The size of the buffer in the OVS implementation is 256;

therefore we set the value of PKT THRES to 256. The MTCFI maintains two lists to

keep track the number of asymmetric flows at a particular time window for both the

TCP and UDP based flows, however, for the ICMP flow one list is sufficient. One

of the lists maintains a flow count for the tuple <protocol, source IP, source port,

destination IP> found in a flow. The other list maintains a flow count using the

tuple <protocol, destination IP, destination port>. If a symmetric flow arrives for

any of the tuples in these two lists, we reduce the flow count for the corresponding

tuples from the lists without inserting the tuples for the incoming flow. If the number

of flow count exceeds the FLOW THRES for a tuple in the lists, we install a rule in the

switches to drop the flow with a match field similar to the tuple for that particular

time window. Figure 5-11 shows the two lists before and after the arrival of a packet

for an asymmetric flow. This approach restricts the number of asymmetric flows

Algorithm 3: Modified Traffic Classifier and Flow Installer (MTCFI) Mod- ule

Data: Incoming packets at the controller Result: List of extracted packet headers for TCP, UDP, and ICMP begin

packets list ← [ ] /* List of symmetric & asymmetric flows with packets count */

symflows,asymflows ← { }, { } while timer for the FE is not triggered do

receive packet from switch store headers in packets list compute flow for packet if packet arrives due to a rule forwarding then

increment pkt cnt for flow if pkt cnt ≥ PKT THRES then

modify rule to stop forwarding packets for flow to controller

return if packet arrives due to flow table-miss then

compute symflow for flow if symflow found in asymflows then

remove symflow from asymflows add flow and symflow in symflows with their pkt cnt set to 1 install rules for flow and symflow reduce count of tuples in queue(s) by 1 for symflow

else if flow found in asymflows then increment pkt cnt for flow if pkt cnt ≥ PKT THRES then

install rules to drop packets for flow

else compute tuple(s) for queue(s) from flow if tuple(s) found then

increment count for tuple(s) if count ≥ FLOW THRES then

install rule to drop incoming flows with match fields equal to tuples

else add tuples in queue(s)

Figure 5-11: Flow count for the tuples in the two lists before and after arrival of a packet for an asymmetric flow

for specific services in a host without affecting the other services in the same host.

The reason, for maintaining two lists, comes from the fact that we want to limit the

asymmetric flows in two situations:

• A reflected DDoS occurs where traffic come to a host from specific services of

other hosts. The first list handles this situation.

• A direct DDoS attack towards specific services of a host. The second list is used

for it.

The controller modifies an installed rule in the switches for a symmetric flow if the

received packets at the controller for the flow exceeds PKT THRES. The modified rule

instructs the switch to forward the packets for the flow to the destined ports only

without forwarding them towards the controller. The modified rule is updated in the

next time window to forward the packets again towards the controller until PKT THRES

Figure 5-12: Average execution time of the FE module for both the TCFI implementations with the increased number of downloads

reaches. For an asymmetric flow, the controller installs a flow rule that drops the pack-

ets for the flow in that time window if the number of packets reaches to PKT THRES.

Algorithm 3 shows the basic implementation of the MTCFI module.

5.4.2.1 Performance Evaluation of the MTCFI

We first evaluated the NIDS implemented using the modified TCFI to observe any

effect on the classification accuracy. We followed the same approach as we did in the

implementation of the NIDS with the TCFI module. Extracted features were saved

as training and test dataset files. We observed that the traffic traces of (TCP and

ICMP), (TCP and UDP), and (TCP, UDP, and ICMP) attacks had the TCP traffic

as symmetric flows in response to the reflected attacks launch to the victim hosts as

RST replies. We did not consider these three attacks for the comparisons otherwise

the MTCFI would behave like the previous implementation. Table 5.9 shows the

Figure 5-13: Average transfer time for a web service with the increased num- ber of concurrent downloads

precision, recall, and f-measure values for five different traffic classes for both the

implementations. Table 5.10 shows the average accuracy and false alarms for both

the implementations. We observed that the MTCFI performs lesser than the previous

implementation. However, we would like to highlight that the DL parameters used

in the MTCFI implementation were kept same to the previous implementation.

We evaluated the execution time of the FE module for both the implementations

and also compared the data transfer time for a network service running under both

the implementation of NIDS with when they run under a Layer-2 switch application

that only installs flow rules in the switches based on the MAC learning. To perform

these tasks, we concurrently ran several client-server web applications in an SDN

testbed discussed earlier. Figure 5-12 shows the time the FE module takes to extract

the traffic features from the packet headers stored in the packets list. We found that

the FE takes lesser time to extract the features in the MTCFI implementation than

Table 5.9: Precision, recall, and f-measure comparisons for the two NIDS implementations

Precision Recall F-Measure

Traffic Type TCFI MTCFI TCFI MTCFI TCFI MTCFI Normal 99.8 100 100 100 99.9 100 TCP 99.8 98.1 98.8 97.6 99.9 97.8 UDP 98.8 94.1 99.5 95.3 99.1 94.7 ICMP 91 98.3 100 99.6 95.3 98.9 UDP + ICMP 99.9 99.4 94.8 97.5 97.3 98.4

Table 5.10: Accuracy and false alarms comparisons for the two NIDS imple- mentations

NIDS Implementation Accuracy (%) False Alarms (%)

TCFI 99.35 0.65 MTCFI 99.48 0.49

the previous implementation due to the limited number of flows and packets for the

services in a host. It is also observed that the rate of increment of the FE execution

time is lesser in the MTCFI compared to the previous one.

Figure 5-13 shows the average transfer time for a network service with the in-

creased number of concurrent downloads. We observed that the transfer takes longer

time when the services run under the previous implementation of the NIDS compared

to the modified NIDS and Layer-2 switch application. However, we found that the

modified NIDS performance is almost equal to the Layer-2 switch SDN application in

all the cases despite the fact that it extracts features and installs rules for the flows.

We performed the experiments for the execution time of the FE and data transfer

time using the VMs created on a VMware ESXi host.

5.5 Chapter Summary

In this work, a deep learning based NIDS for multi-vector DDoS attack detection

was implemented in an SDN environment and results were published for the same.

The implemented system identifies each DDoS attack class and normal traffic with a

high average accuracy and very low false alarms compared to many other works. We

further modified the TCFI to improve the network performance and observed that

the performance of services in the modified NIDS is similar to what they perform

in a Layer-2 SDN application with an equivalent accuracy in the attack detection

compared to the TCFI module based NIDS.

Chapter 6

Conclusion & Future Work

In this chapter, we conclude our dissertation with a summary of accomplishments

and provide insights for the future extensions of some of these works.

6.1 Conclusion

We made four contributions in this dissertation work- attack impact evaluation in the

SDN managed network; application of deep learning in the NIDS implementation;

implementation of an NIDS in the SDN using a DL-approach for a real network; and

a light-weight testbed development for network security experiments. The achieved

accomplishments can be summarized as follows:

We evaluated the attack impact in different scenarios on web services running in

the SDN. It was observed that the attacks affect the performances of web services

significantly. The response time and availability of the services were considered for the

evaluation. We found that the attack impact was severe when the attackers and client-

server of web services co-existed in the same network or the web hosts and adversares

were distributed in different networks. The adverse impact on these metrics may

challenge the network operators to provide a required SLA to the customers.

We implemented a DL-based NIDS using self-taught learning. We used the NSL-

KDD dataset to develop the NIDS. The performance evaluation was done using the

training data and test data as well, and the NIDS was developed for 2-class, 5-

class, and 23-class traffic classification. We observed that the NIDS performed well

compared to many of the previously implemented NIDSs for the intrusion detection

when evaluated over the test dataset. The NIDS was developed to discover the

application of the DL-approach in network intrusion detection and this work was

among the earlier ones in this specific interest.

A DL-based NIDS was implemented for a real network to detect multi-vector

DDoS attacks in an SDN environment. We used SAE for the implementation. The

NIDS was able to identify different DDoS attacks and could determine whether an

incoming traffic is normal or attack. The individual identification of each attack

benefits us in applying the mitigation technique to prevent the specific type of traffic

flows responsible for the attack. This approach would allow the legitimate incoming

traffic towards the victims and block the attack traffic. This work was one of its own

that combines the SDN and DL together to implement an NIDS for a real network

apart from work found in [94].

A light-weight testbed was implemented for the network security experiments

while working on the NIDS implementation in the SDN. The testbed has been devel-

oped using OVS as one of its components that implements OF in the software switch.

The testbed supports the deployment of a large number of virtual networks over a

single infrastructure with limited resources, thus makes it cost-effective and scalable.

The testbed has been used successfully for various network and security courses for

the last few semesters in the CSET department.

6.2 Future Work

Following extensions can be made in the works mentioned above.

In our attack impact evaluation, we confined the performance evaluation for the

web services only. We can consider more attacks and other network services includ-

ing real-time audio and video streaming running in an SDN-managed network for

the analysis. An overall risk assessment of different threats can be performed by

evaluating their impact the SDN-managed network.

We can improve the performance of the DL-based NIDS for the NSL-KDD dataset

by using the SAE for unsupervised feature learning along with NB-Tree, Random Tree

or J48 as a classifier. It was reported in [95] that those techniques performed well

when applied to the dataset compared to others.

The implemented NIDS in the SDN has limitations related to the processing ca-

pabilities. The TCFI and FE modules store packets received at the controller to

extract features with low false alarms in the detection. We have implemented these

modules on top of the controller. However, this approach can cause the performance

bottleneck at the controller. A hybrid approach can be adopted to overcome the lim-

itation in which we can sample the flows or perform packet-based flow computation

determined upon the observed traffic in the network. Another approach could be the

deployment of the TCFI and FE modules in another host and send the packets to it

for the feature extraction instead of the controller. For efficient feature extraction,

distributed processing can be applied as well similar to our previous work [34]. The

NIDS can be extended to detect different kinds of attacks including scanning, mal-

ware, and application layer attacks apart from the DDoS attacks. For the end-to-end

classification in the DL, feature extraction can be made from raw bytes of packet

headers instead of the reduction of the derived features.

References

[1] I. Ahmad, S. Namal, M. Ylianttila, and A. Gurtov. Security in Software Defined

Networks: A Survey. IEEE Communications Surveys Tutorials, 17(4):2317–

2346, Fourthquarter 2015.

[2] Benjamin R. Anderson, Amy K. Joines, and Thomas E. Daniels. Xen Worlds:

Leveraging Virtualization in Distance Education. In Proceedings of the 14th

Annual ACM SIGCSE Conference on Innovation and Technology in Computer

Science Education, ITiCSE ’09, pages 293–297, New York, NY, USA, 2009.

ACM.

[3] William D. Armitage, Alessio Gaspar, and Matthew Rideout. A UML and MLN

Based Approach to Implementing a Networking Laboratory on a Scalable Linux

Cluster. J. Comput. Sci. Coll., 23(2):112–119, December 2007.

[4] Kevin Benton, L. Jean Camp, and Chris Small. OpenFlow Vulnerability Assess-

ment. In Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics

in Software Defined Networking, HotSDN ’13, pages 151–152, 2013.

[5] Bit-Twist. http://bittwist.sourceforge.net/ Accessed July 27, 2017.

[6] R. Braga, E. Mota, and A. Passito. Lightweight DDoS Flooding Attack Detec-

tion Using NOX/OpenFlow. In Proceedings of the 2010 IEEE 35th Conference

on Local Computer Networks, LCN ’10, pages 408–415, Washington, DC, USA,

2010. IEEE Computer Society.

[7] Martin Casado, Tal Garfinkel, Aditya Akella, Michael J. Freedman, Dan Boneh,

Nick McKeown, and Scott Shenker. SANE: A Protection Architecture for En-

terprise Networks. In Proceedings of the 15th Conference on USENIX Security

Symposium - Volume 15, USENIX-SS’06, 2006.

[8] Hee Su Chae, Byung Oh Jo, Sang Hyun Choi, and Twae Kyung Park. Fea-

ture Selection for Intrusion Detection using NSL-KDD. Recent Advances in

Computer Science, pages 184–187, 2013.

[9] Cisco Visual Networking Index Predicts Near-Tripling of IP Traffic by

2020. https://newsroom.cisco.com/press-release-content?articleId=

1771211 Accessed July 27, 2017.

[10] Curl. http://curl.haxx.se/ Accessed July 27, 2017.

[11] DDoS Attack on BBC May Have Been Biggest in History. http:

//www.csoonline.com/article/3020292/cyber-attacks-espionage/

ddos-attack-on-bbc-may-have-been-biggest-in-history.html Accessed

July 27, 2017.

[12] DDoS Attacks in the United Kingdom, 2012. http://goo.gl/qrw0HR Accessed

July 27, 2017.

[13] Denial of Service Attacks. https://www.incapsula.com/ddos/ Accessed July

27, 2017.

[14] Dalibor Dobrilovic, Vesna Jevtic, Zeljko Stojanov, and Borislav Odadzic. Us-

ability of Virtual Network Laboratory in Engineering Education and Computer

Network Course.

[15] Jeremy M. Dover. A Denial of Service Attack against the Open Floodlight SDN

Controller. Research Report, DoverNetworks, Dec 2013.

[16] Maurizio Dusi, Francesco Gringoli, and Luca Salgarelli. Quantifying the Accu-

racy of the Ground Truth Associated with Internet Traffic Traces. Computer

Networks, 55(5):1158 – 1167, 2011.

[17] Heba F Eid, Ashraf Darwish, Aboul Ella Hassanien, and Ajith Abraham. Prin-

ciple Components Analysis and Support Vector Machine based Intrusion De-

tection System. In Intelligent Systems Design and Applications (ISDA), 2010

10th International Conference on, pages 363–367. IEEE, 2010.

[18] Heba F Eid, Mostafa A Salama, Aboul Ella Hassanien, and Tai Hoon Kim.

Bi-layer Behavioral-based Feature Selection Approach for Network Intrusion

Classification. In Security Technology, pages 195–203. Springer, 2011.

[19] EPA-HTTP Web Server Log. http://ita.ee.lbl.gov/html/contrib/

EPA-HTTP.html Accessed July 27, 2017.

[20] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina. Generic Routing

Encapsulation, RFC 2784.

[21] Ugo Fiore, Francesco Palmieri, Aniello Castiglione, and Alfredo De Santis. Net-

work Anomaly Detection with the Restricted Boltzmann Machine. Neurocom-

put., 122:13–23, 2013.

[22] N. Gao, L. Gao, Q. Gao, and H. Wang. An Intrusion Detection Model Based on

Deep Belief Networks. In Advanced Cloud and Big Data (CBD), 2014 Second

International Conference on, pages 247–252, Nov 2014.

[23] K. Giotis, C. Argyropoulos, G. Androulidakis, D. Kalogeras, and V. Maglaris.

Combining OpenFlow and sFlow for an Effective and Scalable Anomaly Detec-

tion and Mitigation Mechanism on SDN Environments. Computer Networks,

62:122 – 136, 2014.

[24] Prasanta Gogoi, Monowar H Bhuyan, DK Bhattacharyya, and Jugal K Kalita.

Packet and Flow based Network Intrusion Dataset. In Contemporary Comput-

ing, pages 322–334. Springer, 2012.

[25] Ian Goodfellow, Yoshua Bengio, and Aaron Courville. Deep Learning. MIT

Press, 2016. http://www.deeplearningbook.org.

[26] Bruce Hartpence. The RIT SDN Testbed and GENI. 2015.

[27] How Much Will Today’s Internet Outage Cost? https://www.theatlantic.

com/technology/archive/2016/10/a-lot/505025/ Accessed July 27, 2017.

[28] Hping3. http://wiki.hping.org Accessed July 27, 2017.

[29] Hongxin Hu, Wonkyu Han, Gail-Joon Ahn, and Ziming Zhao. FLOWGUARD:

Building Robust Firewalls for Software-defined Networks. In Proceedings of the

Third Workshop on Hot Topics in Software Defined Networking, HotSDN ’14,

pages 97–102, 2014.

[30] Ahmad Javaid, Quamar Niyaz, Weiqing Sun, and Mansoor Alam. A Deep

Learning Approach for Network Intrusion Detection System. In Proceedings of

the 9th EAI International Conference on Bio-inspired Information and Commu-

nications Technologies (Formerly BIONETICS), BICT’15, pages 21–26, 2016.

[31] Ahmad Javaid, Quamar Niyaz, Weiqing Sun, and Mansoor Alam. A Deep

Learning Approach for Network Intrusion Detection System. EAI Endorsed

Transactions on Security and Safety, 16(9), 5 2016.

[32] Shuyuan Jin and D. S. Yeung. A Covariance Analysis Model for DDoS Attack

Detection. In 2004 IEEE International Conference on Communications (IEEE

Cat. No.04CH37577), volume 4, pages 1882–1886 Vol.4, July 2004.

[33] M. J. Kang and J. W. Kang. Intrusion Detection System Using Deep Neural

Network for In-Vehicle Network Security. PLoS ONE, 11(6):1–17, 06 2016.

[34] A. M. Karimi, Q. Niyaz, Weiqing Sun, A. Y. Javaid, and V. K. Devabhaktuni.

Distributed Network Traffic Feature Extraction for a Real-time IDS. In 2016

IEEE International Conference on Electro Information Technology (EIT), May

2016.

[35] KDD Cup 99. http://kdd.ics.uci.edu/databases/kddcup99/kddcup99.

html Accessed July 27, 2017.

[36] H. Kim and N. Feamster. Improving Network Management with Software-

defined Networking. IEEE Communications Magazine, 51(2):114–119, February

2013.

[37] R. Kloti, V. Kotronis, and P. Smith. OpenFlow: A Security Analysis. In

Network Protocols (ICNP), 2013 21st IEEE International Conference on, pages

1–6, Oct 2013.

[38] Diego Kreutz, Fernando M. V. Ramos, Paulo Veŕıssimo, Christian Esteve

Rothenberg, Siamak Azodolmolky, and Steve Uhlig. Software-Defined Net-

working: A Comprehensive Survey. Proceedings of the IEEE, 103(1):14–76, Jan

2015.

[39] Diego Kreutz, Fernando M.V. Ramos, and Paulo Verissimo. Towards Secure

and Dependable Software-defined Networks. In Proceedings of the Second ACM

SIGCOMM Workshop on Hot Topics in Software Defined Networking, HotSDN

’13, pages 55–60, 2013.

[40] Kumar Krishna, Weiqing Sun, Pratik Rana Rana, Tianning Li, and R. Sekar.

V-NetLab: A Cost-Effective Platform to Support Course Projects in Computer

Security. In 9th Annual Colloquium for Information Systems Security Educa-

tion, CISSE’05, 2005.

[41] Pavel Krömer, Jan Platoš, Václav Snáael, and Ajith Abraham. Fuzzy Classifi-

cation by Evolutionary Algorithms. In Systems, Man, and Cybernetics (SMC),

2011 IEEE International Conference on, pages 313–318. IEEE, 2011.

[42] Bob Lantz, Brandon Heller, and Nick McKeown. A Network in a Laptop:

Rapid Prototyping for Software-defined Networks. In Proceedings of the 9th

ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets-IX, pages

19:1–19:6, 2010.

[43] Yann LeCun, Yoshua Bengio, and Geoffrey Hinton. Deep Learning. Nature,

521(7553):436–444, 2015.

[44] Lan Li and Gyungho Lee. DDoS Attack Detection and Wavelets. Telecommu-

nication Systems, 28(3):435–451, 2005.

[45] S. Lim, J. Ha, H. Kim, Y. Kim, and S. Yang. A SDN-oriented DDoS Blocking

Scheme for Botnet-based Attacks. In 2014 Sixth International Conference on

Ubiquitous and Future Networks (ICUFN), pages 63–68, July 2014.

[46] R. P. Lippmann, D. J. Fried, I. Graf, J. W. Haines, K. R. Kendall, D. Mc-

Clung, D. Weber, S. E. Webster, D. Wyschogrod, R. K. Cunningham, and

M. A. Zissman. Evaluating Intrusion Detection Systems: the 1998 DARPA

Off-line Intrusion Detection Evaluation. In DARPA Information Survivability

Conference and Exposition, 2000. DISCEX ’00. Proceedings, volume 2, pages

12–26 vol.2, 2000.

[47] M. Liyanage, M. Ylianttila, and A. Gurtov. Securing the Control Channel

of Software-Defined Mobile Networks. In Proceeding of IEEE International

Symposium on a World of Wireless, Mobile and Multimedia Networks 2014,

pages 1–6, July 2014.

[48] LXC-Security. https://help.ubuntu.com/14.04/serverguide/lxc.html

Accessed July 27, 2017.

[49] T. Ma, F. Wang, J. Cheng, Y. Yu, and X. Chen. A Hybrid Spectral Clustering

and Deep Neural Network Ensemble Algorithm for Intrusion Detection in Sensor

Networks. Sensors, 16(10):1701, 2016.

[50] Stephanos Matsumoto, Samuel Hitz, and Adrian Perrig. Fleet: Defending SDNs

from Malicious Administrators. In Proceedings of the Third Workshop on Hot

Topics in Software Defined Networking, HotSDN ’14, pages 103–108, 2014.

[51] McAfee Labs Threats Report, May 2015. https://www.mcafee.com/us/

resources/reports/rp-quarterly-threat-q1-2015.pdf Accessed July 27,

2017.

[52] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Pe-

terson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. OpenFlow: En-

abling Innovation in Campus Networks. SIGCOMM Comput. Commun. Rev.,

38(2):69–74, March 2008.

[53] Syed Akbar Mehdi, Junaid Khalid, and Syed Ali Khayam. Revisiting Traffic

Anomaly Detection Using Software Defined Networking. In Recent Advances in

Intrusion Detection: 14th International Symposium, RAID 2011, Menlo Park,

CA, USA, September 20-21, 2011, pages 161–180. Springer, 2011.

[54] Mininet: An Instant Virtual Network on your Laptop (or other PC). http:

//mininet.org/ Accessed July 27, 2017.

[55] The MLN Project- Complex Virtual Machine Management Made Easy. http:

//mln.sourceforge.net/ Accessed July 27, 2017.

[56] S. M. Mousavi and M. St-Hilaire. Early Detection of DDoS Attacks Against

SDN Controllers. In Computing, Networking and Communications (ICNC),

2015 International Conference on, pages 77–81, Feb 2015.

[57] Reyadh Shaker Naoum, Namh Abdula Abid, and Zainab Namh Al-Sultani. An

Enhanced Resilient Backpropagation Artificial Neural Network for Intrusion

Detection System. International Journal of Computer Science and Network

Security, 12(3):11–16, 2012.

[58] Jad Naous, David Erickson, G. Adam Covington, Guido Appenzeller, and Nick

McKeown. Implementing an OpenFlow Switch on the NetFPGA Platform. In

Proceedings of the 4th ACM/IEEE Symposium on Architectures for Networking

and Communications Systems, ANCS ’08, pages 1–9, 2008.

[59] Cisco IOS NetFlow. http://www.cisco.com/c/en/us/products/

ios-nx-os-software/ios-netflow/index.html Accessed July 27, 2017.

[60] Andrew Ng. Sparse Autoencoder. 2011.

[61] Q. Niyaz, W. Sun, R. Xu, and M. Alam. Light VN: A Light-Weight Testbed

for Network and Security Experiments. In 2015 12th International Conference

on Information Technology - New Generations, pages 459–464, April 2015.

[62] Quamar Niyaz, Weiqing Sun, and Mansoor Alam. Impact on SDN Powered Net-

work Services Under Adversarial Attacks. Procedia Computer Science, 62:228

– 235, 2015.

[63] B. A. A. Nunes, M. Mendonca, X. N. Nguyen, K. Obraczka, and T. Turletti.

A Survey of Software-Defined Networking: Past, Present, and Future of Pro-

grammable Networks. IEEE Communications Surveys Tutorials, 16(3):1617–

1634, Third 2014.

[64] OpenFlow Switch Specification, Oct 2013. https://www.opennetworking.

org/ Accessed July 27, 2017.

[65] Georgios Oikonomou and Jelena Mirkovic. Modeling Human Behavior for De-

fense Against Flash-crowd Attacks. In Proceedings of the 2009 IEEE Interna-

tional Conference on Communications, ICC’09, pages 625–630, 2009.

[66] Open vSwitch. http://www.openvswitch.org Accessed July 27, 2017.

[67] OpenFlow: Proactive vs. Reactive Flows. http://networkstatic.net/

openflow-proactive-vs-reactive-flows/ Accessed July 27, 2017.

[68] Mrutyunjaya Panda, Ajith Abraham, and Manas Ranjan Patra. Discrimina-

tive Multinomial Naive Bayes for Network Intrusion Detection. In Information

Assurance and Security (IAS), 2010 Sixth International Conference on, pages

5–10. IEEE, 2010.

[69] Mrutyunjaya Panda, Ajith Abraham, and Manas Ranjan Patra. A Hybrid

Intelligent Approach for Network Intrusion Detection. Procedia Engineering,

30:1–9, 2012.

[70] Clayton R Pereira, Rodrigo YM Nakamura, Kelton AP Costa, and João P

Papa. An Optimum-Path Forest Framework for Intrusion Detection in Com-

puter Networks. Engineering Applications of Artificial Intelligence, 25(6):1226–

1234, 2012.

[71] POX Wiki: Open Networking Lab. https://openflow.stanford.edu/

display/ONL/POX+Wiki Accessed July 27, 2017.

[72] Rajat Raina, Alexis Battle, Honglak Lee, Benjamin Packer, and Andrew Y. Ng.

Self-taught Learning: Transfer Learning from Unlabeled Data. In Proceedings

of the 24th International Conference on Machine Learning, ICML ’07, 2007.

[73] Mostafa A Salama, Heba F Eid, Rabie A Ramadan, Ashraf Darwish, and

Aboul Ella Hassanien. Hybrid Intelligent Intrusion Detection Scheme. In Soft

computing in industrial applications, pages 293–303. Springer, 2011.

[74] L. Schehlmann, S. Abt, and H. Baier. Blessing or Curse? Revisiting Security

Aspects of Software-Defined Networking. In 10th International Conference on

Network and Service Management (CNSM) and Workshop, pages 382–387, Nov

2014.

[75] J. Schmidhuber. Deep Learning in Neural Networks: An Overview. Neural

Networks, 61:85 – 117, 2015.

[76] S. Scott-Hayward, G. O’Callaghan, and S. Sezer. SDN Security: A Survey.

In Future Networks and Services (SDN4FNS), 2013 IEEE SDN for, pages 1–7,

Nov 2013.

[77] Software Defined Network Security. http://www.sdnsecurity.org/ Accessed

July 27, 2017.

[78] SDSC-HTTP Web Server Log. http://ita.ee.lbl.gov/html/contrib/

SDSC-HTTP.html Accessed July 27, 2017.

[79] S. Sezer, S. Scott-Hayward, P.K. Chouhan, B. Fraser, D. Lake, J. Finnegan,

N. Viljoen, M. Miller, and N. Rao. Are We Ready for SDN? Implementation

Challenges for Software-Defined Networks. Communications Magazine, IEEE,

51(7):36–43, July 2013.

[80] sflow- making the network visible. http://www.sflow.org/ Accessed July 27,

2017.

[81] Shahaboddin Shamshirband, Nor Badrul Anuar, Miss Laiha Mat Kiah, and

Ahmed Patel. An Appraisal and Design of a Multi-Agent System based Co-

operative Wireless Intrusion Detection Computational Intelligence Technique.

Engineering Applications of Artificial Intelligence, 26(9):2105 – 2127, 2013.

[82] S. Shin, L. Xu, S. Hong, and G. Gu. Enhancing Network Security through

Software Defined Networking (SDN). In 2016 25th International Conference on

Computer Communication and Networks (ICCCN), pages 1–9, Aug 2016.

[83] Seugwon Shin, Phillip Porras, Vinod Yegneswaran, Martin Fong, Guofei Gu,

and Mabry Tyson. FRESCO: Modular Composable Security Services for

Software-Defined Networks, 2013.

[84] Seungwon Shin and Guofei Gu. Attacking Software-defined Networks: A First

Feasibility Study. In Proceedings of the Second ACM SIGCOMM Workshop on

Hot Topics in Software Defined Networking, HotSDN ’13, pages 165–166, 2013.

[85] Seungwon Shin, Vinod Yegneswaran, Phillip Porras, and Guofei Gu. AVANT-

GUARD: Scalable and Vigilant Switch Flow Management in Software-defined

Networks. In Proceedings of the 2013 ACM SIGSAC Conference on Computer

& Communications Security, CCS ’13, pages 413–424, 2013.

[86] P. Shinde and S. Guntupalli. Early DoS Attack Detection using Smoothened

Time-Series andWavelet Analysis. In Third International Symposium on Infor-

mation Assurance and Security, pages 215–220, Aug 2007.

[87] Ali Shiravi, Hadi Shiravi, Mahbod Tavallaee, and Ali A Ghorbani. Toward De-

veloping a Systematic Approach to Generate Benchmark Datasets for Intrusion

Detection. Computers & Security, 31(3):357–374, 2012.

[88] Snort. https://www.snort.org/ Accessed July 27, 2017.

[89] Stephen Soltesz, Herbert Pötzl, Marc E. Fiuczynski, Andy Bavier, and Larry

Peterson. Container-based Operating System Virtualization: A Scalable, High-

performance Alternative to Hypervisors. In Proceedings of the 2Nd ACM

SIGOPS/EuroSys European Conference on Computer Systems 2007, EuroSys

’07, pages 275–287, New York, NY, USA, 2007. ACM.

[90] Stacked Autoencoders. http://deeplearning.stanford.edu/wiki/index.

php/Stacked_Autoencoders Accessed July 27, 2017.

[91] S. J. Stolfo, Wei Fan, Wenke Lee, A. Prodromidis, and P. K. Chan. Cost-based

Modeling for Fraud and Intrusion Detection: Results from the JAM Project. In

DARPA Information Survivability Conference and Exposition, 2000. DISCEX

’00. Proceedings, volume 2, pages 130–144 vol.2, 2000.

[92] Weiqing Sun, Varun Katta, Kumar Krishna, and R. Sekar. V-NetLab: An

Approach for Realizing Logically Isolated Networks for Security Experiments.

In Proceedings of the Conference on Cyber Security Experimentation and Test,

CSET’08, 2008.

[93] Iwan Syarif, Adam Prugel-Bennett, and Gary Wills. Unsupervised Clustering

Approach for Network Anomaly Detection. In Networked Digital Technologies,

pages 135–145. Springer, 2012.

[94] Tuan A Tang, Lotfi Mhamdi, Des McLernon, Syed Ali Raza Zaidi, and Mounir

Ghogho. Deep Learning Approach for Network Intrusion Detection in Software

Defined Networking. In The international conference on wireless networks and

mobile communications, WINCOM’16, 2016.

[95] M. Tavallaee, E. Bagheri, Wei Lu, and A.A. Ghorbani. A Detailed Analysis

of the KDD CUP 99 Data Set. In Computational Intelligence for Security and

Defense Applications, 2009. CISDA 2009. IEEE Symposium on, pages 1–6, July

2009.

[96] Tcpdump. http://www.tcpdump.org Accessed July 27, 2017.

[97] Tcpreplay. http://tcpreplay.synfin.net Accessed July 27, 2017.

[98] Sumaiya Thaseen and C Aswani Kumar. An Analysis of Supervised Tree based

Classifiers for Intrusion Detection System. In Pattern Recognition, Informatics

and Mobile Engineering (PRIME), 2013 International Conference on, pages

294–299. IEEE, 2013.

[99] The Recent DDoS Attacks on Banks: 7 Key Lessons. https://www.neustar.

biz/resources/whitepapers/recent-ddos-attacks-on-banks Accessed

July 27, 2017.

[100] Chih Fong Tsai, Yu Feng Hsu, Chia Ying Lin, and Wei Yang Lin. Intrusion

Detection by Machine Learning: A Review . Expert Systems with Applications,

36(10):11994 – 12000, 2009.

[101] Understanding Virtualization, Paravirtualization, and Hardware Assist. http:

//tinyurl.com/yads7w23 Accessed July 27, 2017.

[102] Verisign Q2 2016 DDoS Trends: Layer 7 DDoS Attacks

a Grwoing Trend. https://blog.verisign.com/security/

verisign-q2-2016-ddos-trends-layer-7-ddos-attacks-a-growing-trend/

Accessed July 27, 2017.

[103] Virtual-LAN. http://tinyurl.com/n78hdgq, Accessed July 27, 2017.

[104] VMWare ESXi. https://www.vmware.com/products/esxi-and-esx.html,

Accessed July 27, 2017.

100

[105] Juan Wang, Yong Wang, Hongxin Hu, Qingxin Sun, He Shi, and Longjie Zeng.

Towards a Security-Enhanced Firewall Application for OpenFlow Networks. In

Cyberspace Safety and Security, volume 8300 of Lecture Notes in Computer

Science, pages 92–103. 2013.

[106] R. Wang, Z. Jia, and L. Ju. An Entropy-Based Distributed DDoS Detec-

tion Mechanism in Software-Defined Networking. In Proceedings of the 2015

IEEE Trustcom/BigDataSE/ISPA - Volume 01, TRUSTCOM ’15, pages 310–

317, Washington, DC, USA, 2015. IEEE Computer Society.

[107] Zhanayi Wang. The Applications of Deep Learning on Traffic Identification.

https://goo.gl/WouIM6.

[108] Xitao Wen, Yan Chen, Chengchen Hu, Chao Shi, and Yi Wang. Towards

a Secure Controller Platform for Openflow Applications. In Proceedings of

the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined

Networking, HotSDN ’13, pages 171–172, 2013.

[109] What is a DDoS Attack? https://www.arbornetworks.com/research/

ddos-resources Accessed July 27, 2017.

[110] World Of Warcraft: Legion Goes Down As Blizzard Servers Hit

With DDoS. http://www.forbes.com/sites/erikkain/2016/09/01/

world-of-warcraft-legion-goes-down-as-blizzard-servers-hit-with-ddos/

Accessed July 27, 2017.

[111] Le Xu, Dijiang Huang, and Wei-Tek Tsai. V-lab: A Cloud-based Virtual Lab-

oratory Platform for Hands-on Networking Courses. In Proceedings of the 17th

ACM Annual Conference on Innovation and Technology in Computer Science

Education, ITiCSE ’12, pages 256–261, New York, NY, USA, 2012. ACM.

101

Appendix A

A Light-weight Testbed for

Network and Security Experiments

Teaching computer and networks security courses need hands-on experiments to un-

derstand various concepts involved in them. An instructor either use a simulation

tool or an actual testbed to conduct the hands-on experiments for these courses.

Simulation tools provide an easy-to-configure and cost-effective environment. The

major limitation of the simulation tools is that the experiences and interfaces offered

by them do not match with the real-world experiences. In contrast to the simulation

tools, testbeds mimic real network and carry actual traffic, thus provide experiences

close to real-world. The experiments performed on a testbed help to understand the

concepts in a better way compared to the simulation tools.

Various challenges come across in a physical testbed set-up. A reasonable amount

of investment is needed in its set-up. Different users share the same testbed if the

testbed is created in a shared environment to make it cost-effective. In this settings,

the network configurations of one user can affect the others. In addition, a malicious

user can perform malicious activities on the other users’ files or system settings if

somehow gains an administrator privilege. A separate testbed for an individual can

help in performing the experiments without being affected by the malicious activities

102

of other users. Considering an academic set-up, provision of separate testbed becomes

expensive and a much extra effort is needed. Also, the connectivity of the testbeds

with the Internet to access them poses security threats to the public network. The

system viruses or malware can spread to the public network and affect a large number

of Internet users. The testbed can be installed in a segregated environment to reduce

the security threats, but it makes difficult to access the testbed from the remote.

With the growth of virtualization technologies such as VMware, Virtual Box,

Hyper-V, and Xen- testbed installation has become easier compared to its physical

deployment. These technologies motivated the instructors and researchers to develop

the testbeds using virtualization. The testbeds consist of several VMs connected with

each other through virtual networks. Although the virtualization technologies helped

a lot in the testbeds set-up, most of the testbeds are built over full-virtualization

in which a VM is a separate system from the host machine. The VMs run on top

of a hypervisor and access the host resources indirectly through it [101]. The VMs

built over full-virtualization are heavy-weight and utilize a lot of system resources,

therefore limit the number of VMs that a physical host can accommodate over the

hypervisor and restrict the number of testbed instances that a host can support.

In this work, we propose a light-weight testbed to overcome the scalability lim-

itation of previously deployed testbeds. The testbed simultaneously hosts several

virtual networks in a single physical infrastructure. The testbed is built with Linux

Container and Open vSwitch which are available under the open source license. Al-

though all the virtual networks share a single infrastructure, their network settings

and traffic do not interfere with each other. The testbed redirects a user to its virtual

network using its identity, and a user gets an instance of the physical infrastructure

with an illusion of owning a separate testbed. The proposed architecture is scalable,

cost-effective, and provides a simple management interface to the administrator. The

following section discusses various tools used for developing the testbed.

103

A.1 Tools Overview

We use Linux Container and Open vSwitch to implement our testbed. A brief dis-

cussion of these tools are as follows:

A.1.1 Linux Container (LXC)

LinuX Container is based on OS-level virtualization and allows to run a complete

Linux instance without a hypervisor. The LXC can run multiple instances of the

network services including web, DNS, and mail servers on a single host. Each LXC

executes in an isolated and secure environment. The LXC eliminates the need for ded-

icated systems to run those services and helps in effective utilization of the resources

and infrastructures. An LXC executes over the host kernel and shares the kernel

with the other LXCs. It makes an LXC light-weight compared to other virtualization

techniques including para-virtualization and full-virtualization [89]. An LXC relies

on the cgroup and namespace isolation which are component of the Linux kernel.

The cgroup is used to limit the CPU and memory usage along with the disk I/Os

by various LXCs running on a single host. The root privilege separation, separate

file system, and network isolation features of an LXC make it a suitable tool for the

testbed implementation.

A.1.2 Open vSwitch

Open vSwitch (OVS) is an open source implementation of an Ethernet switch which

can also serve as a multilayer virtual switch with the help of programmatic extensions

[66]. The main design aim of OVS was to use it in a virtualization environment for

traffic forwarding within the VMs within the same physical host or network. It can run

on several Linux-based virtualization environments including Virtual Box, Xen, Xen

Cloud Platform, and Xen Server; and can be ported to other environments as well.

104

It can be operated as a software switch running inside a hypervisor or a control stack

for programmable switches in the SDN. Although it has various features which are

available in the traditional hardware switches, the features such as Layer-2 switching,

VLAN trunking, and Generic Routing Encapsulation (GRE) tunneling are exploited

in the testbed implementation.

A.2 The Testbed Architecture, Management, and

Access

The testbed offers multiple co-existing instances of a physical network as separate

virtual networks to the users. The implementation of such a testbed must fulfill the

following requirements:

• Each user should be oblivious of the presence of the other users’ virtual networks

that co-exist in the same infrastructure.

• There must be a traffic isolation among different virtual networks.

• The traffic of one virtual network should not be affected by the configuration

of other virtual networks.

• There must be a simple interface to access the virtual networks using tools such

as SSH and VNC.

• An automated system should be there to configure and manage the testbed.

A.2.1 Testbed Architecture

An LXC is created for each virtual host on the underlying host of the infrastructure.

The virtual host is assigned to a particular user. The underlying host can be a physical

105

Figure A-1: The testbed with two virtual networks on an infrastructure of three physical hosts. Each virtual network has a virtual host corresponding to the physical host.

host or a virtual machine, but we will refer it as a physical host from now onward in

the chapter. The virtual host has a similar network configuration corresponding to

its physical host. An OVS bridge is created for each network interface in the physical

host except the management network interface. Each network interface is attached

with its corresponding OVS. The management network interface is used to connect

the physical host with the gateway host. The gateway host is used by the users

and administrators to access the testbed. The users access the testbed to perform

their hands-on assignments, whereas the administrator accesses the physical hosts to

manage the virtual hosts running inside them. Each virtual host is assigned a virtual

network interface corresponding the network interface of its physical host. The virtual

network interfaces have two ends in which the one end is attached to a virtual host

and another end is attached to the OVS.

The VLAN feature of an OVS is used to isolate the traffic of a virtual network

106

from the others. All the virtual hosts for a particular user are assigned a unique

VLAN number on all the physical hosts. A unique VLAN number for all the virtual

hosts makes them a part of one virtual network and separates the virtual network’s

traffic from the traffic of other virtual networks [103]. The GRE tunneling is used

to confine the traffic within the testbed [20]. A GRE port is created on each OVS

and associated with the remote IP of the neighbor physical host for the same subnet.

This approach helps in separating the testbed traffic from the public network.

The architectural diagram of the testbed is shown in Figure A-1 for a physical

network with three hosts. The connectivity of the testbed with the gateway host is

not shown in the figure. There are two virtual networks created on the testbed for

illustration. The virtual host 1 on all the physical hosts and their connectivity create

the virtual network for one particular user. Similarly, all the virtual host 2 and their

connectivity create another virtual network. A unique VLAN number is assigned

to each virtual network. GRE tunneling between two neighbor hosts is shown in

Figure A-2. Management network interfaces are not included in the GRE tunneling;

therefore the testbed traffic is confined within the testbed environment and remain

separated from the public network.

A.2.2 Testbed Management

An automated system is used to monitor and manage the virtual networks. The

gateway host is used as an administrator host as well as a gateway for the users to

access the testbed from the Internet. The gateway host has two network interfaces,

one is used to connect it to the management network of the testbed and other con-

nects it to the public network. The management architecture of the testbed is shown

in Figure A-3. The management interface is designed based on the assumption that

a virtual network is an instance of the physical network. We have a pre-configured

LXC in every physical host used as a template to create a new virtual host in it. The

107

Figure A-2: The GRE tunneling between two hosts in which hosts are tun- neled with the remote IP of each other

template LXC has the same number of network interfaces as its physical host has,

excluding the management network interface. Various network utilities and services

are installed in the LXC template. A startup script is used to configure the OVS

switches for a large range of VLAN ports on every host. A large range of IP ad-

dresses is maintained on every physical host similar to the DHCP service that helps

in assigning IP addresses to the virtual hosts. The virtual and physical hosts share

the same subnets. All the physical hosts run a daemon process vnetd for manage-

ment. The administrator connects with every vnetd server using a vnetc client at the

gateway shown in Figure A-3. These applications are written in Python with a few

additional bash scripts. The administrator executes vnetc to perform the following

tasks in the current implementation:

• Add a virtual network : The administrator executes vnetc using the command

vnetc add user. A connection is established with vnetd server on each host

and the arguments are parsed to add a virtual host for a user. A user and

108

Figure A-3: The administrator and users access the testbed from the Gate- way host. The administrator uses vnetc client application to access.

its virtual host are created on the physical host. vnetd uses the lxc-clone

feature to create a new virtual host. IP addresses are assigned to the interfaces

of the virtual hosts from the available IPs in the maintained IP addresses list.

The host name of a virtual host is kept same to its corresponding physical host

to create an illusion that each user owns a dedicated testbed. An entry for

the new user and its virtual host is made into user.conf configuration file by

vnetd that helps in redirecting the user to its virtual host once it accesses to

the physical host.

• Delete a virtual network : An existing virtual network is deleted for a user when

the administrator executes vnetc using the command vnetc del user. The

vnetd daemon on each physical hosts parses the arguments to delete a user. It

finds the name of the virtual host corresponding to the user in the user.conf

file. The virtual host and user account are deleted from the host. vnetd uses

the lxc-destroy feature of LXC to delete a virtual host. The entry for the user

109

Figure A-4: A testbed infrastructure implemented on a VMWare ESXi host with a network topology used in V-NetLab [40].

and its virtual host is removed from the user.conf file.

• Monitor a virtual network : The administrator executes vnetc using the com-

mand vnetc monitor user to monitor a virtual network of a user. The vnetd

server parses the arguments and sends the status of a running virtual host with

its IP to vnetc. It uses the lxc-ls feature to perform this task. vnetc shows

the status received from the vnetd servers for all the virtual hosts for the given

user.

A.2.3 Remote Access

A user accesses its virtual hosts in the testbed using the gateway through an SSH client

shown in Figure A-3. All users are given access to the testbed through the gateway

without any root privilege in it. A log-in bash script on every physical host is used to

110

find the user identity during the SSH log-in. The script checks the user.conf file for

the user and finds the corresponding virtual host for it if it is not an administrator

log-in. The user is then automatically redirected to its virtual host console. The user

can configure its network services and execute various system commands without

affecting the other users after log-in to its virtual host. An administrator accesses the

physical hosts directly to manage and monitor the virtual hosts and users on them

using vnetc.

A.3 Discussion

We provide a light-weight testbed environment with our implementation. However,

there are a few important issues that need to be discussed. First, the LXC provides a

virtualized environment around Linux-based OS. A virtual host runs a Linux instance.

However, it should not be considered as a limitation for the testbed to use a Linux-

based OS as Linux is an open-source, customizable, and provides a closer view of an

OS and its kernel to the user. These properties of Linux made it widely acceptable

in academics for research and teaching.

The second issue with the OS-based virtualization, as used in the LXC, is that the

virtual hosts share the physical host kernel. A vulnerable system call present in the

physical host can be exploited by a malicious virtual host and would give it access to

the physical host and other virtual hosts. However, these threats can be minimized

with the use of AppArmor, SELinux, SMack, and Seccomp features [48]. An LXC

could be restricted to run kernel-based network services such as an NFS server. This

issue could be addressed using the userspace version of the same services.

Finally, we offer an instance of the physical network to a user in the current imple-

mentation. This model might be considered as scalable, but less flexible. However, we

provide the testbed to the users of a particular network and security course with an

111

assumption that same hands-on experiments are assigned to each user in the course-

work. We can create an underlying physical network for the testbed with different

topology using Manage Large Networks (MLN) [55] or the network configurator of

V-NetLab [40].

A.4 Related Work

The virtualization technologies have been used by many institutes to develop the

testbeds for hands-on experiments. Most of them use full-virtualization along with a

few additional middle-ware. V-NetLab offers a virtual network lab with a few VMs to

its users [40]. A text-based script is used to provide the network configuration which is

analyzed for its syntactic correction. A virtual network is created for a user following

the network configuration specified in the script. Data-link layer virtualization is

used in it to isolate the virtual networks from the public network [92]. SOFTICE has

a load-balanced cluster of the PCs and Warewulf [3] has been used in it. The user

connects with a master node which also serves as a gateway, and is redirected to one

of the PC of the cluster. The user is provided with a network configuration file on the

PC. The configuration file is used by the MLN utility to create a virtual network using

UML/Xen on that PC. Iowa State University installed Xen Worlds for the Information

Assurance program [2]. A virtual lab environment is provided to on-campus and off-

campus students using the Xen World. Xen server is used at its core along with

pdmenu- a menu-driven SSH client interface to access it from the remote. V-Lab is a

flexible and re-configurable cloud based virtual network laboratory [111]. It also uses

Xen server and VLAN supported physical switches to isolate the virtual networks.

The instructors use a GUI-based web interface to configure a virtual network. The

students access the virtual network via SSH, VNC or RDP. VNLab is another testbed

that uses Microsoft Virtual Server to implement a virtual laboratory [14].

112

Unlike those approaches, light-weight OS-virtualization and OVS have been used

in our testbed to accommodate a large number of virtual networks. The SDN emula-

tor known as Mininet also uses light-weight virtualization by exploiting the network

namespace features similar to the LXC along with the OVS [42]. However, it is

used for prototyping the SDN and provides an emulation environment for the same.

The virtual hosts in Mininet share the host file systems, therefore changes in system

configuration for the host can be reflected in all the virtual hosts.

A.5 Chapter Summary

We discussed the implementation of a light-weight testbed architecture to support

the networks and security experiments and published the work in [61]. The testbed is

aimed at deploying a large number of virtual networks over a single infrastructure with

limited resources, thus makes the testbed deployment more scalable. We have ported

V-NetLab in our testbed using VMware ESXi host shown in Figure A-4. We found

that the testbed was able to accommodate several virtual networks simultaneously

with a reasonable usage of resources. We asked a few graduate students to use this

testbed voluntarily who have already used V-NetLab for their course work in the

previous semesters. They performed the same lab assignments as were given to them

in their course work such as topology discovery, network services configuration, traffic

monitoring, and firewall/IDS configuration. The experience was found similar to what

they had in the V-NetLab. We have successfully used the testbed for various network

and system courses for last few semesters.

113