network security through software defined networking: a ......network security through software de...

Network Security through SoftwareDefined Networking: a Survey

Jerome Francois, Lautaro Dolberg,Olivier Festor, Thomas Engel

[email protected] 09/30/14

Introduction Firewall Monitoring Advanced Security Tasks Conclusion

Outline

1 Introduction

2 Firewall

3 Monitoring

4 Advanced Security Tasks

5 Conclusion

2

Introduction Firewall Monitoring Advanced Security Tasks ConclusionSDN OpenFlow Security

Outline1 Introduction

SDNOpenFlowSecurity

2 Firewall

3 Monitoring


5 Conclusion

3


Usual routingI Routing algorithms are distributedI Every switch

I runs a program to fill out routing tablesI look at its routing table to forward packets

4


Decoupling the planesI 2 planes

I Control plane (routing decisions)I Data plane (forward the traffic)

I → 2 main types of entitiesI keep switches as forwarders onlyI introduce a dedicated controller to take decisions

I → requires communication between these entities

5


Application aware networkingI How is configured the controller ?

I manuallyI from applications / systems through monitoring or

interactions

I network information (topology, link usage) can bemonitored as well → bidirectional links

6


Network programmabilityI Motivations

I Empower research and innovation = easy testing of newmethods/protocols

I Need for more traffic engineering / performance innetworking 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 beensoftware based for a long time

I → OpenFlowI supported by many actors (research, equipment vendors,

operators, chipset designers)I incremental deployment

7



SDNOpenFlowSecurity

2 Firewall

3 Monitoring


5 Conclusion

8


Specification

I A protocol: Communication switch - controller

I + switch specificationI 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 matchedI a timeoutI counters about the flowI instructions to execute (forward, drop, change some values)

9


Flow table example

App Ingressport

MacSrcAddr

MacDstAddr

Ip SrcAd-dress

Ip DstAd-dress

Protocol Srcport

Dstport

Instructions

Switching * * AB:CD:EF:00:11:22* * * * * Forward to port 3Routing * * * * 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 DropProxy * * * * 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 toport 4

2 * * * 2.3.4.5 TCP * 80 set dst addr =2.3.4.7, Forward toport 6

10


Rule installation

I 2 modesI Proactive: rules are installed beforehand

I coarse grained rule (aggregated)I large flow tablesI lower latencyI → good for general rule like routing or switching

I Reactive: rules are installed when the first packet of a flowarrives (table-miss) → the controller gets a copy(packet in)

I higher latencyI small flow tablesI specific rule (fine-grained)I → more specific applications like load balancing or firewall

11



SDNOpenFlowSecurity

2 Firewall

3 Monitoring


5 Conclusion

12


What about security

I 2 main questionsI 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?I is there existing approach to guarantee the proper functioning

of a SDN enabled network and its applications?

13


Outline

1 Introduction

2 Firewall

3 Monitoring


5 Conclusion

14


Stateless firewallI We already have seen an exampleI Easy to implement

I static policiesI install corresponding rule in a proactive or reactive way

15


Existing proposals

I Building firewall over the software-defined networkcontroller, Suh et al., ICACT 2014

I command line based tool using POX

I FloodlightI OpenFlow controller + applicationsI REST and Java APII http://docs.projectfloodlight.orgI include a firewall application which is configured through a

REST API

ALLOW rule for all flows between 10.0.0.3 and 10.0.0.7. Not specifying action implies ALLOW rule.

curl -X POST -d ’{"src-ip": "10.0.0.3/32", "dst-ip": "10.0.0.7/32"}’ http://...firewall/rules/json

curl -X POST -d ’{"src-ip": "10.0.0.7/32", "dst-ip": "10.0.0.3/32"}’ http://.../wm/firewall/rules/json

16

http://docs.projectfloodlight.org


Stateful firewall 1/3

I Keep track of the connections (history)I More powerful

I in particular for connection oriented protocols to only allowtraffic when the session is established from inside

I → accept reverse traffic with a timeout

17


Stateful firewall 2/3

I What happens when the timeout expires before thesession ends ?

I need to reinstall the rule → possible with ACK-likemechanisms

I → not really stateful

I only few packets are analyzed (flow-based) → saveresources

18


Stateful firewall 3/3I Keep track of the exact status of the connection: need for packet inspectionI → can be done at the controller side

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

I ProblemsI a lot of overhead: each packet is forwarded to the controller and then

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

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

I Add support for matching TCP flagsI possible with OpenFlow v1.2+I controller add a rule to match the last packet(s) (like FIN in TCP) in

order to get a copy of this packet and remove the forwarding rule

19


Outline

1 Introduction

2 Firewall

3 Monitoring


5 Conclusion

20


Security MonitoringI Firewall / Access control is important but cannot

prevent everythingI → need for monitoring, IDS, IPS to detect

misbehaviorsI How to monitor misbehaviors from the network ?

I connections to multiple suspects IP addresses / domains usingblacklists

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

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

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

I many attempts to connect to closed ports (scan)I observing QoS degradationI etc.

21


Main building blocks

I Years of research in security monitoringI But network monitoring for security purposes rely on

common building blocksI services/hosts accessed and communicating togetherI traffic statistics (number of bytes, packets,...)I timing information to have an historic (timestamp)

