Simulative Evaluation of Security Monitoring Systems based on SDN

IN

DEGREE PROJECT ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2016,

Simulative Evaluation of Security Monitoring Systems based on SDN

ALEXANDRA STAGKOPOULOU

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

School of Information and Communication Technology (ICT) KTH Royal Institute of Technology

Degree Project in Electrical Engineering

Simulative Evaluation of Security Monitoring Systems based on SDN

Alexandra Stagkopoulou, {stagk@kth.se}

Examiner: Markus Hidell Supervisor: Peter Sjödin KTH, Royal Institute of Technology

Industry Supervisor: Marco Tiloca SICS, Swedish ICT

Stockholm, 2016

i

ii Abstract

Software Defined Networks (SDN) constitute the new communication paradigm of programmable computer networks. By decoupling the control and date plane the network management is easier and more flexible. However, the new architecture is vulnerable to a number of security threats, which are able to harm the network. Network monitoring systems are pivotal in order to protect the network. To this end, the evaluation of a network monitoring system is crucial before the deployment of it in the real environment. Network simulators are the complementary part of the process as they are necessary during the evaluation of the new system’s performance at the design time.

This work focuses on providing a complete simulation framework which is able to (i) support SDN architectures and the OpenFlow protocol, (ii) reproduce the impact of cyber and physical attacks against the network and (iii) provide detection and mitigation techniques to address Denial-of-Service (DoS) attacks. The performance of the designed monitoring system will be evaluated in terms of accuracy, reactiveness and effectiveness.

The work is an extension of INET framework of OMNeT++ network simulator.

Keywords: SDN; Security; (D)DoS attacks; Monitoring System; OMNeT++; INET

iii Sammanfattning

Software Defined Networks (SDN) utgör den nya kommunikationsmodellen av programmerbara datornätverk. Genom separation av kontroll- och dataplanet blir administrativ hantering av datornätverk enklare och flexiblare. Arkitekturen öppnar emellertid upp nya säkerthets hot, övervakningssystem är därför väsentliga för att skydda datornätverk. Till följd av detta är utvärdering av övervakningssystem kritiskt innan driftsättning i produktionsmiljö. Nätverkssimulatorer är den kompletterande delen i processen då de är nödvändiga för utvärdering av systemets prestanda under design fasen.

Detta arbete fokuserar på att tillföra ett komplettet simulations ramverk vilket är kapabelet till; (i) ge stöd för SDN arkitekturer och OpenFlow protokollet, (ii) reproducera skadegörelsen av cyber- och fysiska attacker mot datornäterk och (iii) förse sätt att upptäcka och mildra Denial-of-Service (DoS) attacker. Prestanda av det designade övervakningssystemet är utvärderat i form av exakthet, responstid och effektivitet. Arbetet är en utvidgning av INET ramverket, som är del av OMNeT++ network simulator.

Nyckelord: SDN; Säkerhet; (D)DoS attacks; Övervakningssystem; OMNeT++; INET

iv Acknowledgments

I would like to express my gratitude to my supervisor at SICS, Swedish ICT, Marco Tiloca for the endless support and guidance during this project. Moreover, I would like to thank my supervisor and examiner at KTH, Royal Institute of Technology, Peter Sjödin and Markus Hidell for their valuable feedback and help. Last but not least, I am thankful to my family and friends for their patience and support during this thesis.

v

Table of Contents

List of Figures ... viii

List of Tables ... x

Abbreviations and Acronyms ... xi

1. Introduction ... 1

1.1. Motivation ... 2

1.2. Problem: SDN Security Risks ... 2

1.3. Problem Statement ... 3

1.3.1.Simulative approach of security attacks against SDN ... 4

1.3.2.SDN-related security risks: Why DoS? ... 4

1.4. Goal and Objectives ... 4

1.5. Methodology ... 5

1.6. Outline ... 7

2. Background ... 8

2.1. Towards... Software Defined Networks (SDN) ... 8

2.2. Software Defined Networks (SDN) ... 9

2.3. OpenFlow Protocol ... 10

2.4. SDN and Simulative Approaches ... 11

2.4.1. OMNeT++ & INET ... 12

3. SDN-based (DDoS) Security Monitoring ... 13

3.1. Statistics Collection ... 13

vi

3.2. Attack Detection ... 16

3.3. Mitigation ... 17

3.4. Selected Methods ... 20

4. A use-case SDN Security Monitoring System ... 21

4.1. SDN support in INET framework ... 21

4.2. New Controller Overview ... 24

4.3. Statistics Collection ... 26

4.4. Attack Detection ... 26

4.4.1. Entropy Algorithm ... 27

4.5. Mitigation ... 30

5. Simulative Evaluation of Attacks, SEA++ ... 31

6. Evaluation... 34

6.1. Topology and Traffic Scenario ... 34

6.2. Defining Entropy Threshold... 35

6.3. Experimental Overview... 36

6.4. Total number of Received Packets per second ... 37

6.4.1. Fixed Statistic Collection Intervals ... 38

6.4.2. Fixed Attack Rate ... 40

6.5. Entropy Value ... 42

6.6. Conclusion Remarks ... 45

vii

7. Discussion and Conclusion ... 47

7.1. Limitations ... 48

7.2. Future Work ... 48

7.3. Benefits, Economic & Environmental, Social & Ethical Aspects ... 49

7.3.1. Benefits ... 49

7.3.2. Economic and Environmental Aspects ... 50

7.3.3. Social and Ethical Aspects ... 50

7.4. Conclusion ... 50

8. References ... 52

viii

List of Figures

F

1: SDN

. T

. T

O

F

. ... 1 F

2: M

. ... 6 F

3: SDN

SWITCHES

. T

. ... 9 F

4: T

BETWEEN THE CONTROL AND DATA PLANE

. ... 9 F

5: O

F

API. T

CONTROLLER AND THE FORWARDING DEVICES

. ... 10 F

6: T

SYSTEM

... 13 F

7: A

P

O

F

-

M

. (

) P

M

: W

,

. (

) A

M

