Network Security through Software Defined Networking: a Survey

jerome.francois@inria.fr 09/30/14 Network Security through Software Defined Networking: a Survey Jérôme François, Lautaro Dolberg, Olivier Festor, Thomas Engel

2 1 Introduction 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion Outline

3 SDN OpenFlow Security Outline 1 Introduction SDN OpenFlow Security 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion

4 SDN OpenFlow Security Routing algorithms are distributed Every switch runs a program to fill out routing tables look at its routing table to forward packets Usual routing

5 SDN OpenFlow Security 2 planes Control plane (routing decisions) Data plane (forward the traffic) 2 main types of entities Decoupling the planes keep switches as forwarders only introduce a dedicated controller to take decisions requires communication between these entities

6 SDN OpenFlow Security Application aware networking How is configured the controller? manually from applications / systems through monitoring or interactions network information (topology, link usage) can be monitored as well bidirectional links

7 SDN OpenFlow Security Motivations Network programmability Empower research and innovation = easy testing of new methods/protocols Need for more traffic engineering / performance in networking in particular by controlling data delivering paths limited flexibility of standard routing approaches network size and speed increases powerful (and costly) forwarding devices vs. cheap commodity computers natural decomposition planes: control planes has been software based for a long time OpenFlow supported by many actors (research, equipment vendors, operators, chipset designers) incremental deployment

8 SDN OpenFlow Security Outline 1 Introduction SDN OpenFlow Security 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion

SDN OpenFlow Security Specification 9 A protocol: Communication switch - controller + switch specification Rules to handle packets in a flow table a set of matching fields in headers (IP/MAC addresses, ports, VLAN id, etc.) a priority to choose the rule is several can be matched a timeout counters about the flow instructions to execute (forward, drop, change some values)

SDN OpenFlow Security Flow table example 10 App Ingress port Mac Src Addr Mac Dst Addr Ip Src Address Ip Dst Address 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 1 * * * 2.3.4.5 TCP * 80 set dst addr = Load balancing 2.3.4.6, Forward to port 4 2 * * * 2.3.4.5 TCP * 80 set dst addr = 2.3.4.7, Forward to port 6

SDN OpenFlow Security Rule installation 11 2 modes Proactive: rules are installed beforehand coarse grained rule (aggregated) large flow tables lower latency good for general rule like routing or switching Reactive: rules are installed when the first packet of a flow arrives (table-miss) the controller gets a copy (packet in) higher latency small flow tables specific rule (fine-grained) more specific applications like load balancing or firewall

12 SDN OpenFlow Security Outline 1 Introduction SDN OpenFlow Security 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion

SDN OpenFlow Security What about security 13 2 main questions May SDN/OpenFlow enable or improve security? what are the potential applications? may we create new security processes? what are the benefits? what are the drawbacks? How secure is SDN/OpenFlow? Can be network programmability misused? is there existing approach to guarantee the proper functioning of a SDN enabled network and its applications?

14 1 Introduction 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion Outline

15 We already have seen an example Easy to implement Stateless firewall static policies install corresponding rule in a proactive or reactive way

16 Existing proposals Building firewall over the software-defined network controller, Suh et al., ICACT 2014 command line based tool using POX Floodlight OpenFlow controller + applications REST and Java API http://docs.projectfloodlight.org 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

17 Stateful firewall 1/3 Keep track of the connections (history) More powerful in particular for connection oriented protocols to only allow traffic when the session is established from inside accept reverse traffic with a timeout

18 Stateful firewall 2/3 What happens when the timeout expires before the session ends? need to reinstall the rule possible with ACK-like mechanisms not really stateful only few packets are analyzed (flow-based) save resources

Stateful firewall 3/3 Keep track of the exact status of the connection: need for packet inspection can be done at the controller side match (dst_ip=y,src_ip=x) -> action=controller Problems a lot of overhead: each packet is forwarded to the controller and then analyzed not feasible in practice (latency!!!) Hybrid approach redirect packets which needs stateful packet inspection to a specific middlebox/firewall very similar to the current situation Add support for matching TCP flags possible with OpenFlow v1.2+ 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

20 1 Introduction 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion Outline

Security Monitoring Firewall / Access control is important but cannot prevent everything need for monitoring, IDS, IPS to detect misbehaviors How to monitor misbehaviors from the network? connections to multiple suspects IP addresses / domains using blacklists creating multiple connections, traffic volume change (flood/scan/spam) network traffic compared to a profile (day/light, user or application patterns...) observations of similar connections between multiple hosts (botnet, worm propagation...) many attempts to connect to closed ports (scan) observing QoS degradation etc. 21

22 Main building blocks Years of research in security monitoring But network monitoring for security purposes rely on common building blocks services/hosts accessed and communicating together traffic statistics (number of bytes, packets,...) timing information to have an historic (timestamp) Retrieve such information with OpenFlow flows are characterized by headers (IP address, ports) flows are associated to counters

23 src: OF spec v1.4.0 Flow table counters

