1 引言

WAF (Web Application Firewall)是Web网络应用防护系统, 担当着是Web应用的防护, 由于现如今Web应用在当今互联网应用中的主流应用, 一般来说WAF的应用防护包括一般包括常见的Web防护, 比如异常的流量监测、DDoS攻击、https攻击、SQL注入的攻击、命令注入攻击、cookie/seesion劫持、应用平台攻击劫持等攻击^[1]. 而这些业界对全面防护能力的要求都离不开专业的WAF设备防护以及流量防护方案.

而云计算业务的应用越来越普及, 行业内的企业和单位已经将自己的Web业务信息系统逐渐的迁移至云服务中. 集中化的云虚机部, 使得部署资源的集中化. 这些企事业单位享受着云化业务带来的好处的同时, 其集中化云Web服务的安全无疑是最大的挑战^[2], 然而集中化的云端部署, 也为WAF防护应用的发挥提供了舞台.

业界公有云提供云内WAF安全框架如图1, 将云内Web流量先交由专业WAF设备来防护清洗.

2 业界WAF方案分析

中国移动在全国布局公有云WAF应用中, 发现业界方案在流量防护效率、整体引流拓扑防护吞吐量表现不足.

2.1 流量监测现状

WAF防护系统在做流量防护的时候, 需要时刻对流量进行检测分析. 而流量监控分析的功能是采集交换机不断的生成Flow, 并将采集后的Flow流的拆包解析、归并. 流量监测分析技术实现的是对高速转发的网络层IP数据流流量信息进行采集, Flow提供的是网络流量的会话级视图, 这种会话级视图, 可以定义为包含一个源IP地址和目的IP地址间传输的数据包流数据交换形式.

这种业界Flow流的串行分析流程, 存在以下问题:

首先, 接收Flow步骤和解析Flow步骤以及归并计算步骤其处理能力被设定预设固定值. 无法动态自适应调整处理能力.

其次, 对着图2的处理步骤, 整体流量监控机制缺乏收集能力与解析能力之间的协同同步机制, 以及缺乏接收能力和解析能力两者之间的协同同步机制. 每个处理步骤无法感知其上游处理业务压力及下游步骤处理能力.

上述缺陷, 或者由于上游步骤传过来的数据量较大, 而下游步骤的处理能力被固定的较小, 导致来不及接收, 来不及解析的丢包情况. 使得监控数据的丢失而降低防护的精度. 或者由于上游数据量较小, 而预置的下游步骤的处理能力被预设的很大, 导致等待接收, 等待解析的浪费计算资源情况. 而在突发大流量的WAF应用场景中, 这种流量监测机制通常会无法适应突发的统计数据量将流量丢弃, 影响中国移动云WAF的防御的效果.

2.2 引流拓扑现状

一般业务的防护系统WAF, 如果云网络不是SDN网络, 需要通过流量代理的方式在云实现东西向流量的牵引调度: 将防护流量引流到WAF设备, 代理引流需要在部署机器中设置一个引流代理, 通过代理来将防护流量引入WAF设备. 通过在部署机器中集中的引流虚拟机接收防护策略, 并按照防护策略对流量进行牵引到WAF设备的一种拓扑, 拓扑中WAF的流量牵引为单线单WAF集群模式. 安全控制平台将相应的引流请求发送至这个引流代理, 引流代理根据虚拟机所在宿主机的位置以及虚拟机当前的网络情况, 下发相应的引流指令, 并且完成对应的网络配置, 实现流量牵引.

这种业界引流代理一方面在进行引流操作时, 需要获取对云计算系统较大的操作权限, 代理功能依赖于平台环境, 这样每种代理和云计算平台之间很难进行解耦^[3], 而且代理的部署设置难以移植和进行部署复用. 另一方面这种单线的引流回大幅的增加图3左侧vswitch的负载. 拓扑中WAF的流量牵引为单线单WAF集群模式, 引流过程中需要占用大量的平台内部网络资源进行. 而且这种代理引流会使得操作依附于云计算平台, 使得操作复杂. 而业界SDN引流也为4.1介绍串行单线引流. 防护策略与流量牵引的串行结构使得策略与操作没有分离, 限制了SDN引流效率^[4], 和WAF的防护吞吐率.

3 流量监测改造