:

. ... 13 F

8: R

INET

. . 22 F

9: R

O

F

-

INET

. .... 22 F

10: N

INET

FRAMEWORK

. ... 24 F

11: P

. ... 25 F

12: A

D

A

... 29 F

13: S

ASL

SEA++

ATTACK SIMULATOR

. ... 32 F

14: T

SEA++. T

HAVE BEEN ENHANCED WITH THE

LEP

,

ix TRAVELING THROUGH THE STACK

. GEP

. ... 32 F

15: T

. T

1 OF

1

CENTRALIZED CONTROLLER

. T

4

3

. C

3

2

-

. ... 35 F

16: T

30

. ... 38 F

17: T

15

... 39 F

18: T

POLLING INTERVAL

45

. ... 39 F

19: T

POLLING INTERVAL

60

. ... 40 F

20: T

RATE OF

14

. ... 41 F

21: T

ATTACK RATE OF

25

. ... 41 F

22: T

ATTACK RATE OF

40

. ... 42 F

23: E

14

POLLING INTERVALS

... 43 F

24: E

25

POLLING INTERVALS

. ... 44 F

25: E

40

POLLING INTERVALS

. ... 45

x

List of Tables

T

1: S

. ... 37

xi

Abbreviations and Acronyms

API Application Programming Interface

ASI Attack Specification Interpreter

ASL Attack Specification Language

CPU Central Processing Unit

DoS Denial of Service

DDoS Distributed Denial of Service

GEP Global Event Processor

ICMP Internet Control Message Protocol

IP Internet Protocol

LEP Local Event Processor

MPLS Multiprotocol Label Switching

OF OpenFlow Protocol

OMNeT++ Objective Modular Network Testbed in C++

OS Operating System

OSI Open Systems Interconnection model

OSPF Open Shortest Path First

RAM Random Access Memory

SDN Software Defined Network

xii SEA++ Simulative Evaluation of Attacks

SOM Self-Organizing Maps

TCP Transmission Control Protocol

TLS Transport Layer Security

UDP User Datagram Protocol

XML Extensible Markup Language

xiii

1

1. Introduction

Nowadays, it is the new era of networks which is defined by the Software Defined Networks (SDN) paradigm [1]. By decoupling the control and data plane, the underlying switches or routers become simple forwarding devices and the logic is implemented in a software programmable centralized controller. The given opportunity of software programmable networks leads the researchers to deploy more flexible protocols, build new systems and efficiently manage the networks [1]–[3]. However, the infrastructure has been proved to be vulnerable to attacks [4], so the demand of security monitoring systems is even higher. In particular, Distributed Denial of Service (DDoS) attacks can be considered a severe threat as they can easily exhaust the bandwidth between the control and data plane and lead to increased packet loss and overall network congestion, as [4], [5] show. Even in such context, the need for reliable simulation tools increases, because it is inconvenient to apply a new system design directly into the real network without validation of its legitimacy. Network simulators constitute a safety net for evaluation of experimental efforts, as the new implementation can be thoroughly tested under various network conditions and different network infrastructures. It is hence desirable to have a complete simulation tool, which makes it possible to evaluate the performance of an SDN- based network, as well as the effectiveness, efficiency and reactiveness of security solutions for attacks carried out against the network.

Figure 1: SDN architecture. The separation of control and date plane and the implementation of the logic in a software centralized controller. The communication between the controller and the switches is based on the OpenFlow protocol.

2 1.1. Motivation

When it comes to the evaluation of a security monitoring system in terms of robustness and efficiency against security attacks, it is pivotal to assiduously test the anomaly detection system before the real deployment. The designer should be aware of the network communication performance, the effects and the impact of the attacks against the network and finally, the effectiveness and the accuracy of the deployed system. Thus, network simulators are essential part of the deployment as they constitute a practical tool to assess the designed system and especially, use it to represent large-scale networks and test them against security threats.

Many studies [6]–[11] proposed monitoring systems and mitigation techniques regarding the identification of the attacks and the protection of the SDN network respectively. Observing the deployment approaches of the proposals, all the above works have a three-part common structure. The first part is the implementation of the proposed algorithm, framework or system based on existing implementations of centralized controllers combined with network emulators in order to present a functional representation of an SDN-based network. The second part is the selection of tools or design of them in order to describe attack scenarios and evaluate their impact on the network and the applications. Finally, the merger of the two previous parts is followed in order to create a complete tool and evaluate the robustness and reliability of the network during the design time.

The current lack of an existing simulation tool, which is able to evaluate the performance of a SDN-network, the impact of cyber and/or physical security attacks against the SDN architecture and finally, the effectiveness and reactiveness of security monitoring and mitigation techniques makes the validation of a new SDN-based security system process more complex.

1.2. Problem: SDN Security Risks

Taking into consideration the architecture of SDN and the OpenFlow protocol, it is not difficult to recognize the vulnerabilities and the critical aspects of them with respect to security. Apart from the traditional types of attacks such as the exploitation of vulnerabilities of the forwarding devices or administration stations, attacks against the

3 network or compromised traffic flows in the data plane of the switches [12], SDN enables new kinds of security attacks, which can aim either at the centralized controller, the virtual infrastructure or the OpenFlow protocol itself [12], [13].

How secure OpenFlow is, is examined in [4] where the authors analyze the security of the protocol under the STRIDE methodology [12]. The results show the vulnerabilities of the protocol against Information Disclosure and Denial-of-Service (DoS) attacks. The lack of TLS protocol usage between the centralized controller and the OpenFlow-enabled switches enhances the sensitivity of the protocol under Information Disclosure attacks, which help the attacker to discover, invisible otherwise, services on the network. On the other hand, the communication link between the controller and the switches can be easily saturated under a DoS attack leading to increased packet loss and overall network congestion.

