Netfilter

Netfilter is a software project that provides translation and more relevant for firewalls tools for the Linux kernel, among other packet filter, Network Address.

Furthermore, the software layer called Netfilter in the Linux kernel that is called when receiving and sending network packets. This only initiates the execution of other modules as just packet filter. These modules can then intercept and manipulate packets.

• 5.1 NAT helper modules

• 6.1 ulogd
• 6.2 ipset

History

The netfilter / iptables project was initiated in 1998 by Rusty Russell in life, who was also the author of its predecessor ipchains. With growth of the project he founded in 1999 the Netfilter Core Team (or simply Core Team; main development team ). The software produced there - called from here on Netfilter - is licensed under the GNU General Public License ( GPL) and was in March 2000, integrated into the Linux kernel, version 2.3. In August 2003, Harald Welte became chairman of the core team. In April 2004 - after an intensive search by the Netfilter project in commercial products that sold the software without having to adhere to the license conditions - Welte in Germany reached an historic injunction against Sitecom Germany. In September 2007, Patrick McHardy, who led the development in recent years, the new chairman of the core team.

Iptables previously were the then predominant firewall packages in Linux 2.2 ipchains and ipfwadm in Linux 2.0, which had similarities to BSD's ipfw. Both ipchains and ipfwadm also intervened directly in the network code to manipulate packets, since there were no generic interface such as Netfilter so far.

While ipchains and ipfwadm packet filtering and NAT combined (especially three certain varieties of NAT, Masqueradieren, port forwarding and redirection ), are divided into smaller package operations in netfilter modules - see more on this below. Each operation hangs at a Netfilter at different positions to manage packages. The connection tracking and NAT subsystems are kept general for netfilter and more powerful than the truncated versions with ipchains and ipfwadm.

Iptables

Kernel modules ip_tables, ip6_tables, arp_tables ( underscores part of the name ) and ebtables are a major component, and thus "user" of the Netfilter Hooksystems; they put it on a table- based system for defining firewall rules that allow filtering or manipulation. The tables can by means of the user-space programs iptables, ip6tables, arptables or ebtables be administered.

Each table is, strictly speaking, a separate hook, and of course each was introduced for a particular purpose. Netfilter relates to this, insofar as tables are processed in a certain order. Otherwise, all tables are passed on to the same sub-function, which then passes over each rule and executing this.

Chains in this respect correspond from where the netfilter stack was invoked, eg packet reception ( PREROUTING ), delivered locally (INPUT ), forwarded (FORWARD ), issued locally (OUTPUT ), and shipping ( POSTROUTING ). Netfilter modules that do not provide tables ( see below), if necessary, inspect the origin, so as to decide which operations are to be carried out.

• The iptable_raw module registered when it is loaded, a hook that is called before any other Netfilter hook. It also makes a table called raw available, in which packets can be filtered before they reach memory-intensive operations such as connection tracking.
• The iptable_mangle module registers a hook, and a table called mangle, which is run after connection tracking ( but before another table) so that manipulations can be performed on packets that may affect later decisions such as NAT or packet filter.
• The iptable_nat module registers two hooks: DNAT - based transformations are processed before the filter-hook, SNAT - based transformations thereafter. The nat table in the course of which is available, is merely a " configuration database " which is intended only for NAT pictures, not for packet filtering.
• Iptable_filter the module registered, the filter table, which is used for general packet filtering.

Package Defragmentation

The nf_defrag_ipv4 module is used to defragment IPv4 packets before Connection Tracking ( in nf_conntrack_ipv4 module) receives this. This step is necessary for the connection tracking and NAT "helper " modules (sort of " mini - ALGs " ) within the kernel that do not inspect the data stream fragment across and therefore more likely to work with fragment- free packages.

Defragmentation of IPv6 packets is not a extra module, but is integrated into nf_conntrack_ipv6.

Connection Tracking

One of the most important building on Netfilter connection tracking functions ( lit. " connection tracking ", " connection monitor "). Connection tracking allows the kernel to keep track of all of the logical network connections or sessions to keep, and thus all packets that make up a compound to provide each other with respect. NAT is all related packets to be transformed in the same way depending on this information. Also, iptables can use this information to provide Stateful Packet Inspection ( SPI).

