En

WAF建设运营及AI应用实践

作者:[腾讯安全平台部研发安全团队] star公布时间:2020-03-24阅读次数:14909评论:3

分享

作者:[腾讯安全平台部研发安全团队] star

一,前言


WEB应用防火墙(Web Application Firewall,WAF)是当前对Web业务进行防护的一种比较常用且有效的手段之一,目前市场上的WAF产品也相对比较成熟,任何一个小公司或个人都可以借助一些WAF开源项目进行快速部署上线,但是对于大型互联网公司而言,业务众多,网络流量巨大,涉及的域名、服务器资源均属海量,在这个规模下的WAF的设计、研发、运营将会有比较多的现实挑战。

如一般会面临以下几个主要问题:
(1) 业务多且分散,如何降低业务接入成本,快速有效的推动业务覆盖
(2) 作为一个串联系统,如何保证最小程度影响业务性能,保证稳定性需求
(3) 每天需要处理几千亿请求,如何保证检测准确率,降低误报

本文主要讲解下我们实现和解决此类问题的一些WAF建设实践经验,希望与业界同行们进行探讨分享。

二,WAF接入方案和机制


在面对运维职能分散在数十个业务部门的WAF,安全团队不能直接运维的复杂场景下,建设一个有效的WAF接入方案和机制,让业务无需太多介入,对业务架构变动少,对安全团队在推动提升业务WAF覆盖率至关重要。

之前我们也探索了几个方案,一个主要方案是“服务器模块+防护云”,对部署在各个生产服务器上的agent模块只做轻逻辑,负责转发用户请求到防护云的门神处理server,在处理server上做攻击检测逻辑。 



这个方案有以下优势:
(1) 在应对大流量时,可以快速的横向扩展检测防护云处理srv,保证防护有效性
(2) 可以汇总所有HTTP流量,除了在线根据用户行为特征实时检测,还可以做一些离线分析扩展,如聚合统计、CC攻击识别等。

但是,该方案最主要问题在于前端服务器模块agent的适配和部署,公司业务web服务器众多(nginx,apache,nodeJS,自研服务器等),每一种服务器都需要一个版本的agent适配,且如果服务器版本变更就可能需要重新研发; 同时即使最少只需要在服务器一次部署,这需要业务参与涉及到在每台服务器上重新编译重启Web Server,有一定的接入成本,也直接导致了业务整体覆盖难度大。如果业务有扩容但没有按流程部署agent模块,就会出现部分服务器漏防,影响防护有效性。

随着公司技术中台的发展,越来越多的业务接入了公司统一接入层stgw,收敛了分散业务的统一入口,这就非常适合把安全防护能力前移到统一入口,安全团队只需要跟统一接入层stgw团队协商设计交互协议和逻辑,完成入口流量的检测任务,后端业务基本无需介入,大大降低业务接入成本。

这里stgw只负责转发流量到WAF检测,等待WAF返回结果,安全团队专注负责做检测集群云,并且协商以域名纬度控制管理流量转发,业务也以域名纬度接入防护,可以做到一键接入开关防护,且所有策略下发和策略配置管理都在WAF自己的控制台闭环实现。基于这种统一接入层的接入方案,收敛入口集中防护和管理,大大提升了WAF覆盖率。


三,后台架构设计要求


WAF从架构逻辑上来看是串联进业务请求的处理流程中,这就直接对WAF的性能和稳定性提出的更高的要求,一旦本身出现故障将直接影响业务。在满足检测功能性需求,还需要满足后台架构海量服务的要求:
1,稳定性:防护集群采用set化的服务和资源隔离设计,可对业务流量进行轻重分离,避免某些业务流量的突然暴涨影响其它业务的防护效果。

2,性能:防护服务采用IO和检测分离的设计方式,并基于共享内存以零拷贝方式进行数据传递,同时,内部对检测引擎进行多方面的优化,基本保证99%的检测请求能在2ms以内返回检测结果。

3,容灾:一旦后端某些处理server出现故障, 请求可自动切换连接可用的处理server。

4,高可维护性
在线部分逻辑足够简单、高效:在线模块与离线模块低耦合分离;维护高效:一键编译、一键运行、一键功能/性能测试、一键发布

