MITIGATING LAYER 2 ATTACKS: RE-THINKING THE DIVISION OF LABOR M.Sc Final Project Nir Solomon Supervised by: Prof. Anat Bremler-Barr December 2015 | IDC Herzliya General Idea in One Slide While OpenFlows whole-view enables to gather network statistics to prevent attacks, it is also susceptible to some Specifically: ARP Poisoning and Controller DDoS We will show how these attacks are executed Also the Controller cannot support the load of handling all the forwarding decisions by itself Our solution called Reactive ARP Query, helps mitigate these attacks By shifting Control-plane responsibilities back to the switch! SDN Switch Controller Outline OpenFlow Intro Legacy Network Layer 2 Attacks Our Contribution Related and Previous Work SDN Layer 2 Attacks Proposed Solution Evaluation Conclusions OpenFlow - Introduction Provides a scalable way to manage SDN networks Control-Plane and Data-Plane A centralized Controller Whole view of the network The ability to gather information and statistics from every network component O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS OpenFlow Flow Tables Every flow that has been installed by the Controller, is added to a flow table residing on the Switch ActionDST MACSRC MACRule Output to port 100:20:B9:CC:2D:A8AA:BB:CC:DD:EE:EERule 1 Output to Port 200:6F:25:1B:99:0C00:11:22:33:44:BE:EFRule 2 Send to Controller* (Dont Care) Rule 3 O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS OpenFlow Learning Switch An application running on the Controller Reactively installs flows on the switch for every packet that dont have a matching flow and arrives an the Controller This event is called a packet-in The next time that a packet is received by the switch, it will be handled and forwarded automatically O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Reactive Packet not matching any flow triggers controller to insert flow entries Efficient use of flow table Every flow incurs small additional flow setup time If control connection lost, switch has limited utility Proactive Controller pre-populates flow table in switch Must know the network topology ahead of time Zero additional flow setup time Essentially requires aggregated (wildcard) rules Hard to install new flows after the network starts operating problematic in BYOD networks OpenFlow Reactive & Proactive O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS The ARP Protocol ARP Request: Argon broadcasts an ARP request to all stations on the network: What is the hardware address of ? O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS The ARP Protocol ARP Reply: Router 137 responds with an ARP Reply which contains the hardware address O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS The ARP Protocol - Cache Hosts maintain a table (ARP Cache) of current entries for each NIC installed The entries expire after some time (implementation dependant e.g. Windows XP - 2 mins, RedHat - 60 secs). For example, an ARP cache in Windows (arp -a ): O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Gratuitous ARP - an ARP request/reply that is not normally needed according to the RFC but could be used in some cases Request: the packet has the source and destination IP both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address Reply: is a reply to which no request has been made Useful for: Detecting IP conflicts Push update to other machines ARP tables (e.g. when host changes its IP address) Inform switches of the hosts address on a given switch port O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS The ARP Protocol Gratuitous ARP Layer 2 Attacks ARP Poisoning A forged ARP Request or Reply can be used to update the ARP cache of a remote system with a forged entry O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Switch Alice MAC: 00:00:00:00:00:01 IP: Bob MAC: 00:00:00:00:00:02 IP: Eve MAC: 00:00:00:00:00:03 IP: is at 00:00:00:00:00: is at 00:00:00:00:00:03 To: 00:00:00:00:00: Layer 2 Attacks - DDoS The attempt to make a machine or service unavailable to its legitimate users, by consuming its resources by a large group of attackers A DDoS scenario may quickly worsen, such as when sending a packet to the victim will cause him to send a reflected packet to another host In many cases, the best solution to contain the damage is to use Rate Limiting We will show that it is possible to create a Layer 2 DDoS on the OpenFlow Controller, while using only ARP packets O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Our Contribution In summary, our work makes the following contributions: Overview of an ARP Poisoning attack and its execution in an OpenFlow network Presentation of a new attack vector on OpenFlow - ARP level Distributed Denial of Service (DDoS) attack on the OpenFlow Controller Extension of the current implementation of OpenFlow to include new mechanisms to mitigate Layer 2 attacks, and an evaluation O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Related & Previous Work O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Legacy ARP Poisoning Mitigation: [Nam et al, 2010] OpenFlow Vulnerability Assessments including DDoS: [Yan et al, 2015], [Kloti et al, 2013], [Benton et al, 2013] Using specially-crafted packets to attack OpenFlow networks: [Shin and Gu, 2013] Shifting responsibilities from the Controller to the Switch: [Shin et al, 2013], [Curtis et al, 2011] Using the Whole-View of SDN to mitigate network attacks: [Braga et al, 2013], [Phaal et al, 2013], [Porras et al, 2013], [Porras et al, 2012] SDN Attacks - ARP Poisoning O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Alice MAC: 00:00:00:00:00:01 IP: Bob MAC: 00:00:00:00:00:02 IP: Eve MAC: 00:00:00:00:00:03 IP: is at 00:00:00:00:00: is at 00:00:00:00:00:03 To: 00:00:00:00:00: ActionIN PORTSRC MAC ActionDST MAC Table 0 Table 1 GOTO Table 1300:00:00:00:00:03 OUTPUT to 300:00:00:00:00:03 GOTO Table 1100:00:00:00:00:01 GOTO Table 1200:00:00:00:00:02 OUTPUT to 100:00:00:00:00:01 OUTPUT to 200:00:00:00:00:02 SDN Attacks Controller DDoS We would like to overload the Controller with multiple packet-in events An attacker can spoof a packet as he likes Let us create a specially crafted packet that will cause a packet-in This attack is unique to OpenFlow and inherent in its design O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Attacks Controller DDoS Crafted Packet No Flow available Send to Controller Packet-in O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Attacks Controller DDoS Controller: running on a MacBook Pro with 16GB of RAM and Core i7 CPU Attacker: simulated with Cbench on an Ubuntu machine with Core i5 CPU and 4GB of RAM Reaching a certain threshold of about 1.3 Mpps (million packet-ins per second), the number of responses does not increase correspondingly O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution - Desired Properties A normal Reactive learning switch enables both ARP Poisoning and a DDoS attack We would like to define a solution with the following properties: Little load on the Controller Lesser number of flows installs on the Switch A Reactive solution We can use multiple or distributed Controllers to mitigate DDoS This is an orthogonal solution We will compare our proposed solution to the Reactive approach, and the tradeoffs of using it O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution - Shifting Control-Plane Responsibilities Usually, separation between the control plane and the data plane Creates a load on the Controller Shifting responsibilities from Controller Switch Allowing the switch to hold the IP to-MAC mappings of the hosts connected to it Similar to all the mappings usually held by the Controller Shifting control plane responsibilities has been suggested: AvantGuard [Shin et al, 2013] DevoFlow [Curtis et al, 2011] O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution General Idea In both Layer 2 attacks, spoofed ARP packets are used We aim to retain: IP-to-MAC mappings and MAC-to-Physical port mappings Of each host connected to the switch Saved in the switch, in the form of OpenFlow flows When a new host connects to the network, we want to authenticate it No matching flow for a packet sent from the new host We will send a Reactive ARP Packet If and only if the host is validated, we will send a packet-in to the Controller Else: drop the packet O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution Attacker Types When discussing the use of spoofed ARP packets, there are two kinds of attackers: Naive Attacker: will not reply to an ARP request for the (MAC, IP) he spoofs Sophisticated Attacker: will reply to an ARP request for the (MAC, IP) he spoofs O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution Possible Scenarios When sending the Reactive ARP Query, there are three possible scenarios: Two ARP replies (one with expected MAC, one with other MAC) Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply) Valid ARP reply (matching IP and MAC) O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution Scenario 1 Scenario 1: Two ARP replies (one with expected MAC, one with other MAC) This is a sophisticated attacker! O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: WHO HAS ? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: Controller Alice MAC: 00:00:00:00:00:01 IP: ActionSRC PORTSRC IPSRC MAC GOTO Table :00:00:00:00:01 WHO HAS ? is at 00:00:00:00:00: is at 00:00:00:00:00:99 DROP! (no packet-in) Solution Scenario 2 Scenario 2: Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply) O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: WHO HAS ? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: Alice MAC: 00:00:00:00:00:01 IP: ActionSRC PORTSRC IPSRC MAC GOTO Table :00:00:00:00:01 WHO HAS ? is at 00:00:00:00:00:01 DROP! (no packet-in) Controller Solution Scenario 3 Scenario 3: Valid ARP reply O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Eve MAC: 00:00:00:00:00:03 IP: WHO HAS ? Spoofed SRC MAC:00:00:00:00:00:99 Spoofed SRC IP: ActionSRC PORTSRC IPSRC MAC GOTO Table :00:00:00:00:01 WHO HAS ? Host (or attacker) is validated is at 00:00:00:00:00:99 Alice MAC: 00:00:00:00:00:01 IP: Packet-in Packet-out+ Install Flow GOTO Table :00:00:00:00:99 Solution What About the Last Scenario? A sophisticated attacker may still be validated he can still create packet-ins! We can use a Rate Limiting mechanism Rate limit only the table misses Only the physical port of the sender Also used against DNS DDoS Amplification attacks O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution Rate Limiting With regard to denial-of-service vulnerabilities, controller vendors need to emphasize the importance of rate-limiting. Even for an application as simple as this one (Learning Switch) protecting it requires implementing MAC spoofing protection through port counters (with timers if network flexibility is required), rate limiters for traffic to unknown hosts, and switch rules for multicast. Networks that rely heavily on PacketIn messages (i.e. reactive designs) can be exposed to denial-of-service attacks against the switches and controller(s) without complex rate-limiting logic in the controller. O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS OpenFlow Vulnerability Assessment, [Benton et al, SIGCOMM 2013] Solution Rate Limiting (Continued) Work is being done to gather network statistics in OpenFlow Flow Collector - Percentage of Pair-flows (PPf) [Braga et al, 2013] Pair-Flow: The source IP of flow 1 must be equal to the destination IP of flow 2 The destination IP of flow 1 must be equal to the source IP of flow 2 Both flows must have the same communication protocol DDoS increases the number of single-flows A switch that has a host suspected as a sophisticated attacker, may use these statistics to decide if the physical port has a large number of single-flows, and limit it accordingly Out of the scope of this work O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution Assumptions We assume a steady state when the network starts operating If an attacker binds the victims IP address to its MAC address before the victim connects, the victims packets will be dropped Can be prevented: By using our solution as soon as the network starts operating Or by installing proactive rules for all known safe hosts ahead O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Solution The Division of Labor There is a fine line between the Control Plane and the Data Plane Only some suggested that this line should be crossed When thinking of the default component used to mitigate network attacks in an SDN network, we think of the Controller - [Braga et al, 2013] We conclude that the Controller, by itself, cannot hold these responsibilities, as the load may cause it to stop function correctly Instead, our approach takes the a different direction; we shift these responsibilities from the default component, the Controller (control plane) into the switch (data plane) O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Evaluation ARP Poisoning O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS SDN Switch Alice MAC: 00:00:00:00:00:01 IP: Bob MAC: 00:00:00:00:00:02 IP: Eve MAC: 00:00:00:00:00:03 IP: is at 00:00:00:00:00:03 ActionIN PORT SRC IPSRC MAC Table 0 Steady State GOTO Table :00:00:00:00:01 GOTO Table :00:00:00:00:02 WHO HAS ? is at 00:00:00:00:00: is at 00:00:00:00:00:02 DROP! (also: no packet-in) Evaluation DDoS Naive Attacker - Packet-ins Using a normal OpenFlow Switch, each spoofed packet requires a packet-in to be received by the Controller Using the Reactive ARP Query Switch, no packet-ins are received at the Controller at all O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Evaluation DDoS Naive Attacker - Flows Installed Using a normal OpenFlow Switch, two flows will be installed for each packet-in - one matches on the source, and one on the destination In our solution, we drop the attacking packet, without installing any flows, and without informing the Controller O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Evaluation DDoS Sophisticated Attacker - Packet-ins Using a normal OpenFlow Switch, each spoofed packet requires a packet-in to be generated by the switch and received by the Controller Using the Reactive ARP Query Switch, the rate of the packet-ins are limited (in our case, to 100 packets per second, chosen arbitrarily) If the Rate-Limiting rate is N pps, then we can assure that the maximum packet-in rate at the Controller will be N pps as well O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Evaluation DDoS Sophisticated Attacker - Flows Installed Using a normal OpenFlow Switch, two flows will be installed for each packet- in - one matches on the source, and one on the destination In our solution, we rate-limit the incoming packet-ins, so the rate of the creation of new flows depends on the rate limitation O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Evaluation Network Overload The three possible scenarios are: Two ARP replies (one with expected MAC, one with other MAC). Invalid ARP reply (a packet is returned with a different MAC address than expected/No reply). Valid ARP reply (matching IP and MAC). Sophisticated Attacker. The first packet sent by him will be intercepted by the switch. A single Reactive ARP packet will be issued for the attackers packet to be dropped. The attacker is naive and a single Reactive ARP packet is used for the packet to be dropped. Might be the attackers packet or a valid host the connected to the network. Let us assume the worst case scenario - that this host is an attacker. We will send an ARP validation, and he will be validated. No more packets from him with his SRC MAC will be validated as a flow is being installed by the Controller. Thus the network overhead here is only a single packet O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Conclusions We presented the execution of Layer 2 attacks in OpenFlow network: ARP Poisoning; and a Layer 2 DDoS on the Controller, which is an inherent vulnerability in OpenFlow networks. We have proposed an extension to OpenFlow Reactive ARP Query. While our solution has only a minor network overhead, both attacks can be mitigated successfully. This is a major step in changing our approach by shifting the control plane responsibilities back to the switch. O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Future Work We hope to allow the creation of a smart Rate-Limiting algorithm, by gathering flow metrics from the whole network Rate-Limit the physical port according to the flow metrics gathered We hope to also implement the Reactive ARP Query extension on a physical switch. This implementation will allow the evaluation of its performance while running as a totally independent data plane component O PEN F LOW I NTRO L EGACY L AYER 2 A TTACKS O UR C ONTRIBUTION R ELATED W ORK SDN L AYER 2 A TTACKS P ROPOSED S OLUTION E VALUATION C ONCLUSIONS Questions? Thanks!