Security Considerations of Software-defined Networks. Felix Klaedtke NEC Labs Europe, Heidelberg

Transcription

1 Security Considerations of Software-defined Networks Felix Klaedtke NEC Labs Europe, Heidelberg

2 SDN Security Background

3 Software-defined Networking in a Nutshell Networks How networks operate is currently undergoing a major change network controller control plane control plane data plane control plane data plane control plane data plane control plane data plane data plane 3 NEC Corporation 2015

4 Software-defined Networking in a Nutshell (cont.) SDN eases network operation Standardized protocols between data plane and control plane OpenFlow is the most prominent one Supported by switch manufacturers The network becomes programmable Automate network operation tasks New/better/richer network services Network virtualization is seen as the killer app for SDN Various start-ups that build network applications (software!) An analogy: In the 60s and 70s: Still true today (mostly): specialized applications app app app app specialized features app app app app specialized OS OS (Windows, OSX, Linux) specialized control plane controller (ONOS and OpenDaylight) specialized hardware microprocessor specialized hardware switching hardware 4 NEC Corporation 2015

5 A Software-defined Network State of the art: network applications are built into the controller Developed/customized and deployed by the network administrator Controller specific A few exist for core network tasks (e.g., routing and monitoring) Envisioned: network applications as apps on your phone Developed by third parties and run by all kind of network users Controller independent Various apps for all sort of tasks (network app store, see e.g., OFPT_FLOW_MOD OFPT_PACKET_IN L3 SCR: L3 DST: L4 SRC: 5433 L4 DST: 80 forwarding element L3 SCR: L3 DST: L4 SRC: 5433 L4 DST: 80 SDN controller app 1 app 2 north-bound interface L3 SRC L3 DST ACTION 10.*.*.* 11.*.*.* fwd to port 2 south-bound interface 5 NEC Corporation 2015

6 SDN Architecture ONF s SDN architecture SDN Architecture Overview (version 1.1). ONF TR-504. November SDN controllers FlowVisor Ryu and many more opensource projects Also various proprietary controllers, e.g., NEC s ProgrammableFlow controller 6 NEC Corporation 2015

7 SDN Security Network applications Enhance security of SDN networks and build new security services Secure SDN networks against attacks, e.g., DoS Restrict and verify controller-switch interactions and secure network flows, e.g., by multitenant access control for network applications Leverage SDN to build new security services, such as isolated network slices 7 NEC Corporation 2015

8 Fingerprinting Software-defined Networks

9 Motivation Packets are processed much faster at the data plane of an SDN network than on its control plane SRC DST protocol out port * R TCP 1 SDN controller * R UDP 2 sender receiver An attacker can measure the processing times of packets Information leakage about the network s control logic 9 NEC Corporation 2015

10 Exploitations Knowledge about the controller-switch interactions empowers an attacker to launch powerful DoS attacks Overload the controller (e.g., too many packet-in messages) Overload the switch (e.g., fill TCAMs) SDN controller Fingerprinting the network can also be exploited for rule scanning Is it feasible to fingerprint an SDN network? Accuracy of predicting a controller-switch interaction? Impact of the number of switches? Active versus passive attacker? 10 NEC Corporation 2015

11 Testbed Simulation of a data-center architecture 3 NEC PF5240 switches and 1 OpenVswitch Floodlight controller Cross-traffic also processed by OpenFlow switches Probe from Internet firewall OpenFlow switches receiver Multiple sender locations around the globe (Amazon EC2 and Microsoft Azure) Measurements conducted over several weeks Time-based features measured at the sender 1. Dispersion 2. Round-Trip Time (RTT) 11 NEC Corporation 2015

12 Results 3 hardware switches PDF N : packet does not trigger rule installation PDF Y : packet triggers rule installation Distributions (PDF N and PDF Y ) significantly differ 1. Dispersion Stable over time Less affected by network size 2. Delta-RTT Less stable over time Can be extracted from passive measurement Experiments provide evidence that fingerprinting an SDN network is feasible With high accuracy (>95%) Number of hardware switches has minor impact Fingerprinting remains feasible even in the presence of a software switch Even a passive attacker can fingerprint an SDN network 12 NEC Corporation 2015

13 Countermeasure Control plane cannot be made significantly faster (ns instead of ms) Make processing times for packets indistinguishable Delay matching packets at a switch before forwarding them Severely harms network performance Delay the first few packets of old flows The delay can be determined from our observations Obscure attacker whether additional delay is caused by controller-switch interaction or our countermeasure No overhead for control plane, minor impact on network performance, and effective 13 NEC Corporation 2015

14 Control Plane Security Policies

15 Network Policies Focus on what should and shouldn t happen with the network packets Which network flows are allowed (e.g., which hosts can access which servers) For policy enforcement: firewalls and middleboxes Verification of network configurations (and also network applications) H. Mai, A. Khurshid, R. Agarwal, M.Cesar, B. Godfrey, S. T. King. Debugging the data plane with Anteater. SIGCOMM M. Canini, D. Venzano, P. Peresini, D. Kostic, J. Rexford. A NICE way to test OpenFlow applications. NSDI A. Khurshid and X. Zou, W. Zhou, M. Cesar, B. Godfrey. VeriFlow: Verifying networkwide invariants in real time. NSDI P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, S. Whyte. Real time network policy checking using header space analysis. NSDI T. Ball, N. Bjorner, A. Gember, S. Itzhaky, A. Karbyshev, M. Sagiv, M. Schapira, A. Valadarsky. VeriCon: Towards verifying controller programs in software-defined networks. PLDI and many more; see also the tutorial at last year s SIGCOMM What about policies for the control plane? How should and shouldn t network applications interact with each other? How should they react to certain network events? Mechanisms for policy enforcement or checking policy compliance of the control plane? 15 NEC Corporation 2015

16 Network Applications Examples: routing, traffic monitoring, Make use of the controller s APIs Access network resources through the controller Interact (directly or indirectly) with each other Operated buy different entities Current controllers trust the network applications; however, network applications: can wrongly interact with the controller (e.g., wrong use of APIs) can wrongly interact with each other can have competing objectives can be vulnerable (e.g., because of software bugs) can be malicious Note that we also trust the controller Its APIs can be buggy It can be vulnerable It even can be malicious and we trust the data plane components (e.g., switches) 16 NEC Corporation 2015

17 Trustworthy SDN Policy enforcement/compliance checking at runtime Isolation and virtualization Also simplifies network operation Reduces the risk of interference between components and network parts Physical resources are still shared (side channels) We need a trustworthy isolation platform Trusted computing Ensures that we run the intended software Support from hardware and software manufactures Need a root of trust Does, e.g., not protect from software bugs None is a silver bullet No surprise and not expected Mechanisms complement each other All can be applied to increase the trustworthiness of SDN networks 17 NEC Corporation 2015

18 Privileges of Network Applications Apply security principle of least privilege [Saltzer, 1974]: Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job. Extend ONF s SDN architecture Reference Monitor Principles of a reference monitor [Anderson, 1972]: 1. complete mediation 2. tamperproof 3. Verifiable Proof-of-concept implementation for the ONOS controller 18 NEC Corporation 2015

19 Network Resources OFPT_FLOW_MOD OFPT_PACKET_IN app 2 app 1 L3 SCR: L3 DST: L4 SRC: 5433 L4 DST: 80 forwarding element L3 SCR: L3 DST: L4 SRC: 5433 L4 DST: 80 SDN controller reference monitor north-bound interface L3 SRC L3 DST ACTION 10.*.*.* 11.*.*.* fwd to port 2 south-bound interface 1. The flow tables Hierarchical structured in flow spaces at the control plane Read and modify permissions Ownership and delegation 2. The flow rules Read and modify permissions Ownership and delegation 3. (OpenFlow) messages from data plane 4. (OpenFlow) messages to data plane 19 NEC Corporation 2015

20 Access Control Scheme The scheme is simple and at the controller s southbound (OpenFlow) Supports the principles of a reference monitor Can be complemented with schemes for higher network abstractions Resemblance with access control schemes of operating systems SDN OS (hierarchical) flow table directory flow rule file Attributes to express relations between flow rules In addition to the flow rules attributes (e.g., priority and timeout values) in the OpenFlow standard These new attributes are attached to flow rules and only exist at the control plane Example: no overwrite prevents the installation of overlapping flow rules with higher priority 20 NEC Corporation 2015

21 Policy Compliance (work in progress) Our reference monitor is limited in scope Basic access control at the SBI of the controller This limitation is on purpose Some policies are not enforceable by runtime monitors An enforceable policy is a safety property [Schneider, 2000] And not even all safety properties are enforceable [Basin et al., 2013] Enforcement might also be too expensive Aim for something weaker/stronger instead View the SDN network as a distributed system Monitor the behavior of the network components Check (offline or online) whether behavior is policy compliant, where policies are expressed in a rich specification language Current status Our policy specification language allows one to express temporal constraints Our online algorithm soundly handles message delays and message loss Our prototype implementation has a throughput of up to 200 message/second 21 NEC Corporation 2015

22 Concluding Remarks

23 Conclusions & Future Work Software is eating the world Marc Andreessen, 2011 SDN will make networks cheaper, richer, and more reliable Less specialized hardware Standardized APIs Network abstractions Virtualized network functions Etc. and also more secure However, SDN needs to be secured by itself Current state-of-the-art controllers still fall short in this respect The control plane (and everything above) is a valuable target Software is, e.g., buggy and vulnerable We have a rich tool set for system security Adapt and extend existing methods and techniques from other areas to SDN SDN networks are large and highly distributed systems Performance is critical in networking 23 NEC Corporation 2015

24 Personal Opinions There is nothing clever about SDN. Why hasn t it be done like this in the first place? The speed and achievements in SDN is amazing! 24 NEC Corporation 2015

25

26