I Retrieve such information with OpenFlowI flows are characterized by headers (IP address, ports)I flows are associated to counters

22


Flow table countersI src: OF spec v1.4.0

23


Getting flow information

I Counters → get statistics about flowsI when a flow is considered inactive: FlowRemoved messageI on demand: FlowStatisticsRequest message (#bytes,

#pkts, duration,...)I when a flow start: PacketIn message → active flows

I Different kind of monitoring: passive vs. active, pushvs. pull

24


Passive MonitoringI no additional traffic to inject into the networkI only able to observe statistics about current usage

(for example, unable to infer which links are up, thebandwidth, etc.)

25


FlowSenseI FlowSense: monitoring network utilization with zero

measurement cost, Yu et al., PAM’13I zero cost = push mode → no intermediate statistics

requestI monitor link usage

I sum all link usages

I issuesI long flow, maybe never ending due to

keep alive messagesI large granularity, i.e. flow patterns

may not be regular26


OpenTMI OpenTM: traffic matrix estimator for OpenFlow networks, Tootoonchian et

al., PAM’10I Volume of traffic between each OD (origin-destination) pairI 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 destinationI other strategies: random uniform, higher probability for closer switches,

round-robin, least load

I multipaths → the control is aware of it and can sum over these paths

27


PayLessI PayLess: A Low Cost Network Monitoring Framework for Software Defined

Networks, Chowdhury et al., IM’14I 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 intervalincrease high variation in the last update, decrease otherwise

I batching multiple requests together

28


Active Monitoring

I inject packets in the network

I infer other information, even from non used links

I low overhead compared to traditional approachesbased on ICMP

src:Monitoring latency with OpenFlow, Phemius et

al., CNSM’13

29


OpenNetMonI OpenNetMon: Network Monitoring in OpenFlow

Software-Defined Networks, Van Adrichemet al.,IM’14

I active + passiveI comparison of first and last switch →packet lossI active → latency measurement (need to take in account

delays between the controller and switches)

I Control plane: PacketOut +PacketIn

I Data plane: install a dedicated

VLAN beforehandI avoid scheduling in

switchesI perform better accuracy

30


Outline

1 Introduction

2 Firewall

3 Monitoring


5 Conclusion

31


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 redirectI 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’11I successful vs unsuccessful connection initiationI only monitor first packets (SYN, SYNACK, RST)I normal flows (successful connections) → install a rule for

consecutive packetsI suspect flows → short flows + few packet

32


Detailed analysisI require accessing upper layer and maybe payload of

packet

I → deep packet inspectionI How to?

I Redirect every packet matching some patterns to thecontroller (PacketIn)

I Example: filter TCP port 25 to analyze emailI Same as before but no guarantee that decision can be made

on first packets only → high overhead

I Redirect/Copy traffic towards dedicated securitymiddleboxes

I Let SDN Be Your Eyes: Secure Forensics in Data CenterNetworks, Bates et al., SENT’14

33


MiddleBox interceptionI Traffic is forwarded when it is confirmed as safe

I many ways to do: MiddleBox could use PacketOut (through an interface),tagging as safe may just be based on addresses (everything coming from themiddlebox), need for rewriting addresses/redirecting to right ports

34


MiddleBox mirroring

I Traffic is duplicated to the middlebox but not blocked

I → less latency but higher risk

I → need countermeasures (alert, disinfection, isolation...)

35


Other approachesI Load Balancing of Security MiddleBoxes

I Middleboxes can modify packets headers → difficult to track flowsI example: NAT traversal, proxies...I add tags to track flows from end to end (FlowTags: enforcing

network-wide policies in the presence of dynamic middlebox actions,Fayazbakhsh et al., HotSDN’13

I Moving target defenseI 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 cannotgather knowledge about hosts

I Each host is associated to a real IP address and mapping frequentlyto virtual IP addresses in a transparent way using OpenFlow

36


Outline

1 Introduction

2 Firewall

3 Monitoring


5 Conclusion

37


Some limitations and opportunities 1/3

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

I ValidationI 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 rulesI → so much information that very few operators may haveI → 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 topologyI generation of traffic using iperfI introduction of artificial delaysI rule fields are usually source and destination IP addresses and ports without prefix

aggregation

I lack of real datasets or scenarios to generate synthetic but realistic datasets

38



I MonitoringI 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 NetflowI impossible to predict the tuples → impossible to install rules beforehandI → install rules on fly → impracticable in large networks due to latency

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

I OpenFlow was aiming at keeping switches as specialized forwardingdevices (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 beneficialI Automated source code extension for debugging of OpenFlow based

networks, Hommes et al., CNSM’13

39



I Advanced tasksI SDN is only limited to forward traffic to dedicated boxesI but it brings a high flexibility to create and test new approach to

allocate dynamically traffic inspection tasks

I SDN can be well coupled with NFV (NetworkFunction Virtualization)

I NFV: allow to instantiate network function into a virtualizedappliance (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

I Acknowledgment: FNR IDSECOM project

40

Network Security through SoftwareDefined Networking: a Survey

Jerome Francois, Lautaro Dolberg,Olivier Festor, Thomas Engel

[email protected] 09/30/14

network security through software defined networking: a ......network security through software de...

Documents