TSRC:【门神】WAF应用层实现的架构漫谈

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

WAF的实现有很多种，详情见《主流WAF架构分析与探索》。根据公司的业务特点，我们采用了文中提到的“服务器模块+检测云模式”。 本文主要讲解我们实现此类WAF的后端整体架构与相关技术方案、在具体实现过程中遇到的种种难点问题，以及此类WAF的优劣势分析。 图一、门神整体框架图 整体框架分为在线、离线部分。 在线部分串联在用户访问腾讯网站的整体环节中，门神模块（蓝色部分）包括将http数据转发给门神后端的门神agent、判定http请求是否恶意的门神判定server； 离线部分主要为判定server生成恶意/非恶意规则，以及数据统计、异常数据告警等。 接下来，将对其中最主要的三大模块进行详细介绍： l 用户请求数据转发模块——门神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模块的实现及遇到的困难》   l 用户恶意数据的识别模块——门神判定server 判定server收到用户数据之后，解析http请求数据，划分为uri、args、host、clientip等等字段，进行一些预处理，然后用单个字段或者组合字段匹配恶意规则来判断是否是恶意内容。   【用户请求数据转发模块】与【用户恶意数据的识别模块】为系统在线部分，一旦出现故障将直接影响业务。因此除了功能性的需求，还需要满足后台架构海量服务的一般性需求：   稳定性 程序无core、无死循环。   容灾 一旦后端某些判定server出现故障，门神agent可自动切换连接可用的判定server。 性能 尽可能简化在线处理流程，判定server集群采用以机器为最小处理单元，多进程监听同一端口竞争处理数据的模式，而不是采用传统的“数据转发+后端多进程处理server”的模式。99%的HTTP数据门神判定server在1ms以内可以返回结果。 可扩展 模块功能支持新增：例如增加CC模块加入到在线自动实时拦截。 高可维护性 在线部分逻辑足够简单、高效：在线模块与离线模块低耦合分离(增加门神日志转发server)； 维护高效：一键编译、一键运行、一键功能/性能测试、一键发布 高可运营 添加规则方便、快捷：在web前台添加xml格式的规则，可以实时验证，一键发布到测试环境、灰度正式环境； 系统监控&告警： 门神判定server可用性监控以及异常告警，包括：恶意阻断、非恶意放过、cpu/内存资源监控；业务websrv超时监控和异常告警。   l 恶意数据识别的规则生成——规则管理系统 我们在规则系统前台生成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功能，在网络层阻断恶意用户请求。 最后，由于笔者能力有限，文中提到的种种问题所使用的解决方案可能存在局限，或者可以使用别的方案完全规避这些问题，真诚欢迎业界大牛们给出建议、批评。  

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/