Research Project:
Floodlight DDoS Vulnerability
Nir Solomon, Yoav Francis and Liahav Eitan
Supervised by : Yotam Harchol a...
Background
Project Goal: DDoS in an OpenFlow
Controller
We aimed to explore the possibility of DDoS on an OpenFlow Controller
OFC – t...
Background - OpenFlow
“an open interface for remotely
controlling the forwarding
tables in network switches,
routers, and ...
Jargon – Secure Channel
The secure channel is the interface that connects an OpenFlow device
(switch) to the controller.
T...
Jargon – “packet_in”
if a packet does not match any of the existing rules on an OFS, default policy
is to send the header ...
Secure Channel Sample pcap
DDoS on an OpenFlow Controller
Effects of OFC-DDoS on the network:
• Increased latency and packet loss in the entire netwo...
Attack Vectors in Software-Defined
Networks
• OFS / OFC Attacks :
• Switch input buffer overload
• OpenFlow Module vulnera...
Chosen Attack Vector
• Assume control of multiple endpoint computers in the network
• Send specially-crafted packets that ...
DDoS Attack – Example
OpenFlow Controller
OpenFlow
Switches
Crafted
Packet
No Flow
available
 Send to
Controller
Packet_in
Related Work
OpenFlow Vulnerability Assessment
K. Benton, L.J. Camp, C. Small
Sigcomm 2013
A brief overview of the vulnerabilities pres...
Attacking Software-Defined Networks:
A First Feasibility Study
S. Shin, G. Gu
Sigcomm 2013
A method to fingerprint software...
OpenFlow: A Security Analysis
R. Kloti
Swiss Federal Institute of Technology Zurich 2012
A detailed security analysis of O...
Research and Results
Floodlight
We have chosen Floodlight as our targeted OpenFlow controller in this work
Common enterprise level controller
...
Floodlight
Part I – Floodlight DDoS by Simulating
Packet-In Events with CBench
 Cbench tests OFCs by sending packet-in events
 Cben...
Floodlight’s LoadMonitor
On high loads, the LoadMonitor practically performs DoS by itself!
Floodlight’s LoadMonitor - cont
Floodlight’s LoadMonitor - cont
The LoadMonitor was disabled by default in the Floodlight git
because the "overload protec...
Floodlight DoS Test Method
We created a Python script which is run on the mininet VM:
•Kills running Floodlight instances
...
Floodlight DoS Test Results
• The blue line represents the
normal mode, and the green
line represents the load
monitor mod...
Part II – Create Specially Crafted Packets
 In this part we demonstrate a way to coerce OpenVSwitch to send
packet-ins to...
Part II - Test Method
• The specially-crafted packets that we sent from the mininet hosts are ARP
packets with random sour...
Part II – Additional Results
• We wanted to also test the network performance during the attack.
• During the attack:
• We...
Part II – Additional Results (cont)
    Throughput (Mbit/s)
Switches Hosts initial 30s 60s 90s 120s 150s 180s 210s 240s 27...
Part II – Additional Results (cont)
Conclusions
 In the work we have found two vulnerabilities in wide-spread SDN
implementations:
1. A DDoS vulnerability in...
Possible Solutions
 Rate limiting of Packet-In events per application (switch-level)
 Flow Aggregation
o controller stra...
Possible Solutions (cont)
 Careful event filtering
o Resembles the idea of Floodlight’s Load Monitor
 Anomaly detection
...
Insights
Insights from Research Process
 Current implementations, specifically Floodlight and OpenVSwitch, do
not adhere to the Op...
Questions ?
Thanks !
Floodlight OpenFlow DDoS
Upcoming SlideShare
Loading in...5
×

Floodlight OpenFlow DDoS

3,537

Published on

By Nir Solomon, Yoav Francis and Liahav Eitan

