【.COM 独家翻译】大概十年前,Web应用防火墙(WAF)进入了IT安全领域,最早提供这类产品的供应商是几家新兴公司,如Perfecto(曾改名为Sanctum,后在2004年被WatchFire收购)、KaVaDo(2005年被Protegrity收购)和NetContinuum(2007年被Barracuda收购)。工作原理相当简单:随着攻击范围向IP堆栈的上层移动,瞄上针对特定应用的安全漏洞,这时势必需要开发旨在识别和预防这些攻击的产品。虽然网络防火墙在阻止较低层攻击方面很有效,但并不擅长解开IP数据包层,以分析较高层协议;这就意味着,网络防火墙缺少应用感知功能,而要关闭自定义Web应用中的漏洞窗口,就需要这种功能。
创新互联建站专业为企业提供疏勒网站建设、疏勒做网站、疏勒网站设计、疏勒网站制作等企业网站建设、网页设计与制作、疏勒企业网站模板建站服务,十载疏勒做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
但是尽管WAF炒得很火,供应商承诺的优点也很多,但最终用户的使用体验却相当差。早期产品存在诸多缺点,比如误报率高,给受保护应用的性能带来负面影响,又很难有效地管理。2005年前后,包括思科、思杰和F5在内的大牌网络供应商或收购或开发了Web层监控技术,WAF随之成为一道公认的边界安全防线。促使WAF得到主流用户采用的另一个因素是,出台了支付卡行业数据安全标准(PCI-DSS),该标准在第6.6项需求中明确要求使用具有应用层感知功能的防火墙。
如今,WAF已是IT安全工具箱中一个公认的组成部分。但许多企业仍在为这个问题而纠结:该买哪一种WAF、如何最合理地把它们集成到Web应用风险管理产品系列中。本文分析了采购WAF方面一些主要的决策因素,并给出了相应的建议,以便确保它们很适合企业架构和网络生态系统。
架构和物理尺寸
WAF应该适合于现有的架构,并采用得到安全操作团队接受和支持的物理尺寸。WAF放置方面主要有两种架构方案可以考虑:桥接模式(in-line)或分接/跨接模式(tap/span)。
·桥接模式:在这种架构(又叫主动配置)中,WAF就直接放在请求方(如浏览器客户端)与Web应用服务器之间的流量路径当中。WAF在检查应用请求和响应之后再传送请求和响应。
在桥接模式里面,WAN到底采用哪一种方法来传送流量,企业可以作出众多选择。网络方面的选择有:路由器(3层)、网桥(2层)和HTTP反向代理系统。WAF还可以直接在主机服务器(Web应用驻留在上面)上使用,这种WAF名为基于主机的WAF或嵌入式WAF。使用网桥模式的WAF可能不需要改动网络,但流量必须定向至路由器或反向代理模式中的WAF。
要选择一种最佳模式,先要评估一下目前网络上的Web应用是如何构建的:该应用是不是已经在反向代理系统的后面?如果是这样,企业又想继续使用反向代理架构,可以考虑支持这种需要的WAF。如果企业要求WAF终结SSL连接,以检查数据包内容,那么反向代理系统是个理想的选择。不过,在一路发送数据包内容之前终结连接(无论是不是SSL连接)的确需要处理能力,所以需要对这种模式进行造型和测试,确保不会带来让人无法接受的延迟。
桥接式WAF经配置后,可以主动阻止违反WAF规则集的请求和流量。这项功能很有用,但使用要慎重--要是桥接式WAF过于主动地阻止,就会阻止合法流量进入到Web服务器,因而导致应用无法使用。在制定任何主动阻止规则之前,先要进行全面测试,确保生产环境中不会出现服务意外受到干扰的情况。另外,可以以桥接方式使用WAF,但要让它处于纯监控(或被动)模式。
架构方面要考虑的另一个因素是,将安装和管理多少个WAF。如果需要WAF用于多个场合,那不妨考虑支持分布式管理或分布式WAF的解决方案。在这种模式下,可使用中央控制台来管理用于多个场合的防火墙。可以针对所有WAF统一运用规则或设置;也可以根据每个WAF的情况,逐个运用规则集,具体取决于WAF在保护哪一种Web应用。 #p#
优点 |
缺点 |
•能防止实时攻击 |
•Web应用的流量速度 可能会减慢 •合法流量可能被阻止 |
表格1:桥接式WAF的优缺点
分接/跨接模式:这种模式又叫"被动"模式,因为WAF被挡在流量路径外面,从分接端口或跨接端口监控流量。分接/跨接式WAF常常用于收集数据,以便之后用于调查或取证分析。这种架构模式的一个主要优点是,它并不干扰网络流量或吞吐量,因为它不是直接嵌入。而另一方面,不在流量路径当中意味着,这种解决方案无法执行主动的桥接式WAF所能执行的那种阻止操作。不过,支持某些形式的阻止操作,比如连接重置,或者通过联系到另一个系统(如网络防火墙),然后让该系统执行阻止操作。
优点 |
缺点 |
•非侵入性 •不干扰流量 |
•无法阻止实时流量 |
图2:分接/跨接式WAF的优缺点
·新的变化:两个重要变化在促使企业需要WAF使用新的架构模式,这两个变化就是云计算和虚拟化。基于云的WAF先拦截流量,然后允许合法流量进入到企业网络;或者对于在云环境也有Web应用的公司来说,允许合法流量通过云进入到服务器。虚拟化环境带来了一个独特的挑战,因为在虚拟机管理程序上运行的虚拟机构成了自己的小型网络;在这个网络中,流量从一虚拟服务器传送到另一虚拟服务器,没必要通过网络传送。为了防止虚拟机内部出现应用攻击,WAF需要能够查看流量。使用应用编程接口(API)或其他服务,通过虚拟机管理程序来监控活动,就能做到这一点。
·物理尺寸:探讨一下WAF如何捆绑和销售给客户的问题。许多WAF支持多种物理尺寸选择,所以企业不需要为购买硬件设备而大伤脑筋,只要独立软件开发商(ISV)的软件得到批准。换句话说,选择什么物理尺寸的硬件取决于贵企业最习惯于什么。选择包括:
◆纯软件--硬件由采购部门负责提供
◆设备--软件与专门针对WAF进行选型和调整的设备捆绑销售
◆硬件--WAF智能直接嵌入在硬件本身里面
◆主机--这是一种软件方案,但软件安装在运行Web应用的同一台服务器上,而不是安装在单独的主机或虚拟机上。
检测技术
刚才已讨论了架构和物理尺寸问题,现在要问一下这个问题:WAF如何检测Web应用中的漏洞以及针对Web应用的攻击?WAF的目的是智能地保护Web应用,所以拥有细粒度规则和检测机制很要紧。大多数WAF采用结合不同检测技术的方法,确保检测范围最广泛、结果最准确。除了问供应商使用哪些检测技术外,还要让供应商出示证明误报率/漏报率的依据以及第三方测试结果,以便更清楚地了解WAF在实际使用时效果会有多好。下面是一些检测技术,以及向最后选出来的几家产品供应商询问的几个问题:
·特征:与为反恶意软件和网络入侵检测系统(IDS)编写的特征很相似,WAF特征也将预定字符串或正则表达式(RegEx)与流量进行匹配,以查找已知攻击。
该产品在交付时随带一套特征吗?#p#
供应商每隔多久更新特征?
·规则:规则在特征概念的基础上更进了一步,它可以用逻辑"与"运算符把一系列字符串联系起来,用"或"运算符添加更复杂的匹配机制,或者用"非"运算符实现"排斥"功能。还可以设定规则,寻索非常特定的字符串类型,就像16位号码(比如信用卡号),作为来自Web服务器的响应而发送。一些WAF能够动态"学习"流量模式,根据一套基准规则来查找异常行为。"学到"的信息可以发送给管理员,提议针对WAF或互补性保护设备(如IDS或网络防火墙)设定什么样的新规则。
供应商提供基准规则吗?
客户能够手动添加新规则吗?
WAF能够动态"学习"新规则吗?
◆规范化:攻击者的一种惯用手法是,对漏洞的有效载荷做手脚,冒充没有危害的内容(比如对有效载荷的一部分进行URL编码),从而避开WAF的检测。为了检测出这种攻击,WAF就要能够对请求进行规范化处理,以便进行分析。以下是仅仅几个规范化机制--完整清单请参阅Web应用安全联盟Web应用防火墙评估标准的第3.1章节。
WAF能够对转义字符或编码字符(如t、01、%2C、xAA和uAABB)进行规范化吗?
使用自引用路径(即使用/./和等效的编码方案)吗?
使用混合大小写和国际字符集吗?
◆API:如果企业想自行开发自定义检测技术或规则,以便进行特别评估,比如逻辑检查,可以通过API来做到这点。咨询一下供应商,看看对方是否的确支持API;如果支持,这些API与WAF分析引擎的集成又有多紧密?
WAF有API吗?
API与WAF引擎的集成有多紧密?
供应商为自定义插件提供哪一种支持?
其他考虑因素
◆高可用性和高吞吐量:如果WAF在流量很大的环境下,它应该能够在不减慢Web应用速度的情况下,处理庞大流量,如果它是桥接式WAF更要有这种功能。如果一个WAF或Web应用失效或超过安全界限,WAF就得支持故障切换,与负载均衡器共同防止服务受到干扰。一些WAF与高可用性设备紧密集成,可作为Web流量管理系统的组件来运行。如果是独立式WAF,就要确保它们满足贵公司的高可用性需求,以便同时符合性能和架构方面的要求。
WAF能与现有的高可用性/负载均衡设备兼容吗?
WAF在不丢失流量或流量丢失有限的情况下支持故障切换吗?
WAF能支持多大的流量?#p#
受保护应用的性能有没有出现任何延迟?
添加新的/复杂的规则后,性能有没有因而下降?
◆日志和报告:作为Web应用的监控器和警卫,WAF具有先天的优势,可以将流量和活动记入日志。一些WAF能够捕获全部流量的完整数据包(这在分接/跨接式解决方案中最常见),但是它们都应该将进出Web应用的事务活动方面的关键信息记入日志。
WAF维护完整的事务日志吗?
日志使用什么格式(如系统日志)?
日志是不是以防篡改/防揭换的方式保存在服务器上?
日志能够从服务器安全地导出吗?
产品是否随带预配置的报告,以便合规和管理?
◆管理多个WAF:如果WAF要部署在复杂的分布式环境中,集中管理功能将大大减轻管理开销。
WAF是否工作在用于多处的分布式WAF环境下?
安全策略能不能运用到所有WAF?
针对单个应用的自定义策略是否得到支持?
◆SSL和加密:加密可以保护传送的数据被人窥视,但这也意味着WAF要是不先对数据解密,就无法检查数据。这方面有两个选择:一是为WAF提供密钥,那样就能对数据解密。二是在WAF处终结SSL连接,然后建立一条新的加密隧道,以便数据从WAF传送到Web服务器/浏览器(建立加密隧道是可选功能)。SSL处理给处理器带来了开销,所以要精心选择可合理终结SSL会话的WAF,考虑使用加速板来卸载一部分处理工作。
WAF支持SSL解密吗?
是否支持桥接式终结?
有没有实现被动解密的密钥共享机制?
有没有加速选件,比如加密加速板?
◆新兴协议:规范化和重新组装HTTP和HTML很棘手,但在Web 2.0及之后的环境中,有许多新兴协议和现有的媒体类型会带来恶意软件或安全漏洞。没有哪个WAF能够分析.swf(Flash),找出所有安全漏洞,但至少应支持图像检测,并支持Jscript和PHP等脚本。
WAF能处理dHTML、CSS、XML和SOAP吗?
WAF能支持对Flash进行扫描吗?支持图像(JPG、GIF和PNG)扫描呢?
◆与Web应用扫描器集成:Web应用扫描器这种产品能够自动扫描来自外部的Web应用,以模拟攻击者可能会发现的那种安全漏洞。扫描器与WAF互为补充,因为它们能发现管理员利用自定义WAF规则可以缓解的安全漏洞。有些Web应用扫描器供应商与WAF供应商结成了合作伙伴,那样扫描过程中发现了安全漏洞后,扫描器就能自动提议采用什么样的自定义规则,使用正确的WAF句法。这有助于迅速消除安全漏洞,也不需要试图制定防止攻击的最佳规则所需要的管理开销。
供应商与Web应用扫描器供应商有没有合作伙伴关系?
双方产品之间的集成有多紧密?
规则能自动更新,还是需要手动干预?
总结
你在购买WAF产品之前,需要弄清楚上述问题和考虑因素,它们是确保你买到合适产品的基础。想了解更多的详细内容和考虑因素,请参阅Web应用安全联盟的Web应用防火墙评估标准评估响应矩阵。将上述几点和评估响应阵里面的更多详细内容作为基准,列明需求,并确定必要的功能特性,然后向供应商提交采购需求,敲定最后的需求。虽然WAF市场不像其他一些市场来得拥挤,但事先做好明确采购需求方面的工作将大大缩小产品的选择范围,并有助于确保企业能够得到合适的工具。
来源:http://www.esecurityplanet.com/features/article.php/3897346/How-to-Choose-the-Right-Web-Application-Firewall-WAF.htm
【编辑推荐】
网站标题:如何选择合适的Web应用防火墙(WAF)?
链接地址:http://www.shufengxianlan.com/qtweb/news33/8033.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联