SPHINX:
Detecting Security Attacks in SoftwareDefined Networks
• Intro- SDN recap and security issues
• Sphinx: Description of Sphinx
• Criticism
Presentation Outline
• SDN evolved out of a need to solve Network
Maintenance issues
• SDN still in its infancy
• SDN enables central control for all servers via separation
of control path and data path
• SDN allows programmable configuration
• SDN allows vendor independence
• SDN solves management issues but also creates a lot of
security issues
SDN Recap:
PC Model (OS)
SDN Model (NOS)
SDN: OpenFlow Protocol
• Single Point of Failure-Controller
• Easy sniffer attacks enabled
• Gives hackers one juicy target-Why target a single host
when you can take over the whole-network?
SDN Security issues:
SDN: Virtual Network
• Article identifies 4 security issues
• no built in security(even with TLS enabled) that prevents
packet spoofing
• Attacks that affect legacy networks also afflict SDNs but
most solutions that work for legacy networks not
applicable to SDN
• Use of OVSes running atop end host servers make an
attractive target for attackers
• End hosts can do control plane flooding and crash the
whole network
Sphinx: Intro
• SPHINX detects both known and potentially unknown
attacks on network topology and data plane forwarding
within an SDN
• Sphinx dynamically learns new network behavior and
raises alerts when it detects changes to existing network
control plane behavior
• SPHINX detects attacks in real-time with low
performance overheads and requires no changes to
controllers for deployment
Sphinx: What it offers
• SPHINX gleans topological and forwarding state
metadata from OpenFlow control messages to build
incremental flow graphs
• Verifies all SDN state in real-time, including detection of
security attacks on topology and data plane forwarding or
violations in administrative policies.
• Any unusual behavior is flagged and reported.
SPHINX Key Idea
SPHINX
SPHINX Flowchart
• Examine 4 popular SDN controllers and demonstrate that they
are vulnerable to a diverse array of attacks on network
topology and data plane forwarding
• Present incremental flow graphs as a novel abstraction for realtime detection of security threats.
• Present the design and implementation of SPHINX and its
policy engine, which allows network administrators to specify
fine-grained security policies, and enables easy action
attribution.
• Evaluate SPHINX to show that it is practical and involves
acceptable overheads. Also report on experiences gained using
SPHINX in four different case studies.
Sphinx: Evaluation
SPHINX controllers
Incremental Flow Graphs
SPHINX provides a light-weight policy framework that enables
administrators to specify validation checks on incremental flow graphs.
SPHINX validates all flow graphs against a set of constraints.
i) any administrator-specified security policies,
(ii) those acquired over time for a specific flow.(Probabilistic)
These administrator-specified constraints must be expressed in a policy
language
SPHINX Policy Engine
Using experimental setup:
physical testbed making a mini network, test Accuracy Performance, Case studies.
AccuracyHow quickly it can detect attacks
-The effectiveness of the byte consistency algorithm
-False alarms generated under benign conditions
Performance-measure user perceived latencies
-variation in packet throughputs for FLOW_Mod and PACKET_IN processing
-Overhead of Policy Verification
Case Studies-Network Virtualization
-VM Migration
-Load balancer
-Multicast
Experiment
Results:
• SPHINX leverages flow graphs to detect security threats on
network topology and data plane forwarding
• This article shows that existing controllers are vulnerable to
these attacks
• SPHINX has been shown to be able to detect threats in realtime
• Flow graphs are incrementally updated and built up with
metadata from each network flow
• SPHINX uses both deterministic and probablistic methods to
identify possible threats
• Evaluation from experiment shows SPHINX imposes minimal
overheads
SUMMARY/ CONCLUSION
• Limits protection to network topology and data plane attacks
• Only operates on the threats and violations coming from within
the SDN
• Assumes the controller is to be trusted- Does not work if
controller compromised
• Only works with Openflow protocol- non-openflow protocols
not considered
• Relies on domain knowledge: assumes SDNs to not be a black
box to leverage access domain knowledge so it can detect
changes in patterns of control messages.
CRITICISM
• SPHINX cannot detect compromise in packet integrity
• SPHINX cannot identify a malicious ingress or egress
switch in a flow path that adds/drops packets to influence
the similarity index.
• The accuracy of results described limited by the lack of
realistic networks available for large scale
experimentation
CRITICISM