Netfilter

from Wikipedia, the free encyclopedia
Netfilter
Basic data

Maintainer Netfilter project
operating system Linux
programming language C.
category Linux kernel module :
packet filter
NAT
firewall
License GNU General Public License
http://www.netfilter.org/

Netfilter is a software project that provides packet filters , network address translation and other firewall- relevant tools for the Linux kernel . Netfilter also describes the software layer within the Linux kernel that is called when network packets are received and sent. This only initiates the execution of further modules such as packet filters. These modules can then intercept and manipulate packets.

Relationship between some Netfilter components

history

The Netfilter / iptables project was started in 1998 by Rusty Russell , who was also the author of the predecessor ipchains . As the project grew , he founded the Netfilter core team (or simply core team ; main development team) in 1999 . The software produced there - called Netfilter from here on - is licensed under the GNU General Public License (GPL) and was integrated into the Linux kernel, version 2.3, in March 2000. In August 2003, Harald Welte became chairman of the core team. In April 2004 - after an intensive search on the part of the Netfilter project in commercial products that sold the software without adhering to the license conditions - Welte in Germany reached a historic court order against Sitecom Germany. In September 2007, Patrick McHardy, who had been in charge of development in previous years, became the new chairman of the core team. Pablo Neira Ayuso has been the chairman of the core team since 2013. In June 2016, Patrick McHardy was expelled from the core team over controversial lawsuits against GPL violations.

iptables were preceded by the then predominant firewall packages ipchains in Linux 2.2 and ipfwadm in Linux 2.0, which had similarities to BSD's ipfw . Both ipchains and ipfwadm intervened directly in the network code to manipulate packets, as there was no generic interface like Netfilter to date.

While ipchains and ipfwadm packet filtering and NAT combined (in particular three certain types of NAT, Masqueradieren , port forwarding and redirection ), package operations are divided into Netfilter into smaller modules - see more on this below. With Netfilter, each operation is attached to a different position in order to process packets. The connection tracking and NAT subsystems at Netfilter are more general and more powerful than the truncated versions at ipchains and ipfwadm.

iptables

The kernel modules ip_tables , ip6_tables , arp_tables (underscores are part of the name) and ebtables represent a main component and thus “users” of the Netfilter hook system. They represent a table-based system for defining firewall rules that enable filtering or manipulation. The tables can be administered using the user space programs iptables , ip6tables , arptables or ebtables .

Each table is actually a hook of its own, and of course each one was introduced for a specific purpose. This affects Netfilter insofar as tables are processed in a certain order. Otherwise, all tables are passed on to the same sub-function, which then runs over and executes each rule.

Chains in this regard correspond whence was called netfilter stack, ie for. B. Parcel receipt (PREROUTING), delivered locally (INPUT), forwarded (FORWARD), output locally (OUTPUT), and parcel dispatch (POSTROUTING). Netfilter modules that do not provide tables (see below) may inspect the origin in order to decide which operations should be carried out.

Modules:

iptable_raw
when it is loaded registers a hook that is called before any other netfilter hook. It also exposes a table called raw where packets can be filtered before they reach more memory-intensive operations such as connection tracking.
iptable_mangle
registers a hook and a table called mangle , which is run through after connection tracking (but before further tables) so that packets can be manipulated which could influence later decisions such as NAT or the packet filter.
iptable_nat
registers two hooks: DNAT-based transformations are processed before the filter hook, SNAT-based transformations afterwards. The nat table that will become available in the course of this is just a “configuration database ” that is only intended for NAT mapping, not for packet filtering.
iptable_filter
registers the filter table used for general packet filtering.

Package defragmentation

The nf_defrag_ipv4 module is used to defragment IPv4 packets before Connection Tracking (in the nf_conntrack_ipv4 module) receives them. This step is necessary for the connection tracking and NAT “helper” modules (so to speak “mini- ALGs ”) within the kernel, which do not inspect the data stream across fragments and therefore work with fragment-free packets.

The defragmentation of IPv6 packets is not an extra module, but is integrated in nf_conntrack_ipv6 .

Connection tracking

One of the important functions based on Netfilter is connection tracking (lit. “connection tracking”, “connection monitoring”). Connection tracking enables the kernel to keep track of all logical network connections or sessions , and thus to relate all packets that make up a connection to one another. NAT relies on this information to transform all related packets in the same way. Iptables can also use this information to provide Stateful Packet Inspection (SPI).

However, the status of a “(Netfilter) connection” is independent of any status of a potential transport protocol such as TCP or SCTP . One reason for this is that when packets are merely forwarded, i.e. no local delivery, the actual TCP processing process does not even have to come into play. Even connectionless protocols such as UDP , IPsec (AH / ESP), GRE and other tunnel protocols have a connection state, albeit “pseudo”. A time-based inactivity timeout is usually used as a heuristic for such protocols, after which a Netfilter connection is deleted and thus “forgotten”.

Each Netfilter connection is uniquely identified by a (layer 3 protocol, source address, destination address, layer 4 protocol, layer 4 key) tuple. The layer 4 key depends on the transport protocol used; for TCP / UDP it is the port number, for tunnels it can be their tunnel ID, but otherwise it is just zero, as if it were not part of the tuple. In order to be able to read out the TCP port in any case, packets are inevitably defragmented.

Netfilter connections can be manipulated with the userspace program conntrack .

