LINUX2.4.x网络安全框架

　    在分析LINUX2.4.x网络安全的实现之前先简介一下它里面包括的几个重要概念：netfilter、iptables、match、target、nf_sockopt_ops、网络安全功能点的实现。详解会在后面的分析中讲到。 首先是netfilter，它定义了协议栈中的检查点和在检查点上引用的数据结构，以及在检查点上对这些结构引用的过程。iptables定义了实现网络安全功能的规则的组织以及对规则的操作。

一个规则中包括零个或多个match和一个target。规则组织沿用了LINUX2.2.x中的chain，rule的概念。可是添加了table的概念，这三者的关系是：table是实现某项功能全部规则的总和，chain是在某个检查点上所引用规则的集合，rule是一个单独的规则。match在规则中用于匹配数据包中的各项參数，每一个match匹配特定的參数，所以一个规则中能够有多个match，这包括系统已定义的match，也包括通过内核模块另外加入的match。target在规则中决定怎样处理匹配到的数据包。因此在target中实现了详细的网络安全功能。nf_sockopt_ops是在系统调用get/setssockopt中引用的数据结构，实现用户空间对规则的加入、删除、改动、查询等动作。以上的结构在使用之前必须先注冊到系统中才干被引用。
LINUX2.4.x网络安全实现了包过滤。地址转换（包括了LINUX2.2.x中的地址伪装和透明代理功能并有其它扩展功能），连接跟踪（这是实现地址转换的基础，在它里面实现了对连接状态的记录和监控。与状态检測类似）。Mangle（这是LINUX2.4.x新增的一个功能，它对数据包进行检查但不做禁止、丢弃或同意的推断）。实现这些功能点须要分别注冊netfilter。iptables。match，target。nf_sockopt_ops的数据结构。

假设实现其它新的功能，仅仅需定义对应的结构并将它注冊到系统中，而且通过用户空间的配置工具（这个配置工具也须支持新的结构）把它增加到规则中就能够了。这些结构在规则中自己主动被引用。

---

netfilter定义了协议栈中的检查点和检查点上引用的数据结构以及对这些数据结构引用的过程。首先看看在检查点上引用的数据结构，如图所看到的：

         图2.1 nf_hoo_ops数据结构的组织

图中ns_hook_ops就是在检查点上引用的结构。每一个协议栈预先定义的8个链表数组用于保存这些结构，这些链表与协议栈中的检查点一一相应。在实际的应用中。这8个链表并不一定都被使用。比方在IPV4中。仅仅定义了5个检查点，分别相应前5个链表。nf_hook_ops结构例如以下：

struct nf_hook_ops

{

            struct list_head list;

            nf_hookfn hook;          /* 函数指针 */

            int pf;                 /*  结构相应的协议栈号 */

            int hooknum;           /*  结构相应的检查点号*/

            int priority;         /*  结构的优先值 */

};

nf_register_hook函数将ns_hook_ops结构注冊到这些链表上，链表的索引由结构中hooknum指定。同一链表上的结构按优先值由小到大排列。在检查点上引用这些结构时，以它们在链表上的先后顺序引用。



          检查点由宏NF_HOOK定义。在检查点上。函数nf_hook_slow调用函数nf_iterate遍历相应链表并调用链表上的结构ns_hook_ops中定义的函数。

假设结构中的函数返回NF_ACCEPT。则继续调用下一个结构中的函数；假设结构中的函数返回NF_DROP或NF_STOLEN或NF_QUEUE，则将这个值返回给nf_hook_slow；假设结构中的函数返回NF_REPEAT,则反复调用此结构上的函数。假设到了链表上的最后一个结构。则把这个结构中函数的返回值返回给ns_hook_slow。

在ns_hook_slow中推断nf_iterate的返回值，假设是NF_ACCEPT，则同意数据包通过，并将数据包传递给协议栈中的下一个函数。假设是NF_DROP。则释放数据包，协议栈流程中断；假设是NF_STOLEN，相同中断协议栈的流程。可是没有释放这个数据包；假设是NF_QUEUE，则将这个包发送到用户空间处理，同一时候中断协议栈的流程。

检查点分布在协议栈的流程中，下图是IPV4中的检查点：

          图2.2 IPV4中的检查点

图中检查点的名称例如以下：



          检查点编号 检查点名称 检查点所在文件名称

          1 NF_IP_PRE_ROUTING ip_input.c 

          2 NF_IP_LOCAL_IN ip_input.c 

          3 NF_IP_FORWARD ip_forward.c 

          4 NF_IP_POST_ROUTING ip_output.c 

          5 NF_IP_LOCAL_OUT ip_output.c 



          表2.1 IPV4中检查点的名称



          图中，ROUTE(1)处对收到的包做路由查找并推断这个包是须要转发的包还是发往本机上层的包，ROUTE(2)处查找发出包的路由。NF_IP_PRE_ROUTING处对全部传入IP层的数据包进行检查，在这之前，有关数据包的版本号、长度、校验和等正确性检查已经完毕。

NF_IP_LOCAL_IN对发往本机上层的数据包进行检查。

请注意这两个检查点与LINUX2.2.x中检查点的差别。在LINUX2.2.x没有区分发往本机上层包和须要转发的包，所以在做完地址解伪装之后又调用了一次路由查找函数。为解伪装之后的包查找路由。NF_IP_FORWARD处检查须要转发的数据包。NF_IP_POST_ROUTING处对全部向链路层传递的数据包进行检查，注意在此处数据包的路由已经确定。NF_IP_LOCAL_OUT对本机发出的包进行检查，此处的路由还没有确定。所以能够做目的地址转换。

