Linux 2.4 netfilter framework implementation _unix Linux

NetFilter is a functional framework for linux2.4 kernel to implement packet filtering/packet processing/nat. This paper discusses the NetFilter functional framework of Linux 2.4 kernel, and discusses packet filtering, NAT and packet processing (packet mangling) based on NetFilter framework. Read this article need to understand the 2.2 kernel ipchains principle and use method as a preliminary knowledge, if you do not have this knowledge, please read IPCHAINS-HOWTO.

Part I: NetFilter Foundation and concept

One, what is NetFilter

NetFilter is stronger than any previous version of the Linux kernel's firewall subsystem. NetFilter provides an abstract, general-purpose framework that defines the implementation of a child function that is the packet filtering subsystem. So don't expect to discuss topics like "How to set up a firewall or camouflage gateway in 2.4" in 2.4, which is just part of the NetFilter feature. The NetFilter framework consists of the following three sections:

1 Define a set of hook functions for each network protocol (IPV4, IPV6, etc.) (IPV4 defines 5 hook functions), which are invoked at several key points in the datagram flow through the protocol stack. In these several points, the protocol stack will call the datagram and hook function labels as parameters of the NetFilter framework.

Any module of the 2 kernel can register one or more hooks for each protocol, implement hooks, so that when a packet is passed to the NetFilter framework, the kernel can detect if any module registers the protocol and the hook function. If registered, calls the callback function used when the module is registered, so that the modules have the opportunity to check (and possibly modify) the packet, discard the packet, and instruct NetFilter to pass the packet into the user's space.

3 Those queued packets are delivered asynchronously to the user's space for processing. A user process can examine the packet, modify the packet, or even reuse the packet into the kernel by leaving the same hook function from the kernel.

All packet filtering/nat and so on are based on the framework. There is no more cluttered code in the kernel network code that modifies the packet. The current NetFilter framework is implemented in the IPV4, IPV6, and DECnet network stacks.

Second, why need NetFilter?

In fact, this problem can also be changed to ipchains What are the drawbacks leading to abandonment? Here are just a few of the reasons:

Because IPChains based on the 2.2 kernel does not provide a framework for passing packets to user space, any code that needs to be processed by the packet must run in kernel space, while kernel programming is complex and can only be implemented in C, and is prone to errors and poses a threat to kernel stability.


Transparent proxy implementations are complex, and each packet must be viewed to determine if there is a socket that handles the address specifically. There are 34 "#ifdef" conditional compilations in the network stack code in 11 files.


It is not possible to create a datagram filtering rule that does not depend on an interface address. We must use the local interface address to determine whether the datagram is locally issued, sent locally, or forwarded. The forwarding chain has only information for the output interface, so administrators must consider the source of the datagram.


Both camouflage and packet filtering are implemented within the same module, resulting in overly complex firewall code.


IPChains code is not modular and is not easily extensible (for example, filtering the MAC address)

Third, the author of NetFilter

The concept of NetFilter framework is proposed and its main implementation is done by Rusty Russell, who is IPChains's collaborators and defender of the current Linux kernel IP firewall. There are also Marc Boucher, James Morris, Harald Welte, and so on, all involved in the NetFilter project.

IV. the structure of NetFilter in IPV4

A packet is passed through the NetFilter system as shown in the following illustration:


--->[1]--->[route]--->[3]--->[4]--->
| ^
local| |
| [ROUTE]
V |
[2] [5]
| ^

V |

As you can see from the diagram, IPV4 has 5 hook functions, respectively:

1 nf_ip_pre_routing
2 nf_ip_local_in
3 Nf_ip_forward
4 nf_ip_post_routing
5 Nf_ip_local_out