本章设计流量监测改造方案解决2.1提出的流量监测低效问题, 方案包括设计3.3模型, 以及3.4改造算法. 方案提供了各个处理流程可动态化调整处理能力的机制, 实现自适应动态化调整处理能力, 解决了流量处理步骤能力固定的问题. 方案提供了同步算法, 使得各个处理流程之间的协同调整处理能力以及启动的同步机制, 实现了处理步骤之间的能力相互感知, 并动态变化能力以匹配高效协同, 解决了处理步骤能力配合低效的问题.

3.1 流量统计监测

如2.1业内对流量解析的流程通过固定的格式包来解析所得到的对应Flow流, 并采用单步的收集过程, 而后进行归并计算. 整体流程的统计监测结果一般如图4.

这是包含网络七元组的统计信息源地址、目的地址、源端口、协议类型、流量大小等. 这些信息都是可用提供WAF平台防DDoS或者其他功能的特征信息. DDoS攻击会使得网络上出现可检测的统计性特征^{[5, 6]}: 比如一个网络真实节点的节点位置相对固定, 其地址的TTL值比较稳定, 由于TTL的值难以变动, 所以可以用来将其视为一个特征值来判定虚假的IP攻击行为; 比如SYN Flood类型的攻击中最明显的攻击特征就是由于虚假的SYN请求过多, 半连接剧烈增长, 而与之对应的FIN信号很少. 这种情况下可以具体设计将间隔时间内将SYN和FIN的比值作为阈值判断, 当SYN信号的数量超过FIN信号数量过多, 起比值超过阈值的时候可作为攻击特征; 另外访问攻击目标的源地址的新增IP数量剧烈上升特征, 也能做攻击判定.

3.2 流量解析模块

对流量解析具体的业界流程为例: 由图2显示在此过程中的收集Flow和归并计算按照流程分两步处理, 这样的设计在做流量监控的时候, 会导致性能上的缺陷. 首先Flow记录的发送能力和接受和收集Flow接受能力难以配和和协同. 在Flow记录高速大量的全部进行发送, 而此Server端没办法感知到Flow流的速度, 从而导致Server端无法全部解析Flow记录, 而无法计算解析的Flow包, 将会被当做流量冗余而被丢弃, 最终使得Server端的缺乏协同而丢失数据Flow而导致流量统计精度不足. 另一方面若Flow记录发生的量小, Server端的处理能力被预置的很大, 会造成Server端的等待, 其预置的处理能力将会空置和浪费.

3.3 改造流量监测模型

本文提出高效流量统计方案所提出的解决方法和系统包括, 如图5所示.

1) 线程组模块Server端接收Flow的接收模块.

2) 线程组模块Server端解析Flow的解析模块.

3) 线程组模块Server端计算Flow归并计算模块.

以上3个处理步骤采用线程, 通过动态化的线程组, 进行实现动态能力自动调节.

1)如图所示定义udpserver.c的Server端的线程能力接收组, 以及Server端的解analyse.c的解析线程能力进程, 以及Server端的归并模块功能线程组.

2)本功能模块组感知到不能够满足当前处理能力需求的时候, 比如当前解析线程数量为n–1模块解析速度较慢, 则本模块动态化处理能力增加处理能力资源, Server端启动新线程n来提升解析速度, 此时的处理能力为使得模块处理速度达到n.

3) 相反的当本模块能力感知能力为过剩的时候. 则同步算法要销毁最新启动的线程, 从而线程能力组的能力下降到n–1, 释放单位的线程资源.

3.4 自适应统计同步算法详解

1)在处理能力的适配上, 是根据处理能力需要自动调整的, 而处理能力大小的由信号量变量的值来决定. 接收线程通过UDPserver中的recvfrom()函数不断的循环监听抓取交换机发的Flow流. (Flow流是UDP包), 并将Flow流写入长度为n的队列^[7], 对于此队列长度n, 如图6所示.

图6中接收步骤为生产者, 不断的往自己的队列塞从交换机那抓取的Flow记录, 解析模块从队列里面抽取, 成为消费者. 他们共享上述队列的资源池.

2)设计算法的决策阈值, 本方案中设计高阈值为队列资源池的长度n, 低阈值为空的队列资源池的长度0, 上图当生产者和消费者的之间的信号量作为两进程之间的线程组通信信号. 当步骤之间的信号量达到对应的阈值n, 或者步骤之间的信号量达到对应的阈值0, 则按照步骤3)的算法进行决策执行.

