CN102438016A

CN102438016A - 获知报文所属进程的方法、访问控制方法、装置及设备

Info

Publication number: CN102438016A
Application number: CN2011104155192A
Authority: CN
Inventors: 张世銮
Original assignee: Beijing Star Net Ruijie Networks Co Ltd
Current assignee: Beijing Star Net Ruijie Networks Co Ltd
Priority date: 2011-12-13
Filing date: 2011-12-13
Publication date: 2012-05-02
Anticipated expiration: 2031-12-13
Also published as: CN102438016B

Abstract

本发明提供了一种获知报文所属进程的方法、访问控制方法、装置及网络通信设备，部署在AFD驱动和协议驱动之间第一过滤驱动对应用程序的通信事件进行监测；获取通信事件相关的IP地址、端口号信息以及对应的进程ID，并发送给部署在协议驱动和网卡驱动之间的第二过滤驱动，这样，第二过滤驱动在收到应用程序收发的报文时，可以根据该报文的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定该报文所属的进程ID。进而可以使用不同进程ID对应的访问控制策略对不同应用程序分别进行访问控制，本发明解决了协议驱动和网卡驱动之间的过滤驱动获知报文所属进程的问题，实现了应用程序粒度级别的访问控制。

Description

获知报文所属进程的方法、访问控制方法、装置及设备

技术领域

本发明涉及计算机通信技术领域，尤其涉及一种获知报文所属进程的方法、访问控制方法、装置及网络通信设备。

背景技术

Windows内核的网络驱动架构如图1所示，小端口驱动(即网卡驱动)、协议驱动、AFD驱动这三个模块构成了Windows内核网络驱动的三个层次。小端口驱动和协议驱动之间，遵循网络驱动接口规范(Network Driver InterfaceSpecification，NDIS)规范进行交互；协议驱动和辅助功能驱动(AncillaryFunction Driver，AFD)之间，遵循传输驱动程序接口(Transport DriverInterface，TDI)规范进行交互。

TDI位于Windows的上层网络组件(如afd.sys)与协议驱动(如TCP/IP协议驱动)之间，它规定了一套接口标准，任何一个上层网络组件，只要遵循TDI规范，就可以调用操作系统中的每个网络协议驱动。TDI把上层网络组件的网络命令，如名称解析、建立连接、发送或接收数据等，用同一套指令集描述，转化成协议驱动能够识别的IRP(I/O Request Packet，输入输出请求包)指令。所以上层网络组件又被称为TDI客户，协议驱动被称为TDI传输器。

协议驱动位于网卡驱动之上，TDI客户之下。对上层的TDI客户开放了内核设备，可以接收上层发来的指令，并封装成网络帧，遵循NDIS规范传送给网卡驱动。并负责从网卡驱动接收网络数据报文，形成通信事件，通知上面的TDI客户(根据TDI事先设置的事件回调函数)。AFD驱动发送给这些设备的IRP指令，经过TCP/IP协议驱动的处理，就成了一系列标准的以太网包。

协议驱动在OSI七层模型中，相当于传输层+网络层。

网络驱动接口规范(Network Driver Interface Specification，NDIS)由微软和3COM于1992年联手开发，是Windows网卡驱动到协议驱动之间的通信规范，遵循NDIS规范开发的协议驱动就称为NDIS协议驱动，最常见的是TCP/IP协议驱动。下表1是各个Windows版本对应的NDIS版本：

表1

Windows版本	NDIS版本
		Windows2000	5.0
WindowsXP	5.1
		Windows2003	5.1
WindowsVista	6.0
		Windows2008	6.1
Windows7	6.2

NDIS中间层驱动，是一种混合型驱动程序，它把协议驱动和小端口驱动的功能结合在一起。它位于协议驱动和小端口驱动之间，如图2所示，上面是协议驱动，下面是小端口驱动。实际上它扮演了双面人的角色：对上面的协议驱动来说，它是小端口驱动；对它下面的小端口驱动来说，它是协议驱动。

