档案
日志
相册
视频
分享
2008-07-21 | 病毒网络行为监控的几个思路
标签：
一个病毒网络行为监控的小工具，工作量不大，但时间紧迫。
思路1，基于网络监控，使用NDIS驱动、TDI驱动或者SPI过滤。相对而言，前两者稳定性差，会导致经常性BSOD。SPI最容易实现，但控制不好的话，会使SPI链混乱，影响正常的网络应用（当然，修复也比较容易）。另外，也可以直接借助winpcap提供的接口，但缺点是需要安装winpcap。
思路2，拦截网络操作的相关API调用（bind、connect、listen、recv、send、recvfrom、sendto等），记录调用发生的时间、应用程序名称以及四元组。如果采用DLL注入的方法，系统稳定性会大打折扣，如果使用DEBUG API加载目标程序，又会受阻于病毒的反调试部分。
思路3，直接使用进程端口关联，相关的代码已经非常成熟，但实时性不够好，同时UDP协议的远程信息无法准确获取（受限于AllocateAndGetUdpExTableFromStack函数）。
考虑到时间仓促，按照思路3快速实现了原型。实时性和UDP信息，准备采用RAW Socket 嗅探的方法来解决。但莫名其妙的事情发生了，RAW Socket在一旦设置了IP_HDRINCL就无法bind，google给出的答案是需要administrator且关闭防火墙，也有设置注册表“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Afd\Parameters:DisableRawSecurity”为1的方法，不过需要重启系统，比较麻烦。考虑到只关注病毒网络行为，不需要关心数据内容，索性省略了这一步，直接bind了。另一件诡异的事情发生了，recv总是无法成功，如果设置timeout，则每次都是超时。无可奈何，正准备推翻重来，偶然拿到虚拟机里面运行——居然在虚拟机里面recv成功了。于是，经过一番里里外外的调试，终于实现了一个最安全的网络行为监控方式。
——后来发现上述诡异现象的原因在于，如果有多块网卡（包括使用ADSL），需要在bind时指定当前监控网卡的IP。虚拟机里只有一块网卡，自然不会有问题。
思路1，基于网络监控，使用NDIS驱动、TDI驱动或者SPI过滤。相对而言，前两者稳定性差，会导致经常性BSOD。SPI最容易实现，但控制不好的话，会使SPI链混乱，影响正常的网络应用（当然，修复也比较容易）。另外，也可以直接借助winpcap提供的接口，但缺点是需要安装winpcap。
思路2，拦截网络操作的相关API调用（bind、connect、listen、recv、send、recvfrom、sendto等），记录调用发生的时间、应用程序名称以及四元组。如果采用DLL注入的方法，系统稳定性会大打折扣，如果使用DEBUG API加载目标程序，又会受阻于病毒的反调试部分。
思路3，直接使用进程端口关联，相关的代码已经非常成熟，但实时性不够好，同时UDP协议的远程信息无法准确获取（受限于AllocateAndGetUdpExTableFromStack函数）。
考虑到时间仓促，按照思路3快速实现了原型。实时性和UDP信息，准备采用RAW Socket 嗅探的方法来解决。但莫名其妙的事情发生了，RAW Socket在一旦设置了IP_HDRINCL就无法bind，google给出的答案是需要administrator且关闭防火墙，也有设置注册表“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Afd\Parameters:DisableRawSecurity”为1的方法，不过需要重启系统，比较麻烦。考虑到只关注病毒网络行为，不需要关心数据内容，索性省略了这一步，直接bind了。另一件诡异的事情发生了，recv总是无法成功，如果设置timeout，则每次都是超时。无可奈何，正准备推翻重来，偶然拿到虚拟机里面运行——居然在虚拟机里面recv成功了。于是，经过一番里里外外的调试，终于实现了一个最安全的网络行为监控方式。
——后来发现上述诡异现象的原因在于，如果有多块网卡（包括使用ADSL），需要在bind时指定当前监控网卡的IP。虚拟机里只有一块网卡，自然不会有问题。
分享
评论
想第一时间抢沙发么？