DELTA: a Security Assessment Framework for Software-Defined Networks

DELTA: a Security Assessment Framework for Software-Defined Networks

DELTA: A Security Assessment Framework for Software-Defined Networks Seungsoo Leey Changhoon Yoony Chanhee Leey Seungwon Shiny Vinod Yegneswaranz Phillip Porrasz y KAIST zSRI International flss365, chyoon87, mitzvah, [email protected] fvinod, [email protected] Abstract—Developing a systematic understanding of the attack This paper introduces a new SDN security evaluation surface of emergent networks, such as software-defined networks framework, called DELTA, which can automatically instantiate (SDNs), is necessary and arguably the starting point toward attack cases against SDN elements across diverse environ- making it more secure. Prior studies have largely relied on ments, and which may assist in uncovering unknown security ad hoc empirical methods to evaluate the security of various problems within an SDN deployment. Motivated by security SDN elements from different perspectives. However, they have testing tools in the traditional network security domain [13], stopped short of converging on a systematic methodology or developing automated systems to rigorously test for security flaws [36], DELTA represents the first security assessment tool for in SDNs. Thus, conducting security assessments of new SDN SDN environments. Moreover, we enhanced our tool with a software remains a non-replicable and unregimented process. specialized fuzzing module [26] to exploit opportunities for This paper makes the case for automating and standardizing discovering unknown security flaws in SDNs. the vulnerability identification process in SDNs. As a first step, we developed a security assessment framework, DELTA, that In designing DELTA, we first assessed the overall operation reinstantiates published SDN attacks in diverse test environments. of an SDN by tracking its operational flows. Operational flow Next, we enhanced our tool with a protocol-aware fuzzing module analysis provides a basis for understanding the attack surfaces to automatically discover new vulnerabilities. In our evaluation, available to external agents across an SDN deployment, and is DELTA successfully reproduced 20 known attack scenarios across a generally applicable strategy for approaching any SDN stack. diverse SDN controller environments and discovered seven novel Based on the popular OpenFlow protocol specification [29], we SDN application mislead attacks. categorize operational flows into three categories (see Section II). In each category, we explore possible security issues and assess which ones are covered by existing studies. I. INTRODUCTION Our intent is to design a testing framework that automates With the increasing interest and visibility of SDN proto- the systematic exploration of vulnerabilities exposed in SDN cols, so too grows the increasing need for thorough security deployments from diverse perspectives. To date, previous stud- assessments of SDN components and component interactions. ies are limited in their coverage of the SDN attack surface, in This need has not gone unnoticed by security researchers. that they usually depend on specific SDN elements or network Indeed, several security challenges have been raised in prior environments. To overcome this issue, we devised a method work [23], [31], [38], and an even wider range of attack sce- to reveal possible unknown security problems in an SDN by narios have been enumerated against SDN environments [1], employing a blackbox fuzzing technique, which randomizes [17], [22]. message input values to detect vulnerabilities in the direct Such security-critical reviews of SDNs offer a view into interface or failures in the downstream message processing various breaches, but overall, the attack surfaces thus far logic. When generating random test vectors, DELTA uses the explored have been quite limited to either highly targeted information from the analysis of the SDN operations and exploits, such as ARP spoofing, or specific vulnerabilities that focuses on the cases where vulnerabilities are likely to be arise in various SDN components. Each previous result may located. not be applicable to other SDN environments (e.g., different We implemented a prototype framework for DELTA and control planes). Hence, operators seeking to assess security evaluated it with real-world SDN elements. For each controller, issues in their SDN environments need to survey existing SDN DELTA is customized with a simple configuration file. The security-related studies and determine relevance on a case-by- flexible design of DELTA accommodates both open source and case basis. Furthermore, an operator may have to adapt or commercial SDN controller implementations. Our prototype redesign deployment-specific security test suites. can (currently) reproduce 20 known SDN-related attack sce- narios targeting several well-known SDN elements, such as the Permission to freely reproduce all or part of this paper for noncommercial ONOS controller [2], the OpenDaylight (ODL) controller [25], purposes is granted provided that copies bear this notice and the full citation the Floodlight controller [27] and the commercial Brocade on the first page. Reproduction for commercial purposes is strictly prohibited Vyatta SDN controller [3]. In addition, DELTA was able without the prior written consent of the Internet Society, the first-named author to discover seven new attack scenarios by applying protocol (for reproduction of an entire paper only), and the author’s employer if the fuzzing techniques. paper was prepared within the scope of employment. NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA The new attack scenarios exposed by DELTA have been Copyright 2017 Internet Society, ISBN 1-891562-46-0 http://dx.doi.org/10.14722/ndss.2017.23457 reported to the Open Networking Foundation (ONF) [28], the standards body dedicated to the promotion of SDN and defin- manually configures network flow-handling policies for each ing the OpenFlow protocol [12]. The results of our analysis network device. Instead, an SDN abstracts the complexity of have also informed our collaborations with the ONF security the underlying networks, and this abstraction hides network working group in drafting white papers defining best practices topologies and network devices from end-users. Thus, unlike for securing SDN environments. Furthermore, DELTA has traditional networks, SDN contains the global view of the been open sourced as one of ONF’s official open SDN projects whole network through the high-level network abstraction. [33]. OpenFlow: OpenFlow is the de-facto standard protocol This paper describes the following contributions: for the communication between the control plane (a.k.a., the OpenFlow controller1) and the data plane. Hence, considering • An analysis of vulnerabilities in the SDN stack that OpenFlow in SDN networks is quite natural, and many com- can mislead network operations. Through this analy- mercial deployments have successfully employed OpenFlow sis, we can reconcile test input with erroneous SDN as the primary interface between those two planes [16], [20]. errors and operational failures. We introduce seven criteria for automatically detecting a successful attack scenario from these failure conditions. We then show B. SDN Control Flows how to combine this information for assessing root cause analysis on successful attacks. Controller Load Balancer Routing App Applications • The development of an automated security assessment APP framework for SDN capable of reproducing diverse attack scenarios. This framework currently reproduces PACKET_IN Flow Rule Statistics 20 attack scenarios against real-world SDN elements Notifier Service Service Core Services with simple configurations and is readily extensible to PACKET_IN FLOW_MOD support more scenarios. STATS_REQUEST STATS_RESPONSE • The incorporation of blackbox fuzzing techniques into our framework to detect new unknown attack Switch scenarios. Through our evaluation, we verified that this technique found seven previously unknown attack Fig. 1: Examples of SDN/OpenFlow control flows. Dotted lines indi- cases. cate symmetric control flows and solid lines correspond to asymmetric control flows. • The demonstration of flexibility of system design by evaluating it against three popular, open-source SDN controllers and the commercial Brocade Vyatta SDN The operations of SDN (specifically, those based on the controller. OpenFlow protocol) can be classified into three types of control based on the control flow of the OpenFlow protocol: We have shared our results with ONF and they are being (i) symmetric control flow operations, (ii) asymmetric control referenced by its security working group in defining new flow operations, and (iii) intra-controller control flow opera- standards. Furthermore, our framework has been promoted to tions. an official open source project by ONF [33]. Symmetric control flow operations: In these operations, II. BACKGROUND AND MOTIVATION an SDN component sends a request to another component and receives a reply back (i.e., a request-reply pair). Fig- A. SDN and OpenFlow ure 1 presents an example illustrating this operation using dotted lines. Consider a load balancer on a controller that In traditional networks, a control plane, computing sophis- needs switch statistics to distribute traffic loads. To retrieve ticated networking functions, and a data plane, handling low- statistics from the switch, the load balancer first issues a level packet forwarding based on the policies of the control statistics request event to the statistics service in the con- plane, are tightly coupled and usually colocated within a single

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    15 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us