最新消息:

TSRC:主流WAF架构分析与探索

安全知识 admin 1201浏览 0评论

背景:

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

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

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

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

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

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

jinglingshu_2014-07-18_09-11-06

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

优点:

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

挑战:

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

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

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

方案B:反向代理模式

jinglingshu_2014-07-18_09-11-062

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

优点:

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

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

挑战:

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

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

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

方案C:硬件防护设备

jinglingshu_2014-07-18_09-11-061

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

优点:

1、 对后端完全透明。

挑战:

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

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

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

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

我们的探索

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

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

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

jinglingshu_2014-07-18_09-11-063

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

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

1、       维护问题

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

2、       网络架构

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

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

1、       网络延时

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

2、       性能问题:

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

3、       部署问题:

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

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

本文只是一个粗略的简介,我们在建设过程中也遇到了远高于想象的挑战和技术难题,后续将会有系列文章来深入剖析和介绍,希望对大家有所帮助。

转自:http://www.youxia.org/tsrc-waf.html

转载请注明:jinglingshu的博客 » TSRC:主流WAF架构分析与探索


Warning: Use of undefined constant PRC - assumed 'PRC' (this will throw an Error in a future version of PHP) in /usr/share/nginx/html/wp-content/themes/d8/comments.php on line 17
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址