Bohatei: Flexible and elastic ddos defense

SuperEgg included in category 科研学习

2019-09-10 2022-08-22 4062 words 9 minutes

Contents

Fayaz S K, Tobioka Y, Sekar V, et al. Bohatei: Flexible and elastic ddos defense[C]//24th {USENIX} Security Symposium ({USENIX} Security 15). 2015: 817-832.

本文提出一种针对新型网络的DDoS的防御系统，通过SDN，将可疑流量通过VM以达到保护主机的目的。（本文目的是为特定主机提供保护服务，收费服务那种。）本篇的introduction和background都比别人难懂。。。

Bohatei的基本概念

problem scope

Deployment scenario:布署在ISP上，并以可选服务的形式提供，图2为布署B的图。

Threat model:攻击类型：普通的DDoS如TCP SYN flood,UDP flood,DNS amplification,elephant flow。攻击可以是否（单类+单入口）$\rightarrow$(多类+多入口)
Defenses:使用有向无环图（DAG）表示攻击和缓解过程，边为前一个节点的处理结果，每个节点都是一个类似多个虚拟VM的实现，图3为一个例子。

本文重点是实现弹性防御，所以假设DDoS防御和DAG都是完成的。

本文不提供检测和防御算法，只作资源分配与管理。当检测到攻击类型与攻击强度后，本文根据攻击类型与攻击强度分配处理的Strategy Graph与VM资源并进行缓解。

Bohatei workflow and challenges

Bo的工作流可见图2

attack detection:检测攻击并声明具体攻击信息。如：“srcprefix=*,dstprefix=cust,type=SYN”
attack estimation:估计攻击流量的强度
Resource management:分配适当的网络资源（VM）来防御。
将可疑流量导入已分配的VM

当前需要解决的困难：

1.ISP 分多大的VM，几个VM来处理，这是一个NP hard 问题
2.如何丢弃恶意流？一发流表会使流表被饱和。
3.攻击者会改变攻击特性：类型，容量，入口点，这个能会导致：防御没有被使用或防御不足。一下章讲如何解决这三个问题。

本文实现原理

Resource Manager：

本部分讲ISP如何分VM的问题1，该问题最优解ILP是一个NP-hard问题，需要解决的时间很长，但作者将其分解为DSP和SSP，可以很快地解决出近似最优解。

Problem inputs

假设ISP是由边集$PoPs^5E={E_e}_e$和数据中心$D={D_d}_d$组成。PoP表示"edge pop and ingress".

ISP contrainsts:uplink capacity$C_d^{link}$和数据中心的计算容量$C_d^{compute}$.
Process requirements：对每个攻击需要策略图，资源管理器所需要的输入为一个标记图$DAG_a^{annotated}$，如图4。$T_{e,a}$表示由a出到e的流量比例，还有一个参数：$P_{a,i}$，它指的是VM对某个逻辑模型的$v_{a,i}$的处理能力。$v_{a,i}$指$DAG_a^{annotated}$的节点i。

Network footprint:$L_{e,d}$表示入口e到数据中心d的网络层代价，数据中心内有IntraUnitCost和InterUnitCost。

Problem statement

将标记图转为物理图时每个$V_{a,i}$由一个或多个VM实现，问题有：

fine-grained scaling:标注图高效并可扩展生成物理图，需要以图5c的方式，而不是图5b的方式扩展。

Goals:实例化VM，分布式处理流量使流量延迟最小化。需要分配置两个参数：1.$T_{e,a}$发给每个数据中心的流量比例；2.在数据中心$V_{a,i}$的VM个数。可将资源管理器问题看作优化问题ILP，解可见图15.但这种解法需要花数个小时运行，因此并不适用于Bohatei.

Hierarchical decomposition

问题分解：1.DSP（Datacenter Selection Problem）:选择一个数据中心处理可疑流量；2.SSP（Server Selection Problem）：在选择的数据中心中选择Server运行VM。利用贪心启发算法来求近似最优解。

DSP：将可疑流量$T_{e,a}$降序排序，算法将流量以最小的$L_{e,d}$分给数据中心。输出：1.$f_{e,a,d}$，表示入口可疑流量分配给每个数据中心的比例。2.对应攻击类型数据中心布署的物理图。可见附录B图16.

SSP：根据前一个节点选择邻近节点中处理能力最高的Server处理可疑流量，见附录B图17.

Network Orchestraion

上一节解决了配置数据中心处理进入的可疑流量以及分配服务器运行防御VM，本节需要进行路由表的配置以支持上一节的决策，主要解决的问题是：当攻击流量出现时的可伸缩性。因为当攻击出现时通过下发流表丢弃包的方式会容易出现效率不高和饱和的问题。本节处理的办法为：通过预定义tag提前下发标记的方式避免流表项过多

High-level idea

将问题分解

1.将流量转到数据中心；2.数据中心内将流量转到正确的VM。
使用基于标签逻辑交付规则和VM标签来替代流规则。