24 Getting flow information Counters get statistics about flows when a flow is considered inactive: FlowRemoved message on demand: FlowStatisticsRequest message (#bytes, #pkts, duration,...) when a flow start: PacketIn message active flows Different kind of monitoring: passive vs. active, push vs. pull

25 Passive Monitoring no additional traffic to inject into the network only able to observe statistics about current usage (for example, unable to infer which links are up, the bandwidth, etc.)

FlowSense FlowSense: monitoring network utilization with zero measurement cost, Yu et al., PAM 13 zero cost = push mode no intermediate statistics request monitor link usage sum all link usages issues long flow, maybe never ending due to keep alive messages large granularity, i.e. flow patterns may not be regular 26

OpenTM OpenTM: traffic matrix estimator for OpenFlow networks, Tootoonchian et al., PAM 10 Volume of traffic between each OD (origin-destination) pair Periodic polling fine grained and tunable update the matrix Switch selection (multiple switches on the path) most accurate = last swictch before reaching the destination other strategies: random uniform, higher probability for closer switches, round-robin, least load multipaths the control is aware of it and can sum over these paths 27

28 PayLess PayLess: A Low Cost Network Monitoring Framework for Software Defined Networks, Chowdhury et al., IM 14 Propose a REST API to define high level monitoring request (per user, per application, type of statistics...) Optimization of polling requests adaptive monitoring (periodic requests): flexible interval increase high variation in the last update, decrease otherwise batching multiple requests together

29 Active Monitoring inject packets in the network infer other information, even from non used links low overhead compared to traditional approaches based on ICMP src: Monitoring latency with OpenFlow, Phemius et al., CNSM 13

OpenNetMon OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks, Van Adrichemet al., IM 14 active + passive comparison of first and last switch packet loss active latency measurement (need to take in account delays between the controller and switches) Control plane: PacketOut + PacketIn Data plane: install a dedicated VLAN beforehand avoid scheduling in switches perform better accuracy 30

31 1 Introduction 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion Outline

32 Packet based analysis Some packets need to be collected individually Redirect every packet matching some patterns to the controller (PacketIn) overhead select packets to redirect checking TCP flags is useful for scan/worm detection only monitor SYN, SYNACK RST... Revisiting Traffic Anomaly Detection Using Software Defined Networking, Mehdi et al., RAID 11 successful vs unsuccessful connection initiation only monitor first packets (SYN, SYNACK, RST) normal flows (successful connections) install a rule for consecutive packets suspect flows short flows + few packet

33 Detailed analysis require accessing upper layer and maybe payload of packet deep packet inspection How to? Redirect every packet matching some patterns to the controller (PacketIn) Example: filter TCP port 25 to analyze email Same as before but no guarantee that decision can be made on first packets only high overhead Redirect/Copy traffic towards dedicated security middleboxes Let SDN Be Your Eyes: Secure Forensics in Data Center Networks, Bates et al., SENT 14

34 MiddleBox interception Traffic is forwarded when it is confirmed as safe many ways to do: MiddleBox could use PacketOut (through an interface), tagging as safe may just be based on addresses (everything coming from the middlebox), need for rewriting addresses/redirecting to right ports

35 MiddleBox mirroring Traffic is duplicated to the middlebox but not blocked less latency but higher risk need countermeasures (alert, disinfection, isolation...)

36 Other approaches Load Balancing of Security MiddleBoxes Middleboxes can modify packets headers difficult to track flows example: NAT traversal, proxies... 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 Moving target defense OpenFlow Random Host Mutation: Transparent Moving Target Defense Using Software Defined Networking, Jafarian et al., HotSDN 12 Objective: change IP addresses frequently such that attackers cannot gather knowledge about hosts Each host is associated to a real IP address and mapping frequently to virtual IP addresses in a transparent way using OpenFlow

37 1 Introduction 2 Firewall 3 Monitoring 4 Advanced Security Tasks 5 Conclusion Outline

38 Some limitations and opportunities 1/3 Stateful firewall need for additional support in both swicthes and controllers... while most of them are not fully compliant Validation usual problem in our domain (having a dataset with labeled attacks) more complex with OpenFlow as it needs network traffic, topology and OF messages or rules so much information that very few operators may have hard to define what would be the rule on a production network Validation is based on (most of the time): simple topology: small tree or linear topology generation of traffic using iperf introduction of artificial delays rule fields are usually source and destination IP addresses and ports without prefix aggregation lack of real datasets or scenarios to generate synthetic but realistic datasets

39 Some limitations and opportunities 2/3 Monitoring main goal is to gather statistics about the tuple (IP src, IP dst, protocol, src port, src dst) fine grained and similar to flow based approaches like Netflow impossible to predict the tuples impossible to install rules beforehand install rules on fly impracticable in large networks due to latency scalability is an issue... but not only for security applications Are we going in the right direction? OpenFlow was aiming at keeping switches as specialized forwarding devices (not monitoring devices...) why achieving monitoring as we did for many years? is SDN / OpenFlow open new ways to monitor the networks? looking at OF communications and installation rules might be beneficial Automated source code extension for debugging of OpenFlow based networks, Hommes et al., CNSM 13

40 Some limitations and opportunities 3/3 Advanced tasks SDN is only limited to forward traffic to dedicated boxes but it brings a high flexibility to create and test new approach to allocate dynamically traffic inspection tasks SDN can be well coupled with NFV (Network Function Virtualization) NFV: allow to instantiate network function into a virtualized appliance (no need for dedicated hardware) example: a firewall can be created on fly in the cloud......but the network has to be (re)configured accordingly Acknowledgment: FNR IDSECOM project

jerome.francois@inria.fr 09/30/14 Network Security through Software Defined Networking: a Survey Jérôme François, Lautaro Dolberg, Olivier Festor, Thomas Engel