Using connection tracking, iptables can view connection parameters such as states, statuses, etc., to make packet filter rules stronger and easier to use. The most important states are:

NEW
a new connection begins with the packet
ESTABLISHED
the package belongs to an existing connection
RELATED
this state is assigned to a packet that would start a new connection, but the connection was already “expected”. The aforementioned mini-ALGs set these expectations upon, e.g. B. if the nf_conntrack_ftp module finds the “PASV” command in an FTP connection.
INVALID
The package was found to be invalid; B. if it does not follow the TCP state transition graph.
UNTRACKED
is a special state that can be assigned by the administrator in order to bypass connection tracking for a certain packet (see above: raw table)

An example would be that the connection tracking classifies the first packet as “new”. A subsequent response packet would then be “established” and an ICMP error packet would be “related”. However, if an ICMP error packet could not be assigned to a connection, it would be classified as “invalid”.

“Helper” modules

Using additional plugins, connection tracking can be expanded so that it receives knowledge of protocols of the application layer and thus understands that two or more connections are “related”. Take, for example, the FTP, which initially opens a control connection, but a separate one for each data transfer. If the nf_conntrack_ftp module is loaded, the first packet of an FTP data connection is classified as “related” instead of “new” because it is a logical part of an existing connection.

The helper modules only inspect one package at a time. So if important information that is relevant for connection tracking is divided into several packets, either by IP fragmentation or TCP segmentation, the modules cannot fulfill their task. IP fragmentation is opposed to forced defragmentation, but TCP segmentation is not yet covered. In the case of FTP it was assumed that segmentation of “close” commands such as PASV with usual segment sizes would not normally occur, and therefore segmentation is not taken into account in Netfilter either.

Network Address Translation

Each connection has “original addresses” (source, destination) and “reply addresses”, which are the same at the beginning. NAT within Netfilter is implemented by rewriting the response address and, where required, ports. If packets are received, their tuples are also compared against reply addresses (and ports). NAT expects packets to be available without fragments. (If necessary and possible, IPv4 packets are refreshed when output from the (non-Netfilter) IPv4 stack.)

NAT helper modules

Similar to the helper modules for connection tracking, there are NAT helper modules which, in addition to the package inspection, also manipulate original addresses into reply addresses in the data stream.

nftables

nftables is a further or new development of the filter options in the Linux kernel that was started by the Netfilter developers in 2009. Like iptables, ip6tables, arptables and ebtables, nftables is based on the Netfilter software layer in the kernel. The main reason for starting the project was and is to standardize multiple codes created by the separate tools for IPv4, IPv6, arp protocols and bridge filtering. The new filter tool was called NFTables , the command line tool for it was called nft . To achieve these goals, nftables was designed from the outset to replace iptables. Due to the success of iptables and the countless tools and firewalls that are based on it, the project did not find the use it wanted for a long time. Therefore the developers decided to introduce a compatibility layer to iptables. The filter engine was implemented as a kind of "virtual machine" that can process the filter rules in a byte code. In principle, Netfilter allows more processing options than the old projects, but until 2016 had not yet achieved the full range of functions for the replacement of the old projects, so that both projects currently coexist in the kernel. NFtables was included in the standard Linux kernel with version 3.13 and partially also backported to older kernels for Linux distributions ( Red Hat Enterprise Linux 7 - Kernel 3.10).

For the user, nftables has the advantage of a standardized syntax for IP, arp and eb rules and the fact that rules for IPv4 and IPv6 can often be standardized.

Other Netfilter projects

Although the following are not kernel modules that build directly on the Netfilter code infrastructure, some other software packages are supported by the Netfilter project.

ulogd

ulogd is a userspace program that is used to receive and archive packets (or their properties) and event notifications from the Netfilter subsystem. iptables can forward packets to userspace using the “userspace queuing” mechanism and connection tracking can interact with ulogd to obtain further information (e.g. connection status) about packets or events (e.g. connection closed, connection was NAT- ed).

ipset

The userspace program ipset is used to set up, view and otherwise manage so-called "IP sets" within the Linux kernel . An IP set is usually a set of IP addresses , but it can also contain sets of network numbers or ports , depending on the type of set.

Such sets are much more efficient to search through than if regular iptables rules were checked and processed piece by piece, but the sets naturally require more memory. Different storage models are available in IP Set , so that the user can choose an optimal solution for himself.

Unlike most of the Netfilter extensions such as Connection Tracking , IP Set is more likely to be associated with iptables. It does not use any netfilter hooks, but provides an iptables module for the membership test and minimal changes (setting / deleting) of IP set contents.

Web links

Homepages:

The workshop:

Technical Documentation:

Individual evidence

  1. ↑ http://lxr.linux.no/linux+*/net/netfilter/core.c#L157
  2. ↑ a b netfilter / iptables project homepage - About the netfilter / iptables project. In: netfilter.org. Accessed March 7, 2018 (English).
  3. ↑ Netfilter's Connection Tracking System, by Pablo Neira Ayuso, June 14 2006: people.netfilter.org (PDF; 185 kB)
  4. ↑ Adoption nftables-Wiki, accessed on May 15, 2019.
  5. ↑ https://www.heise.de/select/ix/2018/1/1514658860742410
  6. ↑ IP sets (English) - official project website at netfilter.org ; As of March 30, 2011