多安全软件共存的讨论

辔繇

  经常看到一些多杀软安装于一台机的现象，想到本人也曾装多杀软进行使用，直至后来看到此文。好文需要分享，以减少杀软爱好者对于多杀软选择的困扰，间接促进、维持良好的多杀软共存讨论氛围。以下为原文，仅对错别字、病句、排版等细节略微修改，文章原意不变。如有错误，望各位不吝指正，非常感谢！

原文地址：https://blog.csdn.net/avwjq/article/details/40897355


各位卡巴斯基软件的用户，大家好！

       撰写此文是为了向大家说明，反病毒软件之间兼容性方面的若干问题。为什么说一台计算机系统中不能够安装多款反病毒软件？究竟是为什么不能够这么做？本文从纯技术层面来阐述问题。某些厂商宣称其产品能够兼容其他安全软件，这是出于商业目的，其实其技术并不兼容其他安全软件的驱动底层。到底兼容不兼容，我们需要数据、测试结果来说话。

       反病毒软件从20年前发展到今天，其技术发展日新月异——从以前的I/O操作截取，到现在的多层次本地监控，如：带有文件、注册表、内存、浏览器、邮件客户端等多种保护环节；整合了主机防火墙、入侵检测机制、主动防御机制的综合型产品。以发展的眼光看，反病毒技术已经从原始的静态的文件扫描检测，变成实时化的主机防护。而实时化的防护推动了反病毒产品使用更多的服务、驱动等底层技术，运行于更接近系统内核的位置，这也为反病毒产品产生相互不兼容性问题埋下了伏笔。

      Windows 7，世上最复杂的操作系统之一，也是世界上流行的微型计算机操作系统，有着全世界大半数的使用用户。放眼回头看，从NT技术发展到如今，操作系统的复杂程度与日俱增。操作系统的复杂化，计算机威胁的不断离散化等影响，反病毒的监控保护点也日趋复杂，反病毒软件需要增设多种探针（某种检测手段）来检测威胁，又加之反病毒厂商数量也在增加，而操作系统厂商并未提供比较标准的技术规范，因此反病毒产品互不兼容，发生共存冲突等带来的问题越来越多，并间接影响了用户对反病毒产品的信任。

      时至今日，己经发现并被报道过的兼容性问题主要包括以下几类，多数由于操作系统触发异常处理机制引起系统蓝屏的最为明显：

1 . 造成系统崩溃和其他严重故障。从2000年以来，根据公开报道，已经出现多起因反病毒产品之间相互冲突，而导致系统蓝屏、死锁等事件。如金山毒霸2008与卡巴斯基6.0、7.0。

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

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

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

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

      下述内容将会阐述所有反病毒软件厂商所使用的共同技术点，用于说明反病毒产品之间兼容性冲突的必然性，不是对实现水平进行评价。


反病毒软件主要冲突点详细解析

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


一、主动防御潜在的兼容性问题

       这个放在第一个讲，为什么？因为这个组件与操作系统内核最为紧密，同时具有很强的排他性。此外，目前反病毒产品普遍采用了一些不依赖于内容规则、综合的行为判断和阻断机制，一般通称为主动防御技术。在多款软件共存的情况下，主动防御的兼容性问题尤为严重。主动防御主要可以分为两个方面来看待：

1 . 自我保护

       多款安全软件都保护自己的监控点不被修改，特别是使用了inline hook，或者对系统设备、内核对象、SSDT进行了hook的产品。类似GMER等Rootkit检查工具曾使用替换进程SSDT以保证自己的hook不被修改，但也因此导致使用SSDT hook的主动防御完全失效。例如，360安全卫士曾使用替换SSDT的技术对自己的监控点进行保护，导致与其共存的安全软件主动防御功能中关于 SSDT的部分完全失效。

       一旦发现自己的监控点被修改，则会对监控点进行修复，也就是重新hook。这就有可能导致多款安全软件反复争夺监控点，或者hook直接互相调用造成死锁，最终耗尽系统资源，导致计算机假死或者死机。

       由于自我保护的存在，病毒可能在感染安全软件后（病毒突破自我保护感染安全软件程序文件及注入安全软件进程），依然会被安全软件的自我保护所保护，其他安全软件可能无法读取其内容进行检测，或者可以检测，但是无法结束相应的进程，强行结束可能会导致系统假死或者死机。

