Sphinx: Detecting Security Attacks in Software-Defined ...€¦ · 10/09/2017 · Sphinx:...
Transcript of Sphinx: Detecting Security Attacks in Software-Defined ...€¦ · 10/09/2017 · Sphinx:...
Sphinx: Detecting Security Attacks in Software-Defined Networks
Mohan Dhawan Rishabh Poddar Kshiteej Mahajan Vijay Mann
IBM Research, India
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
Logically-centralized control
switches
SDN ControllerSmart, slow
Dumb, fast
Data plane2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
Logically-centralized control
switches
SDN ControllerSmart, slow
Dumb, fast
Control plane
2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
Logically-centralized control
switches
SDN ControllerSmart, slow
Dumb, fast
2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN Controller
A
B2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN Controller
A
B
PACKET_IN
2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN Controller
A
B2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN Controller
A
B2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN Controller
A
B2
Feb 11th, 2015 NDSS'15
Software-Defined Network (SDN)
SDN ControllerCorrect functioning requires preservation of
● Network topology● Data plane forwarding
2
Feb 11th, 2015 NDSS'15
Outline
● SDN Overview● Motivation● Sphinx● Implementation● Evaluation● Conclusion
3
Feb 11th, 2015 NDSS'15
Vulnerable SDNs
● OpenFlow operational semantics– All unmatched packets are forwarded to the
controller
4
Feb 11th, 2015 NDSS'15
Vulnerable SDNs
● OpenFlow operational semantics– All unmatched packets are forwarded to the
controller
● Attacks afflicting traditional networks affect SDNs too– Traditional defenses do not work in SDNs
4
Feb 11th, 2015 NDSS'15
Vulnerable SDNs
● OpenFlow operational semantics– All unmatched packets are forwarded to the
controller
● Attacks afflicting traditional networks affect SDNs too– Traditional defenses do not work in SDNs
● Attacks possible from compromised switches and end hosts– Soft switches on end host servers attractive
targets for attackers4
Feb 11th, 2015 NDSS'15
Several Attacks Possible
● Network topology– Corrupt routing table (ARP)
– Fake topology (LLDP)
– Multicast (IGMP)
● Data plane forwarding– Switch TCAM exhaustion
– Switch blackhole
5
Feb 11th, 2015 NDSS'15
Controller Vulnerability
● Security analysis of four popular available SDN controllers
Attack OpenDaylight Floodlight POX Maestro
ARP poisoning Y Y Y Y
Fake topology Y Y N Y
Controller DoS Y N Y Y
Network DoS Y Y Y Y
TCAM exhaustion N Y Y Y
Switch blackhole Y Y Y Y
7
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN ControllerLLDP
A
B
C
D
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
LLDP
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
DLLDP
LLDPD
D
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
PACKET_IN
LLDPCD
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN ControllerLLDP
A
B
C
D
PACKET_IN
BD
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
LLDPD
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
LLDPAD
PACKET_IN
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
LLDPAD
PACKET_IN
6
Feb 11th, 2015 NDSS'15
Fake Network Topology Attack
SDN Controller
A
B
C
D
LLDPAD
PACKET_IN
Video demo: http://goo.gl/zRG8bz
6
Feb 11th, 2015 NDSS'15
Outline
● SDN Overview● Motivation● Sphinx● Implementation● Evaluation● Conclusion
8
Feb 11th, 2015 NDSS'15
Detecting Security Threats in Real Time
● Verify network actions using OpenFlow metadata– All controller communication mediated by a shim
– Learn network behaviour and automatically generate network invariants
9
Feb 11th, 2015 NDSS'15
Key Idea: FlowGraphs
Exploit predictability and pattern in topologicaland data plane forwarding to detect violation
Time T1 10
Feb 11th, 2015 NDSS'15
Key Idea: FlowGraphs
Exploit predictability and pattern in topologicaland data plane forwarding to detect violation
Time T2 10
Feb 11th, 2015 NDSS'15
Workflow (I)
● Intercept relevant OpenFlow messages– PACKET_IN, FLOW_MOD, STATS_REPLY,
FEATURES_REPLY
● Intercept relevant OpenFlow messages to extract topological and forwarding metadata
11
Feb 11th, 2015 NDSS'15
Workflow (I)
● Intercept relevant OpenFlow messages– PACKET_IN, FLOW_MOD, STATS_REPLY,
FEATURES_REPLY
● Intercept relevant OpenFlow messages to extract topological and forwarding metadata
Assumption: Honest majority ofswitches along flow path
11
Feb 11th, 2015 NDSS'15
Workflow (II)
● Intercept relevant OpenFlow messages– PACKET_IN, FLOW_MOD, STATS_REPLY,
FEATURES_REPLY
● Generate flowgraph constraints from the extracted metadata
12
Feb 11th, 2015 NDSS'15
Accurate Characterization of Flows
● Maintain mapping of entities and allowed metadata– Hosts (Src MAC/IP/port, Dst MAC/IP/port)
– Switches (Switch and in/out-port)
– Flows (Flow match and statistics)
● Incrementally augment the flowgraph with such constraints
13
Feb 11th, 2015 NDSS'15
Workflow (III)
● Intercept relevant OpenFlow messages– PACKET_IN, FLOW_MOD, STATS_REPLY,
FEATURES_REPLY
● Use custom algorithms to detect constraint violations on flowgraphs
14
Feb 11th, 2015 NDSS'15
Administrator Policies
● Specified in constraint language
15
Feb 11th, 2015 NDSS'15
Administrator Policies
● Specified in constraint language
● Example policy to check if all flows from host H3 pass through specified waypoints S2 and S3
<Policy PolicyId="Waypoints"> <Subjects><Subject value="H3, *" /></Subjects> <Objects> <Object><Waypoint value="S2" /></Object> <Object><Waypoint value="S3" /></Object> </Objects> <Operation value="IN" /> <Trigger value="Periodic" /></Policy>
15
Feb 11th, 2015 NDSS'15
Constraint Validation
● Topological state– Packet spoofing, controller DoS
– Fast and deterministic
16
Feb 11th, 2015 NDSS'15
Constraint Validation
● Topological state– Packet spoofing, controller DoS
– Fast and deterministic
● Forwarding state– Flow graph consistency, switch DoS, flow statistics
– Both deterministic and probabilistic
– Similarity Index (SI) categorizes nature of flow using statistics observed at switches along the flow path
● Identify malicious switches along flow path
16
Feb 11th, 2015 NDSS'15
Outline
● SDN Overview● Motivation● Sphinx● Implementation● Evaluation● Conclusion
17
Feb 11th, 2015 NDSS'15
Implementation
● Controller-agnostic proxy between the controller and the switches– Prototype compatible with OpenFlow (v1.1.0)
– Works with OpenDaylight (v0.1.0) and Floodlight (v.0.90)
– Written in ~2100 Java LOC
– Uses the fast Netty I/O framework with separate queues for communication in either direction
18
Feb 11th, 2015 NDSS'15
Outline
● SDN Overview● Motivation● Sphinx● Implementation● Evaluation● Conclusion
19
Feb 11th, 2015 NDSS'15
Experimental Setup
● Physical setup of three tiered datacenter topology with 14 switches
● Emulated Mininet network of up to 10K hosts● Measure
– Accuracy of deterministic and probabilistic verification
– Performance impact on end user latency, throughput and policy verification
20
Feb 11th, 2015 NDSS'15
Accuracy (I)
● Attack detection times under different settings
● Measure false alarms generated in three diverse benign traffic traces (14min, 65min and 2hr)– Execution raised no alarms
21
Feb 11th, 2015 NDSS'15
Accuracy (II)
● Probabilistic verification – probability of false alarms and lack of genuine alarms at different margins of similarity (τ)
– τ = x implies that SI observed at each switch in the flow path must lie between SI/x and SI*x
– τ = 1 implies that all switches along the flow path must report the same flow statistics
– τ = 1.045 corresponds to link loss rate of 1%
22
Feb 11th, 2015 NDSS'15
Accuracy (II)
● Probabilistic verification – probability of false alarms and lack of genuine alarms at different margins of similarity (τ)
22
Feb 11th, 2015 NDSS'15
Performance (I)
● End user latency
Only 300µs at 50% for 1K hosts
23
Feb 11th, 2015 NDSS'15
Performance (II)
● Throughput
Just 2% overhead
24
Feb 11th, 2015 NDSS'15
Performance (III)
● Policy verification
Only 869µs for 10K policies
25
Feb 11th, 2015 NDSS'15
Outline
● SDN Overview● Motivation● Sphinx● Implementation● Evaluation● Conclusion
26
Feb 11th, 2015 NDSS'15
Conclusion
● Existing controllers are vulnerable to a wide array of attacks
● Sphinx is a controller agnostic tool that detects security threats originating within SDNs in real time
● Sphinx builds succinct metadata for each network flow and uses both deterministic and probabilistic checks to identify deviant behavior
● Our evaluation shows that Sphinx is practical and imposes minimal overheads
27