Which types of hooks are supported by Netfilter?

Line filter - Netfilter

Package change framework for Linux and the umbrella project for software of the same

Netfilter is a framework provided by the Linux kernel that can be used to implement various network-related operations in the form of custom handlers. Netfilter provides various packet filtering, network address translation, and port translation functions and operations that provide the functions necessary to route packets through a network and prevent packets from reaching sensitive locations within a network.

Netfilter is a series of hooks in the Linux kernel that certain kernel modules can use to register callback functions on the kernel's network stack. These functions, which are normally applied to the data traffic in the form of filtering and modification rules, are called for each packet that goes through the respective hook within the network stack.

history

Relationship (of some) of the various Netfilter components

Rusty Russell started this in 1998 Netfilter / iptables project . He had also authored the project's predecessor, ipchains. As the project grew, he founded the in 1999 Netfilter Core Team (or simply Core team ). The software they produce (hereinafter referred to as Called Netfilter ) uses the GNU General Public License (GPL) license and was merged in March 2000 in version 2.4. x of the Linux kernel mainline.

In August 2003, Harald Welte became chairman of the core team. In April 2004, a German court issued a historic injunction against Sitecom Germany, which refused to adhere to the terms of the GPL, following a course of action taken by the project against those who distribute the project's software embedded in routers without complying with the GPL GPL-related disputes). In September 2007, Patrick McHardy, who had headed development for the past few years, was elected as the new chairman of the core team.

Before iptables, the predominant software packages for creating Linux firewalls were ipchains in Linux kernel 2.2.x and ipfwadm in Linux kernel 2.0.x, which in turn was based on BSD's ipfw. Both ipchains and ipfwadm change the network code so that they can manipulate packets because the Linux kernel lacked a general packet control framework until the introduction of Netfilter.

While ipchains and ipfwadm combine packet filtering and NAT (specifically three specific types of NAT known as Masking , Port forwarding and Are called diversion ), Netfilter separates packet operations into several parts, which are described below. Each one connects to the netfilter hooks in different places to access packets. The connection tracking and NAT subsystems are more general and powerful than the rudimentary versions in ipchains and ipfwadm.

In 2017, the IPv4 and IPv6 flow offload infrastructure was added to speed up software flow table routing and support for hardware offload.

Userspace utilities

Flow of network packets through netfilter with older iptables packet filtering

iptables

The kernel modules are called,, (the underscore is part of the name) and comprise the legacy packet filter section of the Netfilter hook system. They provide a table-based system for defining firewall rules that can be used to filter or transform packets. The tables can be managed by the user-space tools,,, and. Note that both the kernel modules and the userspace utilities have similar names, but each is a different entity with different functions.

Each table is actually its own hook, and each table has been introduced to serve a specific purpose. With respect to netfilter, a particular table is executed in a particular order with respect to other tables. Each table can call itself and execute its own rules, which offers opportunities for additional processing and iteration.

Rules are organized in chains or, in other words, "rule chains". These chains are named with predefined titles, including, and. These chain titles describe the origin in the Netfilter stack. For example, packet reception falls on the chain while the locally delivered data is presented, and the forwarded traffic falls on the chain. The locally generated output goes down the chain and the packets to be sent are on the chain.

Netfilter modules that are not organized in tables (see below) can search for the origin in order to select their operating mode.

module
When loading, registers a hook that is called before any other netfilter hook. It contains a table called raw , which can be used to filter packets before they reach more memory-intensive operations such as connection tracking.
module
Register a hook-and- Mangle Table to be run after the connection trace (see below) (but still before any other table) so that changes can be made to the package. This enables additional changes through the following rules, such as: B. NAT or other filtering.
module
Registers two hooks: destination network address translation based transformations ("DNAT") are applied before the filter hook, source network address translation based transformations ("SNAT") are applied after. The Network address translation table (or "nat"), which is made available to iptables, is only intended as a "configuration database" only for NAT assignments and not for filtering of any kind.
module
Register the Filter table used for general filtering (firewalling).
module
Used for mandatory access control (MAC) network rules, such as: B. for those who are activated by and goals. (These so-called "targets" refer to security-enhanced Linux markers.) Mandatory access control is implemented by Linux security modules such as SELinux. The security table is called after the filter table has been called so that all DAC rules (Discretionary Access Control) in the filter table take effect before MAC rules. This table contains the following built-in chains: (for packets entering the computer itself), (for modifying locally generated packets before routing), and (for modifying packets that are forwarded through the computer).

nftables

nftables is the new packet filter part of Netfilter. is the new userspace program that replaces,, and.

The nftables kernel engine adds a simple virtual machine to the Linux kernel that can run bytecode to inspect a network packet and make decisions about how that packet should be handled. The operations implemented by this virtual machine are purposely basic: it can pull data from within the package itself, view its metadata (such as inbound interface), and manage connection tracking data. Arithmetic, bitwise, and comparison operators can be used to make decisions based on this data. The virtual machine can also process records (usually IP addresses) so that multiple comparisons can be replaced with a single record search.

This is in contrast to the old Xtables code (iptables etc.), whose protocol awareness is so deeply integrated into the code that it had to be replicated four times - for IPv4, IPv6, ARP and Ethernet bridging - as firewall engines too protocol specific to be used generically. The main advantages over this are the simplification of the Linux kernel ABI, the reduction in code duplication, improved error reporting, and more efficient execution, storage and incremental atomic changes to the filter rules.

Packet defragmentation

The module defragments IPv4 packets before they reach the connection tracking (module) of Netfilter. This is required for the in-core link tracking and NAT helper modules (which are a form of "mini-ALGs"), which only work reliably for entire packets, not necessarily fragments.

The IPv6 defragmenter is not an independent module, but is integrated into the module.

