咸蛋超人
博文 标签 类别 其他
咸蛋超人

Contents

SPHINX: Detecting Security Attacks in Software-Defined Networks

SuperEgg  included in  category 科研学习
     3486 words   7 minutes 

Dhawan M, Poddar R, Mahajan K, et al. SPHINX: Detecting Security Attacks in Software-Defined Networks[C]//NDSS. 2015, 15: 8-11.

本文很不错，写得十分详细，很贴近实用，作者是精通OF协议的。 本文目的提出一种检测已知和未知网络攻击并可实时发出警告，自动学习新的网络行为。

介绍部分

OF无法阻止switch发包给Controller,且传统攻击手段对SDN也有作用，而防御手段却不管用，OvS也更容易受到攻击，某一个主机或switch可以恶意地使整个网络变慢

  • 网络拓扑攻击 ARP，IGMP，LLDP攻击，例如，恶意switch可以发送随机LLDP信息从而欺骗网络的链路连接性。

  • 数据交付攻击 DDoS攻击，TCAM是存放流表的内存，DDoS攻击可以使流表溢出

  • 传统网攻击手段 传统网中LLDP攻击可通过加密解决，ARP攻击可通过主机运行arpwatch，DAI,或静态映射来解决，然而这些方法在SDN中都不能用。

SPHINX:Overview

Threat Model

目标是为了：找到攻击，验证policies 两个假设：Controller可信，大多数Switch可信，即：$C \rightarrow S 可信，S \rightarrow C不可信$

Flow Graphs

SPHINX利用流图模拟拓扑和数据层，利用控制信息进行流图构造。流图的建立是利用FLOW_MOD信息进行的，因为Controller可信。流图例子可见图1,流图时刻与最新拓扑一致。

https://s2.ax1x.com/2019/04/08/A4IqXD.png

缺陷：如果大多数的信息被篡改，那么就会使将这些信息视为可信而不发出警报；如果拓扑经常变动，会出现更高的误报。

High-level approach

SP利用从Controller收集到的控制信息增量建流图。 如图2是SP工作流程

https://s2.ax1x.com/2019/04/08/A4oZAs.png

SP拦截flow_mod,stats_reply,packet_in,features_reply消息提取网络拓扑信息，路由交付状态来构建网络视图并维护该流图，然后利用该流图对网络流进行监控，主要通过：自学习信息和管理员的policies进行监控。当有不信任的实体触发改变流行为或当前流违返policies时发出警告。 检测假拓扑例子：SP利用抽取的信息时刻观察网络拓扑状态和连接状态以及switch端口状态，如果packet_in信息中有LLDP，就抽取元数据进行检测：每个端口只能有一个neighbor；连接应该是双向的。 但多个恶意switch可以构建假双向连接接，SP则通过流在switch的字节统计从而确定流是否连续。

Why SPHINX works?

  • Easy of anaysis
  • Actrion attribution
  • Domain knowledge

#SPHINX:DESIGN 架构如图3,首先：监控所有的控制信息，再验证这些信息，最后验证处理后的网络更新。

https://s2.ax1x.com/2019/04/08/A4HZAH.png

Intercept OpenFlow packets

在图3中的架构可以看到，SP垫在Controller中，以便抽取所有的：PACKET_IN,STATS_REPLY,FEATURE_REPLY,FLOW_MOD消息 ##Build incremental flow graphs 网络中有三类实体：host,switch,flow。SP抽取并记录实体相关的元数据以填充表1中的特征集。

https://s2.ax1x.com/2019/04/08/A4qg6x.png

IP/MAC 标记主机，MAC/port标记流，in/out和flow match标记流的waypoint，statistics统计流的字节，包统计。同时，SP还记录具体流的主机，拓扑信息，交付状态以检测潜在的威胁。 packet_in:决定流或拓扑的开始信息 flow_mod:流路径 stats_reply:流级统计 features_reply:收集swithc配置 SP就是收集这些信息来构建拓扑。

Validate netwrok behavior

通过穿过流图来验证网络更新对流的影响和检测相关元数据是否与应用和管理员设定的安全属性一致进行验计，为了加快速度，SP通过缓存当前路径的waypoints来决定这个更新是否满足限制，如果更新修改了path的waypionts，SP缓存也作相应修改。

SPHINX POLICY ENGIN

Constraint specification

限制分两类：管理员声明的和SP对具体某个流学习的。管理员限制声明使用的是SP的policy language进行的，如表2,这里假设policies都是逻辑正确的。

https://s2.ax1x.com/2019/04/08/A4O4Wd.png

subject:流标志 object:traffic 属性 opearation：关系，给定流如何到达object trigger:when to check SP把policy给verifier，verifier抽取流的相关特征进行check。图4是一个例子。

https://s2.ax1x.com/2019/04/08/A4vfFU.md.png

当SP发现有异常时就发出alarm，如：从路由来的流统计信息与流当前路径不符。同时，Controller利用本地算法确保计算出的路径可达，无环，无黑洞等。

Constraint verification

Algorithm1说明了验证步骤：

https://s2.ax1x.com/2019/04/08/A4xepQ.md.png