2 . 恶意行为分析

       一款软件出于安全角度考虑，不调用被hook的原始API，则会导致其他软件在分析恶意行为时，无法检测到该行为，进而造成程序的行为序列发生改变，最终导致行为分析误报或者漏报。

       由于安全软件的某些行为和恶意软件具有相似性，例如：对API进行的某些hook，在多款安全软件共存的情况下，很有可能一款安全软件被另一款报为病毒，这也是一种误报。

       为了保证自身进程的行为不被重复记录，或者对行为分析产生影响，安全软件可能会对特殊API的调用参数含义进行修改，增加自身需要的标识，而这些标识可能会造成后续的监控产生不可预知的行为，最糟糕的情况就是导致系统蓝屏。

       对于ring3与ring0结合判断的主动防御，处于二者中间的其他安全软件对数据的修改可能会造成ring0缓冲区的溢出（例如：ring3的api挂钩通知ring0的驱动，需要26字节实际数据可能由于中间沙盒软件的路径重定向被改为27字节或者更多）或者被截断，导致系统蓝屏或者漏报。

       以上仅仅是主动防御潜在兼容性问题的一部分，由于主动防御技术本身的复杂度，在多款使用主动防御技术的安全软件共存时，兼容性问题就更易出现，也更严重，而这里说明的仅仅是一部分，不是全部。所以，各位请不要在一台计算机上安装多款此类安全软件！以下是总结的一些经验：

       HIPS类软件不允许和包含主动防御组件的安全软件共存并监控系统；沙盒软件或者称之为虚拟系统的软件不允许与HIPS类、主动防御组件的安全软件共存并监控系统。换句话说，使用了HIPS软件，就不能够用沙盒与包含主动防御组件的安全软件，以确保系统内核与HIPS软件的监控不发生失效，或者意外情况，引起系统蓝屏或者假死。同样，使用包含主动防御组件的安全软件，就不能够使用包含HIPS与沙盒类软件，以防止死锁（Death—Lock）的出现。


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

       文件监控是反病毒厂商普遍采用的技术手段，其主要机理是对文件的创建、读取、关闭等行为进行监控触发对文件病毒的检测，以阻断病毒的执行及部分相关行为。一个简单的例子，恶意软件要感染系统，本身就需要在硬盘上创建文件，所以监控文件常见的读取、关闭、打开操作直接能够检测到已知的恶意对象，用一句成语来说的话，就是“守株待兔”。

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

1 . API挂钩。

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

（1）Ring3文件监控。多采用inline hook的方式修改文件操作相关函数的前几个字节，跳转到自己的函数，然后对将要操作的文件、缓冲区进行检测。目前这种方法存在被称做为IAT Hook。但是由于可以很容易地被穿过，所以这类文件过滤技术已经不合时宜。

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

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

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

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

（2）Ring0文件监控。与ring3的情况类似，是目前主流的文件监控技术手段，不容易被穿过。但是产生的后果更加严重。

·由于inline hook不同实现造成的不兼容性很可能导致系统API无法正常工作，导致系统蓝屏。例如：360安全卫士中inline hook有几种不同实现方式共存的现象，并且与360安全浏览器有重合的监控点。

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

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

·Vista以后，微软对内核进行保护，部分对内核函数的修改操作会导致系统蓝屏。例如：多个产品在内测和正式版本都出现过对关键内核函数进行修改，但是并没有仔细判断版本，导致兼容性出现问题而使系统蓝屏。

2. 文件过滤驱动

·File System Filter Drivers
·File System Minifilter Drivers

      目前主要采用以上两种技术手段，文件过滤驱动的本质依然是挂钩，但微软为了方便厂商调用，对其进行了封装，属于官方的技术。此类技术本身已经力求稳定与兼容，多数都提供了一定的兼容性保障。微软自己的安全产品在驱动层面也多使用类似的方式。 这类技术是微软所推荐的。



      但是，在安全产品的实际应用中，多层监控逐层传递会造成效率的降低：一些厂商在实现时会绕过后续的过滤驱动，直接将IRP请求发给下一层驱动完成相关的功能。这时问题就来了，出现这种情况时，实际上您的计算机相当于只有一个反病毒软件产品在正常工作，其他的都因无法获取IRP包而异常工作。这种情况下，反病毒软件认为操作系统没有IRP包，同时反病毒软件也不会报任何错误。从用户感受上来看就是系统没有异常，也就是造成没有发生不兼容的假象。


三、防火墙潜在的兼容性问题

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

· TDI
· NDIS
· IP Filter
· Windows Filtering Platform
· Winsock Kernel

      卡巴斯基产品采用的是NDIS技术构建网络数据包过滤机制。

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

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

2 .由于NDIS和IP Filter比TDI更接近底层，前两者实现的防火墙会对TDI层造成影响，使用单一TDI技术的防火墙因无法获得数据包而无法工作。

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

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