从图2可以看出，协议驱动和小端口驱动之间的所有交互活动，都要经过这个NDIS中间层驱动，所以NDIS中间层驱动又称为NDIS过滤驱动。流经这个驱动的报文，都是即将发到网络上或从网络进来的原始格式报文。在这个驱动里面，可以拦截和修改协议驱动和底层小端口驱动之间的网络包，譬如1.通过或过滤掉；2.延迟或重新排序；3.加密或解密；4.压缩或解压；5.增加或删除标记。也可以做网络地址转换(Network Address Translation，NAT)、负载平衡和失效替换(Adapter Load Balancing And Fail-Over，LBFO)。

由于这类中间层(过滤)驱动处于网络通信的较低层，无法获知流经的报文，是属于哪个进程ID的，这个特点限制了所开发产品的功能，无法细化到应用软件这个粒度级别，如仅针对某个特定软件进行访问控制。

发明内容

本发明实施例提供了一种获知报文所属进程的方法、访问控制方法、装置及网络通信设备，用以解决现有协议驱动和网卡驱动之间的过滤驱动由于位于网络通信较低层，无法获知报文所属进程，进而也无法针对具体的应用程序进行相应的访问控制的问题。

基于上述问题，本发明实施例提供的一种获知报文所属进程的方法，包括：

在AFD驱动和协议驱动之间部署的第一过滤驱动对应用程序的通信事件进行监测；

当监测到存在应用程序发生通信事件时，所述第一过滤驱动根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID并发送给部署于协议驱动和网卡驱动之间的第二过滤驱动；

第二过滤驱动接收所述IP地址、端口号信息以及对应的进程ID并保存；

当所述第二过滤驱动接收到应用程序收发的报文时，根据该报文中的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定所述报文所属的进程ID。

本发明实施例提供的一种应用程序的访问控制方法，包括：

当所述第二过滤驱动接收到进程收发的报文时，根据该报文中的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定所述报文所属的进程ID；

所述第二过滤驱动根据预先设置的各进程ID对应的访问控制策略，对该应用程序的通信事件进行相应的访问控制操作。

本发明实施例提供的一种获知报文所属进程的装置，包括：

第一过滤驱动模块，部署在AFD驱动和协议驱动之间，用于对应用程序的通信事件进行监测；当监测到存在应用程序发生通信事件时，根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID并发送给第二过滤驱动模块；

第二过滤驱动模块，部署于协议驱动和网卡驱动之间，用于接收所述IP地址、端口号信息以及对应的进程ID并保存；以及当接收到应用程序收发的报文时，根据接收的IP地址、端口以及对应的进程ID，确定所述报文所属的进程ID。

本发明实施例提供的一种应用程序的访问控制装置，包括：

第二过滤驱动模块，部署于协议驱动和网卡驱动之间，用于接收所述IP地址、端口号信息以及对应的进程ID并保存；以及当接收到应用程序收发的报文时，根据接收的IP地址、端口以及对应的进程ID，确定所述报文所属的进程ID，以及根据预先设置的各进程ID对应的访问控制策略，对该应用程序的通信事件进行相应的访问控制操作。

本发明实施例提供的网络通信设备，包括本发明实施例提供的上述获知报文所属进程的装置和/或上述应用程序的访问控制装置。

本发明实施例的有益效果包括：

本发明实施例提供的获知报文所属进程的方法、访问控制方法、装置及网络通信设备，部署在AFD驱动和协议驱动之间第一过滤驱动对应用程序的通信事件进行监测；获取通信事件相关的IP地址、端口号信息以及对应的进程ID，并发送给部署在协议驱动和网卡驱动之间的第二过滤驱动，这样，第二过滤驱动在收到应用程序收发的报文时，可以根据该报文的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定该报文所属的进程ID。进而可以使用不同进程ID对应的访问控制策略对应用程序进行访问控制，本发明实施例解决了部署于协议驱动和网卡驱动的之间的过滤驱动获知报文所属进程ID的问题，实现了应用程序粒度级别的访问控制。

附图说明

图1为Windows内核的网络驱动架构的示意图；

图2为NDIS中间层驱动的架构示意图；

图3为本发明实施例提供的获知报文所属进程的方法的流程图；

图4为本发明实施例提供的实例的驱动架构示意图；

图5为本发明实施例提供的实例的流程图；

图6为本发明实施例提供的对应用程序进行访问控制的方法的流程图；

图7为本发明实施例提供的获知报文所属进程的装置的结构示意图；

