Network security framework of Linux kernel 2.4.x

Article Title: Network Security Framework of Linux kernel 2.4.x. 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 ,:
　　 　
　　 . 1 Organization of nf_hoo_ops Data Structure
　　
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:
　　 　
　　 . 2 check points 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. The target_offset in ipt_entry is the offset of the target in the rule. The offset is the length from the starting address of the rule to the position of the target. The next_offset variable also indicates the next rule offset, it is actually the length of this rule.
　　
As mentioned above, the chain and rule concepts in LINUX2.2.x are used in iptables. How can we differentiate the chain and rule in ipt_entry?
　　
We know that chain is a set of rules checked on a Check Point. In addition to the default chain, you can also create a new chain. In iptables, rules in the same chain are stored continuously. The target of the last rule of the default chain is the chain policy. The call return value of the target of the last rule of the chain created by the user is NF_RETURN. The original chain is returned during the traversal process. The target in the rule can also be specified to jump to the chain created by a user. In this case, its target is ipt_stardard_target, and the verdict value of this target is greater than 0. If no matching rule is found on the chain created by the user, the traversal process will return to the next rule of the original chain.
　　
Ipt_match is used to match the parameters of a data packet, such as the flag in the TCP data packet and the type in the ICMP protocol. Each match has different parameters, so a rule may have multiple matches. Ipt_target determines what kind of processing should be done after the data packet completely matches the rule. Both of them must be registered in the system's linked list before they can be referenced by rules. The two data structures are not analyzed too much. You can refer to the source code on your own.
　　
Ipt_table is the data structure of the rule table, as follows:
　　
Struct ipt_table
{
Struct list_head list;
Char name [IPT_TABLE_MAXNAMELEN];
Struct ipt_replace table;/* Rule table passed by user space */
Unsigned int valid_hooks;/* Valid checkpoint position */
Rwlock_t lock;
Struct ipt_table_info private;/* storage structure of the rule table in the kernel */
Struct module * me;
};
　　
In ipt_table, ipt_replace is the rule table that the user space configuration program passes to the kernel. This rule table cannot be directly used, you must first convert match and target into the pointer of the match and target registered in the kernel based on the match and target names contained in it, another important task is to check whether there is a loop in the rule table. If there is a loop, an error should be reported to the configuration program of the user space. The converted rule table is stored in ipt_table_info. Valid_hooks indicates the checkpoint related to the table and sets the corresponding position to 1. A table can have multiple chains. The chain is divided into the default chain (corresponding to the checkpoint registered in the table) and