Software Defined Networking Security: Security for SDN and Security with SDN

Seungwon Shin, Network and System Security Lab, GSIS, KAIST

SDN  Security  Research •  Two  issues  

•  Security  for  SDN  •  Security  issues  in  SDN  itself  

•  Security  with  SDN  •  Security  applica6ons  based  on  SDN  

Security for SDN

Security  Issues  in  SDN • Why  security  issues?  

•  SDN  is  not  so  mature  yet  •  There  could  be  some  (or  many)  possible  security  problems  in  SDN  

•  E.g.,  •  Rule  conflict  and  Dynamic  flow  tunneling  problem  •  Channel  issue  •  Flooding  aFack  problem  

Related  Work •  A  Security  Enforcement  Kernel  for  OpenFlow  Networks  

•  HotSDN  2012  •  Phillip  Porras,  Seungwon  Shin,  Vinod  Yegneswaran,  Mar6n  Fong  Mabry  Tyson,  Guofei  Gu  

•  SRI  Interna6onal  and  Texas  A&M  University  

•  Towards  Secure  and  Dependable  SoYware-­‐Defined  Networks  •  HotSDN  2013  •  Diego  Kreutz,  Fernando  M.  V.  Ramos  and  Paulo  Verissimo  

•  LaSIGE/FCUL  