图8为本发明实施例提供的应用程序的访问控制装置的结构示意图。

具体实施方式

下面结合说明书附图，对本发明实施例提供的一种获知报文所属进程的方法、访问控制方法、装置及网络通信设备的具体实施方式进行说明。

本发明实施例提供的一种获知报文所属进程的方法，如图3所示，具体包括以下步骤：

S301、在AFD驱动和协议驱动之间部署的第一过滤驱动对应用程序的通信事件进行监测；

S302、当监测到存在应用程序发生通信事件时，第一过滤驱动根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID；

S303、第一过滤驱动将获取的IP地址、端口号信息以及对应的进程ID，发送给部署于协议驱动和网卡驱动之间的第二过滤驱动；

S304、第二过滤驱动接收所述IP地址、端口号信息以及对应的进程ID并保存；

S305、当第二过滤驱动接收到应用程序收发的报文时，根据该报文中的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定所述报文所属的进程ID。

本发明实施例提供的上述获知报文所属进程的方法中，需要预先在AFD驱动和协议驱动之间部署中间层驱动(第一过滤驱动)，在协议驱动和网卡驱动之间部署中间层驱动(第二过滤驱动)，第一过滤驱动可以是TDI过滤驱动或者其他可部署于AFD驱动和协议驱动之间的过滤驱动，第二过滤驱动可以是NDIS中间层驱动或者其他可部署于协议驱动和网卡驱动之间的过滤驱动。

上述步骤S301中，第一过滤驱动对应用程序的通信事件进行监测，可以通过对应用程序的TCP和/或UDP通信动作进行监测来实现。

具体地说，第一过滤驱动可以对下述TCP通信动作进行监测：

应用程序发起创建TCP socket连接、发起对外TCP连接、接受TCP连接等等。

第一过滤驱动对下述UDP通信动作进行监测：

应用程序发起创建UDP socket连接、发送数据包、接受数据包等等。

上述步骤S302中，第一过滤驱动根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID，通过下述方式实现：

第一过滤驱动截获通信事件的指令包(例如IRP指令包)或者数据包(例如UDP数据包)，获取指令包或者数据包中包含的IP地址、端口号信息以及对应的进程ID。

在Windows内核中，驱动和驱动之间通常使用IRP指令包进行通信。

第二过滤驱动在接收到第一中间层发送的IP地址、端口以及对应的进程ID之后，会向第一过滤驱动返回接入确认；

第一过滤驱动在接收到第二过滤驱动返回的接入确认之后，会放行所截获的通信事件的指令包或者数据包，让通信事件继续进行，这样，第二过滤驱动后续才能收到报文。

上述步骤S303中，第二过滤驱动接收到第一过滤驱动发送的进程ID及对应的IP地址和端口号信息时，在本地维护一个IP、端口和进程ID的对应列表，这样，在步骤S304中，当第二过滤驱动捕获到应用程序收发的报文时，可以根据该报文中的IP和/或端口的信息，与维护的对应表进行匹配，查找该报文所属的进程ID。

进一步地，当第一过滤驱动截获到某个通信事件结束的指令包时，获取该指令包中包含的该通信事件相关的IP地址、端口号信息以及对应的进程ID，将获取到的IP地址、端口号信息以及对应的进程ID携带在指示该通信事件结束的指令中发送给第二过滤驱动；

第二过滤驱动根据第一过滤驱动发送的指示该通信事件结束的指令，删除本地保存的与之匹配的IP地址、端口号信息以及对应的进程ID的记录。

下面一个具体的例子来说明本发明实施例提供的上述获知报文所属进程的方法，在该实例中，第一过滤驱动为TDI过滤驱动，第二过滤驱动为NDIS中间层驱动，驱动架构图如图4所示。

该实例的流程如图5所示，包括下述步骤：

1、应用程序向外发起Socket连接。

应用程序对外Socket连接，先是创建一个Socket，会使用IRP指令指示创建地址对象、连接终端对象，这时候TDI过滤驱动(即第一过滤驱动)把应用程序进程ID和地址对象绑定；应用程序调用connect函数对外连接时，Windows的I/O管理器会下发一个含TDI CONNECT命令的IRP指令。

