A Practical Framework for Finding Software Vulnerabilities in Sdn Controllers

ABSTRACT

Software-defined networking (SDN) has the potential to greatly reduce the cost and increase the manageability of large networks. However, there are multiple security concerns holding back its wide-scale adoption. While previous research has mainly examined securing the data and application planes of SDN, we argue that the controller itself is the most vulnerable component in the SDN architecture because it is both the most central and the most software-reliant component. Therefore, research into better securing the controller is central to any effort at securing the SDN architecture.

This study examines the question of how to better secure the controller by developing a practical framework for finding vulnerabilities in the underlying software of the Open Day light controller. By finding vulnerabilities in its software, we aim to not only improve the security of the controller software, but also build a foundation to allow previous research to implement better solutions to secure other SDN components.

LITERATURE REVIEW

Figure 6: Adding a Flow in the Open Day light Controller

Figure 6: Adding a Flow in the Open Day light Controller

The Flow Programmer Service then receives a notification that a flow has been added as it is registered to receive updates for changes in the Flow Service data tree. Next, the Flow Programmer Service then uses the OpenFlow (OF) Plugin to generate a Remote Procedure Call (RPC), or a procedure that is executed remotely but coded as if it were executed locally, to add the flow in the appropriate switch. This RPC is then routed through the OF Plugin to the correct switch. Figure 6 illustrates this process.

METHODOLOGY

Figure 15: OpenFlow Packet Structure

Figure 15: OpenFlow Packet Structure

Each OpenFlow packet consists of a header, which is basically the same for each packet type, and a payload, which varies from packet type to packet type. Figure 15 illustrates this structure.

 Figure 26: FireFox Popup Dialog

Figure 26: FireFox Popup Dialog

We included the username and password in the URL to avoid having to instruct the selenium module to enter the credentials through additional actions. We then dismiss ed the popup dialog that resulted. This popup dialog is illustrated by figure 26.

RESULTS

Figure 31: OpenFlow CPU Usage Results

Figure 31: OpenFlow CPU Usage Results

Figure 32: OpenFlow Memory Usage Results

Figure 32: OpenFlow Memory Usage Results

Figures 31 and 32 illustrate CPU and memory usage throughout the fuzzing run for the
OpenFlow plugin of the OpenDaylight controller.

CONCLUSION

Our goal with this project was to provide a practical framework for finding vulnerabilities in SDN controllers. We successfully achieved this objective by developing a fuzzing tool with standard Python modules to fuzz the OpenFlow and RESTCONF plugins of the Open Daylight controller. To develop this framework, we chose to use the Open Daylight controller, because it is well-documented, and fuzzing, because it is an effective method for finding vulnerabilities in large software systems.

We choose two controller features, odl-l2switch-all, a Southbo und plugin and odl-restconf-all, a Northbound plugin, to fuzz with a smart, generation-based, blackbox fuzzing approach. This approach consisted of determining the structure of valid packets or requests to the controller, determining the fields within those packets or requests that could be varied, and varying those fields randomly.

Source: University of Colorado
Author: Walid Sharif

Download Project

Similar Projects:

For Free CSE/IT Project Downloads:

Enter your email address:
( Its Free 100% )

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>