如何用IP Queue机制编写用户态防火墙

一般而言，防火墙都是嵌入在Linux内核协议栈的处理过程中，运行在内核地址空间。这就要求开发者深入理解和掌握内核，以及内核协议栈的代码。对于普通开发者来说，此要求显然过于苛刻。为此，Linux内核在Netfilter框架的基础上提供了IP Queue机制，使得基于用户态（User Mode）的防火墙开发成为可能。

下面详细阐述IP Queue的原理及其编程接口。

内核报文处理流程

首先，大致了解一下内核处理数据报文的流程。正确理解这个流程，对于编写完善的防火墙非常有帮助。

如图1所示，在内核的IP报文处理过程中，散布了一些HOOK点(图中椭圆形的节点)，在这些点上，可以挂载外部处理函数，进行定制的报文处理。

图1 Linux内核报文处理流程简图

数据报文从图1左边“接收”处进入内核协议栈，经过HOOK点PRE_ROUTING后，进行路由选择。若是发往本机的IP报文，则在经过HOOK点LOCAL_IN后提交给本地的上层协议处理。如果是需要转发的IP报文，则该报文在依次经过FORWARD和POST_ROUTING两个HOOK点后，被发往网络接口。

本地输出的IP报文将先通过HOOK点LOCAL_OUT，再根据路由选择，经过HOOK点POST_ROUTING以后，被发往网络接口。

上述这些HOOK点挂载的处理函数将返回适当的值，告知协议栈应该如何继续处理当前报文。具体分为以下各值：

NF_DROP 丢弃该报文，释放所有与该报文相关的资源；

NF_ACCEPT 接受该报文，并继续处理；

NF_STOLEN 该报文已经被HOOK函数接管，协议栈无须继续处理；

NF_QUEUE 将该报文传递到用户态去做进一步的处理；

NF_REPEAT 再次调用本HOOK函数。

当HOOK处理函数返回NF_QUEUE值时，内核协议栈将通过Linux NetLink通信机制把当前报文传递到用户态，由用户态的防火墙程序进行处理。这样，只要能够在相应的HOOK点上返回NF_QUEUE值，就可以安心地在用户态使用自己的程序来过滤报文了，这个功能可以由iptables实现。

NetLink机制

上面提到，使用IP Queue的用户态防火墙程序是通过NetLink机制和内核协议栈进行通信的。NetLink是Linux系统特有的、基于Socket编程接口的通信机制。

它是一个面向数据报文的服务，并提供“路由操作(NETLINK_ROUTE)”、“IP Queue操作(NETLINK_FIREWALL)”和“用户态ARP表操作(NETLINK_ARPD)”等通信协议。在创建IPQueue NetLink Socket时，将采用如下系统调用：

fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_FIREWALL);

这里，PF_NETLINK指明要创建NetLink Socket；SOCK_RAW指明采用原始套接字，也可以采用SOCK_DGRAM，因为NetLink机制的实现并不区分SOCK_RAW和SOCK_DGRAM；参数NETLINK_FIREWALL则指明通信协议采用IP Queue。

既然IP Queue是基于NetLink的，其消息格式自然也遵从NetLink的规范。NetLink消息由两部分组成：消息头(struct nlmsghdr)和数据负载(data payload)。

消息头的定义如下：

　　struct nlmsghdr{
　　
　　__u32 nlmsg_len; /*消息长度*/
　　__u16 nlmsg_type;/*消息类型*/
　　__u16 nlmsg_flags;/*额外的标志*/
　　__u32 nlmsg_seq; /*序列号*/
　　__u32 nlmsg_pid; /*进程号*/
　　};

所有的IP Queue消息都将包含一个struct nlmsghdr消息头，具体的IP Queue消息则包含在NetLink消息的数据负载中。有关NetLink消息格式的详情可以参见手册页Netlink(7)。

IP Queue编程接口

使用IP Queue机制的程序必须包含如下的头文件：

#include<linux/netfilter_ipv4/ip_queue.h>

在这个头文件中定义了所有IP Queue消息的格式。

IP Queue消息可以分为两大类：由内核协议栈发给用户态进程的IP Queue消息和由用户态进程发给内核的IP Queue消息。

