腾讯WAF(Web应用防护系统)应用层实现的架构漫谈

前言

作为腾讯公司级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模型优劣势

l 优势

1 、业务维护成本比较低

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

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

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

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

l 劣势

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

1 、webserver种类问题

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

2 、部署问题

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

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

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