Network Security through Software Defined Networking: a Survey

(1)

Network Security through Software

Defined Networking: a Survey

(2)

Introduction Firewall Monitoring Advanced Security Tasks Conclusion

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(3)

Introduction Firewall Monitoring Advanced Security Tasks Conclusion SDN OpenFlow Security

Outline

1 Introduction

SDN

OpenFlow

Security

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(4)

SDN OpenFlow Security

Usual routing

I

Routing algorithms are distributed

I

Every switch

(5)

Decoupling the planes

I

2 planes

I

Control plane (routing decisions)

I

Data plane (forward the traffic)

I

→ 2 main types of entities

I

keep

switches

as forwarders only

I

introduce a dedicated

controller

to take decisions

(6)

Application aware networking

I

How is configured the controller ?

I

manually

I

from applications / systems through monitoring or

interactions

I

network information (topology, link usage) can be

(7)

Network programmability

I

Motivations

I

Empower research and innovation

= easy testing of new

methods/protocols

I

Need for more traffic engineering /

performance

in

networking in particular by controlling data delivering paths

→ limited flexibility of standard routing approaches

I

network size and speed increases

→ powerful (and costly)

forwarding devices vs. “cheap” commodity computers

I

natural decomposition planes: control planes has been

software based for a long time

I

→

OpenFlow

I

