Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
© 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 [email protected]
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 [email protected]
! Ronald Marx [email protected]
RWTH Aachen University Aachen, Germany
! Adel Zaalouk [email protected]
– 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.