The implementation of Netfilter:linux firewall in kernel

The implementation of Netfilter:linux firewall in kernel

strong> content: NetFilter and Linux Firewall introduction IPv4 Code NetFilter interface netfilter core module Summary Reference about the author " related content: Introduction describes --> In the Linux area there are: Tutorial Tools and Products Code and Components Article

Zhao Wei (zhaoway@public1.ptt.js.cn)
Linux/free Software Independent Technical Advisor
November 15, 2002 This article describes the Linux firewall technology netfilter/iptables in the Linux kernel of the specific implementation.

NetFilter and Linux Firewall introduction

Linux firewall technology has undergone a number of generations of evolution, step-by-step development. The beginning of the IPFWADM was Alan Cox porting from the FreeBSD kernel code at the beginning of the Linux kernel development. Later went through the IPChains, and then through Paul Russell in the Linux Kernel 2.3 series development process NetFilter this architecture. And the User Space Firewall management tool, also corresponding development for iptables. Netfilter/iptables This combination is quite satisfying at the moment. After experiencing the development of Linux kernel 2.4 and 2.5, it is true to say that Netfilter/iptables has withstood the test of the widespread use of a large number of users.

This article does not intend to introduce the use of Linux firewalls in user-space management programs iptables. As for how to use the Netfilter/iptables mechanism to build a reliable Internet firewall, this is not the topic of interest in this article. For the use of iptables, readers can refer to the man iptables manual, as well as the Packet filtering HOW-TO and NAT HOW-TO written by NetFilter's core developer, Paul Russell. For a related link, see the resources directory listed later in this article. Readers should be able to have a good understanding of the use of iptables before they read this article.

This article describes the implementation of NetFilter in Linux kernel. If the conditions permit, we may be in subsequent articles to further explain how to write their own kernel modules and embed it in the NetFilter architecture, to achieve their own custom firewall capabilities. It is worth noting that on NetFilter's website, you can see a subproject of NetFilter patch-o-matic, which includes a large variety of custom kernel modules, which modules the reader to develop their own kernel mod Ules, provides a lot of good examples.

NetFilter Interfaces in IPv4 code

NetFilter in the Linux kernel in the IPv4, IPv6 and DECnet, and other network protocol stacks have a corresponding implementation. This article is limited to space and will only introduce the implementation of the NetFilter on the IPV4 stack that most of the reader's friends are interested in.

As we compile the Linux kernel, we will notice that NetFilter is an optional part of the compilation process. In other words, users in the process of compiling the kernel, can according to their own needs, decide whether to compile in their own kernel netfilter kernel support. This brings us a hint that the implementation of NetFilter code for the implementation of the IPV4 protocol stack of the impact of the code should be as small as possible, not so compelling. Otherwise, the IPV4 protocol stack Code maintenance work and implementation of NetFilter code maintenance work together, let a person headaches.

Indeed, the IPV4 protocol stack, in order to support the NetFilter architecture, has carefully chosen five reference points in the travel route of IP Packet on the IPV4 protocol stack. Each of the five reference points introduces a corresponding call to the Nf_hook () macro function. These five reference points are named Prerouting,local-in,forward,local-out and postrouting respectively. The meaning of these five reference points, in the iptables of the use of the description has an accurate description, I believe that readers should understand the friends. From the grep output as follows, we can see the IPV4 protocol stack implementation code calls to the Nf_hook () macro function:

