背景：

网站安全漏洞在被发现后，需要修复，而修复需要时间，有些厂商可能无能力修复，甚至部分网站主可能连是否存在漏洞都无法感知（尤其是攻击者使用0day的情况下）。或者刚公开的1day漏洞，厂商来不及修复，而众多黑客已经掌握利用方法四面出击，防不胜防。这个时候如果有统一集中的网站防护系统（WAF）来防护，则漏洞被利用的风险将大大降低，同时也为漏洞修复争取时间！

笔者所在公司的业务较多，光域名就成千上万，同时网络流量巨大，动辄成百上千G。而这些业务部署在数十万台服务器上，管理运维职能又分散在数十个业务部门，安全团队不能直接的管理运维。在日常的安全管理和对抗中，还会经常性或者突发性的遇到0day需要响应，比如更新检测引擎的功能和规则，这些都是比较现实的挑战。

对于WAF的实现，业界知名的网站安全防护产品也各有特色。本文将对主流的WAF架构做一个简单的介绍，和大家分享下。同时结合笔者所在公司业务的实际情况，采用了一种改进方案进行探索，希望本文能达到抛砖引玉的效果。(不足之处请各位大牛多多指教)

特别声明：以下方案无优劣之分，仅有适合不适合业务场景的区别。

业界常见网站安全防护方案

方案A：本机服务器模块模式

通过在Apache，IIS等Web服务器内嵌实现检测引擎，所有请求的出入流量均先经过检测引擎的检测，如果请求无问题则调用CGI处理业务逻辑，如果请求发现攻击特征，再根据配置进行相应的动作。以此对运行于Web服务器上的网站进行安全防护。著名的安全开源项目ModSecurity及naxsi防火墙就是此种模式。

优点：

1、网络结构简单，只需要部署Web服务器的安全模块

挑战：

1、维护困难。当有大规模的服务器集群时，任何更新都涉及到多台服务器。

2、需要部署操作，在面临大规模部署时成本较高。

3、无集中化的数据中心。针对安全事件的分析往往需要有集中式的数据汇总，而此种模式下用户请求数据分散在各个Web服务器上。

方案B：反向代理模式

使用这种模式的方案需要修改DNS，让域名解析到反向代理服务器。当用户向某个域名发起请求时，请求会先经过反向代理进行检测，检测无问题之后再转发给后端的Web服务器。这种模式下，反向代理除了能提供Web安全防护之外，还能充当抗DDoS攻击，内容加速（CDN）等功能。云安全厂商CloudFlare采用这种模式。

优点：

1、集中式的流量出入口。可以针对性地进行大数据分析。

2、部署方便。可多地部署，附带提供CDN功能。

挑战：

1、动态的额外增加一层。会带来用户请求的网络开销等。

2、站点和后端Web服务器较多的话，转发规则等配置较复杂。

3、流量都被捕捉，涉及到敏感数据保护问题，可能无法被接受。

方案C：硬件防护设备

这种模式下，硬件防护设备串在网络链路中，所有的流量经过核心交换机引流到防护设备中，在防护设备中对请求进行检测，合法的请求会把流量发送给Web服务器。当发现攻击行为时，会阻断该请求，后端Web服务器无感知到任何请求。防护设备厂商如imperva等使用这种模式。

优点：

1、对后端完全透明。

挑战：

1、部署需改变网络架构，额外的硬件采购成本。

2、如Web服务器分布在多个IDC，需在多个IDC进行部署。

3、流量一直在增加，需考虑大流量处理问题。以及流量自然增长后的升级维护成本。

4、规则依赖于厂商，无法定制化，不够灵活。

我们的探索

笔者所在的公司在不同的场景下，也近似的采纳了一种或者多种方案的原型加以改进使用运营。（比如方案C，其实我们也有给力的小伙伴做了很棒的努力，通过自研的方式解决了不少挑战，以后有机会或许也会和大家分享一些细节）

今天给大家介绍的，是我们有别于业界常见模型的一种思路：

方案D：服务器模块+检测云模式

这种模式其实是方案A的增强版，也会在Web服务器上实现安全模块。不同点在于，安全模块的逻辑非常简单，只是充当桥梁的作用。检测云则承担着所有的检测发现任务。当安全模块接收到用户的请求时，会通过UDP或者TCP的方式，把用户请求的HTTP文本封装后，发送到检测云进行检测。当检测无问题时，告知安全模块把请求交给CGI处理。当请求中检测到攻击特征时，则检测云会告知安全模块阻断请求。这样所有的逻辑、策略都在检测云端。