The status of a " ( Netfilter ) connection" but is independent of any conditions of a potential transport protocol such as TCP or SCTP ​​. One reason for this is that the mere forwarding of packets, so no local delivery, the actual TCP - consuming process does not have to come into play. Even connectionless protocols such as UDP, IPsec ( AH / ESP), GRE and other tunneling protocols have one, even if "pseudo " - connection state. Heuristics for such protocols usually a time-based inactivity timeout comes into play, deleted a Netfilter connection after which, and thus "forgotten" is.

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 being used; for TCP / UDP are the port numbers for the tunnel, it may be the tunnel ID, but is otherwise just zero, as if it were not part of the tuple. To read the TCP port in any case, packets are inevitably defragmented.

Netfilter connections can be manipulated with the userspace program conntrack.

Using iptables connection tracking can make insight on connection parameters such states ( states ), status ( statuses ), etc. packet filter rules stronger and easier to handle. The main conditions are:

• "NEW": the packet starts a new connection
• " ESTABLISHED ": the packet belongs to an existing connection
• "Related": this state is assigned to a packet that would start a new compound, the compound but an " expected " was. The aforementioned mini - ALGs rely on these expectations, such as when the nf_conntrack_ftp module finds the " PASV " command in an FTP connection.
• "INVALID ": The package was rated as invalid, for example when it does not follow the TCP state transition graph.
• " Untracked " is can be assigned by the administrator to bypass connection tracking for a certain package (see above: raw table) a special state

An example would be that the first packet is classified as "new" from the connection tracking. A subsequent response packet would then be "established" and an ICMP error packet would be " related". However, an ICMP error packet Had not allocate connection, it would be classified as "invalid ".

"Helper " modules

Means other plugins can extend as far as connection tracking that it has been informed by application layer protocols and thus be appreciated that two or more compounds "related" ( related ). Let us take for example the FTP, which first opens a control connection for each data transfer, however, a further separate. Is this nf_conntrack_ftp module loaded, so the first packet of an FTP data connection as a "related " will be classified instead of " new", since it is logically part of an existing connection.

The helper modules inspect only one package at a time. So If important information that is relevant to connection tracking, be divided into several packages, either by IP fragmentation or TCP segmentation, the modules can not fulfill its task. IP fragmentation is opposed to forced defragmentation, but TCP segmentation is not covered so far. In the case of FTP, it was assumed that a segmentation would "close" commands such as PASV not normally occur with conventional segment sizes, and thus segmentation will also be ignored in Netfilter.

Network Address Translation

Each connection has "original addresses " (source, destination ) and " reply - address ", which are initially equal. NAT in netfilter is realized that the reply-to address, and where wanted, ports, be rewritten accordingly. If packets are received, the tuple is also compared against response addresses ( and ports). NAT expects packets available free of fragments. (If necessary and possible IPv4 packets are refragmentiert on the issue of ( non- netfilter ) IPv4 stack. )

NAT helper modules

Similar to the helper modules for connection tracking, there are NAT helper modules that implement even manipulation of original addresses to reply-to addresses in the data stream in addition to the packet inspection.

More Netfilter projects

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

Ulogd

Ulogd is a userspace program used for receiving and archiving of packets ( or their properties ) and event notifications from the Netfilter subsystem. iptables can forward packets using the " userspace queuing " mechanism to userspace and connection tracking can interact with ulogd for more information (eg connection state) packets or events (eg closed connection, connection has been ge - NAT ed exchange ).

Ipset

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

Such sets are much more efficient search than if regular iptables rules would be reviewed and processed piece by piece, but along with sets is of course a possibly more memory. Different memory models are available in IP set so that the user can select an optimal solution for themselves.

Unlike most netfilter - extensions such as connection tracking, IP set is more likely to bring with iptables in combination. It uses no netfilter hooks, but provides ( Set / Cancel ) IP set - content a iptables module for membership test and minimal changes.

Netfilter workshop

The netfilter project organizes annual events for developers, which serve to advise on further research and developments and discuss. The last workshop was held in Breisgau ( Germany ) in late August 2011 in Freiburg.