A Security-Mode for Carrier-Grade SDN Controllers

Yoon, Changhoon; Shin, Seungwon; Porras, Phillip; Yegneswaran, Vinod; Kang, Heedo; Fong, Martin; O’Connor, Brian; Vachuska, Thomas

doi:10.1145/3134600.3134603

Cited by 25 publications

(25 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Furthermore, our attacks can disrupt not only the application layer but also the control layer and the data plane layer. Particularly, our attacks can bypass all the previous defense systems [12], [1], [10], [9], [15], [7], [16], [21] that prevent various attacks from disrupting different SDN layers. We detail our attacks and the mechanisms of bypassing existing defense systems in Section IV.…”

Section: A Threat Modelmentioning

confidence: 99%

“…By abusing APIs and permissions provided by controllers, malicious applications can significantly disrupt SDN systems, such as controller rootkits [44] and SDN environment killing [11]. Therefore, researchers have provided many security enhancement systems [16], [10], [12], [7], [13], [14]. Rosemary [16] isolates applications in sandboxes to safeguard controllers from errant operations performed by applications.…”

Section: Related Workmentioning

confidence: 99%

“…Rosemary [16] isolates applications in sandboxes to safeguard controllers from errant operations performed by applications. SE-Floodlight [10], Secure-Mode ONOS [12] and SDNShield [7] provide permission-based access control to enforce minimum required privileges to individual applications. AEGIS [13] and Controller DAC [14] enable dynamic access control for applications to protect controllers against API abuse.…”

Section: Related Workmentioning

confidence: 99%

“…To prevent malicious applications from disrupting SDN systems, a number of effective defense systems have been proposed. Permission control systems can effectively limit excessive privileges of applications [12], [7], [13], [14]. Data provenance systems can prevent cross-app poisoning by tracking shared data objects in controllers and checking information flow control (IFC) [1].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

When Match Fields Do Not Need to Match: Buffered Packets Hijacking in SDN

Cao¹,

Xie²,

Sun³

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Software-Defined Networking (SDN) greatly meets the need in industry for programmable, agile, and dynamic networks by deploying diversified SDN applications on a centralized controller. However, SDN application ecosystem inevitably introduces new security threats since compromised or malicious applications can significantly disrupt network operations. Thus, a number of effective security enhancement systems have been developed to defend against potential attacks from SDN applications. In this paper, we identify a new vulnerability on flow rule installation in SDN, namely, buffered packet hijacking, which can be exploited by malicious applications to launch effective attacks bypassing all existing defense systems. The root cause of this vulnerability lies in that SDN systems do not check the inconsistency between buffer IDs and match fields when an application attempts to install flow rules. Thus, a malicious application can manipulate buffer IDs to hijack buffered packets even though they do not match any installed flow rules. We design effective attacks exploiting this vulnerability to disrupt all three SDN layers, i.e., application layer, data plane layer, and control layer. First, by modifying buffered packets and resending them to controllers, a malicious application can poison other applications. Second, by manipulating forwarding behaviors of buffered packets, a malicious application can not only disrupt TCP connections of flows but also make flows bypass network security policies. Third, by copying massive buffered packets to controllers, a malicious application can saturate the bandwidth of SDN control channels and their computing resources. We demonstrate the feasibility and effectiveness of these attacks with both theoretical analysis and experiments in a real SDN testbed. Finally, we develop a lightweight defense system that can be readily deployed in existing SDN controllers as a patch.

show abstract

Section: A Threat Modelmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

When Match Fields Do Not Need to Match: Buffered Packets Hijacking in SDN

Cao¹,

Xie²,

Sun³

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…To date, defenses that limit the SDN attack surface have included app sandboxing [75], TLS-enabled APIs [61,64,68], API abuse prevention [65,78], and role-based access control (RBAC) for apps [68,89], among others. Although these mechanisms improve control plane security, we posit that they are not sufficient for mitigating information flow attacks within the control plane.…”

Section: Introductionmentioning

confidence: 99%

Cross-App Poisoning in Software-Defined Networking

Ujcich

Jero

Edmundson

et al. 2018

Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

Software-defined networking (SDN) continues to grow in popularity because of its programmable and extensible control plane realized through network applications (apps). However, apps introduce significant security challenges that can systemically disrupt network operations, since apps must access or modify data in a shared control plane state. If our understanding of how such data propagate within the control plane is inadequate, apps can co-opt other apps, causing them to poison the control plane's integrity. We present a class of SDN control plane integrity attacks that we call cross-app poisoning (CAP), in which an unprivileged app manipulates the shared control plane state to trick a privileged app into taking actions on its behalf. We demonstrate how role-based access control (RBAC) schemes are insufficient for preventing such attacks because they neither track information flow nor enforce information flow control (IFC). We also present a defense, ProvSDN, that uses data provenance to track information flow and serves as an online reference monitor to prevent CAP attacks. We implement ProvSDN on the ONOS SDN controller and demonstrate that information flow can be tracked with low-latency overheads. CCS CONCEPTS • Security and privacy → Access control; Information flow control; Information accountability and usage control; • Networks → Programmable networks; KEYWORDS software-defined networking; data provenance; information flow control; network operating system * DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

show abstract

DMoiSDN: A defensive mechanism of object integrity for SDN

Alsalamh,

Al‐Mutairi,

Humayed

et al. 2023

Concurrency and Computation

View full text Add to dashboard Cite

SummarySoftware‐defined network (SDN) technology is widely used for computer networks, especially in enterprise data centers and virtualized networking. However, SDN networks encounter severe challenges to security. One such challenge comes from third‐party applications that contain malicious logic and security vulnerabilities, resulting in controller integrity attacks. In this paper, we propose a defensive mechanism of object integrity for SDN (DMoiSDN) to mitigate the issue known as Cross‐App Poisoning (CAP). Our results contribute to increasing the integrity level of the controller's resources by conducting a potential risk analysis, which showed a decrease of 57% in the risk factor for potential attacks. We further examined the results of comparing DMoiSDN's performance with related work that uses information flow control (IFC) policies. The best results among the three conducted scenarios were as follows: we found that decreased latency in our system ranged from 12% to 90%, with an average of 59%, when encountering an increase in requests. It ranged from 78% to 49%, with an average of 63%, when receiving a variable number of total permissions for each application. DMoiSDN is expected to show a perceptible but reasonable latency and, to some extent, be able to avoid a critical impact on performance.

show abstract

A Security-Mode for Carrier-Grade SDN Controllers

Cited by 25 publications

References 15 publications

When Match Fields Do Not Need to Match: Buffered Packets Hijacking in SDN

When Match Fields Do Not Need to Match: Buffered Packets Hijacking in SDN

Cross-App Poisoning in Software-Defined Networking

DMoiSDN: A defensive mechanism of object integrity for SDN

Contact Info

Product

Resources

About