5,高可运营
统一后台策略管理系统,发布变更便捷、规范、快速,可以实时验证。
完善的系统监控&告警:门神处理server可用性监控以及异常告警,包括:恶意阻断、非恶意放过、cpu/内存资源监控;业务websrv超时监控和异常告警。

6,可扩展
模块化功能支持新增:例如增加CC模块加入到在线自动实时拦截等。

在后台日志系统中,引入的ELK分布式日志处理分析系统,可以处理大量&多种数据格式(错误信息、监控、告警),统一化的数据分析处理平台、风险感知平台。分析结果直接展示,方便强大的报表功能,方便数据运营人员做数据分析。

四,检测准确率


在防护能力上,评价一个WAF的好坏要同时看漏报率和误报率。腾讯门神WAF基于数年来的攻防经验沉淀和不断的跟内外部安全研究者的攻防对抗,目前整体防护策略已处于相对较为完备的状态。 


在误报方面,腾讯业务场景多样,各种发布变更频繁,随时可能产生新的误报,需要不断的优化调整策略模型以适应新的误报场景。 首先要求需要能及时有效的主动发现误报发生,这里介绍通过三个纬度来识别误报数据: 



(1) 通过门神WAF的检测云离线架构部分,汇总所有请求数据,建立多维度的误报识别模型,自动识别误报数据
(2) 建立实时告警机制,在发现误报时,通过微信/电话等移动端告警策略运营人员,及时响应处理
(3) 在产品设计上,用户发现误拦截时可以便捷的一键反馈,会默认带上拦截的相关数据供策略运营人员分析,可以直接触达用户端的影响情况,并及时响应处理

基于以上收集的误报数据,策略运营人员不断的精细化迭代优化策略模型,保证在不影响防护能力上,降低误报。

在Web攻击检测发展中,大部分还是传统的基于正则的检测方式,一般是从所有攻击特征提炼出匹配正则,用正则引擎去检测提交的请求是否是可以命中,命中即判为恶意。这种依赖于正则匹配的检测,在面对变化多样的攻击payload就需要不断的补齐规则,规则维护麻烦且易出错,规则越多检测速度越慢影响性能,且基于正则的匹配理论上证明无法完全避免漏报和误报,面对场景多样的Web请求场景,规则策略人员都是在误报和漏报中寻找一个平衡。

当前业界主要也是出现了基于语义分析的检测和基于机器学习的检测两种新方案:
基于语义分析的检测前提是检测类型本身具备规则定义的语义规范,如运用SQL数据库语言的SQL注入攻击,运用JavaScript的XSS攻击。本质是检测当前输入的检测内容是否是符合对应的语法规范,从语义上去理解当前payload是否是攻击。
基于机器学习分为监督学习和无监督学习,监督学习是根据收集标记的黑白样本,训练出一个检测模型来做预测,无监督学习采用建立正常流量模型,不符合模型的流量识别为恶意,两种方式可能由于样本的不足或特征选取问题,导致漏判或误判,加上不同的算法选择可能会带来更长的延迟,有的可能只在旁路离线跑做为离线数据分析用,还不适合线上实时拦截运行。

腾讯门神WAF也在不断探索实现新的检测方案,这里介绍一种结合语法分析+机器学习的检测方案的demo实现,结合语法分析和机器学习的优势来提高检测准确率。

以XSS攻击检测为例,基本思路是先分析提取payload的JS内容,判断是否是合法的JS标准的语句片段,再通过机器学习算法进行打分评判。


主要介绍下一个实现的几个主要模块作用:

1, 检测流量初筛
从线上运营数据来看,每日请求中正常流量和恶意流量比例大概在10000:1,可以先过滤掉大部分绝对正常的流量,来压缩检测流量,提高检测效率。这里可以采用多种方式过滤掉正常流量,如先过滤掉公司自己的出口IP,再过敏感攻击特征关键字进行字符串匹配(字符串匹配相较正则匹配速度快),筛选出疑似攻击流量走后续流程。

2,请求预处理
和传统WAF实现类似,需要先对请求进行一些解析解码预处理。
解析处理:对http请求按协议规范解析提取出各个字段字段的Key-Value,包括json的一些特殊处理等。
解码处理:避免payload通过各种编码绕过检测(如URL编码,URL多重编码,base64编码,unicode编码,html实体编码等),通过解码阶段处理最终还原出原始payload,再输出给后面模块处理。