验证 有三种：packet level,path level,flow level。 packet-level的元数据在具体的pcket_in包里，path-level元数据指网络的交付状态，packet-level和path-level信息在packet_in中获得时是分开的；flow-level指量化具体的数据层交付，定期从stats_reply中获得。表3列出三个元数据类的一些不变量，表4是SP的默认policies。

https://s2.ax1x.com/2019/04/08/A5pNcQ.png

https://s2.ax1x.com/2019/04/08/A5pdns.png

  • Topological state constraint verification: 拓扑限制可以使用packet_in中的元数据验证，不变量被验证后，就将元数据与应用policies进行比较，偏移的行为会被标记。

  • Forwarding state constraint verification 交付状态验证需要验证包和流级元数据，因为假设大多数switch是良性的，因此通过对流的包统计来确认是否出错，这里提出Similarity Index $\sum$，在t时刻的$\sum$为：$\Sigma_{t}=\Sigma_{t-1}+\left(\Delta_{n}-\Delta_{n-p}\right) / p$,这里的$\Delta_{n}=s_{n}-s_{n-1}$,$s_n$是第s个交换机在时刻t的统计结果，当有坏s时它的$\sum$会不一样，但也会造假$\sum$，但其下游的s的$\sum$又会异常。当坏s注入且移走相同的包时会检测不出来，这可以使用加密机制来解决.algorithm2是流的一致性检测算法。

https://s2.ax1x.com/2019/04/08/A5nRJJ.png

算法解释：输入流和流图，计算该流的路径并找到所有该path上的switch,并计算$\sum$,如果结果与平均值相差较大，就报告异常。同时也监视其它不活动的switch，以保证不会有流量被注入或吸走。$\tau$为阈值，当$\tau=x$时，计算结果要在$\sum/x和\sum *x$之间就算正常。太小会误报，太大会不报。例如：当一个链路丢包率为$\rho,$$s_n$的平均值为$\sum_{avg}$时，$s_{n+1}$的情况为：$\Sigma_{n+1} \propto \Sigma_{a v g} *(1-\rho)$，这时如果$\Sigma_{n+1}$不在$1 / \tau<\left(\Sigma_{n+1} / \Sigma_{a v g}\right)<\tau$时就会出警告，而以上可解出：$\tau \le k/(1-\rho)$。

handing alarms

如果出现alarm就让管理员进行数据核对，对于确定性验证SP就给出相应的包，链路，waypoint，对于可能性验证，SP给出switch/out-port和流。正常就将其并入SP的元数据库存起来，可疑就将相应的包丢弃。

脆弱的Controller

表5列出和各Controller的不足

https://s2.ax1x.com/2019/04/08/A5M2FS.png

Attacks on network topology

  • ARP poisoning SP使用MAC-IP绑定，或有不一样的ARP出现就发出警告，图5给出和该绑定的policy

https://s2.ax1x.com/2019/04/08/A5Qkfe.png

  • Fake topology switchs:X,Y,Z，Servers:A，B。x-A,z-B,A发送坏LLDP包说这是来自Z的，这就产生了一个Z到X的单向连接，这样从B PING A就得不到回应。SP会使用流图检测拓扑图阻止单向连接的产生，也可用policy，如图6

https://s2.ax1x.com/2019/04/08/A5Q0tU.png

attacks on data plane Forwarding

  • controller DoS，给controller发送大量的packet_in，使其忙不过来，这会弄慢整个网的速度 SP会计算packet_in的发送率，越过指定阈值发出警告，图7是pocicy

https://s2.ax1x.com/2019/04/08/A5Q20x.png

  • netword DoS switch间的流量环会卡网速 SP通过flow_mod定其更新流图和验证统计字节的一致性。policy见图8

https://s2.ax1x.com/2019/04/08/A5QqBt.png

  • TCAM exhaustion 即插入大量规则使流表溢出 SP检测流插入率，如果超过一定的值并持续就会发出 警告，图9为一个例子policy

https://s2.ax1x.com/2019/04/08/A5ldKA.png

  • switch blackhole SP检查字节一致性来找该错误，如果发生了，那它的下一个S的流统计为0

Evaluation

10 servers(IBM x3650 M3 ,2 Intel Xeon x5675 CPU 6 cores at 3.07GHz,128GB RAM)64bit ubuntu v12.04,14 switches(IBM Rack switch G8264) 土豪 host用mininet模拟出来。 这里根据经验设置k=1.034,$\tau=1.045$

Accuracy

  • Attack detection:检测时间，结果

https://s2.ax1x.com/2019/04/08/A5GDyQ.png

  • sencitiviuty of $\tau$ 太大太小都不好，不是误报就是不报，合适的值很重要。

Performance

  • end user latencies：对延迟影响很小
  • FLOW_MOD throughput:SP可高吞吐量处理且不影响Controller。不过当flow > 2k时处理时间会长。
  • PACKET_IN process:越多越慢。
  • policy verification:很快
  • Resource utilization:基本不占资源，约2%，最高不超过12.8%(你这个是物理机啊。。。。)

https://s2.ax1x.com/2019/04/08/A5J44P.md.png

#Future work 无法处理ingress 或 egress switch的$\Sigma_s$，缺少现实网络大范围实验，无法检测包的完整性。

HotSDN这个会议怎么样？

Updated on 2022-08-22
 论文阅读
Back | Home