Connection tracking

One of the important functions that build on the Netfilter framework is connection tracking. Connection tracking allows the kernel to keep track of all logical network connections or hold sessions and thus relate all packets that can form this connection. NAT relies on this information to translate all associated packets in the same way and can use this information as a stateful firewall.

However, the connection status is completely independent of a status of the upper level, e.g. B. the status of TCP or SCTP. One reason for this is that simply forwarding packets, that is, without local delivery, may not necessarily call the TCP engine at all. Even transmissions in connectionless mode such as UDP, IPsec (AH / ESP), GRE and other tunnel protocols have at least a pseudo connection status. The heuristic for such protocols is often based on a preset time limit for inactivity, after which a Netfilter connection is disconnected.

Each Netfilter connection is uniquely identified by a tuple (layer 3 protocol, source address, destination address, layer 4 protocol, layer 4 key). The layer 4 key depends on the transport protocol. For TCP / UDP it is the port number, for tunnels it can be your tunnel ID, otherwise it is only zero, as if it were not part of the tuple. In order to be able to check the TCP port in all cases, packets must be defragmented.

Netfilter connections can be edited with the user space tool.

You can check the information of the connection like status, status and more to make the packet filtering rules more powerful and easier to manage. The most common conditions are:

try to establish a new connection
Part of an existing connection
assigned to a packet that initiated a new connection and that was "expected"; The above-mentioned mini-ALGs make these expectations, for example, when the module sees an FTP command ""
The package was found to be invalid, e.g. B. it would not match the TCP status diagram
A special status that can be assigned by the administrator to bypass connection tracking for a specific packet (see raw table above).

A normal example would be that the first packet the Conntrack subsystem sees is classified as "new", the response is classified as "established", and an ICMP error is "in use". An ICMP error packet that does not correspond to a known connection would be "invalid".

Connection tracking helper

By using plug-in modules, connection tracer can gain knowledge of application-level protocols and thus understand that two or more different connections are "related". For example, consider the FTP protocol. A control connection is established, but when data is transferred a separate connection is established to transfer it. When the module is loaded, the first packet of an FTP data connection is classified as "used" instead of "new" because it is logically part of an existing connection.

The helpers only check one package at a time. So if important connection tracing information is split between two packets due to IP fragmentation or TCP segmentation, the helper does not necessarily recognize patterns and therefore does not perform its operation. IP fragmentation is dealt with with the connection tracing subsystem, which requires defragmentation, although TCP segmentation is not dealt with. In the case of FTP, it is assumed that segmentation does not take place "near" a command, as is the case with standard segment sizes, and is therefore not dealt with in Netfilter either.

Network address translation

Each connection has a number of Original addresses and Reply addresses that are about to begin. NAT in Netfilter is implemented by simply changing the reply address and, if necessary, the port. As packets are received, their connection tuple is also compared to the reply address pair (and ports). Being fragment-free is also a requirement for NAT. (If necessary, IPv4 packets can be updated through the normal IPv4 stack without a netfilter.)

NAT helper

Similar to connection tracing assistants, NAT assistants perform a packet inspection and replace the original addresses with reply addresses in the payload.

Other Netfilter projects

While these are not kernel modules that use Netfilter code directly, the Netfilter project includes some other notable software.

conntrack-tools

is a set of user-space tools for Linux that system administrators can use to interact with the records and tables for connection tracking. The package contains the daemon and the command line interface. The userspace daemon can be used to enable cluster-based stateful firewalls with high availability and to collect statistics on the use of the stateful firewall. The command line interface provides a more flexible interface to the connection tracking system than the legacy one.

ipset

Unlike other extensions like Connection Tracking, this relates to the Netfilter core code rather than this. does not use netfilter hooks, for example, but offers a module to synchronize IP sets and to make minimal changes (set / clear).

The called up user space tool is used to set up, manage and check so-called "IP sets" in the Linux kernel. An IP set usually contains a set of IP addresses, but depending on its "type" it can also contain sets of other network numbers. These sets are much more efficient in searching than mere rules, but of course they can take up more memory. Various storage algorithms (for the data structures in the memory) are available to the user in order to select an optimal solution.

Each entry in a set can be tied to a different set, which enables sophisticated matching operations. A sentence can only be removed (destroyed) if there are no rules or other sentences referring to it.

SYN proxy

Aim enables the handling of large SYN floods without the large performance degradation that results from the connection tracing in such cases. By redirecting the first requests to the destination, connections are only registered in the connection trace when they have reached a validated final state. This removes the need for connection tracking to be billed for a large number of potentially invalid connections. In this way, large floods can be dealt with effectively.

On November 3, 2013, the proxy functionality was integrated into the Netfilter with the release of version 3.12 of the Linux kernel main line.

ulogd

is a user-space daemon for receiving and logging packets and event notifications from the Netfilter subsystems. can send packets to it via the userspace queuing mechanism, and the connection tracking can interact with to exchange further information about packets or events (e.g. disconnection, NAT setup).

Userspace libraries

Netfilter also provides a number of libraries prefixed to their names that can be used to perform various tasks from the user area. These libraries are published under the GNU GPL version 2. In particular, these are the following:

Allows user room packet queuing to be performed in conjunction with iptables. based on
enables the manipulation of connection trace entries from the user area; based on
allows the collection of log messages generated by iptables; based on
enables operations on queues, connection tracing and logs; Part of the project
allows changes to the iptables firewall rule sets; It is not library based and its API is used internally by the utilities
enables operations on IP sets; based on .

Netfilter workshops

The Netfilter project organizes an annual meeting for developers to discuss ongoing research and development efforts. The 2018 Netfilter workshop took place in Berlin in June 2018.

See also

References

External links