《（安全生产）内网一体化安全防护系统中》由会员分享，可在线阅读，更多相关《（安全生产）内网一体化安全防护系统中（7页珍藏版）》请在金锄头文库上搜索。
1、蒲堪峰：内部局域网中USB设备分类监控系统的设计与实现安全与保密内部局域网中USB设备分类监控系统的设计与实现蒲堪峰（电信科学技术第十研究所 陕西 .西安 710061）摘 要：分析了Windows 2000 操作系统下采用HOOK系统IRP消息的方式实现对USB设备分类监控,可对用户的USB设备操作行为进行实时监控。该系统采用集中式管理，分布式控制架构，具有动态的USB设备变更检测、类型检测、敏感USB设备控制，安全警报，日志审计等功能。作为内网一体化安全防护系统的一个子系统，通过实际使用表明，该系统能够有效地控制和降低 USB 设备对内部网造成的信息安全风险。关键词：USB IRP WDM
2、 设备监控 HOOK 在我国，国家政府部门、企事业单位已经越来越多地使用计算机网络开展日常工作和业务，利用计算机网络发送和处理大量的内部秘密文件。越来越庞大的计算机网络及其不断更新的相关技术也带来了不断增长的安全隐患，网络安全已经成为了一个国际化的问题。防病毒、防黑客、物理隔离、数据备份、防火墙等是人们常用的防止外部网络侵害的信息保护手段。然而更大的安全隐患来源于网络内部，据统计，大约有80% 的安全破坏是在网络内部发生的。所以防范来自内部的攻击更为重要、更为迫切，一旦因为各种原因导致内部涉密文件泄漏，将对国家稳定和社会安全造成巨大威胁。因此，针对内部网络终端使用者行为、移动存储设备、用户身份
3、认证管理等开发的“内网一体化安全防护系统”，将从技术上解决这个问题，使已发生的事件不再是无法追查，并能够做到有理有据。USB接口是计算机网络信息传输的一个重要途径，同时也是内部网病毒的传播源，因此很多保密单位都在物理上禁用 USB端口。但由于USB设备种类众多且使用广泛，仅仅简单地禁用 USB 接口会使无威胁的外围设备如USB 鼠标、键盘和USBKEY 等无法使用，给用户带来很多不便。本文讲述了“内网一体化安全防护系统”中基于微软Windows 2000操作系统下的USB设备监控系统USBMon的实现。该子系统可以根据管理员制定的策略分类管理USB设备，方便管理员对网络中各主机的USB设备进行
4、细粒度的管理。一、USBMon监控系统的基本原理1Windows 2000系统结构Windows 2000操作系统使用IRP与内核模式驱动程序（NT4和WDM）通信1 。图1是以用户视点所看到的Windows 2000操作系统，该图描述了驱动程序开发者所关心的特征。当用户模式程序需要读取设备数据时，它就调用Win32 API函数,如ReadFile。Win32子系统模块（如Kernel32.dll）通过调用平台相关的系统服务接口实现该API，而平台相关的系统服务将调用内核模式支持例程。在ReadFile调用中，调用先到达系统DLL(Ntdll.dll)中的一个入口NtReadFile函数，然后
5、这个用户模式的 NtReadFile函数接着调用系统服务接口，最后由系统服务接口调用内核模式中的服务例程，该例程同样名为NtReadFile。系统中还有许多与NtReadFile相似的服务例程运行在内核模式中，为应用程序请求提供服务，并以某种方式与设备交互。它们首先检查传递给它们的参数，以保护系统安全或防止用户模式程序非法存取数据，然后创建一个称为“I/O请求包(IRP) ”的数据结构，并把这个数据结构送到某个驱动程序的入口点；NtReadFile将创建一个主功能代码为IRP_MJ_READ的IRP，执行IRP的设备驱动程序最后可能会访问硬件；驱动程序完成一个I/O操作后，通过调用一个特殊的内
6、核模式服务例程来完成该IRP。完成操作是处理IRP的最后动作，它使等待的应用程序恢复运行。同样，对于USB设备的所有操作都是通过向USB设备发送相应的IRP 完成的。USBMon拦截所有发往USB设备的IRP，并对其中的内容进行分析。如果发现USB设备处于配置阶段，说明新插入USB设备，这时，USBMon会通过发送相应的IRP得到新插入USB设备的设备类型，如存储类设备、USB集线器类设备或者厂商自定义设备等，再根据策略文件来决定是否启用这个设备。USBMon中的关键问题是IRP拦截、判断新设备的加入以及对厂商自定义类设备的管理。2HOOK 系统的IRP消息Windows 2000下，设备和驱
7、动程序的有着明显的堆栈式层次结构:处于堆栈最底层的设备对象称为物理设备对象，或简称为PDO，与其对应的驱动程序称为总线驱动程序；在设备对象堆栈的中间某处有一个对象称为功能设备对象（FDO），其对应的驱动程序称为功能驱动程序；在FDO的上面和下面还会有一些过滤器设备对象（FiDO）；位于FDO上面的过滤器设备对象称为上层过滤器，其对应的驱动程序称为上层过滤器驱动程序；位于FDO下面( 但仍在PDO之上)的过滤器设备对象称为下层过滤器，其对应的驱动程序称为下层过滤器驱动程序。这种栈式结构可以使I/O请求过程更加明了。每个影响到设备的操作都使用IRP，通常IRP先被送到设备堆栈的最上层驱动程序，然后
8、逐渐过滤到下面的驱动程序。根据设备以及该IRP所携带的内容，每一层驱动程序都可以决定如何处理IRP，有时驱动程序不做任何事，只是向下层传递该IRP；有时驱动程序直接处理完该IRP不再向下传递；有时驱动程序既处理了该IRP又把该IRP传递下去。USB设备驱动程序在与硬件设备进行通信时，一般使用USB总线驱动程序接口（USBDI，USB Driver Interface），而不直接使用HAL函数与硬件通信。USB驱动程序为了向其硬件设备发送一个请求，先创建一个USB请求块（URB），再把 URB提交到总线驱动程序。例如：为了配置一个USB设备，USB设备的驱动程序需要提交几个URB来读取各种描述符
9、或发送命令，向USBD的调用被转化为带有主功能代码为IRP_MJ_INTERNAL_DEVICE_CONTROL的IRP；然后，这个IRP会被发往由USB集线器驱动为USB设备创建的PDO对象。微软提倡的IRP拦截方法是创建一个上层过滤设备对象，并将它加到要拦截设备所在的设备堆栈中，其过程为：先通过IoCreateDevice创建自己的设备对象；然后获得要拦截设备的设备对象指针；最后通过IoAttachDeviceToDeviceObject将自己的设备放到设备堆栈上成为一个过滤器。这种方法是最可靠，也是最常用的。但是，在USBMon中使用这种方法会有些问题。假如有一个USB存储设备接到USB
10、 Hub上，USB Hub的驱动程序会为这个USB存储设备创建一个PDO,然后由USB存储设备的驱动程序(Windows 2000下为usbstor.sys)创建FDO对象并加到PDO上。此时如果把过滤设备对象加入设备堆栈，过滤设备将在设备堆栈的最上层，I/O管理器发给USB设备的IRP 将先经过过滤设备；而如果先加好了过滤驱动，再插入闪存时就会形成图2所示的设备堆栈结构。绝大多数的IRP都是由USB Hub驱动建立的PDO对象完成，此时根本达不到过滤的效果，因而这种方法只有在USB设备加入后才能拦截IRP，这就使它无法检测到设备的动态插入。如果仅仅是对设备的操作进行记录，而不需要检测设备的动
11、态插入，这到不失为一种理想的方法。USB设备USB设备对应的FDO（由USBHUB驱动建立）过滤设备对象USB Hub设备对象图2 添加过滤设备形成的设备栈USBMon使用了HOOK驱动设备对象派遣函数的方法来拦截IRP，对于发往设备的IRP,I/O管理器会使用DeviceObject中的DriverObject反向指针来定位相应的驱动程序对象，然后根据IRP和IRP堆栈中的参数调用相应的驱动程序例程。从IRP处理过程可看出，只要将驱动程序例程指针用相应的钩子函数来代替就可达到拦截IRP的目的。这种方法最简单直接，而且拦截IRP时不会受到过滤设备必须在设备堆栈栈顶的限制。这里选择了HOOK U
12、SB集线器驱动程序的分发例程。通过动态调试发现，驱动程序开发中，经常使用的IRPTrace工具，通过HOOK IoCallDriver等IRP处理过程中必须使用的I/O服务例程来达到拦截IRP的目的，它使用的方法类似上层截获API调用的方法，直接改写ntokrnl.exe的PE头导出节。这种方法可以截获到系统内所有的IRP，适用面很广，与上面的方法相比，只是实现的难度和系统开销稍微大了一点。另一种方法是通过给USB集线设备添加过滤驱动程序来拦截IRP。这种方法最保险且稳定。3通过分析IRP获取设备加入通知USBMon要完成的功能是根据设备策略禁用USB设备,并不关心USB设备的具体操作,因此钩
13、子函数的工作仅仅是监控新设备的加入并根据策略及时对设备的启用进行控制。所有新加入的设备都要通过配置才能使用，USBMon通过设备配置过程中的某些特殊操作来获得新设备加入的通知，并根据策略及时阻止。以下是USB设备连接时的总线列举过程。(1)USB集线器发现有USB设备插入时,会向主机报告其下行端口上有 USB设备连接。主机接到该通知后，会向集线器发出GetPortStatus请求，以了解更多信息;(2)主机向该集线器发出GetPortStatus请求(集线器设备类请求)，以复位这个USB设备;(3)主机使用默认地址向USB设备发出GetDescriptor请求,以取得其缺省控制管道所支持的最大
14、包长度;(4)主机向USB设备发出SetAddress请求,为其分配一个唯一的设备地址;(5)主机使用新地址向USB设备发出GetDescriptor请求,以读取其设备描述符的全部字段,以了解该设备的总体信息,如供应商ID、产品ID等;(6)主机向USB设备循环发出GetDescriptor请求，以读取其全部配置信息；(7)主机根据USB设备的配置信息如供应商ID、产品ID等，为其选择一个合适的驱动程序；(8)加载USB设备驱动程序以后,主机发出SetConfiguration(x)请求为该设备选择一个合适的配置(x代表非0的配置值)。以上过程都是配置USB设备必不可少的。在钩子函数中阻止上面
15、任何一步的正确完成，都可以达到禁用设备的目的。但USBMon是需要获得一些设备信息来判断新加入的设备是否应该被禁用，获取信息的过程只能在主机分配设备地址之后才能完成，因此选择将SetConfiguration(x)请求作为有新设备加入的标志。SetConfiguration请求并不是配置过程特有的，或许在某些情况下也要使用这个请求(测试中暂时还没发现这种情况)，但只要有设备加入就一定会有 SetConfiguration(x)请求。一旦USBMon拦截到SetConfiguration(x)请求,说明有新设备加入,这时它将会去获取设备类型信息。如果此类设备是被禁用的, USBMon直接完成这个
16、请求并返回状态NTSTATUS_UNSUCCESSFUL；否则将请求交给正常的驱动程序服务例程。二、USBMon监控系统的设计实现USBMon监控系统采用C/S 模式、分布式控制技术，整个系统由一个监管控制台（Console）和若干监管代理（Agent）组成，Console和Agent之间采用socket 进行通信，如图3所示。管理员通过监管控制台统一设置和分发各个节点的安全策略，监管代理驻留在各个受控主机的节点上，以安全中间件的方式嵌入到系统内核，按照安全策略对本机节点上接入的各种USB 设备进行管理，并对用户行为进行监视，一旦发现用户有违规操作USB设备的行为，立即加以阻断，并向控制台发出报警信号。同时，违规行为的相关信息被记录在日志文件中，作为追究违规者责任的依据和凭证。1- 2图3 USBMonitor系统监控模型客户端程序
