·反产品兼容冲突问题概述

　　反病毒产品从最开始的行命令扫描工具发展至今，已经形成了带有文件、注册表、内存等多种本地监控机制;、邮件客户端等多种保护环节;以及整合了主机、检测机制、主动防御机制的综合型产品。而其核心价值早在上世纪末，就已经从最开始的静态的文件扫描检测，变成实时化的主机防护。而实时化的防护推动了反病毒产品使用更多的服务、驱动等底层技术，运行于更接近系统内核的位置，这也为反病毒产品产生相互兼容性问题打下了伏笔。

　　随着的复杂化，威胁的不断离散化等影响，反病毒的监控保护点也日趋复杂，又加之反病毒厂商数量也在增加，而操作系统厂商并没提供比较标准的技术规范，因此反病毒产品因互不兼容，发生共存冲突等带来的问题越来越多，并间接影响了用户对反病毒产品的信任。

　　目前己经发现并被报道过的兼容性问题包括：

　　造成系统崩溃和其他严重故障：从2000年以来，根据公开报道，已经出现多起因反病毒产品之间相互冲突，而导致系统蓝屏、死锁等事件。

　　资源占用：反病毒扫描、监控和其他防护机制，都会带来系统资源的占用。如病毒库的内存展开对内存的资源使用，文件监控、定时扫描可能导致更多的I/O开销、以及各种保护机制对CPU时间片的占用等等。这些对用户操作有一定影响，如系统延迟、文件复制操作时间变长等等。而由于消息传递等机制，有可能在多种反病毒产品共存时，其对资源和时间的影响不是简单的线性叠加，而是出现明显的性能恶化。

　　失效：由于监控机制之间的冲突，多种监控机制共存时，有可能造成其中之一失效，或者部分机制双双失效的风险。上述后果，可以在兼容性测试中被浮现。

　　相互误报：由于厂商之间互信互通机制尚不够通畅，以及少数恶意的“误报构造”攻击的存在，厂商之间出现相互误报的情况，也时常发现。由于被报警为病毒而严重地影响用户对产品的信心，因此，各厂商对被误报的问题也均比较敏感。

　　但需要指出的是，绝大多数情况下，反病毒产品之间的兼容性冲突问题，都是技术与协调的问题，有其工作机理上的必然性，并往往具有一定的不可避免性。相关问题多数并不是由商业竞争引发的，商业竞争也不是反病毒产品兼容冲突问题的本质。本白皮书主要介绍当前反病毒产品冲突的主因，以澄清公众误解。

　　下文中涉及到安天和厂商产品所使用的技术点，均用于说明反病毒产品之间兼容性冲突的必然性，不是对实现水平进行评价。

　　·主要冲突点详细解析

　　实时监控、主动防御等技术的发展是一柄双刃剑，一方面随着监控点的增加能应对新的安全威胁，另一方面也使反病毒产品的稳定性遇到挑战，测试难度普遍加大。反病毒产品自身的稳定性压力都在呈现几何级数增长，相互之间的兼容则变得更加困难。以下从文件监控、防火墙、浏览器防护、主动防御四个主要技术点，描述导致反病毒产品自身的稳定性下降、与操作系统之间和相互之间出现严重冲突问题的成因。

　　·文件监控的潜在兼容性问题

　　文件监控是反病毒厂商普遍采用的技术手段，其主要机理是对文件的创建、读取、关闭等行为进行监控触发对文件病毒检测，以阻断病毒的执行和部分相关行为。

　　文件监控的实现方式主要有以下两大类型：

　　1. API挂钩。根据钩挂API的层次不同我们又可以分为

　　a) Ring3文件监控。多采用inline hook的方式修改文件操作相关函数的前几个字节，跳转到自己的函数，然后对将要操作的文件和缓冲区进行检测。

　　由于实现跳转的方式有多种，所以不同软件的实现策略有所不同，很难保证多个软件共存时前一软件修改后不影响到后一个软件，而且很可能导致相关进程崩溃。