由内核协议栈发给用户态进程的IP Queue消息(nlmsghdr.nlmsg_type = IPQM_PACKET)，其数据类型为ipq_packet_msg_t，定义如下：

　　typedef struct ipq_packet_msg {
　　unsigned long packet_id; /* 报文的标识号 */
　　unsigned long mark; /* Netfilter标记值 */
　　long timestamp_sec; /* 报文到达时间（秒） */
　　long timestamp_usec; /* 报文到达时间（毫秒） */
　　unsigned int hook; /* 所处的HOOK点 */
　　char indev_name[IFNAMSIZ]; /* 接收网络接口名 */
　　char outdev_name[IFNAMSIZ]; /*发送网络接口名*/
　　unsigned short hw_protocol; /* 硬件协议（网络顺序）*/
　　unsigned short hw_type; /* 硬件类型 */
　　unsigned char hw_addrlen; /* 硬件地址长度 */
　　unsigned char hw_addr[8]; /* 硬件地址 */
　　size_t data_len; /* 报文的长度 */
　　unsigned char payload[0]; /* 报文本身 */
　　} ipq_packet_msg_t;

这个数据结构也被称为“报文的元数据”。内核除可以单独向用户进程传递“报文的元数据”以外，也可以同时传递报文本身。此时，报文本身将存储在ipq_packet_msg_t数据成员payload开始的地方。

由用户态进程发给内核的消息，其数据类型为ipq_peer_msg_t，定义如下：

　　typedef struct ipq_peer_msg {
　　union {
　　ipq_verdict_msg_t verdict;
　　ipq_mode_msg_t mode;
　　} msg;
　　} ipq_peer_msg_t;

由上述定义可知，这类消息又分为“模式设置消息(nlmsghdr.nlmsg_type = IPQM_MODE)”和“断言消息(nlmsghdr.nlmsg_type = IPQM_VERDICT)”两个子类。

“模式设置消息”的数据类型定义如下：

　　typedef struct ipq_mode_msg {
　　unsigned char value;/* 请求的模式 */
　　size_t range;/* 请求拷贝的报文长度 */
　　} ipq_mode_msg_t;
　　

这里，请求模式value的值可以是IPQ_COPY_NONE、IPQ_COPY_META和IPQ_COPY_PACKET。当指定请求模式value为IPQ_COPY_NONE时，报文将被丢弃；当为IPQ_COPY_META时，内核将在其后的报文传递中只传递“报文的元数据”；当为IPQ_COPY_PACKET时，内核将同时传递“报文的元数据”和报文本身，报文本身的传递长度由ipq_mode_msg_t的另一个数据成员range指定。IP报文的最大长度为0xFFFF。

另一子类即“断言消息”，其数据类型定义如下：

　　typedef struct ipq_verdict_msg {
　　unsigned int value;
　　unsigned long id;
　　size_t data_len;
　　unsigned char payload[0];
　　} ipq_verdict_msg_t;
　　

其中，value是用户态程序回传给内核的当前报文的处理意见，可以是NF_ACCEPT或NF_DROP等值。id则是用以区分报文的标识号，即内核传来的ipq_packet_msg_t结构中的packet_id。当用户态程序修改了当前报文以后，需要将报文重新传递回内核，此时，新的报文内容必须存储在payload的开始处，并由data_len指明新报文的长度。

从上述内容可以看出，在整个IP Queue的报文传递过程中，用户态程序和内核协议栈之间的互动顺序是，首先，用户态程序利用“模式设置消息”告诉内核协议栈所请求的报文传递模式。

然后，根据这个模式，内核组织好等待传递的消息，通过NetLink Socket发给用户态程序。最后，用户态程序根据自己的防火墙规则，得出该报文的处理意见（可能同时修改当前报文），并回传给内核。

编译和运行防火墙

要编译和运行防火墙程序，执行如下命令：

# gcc o ipqfw ipqfw.c

# ./ipqfw &

ipqfw.c是防火墙的代码文件。

为了在路由器上过滤转发的IP报文，需要运行如下命令：

# iptables A FORWARD j QUEUE

这样，所有经过HOOK点FORWARD的报文都将被送到用户态防火墙进行处理，用户可以自行编写适合具体情况的防火墙。