Wide-area orchestraion

当流量被检测为可疑，就通过预插入规则和$f_{e,a,d}$导入数据中心。预插入规则通过设置表静态隧道的方式进行，当DSP被解出后就在骨干网中根据$f_{e,a,d}$进行分流配置。

Intra-datacenter orchestration

数据中心内部包需要通过一个VM序列 1.本VM对包分析后决定下一个要发送的VM； 2.每个逻辑结点依需要实例化为几个VM，标注图层面需要负载均衡以均衡流量。当包在物理图中传递时，本地控制器跟踪并根据其处理结果上下文信息选下一个VM。这样做会遇到的问题：满足需求并可伸缩。

Encoding processing context:将处理上下文编码成tag并放入包头，S根据这个信息决定要发的端口。如图6

解决Controller channel瓶颈：预插规则解决rule爆炸：规则以通配符的方式决定包的交付。

scale-out load balancing:负载均衡器（LB）本身可能成为瓶颈，将每个VM中放一个LB并分布式协作，当处理包时LB根据处理上下文选择tab并进行负载均衡。
other issues:1.tag位的制定对：$k_{\max } \times l_{\max } \times \sum | V_{a}^{\text {annotated}} |$ 取对数。$k_{max}和l_{max}$为一下文可能的最大个数和一个节点实例化最大可能的VM数，$V_a^{}annotated$为对攻击类型a的标注图的顶点数。2.对于DNS amplification需要同一个VM处理请求和响应，而对UDP flood而不需要，处理办法为：边缘S接收入流量时将其发到处理相同tag出流量的数据中心。

Strategy Layer

interation model:把运行BO的ISP与攻击者之间的交互模型化为：重复的互动（看图原文吧，这个是真翻译不来）（我理解为：针对攻击ISP中BO做的改变）

Objective:由于ISP需要事先分配VM和硬件资源，因此攻击者可以： G1.提高ISP的硬件资源消耗； G2.成功交付攻击流量； ISP的目标就是要最小化G1和G2
Threat model:假设攻击者预算流量因定，只是何时何地的分布不知，则可表示为：$\sum_e\sum_aT_{e,a}\le B$,但具体的$T_{e,a}$值没有限制。
Limitations of strawman solutions:当前的不足以单点为例讲解，对PrevEpoch策略，会出现过度拟合问题，对uniform策略，出现过度供给问题。
Online adaption:这是本文使用的方法，若是静态攻击则$T_{e,a}^*=\frac{\sum_tT_{e,a,t}}{|t|}$合适，但敌人可能会改变改攻击属性，因此我们使用过去+随机的方式，即$\widehat{T_{e, a, t+1}}=\frac{\sum_{t^{\prime}=1}^{t} T_{e, a, t^{\prime}}}{|t|}+randperturb$，而$randperturb$的值为：$\left[0, \frac{2 \times B}{n e x t E p o c h \times|E| \times|A|}\right]$，这里假设防御的全部资源预算为：$2\times B$

implentation

本文提供源码

DDoS Defense modules

防御库由两个逻辑块组成：

Analysis(A):分析可疑流，给流加标签以决定进一步分析或响应。
对从A处得来的流进行交付，log,drop,rate limit. 下面列举每一个攻击的防御办法

1. SYN flood：监控连接的TCP，如果源IP从来不完成握手，则将未来的包标识成attack,如果有的完成有的未完成，则使用SYN-proxy防御。图8
1. DNS amplification：图9。检测DNS Server是否对指定IP查询，并进行分析，如果快速分析结果为未知再进行深入慢速分析。
1. UDP floow：A能过辩别UDP包数据是否异常用地多来检测。
1. Elempant flow:A检测流是否异常大。

异常检测（本文异常检测方法是别人的，工作重点在怎么以服务的形式提供使用）：使用nfdump检测，将结果以三元组(Type,FlowSpec,Volume)发给Bohatei全局控制器.type为攻击类型，FlowSpec为对流的一种描述，volume为基于流记录的异常流容量。

SDN/NFV platform

Control plane:将Bo实现为ODL的一个插件。
Date Plane: 使用Snort,Bro实现A和R，物理节点使用KVM中的VM进行。具体见表1.

使用GO实现DSP和SSP算法

Evaluation

SDN Testbed:13个Dell R720（20-core 2.8GHZ Xeon CPUs,128G RAM）每个机器在CentOS6.5(内核 v2.6.32)KVM。每个VM分配置1CPU，512M 内存。
Network Topologies:100G带宽，10ms延迟，数据中心数为骨干网S数的5%，在[22]中选拓扑结构。
Benig tarffic demands:使用iperf和自定义代码生成流量，流量多少与骨干网规模成正比。
Attack traffic:SYN flood手动写，DNS amplification用OpenDNS BIND,大象流和UDP flood使用Iperf。