3)如果接收步骤过快, 步骤信号量达到满载的n, 此时此发明启动设定增加消费者: 当此接收线程为j, 解析线程为i, 当j写入的数据数量mi, mi在0~n之间, mi在每接收一个单位其值加1, 在解析数据从队列取走数据解析时其值减1, 当mi到达队列长度n(写满)则对解析步骤进行加速(加大消费者能力速度)此时解析步骤启动一个新线程i+1. 此时阈值判断量为新的变量n=mi+1.

4)如果解析步骤过快, 步骤信号量达到空载的0此发明启动设定减少消费者: 当此发送线程为j, 解析线程为i, 当j写入的数据数量mi, mi在0~n之间, 到达队列长度0(取空)则对解析步骤进行减速(降低消费者能力速度)此时解析步骤销毁最新启动的当前线程i. 此时阈值判断量为新的变量n=mi–1.

5)此算法的控制逻辑为图5中P1V1标记处通过信号量向后控制. 向后控制逻辑顺序类似栈结构: 写入相对过快则启动解析新线程顺序为解析(1号, 2号, 3号,…,i号,i+1); 写入相对过慢则销毁的是当前解析线程号销毁顺序(i号, i–1号,…,2号,1号).

4 引流拓扑改造

本章解决2.2业界的WAF的引流拓扑吞吐量低的问题: 业界WAF引流的SDN的引流方案为控制策略和流量承载都通过SDN网关来处理, SDN网关可以通过代码接口用NETCONF协议进行控制配置, 比如下发路由实现流量牵引等, 7750为诺基亚的SDN网关设备, 通过7750进行集中下发策略和承载引流, 使得控制过程和业务承载难以真正相互分离. 单一的防护资源池无法并发的进行流量的牵引. 导致防护吞吐量较低. 无法充分利用WAF的防护能力. 本章提出WAF引流拓扑改造, 实现SDN牵引流量承载和控制策略下发分离, 实现WAF的并发调用防护, 另一方面通过绕过7750的SDN对引流进行并发操作, 提高中国移动WAF设备使用效率, 提高WAF系统防护的吞吐能力.

4.1 WAF的SDN引流拓扑

通过SDN集中的控制器, 来掌握整体的网络结构图^[8-12]. 如果需要云平台里面的目标Web服务器进行防护, 需要进行检测和防护的流量, 方案的SDN完成流量的牵引的结构大概如图7所示: 以某厂商的云平台SDN引流方案为例子.

如图7的流程图所示, 首先用户通过平台控制平面的操作把引流信息通过NETCONF下达给7750流量牵引的命令,其次从流量层面来看首先流量通过7750进行牵引, 结合控制层面来看, 整体的SDN的东西向引流如下:

1) 公网访问防护IP时, 经过7750后, 路由到WAF, 此时的流量过程为源目地址为: 客户端IP——WAF.

2)软WAF对流量进行检测, 合规请求通行, 并对源地址进行转换, 此过程源目地址为: Nat_WAF——业务网络服务器IP.

4)业务网络服务器将响应内容发送给软WAF, 此过程源目地址为: 业务网络服务器IP——Nat_WAF.

5)软WAF收到业务网络服务器的响应后, 转发响应内容给客户端.

7750构成了业务侧的核心, 防护策略、流量牵引只能通过7750串行下达, 无法并发的进行流量的牵引. 导致防护吞吐量较低.

4.2 改造WAF引流拓扑

在高性能SDN并发引流的改造如图8，具体思路提出如下.

1)以6台WAF为. 他们按照hash映射算法与平台映射.

2)通过安全管理平台下发实际的防护策略直接到设备WAF1, WAF2上此时策略到WAF1、WAF2上的IP为真实IP.

3) SDN将保护流量直接牵引到LB.

4)此时LB和平台采用与1)一致的hash映射算法牵引到目的WAF设备, 牵引地址为WAF1 和WAF2的共同的高可用地址VIP.

分析结构: 此时的拓扑接口控制防护策略从上图的左侧通过安全管理平台直接进行下发, 通过平台算法映射下发到WAF设备, 而承载流量通过有7750的SDN网络新加LB并与平台相同映射, 实现策略对应的WAF实现策略与流量承载分离.

总结: 1) 改造后使得用户侧防护策略可以绕过7750直接通过平台映射到对应设备, 使得控制端可以并发调用防护. 2) 7750不用关心具体的引流目标WAF, 只需把流量引入LB, 由LB采取对应控制端引流映射WAF, 实现对应策略的流量牵引.

5 试点实验效果

本章实验在中国移动某省公司公有云进行试点测试, 分别实验(采用流量监测提升和拓扑改造提升)高性能WAF方案比业界传统方案的流量监测防护效率和流量吞吐量.