In DoS attacks and especially in DDoS attacks, where multiple compromised clients are used to generate traffic, a large amount of packets are destined to a specific host. As the name indicates, the purpose of the attack is to make the services of the host unavailable. Usually, during such an attack the source IP address is spoofed and as a result, each flow request is unique. When this attack is applied in SDN networks, the adversary can easily exploit the fact that every new incoming unmatched packet is sent to the controller. By flooding unique flow requests, the result is to saturate the communication path between the controller and the switches as well as affect the limited buffering capacity of the switches. The first option can be easily achieved in case where the switch sends to the controller the whole new incoming unmatched packet, while the second option can be accomplished when the switch buffers the packet and sends only the packet header to the controller. An exclusive investigation about how the protocol behaves in the presence of a DoS attack is conducted in [5] and specifically, it is presented how the bandwidth between control and data plane as well as the switches’ memory can be exhausted due to the large number of new incoming unmatched packets.

1.3. Problem Statement

The current degree project points out two main issues, which are related to the simulation of security attacks against software defined networks as well as the design and

4 the implementation of a network security monitoring system, which addresses DoS attacks.

1.3.1. Simulative approach of security attacks against SDN

Inspired by the motivational observation, there is not a present simulation framework able to support the simulative approach of security attacks against SDNs. As it was mentioned in the above section, currently the designers need to design and evaluate the impact of the security attacks using extra software tools and thereafter integrate the attack scenario in the network testing the monitoring system. This work will investigate the provision of a single simulation framework able to support the simulation of security attacks’ impact against a SDN-based network security monitoring system.

1.3.2. SDN-related security risks: Why DoS?

Among all the present security threats and vulnerabilities of the SDN architecture, this thesis will study the effects of (D)DoS attacks, a severe threat against SDNs not only because the architecture of the network itself is more sensitive to this type of attacks, but also, the result of this threat can be twofold. While a specific host is targeted, at the same time the path between the controller and the switches, a.k.a. saturation attack, or the memory capacity of the devices are affected by the flooding of injected messages. What the effects of the attack on the victim are as well as the factors, which determine the performance of a network security monitoring system will constitute the main research topic of this work.

1.4. Goal and Objectives

The aim of this work is to build a comprehensive simulation framework allowing the evaluation of the impact of security attacks against a Software Defined Network architecture and providing as well security monitoring and mitigation techniques. In particular, the simulation tool must be able to:

 Support the SDN architecture and the OpenFlow protocol

 Reproduce the impact of security attacks

 Support SDN-based monitoring systems to address (D)DoS attacks

In order to do so, an enhanced version of the INET framework [14] built on top of OMNET++ discrete event simulator [15] will be presented. The attack simulator SEA++

5 [16], [17] will be used to reproduce the effect of attacks on the network. The SEA++ attack simulator will be extended in order to support SDN architectures and the specifications of the OpenFlow protocol. Appropriate OpenFlow communication messages will be included as well as necessary functionalities will be implemented such as the detection and mitigation modules.

We will rely on the developed tool in order to evaluate monitoring and mitigation techniques in the presence of Denial of Service (DoS) attacks in terms of accuracy and reactiveness as well as the resulting impact on the network infrastructure.

The purpose of the project is to prove the support of SDN architectures into the attack simulator SEA++ in order to show the simulative approach of attacks against such networks and secondly, the design of a simple security monitoring system based on selected methods in order to demonstrate the quantitative evaluation of a system’s performance under attacks.

1.5. Methodology

For the purposes of this work both quantitative and qualitative research methods will be applied based on [18]. This work is about an experimental effort to build a comprehensive simulation framework able to support a number of monitoring and mitigation techniques and evaluate them under different attack scenarios.

First of all, our implementation will be based on the two already existing works [17], [19] combining and extending them in order to achieve our specific goals. As soon as the integration of the OpenFlow and SDN support in SEA++ simulator will be completed, a qualitative research method will be applied afterwards. A literature study will be conducted in order to review existing works and select the most appropriate monitoring, detection and mitigation techniques that will be included in the tool and constitute the use case monitoring system which will be tested. The final decision and selection among the current works will be based on the comparison of the works regarding their performance, complexity and efficiency as well as the needs of this work.

After the implementation and integration of the selected methods in the tool, an evaluation of them will be performed. For this purpose, the quantitative research method

6 will be adopted and an experimental approach will be conducted. As there is no hypothesis to be confirmed or falsified an iterative process will be followed in order to assess and study the selected monitoring options in terms of efficiency, effectiveness and reactiveness under different tuned attack scenarios. DoS attack scenarios will be designed and the performance of the designed system will be evaluated under specific configuration parameters. The results will be analyzed based on the specific attack scenarios constituting the proof of concept without indicating the generalization of them under all the kind of attacks.

The sequence of the steps which will be followed during this work is presented in the below diagram.

Figure 2: Methodology flowchart.

Add SDN and OF support in

SEA++

•Extend SEA++ to support SDN architectures and OF.

Literature

study •Study current works

Selection of methods and

techniques

•Select methods to be implemented to constitute the use case monitoring system

Design a use case SDN-based

monitoring system •Implementation of the selected methods

Design the attack scenario

•Design tuned DoS attacks in different attack rates

Evaluate the implemented

system

•Evaluate the performance of the designed system in terms of effectiveness and

reactiveness

7 1.6. Outline

The rest of the work is organized as follow: Chapter 2 presents in a more detailed way the background about the SDN architecture. Chapter 3 describes existing works which are related to SDN-based monitoring systems. Methods and techniques are presented regarding the collection of the statistics, the attack detection and finally, the attack mitigation. In chapter 4, the implemented monitoring system is described. How the selected methods are adopted and implemented is shown in this chapter. The description of the attack simulator SEA++ is illustrated in chapter 5. The experimental results are shown in chapter 6. Finally, chapter 7 concludes the work discussing the benefits, the limitations, the economic, environmental, social and ethical aspects of the current work.

Future extensions and improvements are also included in the chapter.

8

2. Background

In this chapter, a brief description of the transition to the new era of Software Defined Networks will be presented as well as a more detailed illustration of the new network architecture. What it is, how it works and how we can simulate such architectures will be discussed.

2.1. Towards... Software Defined Networks (SDN)

