中神通公司技术论坛 - Powered by Discuz! Board

标题: TSRC：主流WAF架构分析与探索 [打印本页]

作者: linda 时间: 2014-12-19 18:56 标题: TSRC：主流WAF架构分析与探索

http://www.valleytalk.org/2014/07/18/tsrc%EF%BC%9A%E4%B8%BB%E6%B5%81waf%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90%E4%B8%8E%E6%8E%A2%E7%B4%A2/

背景：
网站安全漏洞在被发现后，需要修复，而修复需要时间，有些厂商可能无能力修复，甚至部分网站主可能连是否存在漏洞都无法感知（尤其是攻击者使用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服务器等工作量，有一定的成本。并且当涉及到数千个域名时，问题变的更为复杂。可能需要区分出高危业务来对部署有一个前后顺序，并适时的通过一些事件来驱动部署。
最后，我们目前已灰度上线了这套防御方案，覆盖重要以及高危的业务站点。目前日均处理量约数百亿的规模，且正在快速增长阶段。
本文只是一个粗略的简介，我们在建设过程中也遇到了远高于想象的挑战和技术难题，后续将会有系列文章来深入剖析和介绍，希望对大家有所帮助。
作者：腾讯安全应急响应中心那个谁

欢迎光临中神通公司技术论坛 (http://trustcomputing.com.cn/bbs/)