Analyze the Linux firewall framework from five aspects

Netfilter in Linux provides an abstract, generalized framework. The implementation of a sub-function defined by the framework is the packet filtering subsystem. The framework consists of the following five parts: 1. For each network protocol (IPv4, IPv6) Etc.) Define a set of hook functions (IPv4 defines five hook functions) that are called at several key points in the datagram flow through the protocol stack. In these points, the protocol stack will call the Netfilter framework with the datagram and the hook function label as parameters.

2. Any module of the kernel can register one or more hooks of each protocol to implement hooking, so that when a packet is passed to the Netfilter framework, the kernel can detect if there are any modules. The protocol and hook functions are registered. If registered, the callback function used when registering the module is called, so that these modules have the opportunity to check (and possibly modify) the packet, discard the packet, and instruct Netfilter to pass the packet to the queue in user space. .

3. Those queued packets are processed asynchronously to the user space. A user process can examine the packet, modify the packet, and even re-inject the packet into the kernel through the same hook function that leaves the kernel. 4. Any IP packets that are to be discarded at the IP layer should be checked before they are actually discarded. For example, the module is allowed to check the IP-Spoofed package (discarded by the route).

5. The location of the five HOOK points in the IP layer is as follows: (1) NF_IP_PRE_ROUTING: The packet that has just entered the network layer passes this point (just after the version number, checksum, etc.) The source address translation is performed at this point; IP_Rcv is called in IP_Input.c; (2) NF_IP_LOCAL_IN: After the route is searched, it is sent to the machine through this checkpoint, and the INPUT packet filtering is performed at this point, and is called in IP_local_deliver; (3) NF_IP_FORWARD: The packet to be forwarded passes this detection point, FORWORD packet filtering is performed at this point; (4) NF_IP_POST_ROUTING: All packets that are going out through the network device immediately pass this detection point, built-in destination address translation function (including address camouflage) At this point; (5) NF_IP_LOCAL_OUT: The packet sent by the local process passes this detection point, and the OUTPUT packet is filtered at this point.

These points are already defined in the kernel. Kernel modules can register for processing at these HOOK points, which can be specified using the nf_register_hook function. The datagram is called when the datagram passes through these hook functions, so that the module can modify the datagrams and return the following values ​​to Netfilter:

NF_ACCEPT Continue to transmit datagrams normally

NF_DROP Discard the datagrams, No longer transfer

The NF_STOLEN module takes over the datagram and does not continue to transmit the datagram

NF_QUEUE Queries the datagram (usually used to process data to user space)

NF_REPEAT Calling the hook function again

A datagram selection system called IPtables based on the Netfilter framework is applied in the Linux 2.4 kernel. In fact, it is a successor to IPchains, but But it has more scalability. The kernel module can register a new rule table and require the datagram to flow through the specified rules table. This datagram is selected for datagram filtering (filter table), network address translation (Nat table) and datagram processing (Mangle table). The three datagram processing functions provided by the Linux 2.4 kernel are based on Netfilter's hook functions and IP tables. They are independent modules that are independent of each other. They are all perfectly integrated into the framework provided by Netfileter.

Packet Filtering

The Filter table does not modify the datagram, but only the datagram. One aspect of IPtables over IPchains is that it is smaller and faster. It accesses the Netfilter framework through the hook functions NF_IP_LOCAL_IN, NF_IP_FORWARD, and NF_IP_LOCAL_OUT. Therefore, there is only one place for any report to filter it. This is a huge improvement over IPchains because a forwarded datagram traverses three chains in IPchains.

NAT

The NAT table listens for three Netfilter hook functions: NF_IP_PRE_ROUTING, NF_IP_POST_ROUTING, and NF_IP_LOCAL_OUT. NF_IP_PRE_ROUTING implements address translation for the source address of the datagram to be forwarded and NF_IP_POST_ROUTING performs address translation for the destination address of the packet to be forwarded. The conversion of the destination address of the local datagram is implemented by NF_IP_LOCAL_OUT. The NAT table is different from the filter table because only the first datagram of the new connection will traverse the table, and subsequent datagrams will perform the same conversion process based on the results of the first datagram. The NAT table is used in source NAT, destination NAT, masquerading (which is a special case of source NAT), and transparent proxy (which is a special case of destination NAT).

Packet Mangling

The Mangle table is registered in the NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT hooks. Using the mangle table, you can modify the datagram or attach some out-of-band data to the datagram. The current mangle table supports modifying the TOS bit and setting the nfmard field of skb.

If we want to add our own code, we need to use the nf_register_hook function. Our job is to generate an instance of the struct nf_hook_ops structure and use HOF_register_hook to put it on HOOK. The list item we always want to initialize to {NULL, NULL}; because it generally works in the IP layer, pf is always PF_INET; hooknum is the HOOK point we choose; a HOOK point may hang multiple processing functions, whoever is first, then To see the priority, that is, the designation of priority. Netfilter_IPv4.h specifies the priority of the built-in handler with an enumerated type