Datagram from the left into the system, after the IP checksum, the datagram after the first hook function nf_ip_pre_routing[1] processing, and then enter the routing code, which determines whether the packet needs to be forwarded or sent to the local, if the packet is sent to the local machine, The data is then processed by the hook function nf_ip_local_in[2] and then passed to the upper layer protocol, which is nf_ip_forward[3 if the packet should be forwarded; The forwarded datagram passes through the last hook function nf_ip_post_routing[ 4] After processing, transfer to the network again.

Locally generated data after the hook function nf_ip_local_out [5] processing can be processed, routing processing, and then after nf_ip_post_routing[4] processing to send to the network.

V. Foundation of NetFilter

From the above discussion of IPV4 's netfilter example, you can see how the hook function is activated.

The kernel module can register hooks for one or more of these hook functions, and it is invoked when the datagram passes through the hook functions, so that the module can modify the datagram and return the following values to the NetFilter:

Nf_accept continue normal transmission datagrams
Nf_drop discard the datagram and no longer transmit
Nf_stolen module takes over the datagram and does not continue to transmit the datagram
Nf_queue The datagram (typically used to process a datagram to a user's space)
Nf_repeat Call the hook function again

Vi. using iptables for datagram selection

A netfilter framework, called Iptables, is used in the Linux2.4 kernel, which is the successor tool of IPChains, but it is more extensible.

The kernel module can register a new rule table (table) and require the datagram to flow through the specified rules table. This datagram is chosen for the implementation of datagram filtering (filter table), Network address translation (NAT table) and datagram processing (mangle table).

The three datagrams provided by the Linux2.4 kernel are based on NetFilter hook functions and IP tables. They are self-contained modules that are independent of each other. They are all perfectly integrated into the framework provided by Netfileter.

Packet filter
The filter table does not modify the datagram and only filters the datagram. One aspect of Iptables superior to IPChains is that it is smaller and faster. It is through the hook function nf_ip_local_in, Nf_ip_forward and Nf_ip_local_out access NetFilter framework. So there is only one place for any datagram to filter it. This is a huge improvement relative to ipchains, because in IPChains a forwarded datagram traverses three strands.


Nat
The NAT form 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 of the source address of the datagram that needs to be forwarded, and nf_ip_post_routing addresses the destination address of the packet that needs to be forwarded. The conversion of the destination address for the local datagram is implemented by Nf_ip_local_out.

The NAT table differs from the filter table because only the first datagram of the new connection will traverse the table, and subsequent datagrams will have the same conversion process based on the results of the first datagram.

NAT tables are used in source NAT, Destination NAT, camouflage (which is a special case of source NAT) and transparent proxies (a special case of the destination NAT).


Datagram Processing (Packet mangling)
The Mangle form is registered in the nf_ip_pre_routing and nf_ip_local_out hooks. Using the Mangle table, you can make changes to the datagram or attach some out-of-band data to the datagram. The current Mangle table supports modifying the TOS bit and setting SKB nfmard fields.

Seven, connection tracking

Connection tracking is the foundation of NAT, but it has been implemented as a separate module. This feature is used for an extension of packet filtering functionality, using connection tracking to implement a "stateful" firewall.

The second part uses iptables and netfilter for packet filtering

I. Overview

The following content requires an understanding of the basic concepts of TCP/IP, routing, firewalls, and packet filtering.

As explained in the first section, the filter table and three hooks are hooked up, thus providing three chains for data filtering. All the datagrams from the network and sent to this computer traverse the input rule chain. All forwarded datagrams will simply traverse the forward chain of rules. Finally, the locally issued datagram will traverse the output chain.

Ii. inserting rules into the chain of rules

LINUX2.4 provides a concise and powerful tool "iptables" to insert/delete/modify rules in a chain of rules. This is not a detailed introduction to Iptalbes, but rather a discussion of some of its main features:

This command implements all IP tables, currently including Filter,nat and mangle three tables, and later expanded table modules.
This command supports plug-ins to support new matching parameters and target actions. Therefore, any extension to NetFilter is very simple. Just write a module and Iptalbes plug-in (Dynamic Connection library) to complete the actual target action processing to add everything you need.
It has two implementations: Iptables (IPV4) and Ip6tables. Both are based on the same library and basically the same code.
The Basic iptables command
A iptables command basically contains the following five parts:

Which table do you want to work on?
Which chain of the table do you want to use
Operations performed (insert, add, delete, modify)
Target action for a specific rule
Matching datagram condition
The basic syntax is:

Iptables-t table-operation chain-j target match (es)
For example, you want to add a rule that allows all connections from anywhere to the local SMTP port:

Iptables-t filter-a input-j accept-p TCP--dport SMTP

Of course, there are other commands to operate the rules such as: Empty the list, set the chain default policy, add a user-defined chain ....

Basic operations:

-A To add a rule at the end of the chain
-I insert Rule
-d Delete Rule
-R replaces a rule
-L List Rules

Basic target action, applicable to all chains

ACCEPT receive the Datagram
Drop discards the datagram
Queue Queue This data check-in user space
Return returns to the chain previously called
Foobar user-defined chain
Basic matching criteria, applicable to all chains

-p Specifies the protocol (tcp/icmp/udp/...)
-S Source Address (IP address/masklen)
-D Destination Address (IP address/masklen)
-I datagram Input interface
-O Datagram Output interface
Out of the basic operations, matching and targeting also have a variety of extensions.

Third, iptables data filter matching condition extension

There are a variety of packet selection matching criteria extended for packet filtering. Here are just a few simple instructions to make you feel the strength of the extended match.

These matching extensions give us powerful datagram-matching tools:

The TCP matching extension can match the source port, the destination port, and any combination of TCP tags, TCP options, etc.
UPD matching extension can match source port and destination port
ICMP matching extension can match ICMP type
Mac matching extension can match the MAC address of the received data
Mark matching extension can match Nfmark
Owne matching Extension (applies only to locally generated datagrams) to match User ID, group ID, process ID, and session ID
Limit extension matches are used to match datagram restrictions within a specific time period. This extended match is useful for restricting Dos attack data streams.
The state matching extension is used to match datagrams in a particular state (determined by the connection tracking subsystem), and possible states include:
INVALID (does not match any connection)
Established (a datagram that belongs to an already established link)
NEW (set up a connected datagram)
RELATED (a related datagram, such as an ICMP error message or FTP data connection) with an established connection
TOS matches the value of the TOS field that the extension uses to match the IP header.

Iv. iptables Data Filter target action extension

Log passes the matched datagram to the syslog () for logging
Ulog records the matching data to the log process of user space
REJECT not only discards datagrams, but also returns a configurable error message to the sender.
Retransmit the datagram after the MIRROR interchange source and destination address

The third part uses iptables and netfilter to do NAT

Linux's previous kernel only supports limited NAT functionality, which is called camouflage. NetFilter supports any kind of NAT. Generally speaking, Nat can be divided into source NAT and destination Nat.

Source NAT modifies the source address of the datagram when the datagram passes through nf_ip_post_routing. Camouflage is a special snat.

Destination NAT modifies the datagram destination address when the datagram passes through Nf_ip_local_out or nf_ip_pre_routing. Port forwarding and transparent proxies are all dnat.

Iptables's NAT target action extension

SNAT
The source address of the transform packet.

Cases:

Iptables-t nat-a postrouting-j SNAT--to-source 1.2.3.4


Masquerade
Snat for dial-up connections with dynamic IP addresses, similar to Snat, but if the connection is disconnected, all connection tracking information is discarded and IP cloaking is performed using the reconnected IP address.

Cases:

Iptables-t nat-a postrouting-j Masquerade-o ppp0
Dnat
Converts the destination address of the datagram, which is handled in the prerouting hook chain, that is, when the datagram has just entered. So Linux subsequently handles all the new destination addresses.

Cases:

Iptables-t nat-a prerouting-j dnat--to-destination 1.2.3.4:8080-p tcp--dport 80-i eth1


REDIRECT
Redirect datagrams are local, and dnat the destination address to the interface address of the datagram is exactly the same.

Cases:

Iptables-t nat-a prerouting-j REDIRECT--to-port 3128-i eth1-p TCP--dport 80

Part IV using Iptables and netfilter for datagram processing (Packet mangling)

The Mangle table provides a way to modify the values of each field in the datagram.

I. Target expansion for packet processing

MARK
Sets the value of the Nfmark field. We can modify the value of the Nfmark field. Nfmark is simply a token of a user-defined datagram (can be any value within the range of an unsigned long integer). The tag value is used for policy-based routing, informing the IPQMPD (the Queue picker daemon running in user space) to queue the datagram to which process, and so on.

Example: Iptables-t mangle-a prerouting-j MARK--set-mark 0x0a-p TCP

TOS
Sets the TOS field value for the IP header of the datagram. This feature is useful if you want to apply TOS based scheduling and routing.

Example: Iptables-t mangle-a prerouting-j TOS--set-tos 0x10-p tcp--dport SSH

Part V user space for queued data registration

As mentioned earlier, at any time in any nefilter rule chain, datagrams can be queued to be forwarded to user space. The actual queue is done by the kernel module (IP_QUEUE.O).

Datagrams (including the original [meta] data of the datagram, such as Nfmark and MAC addresses) are sent to the user space process via the netlink socket. The process can do anything with the datagram. After processing is complete, the user process can inject the datagram back into the kernel or set a target action for the datagram (such as discard, etc.).

This is a key technology for netfilter, enabling user processes to perform complex datagram operations. Thus reducing the complexity of the kernel space. The user space datagram operation process can be easily applied to the ntfilter provided by the library called LIBIPQ.

Reference documents:

Laforges Talk about NetFilter
Http://www.lisoleg.org/forum-source/messages/1410.html

The NetFilter framework in Linux 2.4
Http://www.gnumonks.org/papers/netfilter-lk2000/presentation.html

Linux 2.4 Packet Filtering HOWTO
Http://netfilter.kernelnotes.org/unreliable-guides/packet-filtering-HOWTO/index.html

Linux 2.4 NAT HOWTO
Http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO/index.html

NetFilter Hacking HOWTO
Http://netfilter.kernelnotes.org/unreliable-guides/netfilter-hacking-HOWTO/index.html

(Source: Viphot)