© F

raun

hofe

r-G

esel

lsch

aft 2

011

OrchSec: An Orchestrator-Based Architecture For Enhancing Network Monitoring and SDN Control Functions

http://dgallery.s3.amazonaws.com/simulating_brain.jpg  

Dr.-Ing. Kpatcha Bayarou Head, Mobile Networks

Fraunhofer SIT Kpatcha.bayarou@sit.fraunhofer.de

9 May 2014

–  2  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Outline

!  Introduction

!  Architectural Design

!  Orchestrator-Based Security

!  Experimental Examination

!  Conclusion

–  3  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Introduction

!  Many protocols of current Internet expose a set of vulnerabilities.

!  One of these protocols is the Address Resolution Protocol (ARP). !  ARP is Stateless

!  It provides no mechanisms for reply authentication

!  These vulnerabilities led to threats such as: !  ARP spoofing / cache poisoning

!  CAM table overflow

!  Null address attack

!  Services in the Internet are provided using a client-server model.

!  This later led to threats such as: !  Denial of Service (DoS) / Distributed Denial of Service (DDoS)

!  Domain Name System (DNS) amplification

–  4  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

!  Challenges in traditional DNS amplification security !  Relies on attack prevention, with no reactive mitigation

!  Limited or no control over network devices (i.e., Open DNS resolvers) !  Lack of automated attack response

!  Can Software Defined Networking (SDN) address these challenges?

!  Challenges in traditional ARP security !  Changes in the network hosts

!  Hardware-based !  Detection-only

!  Incomplete threat coverage

!  Proprietary

!  Challenges in traditional DoS security !  Distributed network management

!  Proprietary middleboxes (e.g., IDS) !  Detection without real-time mitigation

!  Traditional approaches against these threats have their drawbacks.

Introduction

ARP Security Challenges !  Changes in the network host !  Hardware-based

!  Detection-only !  Incomplete threat coverage

!  Proprietary

!  DoS Security Challenges !  Decentralized network management !  Proprietary middle-boxes (e.g., IDS)

!  Detection without mitigation !  Performance bottlenecks

!  DNS Amplification Security Challenges !  Relies on attack prevention, with no reactive mitigation !  Limited or no control over network devices

!  Lack of Automated attack response

Data Plane (Switches)

Controller Plane (Controller) !  Horizontally integrated !  Vendor-agnostic !  Network visibility !  Security as applications !  Automated traffic steering !  Centralized management

–  5  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

!  The research done in security-centric SDN has the following problems: !  Tight coupling of SDN applications to the controllers !  Tight coupling of network monitoring and control functions !  Making use of only one SDN controller (i.e., Single Point of Failure)

!  To solve these problems, the following adjustments can be considered: !  Develop controller-agnostic applications (using a Northbound-API) !  Decouple network monitoring and control functions !  Use multiple controllers for a more reliable and diverse architecture

Introduction

Security-Centric SDN !  Using the features provided by SDN to improve or enable security in

traditional networks.

Controller Platform

APP APP APP APP APP APP

Controller Monitor Controller 1

Controller n

–  6  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Outline

!  Introduction

!  Architectural Design

!  Orchestrator-Based Security

!  Experimental Examination

!  Conclusion

–  7  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Architectural Design – Architectural Requirements

Secure & reliable SDN architecture: !  Using multiple controller instances for reliability and diversity. Flexibility in application development: !  Develop applications using a Northbound API. Decoupling control & monitoring functions: !  Decouple network monitoring from control functions to reduce

the overhead on the controller.

Providing high-resolution attack-detection: !  Provide more information as an input for attack detection. !  Detect attacks that require access to all packets.

–  8  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Architectural Design – Proposed Architecture I

First Iteration: Sampling-based Security

Pros !  Northbound applications !  Multiple controllers !  Decoupled monitoring & control

Cons !  Flow-shortening !  Flow-reduction

Requirements •  Secure & reliable SDN architecture •  Flexibility in application development •  Decoupling control & monitoring functions •  Providing high-resolution attack detection

