SDNs, Clouds and Security Workshop on Science of Security through Software-

Defined Networking Roy H CampbellRead Sprabery

Konstantin Evchenko

Outline

• Motivation• Applications: Corporate Cloud Networks, SCADA• SDN Threat Vectors• Principles for building secure SDN• Examples of implementation• UIUC SDN Research Facilities• Emerging attack vectors• Future research• Conclusion

Motivation for Secure SDNs

• Software Defined Networks become increasingly popular• Ease of management is attractive

• SDNs are currently deployed in many datacenters• Ongoing research of adopting SDNs in cyber-physical infrastructure• Potential deployment in safe-critical systems

• Many modern attacks are launched through the networks• However, centralized control plane might amplify the attacks

Google and SDNs

• Jennifer Rexford: “SDN offers network-wide visibility, network-wide control, and direct control over traffic in the network. That represents a significant departure from the way existing distributed control planes work, which is to force network administrators to coax the network into doing their bidding. Basically, what I think Google and some other companies find attractive about SDN is the ability to affect policy more directly from a single location with one view of the network as a whole.”

Modern Security Problems in Clouds | Meet Treacherous Twelve

1. Data Breaches 2. Weak Identity, Credential and

Access Management 3. Insecure APIs 4. System and Application

Vulnerabilities 5. Account Hijacking 6. Malicious Insiders 7. Advanced Persistent Threats

8. Data Loss 9. Insufficient Due Diligence 10. Abuse and Nefarious Use of Cloud

Services11. Denial of Service 12. Shared Technology IssuesWhich ones can be fixed with SDNs?Which ones are due to SDNs?

SCADA and SDNs

SCADA and SDN – Additional security issues

• How to apply security patches: applications, operating systems• How to install anti-malware on the endpoints: Host Intrusion

Prevention Systems and Firewalls• Legacy SCADA equipment – old operating systems• Use of “proprietary protocols”• No proper and documented configuration management process• Field updates and password convenience• Lifetime of deployed systems• Software vulnerabilities

Verissimo et al on SDN Threat Vectors

1. Forged and faked traffic flows

2. Vulnerabilities in forwarding devices

3. Attacks on the control plane (spoofing)

4. Attacks on the controllers

5. Attacks on the applications

6. Attacks on and vulnerabilities in administrative stations

7. Lack of trusted resources for forensics and remediation

D. Kreutz, “Software Defined Networking: A Comprehensive Survey”, IEEE Proc

SDN Threat Vectors | Consequences for SDNs

1. Open door for DDoS attacks. Fingerprinting: information

disclosure achieved through side channel attacks can be used to

target the flow rule setup process

2. Potential attack inflation.

3. Exploiting logically centralized controllers.

4. Compromised controller may compromise the entire network.

5. Development and deployment of malicious applications on

controllers.

6. Potential attack inflation.

7. Negative impact on fast recovery and fault diagnosis.D. Kreutz, “Software Defined Networking: A Comprehensive

Survey”, IEEE Proc

STRIDE in OpenFlow and Attack Examples

Attack

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Escalation of PrivilegeSecurity Property

Authentication

Integrity

Non-repudiation

Confidentiality

Availability

AuthorizationExamplesMAC and IP address spoofing, forged ARP and IPv6 router advertisement.

Counter falsification, rule installation, modification affecting data plane.

Rule installation, modification for source address forgery.

Side channel attacks to figure out flow rule setup.

Flow requests overload of the controller.Controller take-over exploiting implementation flaws.

D. Kreutz, “Software Defined Networking: A Comprehensive Survey”, IEEE Proc

Example 1 | Data eavesdropping attacks (fraudulent flow entries)

1. An attacker hijacks the application

2. Compromised app issues an illegal policy to

forward the traffic both to Host B and to an

attacker

3. SDN controller installs the policy

4. An attacker is able to receive all the traffic

destined to B

Zhiyuan Hu et el, “A Comprehensive Security Architecture for SDN”. ICIN 2015

Example 2 | Bypassing Mandatory Policy

1. Security Management Server issues the rule for

traffic from host A to B to go through the firewall

2. Later QoS app issues the rule that implements a

better/faster route from A to B, avoiding firewall

3. Since no invariant-preserving mechanism are

employed – security policy will be violated

4. Example of unintentional security violation

Zhiyuan Hu et el, “A Comprehensive Security Architecture for SDN”. ICIN 2015

ONF Eight Principles of Secure SDN

1. Clearly Define Security Dependencies and Trust Boundaries. 2. Assure Robust Identity.3. Build Security based on Open Standards.4. Protect the Information Security Triad (CIA).5. Protect Operational Reference Data. 6. Make Systems Secure by Default. 7. Provide Accountability and Traceability. 8. Properties of Manageable Security Controls.

Addressing the Problems | Approaches

• Building secure controller platforms• Access control, Attack detection, Event filtering

• May be implemented on the controllers, switching devices and middleboxes• Rate limiting, packet dropping, shorter timeouts, flow aggregation

• Controllers, network applications and switching devices• Monitoring and Intrusion Detection Support• Fault tolerance

• Isolating network applications from the platform and from each other (virtual machines, Linux containers)

Addressing the Problems | Approaches (cont.)

• Developing new abstractions to provide integrity/confidentiality• Per-packet, per-flow and inter-flow consistency

