高性能公有云WAF安全方案①

何 丹,张 悦

1(中移(苏州)软件技术有限公司 云计算产品部,苏州 215000)

2(中移(苏州)软件技术有限公司 大数据产品部,苏州 215000)

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 设备来防护清洗.

图1 云内WAF 防护

2 业界WAF 方案分析

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

2.1 流量监测现状

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

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

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

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

图2 WAF 流量解析过程

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

2.2 引流拓扑现状

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

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

图3 流量牵引

3 流量监测改造

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

3.1 流量统计监测

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

图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 个处理步骤采用线程,通过动态化的线程组,进行实现动态能力自动调节.

图5 高性能流量监测流程

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)的算法进行决策执行.

图6 处理模块之间交互

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 常规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，具体思路提出如下.

图8 SDN 引流改造

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.

图9 测试模型

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

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

图10 流量监测效率对比

实验仿真测试结果验证思路为验证流量统计和实际流量偏移量,w 为统计时间.其中为 s (w)高性能监控算法监控统计流量,u(w)为常规算法监控统计流量.θ1 、θ 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 ∈(0-1)偏差的监测数据包因为传统方案无动态自增处理能力机制而大量丢包.1 s 时刻手动增加传统方案监测资源能力,才慢慢在3.2 s 时刻监测足够数据.

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

图11 防护吞吐量对比

5.2 实验防护吞吐量

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

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

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

实验2 结果分析:

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

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

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

6 总结

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

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