实现某个网络安全功能可能须要在多个检查点上注冊对应的结构，在后面的分析中我们能够看到详细的样例。

3. iptables 



          iptables实现对规则的管理和訪问。它里面有几个重要的数据结构ipt_entry，ipt_match，ipt_target，ipt_table，用于构造规则表。另一个重要的函数ipt_do_table，用于遍历规则表并处理规则表上的结构。

ipt_entry是规则的数据结构。例如以下：

struct ipt_table
{
            struct list_head list;
            char name[IPT_TABLE_MAXNAMELEN];
            struct ipt_replace table;            /* 用户空间传递的规则表 */
            unsigned int valid_hooks;          /* 有效的检查点置位*/
            rwlock_t lock;
            struct ipt_table_info private;      /* 规则表在内核中的存储结构 */
            struct module *me;
};

在ipt_table中。ipt_replace是用户空间配置程序传递给内核的规则表，这个规则表不能直接使用，必须先依据它里面包括的match和target的名称将match和target转换成在内核注冊的match和target的指针，另一项重要的工作是检查规则表中是否有循环，假设有循环，要给用户空间的配置程序报告错误。转换之后的规则表存储在ipt_table_info中。valid_hooks指示与这个表相关的检查点，并把相应的位置为1。一个table中能够有多个chain，chain分为系统默认的chain（与table注冊的检查点相应）和用户创建的chain。

全部的table都注冊放在一个链表中，而chain和rule则用偏移值next_offset连接成一个单向链表。

用户空间的配置工具在加入、删除规则之前先把内核中的规则表取到用户空间，然后在用户空间做加入或删除的动作。然后再将改动过的规则表传递到内核空间，由内核空间的函数完毕兴许的转换和检查。



          函数ipt_do_table遍历table上的规则，事实上这个函数的指针就保存在nf_hook_ops结构中。并在检查点上被调用。调用这个函数时须指定它遍历的table的指针和调用它的检查点的值。检查点的值用来定位table中默认chain的位置。前面我们提到。默认的chain是和检查点相应的，在检查点上检查相应chain的规则。

遍历规则，假设找到匹配的规则，则调用这条规则的target中定义的函数，并将它的返回值返回给调用ipt_do_table的函数。假设没有找到匹配的规则，则调用默认chain上最后一条规则的target定义的函数，这个函数的返回值就是这个chain的policy。

4. nf_sockopt_ops 



          前面提到LINUX2.4.x网络安全框架支持多种协议。

规则的配置和查询通过系统调用get/setsockopt完毕。

在调用这两个系统调用时，不同协议使用的參数不同，所以每一个实现网络安全功能的协议栈都定义了自己的nf_sockopt_ops结构并把它注冊系统的链表中。在调用get/setsockopt时依据不同的參数决定引用哪一个nf_sockopt_ops来完毕真正的工作。

5.网络安全功能点的实现 



          在LINUX2.4.x中实现网络安全的功能点须要做下面几件事情：一是定义nf_hook_ops结构。并将它注冊到netfilter中；二是定义iptable。match，target结构，并将它注冊到iptables中，假设须要还须注冊nf_sockopt_ops结构以便处理特殊的get/setsockopt參数。下图就是IPV4中的功能点注冊到netfilter中的nf_hook_ops结构：

图5.1 IPV4的功能点在各检查点上注冊的结构



          （图中conntrack代表连接跟踪；Filter代表包过滤；NAT(src)代表源地址转换，NAT(dst)代表目的地址转换；Mangle是LINUX2.4.x中新增的一个功能。完毕对数据包的检查，可是不正确数据包做禁止或放行的推断。与Filter不同。Mangle在LINUX2.4.18之前的实现中仅仅在NF_IP_PRE_ROUTING,NF_IP_LOCAL_OUT两个检查点上注冊了nf_hook_ops结构，在LINUX2.4.18之后的实现中在五个检查点上都注冊了nf_look_ops结构。）



          图中在每一个检查点上，nf_hook_ops结构按调用的先后顺序从上而下排列。

能够看到同样的功能点在不同的检查点上它的调用顺序并不同样。这与功能点所做的动作有关。比方在NF_IP_LOCAL_IN上假设Conntrack在Filter之前，假设数据包的状态在Conntrack中被记录而在Filter中被禁止，那么与这个数据包相关的状态就不会完整。浪费了一个Conntrack的结构。所以应该先调用Filter，假设它的返回值是NF_ACCEPT才调用Conntrack。

功能点上注冊的ipt_table，ipt_match。ipt_target，nf_sockopt_ops结构例如以下表所看到的：

功能点名称	ipt_table	ipt_match	ipt_target	nf_sockopt_ops
Filter	packet_filter
Nat	nat_table		ipt_snat_reg ipt_dnat_reg
Conntrack				so_getorigdst
Mangle	packet_mangler

表5.1 功能点注冊的数据结构



          值得指出的是连接跟踪（Conntrack）没有注冊不论什么规则表。说明它不须要规则来决定是否要作连接跟踪。同一时候它又注冊了一个nf_sockopt_ops结构。这个结构处理參数SO_ORIGINAL_DST，用于获得透明代理的目的地址。