Researches show that traditional networks have presented limitations and restrictions regarding their flexibility to be managed [20]–[22]. Especially, in large enterprise networks where the devices vary from switches and routers to middleboxes, such as firewalls, load balancers and intrusion detection systems and the configuration of each one is based on the vendor-closed specifications. For example, in an ISP Tier-1, the configuration files of the devices can reach thousands of lines of commands describing complex policies and routing decisions. Administrations should follow vendor-dependent configurations based on the equipment and that imposes more difficulties and challenges in infrastructure maintenance. It is mandatory for them to be specialists with the specifications of each vendor in order to configure and troubleshoot the device. The process of manual configuration has been proved in [20] that is time consuming, complex and also, sensitive to human errors.

In order to illustrate all the boundaries, the costs and the complexity of traditional network services in an enterprise network, a survey is conducted in [23]. The results show that the most common cause of failures is based on human errors due to misconfigurations. The complexity of the devices contribute to the increased errors, because heterogeneous platforms require management expertise. The strict vertical integration between the control and data plane of the traditional device’s architecture involves the transformation of high level policies to low-level configuration commands, hence the innovation of new protocols or more complex routing decisions are difficult to be implemented. The answer to the question how network infrastructure can be more manageable give the authors in Ethane project [2], where they present the concept of programmable networks using a centralized controller. Ethane constituted the base of

9 Software Defined Networks revolution and led to be the ancestor of the dominant OpenFlow protocol [1].

2.2. Software Defined Networks (SDN)

Software Defined Networks (SDNs) have become the new paradigm in network design and constitute the result of extensive research regarding the simplification of network management [2], [3], [24]. By decoupling the control and data plane, the underlying switches or routers become simple forwarding devices while the control logic is implemented in a software programmable centralized controller. The controller is responsible to decide how the traffic will be handled and notifies the switches by installing forwarding rules. Thus, a single program is able to control multiple data-plane devices located within controller’s scope. Figures 3 and 4 illustrate the comparison between the strict vertical structure of control and data plane on traditional switches with the new architecture defined by SDN paradigm. Having the view of the whole network topology and the ability to control the network from a centralized point, SDN makes network monitoring more accurate and network management more efficient [13], [25]. SDN empowers the researchers to design more flexible and innovative protocols avoiding

Figure 3: Traditional network switches which indicate the vertical dependency between the control and data plane.

Figure 4: SDN topology where the centralized controller interacts with the switches. The switches act as simple forwarding devices.

10 vendor-depended configurations [26], since they do not have to configure each device individually but they take traffic forwarding decisions form a centralized point instead and by referring to a single common API (i.e. OpenFlow protocol).

Many implementations of centralized controllers have been developed. Indicative examples are POX [27] and RYU [28] whose implementation is based on Python, OpenDayLight [29] and Floodlight [30], which are implemented in Java and finally, NOX the first implemented controller [31]. Scalability issues between the controller and the switches can be solved by using multiple, distributed controllers, such as ONIX [32], ONOS [33] and PANE [24]. Even if there were doubts about the performance and the scalability of the new architecture [34], [1] proved that SDN is able to form future networks. By identifying the benefits of the new proposed architecture, industry has also started integrating SDN in their enterprise networks such as Google with B4 project [35]

and Andromeda [36]. The open source OpenDayLight project and the Open Networking Foundation [37] have motivated many companies to support and include SDN principle in their networks [38], [39].

2.3. OpenFlow Protocol

OpenFlow protocol [40] is the first standard implementing the SDN concept both in software and hardware [37] and is the preponderant implementation of southbound interface between the forwarding devices and the centralized controller as indicating in Figure 5. Providing a well-defined Application Programming Interface (API) enables researchers to implement new ideas, run experiments and design networks composed of heterogeneous devices, while being unaware of vendor-dependencies.

Figure 5: OpenFlow API. The dominant southbound interface between the controller and the forwarding devices.

11 The OpenFlow protocol is flow-based oriented. Each OpenFlow switch contains one or more flow tables of multiple flow entries. Each flow entry contains multiple fields such as the match and instruction fields, the lifetime duration and the priority of the rule and counters about the matched packets. When a forwarding device receives a new packet, it looks for an appropriate flow entry in the flow table, which matches to the flow the packet belongs in. The comparison between the incoming packet and the match fields of the flow entry is basically based on the ingress port and packet headers. If there is such a rule, then the switch will forward the packet according to the instructions defined within the instructions field of the rule. In case, there is no flow entry defining how to forward the packet, the switch sends the packet to the controller using an OpenFlow message asking for forwarding instructions. The controller is responsible to take the correct decisions about the handling of such packets and informs the switch by installing a new flow entry in the flow table. The switch is now aware of the way to process future incoming packets, which match the recently installed rule. The rule is removed either by a forced decision by the controller or due to expiration of the timeout interval.

2.4. SDN and Simulative Approaches

Considering the benefits of the network simulators as well as the new era of SDN, it is seem that limited works have been conducted regarding the integration of OpenFlow protocol in simulation tools. An effort is being under development in order for the OpenFlow protocol to be included in ns-3 simulator [41]. Yet, only a very early version of OpenFlow is supported, v.0.89, which is quite old since the current version of the protocol is v. 1.5.1 [42]. EstiNet [43], [44] is a network simulator and emulator supporting multiple versions of OpenFlow protocol compatible with a collection of multiple controllers, such as POX [27], Ryu [28] and OpenDayLight [29]. It provides the possibility to simulate SDN architectures by choosing the desired controller without any modification on it. According to the official reference of the project, it is considered “the most accurate, fast, scalable, and useful OpenFlow network simulator and emulator in the world” [43]. However, it is not an open source project but a commercial one.

One interesting proposal has been presented in [45], where the authors integrate the OpenFlow protocol v. 1.0 [46] in INET v.2.0. framework [14], [47] of OMNET++, the discrete event simulator [15]. The authors consider OpenFlow switches, OpenFlow