supported by many actors (research, equipment vendors,

(8)

Outline

1 Introduction

SDN

OpenFlow

Security

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(9)

Specification

I

A protocol: Communication

switch - controller

I

+ switch specification

I

Rules to handle packets in a

flow table

I

a set of matching fields in headers (IP/MAC addresses,

ports, VLAN id, etc.)

I

a priority to choose the rule is several can be matched

I

a timeout

I

counters about the flow

(10)

Flow table example

App Ingress port Mac Src Addr Mac Dst Addr Ip Src Ad-dress Ip Dst Ad-dress Protocol Src port Dst port Instructions

Switching * * AB:CD:EF:00:11:22* * * * * Forward to port 3 Routing * * * * 1.2.3.* * * * Set Mac src

addr=AB:CD:EF:00:11:33, Mac dst addr = AB:CD:EF:00:11:44, forward to port 5 Firewall 1 * * * 1.2.3.* TCP * 22 Drop Proxy * * * * 2.3.4.5 TCP * 80 Set IP addr=10.11.12.13, forward to port 5 Load balancing1 * * * 2.3.4.5 TCP * 80 set dst addr =

2.3.4.6, Forward to port 4

(11)

Rule installation

I

2 modes

I

Proactive

: rules are installed beforehand

I coarse grained rule (aggregated)

I large flow tables

I lower latency

I → good for general rule like routing or switching

I

Reactive

: rules are installed when the first packet of a flow

arrives (table-miss) → the controller gets a copy

(packet in)

I higher latency

I small flow tables

I specific rule (fine-grained)

(12)

Outline

1 Introduction

SDN

OpenFlow

Security

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(13)

What about security

I

2 main questions

I

May SDN/OpenFlow enable or improve security?

I what are the potential applications ?

I may we create new security processes?

I what are the benefits?

I what are the drawbacks?

I

How secure is SDN/OpenFlow ?

I Can be network programmability misused?

(14)

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(15)

Stateless firewall

I

We already have seen an example

I

Easy to implement

I

static policies

(16)

Existing proposals

I

Building firewall over the software-defined network

controller, Suh et al., ICACT 2014

I

command line based tool using POX

I

Floodlight

I

OpenFlow controller + applications

I

REST and Java API

I

http://docs.projectfloodlight.org

I

include a firewall application which is configured through a

REST API

(17)

Stateful firewall 1/3

I

Keep track of the connections (history)

I

More powerful

I

in particular for connection oriented protocols to only allow

traffic when the session is established from inside

(18)

Stateful firewall 2/3

I

What happens when the timeout expires before the

session ends ?

I

need to reinstall the rule → possible with ACK-like

mechanisms

I

→ not really stateful

I

only few packets are analyzed (flow-based) → save

(19)

Stateful firewall 3/3

I Keep track of the exact statusof the connection: need for packet inspection

I → can be done at the controller side

match (dst_ip=Y,src_ip=X) -> action=CONTROLLER

I Problems

I a lot ofoverhead: each packet is forwarded to the controller and then analyzed

I → not feasible in practice (latency !!!)

I Hybrid approach → redirect packets which needs stateful packet inspection to a specific middlebox/firewall → very similar to the current situation

I Add support for matching TCP flags

I possible with OpenFlow v1.2+

(20)

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(21)

Security Monitoring

I

Firewall / Access control is important but cannot

prevent everything

I

→ need for monitoring, IDS, IPS to detect

misbehaviors

I

How to monitor misbehaviors from the network

?

I connections to multiple suspects IP addresses / domains using blacklists

I creating multiple connections, traffic volume change (flood/scan/spam)

I network traffic compared to a profile (day/light, user or application patterns...)

I observations of similar connections between multiple hosts (botnet, worm propagation...)

(22)

Main building blocks

I

Years of research in security monitoring

I

But network monitoring for security purposes rely on

common building blocks

I

services/hosts accessed and communicating together

I

traffic statistics (number of bytes, packets,...)

I

timing information to have an historic (timestamp)

I

Retrieve such information with OpenFlow

(23)

Flow table counters

(24)

Getting flow information

I

Counters →

get statistics about flows

I

when a flow is considered inactive: FlowRemoved message

I

on demand: FlowStatisticsRequest message (#bytes,

#pkts, duration,...)

I

when a flow start: PacketIn message → active flows

I

Different kind of monitoring: passive vs. active, push

(25)

Passive Monitoring

I

no additional traffic to inject into the network

I

only able to observe statistics about current usage

(26)

FlowSense

I

FlowSense: monitoring network utilization with zero

measurement cost, Yu et al., PAM’13

I

zero cost = push mode → no intermediate statistics

request

I

monitor link usage

I sum all link usages

I issues

(27)

OpenTM

I OpenTM: traffic matrix estimator for OpenFlow networks, Tootoonchian et al., PAM’10

I Volume of traffic between each OD (origin-destination) pair

I Periodic polling → fine grained and tunable update the matrix

I Switch selection (multiple switches on the path)

I most accurate = last swictch before reaching the destination

I _{other strategies: random uniform, higher probability for closer switches,}

(28)

PayLess

I PayLess: A Low Cost Network Monitoring Framework for Software Defined Networks, Chowdhury et al., IM’14

I Propose a REST API to define high level monitoring request (per user, per application, type of statistics...)

I Optimization of polling requests

I adaptive monitoring (periodic requests): flexible interval increase high variation in the last update, decrease otherwise

(29)

Active Monitoring

I

inject packets in the network

I

infer other information, even from non used links

I

low overhead compared to traditional approaches

based on ICMP

src: Monitoring latency with OpenFlow, Phemius et

(30)

OpenNetMon

I

OpenNetMon: Network Monitoring in OpenFlow

Software-Defined Networks, Van Adrichemet al.,

IM’14

I

active + passive

I

comparison of first and last switch →packet loss

I

active → latency measurement (need to take in account

delays between the controller and switches)

I Control plane: PacketOut + PacketIn

(31)

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(32)

Packet based analysis

I

Some packets need to be

collected individually

I

Redirect

every packet matching some patterns to the controller

(PacketIn) → overhead

I

→

select packets to redirect

I checking TCP flags is useful for scan/worm detection → only monitor SYN, SYNACK RST...

I Revisiting Traffic Anomaly Detection Using Software Defined Networking, Mehdi et al., RAID’11

I successful vs unsuccessful connection initiation

I _{only monitor first packets (SYN, SYNACK, RST)} I normal flows (successful connections) → install a rule for

(33)

Detailed analysis

I

require accessing upper layer and maybe payload of

packet

I

→

deep packet inspection

I

How to?

I

Redirect every packet matching some patterns to the

controller (PacketIn)

I Example: filter TCP port 25 to analyze email

I Same as before but no guarantee that decision can be made on first packets only → high overhead

I

Redirect/Copy traffic towards dedicated security

middleboxes

I

Let SDN Be Your Eyes: Secure Forensics in Data Center

(34)

MiddleBox interception

I Traffic is forwarded when it is confirmed as safe

(35)

MiddleBox mirroring

I Traffic is duplicated to the middlebox but not blocked

I → less latency but higher risk

(36)

Other approaches

I Load Balancing of Security MiddleBoxes

I Middleboxes can modify packets headers → difficult to track flows

I example: NAT traversal, proxies...

I add tags to track flowsfrom end to end (FlowTags: enforcing network-wide policies in the presence of dynamic middlebox actions, Fayazbakhsh et al., HotSDN’13

I Moving target defense

I OpenFlow Random Host Mutation: Transparent Moving Target Defense Using Software Defined Networking, Jafarian et al., HotSDN’12

I Objective: change IP addresses frequently such that attackers cannot gather knowledge about hosts

(37)

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

(38)

Some limitations and opportunities 1/3

I Stateful firewall → need for additional support in both swicthes and controllers... while most of them are not fully compliant

I Validation

I usual problem in our domain (having a dataset with labeled attacks)

I more complex with OpenFlow as it needs network traffic, topology and OF messages or rules

I → so much information that very few operators may have

I → hard to define what would be the rule on a production network

I Validation is based on (most of the time):

I simple topology: small tree or linear topology

I _{generation of traffic using iperf} I introduction of artificial delays

(39)

Some limitations and opportunities 2/3

I

Monitoring

I main goal is to gather statistics about the tuple (IP src, IP dst, protocol, src port, src dst)

I fine grained and similar to flow based approaches like Netflow

I impossible to predict the tuples → impossible to install rules beforehand

I → install rules on fly → impracticable in large networks due to latency

I _{→ scalability is an issue... but not only for security applications} I Are we going in the right direction ?

I OpenFlow was aiming at keeping switches as specialized forwarding devices (not monitoring devices...)

I why achieving monitoring as we did for many years ?

I is SDN / OpenFlow open new ways to monitor the networks ?

I looking at OF communications and installation rules might be beneficial

(40)

Some limitations and opportunities 3/3

I

Advanced tasks

I SDN is only limited to forward traffic to dedicated boxes

I but it brings ahigh flexibilityto create and test new approach to allocate dynamically traffic inspection tasks

I

SDN can be well coupled with NFV (Network

Function Virtualization)

I NFV: allow to instantiate network function into a virtualized appliance (no need for dedicated hardware)

I example: a firewall can be created on fly in the cloud...

I ...but the network has to be (re)configured accordingly

(41)