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

Transcription

1 OrchSec: An Orchestrator-Based Architecture For Enhancing Network Monitoring and SDN Control Functions 9 May 2014 Dr.-Ing. Kpatcha Bayarou Head, Mobile Networks Fraunhofer SIT Kpatcha.bayarou@sit.fraunhofer.de Fraunhofer-Gesellschaft 2011

2 Outline! Introduction! Architectural Design! Orchestrator-Based Security! Experimental Examination! Conclusion 2

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 3

4 Introduction! Traditional approaches against these threats have their drawbacks.! Can Challenges Software in Defined traditional Networking DNS DoS ARP security amplification (SDN) address security these challenges?!! Horizontally Relies Distributed Changes on in attack network integrated the network prevention, management hosts with no reactive mitigation Plane ()!! Vendor-agnostic Limited Proprietary Hardware-based no middleboxes control over (e.g., network IDS) devices (i.e., Open DNS resolvers)!! Network Lack Detection-only of automated visibility without real-time attack response mitigation! Security as applications! Incomplete threat coverage! Automated traffic steering Data Plane (Switches)!! Centralized Proprietary management 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 4

5 Introduction Security-Centric SDN! Using the features provided by SDN to improve or enable security in traditional networks.! The To solve research these done problems, in security-centric the following SDN adjustments has the following can be considered: problems:! Tight Develop coupling controller-agnostic of SDN applications applications to the (using controllers a Northbound-API)! Tight Decouple coupling network of network monitoring monitoring and control and control functions functions! Making Use multiple use of controllers only one SDN for a more controller reliable (i.e., and Single diverse Point architecture of Failure) APP APP APP APP APP APP Monitor Platform 1 n 5

6 Outline! Introduction! Architectural Design! Orchestrator-Based Security! Experimental Examination! Conclusion 6

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. 7

8 Architectural Design Proposed Architecture I First Iteration: Sampling-based Security Requirements Secure & reliable SDN architecture Flexibility in application development Decoupling control & monitoring functions Providing high-resolution attack detection App App App Network Monitor (sflow Collector) Switch Northbound API (REST, ) 1 Virtualization Layer N Southbound API (OpenFlow, ) Switch vswitch vswitch Switch SDN Device Network Monitor SDN SDN Device Pros! Northbound applications! Multiple controllers! Decoupled monitoring & control Cons! Flow-shortening! Flow-reduction 8

9 Architectural Design Proposed Architecture II Second Iteration: High Resolution Sampling Requirements Secure & reliable SDN architecture Flexibility in application development Decoupling control & monitoring functions Providing high-resolution attack detection App App App Network Monitor (sflow Collector) Northbound API (REST, ) 1 Virtualization Layer N Southbound API (OpenFlow, ) Filter Device Network Monitor SDN Switch Switch vswitch vswitch Switch SDN Device Pros! Higher sampling budget! Northbound applications! Multiple controllers! Decoupled monitoring & control Cons! Flow shortening was not completely solved 9

10 Architectural Design Proposed Architecture III Third Iteration: Delegating Attack Detection Requirements Secure & reliable SDN architecture Flexibility in application development Decoupling control & monitoring functions Providing high-resolution attack detection App App App Network Monitor (sflow Collector) Northbound API (REST, ) App App App App 1 N Virtualization Layer Southbound API (OpenFlow, ) SDN Device Network Monitor SDN Switch Switch vswitch vswitch Switch SDN Device Pros! High resolution attack detection using delegation! Multiple controllers! Decoupled monitoring & control Cons! Tightly-coupled applications 10

11 Architectural Design Proposed Architecture IV Orchestrator-based Architecture Requirements Secure & reliable SDN architecture Flexibility in application development Decoupling control & monitoring functions Providing high-resolution attack detection App App App App App Orchestrator Northbound API (REST, ) App Orchestrator Network Monitor (sflow Collector) Agent 1 Virtualization Layer Agent N Network Monitor SDN Controlle r Southbound API (OpenFlow, sflow ) SDN Device Switch Switch vswitch vswitch Switch Pros! High resolution attack detection! Northbound applications! Multiple controllers! Decoupled monitoring and control SDN Device Cons! Overhead for high resolution attack detection 11

12 Outline! Introduction! Architectural Design! Orchestrator-Based Security! Experimental Examination! Conclusion 12

13 Orchestrator-Based Security DNS Amplification Security DNS Attack! Flooding-based DNS amplification DDoS DNS Amplifica1on Security Applica1on RR Ratio Calculation Destination Address Entropy Related Work! Hardware-based Spoofed [5] small DNS requests! Stateful detection (store requests Servers / and replies) [6] Open DNS Recursive Resolvers Security Blocks! Network Monitor threshold checker! Received-Reply (RR) ratio calculation! Destination IP address entropy Large DNS response NM Threshold Victim Checker Network Monitor (sflow Collector) Switch Packet Orchestrator Northbound API (REST, ) Agent 1 Packet Virtualization Layer Southbound API (OpenFlow, sflow ) Agent N Switch vswitch vswitch Switch 13

14 Orchestrator-Based Security DNS Amplification Security Orchestrator DNS Amplifica1on Security Applica1on RR Ratio Calculation Destination Address Entropy Suspicious event on port x Forward traffic to me from port x Packet Packet Orchestrator sflo w C2 C1 NM Threshold Checker Northbound API (REST, ) Agent 1 Agent N Suspicious DNS traffic Network Monitor (sflow Collector) Virtualization Layer DNS Resolvers Large DNS responses Switch Southbound API (OpenFlow, sflow ) Switch vswitch vswitch Switch 14

15 Outline! Introduction! Architectural Design! Orchestrator-Based Security! Experimental Examination! Conclusion 15

16 Experimental Examination Testing Enviroment Host System! Ubuntu LTS! Intel Core i7-3630qm! 8 GB RAM s! Floodlight! POX Network Monitor! sflow Virtualization! Virtualbox VM (with a NAT adapter and a host-only adapter)! Mininet 16

17 Experimental Examination DNS Security Experiment I DNS Amplification Experiment Orchestrator sflow Floodlight POX vswitch H1 (Attacker) H3 (Victim) H2 (DNS Resolver) 17

18 Experimental Examination DNS Security Experiment II 18

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 19

20 Contact for specific questions Fraunhofer Institute for Secure Information Technology (SIT) Rheinstr. 75, Darmstadt, Germany! Rahamatullah Khondoker Ronald Marx RWTH Aachen University Aachen, Germany! Adel Zaalouk 20

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 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 Kim, Myung-Sup, et al. "A flow-based method for abnormal network traffic detection." Network Operations and Management Symposium, NOMS IEEE/IFIP. Vol. 1. IEEE, 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, Sun, Changhua, Bin Liu, and Lei Shi. "Efficient and low-cost hardware defense against DNS amplification attacks." Global Telecommunications Conference, IEEE GLOBECOM IEEE. IEEE, Kambourakis, Georgios, et al. "A fair solution to DNS amplification attacks." Digital Forensics and Incident Analysis, WDFIA Second International Workshop on. IEEE,