12 controllers and the most important OpenFlow messages, which are exchanged between the controller and the switches in order to extend the already existing and well-known simulator with the support for OpenFlow features. As a result, the integration of the protocol in the framework has been implemented offering now the possibility to simulate OpenFlow-enabled devices and represent SDN architectures by means of a single simulation tool. Yet, none of the above works provides the possibility to perform and evaluate attacks against the network.

SEA++, Simulative Evaluation of Attacks, [16] allows the reproduction of the effects of both physical and logical attacks on the network by describing attacks through a high level description language without altering the actual simulation platform. It is a complete tool for simulative evaluation of attacks’ impact related to two previous works [48], [49]. SEA++ is based on the discrete event INET v.2.6 framework built on top of the OMNET++ and according to the authors is a flexible and easy to use tool. The interesting part of the tool is that it reproduces the effect of successful attacks allowing a quantitative evaluation of their impact, while it does not consider the actual way attacks are mounted.

This makes it possible to model the effects of successful attacks without concerning about their actual implementation and hence focusing on the evaluation of their impact. SEA++

has been tested in traditional and wireless sensor networks but not in SDN.

2.4.1. OMNeT++ & INET

INET framework is an open source library, which provides support for the simulation of communication networks. The representation of the OSI stack is given including Internet transport and routing protocols such as TCP, UDP, OSPF and MPLS.

The framework is available to the users to extend and design new protocols and network scenarios. INET simulation framework is based on OMNeT++ discrete event simulator.

OMNeT++ is a C++-based library able to support the addition of network simulators on top of it. The modeling of the library is based on components and the communication among them is based on messages. More information about the frameworks can be found at https://inet.omnetpp.org/ and https://omnetpp.org/ respectively.

13

3. SDN-based (DDoS) Security Monitoring

In order to prevent an attack against the network, an effective security monitoring system should be built. The system is responsible to collect traffic information, analyze it and possibly identify the threats against the network. In case, a threat has been recognized, the system should try to mitigate the attack. The required components for successful network monitoring system can be categorized as: (1) Collection of the statistics, (2) Analysis of the collected data and detection of attacks and (3) Mitigation techniques to neutralize the ongoing attacks. In the following sections, different techniques and methods considered for the above components will be presented.

3.1. Statistics Collection

In order to identify an anomaly within the network, a continuous monitoring is needed. Two prominent approaches can be adopted regarding the monitoring over SDN:

(a) (b)

Figure 7: Active and Passive OpenFlow-based Monitoring. (a) Passive Monitoring: When the flow expires, the switch sends the collected data to the controller. (b) Active Monitoring: the controller periodically requests the current values of the counters.

Figure 6: The three components which constitute the network monitoring system

(a) (b)

14 (i) flow-based and (ii) packet sampling-based approach. Taking advantage of the features of the OpenFlow protocol itself, flow-based monitoring approaches can be implemented either in a passive or an active way, as Figure 7 presents. During passive monitoring, when a flow entry is expired in the flow table of the OpenFlow switch, the counters regarding the collected statistics of the specific flow are sent to the controller. On the other hand, during active monitoring, the controller periodically requests the current values of the counters of all flows and each switch replies with the corresponding message.

Both approaches present strengths and weaknesses [50]. In the latter, the increased overhead between the data and control plane path is obvious as the controller periodically requests the statistics and the switches reply to that. If the system is under attack, and especially a DDoS attack, the new incoming unmatched packets are excessive in number and all of them should be sent to the controller in order for the switch to receive instructions of how it will forward the packets. Adding these amount of messages in the data-to-control plane path and including the periodic statistics request, the controller will be finally collapsed and part of the system will be frozen under the hands of the adversary.

However, this way of statistics collection can be very accurate since there is timely overview of the network’s status. Depending on the collection frequency and a fine-grained monitoring an early detection of an attack can be achieved.

As it was mentioned above, the passive monitoring reduces the overhead in the control-data plane path because the number of required messages is smaller. Yet, it leads to a delayed detection of the attack, because the switch informs the controller only when a flow entry is expired. Depending on the defined lifetime of a flow entry, the controller can be informed about the counters’ values sooner or later. A tradeoff between the overhead in the data-to-control plane path and the monitoring accuracy exists. When a rule has a short lifetime duration, as soon as it is expired the controller collects the information for the statistics too. However, on the next incoming packet related to that flow, the switch requests again forwarding instructions, because the previous rule has been removed. As a result, messages between the controller and the switches are added. On the other hand, setting longer timeout intervals requires less communication between the switches and the controller, but the controller collects the statistics later. Consequently, setting parameters in the order to properly achieve both accurate monitoring and good system performance is very challenging.

15 An alternative to the above methods is the approach based on packet sampling.

sFlow [51] was introduced in order to achieve an accurate monitoring on traditional networks by retrieving statistical packet-based samples of the switch’s flows according to different rates. When a packet arrives on the switch, filtering policies on the switch itself determine whether the packet should be sampled or not. The decision is based on a rule defining the sampling rate. If the packet should constitute a sample, then either the whole packet or part of it is sent to the next module for analysis. The collected samples are sent for analysis thereafter in order for anomalies in the network to be detected. In case of SDN- based networks, switches send the collected packets to the controller and the latter is responsible for the threat detection and mitigation. sFlow seems to be applicable as well as efficient on SDNs as results show in [11].

All the current approaches regarding the statistics collections over SDN are listed in [52]. The authors classify the approaching methods into three categories, each of them point out to the problem from a different angle. The first approach is related to the required balance between the monitoring accuracy and the added overhead. In this category, improved versions of traditional OpenFlow approaches are presented. Inspired by the OpenFlow baseline approaches, Payless [53] is an active monitoring approach, which regularly requests for flow statistics. The adaptive polling interval to get statistics makes it possible to trade accuracy with overhead. On the other hand, FlowSense [54]