2、TDI过滤驱动截获含TDI CONNECT命令的IRP指令，从中提取出协议、IP、端口号信息；根据IRP中的地址对象，结合步骤1的绑定关系，查知应用程序的进程ID。

3、TDI过滤驱动获取这些信息后，先不下发所截获的IRP指令，而是建立跟NDIS中间层驱动之间的通信，新建一个IRP，将该通信事件相关的协议、双方IP、双方端口号、对应的进程ID信息，通过该新建的IRP通知给NIDS中间层驱动(即第二过滤驱动)。

4、NDIS中间层驱动将这些信息保存在IP、端口号信息和进程ID的对应表里面。

5、NDIS中间层驱动向TDI过滤驱动返回IRP反馈。

本步骤5中，为了迅速地反馈，NDIS中间层可不用生成新的IRP，直接反馈之前TDI过滤驱动发送的IRP给TDI过滤驱动即可。

6、TDI过滤驱动等待发出通知的IRP返回后，放行原先截获的socket相关IRP指令，使通信继续进行。

7、这个IRP指令进过协议层，成为TCP连接的握手报文，并经过NDIS中间层驱动下发给网卡驱动。NDIS中间层驱动从报文中提取出双方IP地址和端口，与对应表中的信息进行匹配，获知该报文属于哪个进程ID。

8、应用程序的通信继续进行，TDI过滤驱动对收发数据的IRP全部放行，NDIS中间层驱动从截获的收发报文中，提取出双方IP地址和端口，与匹配队列中的信息进行匹配，获知该报文属于哪个进程ID。

9、TDI过滤驱动捕获到Socket连接断开的IRP指令，从中获取到通信双方的IP地址、端口和进程ID。

10、TDI过滤驱动将获取到的IP地址、端口号信息和进程ID通过IRP指令发给NDIS中间层驱动，告知socket连接断开。

11、NDIS中间层驱动将维护的对应表中的该IP地址、端口和进程ID的记录删除。

12、NDIS中间层驱动返回IRP反馈。

类似地，本步骤12中，为了迅速反馈，NDIS中间层可不用生成新的IRP，直接反馈之前TDI过滤驱动发送的IRP给TDI过滤驱动即可。

上述流程中，TDI过滤驱动发送IRP信息给NDIS驱动，所花费的时间很短，并且由于只会在连接建立和断开时各发送一次，不会对应用程序的通信效率造成影响。

上述实例是以监测到应用程序向外发起Socket连接为例说明的，对于应用程序接收外部的Socket连接、或者通过监测UDP通信等方式的流程，由于这些过程中都会涉及到TDI创建地址对象的过程，在这个过程中，TDI过滤驱动可以获知本地IP、端口号和进程ID的关联关系，TDI过滤驱动将这种关联关系告知NDIS中间层驱动，这样，在后续Socket连接或者数据包收发的过程中，就可以根据这些关联关系，获知报文所属ID，与上述实例的流程类似，在此不再赘述。

本发明实施例还提供了一种根据进程ID对应用程序进行访问控制的方法，如图6所示，包括：

S601、在AFD驱动和协议驱动之间部署的第一过滤驱动对应用程序的通信事件进行监测；

S602、当监测到存在应用程序发生通信事件时，第一过滤驱动根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID；

S603、第一过滤驱动将获取的IP地址、端口号信息以及对应的进程ID，发送给部署于协议驱动和网卡驱动之间的第二过滤驱动；

S604、第二过滤驱动接收IP地址、端口号信息以及对应的进程ID并保存；

S605、当第二过滤驱动接收到应用程序收发的报文时，根据该报文中的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定所述报文所属的进程ID；

S606、第二过滤驱动根据预先设置的各进程ID对应的访问控制策略，对该应用程序的通信事件进行相应的访问控制操作。

上述步骤S601-S605的具体实施过程与步骤S301-S305的实施过程类似，在此不再赘述，在上述步骤S606中，第二过滤驱动(例如NDIS中间层驱动)可以根据原先的业务设定，对特定的进程的报文，做个性化地处理，比如：对某个应用程序发送的报文加密，对接收的报文解密，以保护业务数据；对浏览器类的进程，如果其访问外网IP，除了特定的服务器IP之外，其余的数据包都丢弃，可以保证本机在只能访问外网中特定的网站；或者NDIS中间层驱动对应用程序发出的数据包都不做任何处理等等。

