目前反病毒產品普遍使用單機防火墻技術來過濾出入數據，應對來自網絡的威脅。

 

目前防火墻的實現方式包括：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，則用自己的進行替換，導致其他軟件失效。