LINUX2.4.x Network Security Framework

LINUX2.4.x network security framework-Linux Enterprise Application-Linux server application information. For more information, see. 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 ,:



(400) {this. resized = true; this. width = 400; this. alt = 'click here to open new window';} "onmouseover =" if (this. resized) this. style. cursor = 'hand'; "onclick =" window. open ('HTTP: // security.ccidnet.com/col/attachment/2004/6/302367.jpg'); ">

. 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:



(400) {this. resized = true; this. width = 400; this. alt = 'click here to open new window';} "onmouseover =" if (this. resized) this. style. cursor = 'hand'; "onclick =" window. open ('HTTP: // security.ccidnet.com/col/attachment/2004/6/3022.16.jpg'); ">

. 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 the chain created by the user. All tables are registered in a linked list, while chain and rule are connected to a one-way linked list using the offset value next_offset. The user space configuration tool obtains the rule table in the kernel to the user space before adding or deleting rules, and then adds or deletes the rules in the user space, then, the modified rule table is passed to the kernel space, and the functions in the kernel space perform subsequent conversion and check.

The ipt_do_table function traverses the rules on the table. In fact, the pointer of this function is saved in the nf_hook_ops structure and called at the check point. When calling this function, you must specify the pointer to the table it traverses and the value of the checkpoint that calls it. The checkpoint value is used to locate the default chain position in the table. As we mentioned above, the default chain corresponds to the checkpoint and check the rules of the corresponding chain at the checkpoint. Traverse the rule. If a matching rule is found, call the function defined in the target of the rule and return the returned value to the function that calls ipt_do_table. If no matching rule is found, call the target defined function of the last rule in the default chain. The return value of this function is the policy of this chain.

4. nf_sockopt_ops

As mentioned above, the network security framework of LINUX2.4.x supports multiple protocols. The system calls get/setsockopt to configure and query rules. When calling these two system calls, different protocols use different parameters. Therefore, each protocol stack that implements the network security function defines its own nf_sockopt_ops structure and registers it to the linked list of the system. When you call get/setsockopt, you can decide which nf_sockopt_ops to reference based on different parameters to complete the real work.

5. Implementation of Network Security Functions

To implement network security in LINUX2.4.x, you need to do the following: First, define the nf_hook_ops structure and register it into netfilter; second, define the iptable, match, and target structures, and register it in iptables. If necessary, you must register the nf_sockopt_ops structure to handle special get/setsockopt parameters. The Function Point in IPV4 is registered to the nf_hook_ops structure in netfilter:



(400) {this. resized = true; this. width = 400; this. alt = 'click here to open new window';} "onmouseover =" if (this. resized) this. style. cursor = 'hand'; "onclick =" window. open ('HTTP: // security.ccidnet.com/col/attachment/2004/6/302371.jpg'); ">

. 1 structure registered by IPV4 function points on each check point

(In the figure, conntrack indicates connection tracking; Filter indicates packet filtering; NAT (src) indicates source address translation; NAT (dst) indicates destination address translation; Mangle is a new feature in LINUX2.4.x, checks data packets, but does not determine whether to prohibit or allow data packets. This is different from filters. In the implementation before LINUX2.4.18, Mangle only registers the nf_hook_ops structure on the NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT check points. In the implementation after LINUX2.4.18, The nf_look_ops structure is registered on the five check points .)

In the figure, the nf_hook_ops structure is arranged from top to bottom in the order of calls. We can see that the calling sequence of the same function point varies with the check point, which is related to the actions performed by the Function Point. For example, on NF_IP_LOCAL_IN, if the status of the data packet is recorded in the Conntrack and disabled in the Filter before the Filter is performed, the status related to the data packet will not be complete, A Conntrack structure is wasted. Therefore, Filter should be called first. If the returned value is NF_ACCEPT, Conntrack is called.

The following table lists the structure of ipt_table, ipt_match, ipt_target, and nf_sockopt_ops registered on the function:

Feature name
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




Table 5.1 data structure registered by Function Points

It is worth noting that the Conntrack does not register any rule table, indicating that it does not need rules to decide whether to perform connection tracking. At the same time, it registers an nf_sockopt_ops structure. This structure processing parameter SO_ORIGINAL_DST is used to obtain the destination address of the transparent proxy. Detailed analysis of address translation and Connection Tracing will be described in a future article.

6. Summary

The Network Security Implementation in LINUX2.4.x has significantly improved compared with LINUX2.2.x. First, the IPV4 protocol stack has more reasonable checkpoints to avoid unnecessary function calls when implementing various functional points. Secondly, its architecture is highly scalable. Separates the function implementation from the framework so that you do not have to modify the framework when implementing the function, but just register the corresponding structure. In addition, the network security framework provides more functions than LINUX2.2.x, and supports more protocol stacks than LINUX2.2.x. Here we only analyze the general implementation of LINUX2.4.x network security. The implementation of a specific function will be analyzed in the following article. Through these analyses, we will learn how to add the functions we want to implement in the network security framework of LINUX2.4.x, and how to use the resources in the existing implementation to avoid conflicts with the existing implementation.

Author profile: Lin Feng, an independent contributor. Familiar with LINUX network security technology. The direction of interest is the implementation of the network protocol stack. Writing articles is to organize ideas, discover problems, and share experiences, knowledge, or lessons with more people. The email address is a droplet@163.net, which can be criticized, encouraged, or corrected.