Upload
vudieu
View
222
Download
2
Embed Size (px)
Citation preview
IntroductionApproach
ResultsRecommendations
Conclusion
OpenFlow: A Security Analysis
Rowan Kloti1 Vasileios Kotronis2 Paul Smith3
[email protected] Zurich
[email protected] Zurich
[email protected] Austrian Institute of Technology GmbH
07.10.2013ICNP NPSec 2013, Gottingen, Germany
1 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Outline
1 IntroductionObjectivesSDN and OpenFlow
2 ApproachAttack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
3 ResultsSecurity AnalysisEmpirical Testing
4 Recommendations
5 Conclusion2 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
ObjectivesSDN and OpenFlow
Objectives
Security analysis of OpenFlow protocol and networks
Focus on v1.0.0, but extensible/adaptable methodologyDevelop modelAnalyze modelDescribe attacks
Empirically demonstrate one or more security issues
Develop setup to enable this empirical demonstration
Suggest potential fixes and mitigations for security issues
3 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
ObjectivesSDN and OpenFlow
Why OpenFlow Security Analysis?
OpenFlow started as a largely academic endeavour
But has recently seen increasing deployment in productionsystems:
Google’s OpenFlow WANCisco, Juniper, HP productsAdoption by cloud hosts and service providers
But why security?
No official security analysis of the protocol itselfResearch is just catching up (see HotSDN 2013 program)Security is extremely important for production systems, butcan be overlooked
4 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
ObjectivesSDN and OpenFlow
SDN and OpenFlow 101
Software Defined Networks (SDNs)separate data plane and control plane
OpenFlow implements SDN:
Switch implements data planeController implements control planeSwitch and controller connected withsecure channel over control networkController installs flow rules onswitchFlow rule header fields match packetheadersPackets matching a flow rule haveactions performed on them
Header
Fields
Counters
Actions
OpenFlow Switch Specification
Version 1.0.0 ( Wire Protocol 0x01 )
December 31, 2009
1 Introduction
This document describes the requirements of an OpenFlow Switch. We rec-ommend that you read the latest version of the OpenFlow whitepaper beforereading this specification. The whitepaper is available on the OpenFlow Con-sortium website (http://OpenFlowSwitch.org). This specification covers thecomponents and the basic functions of the switch, and the OpenFlow protocolto manage an OpenFlow switch from a remote controller.
Version 1.0 of this document will be the first for which official vendor supportis expected. Versions before 1.0 will be marked “Draft”, and will include theheader: “Do not build a switch from this specification!” We hope to generatefeedback prior to Version 1.0 from switch designers and network researchers, sothat the set of features defined in Version 1.0 enables production deploymentson a variety of vendor hardware.
Figure 1: An OpenFlow switch communicates with a controller over a secureconnection using the OpenFlow protocol.
1
5 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
Attack Model
Three scenarios
Attacker controls a single clientAttacker controls multiple clientsAttacker has access to control network
The first scenario is given greatest consideration
Scenarios where attacker has access to actual secure channelare not considered
This would involve compromising SSL or TLS, which is outsidethe scope of this work
6 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
STRIDE
Security modeling methodology
Types of vulnerabilities modeledby the method[3]:
SpoofingTamperingRepudiationInformation DisclosureDenial of Service andElevation of Privilege
Use data flow diagrams touncover potential vulnerabilities
Models how external dataenters into and propagatesthrough system
Client
Web application
Database
Request Reply
Query Results
Figure : Data flow diagram
7 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
Attack Trees
Used to describe and analyzeattacks
Based on fault tree analysis[4]
Represent prerequisites forattacks
Leaf nodes represent actionsor eventsThese propagate throughAND and OR gatesRoot node is objectiveCan calculate various metricsif values for leaf nodes areknown
Get root access
Dictionary attack
Social engineering
Exploit vulnerability
Develop exploit
Find vulnerability
Execute attack
Figure : Attack tree
8 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
From STRIDE DFDs to Attack Trees
Data flow diagrams show us potential vulnerabilities
They show us which components present an attack surface
Attack trees allow these to be developed into practical attacks
A given objective may have multiple attack pathsAttack trees help to analyze and optimise attack paths
These two approaches are complementary
9 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
Experimental Setup
Mininet is a virtual network emulation environment
Based on Linux network namespacesRuns Open vSwitch (virtual OpenFlow switch)
Can emulate performance constraints
BandwidthLatency and jitterThis is required to simulate attacks
Forms the basis of test environment
Use POX as a controller
10 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Attack ModelSTRIDEAttack TreesCombining the ApproachesExperimental Setup
Setup Schematics
h1h1 h2h2
c0c0
s1s1
Figure : Network topology forDenial of Service attackdemonstration
h1-1h1-1 h2-1h2-1
c0c0
s1s1 s2s2
h1-3h1-3 h2-3h2-3
h1-2h1-2h1-2h1-2 h2-2h2-2
Figure : Network topology forInformation Disclosure attackdemonstration
11 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Denial of Service I
Asynchronous message
Input buffer 1
Secure ChannelData path
Packet to process
Read flow table
Update counter
Set state/actionPacket sample
Read flow table
Interface 1
Received packet
Interface 2
Transmitted packet
Output buffer 2
Forwarded/Enqueued packet
Output buffer 1
Forwarded/Enqueued packet
Transmitted packet
Remove/modify packet
Input buffer 2
Received packet
Packet to process
OpenFlow Module
Transmit packet
Modify flow table
Get state/event
Received packet from 1
Sent packet to 1
Sent packet to 2
Received packet from 2
Controller-to-switch message
Remove/modify packet
Denial of ServiceInformation Disclosure
Tampering
Flow table
Figure : Data flow diagram of switch
12 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Denial of Service II
Secure Channel
Read flow table
Update counter
Set state/action
Packet sample
Read
OpenFlow Module
Transmit packet
Modify
Get state/event
Denial of ServiceInformation Disclosure
Tampering
Flow table
Data path
Figure : Close-up of data flow diagram
13 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Denial of Service III
Denial of service
Against switch Against controller
Against Flow table
Against OpenFlow Interface and data flow Asynchronous
message
Against OpenFlow Module
Generate very high traffic load
on interface
Exploit security hole in controller (if
present)Against Input buffer
Attack controller OpenFlow Interface
directly
Perform regular denial of
service attack against
controller
Attack OpenFlow Interface and Asynchronous
message
Generate very high rate of new flows on
several interfaces
Generate very high traffic load
on each interface
Generate extremely high traffic load on
interface
Obtain access to multiple
client interfaces
Obtain access to multiple
client interfaces
Obtain access to management
network
Locate security hole in
controller software
Develop exploitPerform processor
intensive tasks on several
connections
Identify which flow rules are
created without wildcards
Identify which flow rules are
created without wildcards
Identify which flow rules are
created without wildcards
Against Decision process
Identify exact form of flow table entries
Identify hash function used for flow table
Cause hash collisions on
flow table
Figure : Denial of Service attack tree with attack path highlighted
14 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Denial of Service IV
Denial of service
Against switch
Against Flow table
Generate very high traffic
load on interface
Identify which flow rules are
created without
wildcards
Figure : Close-up of highlighted attack path
15 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure I
Asynchronous message
Controller-to-switch message
OpenFlow Interface
Policy
Administration interface
Write policyRead policy
Administrator
Get value
Decision
Get state/event
Set state/action Get policy
Log
Write log
Read log
Write log
Set configuration
Get configuration
Set value
Denial of ServiceInformation Disclosure
Tampering
Figure : Data flow diagram of controller
16 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure II
Asynchronous message
Controller-to-switch message
OpenFlow Interface
Decision
Get state/event
Set state/action
Denial of ServiceInformation Disclosure
Tampering
Switch
Figure : Close-up of data flow diagram
17 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure III
Information disclosure
Against switch Against controller
Disclose existing flows with side channel attack
Disclose whether a new flow rule is
created
Send packets between clients,
measure time
Disclose existing flow actions with
side channel attack
Obtain hardware, measure
reaction times
Send many packets
between clients,
measure time
Send packet between clients,
measure time
Repeat procedure
second time, measure time difference
Obtain access to multiple
client interfaces
Obtain access to multiple
client interfaces
Force another client to reflect
traffic or produce response
Force another client to reflect
traffic or produce response
Obtain access to multiple
client interfaces
Force another client to reflect
traffic or produce response
Wait for flow rule timeout,
repeat procedure for
statistical certainty
Select packet contents based on policy query
type
Select packet contents based
on flow rule query type
Against data flow Packet sample
Against data flow Asynchronous
message
Figure : Information Disclosure attack tree with attack path highlighted
18 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure IV
Information disclosure
Against controller
Disclose existing flows with side channel attack
Send packets, measure
time
Obtain access to multiple
client interfaces
Force another client to produce response
Select packet contents
Against data flow Asynchronous
message
Figure : Close-up of highlighted attack path
19 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Denial of Service
10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85
0
10000
20000
30000
40000
50000
60000
Soft timeout [s]
Pac
kets
lost
Figure : Number of lost packets vs rule timeout value due to flow tableoverflow (with control link at 100 Mbps and 1ms latency)
20 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure I
0
2
4
6
8
10
12
14
16
18
20
50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200
Fre
qu
en
cy
Measured response time [ms]
Single flow (initial)
Two flows (new+initial),distinct
Figure : Distribution of measured times with exact matching flow rules
21 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Security AnalysisEmpirical Testing
Information Disclosure II
50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200
0
2
4
6
8
10
12
14
16
18
20
Measured response time [ms]
Fre
qu
en
cy
Single flow (initial)
Two flows (new+initial),aggregated
Figure : Distribution of times with source address and port as wildcards
22 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Denial of Service
Rate Limiting, Event Filtering, Packet Dropping, RuleTimeout Adjustment
Some of them introduced in newer OpenFlow standardsExample of usage: large timeouts lighten load on controllerbut can cause table overflows
Flow Aggregation
Try to reduce load on controller with proactive strategies
Attack Detection
Employ OpenFlow for logically centralized detectionDirect flows to specialized monitoring systems
Access Control - Distributed Firewall
ACLs implemented as sets of flow rules on the switch
23 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Information Disclosure
Proactive Strategies
Remove response time-state dependency
Randomization
Increase variance of measurable response timesClever rule timeout randomization
Direct Attack Detection-Mitigation
Exploit bird’s eye view over traffic to detect suspicious patternsEnact counter-measures using direct flow control
24 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Conclusion
Found potentially problematic issues in OpenFlow, including:
Denial of service (i.e. resource depletion)Information disclosure (i.e. timing analysis)
Newer specifications reflect some of these issues
Metering, multiple controllers with fail-over, parallelismBut further work is required!
Demonstrated two different forms of attack
Developed test setup (could be used for unit tests)
Contributions
Extensible and adaptable methodologyTowards SDN architectures that are more secure by design
25 / 36
IntroductionApproach
ResultsRecommendations
Conclusion
Discussion
Thank you very much for your attention!
Questions?
26 / 36
Approach (supplemental material)Results (supplemental material)
References
Other Approaches
Attack nets (from Petri nets)[5]
More versatile than DFDs, but also harder to analyseThis level of formalism is not neededLess suited to fully asynchronous systemDifficult to model system with discrete, fully enumerated states
State-based system models[1, 2]
These systems tend to model control flow rather than data flowOpenFlow specification does not require any particular controlflowMight be useful with a given controller
27 / 36
Approach (supplemental material)Results (supplemental material)
References
Denial of Service V
Identify which flow rules are created with or without
wildcards
Determine from timing analysis
Obtain access to multiple
client interfaces
Force another client to reflect
traffic or produce response
Compromise controller
Social engineering or educated guess
Send packet between clients,
measure time
Repeat procedure
second time, measure time difference
For each header column, select
two neighboring
values
Wait for flow rule timeout,
repeat procedure for
statistical certainty
Ensure that adjacent client addresses are
available, if address is to be
probed
Secure multiple source addresses, if
needed.
Send falsified ARP or LLDP or routing packets
to redirect traffic
Obtain access to multiple
client interfaces
Use forged source addresses
Figure : Denial of service attack tree with attack path highlighted
28 / 36
Approach (supplemental material)Results (supplemental material)
References
Denial of Service VI
Identify which flow rules are created with or without wildcards
Social engineering or educated guess
Figure : Close-up on highlighted attack path
29 / 36
Approach (supplemental material)Results (supplemental material)
References
Information Disclosure V
Force another client to reflect traffic or produce response
UDP based trafficICMP based traffic TCP based traffic
ICMP echo request/echo
response (ping)
DNS request NTP RIP HTTP request
NetBIOS (Windows) or network file
system
SSH or telnet
NB: This attack tree should not be considered exhaustive.
Figure : Information disclosure attack tree with attack path highlighted
30 / 36
Approach (supplemental material)Results (supplemental material)
References
Information Disclosure VI
Force another client to reflect traffic or produce
response
TCP based traffic
HTTP request
Figure : Close-up on highlighted attack path
31 / 36
Approach (supplemental material)Results (supplemental material)
References
Denial of Service (Empirical) II
10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85
0
10000
20000
30000
40000
50000
60000
Soft timeout [s]
Pac
kets
lost
Figure : Number of lost packets vs timeout value due to flow tableoverflow (with control link at 10 Mbps and 10ms latency)
32 / 36
Approach (supplemental material)Results (supplemental material)
References
Information Disclosure (Empirical) III
40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120
0
1
2
3
4
5
6
7
8
9
10
Measured response time [ms]
Freq
uen
cy
Without aggregation
With aggregation
Figure : Distribution of times with source address and port as wildcardsand asymmetrical delay (delay in control network shorter than in datanetwork)
33 / 36
Approach (supplemental material)Results (supplemental material)
References
References I
O. El Ariss, Jianfei Wu, and Dianxiang Xu.Towards an Enhanced Design Level Security: IntegratingAttack Trees with Statecharts.In Secure Software Integration and Reliability Improvement(SSIRI), 2011 Fifth International Conference on, pages 1–10,june 2011.doi:10.1109/SSIRI.2011.11.
Omar El Ariss and Dianxiang Xu.Modeling security attacks with statecharts.In Proceedings of the joint ACM SIGSOFT conference – QoSAand ACM SIGSOFT symposium – ISARCS on Quality ofsoftware architectures – QoSA and architecting critical systems
34 / 36
Approach (supplemental material)Results (supplemental material)
References
References II
– ISARCS, QoSA-ISARCS ’11, pages 123–132, New York, NY,USA, 2011. ACM.URL: http://doi.acm.org/10.1145/2000259.2000281,doi:10.1145/2000259.2000281.
Shawn Hernan, Scott Lambert, Tomasz Ostwald, and AdamShostack.Uncover Security Design Flaws Using The STRIDE Approach,2006.URL: http://msdn.microsoft.com/en-gb/magazine/cc163519.aspx.
35 / 36
Approach (supplemental material)Results (supplemental material)
References
References III
Wikipedia.Fault tree analysis.http://en.wikipedia.org/wiki/Fault_tree_analysis.Accessed on 02.04.2013.
Ruoyu Wu, Weiguo Li, and He Huang.An Attack Modeling Based on Hierarchical Colored Petri Nets.In Computer and Electrical Engineering, 2008. ICCEE 2008.International Conference on, pages 918–921, dec. 2008.doi:10.1109/ICCEE.2008.69.
36 / 36