exploits the passive monitoring way. The approach collects statistics not only when a flow is removed from the flow table, but also when a new packet is sent to the controller for handling instructions. FlowSense achieves low overhead and high accuracy using the passive monitoring way. An adaptive way of flow monitoring is illustrated in [6], where a prediction-based algorithm is used in order to dynamically change the granularity of network flow measurement. The limitation of the work, is the delayed threat detection, since the basic algorithm is based on comparison with historical data, but the accuracy of the results is notable. The second challenge is between the usage of resources and the measurement accuracy and DREAM [55] is a promising proposal for dynamical resource allocation providing highly accurate results. However, a deeper analysis about this category is out of the scope of this project. Last but not least, the tradeoff between the real- time measurements and the accuracy is the third challenge during monitoring. In this category, sample-based approaches have been proposed, with OpenSample [56] to give adequate results with low latency and high accuracy. OpenSample platform is based on

16 the sFlow and uses TCP sequence numbers in order to provide an accurate passive monitoring.

Attack Detection

An early work about how DDoS attacks can be detected over SDNs is also illustrated in [9]. The authors use active monitoring in order to periodically collect statistics and consider the Self Organizing Maps (SOM) [57] method to analyze the results and successfully detect the threat. However, SOM-based approaches require training time for collecting statistics and display better results as time passes and the total number of collected packets increases, so improving the gathered statistics.

Four prominent methods have been proposed for data analysis [10], [13] and each one can be used depending on the addressed threat. Threshold Random Walk with Credit Based Rate Limiting (TRW-CB) [58] is a suitable algorithm for scanning worms detection by observing the rate of a successful TCP connection. One more host-based anomaly detector is Rate-Limiting algorithm [59], which detects virus propagation by observing whether an affected host attempts to connect to many machines in a short period of time.

NETAD algorithm [60] is able to block suspicious traffic based on the packet header by computing packet scores in order to identify the anomalous packets. In order to take a decision based on traffic statistical features, the Maximum Entropy Detector [61] can be used leading to classification of the packets into categories and distinction of the categories as benign or malicious by using traffic distribution statistical methods. The main drawbacks of this method are the required training time as well as the examination of every packet, which are inefficient approaches for SDN-based networks.

However, entropy-based approaches seem to be ideal for DDoS detection [62].

Studies like [11], [62]–[64] use entropy-based approaches in order to identify DDoS attacks both in traditional networks and SDNs. Entropy measures the randomness of events happening. Entropy is applicable in computer networks as the method is able to provide traffic distribution features that can be translated in valuable information identifying traffic anomalies within the network. Based on the entropy value, the result of the method can show if the total traffic is equally distributed within the network or presents anomalies and lower randomness. Considering as an example the case of a DDoS attack, the result of the entropy-based analysis can reveal information about the

17 destination IP address, the destination port, the source IP address or the source port. The final result depends on the analysis angle and the investigated data set independently of the traffic type (TCP, UDP or ICMP attack). During a DDoS attack, excessive amount of traffic is destined to a specific host. Analyzing the data the randomness of the destination of the total traffic decreases and as a result, the entropy value is low enough able to generate a security suspicious warning. The authors in [62] applied the method in a SDN in a light and effective way in order to early and successfully identify the attack targeting a specific host.

Mitigation

As soon as the analysis of the collected data has been performed and the characteristics of the anomaly have been identified, mitigation actions should be taken into consideration in order to allow only the legitimate traffic to flow towards the intended destination. Apart from the protection of the aimed host, it is also necessary to protect the network and the system itself. It is up to the controller to take the right decisions regarding the proper countermeasures. A list of countermeasures, depending on the corresponding attack, is presented in [12]. The authors identify the most common mitigation techniques, which are applicable in OpenFlow and SDN architectures in the presence of a DDoS attack.

Flow aggregation, packet dropping, rate limit and shorter timeouts are the most suitable techniques applicable on controllers and forwarding devices in order to protect the system while it is threatened. They are also recommended in the OpenFlow v.1.5 specifications [42].

Packet dropping can protect both the data plane as well as the targeted host. When the destination or the source IP address has been identified, then the controller can prevent the flow of any suspicious traffic within the network by installing specific rules in the forwarding devices to drop the matched packets. Rate limit can be combined with the packet dropping technique directly on the switches in order to confine the number of packets sent to the controller. For example, if the number of received packets per flow in the forwarding device exceeds the defined threshold, then the next incoming packets are dropped. Moreover, rather than installing fine-grained rules on the switches, flow aggregation techniques exploit the use of wildcards and matches multiple flows to a simple aggregative rule. The abstraction of the rule helps to prevent attacks on a specific target.

18 Finally, shorter timeouts can contribute to a faster identification of the attack while the attacker should send forged packets at a high rate in order to update the life time duration of the rule and avoid the expiration of it.

The implementation of middlebox functionalities provided by the devices is illustrated in [50]. In this case, the switches behave like stateful or stateless firewalls adding further protection to the network. A stateless firewall filters the packets based on the current values in the headers and decides if the packet will be dropped or accepted.

The controller can install decision rules in order to implement this behavior. The installation of the rules can be performed in two ways, the reactive or the proactive one.

During the proactive installation, the controller installs the rules in advance, namely before the switch asks for further instructions. The main advantage of this approach is the low additional delay between the switch and the controller. However, it may lead to larger flow tables filled with unnecessary low entries. On the other hand, by considering the reactive approach the switch sends the first packet to the controller asking for instructions.

The controller installs the appropriate rule representing the firewall behavior. Although this way of communication leads to small flow tables, it adds additional delay because the controller has to translate the firewall policies into forwarding rules.

A stateful firewall keeps tracking the status of a connection and the decisions are not based only on the current packet header but on the history and the current status of the connection. The decision rules should be installed on the switch using different priorities in order to represent the correct functionality. Since this results in a more complex implementation, in order to lighten the workload of the controller, specific dedicated applications acting as middleboxes are adopted. Thereafter, the controller acts as an intermediate interface between the switches and the specified applications. The applications are responsible for analyzing the incoming packets and identifying the suspicious or legitimate ones. Two typical ways are described in [65] and can be used in order to implement a stateful firewall, the interception and the mirroring mode. Both of them are totally applicable in OpenFlow as the authors in [50] mention. In interception mode, the controller forwards the packet to the dedicated application and after the analysis, the application can modify the installed rule on the switch. After receiving the notification from the middlebox, the switch forwards the packet to the destined host or dropped it. During mirroring mode, the application modifies the installed rule and at the same time forwards the packet to the destination. While the mirroring mode avoids the

