防火墙的潜在兼容性问题
目前反病毒产品普遍使用单机防火墙技术来过滤出入数据，应对来自网络的威胁。
目前防火墙的实现方式包括：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针对防火墙和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，则用自己的进行替换，导致其他软件失效。
反病毒软件排斥与兼容问题分析的更多内容请读者阅读：
【编辑推荐】
