|
NetFilter defines the checkpoints in the protocol stack and the data structures referenced on checkpoints, as well as the process of referencing those data structures. First look at the data structure referenced at the checkpoint, as seen in: Figure 2.1 Organization of NF_HOO_OPS data Structures
The ns_hook_ops in the figure is the structure referenced on the checkpoint. Each protocol stack has a predefined array of 8 linked lists to hold these structures, which correspond to checkpoint one by one in the protocol stack. In the actual application. These 8 lists are not necessarily used. For example, in IPV4. Only 5 checkpoints are defined, corresponding to the first 5 linked lists respectively. Nf_hook_ops structures such as the following:
struct nf_hook_ops{ struct list_head list; NF_HOOKFN Hook; /* Function pointer */ int pf; /* structure corresponding to the protocol stack number */ int hooknum; /* structure corresponding checkpoint number */ int priority; /* The priority value of the structure */}; |
The Nf_register_hook function assigns the NS_HOOK_OPS structure to these linked lists, and the index of the linked list is specified by Hooknum in the structure. Structures on the same list are arranged by priority values from small to large. When you reference these structures on a checkpoint, they are referenced in the order in which they are on the list.
The checkpoint is defined by the macro Nf_hook. On the checkpoint. The function Nf_hook_slow calls the function nf_iterate iterates through the corresponding linked list and invokes the function defined in the structure ns_hook_ops on the linked list. Assume that the function in the struct returns NF_ACCEPT. continues to invoke the function in the next struct, assuming that the function in the struct returns Nf_drop or Nf_stolen or Nf_queue, the value is returned to Nf_hook_slow, and if the function in the struct returns Nf_repeat, the function on this structure is called repeatedly. Assume the last structure on the list. The return value of the function in this structure is returned to Ns_hook_slow. The return value of Nf_iterate is inferred in Ns_hook_slow, assuming that it is nf_accept, agreeing to pass the packet and passing the packet to the next function in the protocol stack. The hypothesis is nf_drop. The packet is freed, the stack flow is interrupted, and the Nf_stolen is the same as the flow of the interrupt protocol stack. However, the packet is not released, and if it is nf_queue, it is sent to the user-space process, which interrupts the protocol stack at the same time.
Checkpoints are distributed in the process of the protocol stack and are checkpoints in IPV4:
Figure 2.2 Check points in the IPV4
The name of the checkpoint in the figure is as follows:
Checkpoint number checkpoint name Check Point 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 Name of the checkpoint in IPV4
In the diagram, route (1) Routes the packets received and infers whether the packet is a packet to be forwarded or a packet destined for the upper layer of the machine, and Route (2) looks for the route that sent the packet. Nf_ip_pre_routing the packet at all incoming IP layers is checked, before that, the correctness check of the data packet's version number, length, checksum, etc. is complete.Nf_ip_local_in checks packets destined for the upper layer of the machine. Note the difference between these two checkpoints and the checkpoint in linux2.2.x. In linux2.2.x, there is no distinction between packets destined for the upper deck and packets that need to be forwarded, so a route lookup function is called once the address has been spoofed. Find the route for the package after the spoofing. Nf_ip_forward Check the packets that need to be forwarded. Nf_ip_post_routing checks all packets passed to the link layer, noting that the routing of the packets here has been determined. Nf_ip_local_out checks the packets sent by the machine, and the routes here are not determined. So can do destination address translation. Implementing a network security feature may require a corresponding structure to be registered at multiple checkpoints, and we can see detailed examples in the subsequent analysis.
3. iptables
Iptables implements management and access to rules. It contains several important data structure ipt_entry,ipt_match,ipt_target,ipt_table, which are used to construct the rules table. Another important function, ipt_do_table, is to traverse the rules table and process the structure on the rules table.
Ipt_entry is the data structure of the rule. For example, the following:
struct ipt_table{ struct list_head list; Char Name[ipt_table_maxnamelen]; struct Ipt_replace table; /* User space pass the Rules table */ unsigned int valid_hooks; /* Valid checkpoint position */ rwlock_t lock; struct Ipt_table_info private; /* The storage structure of the rules table in the kernel */ struct module *me;}; |
In the ipt_table. Ipt_replace is a rule table that the user space Configurator passes to the kernel, which cannot be used directly, and must first convert match and target to the match and target pointers in the kernel register, based on the match and target names included in the code. Another important task is to check if there are loops in the rules table, with loops, to report errors to the configuration program for the user space. The rule table after conversion is stored in Ipt_table_info. Valid_hooks indicates the checkpoint associated with this table and places the corresponding position at 1. A table can have more than one chain,chain divided into the system default chain (corresponding to the check point of the table register) and user-created chain. All tables are placed in a list, while the chain and rule are connected to a one-way list with an offset value of next_offset. The User space Configuration tool takes the rules table in the kernel to the user space before adding or deleting rules, and then adding or deleting the user space. The changed rules table is then passed to kernel space, which is converted and checked by the function of kernel space.
The function ipt_do_table iterates through the rules on the table, in fact the pointer to the function is stored in the nf_hook_ops structure. and is called on the checkpoint. Calling this function specifies the pointer to the table it iterates through and the value of the checkpoint it is invoked on. The value of the checkpoint is used to position the default chain in table. We mentioned earlier. The default chain is the one that corresponds to the checkpoint and checks the rules for the corresponding chain on the checkpoint. The traversal rule, assuming that a matching rule is found, invokes the function defined in the target of this rule and returns its return value to the function calling Ipt_do_table. Assuming that no matching rule is found, call the function defined by the target of the last rule on the default chain, and the return value of this function is the chain policy.
4. nf_sockopt_ops
As mentioned earlier, the LINUX2.4.X network security framework supports multiple protocols.
The configuration and query of the rule is get/setsockopt through the system call. When invoking these two system calls, different protocols use different parameters, so each protocol stack that implements the network security feature defines its own nf_sockopt_ops structure and lists it in the list of systems. When calling Get/setsockopt, depending on the number of parameters, which nf_sockopt_ops to refer to to complete the real work.
5. implementation of network security function points
The function point of implementing network security in linux2.4.x need to do the following: First, define the nf_hook_ops structure. and register it in NetFilter, the second is to define iptable. Match,target structure and register it with the iptables, assuming that a nf_sockopt_ops structure is required to handle special get/setsockopt parameters. Is the function point in IPV4 to the nf_hook_ops structure in NetFilter:
Figure 5.1 The structure of the function points of IPV4 on each checkpoint.
(The conntrack represents the connection tracking; filter represents packet filtering; NAT (SRC) represents the source address translation, Nat (DST) represents the destination address translation; Mangle is a new feature in linux2.4.x. The packet is checked, but the incorrect packet is inferred to be forbidden or released. different from filter. Mangle in the implementation prior to LINUX2.4.18 only in Nf_ip_pre_routing,nf_ip_local_out two checkpoints to register the NF_HOOK_OPS structure, The NF_LOOK_OPS structure was registered on five checkpoints in the implementation after LINUX2.4.18. ）
On each checkpoint, the nf_hook_ops structure is arranged from top to bottom in the order in which they are called. Being able to see the same function points on different checkpoints is not the same as the order in which they are called. This is related to the action of the function point. For example, assuming Conntrack before the filter, assuming that the state of the packet is recorded in Conntrack and banned in the filter, the state associated with the packet will not be complete nf_ip_local_in. Wasted a conntrack structure. Therefore, the filter should be called first, assuming that its return value is nf_accept before calling Conntrack.
The ipt_table,ipt_match of the function point on the booklet. The IPT_TARGET,NF_SOCKOPT_OPS structure is as seen in the following table:
| Function Point 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 structures for functional point registration
It is worth noting that connection tracking (Conntrack) does not register any rules table. Indicates that it does not require a rule to determine whether to make a connection trace. At the same time it has a nf_sockopt_ops structure. This structure handles the parameter so_original_dst, which is used to obtain the destination address of the transparent proxy. |
|