Nor

thbo

und

API

(RES

T, …

)

Network Monitor (sFlow Collector)

Controller 1

Controller N

…

Virtualization Layer

Southbound API (OpenFlow,…)

Switch vSwitch vSwitch Switch

App App App

Switch

SDN Device

SDN Device

SDN Controller

Network Monitor

1   3  

2  

–  9  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Architectural Design – Proposed Architecture II

Second Iteration: High Resolution Sampling

Pros !  Higher sampling budget !  Northbound applications !  Multiple controllers !  Decoupled monitoring & control

Cons !  Flow shortening was not completely

solved

Requirements •  Secure & reliable SDN architecture •  Flexibility in application development •  Decoupling control & monitoring functions •  Providing high-resolution attack detection

Nor

thbo

und

API

(RES

T, …

)

Network Monitor (sFlow Collector)

Controller 1

Controller N

…

Virtualization Layer

Southbound API (OpenFlow,…)

Switch vSwitch vSwitch Switch

App App App

Switch

Filter Device

SDN Device

SDN Controller

Network Monitor

1  

3  

2  

4  

–  10  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Architectural Design – Proposed Architecture III

Third Iteration: Delegating Attack Detection

Pros !  High resolution attack detection

using delegation !  Multiple controllers !  Decoupled monitoring & control

Cons !  Tightly-coupled applications

Requirements •  Secure & reliable SDN architecture •  Flexibility in application development •  Decoupling control & monitoring functions •  Providing high-resolution attack detection

Nor

thbo

und

API

(RES

T, …

)

Network Monitor (sFlow Collector)

Controller 1

Controller N

…

Virtualization Layer

Southbound API (OpenFlow,…)

Switch vSwitch vSwitch Switch

App App App

Switch

SDN Device

SDN Device

SDN Controller

Network Monitor

1  

2  

1  App App App App

3  

2  

3  

–  11  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Architectural Design – Proposed Architecture IV

Orchestrator-based Architecture

Pros !  High resolution attack detection !  Northbound applications !  Multiple controllers !  Decoupled monitoring and control

Cons !  Overhead for high resolution

attack detection

Requirements •  Secure & reliable SDN architecture •  Flexibility in application development •  Decoupling control & monitoring functions •  Providing high-resolution attack detection

Orchestrator

App App App App App

Northbound API (REST, …)

Network Monitor (sFlow Collector)

Controller 1

Controller N

…

Virtualization Layer

Southbound API (OpenFlow, sFlow…)

Switch vSwitch vSwitch Switch

App

Switch

Orchestrator

SDN Device

SDN Device

SDN Controlle

r

Network Monitor

1  

2  3  

4  

5  

6  

Agent   Agent  

1  

2  

3  

4  

–  12  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Outline

!  Introduction

!  Architectural Design

!  Orchestrator-Based Security

!  Experimental Examination

!  Conclusion

–  13  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Related Work !  Hardware-based [5] !  Stateful detection (store requests

and replies) [6] Security Blocks !  Network Monitor threshold

checker !  Received-Reply (RR) ratio

calculation !  Destination IP address entropy

Orchestrator-Based Security – DNS Amplification Security

DNS Attack !  Flooding-based DNS amplification DDoS

Northbound API (REST, …)

Network Monitor (sFlow

Collector)

Controller 1 Controller N …

Virtualization Layer

Southbound API (OpenFlow, sFlow…)

Switch vSwitch vSwitch Switch Switch

Agent   Agent  

Packet   Packet  

Orchestrator

RR Ratio Calculation

Destination Address Entropy

DNS  Amplifica1on  Security  Applica1on  

NM Threshold Checker

Open DNS Recursive Servers / Resolvers

Spoofed small DNS requests

Large DNS response

Victim

–  14  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Orchestrator-Based Security – DNS Amplification Security

Northbound API (REST, …)

Network Monitor (sFlow

Collector)

Controller 1 Controller N …