19 extra delays added by interception mode, it may delay to identify and block the malicious traffic. Depending on the type of application, the right selection between the two modes should be done.

Many studies have been conducted investigating efficient ways of network monitoring and attack detection over SDNs. A packet sampling approach for statistics collection over SDN is presented in [11]. The authors compare the native OpenFlow methods for statistics collection with the sFlow-based approach [51] in order to prove the efficiency of packet sampling method in a complete detection and mitigation system. In order to mitigate the threat the authors propose the installation of new higher prioritized rules indicating that suspicious flows targeting the victim (e.g. specific IP/protocol/port) will be dropped. Although, this action is easy to be implemented, its drawback is that benign traffic can be also dropped. In order to bypass this limitation, the authors use whitelists in order to recognize the spikes of legitimate traffic. Before a drop rule is inserted into the switch, the mitigation module firstly checks the identified target pairs against the white list. If the suspicious IP or port belongs to a legitimate anomalous behavior, then the packets are forwarded to the destination, otherwise, they are dropped.

In [7], an OpenFlow extension is proposed in order to detect threats, such as DDoS and network scanning by adding some intelligence in the data plane. Even if this approach can be characterized as controversial to the SDN philosophy, AVANT-GUARD, is a complete flexible framework, which is based on two basic mechanisms, the connection migration and the actuating trigger in order to detect and mitigate the threat. The basic limitation is the detection of only TCP-based flooding attacks and not others, such as UDP or ICMP flooding attacks. A system, which is able to deal with all types of flooding attacks is proposed in [8]. The authors consider proactive flow rule installation in order to avoid saturation attacks and a packet mitigation method that caches new incoming unmatched packets in order to protect and distinguish the legitimate traffic from the malicious one when the network is under attack. The cached packets are forwarded to the controller as soon as the alert of the attack is over in order for forwarding instructions to be given. Even though there is a delay when a host receives the packets, it is guaranteed that legitimate packets are not being dropped but forwarded to the destination in the end.

20 Selected Methods

After studying the literature and taking into consideration all the existing methods and approaches regarding a complete security monitoring system, for the purposes of this work the below techniques are selected to form the use-case system, which will be evaluated. The collection of the statistics will be implemented based on the native OpenFlow approach. Since it is the first implementation and integration of the SDN support into SEA++ simulator, the native OpenFlow approach is pivotal and will provide a more concrete and complete support of the protocol. Furthermore, the attack detection module will be based on the entropy algorithm, as the literature has proved that the algorithm is suitable for the identification of DDoS attacks, because it analyzes the traffic distribution and is able to provide valuable results regarding both the target and the compromised source host. Finally, the selected technique, which will be used as mitigation action, is the packet dropping. The implementation of the DROP action has been considered essential to be implemented, as it is one of the most basic OpenFlow instructions given by the centralized controller to the switches. Further details and a step by step presentation of the deployment of the chosen monitoring system will follow in the next chapter.

21

4. A use-case SDN Security Monitoring System

In order to reach the specified goal, namely the provision of a complete simulation framework able to support detection and mitigation techniques to protect SDN architectures, this work will constitute an extension of the INET v.2.6 simulation framework based on OMNeT++ v.4.2 discrete event network simulator. An initial model is presented in [45] and it consists of the two basic SDN components, the SDN centralized controller and the OpenFlow enabled switch supporting the basic OpenFlow messages for the flow establishment and communication between the components as an extension of the INET framework. This project will enhance the work in [45] with additional OpenFlow messages in order to support a network monitoring system and enable the packet processing based on flow matching rules of arbitrary complexity. Before we continue to the presentation of the implemented extensions, a brief description of the work in [45] will be presented in the next section, as it provides the basic SDN components as well as the support of the OpenFlow protocol and constitutes the fundamental basis of this work. The rest of the sections will present the selected methods regarding the collection of the statistics, the attack detection method and the selected mitigation technique which have been implemented in order to accomplish the goal of this thesis.

SDN support in INET framework

The authors in [40] presented an initial model of the SDN architecture in INET framework of OMNeT++ discrete event simulator. Their model is based on the integration of the OpenFlow enabled switch and the implementation of a basic SDN centralized controller including also, the basic implementation of the OpenFlow protocol v.1.0. They designed the initial components in that way as it is illustrated in the below figures. The SDN controller consists of a complete TCP/IP stack and can be easily represented as a generic host node. The controller application, ofa_controller, is responsible for the communication between the switches using OpenFlow messages. This includes the flow establishment, update and revocation. The controller behavior represents all the possible operational applications that can be built on it. The controller can act for example as

22 traditional L2 switch, Hub or Router. The desired forwarding behavior of the controller is defined in this module.

The main characteristic of the SDN architecture is the separation of the control and data plane of a switch. The authors aiming to follow and represent the new philosophy, they designed the OpenFlow switch as a combination of two independent modules. The left part of the figure below represents the control plane and the right part illustrates the

Figure 8: Representation of the centralized controller in INET framework.

Figure 9: Representation of OpenFlow-enabled switch in INET framework.

23 data plane. As it can be seen, both modules share the flow table, which contains all the flow match rules.

All the Ethernet frames are received by the MAC module of the data plane. The messages are forwarded to the Flow Forwarding Application, OF_Processing module. The module searches for a flow match in the flow table. If such flow exists then it forwards the packet from the port indicated in the instruction list. If there is no related match rule, the OF_processing module sends a signal to the flow processing application, OFA_swtich.

This application is responsible for the communication with the controller. When the module receives signal for unmatched packet, it establishes a new TCP connection to the controller and sends the packet to it through OpenFlow message, OFP_Packet_In. The switch will receive from the controller through the communication channel the OFP_Packet_Out and the OFP_Flow_Mod messages. When the OFP_Packet_Out is received the OFA_switch module will inform the OF_processing module through the signal mechanism to apply the specific output action. As soon as the switch received the OFP_Flow_Mod message, it will update the flow table inserting the new flow.