我们之所以选择这个改进方案来实现防护系统，主要是出于以下几个方面的考虑：

1、维护问题

假如使用A方案，当面临更新时，无法得到及时的响应。同时，由于安全逻辑是嵌入到Web服务器中的，任何变更都存在影响业务的风险，这是不能容忍的。

2、网络架构

如果使用方案B，则需要调动大量的流量，同时需要提供一个超大规模的统一接入集群。而为了用户就近访问提高访问速度，接入集群还需要在全国各地均有部署，对于安全团队来说，成本和维护难度难以想象。

使用该方案时，需要考虑如下几个主要的挑战：

1、网络延时

采用把检测逻辑均放在检测云的方式，相对于A来说，会增加一定的网络开销。不过，如果检测云放在内网里，这个问题就不大，99%的情况下，同城内网发送和接收一个UDP包只需要1ms。

2、性能问题：

由于是把全量流量均交给集中的检测云进行检测，大规模的请求可能会带来检测云性能的问题。这样在实现的时候就需要设计一个好的后端架构，必须充分考虑到负载均衡，流量调度等问题。

3、部署问题：

该方案依然需要业务进行1次部署，可能会涉及到重编译web服务器等工作量，有一定的成本。并且当涉及到数千个域名时，问题变的更为复杂。可能需要区分出高危业务来对部署有一个前后顺序，并适时的通过一些事件来驱动部署。

最后，我们目前已灰度上线了这套防御方案，覆盖重要以及高危的业务站点。目前日均处理量约数百亿的规模，且正在快速增长阶段。

主流WAF架构分析与探索相关推荐

（8）web安全|渗透测试|网络安全常见的站点搭建类型分析，子域名爆破，旁注等，WAF防护分析及绕过，wafwoof工具的安装和使用
常见的站点搭建习惯分析目录型站点主站上的其他文件夹上对应着其他的cms程序,找漏洞思路: 主站的漏洞: 站上其他程序的漏洞例如:某网站通过后台扫描发现有一个bbs目录,点击发现是一个bbs的论坛 ...
中国开源年会报名 | StarRocks 极速湖仓分析的探索与实践
开源年度盛会 2022 第七届中国开源年会 (COSCon'22) 来啦! 本次年会将于 10 月 29-30 日由开源社举办,线上共设有1个主论坛和16个分论坛,线下分会场遍布成都.深圳.上海.北京 ...
大型网站系统架构分析--转
大型网站系统架构分析原文地址:http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html 千万级的注册用户,千万级的帖子,nTB级的附件 ...
【完结】总结12大CNN主流模型架构设计思想
文章首发于微信公众号<有三AI> [完结]总结12大CNN主流模型架构设计思想专栏<CNN模型解读>正式完结了,在这一个专栏中,我们给大家回顾了深度学习中的各类具有代表性的C ...
基于React的PC网站前端架构分析
代码地址如下: http://www.demodashi.com/demo/12252.html 本文适合对象有过一定开发经验的初级前端工程师: 有过完整项目的开发经验,不论大小: 对node有所了 ...
从上到下的系统架构分析方法 - Intel PMU
来源:内核月谈 layout: Top-down Microarchitecture Analysis Method 原文链接 1,https://www.intel.com/content/dam/ ...
百度红包架构分析与推测
百度红包架构分析与推测本文是笔者根据百度今年红包活动运行状况,对于红包内部架构的推测,并非百度具体架构. 2019年百度春晚期间请求量总计在209亿次,其中峰值主要集中在春晚期间四次互动红包活动,预 ...
b2c项目基础架构分析（一）b2c 大型站点方案简述已补充名词解释
b2c项目基础架构分析(一)b2c 大型站点方案简述已补充名词解释我最近一直在找适合将来用于公司大型bs,b2b b2c的基础架构. 实际情况是要建立一个bs架构b2b.b2c的网站,当然还包括w ...
b2c项目基础架构分析（二）前端框架以及补漏的第一篇名词解释
b2c项目基础架构分析(二)前端框架以及补漏的第一篇名词解释继续上篇,上篇里忘记了也很重要的前端部分,今天的网站基本上是以一个启示页,然后少量的整页切换,大量的浏览器后台调用web服务局部.动态更 ...

主流WAF架构分析与探索

背景：