•  Towards  A  Secure  Controller  Pla`orm  for  OpenFlow  Applica6ons  •  HotSDN  2013  •  Xitao  Wen,  Yan  Chen,  Chengchen  Hu,  Chao  Shi  and  Yi  Wang  

•  Northwestern  University  

•  AFacking  SoYware-­‐Defined  Networks:  A  First  Feasibility  Study  •  HotSDN  2013  •  Seungwon  Shin  and  Guofei  Gu  

•  Texas  A&M  University

Dynamic  Flow  Tunneling • Problem  

•  A  buggy  (or  malicious)  applica6on  can  let  an  aFacker  evade  security  policies  •  Reported  at  HotSDN  2012  

SDN Switch

Host A Host B

Malicious or buggy application Controller (e.g., NOX)

SDN Controller

A à C: Replace A with D, D à C: Replace C with B D à B: Forward Finally, A can contact B

A à B: Block

A à C

SDN  Architecture

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 1 forged or faked traffic f

lows

Not specific to SDNs, but can be a door for augmented DoS attacks.

Possible solutions: IDS + rate bounds for control plane requests

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 2 attacks on vulnerabiliti

es in switches

Not specific to SDNs, but now the impact is potentially augmented.

Possible solutions: sw/hw attestation with autonomic trust management

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 3 attacks on control plane

communication

Specific to SDNs: communication with logically centralized controllers can be exploited.

Possible solutions: threshold cryptography across controller replicas

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 4 attacks on and vulnera

bilities in controllers

Specific to SDNs, controlling the controller may compromise the entire network.

Possible solutions: replication + diversity + recovery

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 5 lack of mechanisms to ensure trust between the controller and ma

nagement apps

Specific to SDNs, malicious applications can now be easily developed and deployed on controllers.

Possible solutions: sw attestation with autonomic trust management

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 6 attacks on and vul

nerabilities in admin stations

Not specific to SDNs, but now the impact is potentially augmented.

Possible solutions: double credential verification

Slide from Deigo Kreutz

Data Plane!

Control & Ma

nagement!

7"

SDN"device"

SDN"device"

SDN"device"

Admin"Sta0on"

6"5"

4"

3"

SDN"Controller"

SDN$control$protocol$(e.g.,$OpenFlow$)$

Management$connec8on$(e.g.,$SSH$)$

2"

Data$plane$physical$/$logical$connec8ons$

SDN"device"

1"

Threat vector 7 lack of trusted resources for forensics and

remediation

Not specific to SDNs, but it is still critical to assure fast recovery and diagnosis when faults happen.

Possible solutions: indelible logging

Slide from Deigo Kreutz

PermOS  for  SDN •  Problem  

•  Applica6ons  can  access  system  resources  without  permission  

•  PermOF  •  Isolate  applica6ons  and  check  their  permissions

Flooding  Problem •  Problem  

•  AFacker  can  flood    •  Messages  to  a  controller  •  Flow  rules  in  a  flow  table  

•  Reported  at  HotSDN  2013  

Attacker 20.0.0.1

Load balancing application Controller (e.g., NOX)

SDN Controller

SRC IP -> DST IP

Fake SRC IP

10.0.0.1 -> 20.0.0.1

10.0.0.255 -> 20.0.0.1

10.0.0.1 -> 20.0.0.1 10.0.0.2 -> 20.0.0.1

……

Flow Table

Some  More  Possibility • Malicious  applica6ons  

•  They  can  crash  a  controller  •  They  can  infect/kill  other  applica6ons  •  They  can  modify  internal  data  structures  as  they  want  

• Buggy  applica6ons  •  They  can  crash  a  controller  •  They  can  kill  other  applica6ons    

Security with SDN

Related  Work •  CloudPolice:  taking  access  control  out  of  the  network  

•  Lucian  Popa,  Minlan  Yu,  Steven  Y.  Ko,  Sylvia  Ratnasamy,  Ion  Stoica  •  HotNET  2010  

•  Can  the  Produc6on  Network  Be  the  Test-­‐bed?  •  Rob  Sherwood,  Glen  Gibb,  Kok-­‐Kiong  Yap,  Guido  Appenzeller,  Mar6n  Casado,  Nick  McKeown,  Guru  Parulkar    •  OSDI  2010  

•  Broadband  Internet  Performance:  A  View  From  the  Gateway    •  S.  Sundaresan,  W.  de  Donato,  N.  Feamster,  R.  Teixeira,  S.  Crawford,  A.  Pescape  •  SIGCOMM  2012  

•  CloudWatcher:  Network  Security  Monitoring  Using  Openflow  in  Dynamic  Cloud  Networks  •  Seungwon  Shin  and  Guofei  Gu  •  ICNP,    NP-­‐Sec,  2012  

•  FRESCO:  Modular  Composable  Security  Services  for  SoYware-­‐Defined  Networks  •  Seungwon  Shin,  Phil  Porras,  Vinod  Yegneswaran,  Mar6n  Fong,  Guofei  Gu,  and  Mabry  Tyson    •  NDSS  2013    

Access  Control •  In  a  Cloud  network  

•  Problems  •  Access  control  for  a  cloud  network  

•  Inside  aFacks  •  A  tenant  can  aFack  another  tenants  

•  Need  to  install  F/W  to  protect  each  tenant  

•  However,  •  Hard  to  install  access  control  policies  in  a  cloud  network  

•  Many  network  links  •  Complicated  and  different  access  control  policies  

Access  Control:  Solution  with  SDN   • CloudPolice  

•  New  access  control  for  a  cloud  network  environment  •  Installed  at  each  VM  •  Features  

•  Scalable  (millions  of  tenants)  •  Flexible  (easy  to  change)  •  Robust  to  DoS  aFacks  

•  Affilia6on  •  UCB  and  Princeton  

CloudPolice •  Overall  opera6on  

•  CloudPolice  at  a  source  sends  a  control  packet  before  sending  data  flow  •  CloudPolice  at  a  des6na6on  inves6gates  access  control  policies  for  a  source,  and  it  returns  response  message  to  a  source  

•  CloudPolice  at  a  source  performs  some  opera6ons  based  on  the  received  messages  

Network  Separation • Problem  

•  A  cloud  or  an  enterprise  network  needs  to  separate  logical  networks  for  each  tenant  

•  Solu6on  •  VLAN  •  However,  limita6on  in  crea6on:  4096    

Network  Separation:  Solution  with  SDN •  FlowVisor  

•  Create  virtual  networks  with  SDN  •  Ideally,  no  limita6on  

•  Affilia6on  •  Stanford  and  BigSwitch     FlowVisor

Controller 1 Controller 2

Alice Virtual Network Bob Virtual Network

Physical Network

OpenFlow switch

App 1 App 2 App 1 App 2

Home  Network  Instrumentation • Problem  

•  Home  network  elements  are  commonly  used  for  network  aFacks  •  Bot  infected  hosts  

•  However,  it  is  not  easy  to  inves6gate  each  home  network  element  •  Need  to  install  third-­‐party  applica6ons  •  No  standard  

Home  Network  Instrumentation:    Solution  With  SDN • Bismark  project  

•  Embed  an  OpenFlow  switch  module  into  each  AP      •  Monitor  home  network  traffic  (1)  •  Detect  aFacks  (2)  •  Enforce  a  flow  rule  to  handle  aFacks  (3)  

•  Affilia6on  •  GIT    

Alice home network Bob home network John home network

Controller

Security Application

(1) (1) (1)

(2) Detect attacks(e.g., botnet, spam)

(3) (3) (3)

Security  Aware  Routing  

• Problem    •  It  is  not  easy  to  protect  a  cloud  network,  even  though  we  have  installed  network  security  devices  

• Why?  •  AFack  from  inside  

•  Most  network  security  devices  monitor  traffic  from  outside  •  Dynamic  configura6on  

•  VM  migra6on  •  Network  configura6on  change  •  Where  do  we  need  to  install  security  devices?  

Security  Aware  Routing:  Solution  with  SDN  

• CloudWatcher  •  Provide  new  rou6ng  algorithms,  and  they  guarantee  that  specified  network  security  devices  can  monitor  specific  network  flows  

CloudWatcher  • New  Rou6ng  algorithms  

•  Mul6path  naïve  •  Shortest  through  • Mul/path  shortest  •  Shortest  inside  

- Sample network - S: start node, E: end node R: router, C: security device

CloudWatcher  • Basic  rou6ng  scheme  (NOT  CloudWatcher’s  idea)  

•  Find  the  shortest  path  between  a  start  host  and  an  end  host  •  Path:  S  à  R1  à  R5  à  R6  à  E  

• Problem  •  It  does  not  pass  through  the  security  device  C  (R4)  

CloudWatcher  • Mul/path  shortest  

•  Improved  version  of  mul6path  naïve  •  Two  phase  

•  Find  the  shortest  path  (P1)    •  S  à  R1  à  R5  à  R6  à  E  

•  Find  the  shortest  path  between  routers  on  the  path  P1  and  R4  •  R6  à  R4  •  R6  à  {R4,  E}  

Killer  Application  of  SDN?  

• Reducing  energy  in  data  center  networks  • Dynamic  virtual  machine  migra6on  in  cloud  networks  •  ....  diverse  network  applica6ons    

• What  about  security?  •  Can  SDN  enable  new  capabili/es  to  improve  network  security?  

Exemplar  SDN  Security  Apps  

•  Security  func6ons  can  be  applica6ons  of  SDN  •  Firewall  •  DDoS  detec6on  •  Scan  detec6on  •  Reflector  net  •  Tarpit  •  Dynamic  quaran6ne  •  and  more…  

import logging from nox.lib.core import * import nox.lib.openflow as openflow from nox.lib.packet.ethernet import ethernet from nox.lib.packet.packet_utils import mac_to_str, mac_to_int log = logging.getLogger('nox.coreapps.examples.demo') class demo(Component): def __init__(self, ctxt):def create_and_enfoce_policy(self, dpid, policy_type, outport_find, inport, outport, bufid, buf, packet): if outport_find == 0: print 'DBG: No Specific Out Port: Flooding’ if policy_type == 'ARP': print 'DBG: ARP packet’ self.send_openflow(dpid, bufid, buf, openflow.OFPP_FLOOD, inport) elif policy_type == 'REQ': attrs = extract_flow(packet) attrs = {core.IN_PORT:inport, core.DL_TYPE:ethernet.IP_TYPE, core.NW_PROTO:ipv4.ipv4.TCP_PROTOCOL core.NW_SRC:'10.0.0.2'}

SDN switch

SDN controller

Host A Host B

F/W application

(1) Host A sends packet to Host B (2) Switch asks a controller form a flow rule (3) F/W application decides to block the packet (4) Switch drops this packet

(1) (2) (3)

(4)

SDN  Security  App  Development  Challenges  • However,  it  is  not  easy  to  create  security  apps  in  SDN  

•  Security  service  crea6on  and  composi6on  challenge  •  How  do  we  simplify  development  of  security  applica6ons?  

•   Informa6on  deficiency  challenge  •  E.g.,  TCP  session,  network  status  

•  Threat  response  transla6on  challenge  •  How  do  we  enforce  security  policies  to  the  network  devices?  

 

FRESCO  • FRESCO  is  a  new  frame  work  that  

• Provides  a  new  development  environment  for  security  applica6ons  

• Effec6vely  manages  shared  resources  among  security  applica6ons  

• Simplifies  deployment  of  security  policies  •  provides  a  set  of  7  new  intelligent  security  ac6on  primi6ves    

•  E.g.,  block,  deny,  allow,  redirect,  and  quaran6ne  

FRESCO  Architecture  • Component  

•  Applica/on  layer  •  Development  env.  (DE)  •  Resource  controller  (RC)  

•  Kernel  layer  •  Security  enforcement  kernel  •  FortNOX  

•  paper  in  HotSDN  2012  

Development environment

Resource controller

OpenFlow application

OpenFlow application

NOX

Application layer

Kernel layer (FortNOX)(controller)

OpenFlow switch OpenFlow switch OpenFlow switch

Operational  Scenario  

Module 2

Module 3

Module 1

Module 4

Instance 1 Instance 2

FRESCO Security Kernel Enforcement Controller

OpenFlow switch

OpenFlow switch

OpenFlow switch

OpenFlow switch

Administrator FRESCO Script

FRESOCO DB Event

Execution

Table

Monitoring

DE RC

Example:  Scan  Detection    •  Steps  

•  Check  blacklist  à  Threshold  based  scan  detec6on  à  Drop  or  Forward  

blacklist_check (1)(1) { type: TableLookup event: TCP_CONNECTION_FAIL, TCP_CONNECTION_SUCCESS input: SRC_IP output: blacklist_out parameter: NONE action: NONE }

scan_detect (1)(1) { type: ScanDetect event: PUSH input: blacklist_out output: detect_result parameter: NONE action: NONE }

final_action (1)(0) { type: ActionHandler event: PUSH input: detect_result output: NONE parameter: NONE action: detect_result == 1 ?DROP:FORWARD }

TCP CONNECTION SUCCESS || TCP CONNECTION FAIL

SRC IP IF SRC_IP in Table output = 1 ELSE output = 0

output

PUSH

IF output == 1 result = 1 ELSE ret = detect_scan() IF ret == 1 result = 1 ELSE result = 0

result

PUSH

IF result == 1 DROP ELSE FORWARD

Evaluation  Source code length comparison

Algorithm

Implementation Standard OpenFlow FRESCO

TRW-CB 1,060 741 66 (58 + 8) Rate Limit 991 814 69 (61 + 8)

Results for Standard and OpenFlow are obtained in the following paper, S. A. Mehdi, J. Khalid, and S. A. Khayam. Revisiting Traffic Anomaly Detection Using Software Defined Networking, In Proceedings of Recent Advances in Intrusion Detection, 2011.

Flow rule setup time NOX Simple Flow

Tracker Simple Scan Detector

Threshold Scan Detector

BotMiner P2P Plotter Detector

Time (ms) 0.823 1.374 2.461 7.196 15.461 11.775

Summary •  Security  in  SDN  

•  Two  main  issues  •  Make  SDN  secure  •  Use  SDN  to  make  secure  applica6ons  

• What  is  your  choice?  •  Hacking  SDN?  •  Using  SDN?