Cloud & Telecom Security

看完皓月所写的“防火墙、UTM产品OEM第三方产品或嵌入第三方反病毒引擎的利弊分析”，掩卷而思，这些观点印证了前些天和朋友们探讨的若干观点。近几年，防火墙和入侵检测系统IDS演变到防火墙FW、入侵防御系统IPS和统一威胁管理UTM系统的三国争霸，UTM将会代替防火墙的声音获得了不少关注。从皓月的这篇文章中，你能发现很多更深层次的思索。

皓月认为：基本上第一阵营、第二阵营传统信息安全厂商中的一半以上OEM飞塔的防毒墙，而采用嵌入引擎的方式则种类繁多，包括国外的卡巴斯基、赛门铁克、 Sophos、F-Prot以及国内的金山、安天等在内，而三线厂商则更有采用廉价但粗糙的开源的反病毒引擎ClamAV的解决方案。

与这几年的安全运营经验匹配，下面三点可能会对FW/IPS和UTM之争产生相当大的影响：

    位置和策略的合理性：网关位置对抗恶意代码不是一劳永逸的，一方面恶意代码的最终目标并不是网关，而是在网关之后内网内的各类终端节点，而单纯的依赖网关防毒，则会造成“单点突破，全局沦陷”的现象出现；另一方面，恶意代码无法单独存在，势必要通过各类行为（如：扫描、攻击、窃取等）扩散其影响，而这些行为对于现有直路带基于文件代理方式静态匹配的病毒功能的防火墙以及UTM设备来说，是根本无法检测的；
    升级频率的差异化：传统的防火墙理论上是一个稳定的面向策略的高性能安全功能组件，通过策略的配置、变更来起到安全控制；其最坏的情况下即使不能够确保预定义的安全策略有效执行，也可以通过全部阻断方式切断网络出口连接。换句话说，即使无法对内网内的威胁作出响应，也可以使之不通过网络出口进一步扩散。对于反病毒来说，其是一个可变的面向恶意代码对象的易扩展安全功能组件，特征库的升级、程序模块的升级频率远高于防火墙类安全产品的升级。对于UTM产品来说，其统一化的功能架构为新功能的扩充打下了基础，但这并不是一个简单的堆叠、加法过程，相反，当可变的功能组件与稳定的功能组件发生同处于一个硬件及部署位置时，就会导致每个功能都会大打折扣，而反病毒引擎的不稳定概率是最高的。
    运维管理的特殊性：对于IT管理者来说，其最根本的目标是保障业务的连续性不受破坏，那么在网络出口直连的带防病毒功能的防火墙、新型UTM设备如果频繁的升级、变更安全策略，势必会引入一定的风险，而致使业务的可用性受到很大的损害，那么是得不偿失的。

- 点击下载原文(pdf) -。

以下是一些精彩观点：

反病毒是信息安全体系中非常特殊的领域，由于其对抗的密度和强度，对资源、对基础依赖的程度远高于其他多数安全领域，因此是多数安全厂商不愿意半路杀入的原因。就连Cisco这样的巨无霸企业在推出自防御网络中也是与trendmacro(趋势)携手，而微软则采用直接购买其他反病毒企业的方法。

正因如此，无论是国内的传统防火墙厂商（，抑或是新兴的UTM（统一威胁管理厂商）为了即扩展反病毒能力，又不承担庞大的病毒引擎研发分析成本，都在其安全产品中不约而同的嵌入了来自于第三方反病毒厂商的引擎；前者多以新型防火墙为主营业务，后者则以新兴UTM架构为主打，市场上一时间风生水起，一片叫好之声；甚至就连长久以来被人所指责的“网络病毒检测过滤性能瓶颈”也随着ASIC专用芯片、多核NP等硬件技术的应用而号称“已经解决”据比较可靠的资料分析，国内比较有代表性的安全厂商为了迅速扩展产品线，或者提升产品能力，分别采用过OEM国外反病毒厂商成型产品（贴牌），或选择在自身现有产品拟上嵌入第三方反病毒引擎的方法，也有的厂商产品线较长，采用OEM+自身产品嵌入引擎，两条路并举的方式大力扩张产品线。

从反病毒引擎自身来看，其自身一定存在安全漏洞，从来自Securityfocus安全组织的不完全统计来看，其漏洞主要类别包括但不限于以下所列：
    反病毒引擎在处理特殊文件格式（如：畸形ZIP、ARJ、CHM等）时被欺骗；
    基于代理方式的反病毒引擎（如：FTP代理、SMTP代理等）可被精心绕过；
    反病毒引擎在处理特殊报头时（如：MIME、PE等）被拒绝服务攻击DoS；
    反病毒引擎自身存在缓冲区溢出漏洞（如：Sophos中的veex.dll等）。
那么，引擎自身存在漏洞，对于反病毒厂商而言，其响应、修复往往需要一个周期，短则数日，长则以月来计算；而对于嵌入第三方反病毒引擎的安全产品，其修复补丁的发布与安装势必滞后一段时间；尤其是对于部署在生产环境中的安全设备而言，其所遵循的配置管理、变更管理策略更对升级需要进行多次审核。
因此，对OEM其他产品或者嵌入第三方反病毒引擎自身漏洞的响应不力、无法及时修复，将为该客户以及厂商本身带来一定的风险。

Be Sociable, Share!

•