Comparison of linux Firewall implementation technologies

Article Title: Comparison of linux Firewall implementation technologies. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
This article describes the differences between different implementations of firewalls in linux. The following uses ipchains, iptables, and checkpoint FW1 as an example.
2. Basic Concepts
2.0
Before getting started, I will spend a little time explaining some basic concepts. Although the term firewall has not changed much over the years, if you have read only some documents in the early 1990s s, some concepts will confuse you. Only some of the most practical ones are listed here. They are not accurate definitions. I just try my best to make them easy to understand.
2.1 packet filtering:
A type of firewall. This system was described in a paper in 1980s. Traditional packet filtering functions are often seen on routers, while specialized firewall systems generally add function extensions, such as status detection. It checks the address, protocol, port, and other information of a single packet to determine whether to allow the packet to pass through.
2.2 Proxy:
A type of firewall. It works at the application layer and features two connections (between browser and proxy, between proxy and web server ). If you are still confused about the principle, we recommend that you use sniffer to capture the package. The proxy is not covered in this article.
2.3 status detection:
Also known as dynamic packet filtering, It is a feature extension in traditional packet filtering, which was first proposed by checkpoint. Traditional packet filtering is difficult to use dynamic port protocols, such as ftp. You cannot know which ports need to be opened in advance. If you use the original static packet filtering and want to use this service, you need to enable all the ports that may be used, this is often a very large scope, which will bring unnecessary hidden dangers to the seat belt. Status detection checks the application information (such as the ftp PORT and PASS Command) to determine whether the PORT can be opened temporarily. When the transfer ends, the port is immediately restored to disabled.
2.4 DMZ non-military zone:
For ease of configuration management, servers that need to provide external services on the Intranet are usually placed in a separate network segment, which is not a military zone. The firewall is generally equipped with three NICs. During configuration, the firewalls are connected to the Intranet, internet, and DMZ respectively.
2.5
Because of the superior geographical location of the firewall (usually at the key egress of the Network), the firewall generally attaches NAT, address disguise and VPN functions, which are not discussed in this article.
Three Detection Points
3.0 Summary
Packet filtering requires checking the IP packet. Therefore, it works at the network layer, intercepts the IP packet, and compares it with user-defined rules.
3.1 ipchains
From [3]
　　　
In general, it can be divided into input detection, output detection, and forwarding detection. But when the code is specific, the output detection is actually distributed to several places (different upper-layer protocols go through different processes on the IP layer ):
UDP/RAW/ICMP Packets: ip_build_xmit
TCP packet: ip_queue_xmit
Forwarded packet: ip_forward
Others: ip_build_and_send_pkt
As Rusty Russell, director of the ipchains project, said, shortly after starting ipchians, he found that the selected detection site location was wrong, and finally he could only make a mistake for the moment. An obvious problem is that the forwarded packet must be matched by three links in this structure. The address disguise function is too closely related to the firewall module. If you do not know the principle in detail, the configuration rules are prone to errors.
For detailed analysis in this section, see my earlier article [9 ].
3.2 iptables
　　
The firewall system in the 2.4 kernel is not a simple enhancement of 2.2, but a complete rewrite, which has undergone great structural changes. Compared with the 2.2 kernel, the 2.4 detection point is changed to five.
The function to be processed is registered on each detection point (stored in the global variable nf_hooks through nf_register_hook (). When this detection point is reached, the function that implements registration is executed according to a certain priority. Strictly speaking, netfilter is such a framework. You can register some processing functions at the appropriate position, many handler functions have been registered in the official code (call nf_register_hook in the Code). For example, you have registered the package filtering function on NF_IP_FORWARD. You can also register your own processing functions. For more information, see [8] and [10 ].
3.3 FW1
FW1 is a firewall launched by chekpoint for the 2.2 kernel. The module File released by Alibaba Cloud contains a large amount of debugging information, which can be traced to many implementation details from the decompiled code.
FW1 uses the dev_add_pack method to load the input filter function. If you are not familiar with this function, see [14 ]. But there is a problem here: in net_bh (), the skbuff passed to the network layer is cloned, that is
Skb2 = skb_clone (skb, GFP_ATOMIC );
If (skb2)
Pt_prev-> func (skb2, skb-> dev, pt_prev );
In this case, if you want to discard this package, it is not enough to free it, because it is only a copy of it.
How does FW1 solve this problem? See the following code (translated from assembly code to C program ):
Packet_type * fw_type_list = NULL;
　　
Static struct packet_type fw_ip_packet_type =
{
_ Constant_htons (ETH_P_IP ),
NULL,/* All devices */
Fw_filterin,
NULL,
NULL,/* next */
};
　　
Fwinstallin (int isinstall)
{
Packet_type * temp;
　　
/* Install */
If (isinstall = 0 ){
Dev_add_pack (& fw_ip_packet_type );
Fw_type_list = fw_ip_packet_type-> next;
　　
For (temp = fw_type_list; temp = temp-> temp)
Dev_remove_pack (temp );
}
/* Uninstall */
Else {
Dev_remove_pack (& fw_ip_packet_type );
　　
For (temp = fw_ip_packet_type; temp = temp-> next)
Dev_add_pack (temp );
}
}
It is not hard to see that FW1 has loaded ip_packet_type, and then calls ip_recv in its own processing function (fw_filterin.
The output Mount method is the same as that of lkm. Change dev-> hard_start_xmit. The dev structure changed once in the development process of Version 2.2, and was also processed to be compatible with FW1 (the offset is obtained by checking the version number ).
There is also a linux Firewall product WebGuard (http://www.gennet.com.tw/b5/csub_webguard.html) using a very similar approach and FW1 it. If you are interested, you can study it on your own.
Rules 4
4.0 Summary
4.1 ipchains
Man ipfw can see the detailed explanation of this section. The key data structure is as follows:
The rule chain is represented by the ip_chain structure. By default, there are three chains: input, ouptput, and forward. You can also add a new link When configuring rules. Each chain is actually a set of related rules stored in the form of a linked list.
Struct ip_chain
{
Ip_chainlabel label;/* Defines the label for each block */
Struct ip_chain * next;/* Pointer to next block */
Struct ip_fwkernel * chain;/* Pointer to first rule in block */
_ U32 refcount;/* Number of refernces to block */
Int policy;/* Default rule for chain. Only *
* Used in built in chains */
Struct ip_reent reent [0];/* Actually several of these */
};
Each rule is represented by an ip_fwkernel structure:
Struct ip_fwkernel
{
Struct ip_fw ipfw;
Struct ip_fwkernel * next;/* where to go next if current
* Rule doesn' t match */
Struct ip_chain * branch;/* which branch to jump to if
* Current rule matches */
Int simplebranch;/* Use this if branch = NULL */
Struct ip_counters counters [0];/* Actually several of these */
};
An important part of ip_fwkernel is ip_fw, which indicates the packet message to be matched:
Struct ip_fw
{
Struct in_addr fw_src, fw_dst;/* Source and destination IP addr */
Struct in_addr fw_smsk, fw_dmsk;/* Mask for src and dest IP addr */
_ U32 fw_mark;/* ID to stamp on packet */
_ 2010fw_proto;/* Protocol, 0 = ANY */
_ 2010fw_flg;/* Flags word */
_ 2010fw_invflg;/* Inverse flags */
_ 2010fw_spts [2];/* Source port range .*/
_ 2010fw_dpts [2];/* Destination port range .*/
_ 2010fw_redirpt;/* Port to redirect .*/
_ 16fw_outputsize;/* Max amount to output
NETLINK */
Char fw_vianame [IFNAMSIZ];/* name of interface ""*/
_ U8 fw_tosand, fw_tosxor;/* Revised packet priority */
};
2.2 The actual matching of network packets and rules in the kernel is carried out in ip_fw_check.
4.2 iptables
A rule is divided into three parts:
Struct ipt_entry file: // mainly used to match the IP Header
Struct ip_match file: // extra match (tcp Header, mac address, etc)
Struct ip_target file: // In addition to default actions (such as ACCEPT and DROP), you can add new actions (such as REJECT ).
Man iptable:
> A firewall rule specifies criteria for a packet, and
> Target. If the packet does not match, the next rule in
> The chain is the examined; if it does match, then the next
> Rule is specified by the value of the target, which can be
> The name of a user-defined chain, or one of the special
> Values ACCEPT, DROP, QUEUE, or RETURN.
2.4 The actual matching of network packets and rules in the kernel is performed in ip_do_table. The process of this Code is as follows:
Netfilter hacking howto 4.1.3 is clearly described.
　　
The simplified code is as follows:
/* Returns one of the generic firewall protocols ies, like NF_ACCEPT .*/
Unsigned int
Ipt_do_table (struct sk_buff ** pskb,
Unsigned int hook,
Const struct net_device * in,
Const struct net_device * out,
Struct ipt_table * table,
Void * userdata)
{
Struct ipt_entry * e;
Struct ipt_entry_target * t;
Unsigned int verdict = NF_DROP;
　　
Table_base = (void *) table-> priva