Abstract:
One of greatest applicative benefits of SDN is enhancement of network security by making the network react to threats in real-time using data from all the switches in the network. For example, the OpenFlow Controller (OFC) can identify a DDoS attack on the network and divert or block traffic in an adaptive manner.
Unfortunately, OpenFlow also introduces a new threat to network security – attacks on the OFC itself, the “soft-belly” in regards to network security in SDN. The controller, by being responsible for multiple switches, is a `high-valued` target (a single point-of-failure), and we aim to understand better its vulnerability to DDoS attacks.
DDoS on the OFC can affect the entire network in several ways, depending on the OpenFlow Applications in the network and the level of dependency of the OF Switches on the OFC:
1. The entire network might be slowed down and suffer from packet-loss.
2. Some packets might be handled normally while others are mishandled by switches in the network, depending on the OpenFlow Applications that apply to these packets and whether they require communication with the OFC.
3. The entire network might stop functioning.
All of the above share a unique property that does not apply in ordinary DDoS attacks: even if only one or two switches are being flooded, the entire network can be affected.

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,537
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Floodlight OpenFlow DDoS

  1. 1. Research Project: Floodlight DDoS Vulnerability Nir Solomon, Yoav Francis and Liahav Eitan Supervised by : Yotam Harchol and Anat Bremler-Barr September 2013 | IDC Herzelia
  2. 2. Background
  3. 3. Project Goal: DDoS in an OpenFlow Controller We aimed to explore the possibility of DDoS on an OpenFlow Controller OFC – the “soft-belly” in regards to network security of a Software-Defined Network. The controller, by being responsible for multiple switches, is a `high- valued` target.
  4. 4. Background - OpenFlow “an open interface for remotely controlling the forwarding tables in network switches, routers, and access points. Upon this low-level primitive, researchers can build networks with new high-level properties”
  5. 5. Jargon – Secure Channel The secure channel is the interface that connects an OpenFlow device (switch) to the controller. This channel is encrypted with SSL. But… This is not enough to prevent a DDoS from happening!
  6. 6. Jargon – “packet_in” if a packet does not match any of the existing rules on an OFS, default policy is to send the header to the OFC.   This “packet sent to the controller” message is called a “packet-in”.“packet-in”. We will explore DDoS using this type of packet. “an OpenFlow controller can block traffic, install rate limiters, or even change the default policy for an unmatched packet to drop it on the ground.” “ ..But on the other side, being too aggressive—that is blocking or rate limiting too much—can break features or have a negative impact on performance.” (Floodlight Blog)
  7. 7. Secure Channel Sample pcap
  8. 8. DDoS on an OpenFlow Controller Effects of OFC-DDoS on the network: • Increased latency and packet loss in the entire network • The entire network might stop functioning • Mishandling of specific protocols by the switches • Protocols that require constant communication with the OFC are more vulnerable Difference from classic DDoS attacks: • An attack carried out at one place in the network can affect the global network behavior
  9. 9. Attack Vectors in Software-Defined Networks • OFS / OFC Attacks : • Switch input buffer overload • OpenFlow Module vulnerability in OFS (Software vulnerability) • Secure Channel traffic amplification • Assuming access to the Secure Channel: •SYN flood (or any other TCP attack) •ARP Poison between OFS and OFC if there is no SSL
  10. 10. Chosen Attack Vector • Assume control of multiple endpoint computers in the network • Send specially-crafted packets that do not match flows in the OFS • The switches will then create packet_in events to the controller – Secure Channel Traffic Amplification • This will also overload the CPU of the controller because of multiple secure channel connections – CPU depletion • After some time – the controller will have to drop packets due to high load  DDoS
  11. 11. DDoS Attack – Example OpenFlow Controller OpenFlow Switches Crafted Packet No Flow available  Send to Controller Packet_in
  12. 12. Related Work
  13. 13. OpenFlow Vulnerability Assessment K. Benton, L.J. Camp, C. Small Sigcomm 2013 A brief overview of the vulnerabilities present in current OpenFlow devices. Finds that OpenFlow implementations rely on physical security •Lacks TLS, Access Control •Repeats errors of older network management protocols • Telnet, SNMPv2, TFTP Existing vulnerabilities assuming access to the Secure Channel: •Man in the Middle •Listener Mode •Switch Authentication •Flow Table Verification •Denial of Service Risks •Controller Vulnerabilities
  14. 14. Attacking Software-Defined Networks: A First Feasibility Study S. Shin, G. Gu Sigcomm 2013 A method to fingerprint software-defined networks. The fingerprinting is done by noticing the different response times in the cases of Existing-Flow and New-Flow. The article suggests that if an attacker identifies a network as an SDN, they can move on to conduct a resource consumption attack (DoS).
  15. 15. OpenFlow: A Security Analysis R. Kloti Swiss Federal Institute of Technology Zurich 2012 A detailed security analysis of OpenFlow 1.0 that describes, categorizes and suggests solutions for different attack methods. Three categories of attacks on Software Defined Networks: •Information Disclosure •Tampering •Denial of Service Several targets for DDoS attacks: -OFS flow table – overload the switches’ flow table -OFS input buffer – make the switches send whole packets to the OFC -OFS OpenFlow Module – software vulnerability -Management Interface and/or Controller – software vulnerability Most of these attacks do not target the OFC, but some solutions still applicable: •Rate limiting, flow aggregation, attack detection
  16. 16. Research and Results
  17. 17. Floodlight We have chosen Floodlight as our targeted OpenFlow controller in this work Common enterprise level controller  Used by Arista, Brocade, Citrix, Dell, Extreme Networks, Fujitsu, Google, HP, IBM, Intel, Juniper Networks and Microsoft Open-source JAVA code with public git repository Declares itself to be designed for high-performance  therefore should not be susceptible to DDoS attacks Easy to use and deploy
  18. 18. Floodlight
  19. 19. Part I – Floodlight DDoS by Simulating Packet-In Events with CBench  Cbench tests OFCs by sending packet-in events  Cbench emulates switches which connect to a controller, send packet-in messages, and watch for flow-mods to get pushed down  We used Cbench to directly test how Floodlight responds to a flood of packet-in events on the secure channel  Note that in real-life scenarios, we will also need a way to generate the packet-in events using specially crafted packets.  We will demonstrate such a way in part 2.
  20. 20. Floodlight’s LoadMonitor On high loads, the LoadMonitor practically performs DoS by itself!
  21. 21. Floodlight’s LoadMonitor - cont
  22. 22. Floodlight’s LoadMonitor - cont The LoadMonitor was disabled by default in the Floodlight git because the "overload protection is not yet tuned”
  23. 23. Floodlight DoS Test Method We created a Python script which is run on the mininet VM: •Kills running Floodlight instances •Runs Floodlight with correct configuration •Runs Cbench with an increasing number of switches (20-300) and a constant number of simulated MAC addresses (100000) •Sniffs the returning packets from the OFC •Calculates the average number of flow mods per second returned from the controller, per run •Saves the average fmods and the sniffed packets to a pickle file
  24. 24. Floodlight DoS Test Results • The blue line represents the normal mode, and the green line represents the load monitor mode. • Overall, especially when dealing with a large number of switches, the load monitor mode decreases the controller performance. • This is practically a DoS using the secure channel access, as Cbench simulates OpenFlow switches.
  25. 25. Part II – Create Specially Crafted Packets  In this part we demonstrate a way to coerce OpenVSwitch to send packet-ins to the OFC.  In this part we do not assume access to the Secure Channel – unlike Cbench in the previous part  The entire attack must be carried out entirely from the endpoint computers  We do this using a specially crafted packet that is sent from the computers and generates packet-in events in the switches.
  26. 26. Part II - Test Method • The specially-crafted packets that we sent from the mininet hosts are ARP packets with random source MACs: Ethernet Header Arp header Src MAC = random MAC Dst Mac = FF:FF:FF:FF:FF:FF (broadcast) Type = ARP Request   Src MAC = random MAC (same as in ETH header) Dst MAC = FF:FF:FF:FF:FF:FF (Broadcast) Src IP = Another host IP Dst IP = Another host IP (same as Src IP) • Each host Repeatedly sent this packet to all other hosts that participate in the DDoS attack, each time with a different source MAC • We found that when OpenVSwitch observes a packet from a previously unseen source MAC it sends a packet-in to the Controller and waits for a flow mod to be installed
  27. 27. Part II – Additional Results • We wanted to also test the network performance during the attack. • During the attack: • We ran two hosts that did not participate in the DDoS for performance evaluation on the end-user • We used the iperf utility, which calculates network throughput, in a pre- defined interval to evaluate network performace • We have examined this attack with varying number of “malicious” hosts and with varying number of OpenFlow Switches, and measured the network throughput in each case
  28. 28. Part II – Additional Results (cont)     Throughput (Mbit/s) Switches Hosts initial 30s 60s 90s 120s 150s 180s 210s 240s 270s 300s 10min 2 10 1270 253 146 135 156 140 186 137 150 158 98 158 2 20 1170 72 62 84 62 60 72 81 65 66 80 55 2 25 1190 30 40 37 1 40 35 43 45 34 37 44 5 10 835 94 103 115 97 53 92 76 92 100 90 61 5 20 798 41 41 FAIL 50 48 48 34 49 FAIL     5 25 FAIL                       10 10 551 44 66 20 FAIL               10 20 538 FAIL                     10 25 FAIL                       • These results show clearly that using the Specially-Crafted Packet method we have successfully denied service in the network. • As the number of hosts or switches gets sufficiently high, even two hosts that do not participate in the DDoS attack have a difficulty to communicate
  29. 29. Part II – Additional Results (cont)
  30. 30. Conclusions  In the work we have found two vulnerabilities in wide-spread SDN implementations: 1. A DDoS vulnerability in the Floodlight controller 2. A Packet-In generation vulnerability in OpenVSwitch  While exploiting these vulnerabilities, we have managed to:  Generate Packet-In events using specially crafted packets  Overload the Floodlight OpenFlow controller  Deny service from all of the OpenFlow switches that rely on the controller.
  31. 31. Possible Solutions  Rate limiting of Packet-In events per application (switch-level)  Flow Aggregation o controller strategy where one rule matches multiple flows (performance vs. precision) o Allows network to partially work when the OFC is not responsive  Fully Proactive Approach (flow rules cover all possible traffic in advance) o Immune to this sort of attack o Relinquishes many benefits of SDN – applications that require dynamic information can’t function in a proactive network.
  32. 32. Possible Solutions (cont)  Careful event filtering o Resembles the idea of Floodlight’s Load Monitor  Anomaly detection o Under heavy research for various other network security issues o More effective in a reactive SDN than in classic networks
  33. 33. Insights
  34. 34. Insights from Research Process  Current implementations, specifically Floodlight and OpenVSwitch, do not adhere to the OpenFlow RFC o TLS is not in supported o Packets are sent in whole to the OFC by default  Security is not taken seriously enough in current SDN implementations o As a Floodlight developer stated: “it would be pretty trivial to add [TLS support] if there was sufficient interest”  SDN is inherently susceptible to attacks  Not enough articles concerning SDN security  SDN applications need to be designed carefully and to meet a common security standard: o Function to some extent without a controller o Limit the number of packet-in events it generates
  35. 35. Questions ?
  36. 36. Thanks !

×