基于同一发明构思，本发明实施例还提供了一种获知报文所属进程的装置、应用程序的访问控制装置及网络通信设备，由于这些装置和设备所解决问题的原理与前述获知报文所属进程的方法及应用程序的访问控制方法相似，因此该装置和设备的实施可以参见前述方法的实施，重复之处不再赘述。

本发明实施例提供的一种获知报文所属进程的装置，如图7所示，包括：

第一过滤驱动模块701，部署在AFD驱动和协议驱动之间，用于对应用程序的通信事件进行监测；当监测到存在应用程序发生通信事件时，根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID并发送给第二过滤驱动模块702；

第二过滤驱动模块702，部署于协议驱动和网卡驱动之间，用于接收IP地址、端口号信息以及对应的进程ID并保存；以及当接收到应用程序收发的报文时，根据接收的IP地址、端口以及对应的进程ID，确定该报文所属的进程ID。

进一步地，上述第一过滤驱动模块701，具体用于对应用程序的TCP和/或UDP通信动作进行监测。

进一步地，上述第一过滤驱动模块701，具体用于将获取的所述IP地址、端口号信息以及对应的进程ID携带在IRP指令中，并将该IRP指令发送给所述第二过滤驱动模块。

进一步地，上述第一过滤驱动模块701，具体用于截获通信事件的指令包或者数据包，根据指令包或者数据包中包含的IP地址、端口号信息以及对应的进程ID。

进一步地，上述第二过滤驱动模块702，还用于在接收到第一过滤驱动模块701发送的IP地址、端口以及对应的进程ID之后，向第一过滤驱动模块701发送接收确认；

相应地，上述第一过滤驱动模块701，还用于在接收到第二过滤驱动702发送的接收确认后，放行所截获的通信事件的指令包或者数据包，让通信事件继续进行。

较佳地，上述第一过滤驱动模块701为TDI过滤驱动，第二过滤驱动模块702为NDIS中间层驱动。

进一步地，上述第一过滤驱动模块701，还用于当截获到所述通信事件结束的指令包时，获取所述指令包中包含的该通信事件相关的IP地址、端口号信息以及对应的进程ID，将获取到的IP地址、端口号信息以及对应的进程ID携带在指示该通信事件结束的指令中发送给所述第二过滤驱动模块702；

第二过滤驱动模块702，还用于根据第一过滤驱动模块701发送的指示该通信事件结束的指令，删除本地保存的与之匹配的IP地址、端口号信息以及对应的进程ID的记录。

本发明实施例提供的一种应用程序的访问控制装置，如图8所示，包括：

第一过滤驱动模块801，部署在AFD驱动和协议驱动之间，用于对应用程序的通信事件进行监测；当监测到存在应用程序发生通信事件时，根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID并发送给第二过滤驱动模块802；

第二过滤驱动模块802，部署于协议驱动和网卡驱动之间，用于接收所述IP地址、端口号信息以及对应的进程ID并保存；以及当接收到应用程序收发的报文时，根据接收的IP地址、端口以及对应的进程ID，确定所述报文所属的进程ID，以及根据预先设置的各进程ID对应的访问控制策略，对该应用程序的通信事件进行相应的访问控制操作。

本发明实施例提供的一种网络通信设备，包括本发明实施例提供的上述获知报文所属进程的装置和/或本发明实施例提供的上述应用程序的访问控制装置。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本发明实施例提供的获知报文所属进程的方法、访问控制方法、装置及网络通信设备，部署在AFD驱动和协议驱动之间第一过滤驱动对应用程序的通信事件进行监测；获取通信事件相关的IP地址、端口号信息以及对应的进程ID，并发送给部署在协议驱动和网卡驱动之间的第二过滤驱动，这样，第二过滤驱动在收到应用程序收发的报文时，可以根据该报文的IP地址和/或端口号信息，以及所保存的IP地址、端口号信息以及对应的进程ID，确定该报文所属的进程ID。进而可以使用不用进程ID对应的访问控制策略对应用程序进行访问控制，本发明实施例解决了网络通信的较低层(内核中)获知报文所属进程ID的问题，实现了对应用程序粒度的访问控制。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种获知报文所属进程的方法，其特征在于，包括：