When the controller receives an OFP_Packet_In message, it notifies the defined in the configuration file behavior application. The controller application emits a signal to the behavior application including the packet in order for the later to process it. The controller behavior application has a complete awareness of the network topology and is the module which takes the forwarding decisions. As soon as it declares the action list, it notifies the basic controller application to send the OFP_Packet_Out and OFP_Flow_Mod messages to the switches.

All the implemented OpenFlow messages are listed below:

 OFP_Features_Request & OFP_Features_Reply: The messages are necessary for the initialization of the OpenFlow Channel between the controller and the switches. The first message is sent by the controller and the reply is sent by the switch.

 OFP_Packet_In: This message is sent by the switch to the controller in order to inform the module for the presence of a new incoming packet. The switch forwards the packet to the controller asking for forwarding instructions.

24

 OFP_Packet_Out: The centralized controller replies to the above request with this message. The controller informs the switch which port should be used to forward the packet.

 OFP_Flow_Mod: The controller sends the switch the specific message in order to establish a new flow in the flow table, or to update an existing one. The message contains all the match fields will be checked when a packet arrives at the switch as well as the instruction set list indicating the forwarding actions.

The following sections describe the extensions of this work in order to build new functionalities in the centralized controller and the switches aiming to build a complete security network monitoring system.

New Controller Overview

The below Figure 10 illustrates the new additional modules which are the basic components of a complete security network monitoring system. All the new modules are integrated as applications in the centralized controller. The new composed module of the controller is enhanced with two new modules, AttackDetection and Mitigation. The AttackDetection module is able to support multiple analysis methods in order to detect an

Figure 10: New representation of the centralized controller in INET framework.

25 anomaly. In this work, the Entropy algorithm is the integrated method of the module. The Mitigation module is called whenever the AttackDetection module identifies a new anomaly within the network. It is responsible to prepare the new flow entry, which will be established on the switches and will be regarded to the protection of the victim.

Furthermore, it has to be mentioned that the controller acts as forwarding switch running the “FwdSwitch” application. The controller does not base the forwarding decisions only in the MAC address fields but based on the type of the packet. Let’s take the below example into consideration. When the controller receives a new IP packet, then the fields of the new flow entry about the IP source address, IP destination address, IP Protocol, MAC source address, MAC destination address and Ethernet packet type will be matched. The below graph illustrates the fields which are matched based on the packet type.

The below sections analytically describe the implemented methods regarding the statistics collection, the attack detection and the attack mitigation module respectively.

Figure 11: Packet matching fields.

26 Statistics Collection

For the purposes of this project, the statics collection is achieved by using native OpenFlow messages via the flow-based active monitoring. More specifically, the

“OFPT_STATS_REQUEST” and “OFPT_STATS_REPLY” OpenFlow messages have been implemented. The controller application periodically requests from all the switches to report statistics about the packet matches and the accesses to their flow tables occurred during the specified time window. The time interval is defined in the configuration file by the user. When the switch, namely the OFA_switch module, receives this message parses the flow table and collects all the current flow entries and their counters. All the information is included in the OFPT_STATS_REPLY OpenFlow message, which is sent back to the controller. When the controller receives replies from all the switches presented in the network sends the information to the attack detection module.

Moreover, the OFPT_FLOW_REMOVED message has been also implemented.

The switches send this message when a flow entry expires to notify the controller about the event. The message includes all the statistical information regarding this flow entry containing also the total number of matched packets during this specific time interval. For the purposes of this work, the particular message is not used further, but it proves that a different system, which uses the passive monitoring way, can be supported.

Attack Detection

As it was discussed earlier, the attack detection module is based on the entropy algorithm. The specific method has been proved to be able to identify easily DDoS attacks based on the entropy value as it mainly measures the randomness of the traffic distribution in the network. Collecting statistics periodically and exploiting the features of the entropy algorithm, the controller is able to recognize if there are anomalies of the traffic distribution in the network. It is a fact that during DoS or DDoS attacks, excessive volume of traffic is destined to the target host giving as a result a concentrate traffic distribution.

Using the entropy algorithm, it is easily to identify the anomaly as the value of the measurement decreases indicating lower randomness of the traffic distribution and reveal information about the victim and the compromised host.

27 The two main characteristic parameters of the entropy algorithm are the threshold and the window size. If the entropy value is lower than a predefined threshold, then there is an alert for abnormal traffic distribution. The window size indicates the size of the data set, which will be analyzed for anomalies. The window size can be determined either based on time or number of packets and it defines the period when the algorithm will be applied.

Since the collection of the statistics are based on the active OpenFlow active approach, the window size is based on time and the entropy algorithm is performed every polling interval.

In order to minimize the false positive alerts a second check is followed. The entropy algorithm generates an alert when the entropy value is lower than the threshold.

The alarm indicates suspicious traffic volume within the network. Before the mitigation module takes action, a second check is performed is order to confirm the existence of an anomaly. As soon as the entropy analysis returns a positive alarm, the packet counters of the suspicious sender and the suspicious victim are checked against predefined thresholds. If the number of sent packets within the window exceeds the threshold as well as the receiver accepts more packets than the threshold, then the anomaly between this pair is identified and the mitigation module is called.

4.4.1. Entropy Algorithm

Let W be the set of n elements and x events during the window size. The randomness of the events’ distribution is calculated through the entropy value H, which is the logarithmic sum of the probability pi of each element in the set, as equations (2) and (3) show.

W = {𝑥_1,𝑥₂, … , 𝑥_𝑛} (1)

𝑝_𝑖 = ^𝑥𝑖

𝑛 (2)

H = - ∑^𝑛_𝑖−1𝑝_𝑖∗ log 𝑝_𝑖 (3)

When the entropy value H is lower than the predefined threshold t, then an attack alarm is generated.