• Improving implementation of SDN• Secure connections between controllers and switches

• Employing formal methods to improve integrity• Software verification for controllers/applications• Declarative languages to specify semantic constraints• Verification of network invariants (VeriFlow)

Example | Integrity and Consistency Evolution

• Updates in SDNs are asynchronous in nature• Inconsistencies during updates were addressed earlier

• per-packet consistency• per-flow consistency

• These abstractions do not span across flows• A (our) new approach is required to guarantee interflow consistent

updates

Motivation | Transitional Inconsistency

• Constraints can exist between flows1. Power grid: isolation of critical controls flows from engineering/debug flows2. Network operators: isolation between data flows of different companies3. Data centers: related flows need to be updated at the same times

• Interflow Constraints• Such constraints can be violated during transitional states

• When flow rules need to be updated for entire system• E.g. in response to link failures, attacks, changing requirements, etc.• Original rules meet constraints; updated rules meet constraints

What happens during the update process?

Example 3*

• Consider following scenarioController

H1

H2

I1

I2

Packet Inspector

f1

f2

ORIGINAL Configuration[Handshake Packets]

Controller

H1

H2

I1

I2

Packet Inspector

f2

f1

TARGET Configuration[Application Packets]

[* Ghorbani et al. “Towards Correct Network Virtualization”. Hot SDN2014]

Example 3 [contd.]

• Problem: what if f2 gets updated before f1?Controller

H1

H2

I1

I2

Packet Inspector

f1

f2

TRANSITIONAL Configuration!

f1 and f2 should be updated together not guaranteed by current mechanisms

High-level Approach

Step I: Construct a dependency graph to

model proposed updates

Step II: Revise dependency graph to guarantee interflow

consistency

Step III: Output valid update order for flows

Version Isolation | Solution

• Forward packets (for certain flows) to the controller before updates

Controller

Switch Switch

Switch

Step 1| Forward f1’s packets to the controller

Step 2| Update forwarding rules for f1 and f2

Step 3| Send buffered packetsback into the network

Version Isolation Set• Version Isolation Set: set of flows with version isolation constraints among them• Forward to controller solution:

1. Build a graph where each node is a flow and the edge represents that two flows are in one VI set

2. Find maximum independent set in this graph3. Forward all the flows that are not this set to the controller for caching4. Update all the other flows in the network5. once updates are complete transmit cached packets back into network

• Choice of which flows to forward to controller greedy algorithm based on• Rate of the various flows• Criticality of the flow• Number of the flows in the VI set

VeriFlow | Real Time Network Verification

• Middle layer between control and data plane

• Every rule is intercepted and its potential effects on network-

wide invariants are examined

• Rules are classified into malicious (violating invariants) and

good (non-violating invariants)

• Good rules are accepted and installed on the switches

• Malicious rules are delivered for diagnostics

• This approach combines preserving integrity and providing

information for intrusion detection/forensics

Ahmed Khurshid et al, VeriFlow: Verifying Network-Wide Invariants in Real Time, NSDI’ 13

Security Architecture for SDN

Zhiyuan Hu et el, “A Comprehensive Security Architecture for SDN”. ICIN 2015

FortNOX | Example of Hardening the Controller• Ensures rule integrity• Limits access to the controller• Specifies policy language to ensure network flow constraints are met• Role based authentication using public keys for agents that can

modify rules

FortNOX Motivation |Dynamic Flow Tunneling1. Initially traffic from 10.0.0.2 to

10.0.0.4:80 is blocked by an OF app implementing firewall

2. Another OF app install modifing rules on the switch• If 10.0.0.2 -> 10.0.0.3:80 Set SRC IP

to 10.0.0.1• If 10.0.0.1 -> 10.0.0.3:80 Set DST IP

to 10.0.0.4• If 10.0.0.1 -> 10.0.0.4:80 Forward

3. Now if 10.0.0.2 sends a packet to 10.0.0.3:80, it will be delivered to 10.0.0.4

4. Firewall bypassed!

The application might be malicious or it can be benign as seen in Example 2Philip Porras, Seungwon Shin, Vinod Yegneswaran, Martin

Fong, Mabry Tyson, and Guofei Gu. 2012. A security enforcement kernel for OpenFlow networks. In Proceedings of the first workshop on Hot topics in software defined networks

(HotSDN '12)

FortNOX | Implementation

Philip Porras, Seungwon Shin, Vinod Yegneswaran, Martin Fong, Mabry Tyson, and Guofei Gu. 2012. A security

enforcement kernel for OpenFlow networks. In Proceedings of the first workshop on Hot topics in software defined networks

(HotSDN '12)

ONOS – Distributed Core

• Larger attack surface• Consistency between instances

ONOS White Paper

Problems With Existing Solution

• Generally address only specific problems• Do not cover 8 security principles• Do not consider 7 threat vectors• Possibly big overheads

Future Research Directions

• Distributed Control Plane with Security• Integrity issues

• Authentication and authorization for controllers and switches• How much can be inferred from encrypted open flow messages and

latencies?• Application to controller security – distributed/redundant?• Interdomain traffic issues

Research Facilities at UIUC | Matrix Lab• Mimics two campus networks• Allows to run both proprietary (HP) and open source controllers• 16 server machines allow to generate realistic traffic

Questions?