Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of the LINUX 2.4.x kernel network security framework. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

1. Overview

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

The first is netfilter, which defines the checkpoints in the protocol stack and the data structures referenced on the checkpoints, as well as the process of referencing these structures at the checkpoints. Iptables defines the organization of rules that implement network security functions and the operation of rules. A rule contains zero or more match and a target. The rule organization follows the concept of chain,rule in LINUX2.2.x, but adds the concept of table. The relationship between these three is: table is the sum of all rules for implementing a function, chain is a collection of rules referenced at a checkpoint, and rule is a separate rule. Match is used in rules to match the parameters in a packet, and each match matches specific parameters, so there can be multiple match in a rule, including the match defined by the system and the match added through the kernel module. Target decides how to deal with matched packets in the rules, so it implements specific network security functions in target. Nf_sockopt_ops is a data structure referenced in the system call get/setssockopt, which realizes the actions of adding, deleting, modifying and querying rules in user space. The above structure must be registered with the system before it can be used.

LINUX2.4.x network security implements packet filtering, address translation (including address masquerading and transparent proxy functions in LINUX2.2.x and other extended functions), connection tracking (this is the basis for implementing address translation, in which the recording and monitoring of connection status is similar to state detection), Mangle (this is a new feature of LINUX2.4.x It examines the packet but does not make a forbidden, discarded, or allowed judgment. To implement these function points, you need to register the data structure of netfilter,iptables,match,target,nf_sockopt_ops separately. If you implement other new functions, just define the corresponding structure and register it with the system, and add it to the rules through the user space configuration tool (this configuration tool must also support the new structure). These structures are automatically referenced in the rules.

2.netfilter

Netfilter defines checkpoints in the protocol stack and the data structures referenced on checkpoints, as well as the process of referencing these data structures. First take a look at the data structure referenced on the checkpoint, as shown in the figure:

The ns_hook_ops in the figure is the structure referenced on the checkpoint. The eight linked list arrays predefined in each protocol stack are used to hold these structures, which correspond to the checkpoints in the protocol stack one by one. In practical applications, these eight linked lists are not necessarily used. For example, in IPV4, only five checkpoints are defined, corresponding to the first five linked lists. The structure of nf_hook_ops is as follows:

Struct nf_hook_ops

{

Struct list_head list

Nf_hookfn hook; / * function pointer * /

Protocol stack number corresponding to int pf; / * structure * /

Checkpoint number corresponding to int hooknum; / * structure * /

Priority value of int priority; / * structure * /

}

The nf_register_hook function registers the ns_hook_ops structure with these linked lists, and the index of the linked list is specified by hooknum in the structure. The structures on the same linked list are arranged from small to large according to priority values. When referencing these structures on a checkpoint, they are referenced in the order in which they are on the linked list.

Checkpoints are defined by the macro NF _ HOOK. At the checkpoint, the function nf_hook_slow calls the function nf_iterate to traverse the corresponding linked list and invokes the function defined in the structure ns_hook_ops on the linked list. If the function in the structure returns NF_ACCEPT, it continues to call the function in the next structure; if the function in the structure returns NF_DROP or NF_STOLEN or NF_QUEUE, it returns this value to nf_hook_slow;. If the function in the structure returns NF_REPEAT, the function on this structure is called repeatedly; if the last structure on the linked list is reached, the return value of the function in this structure is returned to ns_hook_slow. Judge the return value of nf_iterate in ns_hook_slow, if it is NF_ACCEPT, allow the packet to pass and pass the packet to the next function in the protocol stack; if it is NF_DROP, release the packet and interrupt the flow of the protocol stack; in the case of NF_STOLEN, also interrupt the flow of the protocol stack, but do not release the packet In the case of NF_QUEUE, the packet is sent to user space for processing while interrupting the flow of the protocol stack.

Checkpoints are distributed in the process of the protocol stack. The following figure shows the checkpoints in IPV4:

The names of checkpoints in the figure are as follows:

Checkpoint number checkpoint name file name where the checkpoint is located

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 names of checkpoints in IPV4

In the figure, ROUTE (1) does a route lookup of the received packet and determines whether the packet needs to be forwarded or sent to the upper layer of the machine, and ROUTE (2) looks up the route of sending the packet. All packets sent to the IP layer are checked at NF_IP_PRE_ROUTING, and before that, the version, length, checksum and other correctness checks of the packets have been completed. NF_IP_LOCAL_IN examines packets destined for the upper layers of the machine. Please note the difference between these two checkpoints and the checkpoints in LINUX2.2.x. In LINUX2.2.x, there is no distinction between the packets sent to the local upper layer and the packets that need to be forwarded, so the route lookup function is called again after the address uncamouflage is done to find a route for the packets after uncamouflage. Check for packets that need to be forwarded at NF_IP_FORWARD. Check all packets passed to the link layer at NF_IP_POST_ROUTING, and notice that the route of the packet has been determined here. NF_IP_LOCAL_OUT checks the packets sent by the machine, and the route here has not been determined, so the destination address translation can be done. To implement a network security function, you may need to register the corresponding structure at multiple checkpoints, as we can see in the later analysis.

3. Iptables

Iptables implements the management and access of rules. It has several important data structures, ipt_entry,ipt_match,ipt_target,ipt_table, for constructing rule tables. There is also an important function, ipt_do_table, that traverses the rule table and processes the structure on the rule table.

Ipt_entry is a regular data structure, as follows:

Struct ipt_entry

{

Struct ipt_ip ip

Unsigned int nfcache

Offset of u_int16_t target_offset;/* target in the rule * /

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

Unsigned int comefrom

Statistical count of packets for struct ipt_counters counters;/* matching rules * /

Unsigned char elems [0]

}

In ipt_entry, ipt_ip is a basic match, which is fixed and is used to match the source address / source port, destination address / destination port, protocol and so on. Other match are added as needed, and the number is not fixed, so there is a variable-length character array in ipt_entry to hold pointers to match in the rule, which point to the match registered in the system. Each rule has a target that determines what to do with the packet after it exactly matches the rule, which is also a pointer to the system-registered target and is also placed in the variable-length character array mentioned earlier. The target_offset in ipt_entry is the offset of target in the rule, the offset is the length from the starting address of the rule to the location of the target, and a variable next_offset indicates the next rule offset, which is actually the length of this rule.

It was mentioned earlier that the concepts of chain and rule in LINUX2.2.x are used in iptables, so how to distinguish between chain and rule in ipt_entry?

We know that a chain is a collection of rules checked at a checkpoint. 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 policy of chain. The call return value of target for the last rule of the user-created chain is NF_RETURN, and the traversal process will return the original chain. The target in the rule can also specify to jump to a user-created chain, where its target is ipt_stardard_target and the vertex value of this target is greater than 0. If no matching rule is found on the user-created chain, the traversal process returns to the next rule of the original chain.

Ipt_match is used to match the parameters of the packet, such as the flag bits in the TCP packet, the type in the ICMP protocol, and so on. Each match is interested in different parameters, so a rule may have multiple match. Ipt_target decides what to do after the packet exactly matches the rules. Both of these must be registered in the linked list of the system before they can be referenced by the rules. Do not do too much analysis of these two data structures, readers can refer to the source code.

Ipt_table is the data structure of the rule table, as follows:

Struct ipt_table

{

Struct list_head list

Char name[IPT _ TABLE_MAXNAMELEN]

Table of rules passed in struct ipt_replace table;/* user space * /

Unsigned int valid_hooks; / * valid checkpoint setting * /

Rwlock_t lock

Struct ipt_table_info private; / * Storage structure of rule table in kernel * /

Struct module * me

}

In ipt_table, ipt_replace is the rule table passed to the kernel by the user space configuration program. This rule table cannot be used directly. It must first convert match and target into pointers of match and target registered in the kernel according to the names of match and target contained in it. Another important task is to check whether there is a loop in the rule table. If there is a loop, report errors to the configuration program in user space. The transformed rule table is stored in ipt_table_info. Valid_hooks indicates the checkpoint associated with this table and sets the corresponding location to 1. There can be multiple chain,chain in a table divided into a system default chain (corresponding to a table registered checkpoint) and a user-created chain. All table are registered in a linked list, while chain and rule are joined into an one-way linked list with an offset value of next_offset.

This is the end of the article on "sample Analysis of LINUX 2.4.x Kernel Network Security Framework". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.