在辅助功能驱动AFD和协议驱动之间部署的第一过滤驱动对应用程序的通信事件进行监测；

2.如权利要求1所述的方法，其特征在于，第一过滤驱动对应用程序的通信事件进行监测，包括：

所述第一过滤驱动对应用程序的传输控制协议TCP和/或用户数据报协议UDP通信动作进行监测。

3.如权利要求1所述的方法，其特征在于，TDI过滤驱动将获取的所述IP地址、端口号信息以及对应的进程ID，发送给第二过滤驱动，包括：

所述第一过滤驱动将获取的所述IP地址、端口以及对应的进程ID携带在IRP指令中，并将所述IRP指令发送给所述第二过滤驱动。

4.如权利要求1-3任一项所述的方法，其特征在于，第一过滤驱动根据所发生的通信事件，获取该通信事件相关的IP地址、端口号信息以及对应的进程ID，具体包括：

第一过滤驱动截获所发生的通信事件的指令包，获取所述指令包中包含的该通信事件相关的IP地址、端口号信息以及对应的进程ID。

5.如权利要求4所述的方法，其特征在于，第一过滤驱动将所述IP地址、端口号信息以及对应的进程ID，发送给第二过滤驱动之后，还包括：

第一过滤驱动接收到第二过滤驱动发送的接收确认；

第一过滤驱动根据所述接收确认，放行所截获的通信事件的指令包或者数据包，让通信事件继续进行。

6.如权利要求1-3任一项所述的方法，其特征在于，还包括：

当所述第一过滤驱动截获当截获到所述通信事件结束的指令包时，获取所述指令包中包含的该通信事件相关的IP地址、端口号信息以及对应的进程ID，将获取到的IP地址、端口号信息以及对应的进程ID携带在指示该通信事件结束的指令中发送给所述第二过滤驱动；

所述第二过滤驱动根据第一过滤驱动发送的指示该通信事件结束的指令，删除本地保存的与之匹配的IP地址、端口号信息以及对应的进程ID的记录。

7.一种应用程序的访问控制方法，其特征在于，包括：

8.一种获知报文所属进程的装置，其特征在于，包括：

9.如权利要求8所述的装置，其特征在于，所述第一过滤驱动模块，具体用于对应用程序的TCP和/或UDP通信动作进行监测。

10.如权利要求8所述的装置，其特征在于，所述第一过滤驱动模块，具体用于将获取的所述IP地址、端口号信息以及对应的进程ID携带在IRP指令中，并将所述IRP指令发送给所述第二过滤驱动模块。

11.如权利要求8-10任一项所述的装置，其特征在于，所述第一过滤驱动模块，具体用于截获通信事件的指令包或者数据包，获取所述指令包或者数据包中包含的IP地址、端口号信息以及对应的进程ID。

12.如权利要求11所述的装置，其特征在于，所述第二过滤驱动模块，还用于在接收到第一过滤驱动模块发送的IP地址、端口以及对应的进程ID之后，向所述第一过滤驱动模块发送接收确认；

所述第一过滤驱动模块，还用于在接收到第二过滤驱动发送的接收确认后，放行所截获的通信事件的指令包或者数据包，让通信事件继续进行。

13.如权利要求8-10任一项所述的装置，其特征在于，所述第一过滤驱动模块，还用于当截获到所述通信事件结束的指令包时，获取所述指令包中包含的该通信事件相关的IP地址、端口号信息以及对应的进程ID，将获取到的IP地址、端口号信息以及对应的进程ID携带在指示该通信事件结束的指令中发送给所述第二过滤驱动模块；

第二过滤驱动模块，还用于根据第一过滤驱动模块发送的指示该通信事件结束的指令，删除本地保存的与之匹配的IP地址、端口号信息以及对应的进程ID的记录。

14.如权利要求8-10任一项所述的装置，其特征在于，所述第一过滤驱动模块为TDI过滤驱动，所述第二过滤驱动模块为NDIS中间层驱动。

15.一种应用程序的访问控制装置，其特征在于，包括：

16.一种网络通信设备，其特征在于，包括如权利要求8-14任一项所述的获知报文所属进程的装置和/或如权利要求15所述的应用程序的访问控制装置。