　　由于此类技术也多被恶意软件使用，一些安全软件不会在执行完自己的代码后执行修改前的自己，而是采用从原始文件中读取、分析、执行的方式，导致多个安全软件同时监控一个API时，只有一个生效。

　　出于性能考虑，不传递给原API处理而采用自己实现的代码完成该API的相应功能，那么也不会将相关信息传递给其他软件。

　　部分软件在执行完自己的函数后会把修改后的字节还原，然后调用原系统API完成功能后再次修改、挂钩。两个使用此实现的软件同时工作则可能造成互相调用导致死锁，程序没有响应。

　　b) Ring0文件监控。与ring3的情况类似，但是后果更加严重。

　　由于inline hook不同实现造成的不兼容性很可能导致系统API无法正常工作，导致系统蓝屏。

　　例如：安天客户端产品(Antiy Ghostbusters4.0)早期版本采用大量inline hook，后因与其他产品严重冲突放弃;360安全卫士中inline hook有几种不同实现方式共存的现象，并且与360安全浏览器有重合的监控点。

　　挂钩之间相互调用，会导致死锁，系统死机。

　　采用替换SSDT的方式，则只有自己的挂钩有效，其他软件的挂钩均无效。

　　例如：360安全卫士等产品采用替换SSDT的方式，与其共存的安全软件通过标准方法获取的SSDT是无效的，导致其他安全软件功能出现缺失。

　　Vista以后对内核进行保护，部分对内核函数的修改会导致系统蓝屏。

　　例如：多个产品在内测和对外版本都出现过对关键内核函数进行修改，但是并没有仔细判断版本，导致兼容性出现问题而使系统蓝屏。

　　2. 文件过滤驱动

　　File System Filter Drivers

　　File System Minifilter Drivers

　　过滤驱动的本质依然是挂钩，但微软为了方便厂商调用，对其进行了，属于官方的技术。此类技术本身已经力求稳定与兼容，多数都提供了一定的兼容性保障。微软自己的安全产品在驱动层面也多使用类似的方式。

　　处置方式 交给后续过滤函数继续过滤 直接交给下层函数处理 拒绝访问

　　兼容问题现象 扫描次数多、系统变卡、变慢 后续过滤不生效，实际上只有一个安全软件在保护主机。 后续过滤不生效，只有一个安全软件报告病毒。

　　但是在安全产品的实际应用中，多层监控逐层传递会造成效率的降低，一些厂商在实现时会绕过后续的过滤驱动，直接将IRP请求发给下一层驱动完成相关的功能。

　　·防火墙的潜在兼容性问题

　　目前反病毒产品普遍使用单机防火墙技术来过滤出入数据，应对来自网络的威胁。

　　目前防火墙的实现方式包括：

　　TDI

　　NDIS

　　IP Filter

　　Windows Filtering Platform

　　Winsock Kernel

　　在以windows XP为主的时期，多数防火墙选择前三者中的某一种或者某两种结合的方式。在实际应用的过程中，同样存在多个共存无法同时生效的现象。其原因有：

　　1.过滤时出于效率考虑，直接将允许通过的包交给下层驱动处理，而不是后续的防火墙驱动。

　　2.由于NDIS和IP Filter比TDI更接近底层，前两者实现的防火墙会对TDI层造成影响。

　　3.XP自带的IP Filter存在谁先设置谁先生效的问题。安天盾防火墙与防火墙某版本同时使用该方式，如果同时安装在用户的机器中，则出现谁先启动谁先生效的现象。

　　WFP和Winsock Kernel是自vista之后引入的方式，兼容性相对而言更好，只要实现得当，一般没有兼容性的问题。特别是WFP针对防火墙和类软件做了设计上的考虑，兼容性问题得到了较好的解决。这也说明，操作系统提供相对规范的接口是解决安全产品冲突的较好方式。