腾讯门神系统整体架构与相关技术方案介绍

作为腾讯公司级的漏洞防护系统，腾讯门神系统（以下简称门神）目前覆盖近万台服务器，平均每天处理数百亿个HTTP数据包。

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

本文主要讲解实现该类型WAF的整体后端架构及相关技术方案，具体实现过程中遇到的各种难点，以及该类型WAF的优缺点分析。

门神整体框架

图1 守门员整体框架图

整体框架分为线上和线下两部分。

线上部分串联于用户访问腾讯网站的整个流程。 门神模块（蓝色部分）包括将http数据转发给门神后端的门神代理和判断http请求是否恶意的门神判断；

离线部分主要生成恶意/非恶意规则进行判定，以及数据统计、异常数据报警等。

接下来详细介绍其中最重要的三个模块：

l 用户请求数据转发模块——门神代理

我们在业务程序中增加了门神代理模块。 当用户请求页面时，业务解析http请求包后，首先调用门神代理注册的入口API。 Agent会根据一定的负载均衡算法获取并处理srv ip和port。 然后将http请求头、请求体、用户IP等数据通过udp、tcp转发给门卫进行判断。

该模块的难点在于：公司业务类型很多，是否需要针对每种类型做一个适配的代理模块？

我们的解决方案是为主流提供统一的代理模块，比如nginx； 为自研的提供协议解包和封包api，由业务完成通信； 对于非主流，在前端添加nginx代理转发，在代理层添加门神代理模块。

该模块实现的难点在于，相比于nginx的多进程同步机制，nginx的异步机制决定了agent模块要复杂很多。 它要求模块也必须是异步的，包括异步采集车身数据、异步处理门神srv。

Nginx开源模块中没有现成的示例。 我们研究了nginx源码和多个版本（包括早期使用开源mtask模块和最终自研）才解决了完全异步的问题。 具体实现方法可以参见后续文章《门神-nginx模块的实现及遇到的难点》

l 用户恶意数据识别模块——门神审判

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

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

稳定

该程序没有核心，也没有无限循环。

灾难恢复

一旦某些后端判断失败，守门员代理可以自动切换到可用的判断。

表现

为了尽可能简化在线处理流程，决策集群采用一台机器作为最小处理单元，多个进程监听同一端口竞争数据处理，而不是采用传统的“数据转发+后端多进程”的方式。过程处理”模型。 99%的HTTP数据可以在1ms内返回结果。

可扩展

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

高可维护性

线上部分的逻辑足够简单、高效：线上模块和离线模块分离，耦合度低（增加门神日志转发）；

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

高度可操作性

添加规则方便快捷：在Web前台添加XML格式的规则，可实时验证并一键发布到测试环境和灰度正式环境；

系统监控报警：

门神判定可用性监控和异常报警，包括：恶意阻塞、非恶意出租、CPU/内存资源监控； 业务超时监控及异常报警。

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

我们在规则系统前台生成xml规则文件，通过下发命令通知所有门神确定动态加载规则。 简要流程如下：

图2 规则发布流程

生成规则主要有两种方式：

1、收集行业Web漏洞，包括0day，并将其转化为可防御的规则；

2、误报分析系统根据松散规则提取可能的误报（准确率约50%），人工分析将真实的漏报转化为防御规则；

这种WAF模型的优点和缺点

l 优势

1、业务维护成本相对较低

一次部署后，所有因恶意判定逻辑变化而导致的规则和程序变更都在后端进行，业务侧基本不需要做任何更新。

业务侧的门代理逻辑足够简单，基本不会影响业务的性能和功能。

2、保护的漏洞类型比较齐全。