5.1 实验流量监测效率

测试环境1搭建: WAF流量检测端与流量业务发送端直连, 对流量检测端进实验测试对比分析, 对象为1: 高性能WAF方案和2: 传统WAF防护方案. 测试模型如图9.

测试内容为对0.2 s后开始同时分别对两组WAF模块分别发送500 mb/s的流量来考察观测对象1: 在测试时间高性能方案的流量监测结果. 2: 常规方案的流量监测结果. 两组的时间段都一致, 发送端和接收端的测试时间也相同.

1和2对象测试结果如图10.

实验仿真测试结果验证思路为验证流量统计和实际流量偏移量, $w$ 为统计时间. 其中为 $s(w)$ 高性能监控算法监控统计流量, ${{u}}(w)$ 为常规算法监控统计流量. $\theta 1$ 、 $\theta 2$ 为对应算法偏差量.

$\theta 1 = {\left( {{{5 - s(}}\omega {\rm{)}}} \right)^2}$

(1)

$\theta 2 = {\left( {{{5 - u}}(\omega )} \right)^2}$

(2)

实验1结果分析:

1)流量发送端, 向WAF系统发送需要防护监测的流量. 在时间在0.2 s时刻, 发送流量由0 b/s突发增加到500 mb/s.

2)流量统计端, 为WAF系统内防护流量统计, 如图11, 采用改造流量监测统计算法的高性能WAF系统, 面对突发数据压力, 按照3.4自适应算法预期, 迅速自适应增加处理能力, 在1 s时刻, 就监控解析了480 mb/s以上的流量.

3)对比传统WAF系统, 其到3.2 s时刻才监控解析了480 mb/s以上的流量. 在 $w$ $ \in \left( {0{\rm{ - }}1} \right)$ 偏差的监测数据包因为传统方案无动态自增处理能力机制而大量丢包. 1 s时刻手动增加传统方案监测资源能力, 才慢慢在3.2 s时刻监测足够数据.

4) 1)−3)分析结合仿真计算结论式(1)和式(2), 得到采用改造流量监测方案的高性能WAF方案比传统WAF系统的流量监测丢包率更少, $\theta 1$ 小于 $\theta 2$ 更高效贴合实际流量的承载. 因而高性能WAF方案的防护效率更高.

5.2 实验防护吞吐量

实验2设计: 对象1、2同时对公有云环境内的3台云主机按照相同策略进行WAF防护.

实验对象为1: 高性能WAF方案, 2: 传统WAF防护方案, 单台业务访问流量访问为10 mb/s. 实验测试对象为检测WAF防护系统池的防护吞吐量.

时间 $w$ 选取说明, 单台主机策略的WAF防护系统的调度启动周期为10 s以上, 启动后WAF系统有吞吐流量可以统计. 实验选取第一个启动周期中的10 s时间段作为统计周期来进行统计. $w$ $ \in \left( {0{\rm{ - }}10} \right)$ .

实验2结果分析:

1)传统WAF防护方案在第一个启动周期10 s内, $w$ $ \in \left( {0{\rm{ - }}10} \right)$ 顺序启动了一台主机的流量防护, 而其他主机防护策略还在排队, 统计周期内整个传统WAF方案在10 mb左右的防护流量.

2)高性能的WAF方通过改造引流拓扑, 策略与引流承载分离, 测试结果实现可并发的防护, 如图在 $w$ $ \in \left( {0{\rm{ - }}10} \right)$ , 3台的防护流量全部牵引到位.

3)结合1、2得到采用高性能并发拓扑的高性能的WAF方案, 可以实现WAF流量牵引的并发调度, 在第一个调度启动周期后就可以实现并发调度3台主机的并发流量防护, 达到30 mb左右, 因而高性能WAF方案的实现了无任务排队的并发高吞吐量防护.

6 总结

通过改造流量监测方案在流量监测改造上设计的处理步骤自适应机制算法, 在公有云实施测试中有效实现了下游网络处理能力自适应匹配, 减少了监测流量的丢包, 提高了WAF流量监测效率.

通过改造WAF防护拓扑的安全方案: 新加平台策略映射, 新加LB对应引流, 有效绕过传统方案的交换机7750串行处理核心的问题, 通过平台端直接映射策略到设备, 网络侧新加LB将对应映射策略引流. 实现WAF防护控制与承载分离, 由此公有云实施测试中, 证明了可并发用户调度实现方案高吞吐的提升.