Virtualization Layer

Southbound API (OpenFlow, sFlow…)

Switch vSwitch vSwitch Switch Switch

Agent   Agent  

Packet   Packet  

Orchestrator

RR Ratio Calculation

Destination Address Entropy

DNS  Amplifica1on  Security  Applica1on  

NM Threshold Checker

Orchestrator

C2 C1

Large  DNS    responses  

Suspicious  event  on  port  x  

Forward  traffic  to  me  from  

port  x  

sFlow

Suspicious  DNS  traffic  

DNS Resolvers

–  15  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Outline

!  Introduction

!  Architectural Design

!  Orchestrator-Based Security

!  Experimental Examination

!  Conclusion

–  16  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Experimental Examination – Testing Enviroment

Host System !  Ubuntu 12.04 LTS !  Intel Core i7-3630QM !  8 GB RAM Controllers !  Floodlight !  POX

Network Monitor !  sFlow

Virtualization !  Virtualbox VM (with a NAT adapter and a host-only adapter) !  Mininet

–  17  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Experimental Examination – DNS Security Experiment I

DNS Amplification Experiment

Orchestrator

Floodlight POX

vSwitch

H2 (DNS Resolver) H1 (Attacker)

H3 (Victim)

sFlow

–  18  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Experimental Examination – DNS Security Experiment II

–  19  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Conclusion & Future Work

Conclusion !  SDN provides features that can enhance network security. !  However, SDN has some architectural deficiencies when it comes to security. !  To address these deficiencies, an Orchestrator-based architecture is proposed. !  The proposed architecture provides:

!  Reliability through the use of multiple controllers !  Flexibility in application development !  Decoupled monitoring and control functions !  High-resolution attack detection

!  Using the proposed architecture, applications to mitigate against ARP cache poisoning, DoS /DDoS and DNS amplifications were developed.

!  The proposed architecture provides flexibility at the cost of increased latency.

Future work !  Orchestrator-agents support !  Further attack analysis !  Threshold optimization

!  Attack mitigation strategies

–  20  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

Contact for specific questions

Fraunhofer Institute for Secure Information Technology (SIT) Rheinstr. 75, Darmstadt, Germany

!  Rahamatullah Khondoker rahamatullah.khondoker@sit.fraunhofer.de

!  Ronald Marx ronald.marx@sit.fraunhofer.de

RWTH Aachen University Aachen, Germany

!  Adel Zaalouk adel.zaalouk@rwth-aachen.de

–  21  –  

© F

raun

hofe

r-G

esel

lsch

aft 2

012

References

1.  Carnut, M., and J. Gondim. "ARP spoofing detection on switched Ethernet networks: A feasibility study." Proceedings of the 5th Simposio Seguranca em Informatica. 2003.

2.  Gao Jinhua; Xia Kejian, "ARP spoofing detection algorithm using ICMP protocol," Computer Communication and Informatics (ICCCI), 2013 International Conference on , vol., no., pp.1,6, 4-6 Jan. 2013

3.  Kim, Myung-Sup, et al. "A flow-based method for abnormal network traffic detection." Network Operations and Management Symposium, 2004. NOMS 2004. IEEE/IFIP. Vol. 1. IEEE, 2004.

4.  Jun, Jae-Hyun, Hyunju Oh, and Sung-Ho Kim. "DDoS flooding attack detection through a step-by-step investigation." Networked Embedded Systems for Enterprise Applications (NESEA), 2011 IEEE 2nd International Conference on. IEEE, 2011.

5.  Sun, Changhua, Bin Liu, and Lei Shi. "Efficient and low-cost hardware defense against DNS amplification attacks." Global Telecommunications Conference, 2008. IEEE GLOBECOM 2008. IEEE. IEEE, 2008.

6.  Kambourakis, Georgios, et al. "A fair solution to DNS amplification attacks." Digital Forensics and Incident Analysis, 2007. WDFIA 2007. Second International Workshop on. IEEE, 2007.