OrchSec: An Orchestrator-Based Architecture For Enhancing...

transcript

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 –

Outline

!  Introduction

!  Architectural Design

!  Orchestrator-Based Security

!  Experimental Examination

!  Conclusion

– 3 –

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 –

!  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 –

!  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 –

Outline

!  Introduction

!  Conclusion

– 7 –

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 –

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

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 Controller

Network Monitor

– 9 –

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

T, …

Controller 1

Controller N

App App App

Switch

Filter Device

SDN Device

SDN Controller

Network Monitor

– 10 –

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

T, …

Controller 1

Controller N

App App App

Switch

SDN Device

SDN Controller

Network Monitor

1 App App App App

– 11 –

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

Orchestrator

App App App App App

Northbound API (REST, …)

Controller 1

Controller N

Southbound API (OpenFlow, sFlow…)

Switch

Orchestrator

SDN Device

SDN Controlle

Network Monitor

Agent Agent

– 12 –

Outline

!  Introduction

!  Conclusion

– 13 –

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

Network Monitor (sFlow

Collector)

Controller 1 Controller N …

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 –

Orchestrator-Based Security – DNS Amplification Security

Network Monitor (sFlow

Collector)

Controller 1 Controller N …

Switch vSwitch vSwitch Switch Switch

Agent Agent

Packet Packet

Orchestrator

RR Ratio Calculation

Destination Address Entropy

DNS Amplifica1on Security Applica1on

NM Threshold Checker

Orchestrator

Large DNS responses

Suspicious event on port x

Forward traffic to me from

port x

Suspicious DNS traffic

DNS Resolvers

– 15 –

Outline

!  Introduction

!  Conclusion

– 16 –

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 –

Experimental Examination – DNS Security Experiment I

DNS Amplification Experiment

Orchestrator

Floodlight POX

vSwitch

H2 (DNS Resolver) H1 (Attacker)

H3 (Victim)

– 18 –

Experimental Examination – DNS Security Experiment II

– 19 –

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 –

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 –

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.

OrchSec: An Orchestrator-Based Architecture For Enhancing...

Documents