ZHAOWAY@QHQ ~/linux-2.4.19/net/ipv4 $ grep-n nf_hook *.c arp.c:591:nf_hook (Nf_arp, Nf_arp_out, SKB, NULL, Dev, dev_queue _xmit); Arp.c:871:return Nf_hook (Nf_arp, nf_arp_in, SKB, Dev, NULL, arp_process); igmp.c:187:/* Don ' t just hand nf_hook skb->dst->output, in case NetFilter HOOK igmp.c:252:return nf_hook (PF_INET, NF _ip_local_out, SKB, NULL, Rt->u.dst.dev, Ip_forward.c:145:return nf_hook (pf_inet, Nf_ip_forward, SKB, Skb->dev, Dev2, ip_gre.c:668:/* Need This wrapper because Nf_hook takes the function address */Ip_input.c:302:return Nf_hook (pf_ine T, nf_ip_local_in, SKB, Skb->dev, NULL, Ip_input.c:437:return Nf_hook (pf_inet, nf_ip_pre_routing, SKB, dev, null, ip_o utput.c:111:/* Don ' t just hand nf_hook skb->dst->output, in case NetFilter HOOK ip_output.c:156:return Nf_hook (PF_I NET, Nf_ip_local_out, SKB, NULL, Rt->u.dst.dev, Ip_output.c:191:return nf_hook (pf_inet, nf_ip_post_routing, SKB, null, Dev, Ip_output.c:233:nf_hook (pf_inet, nf_ip_post_routing, NEWSKB, NULL, Ip_output.c:249:nf_hook (Pf_inet, nf_ip_post_routing, NEWSKB, NULL, Ip_output.c:400:return NF_HOOK (PF_INET, NF_IP_ Local_out, SKB, NULL, Rt->u.dst.dev, Ip_output.c:603:err = Nf_hook (pf_inet, nf_ip_local_out, SKB, NULL, Ip_output.c:7 14:err = Nf_hook (pf_inet, Nf_ip_local_out, SKB, NULL, Rt->u.dst.dev, ipip.c:516:/* Need this wrapper because NF_HOOK ta Kes The function Address * * Ipmr.c:1211:nf_hook (pf_inet, Nf_ip_forward, Skb2, Skb->dev, Dev, Zhaoway@qhq ~/linux-2.4.1 9/net/ipv4 $

Nf_hook () This macro function, defined in the Linux-2.4.19/include/linux/netfilter.h. When the #ifdef config_netfilter is defined, the Nf_hook_slow () function is transferred, and if Config_netfilter is not defined, the NetFilter module is transferred back to the IPV4 protocol stack and continues to be processed. This gives the user an option to compile the kernel, by defining config_netfilter or not to determine whether to compile NetFilter support code into the kernel. From the name of this function, we can also guess that we can put the five reference points on the IPV4 protocol stack, image as five hooks. IP packet in the IPV4 protocol stack travel, through the five hooks, will be netfilter module fishing, review Some, and according to the results of the review, decided to packet next fate: is to put back to the IPV4 protocol stack, continue to travel, or after some modification, Put it back, or simply throw it away.

NetFilter's core modules

"Hooks" and "fishing spots."

After the IP packet is Nf_hook () from the IPV4 protocol stack, the Nf_hook_slow () function is processed into the linux-2.4.19/net/core/netfilter.c. The main thing to do with this function is to start processing the packet based on the nf_hooks[] array. To be exact, the five reference points on the IPV4 protocol stack mentioned in the previous paragraph are not "fishing hooks", but "places to allow fishing". In other words, there are five "allowed fishing points" defined on the IPV4 protocol stack. In every "fishing point", can let NetFilter put a "hook", the passing packet fishing up. So where are the Netfiler "hooks"? is placed inside the nf_hooks[][] array. This "Hook" is described in the following struct as defined in Linux-2.4.19/include/linux/netfilter.h:

struct Nf_hook_ops { struct list_head list; NF_HOOKFN *hook; int PF; int hooknum; int priority; };

We see that the essence of the "hook" is a NF_HOOKFN function. This function will perform a preliminary processing of the hooked IP packet. So, who is going to put these "hooks" into the nf_hooks[][] array? The answer is, each table. Readers who are familiar with iptables management tools should understand that a table is a collection of similar firewall rules. Iptables inside the default definition of three Table:filter,mangle, and Nat. Take the filter table for example, which is a kernel module implemented in LINUX-2.4.19/NET/IPV4/NETFILTER/IPTABLE_FILTER.C. During the initialization of this module, it invokes Nf_register_hook () to register a set of "hooks" into the NetFilter core code. This registration process, in fact, is the "fish hook" into the "fishing point" process. The specific location of the "fishing point" is specified by the subscript of the nf_hooks[][] array.

Ipt_do_table ()

We specifically see LINUX-2.4.19/NET/IPV4/NETFILTER/IPTABLE_FILTER.C is the filter table implementation code, the filter table found in the "hook" on the NF_HOOKFN function, The main is to invoke the Ipt_do_table () function. This is a function defined in the LINUX-2.4.19/NET/IPV4/NETFILTER/IP_TABLES.C. As mentioned earlier, a table is a set of firewall rules. Obviously, what the ipt_do_table () function will do is to handle the "phishing" IP packet by following the rules stored in the table.

The table contains all the firewall rules in this table. But not all rules have to be brought in and follow it to review the packet. In fact, the packet was fished from which "fish hooks", and only the rules related to the "hook" were brought in to censor the packet. This mechanism enables multiple chain for each table, and more rules on each chain. And, as we immediately see, a chain corresponds to a "fishing point" on the IPV4 protocol stack. Readers who are familiar with the use of iptables user space management tools should be aware of this right away.

The format of the rule in table is defined in Linux-2.4.19/include/linux/netfilter_ipv4/ip_tables.h, as follows:

/* This structure defines each of the firewall rules. Consists of 3 parts which are 1) General IP header stuff 2) match specific stuff 3) the target to perform if the Rul E matches * * struct ipt_entry {struct IPT_IP IP; * Mark with fields that we care about. * * unsigned int nfcache; /* Size of Ipt_entry + matches * * u_int16_t Target_offset; /* Size of Ipt_entry + matches + target */u_int16_t next_offset; /* Back pointer * * unsigned int comefrom; /* Packet and byte counters. * * struct ipt_counters counters; /* The matches (if any), then the target. * * unsigned char elems[0]; };

A entry is a rule. A entry is mainly composed of two parts. Part is a series of matches, and the other part is a target. The question to be answered by this number of matches is whether the relevant packet match the rule. And the target is to answer the question, once packet match, what to do with this packet. It is up to target to determine the future fate of this matching packet. The beginning of the struct IPT_IP is defined as follows:

struct IPT_IP { /* Source and destination IP addr /struct in_addr src, dst; /* Mask for SRC and dest IP addr * * struct in_addr smsk, Dmsk; Char Iniface[ifnamsiz], outiface[ifnamsiz]; unsigned char iniface_mask[ifnamsiz], outiface_mask[ifnamsiz]; /* Protocol, 0 = any * * u_int16_t Proto; * Flags Word * /u_int8_t flags; * Inverse flags * /u_int8_t invflags;

We can see at once that some of the characteristics of the packet that this rule is to match (match) are documented in struct IPT_IP.

Match and Target

NetFilter Core section provides an analysis and disposal of packet architecture, but the core code is not specific to analyze, dispose of packet. This specific analysis and disposal task is assigned to other module to complete. The core code can pass packet to the module code that can handle the corresponding rules based on the rules that are recorded in the table. So how does the core code know which module can handle what kind of rules? This is to be registered with the core Code, Ipt_register_target () or Ipt_register_match () when the corresponding modules start. This registration process is mainly to inform the core code, this module has a target () function, you can determine the fate of packet, or, this module has a match () function, can determine whether a packet meets the rules matching requirements.

This prompts us, if we want to write their own firewall module, embedded in the NetFilter architecture, our main task is to NetFilter Core registration Ipt_register_target () or Ipt_register_match ().

Iptables Management Tools

Finally, the iptables, the management tool in user space, is to be explained. As we saw earlier, the NetFilter code in the kernel space completes the analysis and disposal of the packet according to the rules in the table. However, the specific firewall rules in these table must be written by the system administrator in person. The NetFilter in kernel only provides a mechanism that does not know how to use this mechanism and write the appropriate rules to implement a network firewall. So, how does the rules written by the system administrator go into the NetFilter maintenance table in the kernel space?

This task is done by the Iptables tool. It passes through getsockopt () and setsockopt () two system calls to enter kernel space. These two calls are part of the BSD Socket interface. The problem here is how IPv4 should be treated when receiving an opt for a sock. NetFilter requires that it handle the appropriate local invocation of the ip_sockopt () function in the getsockopt () and setsockopt () system calls in the Linux-2.4.19/net/ipv4/ip_sockglue.c file nf_ Sockopt (). In this way, user space can be communicated with the NetFilter core, you can maintain the firewall rules in table.

Summary

NetFilter for IPv4 is very small, one is called Nf_hook () in several places, and the other is called nf_sockopt () in ip_sockopt (). NetFilter's core code is just to maintain table, and the task of interpreting the table rests with other kernel module. NetFilter will send the packet from the hook and the contents of the table to the registered module to determine the fate of packet.

Resources

1 netfilter/iptables main site in http://www.netfilter.org or http://www.iptables.org on this site, can find NetFilter core developer Paul Russell wrote Linux Packet filtering How-to,linux NAT HOW-TO, and other technical articles on how to deploy Linux netfilter firewalls.

2 online cross index of Linux kernel source code in http://lxr.linux.no this site can help readers more easily read the Linux kernel source program.

About the author

Zhao Wei, a linux/free Software independent technical advisor who lives in Nanjing. Published many articles in Chinese at IBM DeveloperWorks. A list of technical articles he publishes on the Web can be found in http://www.advogato.org/person/zhaoway/. He frequented the Linuxunix version of the BBS on the little Lily of Nanjing University. South size Lily's URL in http://bbs.nju.edu.cn Zhao Wei in the south size lily above the ID is ILOVEQHQ welcome reader friends and he discusses Linux/free Software related technical issues.