注册
登录
标签
统计
帮助
中神通公司技术论坛
»
应用过滤
»
WEB审计过滤(WAF)
» TSRC:主流WAF架构分析与探索
‹‹ 上一主题
|
下一主题 ››
发新话题
发布投票
发布商品
发布悬赏
发布活动
发布辩论
发布视频
打印
TSRC:主流WAF架构分析与探索
linda
琳达
版主
发短消息
加为好友
当前离线
1
#
大
中
小
发表于 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服务器等工作量,有一定的成本。并且当涉及到数千个域名时,问题变的更为复杂。可能需要区分出高危业务来对部署有一个前后顺序,并适时的通过一些事件来驱动部署。
最后,我们目前已灰度上线了这套防御方案,覆盖重要以及高危的业务站点。目前日均处理量约数百亿的规模,且正在快速增长阶段。
本文只是一个粗略的简介,我们在建设过程中也遇到了远高于想象的挑战和技术难题,后续将会有系列文章来深入剖析和介绍,希望对大家有所帮助。
作者:腾讯安全应急响应中心 那个谁
搜索更多相关主题的帖子:
WAF
UID
123
帖子
1821
精华
5
积分
50
阅读权限
100
在线时间
760 小时
注册时间
2013-8-15
最后登录
2024-10-24
查看详细资料
TOP
‹‹ 上一主题
|
下一主题 ››
最近访问的版块 ...
通知公告
产品下载
大地云控
官方发布
通知公告
产品下载
购买咨询
技术讨论
系统管理
系统管理
状态统计
访问控制
基础策略
内置服务
网络设置
应用过滤
特殊应用
网络审计
WEB审计过滤(WAF)
DNS过滤
WEB代理及过滤
FTP、POP3、SMTP过滤
MSN、QQ过滤
VOIP应用
防病毒、防垃圾邮件引擎
入侵防御
蜜罐检测
IDP规则及IPS状态
远程接入
用户认证
IKEv2/IPsec
OCSERV
PPTP/L2TP
OpenVPN/SSLVPN
WireGuard
SoftEther/SSTP
SSL接入
大地云控
IT技术交流
硬件选型
虚拟化&云计算&SDN&NFV
真实IT经验
灌水聊天
同行动态
行业信息
龙门阵