3,词法和语法分析
提到词法语法分析就是涉及到编译原理基础知识,这里介绍一个解析生成器Antlr4,可以根据需求编写文法,描述我们要解析的语言语法,antlr4会自动生成词法分析器和语法分析器。(flex/bison类似)

词法分析:读入源程序,识别出单词,并用记号token方式表示识别出的单词
语法分析:在词法分析的基础上,根据语言的语法规则,把单词符号串组成各类语法单位,即在单词流的基础上建立一个层次结构-语法树。

如Payload:


经过解析解码处理,对html内容进行解析,提取JS内容,包括:script标签内,on事件内,src/href, data-uri base64编码等,进行词法分析:

再经过语法分析,同时注意支持到最新版本的ECMAScript,以处理更多的场景:


4,基于机器学习的打分评判
经过前面语法分析检测以后,已经知道一个payload是否符合JavaScript语法,但是还不一定是真正的攻击语句,需要再经过一个算法打分来最终评判危害程度。 


目前基础的机器学习算法都相对较为成熟,这里选取以基于HMM算法来做payload评分为例,关于HMM的原理可以查看相关书籍。HMM的基础假设:一个连续的时间序列事件,它的状态受且仅受它前面的N个事件决定,对应的时间序列可以成为N阶马尔科夫链。 


一般简单的打分思路可以采用计算payload里面敏感词出现次数和权重算法,但仅是判断有无,会有比较多的误判,基于攻击语句的特征,加上考虑上特征出现的顺序,通过样本学习,计算出现概率,判断是否为恶意,区别于传统规则系统的非黑即白的简单判断,可以根据场景调整分值区分恶意程度,根据阀值做实际拦截动作。 

 
特征工程方面:对payload根据XSS攻击模式进行分词,应用专家经验知识干预和特征提取技巧进行特征化,如可以采用基于词集模型编码(参考兜哥《web安全之机器学习》) 


样本训练方面,基于腾讯海量正常流量和人工打标的恶意攻击流量,建立了丰富高质量的黑白样本库。最终测试攻击检出率可以达到99%,同时误报率控制在0.03%以下。

做了一个简单的demo接口,输出风险情况和完整的语法树结构: 



腾讯安平门神WAF一直在探索一些新的检测方案,并搭建了靶场环境部署新的门神WAF智能引擎检测,进行为期一个月的安全众测,欢迎各位业界同仁测试拍砖。

发现绕过可通过TSRC平台提交,或联系TSRC工作人员。

众测时间、挑战环境、判定标准、规则要求相关细节,点击链接:https://security.tencent.com/index.php/announcement/msg/189进行了解。


五,WAF扩展,进一步发挥更大作用


WAF产品除了能完成自身的主要防护功能外,还可以结合自身特点优势和其他安全产品联动在安全防护体系中发挥更大的作用。如:
1, WAF所处的网络位置有天然的数据优势,可以作为一个7层流量分析平台,实现业务自定义建模分析,感知和解决一些特定场景的风险问题。比如我们内部有的业务安全团队对流量进行分析,然后使用WAF阻断恶意攻击者;门神也提供开放平台,支持由业务团队来制定阻断策略;
2, 与扫描器联动,实时采集测试环境数据提交扫描器,被动式扫描;
3, 与威胁情报、日志分析、蜜罐系统联动等等。

六,总结


WAF可以看成是Web业务抵挡攻击的第一道防线,也是企业安全体系建设的一个重要环节。安全是处于长期动态发展的过程,保持敬畏和进步才能在攻防中争取到主动。同时,安全是一个整体,强大的腾讯蓝军、TSRC、反入侵等兄弟团队为Web应用防火墙“门神”、 Web漏洞扫描系统”洞犀”和终端漏洞扫描系统“金刚”能力优化提供了非常宝贵的信息支持和帮助,向战友们致敬。

本文部分内容只做了一个粗略的概述,我们在建设过程中也遇到了远高于想象的挑战和技术难题,后续将会有相关文章来深入剖析和介绍,欢迎大家关注。笔拙表述不当或存在错误之处,欢迎交流指正,也欢迎志同道合的伙伴们加入腾讯安全平台部大家庭。最后,感谢harite、wancheng、online、baohu在成文过程中提供的帮助和建议。  

评论留言

提交评论 您输入的漏洞名称有误,请重新输入