四、浏览器防护潜在的兼容性问题

       浏览器防护多使用ring3 API HOOK。下面，结合网页防护类的主流产品分析其潜在的兼容性问题。




      使用ring3层 API hook实现的浏览器保护，不可避免要遇到和文件监控一样的问题。在实际对抗中，网马不断发展升级，已经开始将浏览器中的ring3 hook摘除。为了对抗此类威胁，主流软件多采取不断检测自己的hook是否存在，发现不存在则重新将函数挂钩，造成多款软件争抢一个API的现象，导致浏览器无响应或者响应缓慢，特别是与CreateProcesss相关的。

       在浏览器防护软件进行行为分析的时候，由于其他浏览器防护软件的参与，这会对浏览器的行为造成一定影响，这些影响可能是对堆栈的影响（由于多了一层Hook，实际调用的堆栈可能会增加一层）。以某浏览器防护软件为例，其堆栈检测只会向上追溯5层，如果同时共存3个软件，那么其想要检测的那层调用，则会由原来的第5层变为第7层，原来的检测方式就失效了。

       例如：360和金山网盾共存时，网马在创建进程时360进行检测。如果放行则会通过360的函数调用系统API，进而再次调用金山的进程创建检测，此时金山追溯堆栈会发现是360的模块调用，而不是js脚本解释引擎调用，予以放行。

       即使不考虑对堆栈的影响，由于不同浏览器防护软件都进行了拦截，对浏览器的行为也就产生了影响，造成相互的行为分析干扰，无法正确分析恶意行为，进而出现漏报或者误报。

       再如：金山网盾在脚本解释层根据特征检出了恶意脚本，构筑在其上层的其他防护的行为分析就无法发现该恶意脚本的行为。另外，360网盾会不断检测其监控点是否存在，而检测的机制是基于二进制比较的，如果发现其他软件进行了HOOK，则用自己的进行替换，导致其他软件失效。


五、兼容性问题对反病毒厂商有什么影响？

       兼容性是反病毒厂商的核心困扰之一，由于反病毒使用大量的内核技术、驱动等，一旦出现兼容性的后果，其所造成的影响要远远严重于其他应用软件。同时反病毒产品为了对抗病毒的某些自我防护机制，也会使问题的处置变得比较复杂。因此，多种反病毒软件之间冲突引发的问题要比其他应用软件冲突的后果更为严重。

       兼容性冲突问题使反病毒厂商技术支持的难度增大，由于环境的复杂性，问题变得更加难以排查和处理。如果出现潜在的冲突可能，技术支持需要去重现兼容性冲突的步骤，使冲突场景能够被重现。但是，用户的计算机操作系统环境与软件环境离散性、差别较大，有时候无法重现出兼容性问题。这时，可能需要在用户处获取一些原始数据，比如发生假死、蓝屏等严重的兼容性问题的信息就变得相当的重要。一般发生此类事故，需要从用户处获取“核心态内存完整转储”是基本的操作，往往会生成“完整内存转储”，因为该转储文件记录着发生错误一瞬间的事故现场原始数据，并且指向发生错误的指令及堆栈数据。这对于检查问题非常直观，为迅速查明产生问题的原因提供了可能。所以安全软件厂商非常重视这方面的数据信息的收集与反馈。

       此外，企业版产品，由于安全厂商承担着更大的责任和支持义务。如果由于冲突而带来了问题，对于问题的责任、后果的认定等方面都带来较大压力。

       同时，有的冲突问题由于需要厂商间的相互沟通才能解决，因此增加了技术支持的压力，以及延长了用户问题解决的周期。最值得一提的是，卡巴斯基2010系列软件与腾讯游戏反外G驱动的不兼容问题，双方持续沟通处理了大半年，问题才得以解决。用户给技术支持带来了很大的压力，这对一个经得起市场考验的安全厂商来说，承担的责任非常巨大。


六、如何解决冲突问题，有无约定俗成的规则？

       实时监控技术在Windows体系下刚刚成熟时，能够提供相关机制的厂商不多，监控点也相对较少，因此在出现兼容冲突问题时，安全软件厂商之间可以相互改造和规避。比如，冲突在哪个监控点，分析对方的监控方式，改造自身软件代码来规避冲突，同时解决冲突问题。但是后来，由于安全软件厂商过多，而监控点也在不断增加，解决相关问题的复杂度已经超出每个安全软件厂商的个体能力。

       因此在经历了大量冲突事件后，部分主流厂商选择了从安装环节保证互斥的方法。具体操作是：在安装时检测用户系统中是否有其他反病毒产品，如果有则提示用户可能的冲突后果，并提示用户卸载。如果用户不卸载，则明示用户共存后果，或者选择自身不予安装。但先被装载到主机上的反病毒产品，并不监控其他反病毒产品的安装行为，以及进行提示。这就是约定俗成的“后卸前”原则。

       这种方法，虽然影响到了部分用户让多种反病毒产品共存的意愿，但其形成了一个单向的逻辑，即：后安装的有告知和卸载的主动权，先装入主机的接受用户的选择。

       这个过程有一定合理性的：

·通过互斥，一定程度上解决了兼容性问题。

