LINUX2.4.x kernel Network Security Framework

Article Title: Detailed description of LINUX2.4.x kernel network security framework. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

1. Overview

Before analyzing the implementation of LINUX2.4.x network security, we will briefly introduce several important concepts in LINUX2.4.x: netfilter, iptables, match, target, nf_sockopt_ops, and network security functions. The detailed explanation will be discussed in later analysis.

The first is netfilter, which defines the check points in the protocol stack and the data structures referenced at the check points, as well as the process of referencing these structures at the check points. Iptables defines the organization of Rules for Implementing network security functions and the operations on rules. A rule contains zero or more matches and one target. The rule organization follows the chain and rule concept in LINUX2.2.x, but adds the table concept. The relationship between the three is: table is the sum of all the rules to implement a function. chain is the set of rules referenced at a Check Point, and rule is a separate rule. Match is used in the rule to match various parameters in the data packet. Each match matches a specific parameter. Therefore, a rule can have multiple matches, including the system-defined match, it also includes the match added through the kernel module. Target determines in the rule how to process the matched data packets, so it implements the specific network security function in target. Nf_sockopt_ops is a data structure referenced in get/setssockopt by the system call. It allows you to add, delete, modify, and query rules in a user space. The above structure must be registered to the system before it can be referenced.

LINUX2.4.x Network Security implements packet filtering, address conversion (including the address camouflage and transparent proxy functions in LINUX2.2.x, and other extension functions), connection tracking (this is the basis for realizing address conversion, it records and monitors the connection status, similar to status detection), Mangle (a new feature of LINUX2.4.x, it checks data packets but does not prohibit, discard, or allow the determination ). To implement these functions, you must register the data structures of netfilter, iptables, match, target, and nf_sockopt_ops. To implement other new functions, you only need to define the corresponding structure and register it to the system, and use the user space configuration tool (this configuration tool must also support the new structure) add it to the rule. These structures are automatically referenced in rules.

2. netfilter

Netfilter defines the data structures referenced by checkpoints and checkpoints in the protocol stack and the process of referencing these data structures. First, let's look at the data structure referenced at the check point ,:

In the figure, ns_hook_ops is the structure referenced at the check point. Each protocol stack pre-defined 8 Linked List arrays are used to save these structures. These linked lists correspond to checkpoints in the protocol stack one by one. In practice, these eight linked lists are not always used. For example, in IPV4, only five checkpoints are defined, which correspond to the first five linked lists respectively. The structure of nf_hook_ops is as follows:

Struct nf_hook_ops

{

Struct list_head list;

Nf_hookfn hook;/* function pointer */

Int pf;/* protocol stack number corresponding to the structure */

Int hooknum;/* Check Point number corresponding to the structure */

Int priority;/* structure priority */

};

The nf_register_hook function registers the ns_hook_ops structure to these linked lists. The index of the linked list is specified by hooknum in the structure. The structures on the same linked list are sorted by priority values from small to large. When these structures are referenced at the check point, they are referenced sequentially on the linked list.

The checkpoint is defined by the macro NF_HOOK. At the Check Point, the function nf_hook_slow calls the function nf_iterate to traverse the corresponding linked list and calls the function defined in the structure ns_hook_ops on the linked list. If the function in the structure returns NF_ACCEPT, the function in the next structure will be called. If the function in the structure returns NF_DROP, NF_STOLEN, or NF_QUEUE, the value will be returned to nf_hook_slow; if the function in the structure returns NF_REPEAT, the function in this structure will be called again. If the function is in the last structure of the linked list, the return value of the function in this structure will be returned to ns_hook_slow. Determine the returned value of nf_iterate in ns_hook_slow. If it is NF_ACCEPT, the data packet is allowed to pass and the data packet is passed to the next function in the protocol stack. If it is NF_DROP, the data packet is released, the protocol stack process is interrupted. If NF_STOLEN is used, the protocol stack process is also interrupted, but the packet is not released. If NF_QUEUE is used, the packet is sent to the user space for processing, the process of interrupting the protocol stack at the same time.

The checkpoint is distributed in the protocol stack process and is a checkpoint in IPV4:

The checkpoint name in the figure is as follows:

Checkpoint No. Checkpoint name checkpoint file name

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

Table 2.1 IPV4 checkpoint name

In the figure, ROUTE (1) performs a ROUTE query on the received package and determines whether the package needs to be forwarded or sent to the upper-layer package of the Local Machine. ROUTE (2) find the route for the sent package. The NF_IP_PRE_ROUTING field checks all packets passed into the IP layer. Before that, the packet version, length, checksum, and other correctness checks have been completed. NF_IP_LOCAL_IN checks the packets sent to the upper layer of the local machine. Note the differences between these two checkpoints and those in LINUX2.2.x. In LINUX2.2.x, there is no difference between the packages sent to the upper layer of the local host and those to be forwarded, therefore, after the address disguise is completed, a route lookup function is called again to find the route for the packets after the disguise is solved. Check the data packets to be forwarded at NF_IP_FORWARD. NF_IP_POST_ROUTING checks all data packets transmitted to the link layer. Note that the route of the data packets is determined. NF_IP_LOCAL_OUT checks the packets sent from the local machine. The route here is not yet determined, so the destination address can be converted. To implement a network security function, you may need to register the corresponding structure on multiple check points. In the following analysis, we can see the specific example.

3. iptables

Iptables allows you to manage and access rules. It has several important data structures, ipt_entry, ipt_match, ipt_target, and ipt_table, which are used to construct rule tables. An important function, ipt_do_table, is used to traverse the rule table and process the structure of the rule table.

Ipt_entry is the data structure of the rule, as follows:

Struct ipt_entry

{

Struct ipt_ip ip;

Unsigned int nfcache;

U_int16_t target_offset;/* offset of the target in the Rule */

U_int16_t next_offset;/* offset of the next rule */

Unsigned int comefrom;

Struct ipt_counters counters;/* statistical count of packets matching rules */

Unsigned char elems [0];

};

In ipt_entry, ipt_ip is a basic match, which is fixed and used to match the source address/source port, Destination Address/destination port, and Protocol of the data packet. Other matches are added as needed, and the number is not fixed. Therefore, there is a variable length character array in ipt_entry to save the match pointer in the rule. These pointers point to the match registered in the system. Each rule has a target, which determines how to process the data packet after the data packet completely matches the rule. It is also a pointer to the target registered by the system, and is also placed in the variable-length character array mentioned above.

[1] [2] [3] Next page