腾讯门神:WAF应用层实现的架构漫谈

前言


作为腾讯公司级webserver的漏洞防护系统,目前腾讯门神系统(以下简称门神)已经涵盖了近万台webserver服务器,日均处理HTTP数据包达数百亿。


WAF
的实现有很多种,详情见《主流WAF架构分析与探索》。根据公司的业务特点,我们采用了文中提到的“服务器模块+检测云模式”。


本文主要讲解我们实现此类WAF的后端整体架构与相关技术方案、在具体实现过程中遇到的种种难点问题,以及此类WAF的优劣势分析。


门神整体框架

 

图一、门神整体框架图


整体框架分为在线、离线部分。


在线部分串联在用户访问腾讯网站的整体环节中,门神模块(蓝色部分)包括将http数据转发给门神后端的门神agent、判定http请求是否恶意的门神判定server;


离线部分主要为判定server生成恶意/非恶意规则,以及数据统计、异常数据告警等。


接下来,将对其中最主要的三大模块进行详细介绍:

用户请求数据转发模块——门神agent


我 们在业务webserver程序中添加了一个门神agent模块,当用户请求页面时,业务webserver解析完http请求包后首先调用门神 agent已注册的入口api,agent会按照一定的负载均衡算法获取处理srv ip、port,再将http请求头、请求body、用户ip等数据通过udp、tcp的方式转发给门神判定server。


此模块的难点问题在于:公司业务webserver种类繁多,难道我们需要为每一种webserver做一个适配的agent模块?


我们的方案是为主流webserver提供统一的agent模块,例如apache、nginx;为自研的websrv提供协议解包封包api,由业务完成socket通信;在非主流webserver在前端添加一个nginx代理转发,代理层添加门神agent模块。


此模块实现的难点在于:相对于apache的多进程同步机制,nginx的异步机制决定了agent模块要复杂得多,它要求模块必须也是异步的,包括获取body数据的异步以及门神处理srv的异步。


Nginx
开源模块中并没有现成的样例,经过了我们对nginx源码研究以及多次版本(包括前期使用开源mtask模块,到最后自研)迭代才解决全异步问题。具体实现方式可见后续文章《门神-nginx模块的实现及遇到的困难》

 

用户恶意数据的识别模块——门神判定server


判定server收到用户数据之后,解析http请求数据,划分为uri、args、host、clientip等等字段,进行一些预处理,然后用单个字段或者组合字段匹配恶意规则来判断是否是恶意内容。

 

【用户请求数据转发模块】与【用户恶意数据的识别模块】为系统在线部分,一旦出现故障将直接影响业务。因此除了功能性的需求,还需要满足后台架构海量服务的一般性需求:

 

稳定性

程序无core、无死循环。

 

容灾

一旦后端某些判定server出现故障,门神agent可自动切换连接可用的判定server。


性能

尽可能简化在线处理流程,判定server集群采用以机器为最小处理单元,多进程监听同一端口竞争处理数据的模式,而不是采用传统的“数据转发+后端多进程处理server”的模式。99%的HTTP数据门神判定server在1ms以内可以返回结果。


可扩展

模块功能支持新增:例如增加CC模块加入到在线自动实时拦截。


高可维护性

在线部分逻辑足够简单、高效:在线模块与离线模块低耦合分离(增加门神日志转发server);

维护高效:一键编译、一键运行、一键功能/性能测试、一键发布


高可运营

添加规则方便、快捷:在web前台添加xml格式的规则,可以实时验证,一键发布到测试环境、灰度正式环境;

系统监控&告警:

门神判定server可用性监控以及异常告警,包括:恶意阻断、非恶意放过、cpu/内存资源监控;业务websrv超时监控和异常告警。

 

恶意数据识别的规则生成——规则管理系统


我们在规则系统前台生成xml规则文件,通过下发命令的方式通知所有门神判定server动态加载规则,简要流程如下:

 

图二、规则下发流程


规则的生成主要包括两种途径:

 

1、收集业界web漏洞,包括0day,转化为可以防御的规则;

2、由漏报分析系统根据松散规则(准确性50%左右),提炼出可能的漏报,人工分析将真正的漏报转化为防御规则;


此WAF模型优劣势

 

优势


1
、业务维护成本比较低

       一次部署后,所有恶意判定逻辑变化引起的规则、程序变更都在后端进行,业务侧基本上不用做任何更新。

       在业务侧的门神agent逻辑足够简单,基本上不会对业务的性能、功能产生影响。


2
、防护的漏洞种类比较齐全

       此WAF模型会将所有HTTP数据汇总,可以用户的行为特征来判定请求是否恶意,例如我们的恶意拉取识别模块,可以防止CC攻击等恶意行为。

 

劣势


与业界的waf方案相比较,我们这种方案也有它的劣势,例如:

 

1、webserver种类问题

需要适配主流最新webserver,webserver的版本一旦做重大更新或者出现一种新的流行webserver,我们的门神agent可能就需要重新研发。由于业务的复杂性,可能需要迭代多次版本才稳定下来,例如nginx门神模块,迭代了16个版本才最终稳定;

 

2、部署问题

需要业务进行部署,可能会涉及到重编译webserver等工作量,有一定的成本,并且当涉及到数千个域名时,问题变的更为复杂。

针对这些劣势,除了此类WAF,我们也尝试使用其它模式来平衡它的缺陷,例如在宙斯盾系统中也添加了WAF功能,在网络层阻断恶意用户请求。


最后,由于笔者能力有限,文中提到的种种问题所使用的解决方案可能存在局限,或者可以使用别的方案完全规避这些问题,真诚欢迎业界大牛们给出建议、批评。

【via@腾讯安全