·保证了用户的知情权、选择权和自觉权。用户是在被告知后果的情况下，做出了符合个人意愿的选择。

·用户在后一个反病毒产品的体验中，如果觉得不如之前的软件，可以通过再安装前一个软件的方法，重新选择之前的产品。这确保了厂商之间的竞争基本上是用户体验和效果的竞争，而没有赖在用户机器上不走的情况。

       但互斥性的方法，所带来的问题也显而易见：用户很难同时分享两个产品的保障。而这对于地下经济产业链所驱动的木马小众化、数量爆炸化的严峻安装形式，只靠任何一个安全软件厂商的力量，可能都很难保证用户安全。相关产品能够合理共存、机制互补更符合用户价值的最大化。


七、目前世界范围内主流的兼容性问题建议

       尽管反病毒厂商之间存在着长期的、持久的竞争，但主流厂商之间的技术层次的互通，技术资源（如病毒样本）的分享是一直存在的。加上管理部门、测评机构、CERT组织等的协调和努力，各厂商之间基本遵循了一些基础的原则。在历史上较长的一段时期内，尽管出现过各种商业摩擦，但各厂商一直期望回避有关兼容、冲突的问题，而不是将其作为竞争的筹码和手段。有关问题的复杂化、扩大化是后期才出现的，直至近期出现的奇虎360与金山大打出手的口水战。这在世界范围的计算机安全领域内都是前所未有的，也是后无来者的。彼此为了一些利益而互相以不兼容为砝码，逼迫用户做出一个选择。这种行为会被国际同行当作笑料，实在不堪入目。

      此次事件说明任何没有明确行业规范为支撑的原则，都是脆弱的。在“后卸前”的用户自主选择链条中，只要有一家采用不良手段，如通过反人机工程的方法，在竞争对手产品安装过程中，给予多次提示，造成用户一次选择不当就无法安装、或者安装后失效等，保护自己所谓装机率，则会连带造成被拦截的厂商进行报复，从而导致规则被打破，形成恶性循环，最终导致通过恶意构造兼容性壁垒和陷阱变成普遍性的行为。因此，自然形成的事实标准需要形成行业规范，才能具有权威性。在这里，呼吁国家工信部等有关部门、行业协会，应该指定一个行业范围内的自律准则，杜绝这类打击报复行为的发生。同时，建立第三方行业仲裁组织或机构，对于发生争议的事件，进行技术鉴定，并给出公正的仲裁。更换安全软件原本用意是保护用户的计算机，而非角逐个体利益的战场！

      反病毒产品作为主机安全的核心屏障，不仅要让用户远离安全威胁，也要保障用户的知情权、选择权，尊重用户卸载意愿，包括在保证稳定性基础上，尊重用户希望多个安全产品共存的愿望。这不仅是用户权益的体现，也是安全软件厂商不怕被用户进行比较与选择的自信心的体现。这个行业之所以前进，正是因为用户拥有不断尝试和选择的机会，这是每个安全软件厂商的动力源泉。

      同时，我们需要意识到：用户期望多安全产品共存，是当前严峻的安全形势所催生的真实需求。反病毒产品如果能提供更多的定制选择，如提供行命令行的扫描工具，提供扫描界面和监控机制，甚至不同监控机制的可定制安装，就能让用户在获得多个安全软件厂商检测能力的基础上，付出更少的因为兼容性带来的代价。如果安全厂商之间进一步强化其互通体制和配置策略，未来能够支持用户更灵活的、定制多产品共存的监控策略，则将创造一种更为理想的境界。

      而主流操作系统厂商如果能对监控基础给出更为丰富的接口，定义相应的规范，包括保证公共安全接口统一嵌套化，提高封装的稳定性，则能进一步降低冲突发生的概率。

      当然，希望用户理解：只要反病毒产品的实时监控和防御的使命存在，不同产品之间的兼容冲突问题就必然存在，不可能有终极解决之道。也希望传达给用户的信息是：大量安全软件厂商所研发的、充满不同个性的安全产品，是攻击者需要逾越的一个整体代价。只有八仙过海、各显其能的安全软件厂商的个性化存在着，才能保证网络整体的安全。多个安全软件厂商的共存和有序竞争，是互联网安全的基础保证。


（完）

fzp070

感谢分享，学习了

15717522768

同意.
确实是这样的.

kisok

很久以前我也是杀软控，装过多个杀软组合，现在单奔卡巴已足矣

我是风我是风

kfa加简单防火墙路过

喀反

所以还是不要相信所谓的最佳杀软组合，单奔才是王道

bbs2811125

多引擎主要是心理层面的需求

装甲未被击穿

有个成语叫过犹不及，一语中的了

a8855942

谢谢分享

裂空我爱杰

我试过手工组合原来GDATA的引擎，其实功能不要叠加，互相排除，扫描敏感度调低，大问题是没有的。